多模型时代，agent 的胜负手在 harness

最近看到 GitHub 把内部那套 Copilot harness 通过 Foundry 对外开放了，我第一反应是：这才是真正值得关注的基建层。模型能力再强，如果外面那层编排没做好，agent 照样跑不起来。GitHub 自己说得很直白——想竞争就得支持多模型，而想用好多模型，就得有一个足够好的 harness。

harness 到底是什么？简单说，模型提供智力，harness 就是模型之外的一切：给 agent 正确的指令、上下文、执行环境，把工具调用串起来，还要在性能、质量和成本之间做平衡。难的不是做一个能跑的版本，而是做一个跨模型、跨入口都稳定一致的版本，并且长期维护下去。GitHub 这套东西已经跑在 Copilot Code、Copilot Studio、Copilot 应用、CLI 和 VS Code 里，算是经过大规模验证了。这次开放的意义在于，开发者不用自己从零搭编排层，就能直接构建会推理、会用工具、能完成长任务的 agent。换模型不用换 harness，也不用动整个技术栈，这对企业客户尤其省事。我的判断是，未来 agent 产品的差距会越来越多地体现在 harness 上，而不是单纯拼模型参数。不过也别把它当成万能药。托管服务省了维护成本，但定制空间和迁移成本还是要提前想清楚。对中小团队来说，先用成熟 harness 跑通场景是划算的；对已经有深度自研编排的团队，是否切换就得算一笔账了。总的来说，这是一个信号：基础设施正在从「模型即产品」转向「harness 即产品」。谁能把多模型编排做稳，谁就更有机会把 agent 真正落到业务里。