📐 Harness 工程 · 中文翻译

17 结论与未来工作

本文给出了 11 个 LLM 驱动编码 Harness 的源码级解剖——每个主流商业 LLM 供应商各一个(Claude Code/Anthropic、Codex/OpenAI、Gemini CLI/Google、Mistral Vibe/Mistral),外加七个开源设计——连同元 Harness 对照点、一个季度演化的纵向 diff,以及对这个领域转向平台的记述。

17.1 要点

  1. 1.

    架构重要,但不是当下话语所暗示的那种重要。智能体循环的精巧程度不能预测基准表现(Mini-SWE-Agent 的 50 行循环报告出前沿区间的成绩)。但它确实预测生产就绪度:安全基础设施、用户体验、可扩展性——以及越来越多的客户端与传输,最大的系统如今把大部分体量压在这里。

  2. 2.

    模型与智能体的关系是共同演化的,而耦合关乎更新循环,不关乎能力。厂商原生的优化(缓存边界、思考预算、模型专属提示词、路由)在耦合光谱的两端都被行使:厂商系统原生行使,Hermes、Pi 与 OpenCode 则从多供应商基底出发、集中支付逐供应商条件化成本来行使。只有厂商保留的是服务端的共同演化——Codex 经一个目录端点按每次模型发布重新调校提示词、推理档位甚至多智能体工具,无需客户端更新。

  3. 3.

    安全在架构上是昂贵的——而且是一种选择,不是规模的后果。Codex 的跨平台沙箱(如今带 vendored bubblewrap)仍是一笔基准从不度量的可观投入,元 Harness 在高一层又付了同样的账单。但 4 月版“体量意味着沙箱”的相关性已经破裂:Hermes 与 OpenCode 位列最大系统却零操作系统级隔离,转而把钱花在内容型威胁防御与语法感知的权限控制上。

  4. 4.

    多智能体编排收敛到分层模式,而协议找到了第三种角色。协调者-工作者形态如今出现在 7 个系统中。ACP 服务的不只是编辑器 ↔\leftrightarrow 智能体边界(语料库中 6 个采纳者),还有设计简报之外的角色:Harness 托管,OpenHands 把 Claude Code、Codex 或 Gemini CLI 作为可互换后端运行。A2A 仍是 Gemini CLI 独自的跨厂商网格押注。子智能体协调在 9 个多智能体系统中的 8 个里留在进程内。

  5. 5.

    可扩展性标准已成定局:技能领先。当 Pi 打破平局——实现 agentskills.io 而直接拒绝 MCP——技能(9/11 系统)超越了 MCP(8/11)。技能层获得了注册表、信任分级、来源验证、跨厂商发现(OpenCode 读 ~/.claude/skills)与第一批智能体作者(Hermes 的自我改进循环、Gemini CLI 的抽取收件箱)。

  6. 6.

    双重缺席是真实的、经过复核的,如今有了历史解释。横跨 11 个系统约 400 万行代码,没有任何智能体运行时使用通用智能体框架,也没有任何运行时对代码用 RAG——全部依赖手写的异步循环与确定性的结构检索。缺席挺过了语料库三倍扩容与为期三个月的复审,与 Anthropic 公开的指导 [16, 19] 及独立的 AHE 结果 [85] 相互印证。它的解答是第 14.2 节的 Harness-框架合并。

  7. 7.

    Anthropic 有效智能体系列预言了我们观察到的架构。2024 年 12 月至 2025 年 9 月间发布的四篇工程文章,与 11 个独立开发系统中文档化的模式高度吻合。这反映的是共享的经验现实、被指导塑造的设计,还是两者皆有,值得作为独立问题追寻。

  8. 8.

    这份分析可以直接落地。第 16 节为构建新 Harness 的实践者提炼了 18 条具体的、以证据为锚的设计建议,外加一个直接实现其中 10 条的 90 行最小可用 Harness 脚手架(清单 3)。加上源码审计本身,据我们所知,这是这门学科第一份基于证据、且不是单一厂商白皮书的操作指南。

  9. 9.

    平台化转向不再是假说。 4 月版以 CLI 即框架假说的名义谨慎提出的东西,第 14 节如今作为一项已完成的转向来记录:Harness 以可引入的 SDK 交付,而框架厂商出货 Harness(第 14.2 节的合并);能力分发有了市场、注册表、信任分级 [89] 与智能体作者;厂商互写对方磁盘状态的导入器并暴露 MDM 级(移动设备管理)治理;智能体本身作为一个 OpenAI 兼容端点背后的模型变得可寻址;一个元 Harness 在一个 API 之后编排 11 个厂商 Harness——本研究系统的五个位列其中(第 14.4 节)。 周围的生态数据指向同一方向:MCP 的 8000+ 服务器生态带着应用商店式的策展病灶 [86],技能被形式化为可组合的包 [87],配有类 npm 的包管理器 [88],22–29% 的 GitHub 项目带着智能体痕迹 [91],以及把开发框定为编排的“SE 3.0”叙事 [92]。 开发者不再用框架编程,而是在框架里面编程;观察 7.1 的厂商锁定,正在变成操作系统与 IDE 一直制造的那种结构性锁定 [90]——而元层已在套利它。 Harness 会长合为少数主导平台、碎片化为可互操作的运行时,还是从上方被大宗商品化,是未来一年的竞争问题;三种结局的架构前提今天都已在源码之中。

17.2 未来工作

我们的分析浮现出几个方向:

  • •

    统一的评测框架:在正确性之外同时评估安全、用户体验、成本效率与可扩展性,弥合基准表现与生产就绪度之间的鸿沟。

  • •

    参考架构规范:把本文识别的模式(事件溯源、策略即代码、上下文分叉、工具延迟加载、中间件管线、基于哈希的循环检测、JIT 仓库上下文)形式化为可复用的架构框架。

  • •

    安全策略的形式化验证:面向策略即代码系统,就给定策略配置下允许哪些智能体动作建立保证。

  • •

    模型-智能体共同演化的实证研究:追踪智能体脚手架如何跨模型代际变化,量化模型专属优化的性能影响。Lin 等人的 AHE 系统 [85] 证明自动 Harness 演化已可行;纵向研究如今可以量化比较自动演化脚手架与手工脚手架跨模型代际的表现。

  • •

    跨系统基准套件:在受控条件下对全部 11 个系统跑相同任务,使我们识别的架构权衡可以直接对比。

  • •

    智能体间协议采纳研究:追踪 ACP 的三种角色(编辑器集成、Harness 托管,以及经 A2A 的跨厂商网格),并度量 OpenHands 的 ACP 后端与 Omnigent 的适配器舰队之类托管式 Harness 拓扑的开销。

  • •

    纵向续篇:4 月/7 月的快照对已把本研究变成一个时间序列;按季度重新固定版本,就能定量而非轶事地度量模式扩散半衰期、提示词瘦身与平台化轨迹。

  • •

    元 Harness 经济学:自上而下的大宗商品化(第 14.4 节)能否持久捕获价值,以及面向 Harness 能力的一致性基准方法是否会成为标准接口。

  • •

    Anthropic 与业界对齐的因果分析:经访谈、设计文档考古与提交历史相关性,把公开指南的影响与趋同工程区分开。