Harness 才是产品：Agent 的竞争重心正在从模型上移到执行层

从一个榜单说起

今天 GitHub 趋势榜前五里有四个项目在做同一件事：给 Agent 装配工作台。paperclip 管的是「办公室里所有的 agent 谁负责什么」，hindsight 管 agent 的记忆，univer 把表格、文档、幻灯片、PDF 打包成 agent 可以直接调用的运行时，impeccable 管的是让 agent 输出好看的设计语言。

四个项目，没有一个在训练模型。

再看另一个细节：univer 的定位词从「开源 Office SDK」改成了「The Office Harness for AI Agents」。一家做了几年表格引擎的公司，把官网第一行字改掉了。这不是文案品味问题，是它判断钱和注意力正在流向哪里。

如果把 2024 年的关键词是「模型能力」，2025 年的是「提示词工程」和「上下文工程」，那 2026 年正在被反复提起的词是 harness engineering，执行层工程。本文想聊清楚三件事：harness 到底在管什么，它今天的三个真实战场长什么样，以及一个工程团队应该从哪里下手。

一、Harness 是模型外面那层会拒绝你的代码

先把定义钉死。模型只做一件事：读进一段 token，吐出一个结构化的工具调用。它不拥有文件系统，不真的执行 shell，不记得上一轮发生了什么。真正把工具调用接过来、校验参数、丢进隔离环境跑、再把结果喂回去的，是 harness。

Anthropic 在它的 Managed Agents 架构里给的切分最干净，把系统分成三块：

• session：持久的事件日志，记录发生了什么
• harness：调用模型、路由工具调用的那个循环
• sandbox：真正执行代码的环境

这三件事没必要挤在一个进程里。OpenAI 的 Agents SDK 从另一个方向做了同样的切分：想要自己掌控循环就用 Responses API 直接写，想让运行时托管轮次、工具执行、护栏、会话和追踪就用 SDK。DeepSeek 开源的 harness 更进一步，把模型适配器、工具注册表、会话日志、agent 循环全部做成可替换插件，官方代码本身只是这套约定的一个默认实现。

在 harness 的六个组件里，最容易被低估的是最后两个。

有一句话说得挺狠：如果你指望模型自己拒绝坏动作，那你等于没有安全机制。拒绝只有在 harness 校验了工具调用 schema 并在执行前把它拦下来的时候才算数。这个判断把责任从模型划到了工程侧，也解释了为什么「换了更强的模型」经常不能让 Agent 变可靠。

二、第一个战场：工具面与上下文税

harness 设计里最反直觉的一条经验是：工具越多，Agent 越蠢。

Speakeasy 做过一个特别清楚的实验。他们把 Dog CEO API 的 107 个端点全部生成成 MCP 工具，让 Claude 和 qwen3 去调。107 个工具时两个模型都崩：Claude Desktop 开始回报「响应被中断」，模型凭空编出一个不存在的「金毛寻回犬」端点。砍到 40 个工具，四次调用对三次还带一次幻觉；20 个工具时 20 次对 19 次；10 个工具时全对。作者的原话是，这不是缓慢衰减，是悬崖。

数字更难看的地方在成本侧。有团队实测，GitHub MCP 加 Playwright 加一个 IDE 集成，在 Agent 还没读到用户第一句话之前，就吃掉了 20 万 token 窗口里的 14.3 万，占 72%。原因很朴素：一个函数 schema 连同描述、参数名、类型、文档字符串，就是 150 到 400 token；一个 20 工具的服务就是 3000 到 8000 token；而且这些 schema 在 agent 循环里每一轮都要重新加载一次，20 轮的会话等于把这份税交 20 遍。

平台方的反应很一致，各自用遥测数据划了线：

于是三种工程解法在 2026 年同时落地，而且分别落在不同层：

• 提示层，把工具定义延迟加载。Anthropic 的 Tool Search 把 77K token 的工具栏压到 8.7K，官方数据是 Opus 4 的 MCP 基准从 49% 提到 74%，Opus 4.5 从 79.5% 提到 88.1%。
• 基础设施层，网关做工具裁剪。前提是网关必须真的裁剪，Arcade 那句吐槽很到位：最容易实现的网关是「全部代理转发」，而那恰好是把工具过载原样搬到上一层的最快方式。
• 编排层，把工具面收敛成子 Agent。主 Agent 只看到 query_slack、query_drive、query_crm、update_crm 四个工具，28 个底层工具被折叠进各自的子 Agent，分页、游标、先查后写这些脏话只在真正用到的轮次里加载。

我自己的看法是，最值得抄的不是某个具体方案，而是那条判据：Agent 的工具面应该等于它的岗位说明书，而不是它能碰到的所有 API 的并集。真实案例已经证明了这条路能赚钱：GitHub 把 Copilot 的 MCP 工具从 40 个砍到 13 个，SWE-Lancer 和 SWE-bench Verified 上的成绩反而涨了 2 到 5 个百分点，延迟降了 400 毫秒。Block 把 Linear MCP 服务器重做了三次，最后留两个工具。

三、第二个战场：记忆、状态与可回滚

第二个战场是状态。它比工具面难，因为工具面是静态配置，状态是运行时行为。

多轮调试里最常见的抱怨是「它刚才明明做对了」。根因往往不在模型，而在 harness 没有把「做对了什么」变成可复用的持久状态。代码 Agent 里比较成熟的答案是拿文件系统当持久状态，用 git 当回滚路径，把子 Agent 当作上下文隔离手段。这恰好是 univer 那条最值得关注的设计：它给 Agent 的编辑引入 worktree 概念，Agent 在隔离的草稿分支上改，人审完再合并。

这个借用的妙处在于它把「审阅」从事后补救变成了结构性步骤。大家做 Agent 改文档时都撞过同一堵墙：改动要么生效要么不生效，改错了就去翻一个从来没为「每分钟改四十次」设计的版本历史。把 git 的分支模型搬到表格上，review 就不再是 vibe check。

与之配套的是无头运行时。如果整套 Office 逻辑不需要浏览器就能跑，Agent 就能在服务端循环里打开一个工作簿、跑一遍公式链、截一张范围图检查自己的排版、然后关掉。表格从「Agent 得去戳的界面」变成了「它能调用的计算环境」。这句话其实适用于所有 harness：能让 Agent 自我验证的接口，比能让它操作的接口值钱得多。

四、第三个战场：审批门与验证回路

第三条战线是安全边界，也是最容易被当成「上线前再补」的部分。

2026 年收敛出两种参考设计，它们不是竞品，是两种押注。Codex 走的是每个任务起一个云容器，靠进程边界隔离并发；Claude Code 走的是本地常驻，对每个有后果的动作显式征求同意，把开发者当成共同签署人。前者适合批量、可丢弃、隔离优先的工作流，后者适合需要贴着真实代码库、频繁改主意的场景。

再往下是成本权衡。把沙箱当成常驻环境，最省事也最贵，Agent 的每一次非代码轮次都在付容器的钱；把沙箱当成一个工具按需调用，非代码轮次就便宜下来，代价是每次开沙箱有额外延迟和状态搬迁成本。

审批门的难点从来不是「要不要有」，而是校准。门太多，Agent 比人手动干活还慢；门太少，一次幻觉出来的 API 调用就能捅出生产事故。比较靠谱的经验是先激进后放松：一开始把所有写操作都设成需要批准，等某个动作类别累积到足够的成功样本，再按类别放开。这本质上是把运维里的信任建立过程搬到了 Agent 上。

还有一个经常被忽略的事实：多用户才是 harness 设计的真正分水岭。单用户场景下，权限、记忆、审计都可以糊过去；一旦十个开发者共享一个实例，就必须处理按用户继承权限、记忆命名空间隔离、以及带归属信息的防篡改审计日志。这三件事不做，Agent 越能干，风险越集中。

五、给团队的三条落点

把上面三块拼起来，harness 工程其实可以拆成三句可执行的话。

第一，先画边界，再选框架。框架是蓝图和建材，harness 是运行时。LangChain、CrewAI 属于前者，Claude Agent SDK、Codex 的运行时、自研编排层属于后者。很多团队跳过 harness 直接把框架搭出来的 Agent 推上生产，失败恰好都发生在缺失的那一层。设计顺序建议反过来：先写清楚任务「完成」的标准，再倒推需要哪些工具、需要什么上下文、哪些步骤值得验证、哪些步骤必须过人。从组件清单正着设计，往往会长出一堆任务根本用不到的 capability。

第二，把上下文当预算管，不当资源用。工具面只是最容易量化的那部分。真正要建立的习惯是每一轮都问一遍：这次模型看到的 token 里，有多少真的和当前这一步有关？一兆窗口不会解决工具选择的问题，它只会推迟你撞墙的时间。MCP-Atlas 那个基准可以拿来做参照：1000 个跨 36 个服务器、220 个工具的真实多服务器任务，全场最好的 Claude Opus 4.5 也只有 62.3% 的通过率。这个数字提醒的是，多服务器工具编排本身还远没到「配好就能用」的阶段。

第三，把验证回路当第一优先级的功能来做。行业里有一种说法是 harness 的质量能解释生产环境 Agent 可靠性的六到七成，这个比例我没办法验证，但方向我认同。Agent 输出能不能被自动校验，决定了它是能整夜跑，还是必须有人盯着。表格能被程序读回来核对，代码能跑测试，比任何提示词技巧都更能提高可交付性。

六、一句话总结

模型层正在被三家大厂拉平，价格也在往下走，所以护城河正在往模型外面挪：挪到工具面的裁剪能力、状态的持久化设计、审批门的校准经验，以及验证回路的自动化程度上。这四件事没有一件能靠换模型解决。

对今天在榜上这几个项目来说，它们的价值不在于「又一个 Agent 工具」，而在于它们把 harness 的某个缺口做成了独立产品。对做产品的人来说，这个信号更直接的读法是：别再造第 N 个通用 Agent 框架了，找到一个高频、具体、有脏活的工作台，把它做成 Agent 能直接调用的运行时，被集成的概率远高于被重新实现。

参考来源：

• GitHub Trending 2026-09-27 榜单（paperclip、hindsight、univer、impeccable）
• The Complete Guide to Agent Harness（harness-engineering.ai）
• Harness Engineering: Matching Agents to the Work（interloom.com）
• Building Your Own AI Agent Harness: Start With Boundaries, Not Frameworks（Tosin Akinosho, Medium）
• AI Agent Harnesses Explained: Architecture, Ecosystem, and Multi-User Design（boringbot Substack）
• The Over-Tooled Agent Problem: Why More Tools Make Your LLM Dumber（tianpan.co）
• How Many MCP Servers Is Too Many? The Tool Overload Problem（getunblocked.com）
• 更多 MCP 工具的代价：Cloudflare Code Mode、Anthropic Tool Search 官方数据
• Univer: The Office Harness for AI Agents（univer.ai / dream-num/univer）