多模型时代，别自己造轮子

最近看到 GitHub 把内部那套 Copilot harness 通过 Foundry 对外开放了，挺有感触。以前我们团队做 Agent 产品，最头疼的就是模型一换，整个工具调用和上下文管理就得重写一遍。现在官方把多模型编排层做成托管服务，等于把最脏最累的活接过去了。

说白了，模型提供智力，harness 提供的是围绕模型的一切：指令注入、上下文裁剪、工具执行、长任务的状态管理。这些事单看都不难，难的是跨模型、跨终端还要保证性能、质量和成本三者平衡。GitHub 自己拿它跑 Copilot Code、Copilot Studio、CLI 和 VS Code，说明这套东西至少在生产环境里被反复捶打过。我的判断是，这对中小团队是利好，对做中间层的公司是压力。以前大家拼的是谁家 prompt 调得好、谁家工具链稳，现在这些逐渐变成基础设施。真正拉开差距的，会是你对业务场景的理解，以及怎么用这套 harness 把长任务拆得又稳又省。当然也别指望开箱即用就万事大吉。托管 harness 省的是维护成本，但模型选型、评测集、失败重试策略这些还是得自己定。我比较关心的是它跨模型切换时的一致性到底如何，以及长任务跑崩了之后的恢复粒度。这些细节决定它能不能真进生产。总的来说，方向是对的：别每家都重复造编排层，把精力留给产品和场景。接下来我会拿一个小型内部工具先试水，重点看成本和稳定性，再决定要不要把现有链路迁过去。