多模型代理框架成刚需

最近看到 GitHub 把内部用的 Copilot harness 通过 Foundry 对外开放了，这件事挺值得琢磨。以前大家做 agent 都在卷模型本身，现在风向明显变了——模型能力再强，没有一套好的编排层去喂指令、管上下文、跑执行，实际落地效果就是上不去。

所谓 harness，说白了就是模型外面那一整圈东西：怎么给指令、怎么塞上下文、怎么调度工具、怎么控制成本。GitHub 这套东西同时支撑了 Copilot Code、Studio、CLI、VS Code 等多个产品线，说明它已经在真实场景里被反复打磨过。对中小团队来说，自己从零搭一套跨模型、跨端的编排层，维护成本高得吓人，直接复用成熟方案是更现实的选择。我比较认同它强调的「多模型」思路。现在没有哪个模型能在所有任务上都最优，写代码、做推理、跑长任务各有擅长的选手。如果 harness 绑死一家，换模型就得动整个技术栈，这个隐性成本很多团队一开始没算进去。能在一个框架里按任务挑模型，才是真正省心的做法。当然也要冷静看待。托管服务意味着把编排层交给平台，长期看会不会形成新的锁定，值得提前想清楚。另外这类框架的卖点是「复杂长任务」，但实际效果还得看具体业务场景的验证，不能光看发布时的演示。我的判断是，接下来一两年 agent 的竞争会从模型层往工程层迁移，谁能把 harness 做得又稳又便宜，谁就更有机会。对出海团队来说，选型时除了看模型榜单，也该把编排层的可迁移性纳入考量。