Copilot Fusion 正式可用：你选的是「用力程度」，不是模型

一、10 月 28 日到底发了什么

在模型选择器里选 Copilot Fusion，你选的不是某个具体模型，而是一套运行时路由与编排系统。你不需要在任务中途换模型，也不需要判断哪一步该用谁：每个 prompt 进来，Fusion 自己决定用哪些模型、怎么配合，以及每步需要多少推理力度。执行过程中你能看到每一步在用哪个模型，但中间草稿可能被改写或丢弃，所以最终只呈现一个回答。这个设计对开发者的实际影响是：以前那种「先问便宜模型、不满意再换贵的」的手工动作，被内化进了产品里。

二、三个用力等级，差的不只是钱

Fusion Standard 在成本、质量和延迟之间取平衡，日常活基本落在这一档，通常是单模型直接做。Fusion High 面向「体量不小但范围清楚」的任务——修一个复杂 bug、跨几个文件改一处行为——允许增加模型调用次数来换取更稳的结果。Fusion Max 把最强模型放在最前面，但仍然考虑 token 效率，留给最难、最需要深度推理的活。文档里还有第四个 Fusion Fast，但用户选不到，它只在 VS Code 的内联聊天里出现。真正的配置难点在第二档：High 值不值，取决于你的任务里「一次改对」和「返工一次」哪个更贵。

# Routing decisions are only auditable if you log which model ran each step.
# Copilot's usage export gives per-request token counts; join them to the
# effort level your team actually selected.
import csv, collections

by_tier = collections.defaultdict(lambda: {"tasks": 0, "tokens": 0, "resolved": 0})

for row in csv.DictReader(open("copilot_usage.csv")):
    tier = row["effort_level"].lower()
    b = by_tier[tier]
    b["tasks"] += 1
    b["tokens"] += int(row["total_tokens"])
    b["resolved"] += 1 if row["task_outcome"] == "resolved" else 0

for tier, b in sorted(by_tier.items()):
    t = b["tasks"] or 1
    print(f"{tier:<18} tasks={t:<5} tok/task={b['tokens']//t:<7} resolved={b['resolved']/t:.0%}")

# The row you are looking for is the one where tok/task doubles and the
# resolved rate does not move.

三、三种执行模式：单跑、级联、评审

Single 是一个模型直接做完。Cascade 让一个高效模型先起草，再由一个裁判判断是接受还是升级到更强的模型。Critique 是一个模型起草、多个模型并行独立挑刺、汇总意见后由原模型改写。模式是按每个 prompt 选的，同一个会话里第一条用 Single、第二条用 Critique 完全正常，而且这个选择步骤本身开销很小。文档里有一句话值得抄下来：只有任务值得时才会增加模型调用，直白的活不会为一次它并不需要的审查等待，也不会消耗 AI credits。翻成工程语言就是——别把评审当默认动作。

# Cascade is not magic: a cheap draft, a judge, and a rule for escalation.
# You can build the same loop around any provider, with your own acceptance bar.
from dataclasses import dataclass

@dataclass
class Draft:
    text: str
    model: str
    files_touched: int
    tests_pass: bool
    lint_clean: bool

def judge(d: Draft) -> bool:
    # Deterministic signals first. Never ask a model what a test suite can answer.
    if not d.tests_pass or not d.lint_clean:
        return False
    if d.files_touched > 4:
        return False  # wide edits are where cheap drafts quietly break things
    return True

def cascade(task, cheap_model, strong_model):
    d = cheap_model.run(task)
    if judge(d):
        return d, "accepted"
    s = strong_model.run(task, prior=d.text)  # escalate, draft kept as context
    return s, "escalated"

四、那组数字该怎么读

60 分、差两分、一半成本、一半 token、少 40% 时间，这五个数放在一起才有意义。单看分数，Fusion Max 是在追平前沿模型；单看成本，它是砍半。但这是厂商公布的、在第三方指数上的一次测量，指数本身是代理指标。你真正要知道的是你自己的分布：如果你的任务绝大多数是一两行的改动，Standard 和 Max 的差距可能小于噪音；如果你的任务是跨仓库重构，那两分可能是全部。所以别把「平均成本减半」当承诺，把它当一个需要你自己复现的假设。

{
  "copilot_fusion": {
    "default_effort": "standard",
    "pool": {
      "enabled_for_fusion": ["model-a-code", "model-b-reason", "model-c-fast"],
      "disabled_for_fusion": ["model-legacy-2025"]
    },
    "team_overrides": {
      "platform": "high",
      "docs-site": "standard"
    }
  }
}

// A shape like this is worth writing down even if your admin console stores
// it differently: it forces the argument about who gets Max and who does not.

五、三个容易踩到的运维细节

第一，Fusion 自己没有上下文窗口。每一步都在执行它的那个模型自己的窗口里跑，界面上显示的窗口是按池子里最小那个模型的限制给出的保守值。第二，路由是沿着缓存边界和「会话复杂度发生大跳变」的位置发生的，目的是避免为了不带来质量提升的缓存重建而多付钱——反过来说，如果你的系统前缀每轮都在变，这套优化对你是失效的。第三，管理员能控制池子：企业可以按模型单独设置策略状态，甚至只对 Fusion 禁用某个模型而不对全员禁用；把 Fusion 设为默认模型则需要在企业托管设置里动。

# Routing happens along cache boundaries, so keep the expensive prefix stable.
# A prefix that changes every request re-bills the whole context every turn.
import hashlib, json

def make_prefix(repo_rules: str, tool_schemas: dict) -> tuple[str, str]:
    blob = json.dumps({"rules": repo_rules, "tools": tool_schemas}, sort_keys=True)
    return blob, hashlib.sha256(blob.encode()).hexdigest()[:12]

def build_turn(prefix_text: str, prefix_id: str, user_turn: str) -> list[dict]:
    return [
        {"role": "system", "content": prefix_text},  # identical bytes every turn
        {"role": "user", "content": f"[turn {prefix_id}] {user_turn}"},
    ]

# Editing repo_rules should create a new prefix on purpose. Editing the user
# turn must never invalidate the cache sitting above it.

六、翻默认值之前，先量三件事

第一件，每个任务的 token 和你实际付的钱，按用力等级分开统计。第二件，解掉率——任务一次做完的比例，而不是「模型说它做完了」的比例。第三件，p95 延迟，因为级联和评审都是在尾部加时间，平均值会骗你。把这三件在切换前后各跑两周，你才有资格说 Fusion 对你们团队是快还是慢。

# Do not compare routing setups on vibes. Compare resolved tasks per dollar,
# with p95 latency next to it, or you will optimise the average and ship a
# regression to the slow tail of your team.
import json, statistics

def summarise(path: str) -> dict:
    lat, tok, resolved = [], [], 0
    for line in open(path):
        r = json.loads(line)
        lat.append(r["latency_ms"])
        tok.append(r["total_tokens"])
        resolved += 1 if r["resolved"] else 0
    return {
        "n": len(lat),
        "p95_ms": statistics.quantiles(lat, n=20)[18],
        "tok_per_task": round(sum(tok) / len(tok)),
        "resolved_rate": round(resolved / len(lat), 3),
    }

print("baseline", summarise("runs_before.jsonl"))
print("fusion  ", summarise("runs_after.jsonl"))