多模型时代拼的是harness

最近看到 GitHub 把内部那套 Copilot harness 通过 Foundry 对外开放了，我第一反应是：终于有人把「多模型」这件事从口号做成了基础设施。现在做 AI 产品，谁都知道不能绑死一家模型，但真要做多模型切换，性能、质量、成本三条线同时压过来，光调 prompt 根本兜不住。

harness 这个词很多人还陌生，说白了就是模型外面那一整层编排：给什么指令、塞什么上下文、工具怎么调、长任务怎么拆、失败怎么重试。模型提供智力，harness 决定这份智力能不能稳定落地。GitHub 这套东西撑起了 Copilot Code、Copilot Studio、CLI、VS Code 等一堆入口，说明它不是在 demo 里跑通，而是在真实流量下磨出来的。我觉得这次开放最实际的价值，是让中小团队不用自己从零搭一套多模型编排。以前想接第二个模型，往往要重写工具调用和上下文管理，迁移成本高到劝退。现在托管式 harness 把「换模型不换栈」变成默认选项，团队可以把精力放回业务逻辑和成本优化上。但也要冷静看：托管 harness 意味着编排层的话语权交出去了，模型路由策略、日志、数据边界这些细节，企业客户得提前问清楚。另外多模型不等于自动更优，路由规则设计不好，反而会出现同一任务不同模型输出风格割裂的问题。我的判断是，未来一两年 harness 会像当年的容器编排一样，从自研变成采购。真正拉开差距的不再是谁能接更多模型，而是谁更懂自己的任务该在什么节点用哪个模型、花多少成本。这对做跨境工具和 AI 应用的团队来说，是个值得提前布局的信号。