多模型时代拼的是harness

最近看到 GitHub 把内部那套 Copilot harness 通过 Foundry 对外开放了，我第一反应是：这才是真正难啃的骨头。模型能力再强，如果没有一层好的编排把指令、上下文、工具调用和长任务执行串起来，实际落地效果会大打折扣。很多团队以为换个更强的模型就万事大吉，其实真正的差距往往在模型之外。

所谓 harness，说白了就是模型周围的一切：怎么给指令、怎么塞上下文、怎么调度工具、怎么处理多轮和长任务。它难就难在要同时兼顾性能、质量和成本，还要跨多个模型和多个入口保持一致。自己搭一套能跑不难，难的是长期维护——模型一更新、接口一变、场景一多，维护成本会迅速吃掉团队精力。GitHub 这套东西已经在 Copilot Code、Copilot Studio、Copilot 应用、CLI 和 VS Code 里跑起来了，现在通过 Foundry 提供全托管方式，开发者可以直接拿来构建会推理、会用工具、能跑复杂长任务的 agent。我觉得这个信号很明确：以后竞争不是单模型比拼，而是谁能用一套 harness 灵活调度多个模型，按任务选最合适的那个，而不用换掉整条技术栈。对出海团队来说，这点尤其值得琢磨。我们经常要在成本、延迟和质量之间做取舍，如果每换一个模型就得重做一遍集成，那基本没法规模化。托管 harness 的价值就在于把这层脏活接过去，让团队把时间花在业务和产品上，而不是反复造轮子。当然，托管也意味着对底层编排的掌控变弱，关键场景还是得评估可观测性和可替换性。我的判断是，harness 会逐渐成为和模型同等重要的基础设施，甚至在某些场景下更决定成败。选型时别只盯着榜单分数，多问问这套编排能不能跨模型、能不能扛住长任务、维护成本到底谁承担。能把这些问题想清楚的团队，才更可能在多模型时代跑得更稳。