Paper Report

Agent Harness for Large Language Model Agents: A Survey

这篇综述把 LLM agent 外部的运行时基础设施提升为研究对象：模型能力只是必要条件，真正部署时还要靠 harness 管执行、工具、上下文、状态、安全和评测。

论文定位Preprints.org 综述，未同行评审，发布时间为 2026 年 4 月 28 日。
核心定义Agent harness = H = (E, T, C, S, L, V)。
主张现实 agent 可靠性经常被 harness 约束，而不只是模型能力约束。
阅读态度框架价值强，但证据来源混杂，不能把所有数字当作同等强度实验。

1. 论文基本信息

论文标题Agent Harness for Large Language Model Agents: A Survey
作者Qianyu Meng, Yanan Wang, Liyi Chen, Yihang Li, Wei Wu, Wenyuan Jiang, Qimeng Wang, Chengqiang Lu, Yan Gao, Yi Wu, Yao Hu
来源Preprints.org
DOI10.20944/preprints202604.0428.v3
时间2026 年 4 月 28 日
同行评审状态未同行评审
资料页https://github.com/Gloriaameng/Awesome-Agent-Harness
汇报人待填写

这篇论文是一篇关于 LLM Agent Harness 的综述。它的核心判断是：LLM agent 的可靠性不只由底层模型决定，还强烈依赖模型外面的运行时基础设施，也就是 agent harness。

作者把 harness 形式化为六元组 H = (E, T, C, S, L, V)，分别对应执行循环、工具注册表、上下文管理器、状态存储、生命周期钩子和评测接口。论文进一步梳理了 20 多个代表系统、9 类技术挑战和一组未来研究方向。

我的判断：这篇论文的概念整合价值比较高，很适合建立“harness 是什么”的统一语言；但它不是严格实验论文，很多证据来自预印本、官方文档和产业博客，所以应当把它当作“领域框架综述”，而不是“已被充分验证的定量结论”。
Figure 1Graphical abstract
Graphical abstract
图 1 把论文的两个核心放在一起：左侧是 harness-only change 也能带来性能变化的案例，右侧是六组件框架。

2. 背景：为什么需要 Agent Harness

2.1 从模型能力到运行时治理

过去很多 LLM agent 研究会把重点放在模型能力本身，例如更强的推理、更长上下文、更好的工具调用训练和更复杂的多智能体协作。这个思路默认了一件事：只要模型足够强，再配上 prompt 和上下文，agent 就能稳定完成真实任务。

论文认为这个假设不够。真实 agent 系统不是“模型直接行动”，而是模型被放进一个运行时系统中。这个系统决定模型什么时候调用工具、能看到什么上下文、失败后如何恢复、状态如何保存、日志如何记录、权限如何控制，以及最后如何被评测。

Agent System = LLM + Harness + Environment

因此，很多看似是模型能力不足的问题，可能其实是 harness 设计不充分。

2.2 三条历史线索

软件测试 harness

提供受控执行环境、自动化验证和回归测试思想。

强化学习环境 / OpenAI Gym

提供环境接口、动作空间、观测空间和 benchmark 标准化思想。

早期 LLM agent 框架

暴露工具调用、上下文膨胀、循环失控、状态丢失等工程失败模式。

论文把 2022-2026 年的演化概括为三阶段：prompt engineering 管单个输入，context engineering 管进入模型的信息流，harness engineering 管完整运行时治理系统。

Figure 10Prompt -> Context -> Harness
Engineering paradigms
作者认为 agent 工程关注面正在从 prompt 字符串扩展到 context 管理，再扩展到完整的六组件运行时。

3. 研究问题与目标

这篇论文主要回答四个问题：

定义边界

什么才算 agent harness？它和 prompt、framework、agent OS、evaluation harness 有什么区别？

系统分类

现有代表性 agent 系统可以如何分类？哪些系统更接近 full-stack harness？

技术挑战

真实 harness 面临哪些跨组件问题？安全、评测、协议、记忆、规划如何互相影响？

研究路线

未来应该如何把 harness 作为独立研究对象推进？

它的贡献不是提出一个新模型或新 benchmark，而是试图给 agent 运行时基础设施建立统一定义、分类表和研究议程。

4. 核心框架：六组件 Agent Harness

4.1 H = (E, T, C, S, L, V)

组件英文作用
EExecution Loop管理 observe-think-act 循环，包括步骤顺序、终止条件和错误恢复。
TTool Registry维护可调用工具目录，做 schema 校验、权限约束、路由和监控。
CContext Manager决定哪些信息进入模型上下文，包括压缩、检索和优先级排序。
SState Store保存跨轮次 / 跨会话状态，支持恢复和长期记忆。
LLifecycle Hooks在关键边界做认证、审计、日志、策略执行和拦截。
VEvaluation Interface记录完整执行轨迹、状态、工具结果和成功信号，供评测和调试使用。

作者认为，最低限度的 harness 至少要有 E 和 T：没有执行循环就只是一次模型调用；没有工具注册和动作边界，就没有真正的 agent 行动接口。完整生产级 harness 则应该具备六个组件。

Figure 3Six-component architecture
Six-component architecture
六组件架构图。中间是模型调用，外面是执行、工具、上下文、状态、生命周期和评测接口共同构成的运行时治理层。

4.2 Execution Loop 是核心控制器

论文把 E 组件写成类似 labeled transition system 的形式。agent 运行过程被看成状态迁移：

idle -> observing -> invoking-model -> dispatching-tool
     -> awaiting-tool-result -> committing-state -> terminated

这件事的意义是：模型不是整个系统的控制器，模型只是执行循环中的一个被调用子程序。真正决定“下一步是否继续、失败是否重试、工具结果如何进入状态”的，是 harness 的执行循环。

这个视角对理解 agent 很关键。ReAct 只是一个原始 thought-action-observation 循环；AutoGPT 是单体式 harness；LangGraph 则把执行拓扑编码成图结构 harness。

5. 系统分类与证据

5.1 分类树

论文把系统大致分成三类：full-stack harnesses、framework / orchestration systems、capability modules / evaluation infrastructure。

Figure 11Taxonomy tree
Taxonomy tree
分类树把系统按架构完整性和栈位置组织起来。它不是能力排行榜，更像一张“这个系统主要解决哪部分 harness 问题”的地图。

5.2 完整性矩阵

论文用一个矩阵把代表系统映射到 E,T,C,S,L,V 六个组件上。它的观察是：full-stack harness 通常在 E,T,C,S,L 上比较完整；framework 往往只强在 E/T 或编排接口；能力模块只解决某个局部问题；评测基础设施则强在 V。

Table 4Completeness matrix
Harness completeness matrix
完整性矩阵是本文最实用的图表之一。它帮助快速判断一个系统主要实现了 harness 的哪些治理功能。
这里需要保留一点怀疑：表格标题写的是 23 systems，但表中实际行数看起来并不完全对应；正文有的地方又写 22 systems analyzed。这种数字不一致不影响核心思想，但说明论文整理层面并不完全严谨。

5.3 Harness 层变化带来的性能证据

论文引用了一组案例来支撑“harness 不是背景工程，而是性能决定因素”：

  • xAI / Can1357：只改 edit tool format 和上下文格式，SWE-bench 表现从 6.7% 到 68.3%。
  • LangChain DeepAgents：通过 harness 层 middleware、上下文注入、验证 hooks，把 TerminalBench 从 52.8% 提到 66.5%。
  • Meta-Harness：自动搜索 harness 配置，在 TerminalBench-2 上超过手工配置。
  • AgencyBench：同一模型在原生 harness 和独立 harness 中表现不同，说明 harness 选择会影响测量结果。
  • HAL：标准化 evaluation harness 后，评测从数周降到数小时，并暴露普通日志看不到的异常行为。
Figure 4Empirical evidence matrix
Empirical evidence matrix
这些案例说明 harness 层变动会显著改变 agent 表现。不过它们来自不同系统、不同 benchmark、不同报告来源，不能直接当作统一实验。

6. 九类核心技术挑战

论文把 agent harness 面临的问题整理成 9 类：安全、评测、协议、上下文、工具、记忆、规划、多智能体和成本经济性。

Figure 12Challenge coupling matrix
Challenge coupling matrix
挑战耦合矩阵说明一个关键点：这些问题不是互相独立的模块 bug。比如评测会同时牵涉执行、工具、上下文、状态、生命周期和轨迹记录。
挑战主要牵涉组件核心问题
Sandboxing & SecurityE,T,L模型生成的动作可能逃逸、越权、被 prompt injection 污染。
Evaluation & BenchmarkingE,T,C,S,L,Vagent 输出是轨迹，不只是字符串，评测很容易被 harness 细节污染。
Protocol StandardizationT,L,EMCP、A2A、专有 tool calling 协议边界不同。
Runtime Context ManagementC,S,E上下文保留、压缩、检索与安全风险相互冲突。
Tool Use & Tool ManagementT,L,V工具太多、schema 不准、权限组合和失败恢复都很难。
Memory ArchitectureC,S,L写入、检索、遗忘、权限和污染治理缺少统一接口。
Planning & Reasoning InfrastructureE,C,S,L从线性规划到 MCTS，治理责任逐渐转移到 harness。
Multi-Agent CoordinationE,S,L,V身份、消息校验、共享状态一致性和跨 agent 攻击。
Cost & Compute EconomicsC,S,T,E长上下文、工具 schema、子 agent 和反复规划会推高成本。

6.2 安全：agent 风险不是“模型说什么”，而是“系统做什么”

传统 LLM safety 主要担心模型输出有害内容；agent harness safety 更担心模型生成的动作会真的执行。攻击面包括直接 prompt injection、检索内容中的间接注入、工具文档投毒、memory poisoning、capability escalation、sandbox escape 和 cross-agent injection。

作者认为 Docker 这类容器隔离不一定足够，因为 agent 能调用工具、改文件、访问网络、长期保存状态。隔离机制需要根据风险选择 process-only、Docker/OCI、gVisor、Firecracker microVM 或 WebAssembly。

6.3 评测：agent 的输出是轨迹，不是单个答案

普通 LLM benchmark 常常只看最终答案，但 agent 评测必须看完整轨迹：调了哪些工具、中间状态是什么、是否误用了外部资源、是否绕过 benchmark、失败是模型错还是环境接口错。

论文提出评测应报告 harness 配置，包括终止策略、工具目录、上下文策略、状态持久化、policy hooks 和轨迹记录格式。这个思想和 HARNESSCARD 类似：以后报告 agent benchmark 时，不能只写 model name + score。

6.4 协议：MCP 与 A2A 是互补而不是替代

论文把 MCP 和 A2A 放到 harness 架构中解释：MCP 主要标准化 agent-to-tool 边界，对应 T 组件；A2A 主要标准化 agent-to-agent delegation 边界，对应多 harness / 多 agent 的 E/L/S 交互。

Figure 16Protocol tradeoffs
Protocol tradeoffs
MCP 优先解决工具生态标准化，A2A 更关注 agent 间语义完整性。论文的结论是没有单一“最好协议”，要看系统优先标准化还是表达力。

论文还提到 Anthropic Agent Skills：它不是单个工具调用协议，而是工作流层的可移植技能包，偏向 L 组件。一个自然的两层结构是：MCP 管原子工具，Agent Skills 管多步工作流。

6.5 上下文：context manager 是主动过滤器

上下文管理不是简单地“塞更多 token”。论文把策略从低保留到高保留排列：truncation、summarization、retrieval-augmented、structured memory、full replay + compression。

Figure 17Context management spectrum
Context management spectrum
上下文保留越完整，通常成本越高，安全风险也更难控制。context manager 的任务是做选择，而不是盲目保存一切。

这部分和我们之前讨论 RLM / hidden state refinement 的直觉有一点相通：都在问“模型每一步到底应该看到什么状态”。区别是这里不改模型内部，而是在模型外部管理进入上下文的信息。

6.6 工具治理：tool registry 是权限边界

论文把 tool registry 类比为操作系统的 system call table。它不是简单列表，而是权限、审计和失败恢复边界。工具治理包括注册时校验、调用前选择、调用时沙箱、失败异常分类、结果清洗和轨迹记录。

Figure 18Tool governance pipeline
Tool governance pipeline
工具从注册到结果进入上下文，整个生命周期都需要治理。工具不是越多越好，registry 也要主动裁剪可见能力。
一个很现实的结论：工具不是越多越好。论文引用 Vercel 的案例，工具数量从 15 降到 2 后准确率从 80% 到 100%。这说明 T 组件不仅要提供能力，还要限制能力。

6.7 记忆：memory 是基础设施，不是模型魔法

论文把 memory 分成 C 和 S 两个层面：C 决定哪些记忆进入上下文，S 决定哪些状态被持久化、如何索引、如何遗忘、如何授权访问。

Figure 19Memory architecture patterns
Memory architecture patterns
代表模式包括 MemGPT 的 paging、Generative Agents 的 memory stream、Reflexion 的 episodic buffer、MemoryBank 的遗忘曲线和 Voyager 的 skill library。

论文的关键批评是：现在没有类似 MCP 的标准 memory interface。不同 memory 系统的读写接口、写入权限、安全检查、遗忘策略都不可移植，所以很难公平比较。

6.8 规划：越复杂的 planning，越依赖 harness

从 ReAct 到 Tree of Thoughts，再到 MCTS 型 agent，模型的角色逐渐从“自己规划”变成“被 harness 多次调用的搜索子程序”。

Figure 20Planning progression
Planning progression
线性 ReAct 只需要简单循环；树搜索需要分支状态、预算、剪枝、回滚；MCTS 还需要 value backup、simulation 和训练信号生成。

这部分最重要的观点是：planning quality 是 model-harness system 的性质。模型能力强不代表搜索循环、状态回滚、预算控制和错误恢复就自动正确。

6.9 多智能体：多 agent 不是免费收益

多智能体系统带来新的治理问题：身份管理、agent 间消息校验、共享状态一致性、跨 agent prompt injection。论文把这些问题看成分布式系统治理问题，而不是简单的 prompt 协作问题。

Figure 21Multi-agent topologies
Multi-agent topologies
不同拓扑带来不同治理需求。role-based、market-based、simulation substrate 和 hierarchical delegation 的状态一致性风险并不相同。
作者引用了一个重要负结果：精心设计的单 agent 加 KV cache reuse，可以匹配同质多 agent ensemble。只有异质 agent 组合在提供不同能力或视角时，才更稳定地超过单 agent baseline。也就是说，多 agent 的协调开销必须被收益证明。

7. 研究方向

短期社区优先方向

  • Cross-component coupling：例如 context retention 和 security 的冲突。
  • Observability and debugging：结构化轨迹、断点、回放、差分分析。
  • Human-in-the-loop：风险驱动的审批点，而不是硬编码询问。
  • Cost and compute economics：用 Cost Per Task 衡量 harness 经济性。
  • Long-running autonomy：长期运行 agent 的自我改进和状态治理。
  • Automated harness engineering：用 agent 自动搜索 harness 配置。
  • Natural-language harness specification：用自然语言描述 harness 规则，但要解决可验证性。

长期研究议程

  • Formal verification and behavioral guarantees。
  • Cross-harness portability and unified benchmarking。
  • Protocol bridging and federated interoperability。
  • Long-horizon task decomposition。
  • Security model formalization。
  • Tool composition and dependency inference。
  • Energy-aware infrastructure design。
Figure 15Meta-Harness optimization loop
Meta-Harness optimization loop
Meta-Harness 把 harness 本身变成搜索对象：提出新配置、生成代码、跑 benchmark、收集轨迹，再把反馈用于下一轮优化。这和前一篇 AutoHarness 的思想可以连起来看。
Figure 22Research priority matrix
Research priority matrix
研究路线图把方向按影响和投入排列。作者认为 harness 研究需要从单组件优化走向系统级设计。
Figure 23Industry convergence
Industry convergence
论文用 OpenAI、Stanford/MIT、LangChain、Anthropic 的案例说明产业界和学界都在向 harness thesis 收敛。

8. 总结

Agent reliability = model capability translated through harness governance.

模型能力是必要条件，但不是充分条件。harness 决定能力如何被执行、约束、记录、恢复和评测。

如果用一句话概括：这篇论文不是提出一个新 agent 算法，而是把 agent 运行时基础设施本身提升为研究对象。

对我们理解 agent 很有帮助的地方在于，它把很多分散概念统一起来：

ReAct / planning loop -> E Tool calling / MCP -> T context compression / RAG -> C long-term memory -> S approval / policy / sandbox -> L trajectory logging / benchmark -> V

这样再看之前的 AutoHarness，它其实可以放在本文的“automated harness engineering”方向里：AutoHarness 是自动合成任务特定代码 harness；这篇综述则是在更高层次上定义整个 harness 研究版图。

9. 个人思考与批判

9.1 优点

  • 概念整合能力强。论文把工具、记忆、上下文、评测、安全、规划、多 agent 都放进 H = (E,T,C,S,L,V) 里，形成了比较清楚的讨论语言。
  • 抓住了 agent 工程中的真实问题。很多 agent failure 确实不是模型完全不会，而是因为工具接口差、上下文乱、错误恢复弱、权限边界不清、评测轨迹不完整。
  • 对“多 agent 不一定更好”“工具不是越多越好”“评测必须报告 harness 配置”这些判断比较清醒，不是单纯追逐复杂架构。
  • research agenda 写得比较具体。HARNESSCARD、memory interface、protocol bridge、formal invariant、Cost Per Task 都有可操作性。

9.2 局限性

  • 它不是严格意义上的系统综述。论文没有完整的 PRISMA 式检索流程、纳入排除标准、编码一致性统计。
  • 证据来源异质。它混合了 peer-reviewed paper、preprint、官方文档、产业博客和实践报告。启发性很强，但定量强度并不相同。
  • 部分表述有过强倾向。比如“the harness, not the model, is the binding constraint”在很多工程场景成立，但不应理解成模型能力不再重要。更准确的说法是：在模型能力达到某个阈值后，harness 常常成为可靠性瓶颈。
  • 分类有一些细节不一致。正文有时说 22 systems，有时说 23 systems；Table 4 的行数看起来也不完全对应。图号附近也有 Figure 16 / Figure 17 的不一致。
  • 闭源系统评分不够稳。Claude Code、DeepAgents 等系统内部实现并不完全公开，只能根据公开文档判断组件完整性。
  • 缺少一套统一实验来验证六组件框架。论文提出的框架很有解释力，但还需要跨 harness benchmark 来证明哪些组件真的带来多少收益。

9.3 对我们后续阅读的启发

以后读具体 agent 论文时，可以问：

改的是哪个组件？

这篇论文主要改的是 E/T/C/S/L/V 哪个组件？

能力还是治理？

它提升的是模型能力，还是 harness 治理能力？

有没有披露 harness？

它是否报告工具目录、上下文策略、状态和轨迹格式？

收益来自哪里？

收益是否可能来自工具、上下文、状态或评测环境，而不是算法本身？

能否迁移？

它能不能脱离原 harness 迁移到别的系统？

是否有单 agent baseline？

多智能体或复杂 planning 是否真正超过简单强 baseline？

9.4 可能的课题切入点

  • Harness-aware benchmark：让同一模型在多个 harness 中跑同一任务，测 harness 方差。
  • Memory interface standardization：给长期记忆定义统一读写和权限接口。
  • Tool governance：自动裁剪工具集合，降低工具过多带来的干扰和风险。
  • Harness transparency card：给 agent 论文统一披露 E,T,C,S,L,V 配置。
  • Automated harness search：延续 AutoHarness / Meta-Harness 思路，自动搜索上下文、工具、循环和验证策略。

总体来看，这篇论文的价值主要在“定义问题”和“组织领域”，不是在“证明一个具体算法最强”。读的时候要吸收它的框架，但不要把所有产业案例数字都当作同等强度的实验结论。