Agent Harness Engineering Survey 论文所想

相关笔记：[[AI|AI 知识总结]]

最近看到了一篇关于 Agent Harness Engineering: A Survey 的论文，在这里做个学习记录。

从 Prompt 到 Harness

工程的边界一直在扩大：Prompt Engineering → Context Engineering → Harness Engineering。每个阶段关注的问题不一样，但都在摸索围绕模型的工程该长什么样。

Prompt Engineering 设计模型调用：system 指令、few-shot 示例、输出格式、推理模板。

Context Engineering 管理多步执行里的信息状态：检索什么文档、记住哪些历史、怎么排序和过滤，让模型每一步都能看到对的信息。

Harness Engineering 协调整个闭环系统：prompt 和 context 怎么跟执行环境、工具接口、持久状态、生命周期控制、可观测性、验证、治理绑在一起。它控制的是输出如何变成行动，结果如何反馈到下一步。

Harness 时间线

这张是从论文下截取下来的，里面详细表明了 harness 的发展时间线～

从论文中的这张图可以总结出来：

• 2022-2023 年的 ReAct 时代，harness 就是个 while 循环加 prompt 模板加几个工具调度；AutoGPT 和 BabyAGI 把问题暴露出来了：执行失控、context 爆炸、状态丢失、副作用没人管。
• 2023-2024 开始有学习式工具使用（Gorilla、ToolLLM）、多智能体协作（CAMEL、ChatDev、MetaGPT）、第一批 benchmark（SWE-bench、AgentBench、WebArena、GAIA）、协议标准化的雏形（MCP、A2A）。
• 到 2025-2026，部署经验积累到一定程度，“harness engineering” 开始被当作独立学科讨论，也开始出现只改 harness 不改模型的实验结果。

ETCLOVG 七层分类

此论文把 Harness 工程拆成七层。前四层是系统的结构核心，后三层是围绕核心的控制平面。

详细分类视图

这张图把每一层再往下拆。每个分支对应一个 ETCLOVG 层，叶子节点是论文用来组织调查的子类别，层名后面的 §3-§9 是对应的论文章节，可以当索引用。

E 执行环境与沙箱： 叶子按"代码在哪跑、被什么约束"来分：通用托管沙箱、computer-use 基础设施、代码专用沙箱、框架内建运行时、浏览器评测环境、OS 级权限沙箱，最后还有一层抽象，把不同沙箱统一成同一套接口。

T 工具接口与协议： 从协议标准（MCP、A2A）开始，到工具的描述、发现与选择，再到把工具用法直接训进模型的 tool-augmented training，最后处理多会话下的扩展性与会话管理。

C 上下文与记忆管理： 叶子按时间跨度排开：短期活跃窗口、中期会话状态与跨次运行的持久化、长期记忆系统，再加上长程上下文技术和 context drift 的边界问题。[[RAG]] 这类检索增强技术也落在这一层。

L 生命周期与编排： 控制流的三种组织方式：单 agent 的内层 [[Loop]]（ReAct 循环）、多 agent 编排模式、从 issue 到 PR 的完整任务管道。

O 可观测性与运维： tracing 与监控平台、agent 专用运维平台、成本追踪与优化、可靠性工程，再到把这些信号汇在一起的统一可观测性。

V 验证与评估： 五个叶子连起来是一条评估流水线：任务与 benchmark 对齐、执行前就绪校验、受控执行与轨迹捕获、多层次裁判与失败归因、持续回归与部署反馈。

G 治理与安全： 权限模型与身份管理、生命周期 [[Hooks]]、组件加固、声明式 constitutions、审计基础设施，最后是对整个 agent 安全威胁面的梳理。

前四层（环境/工具/上下文/编排）解释了系统搭建的过程，后三层（可观测/验证/治理）记录的是如何监管系统，想深入某个子类直接翻对应章节就行。

核心主张

这篇论文不只是做分类，还有三条主要论点：

Harnesses 是独立系统层
真实场景中的可靠性很大一部分是取决于执行控制、反馈循环、治理、评估和运维设计等等，对模型本身的能力要求反而不是很注重。更多时候瓶颈在 harness 而不在模型，将未来的发展重心从模型迁移到了 Harness 上。

ETCLOVG 细化了技术重点
之前的六组件框架往往把可观测性和治理混在其他层里，但这篇论文认为在生产部署中，可观测层和治理层各自有独立的技术栈和负责团队，不应该被降级为子模块。ETCLOVG 的真正价值是把架构边界画清楚，让不同团队可以独立演进各自负责的层。

数据分析

论文把大量开源 agent-harness 项目映射到这个七层模型里，七个层的简称分别是环境层、工具层、上下文层、编排层、可观测层、验证层、治理层。统计到的关于编排层 primary 项目有 47 个，是最多的；其次是验证层 21 个；环境层 20 个，工具层 12 个，治理层 14 个，可观测层 15 个，上下文层 9 个。

能看到编排层是最多的，说明社区投入agent 执行流程上最多，SWE-bench、WebArena 这类 benchmark 也推动了编排层工具的发展。上下文层项目存在但分散，很多是作为大框架的内置模块存在，独立出来的记忆系统不多。这意味着上下文管理更多是框架附带的 feature，没有单独作为一个研究方向。可观测层/治理层在开源中偏少。这能够看出来可观测性和治理在商业产品里更有价值（企业愿意为此付费），环境层项目增多可说明沙箱隔离这个工程问题已经被社区认真对待了，各种代码执行环境，比如 Codex 的 computer-use。

跨层权衡

论文从各层的交互中提炼出了几条反复出现的问题

成本问题

安全的沙箱、更长的上下文、更强的思考强度，都会提升任务质量，但肯定是会增加 token 消耗的、这些都是成本。生产环境中的 harness 不能把"质量"当成单一标量目标，他们更加关注成本、技术安全问题等等，这些都是业务上的考量。

安全问题

更丰富的工具、更宽松的权限会覆盖到更多的任务范围，模型能够影响的范围也越广。工具、上下文策略、运行时权限、身份认证、审批等，所有这些机制共同决定了 agent 的"权限边界"。做一个能力强的 agent 和做一个安全的 agent，往往是冲突的目标。

耦合问题

Harness 的各层之间是耦合的。prompt、工具、沙箱、验证器这些中间件组合在一起时，可能会出现牵一发而动全身的情况。比如：

• 一个激进的 context 压缩策略减少了 token 消耗，但导致验证器无法正确判断输出质量
• 一个严格的安全沙箱阻止了恶意工具调用，但也误杀了合法的工具组合

论文给出的结论是：harness 的改动应该被当作系统级改动来测试，而不是在单个模块上做优化然后假设其他层不受影响。除了问题可能就会影响模型执行过程，最坏的情况就是坏的产出 =v=

从框架到平台

论文指出了一个正在发生的生态转变：过去的各种 agent 框架，比如 LangChain、LlamaIndex ，提供抽象的框架，适合研究和实验；到现在的 agent 平台，比如 Cursor ，在此基础上加了持久工作空间、评估回路、治理约束，更加适合生产部署。

这个转变的核心驱动是：单人实验时，框架够用；多人长期用时，需要平台。意味着未来 1-2 年里，harness 工程的重点会从"搭框架"转向"搭平台"——也就是把可观测层、验证层、治理层这种插件的形式内化为核心功能，或者说是必备技能。

五个开放问题

论文在结尾提了五个尚未解决的研究问题，每个都跨多个 ETCLOVG 层：

1. 执行环境的硬化与扩展

• 如何统一做 prompt 注入、目标错位、组合放大攻击的安全评估？
• 如何建模不同沙箱方案的成本与安全权衡？
• 如何在不同部署形态之间保持语义一致性？

2. 长期运行 agent 的可靠状态

• 把上下文管理重新定义为状态估计问题：在每次压缩、检索、遗忘操作中，到底丢失了多少信息？毕竟可以长时间运行的 agent 肯定需要对上下文管理有非常严苛的要求。
• 需要对丢失的信息加 provenance、矛盾检测、显式的过期标记
• 目前大多数 agent 在长程任务中表现下降，根因往往在状态管理而不在模型能力。我个人使用 agent 时也有同样的感受，当上下文完全干净时，模型的状态往往是最好的，当上下文窗口占到 70～80% 时，生成的质量就开始有明显的偏差了。这时候要么新开一个窗口要么就进行压缩，上下文窗口的问题一直是模型的痛点…

3. Trace 原生的失败诊断

• 现在的溯源和日志工具主要是出现问题后作为调试材料进行使用的
• 未来 traces 应该成为主要对象——从中直接计算输出权重、失败归因、回归测试

4. 跨 agent、工具、人的标准交接协议

• 交接不应该只传一个文本摘要，还应该传递：意图、约束、权限、artifacts、provenance、预算状态、风险等级、trace 历史、未解决的决策
• 问题是如何让协议足够丰富以保证安全和可恢复，同时足够简单以实现广泛采用
• 这也是 MCP 和 A2A 协议在尝试解决但还没解决好的问题

5. 模型进步后的自适应简化

• 现在每一层的约束，如沙箱、验证规则、审批流程，其实都隐含了一个"模型目前在这个方面做不好"的假设，但有没有一种可能，随着模型能力提升，有些变成了纯粹的成本、或者是负担，模型能够内化流程且能根据当前的环境找到更好的解决方式。
• 未来的 harness 需要有能力对自己的每层干预做 ablating，在 quality、latency、cost、risk 联合约束下找出最简配置，然后自动化地简化自己，现在有些势头已经出现，如 Pi，追求极简的一个 harness，各种联网工具或者内置skill 都按需所取，配置适合自己的工作流的 agent。

个人思考

读完这篇论文，有几个点让我印象最深刻

1. Harness 是独立的系统层
现在大家都会关注很多模型的评分，判断这个模型有多强，跑分有多高，会认为 agent 的上限由模型决定，但这篇论文阐述的方向跟我们不太一样：生产环境的下限由 harness 决定。模型决定你能做多难的任务，harness 决定你能不能稳定、可重复地把任务做完，这个视角把软件工程问题放到了和能力问题同等重要的位置。这是我觉得 harness 是作为一个独立的系统层的依据 =v=

2. 编排层项目数量明显比排第二的验证层多
说明社区在"让 agent 跑起来"这件事上极度内卷，在"怎么判断 agent 跑得对不对"这件事上投入不足。现在都开始加强 harness 的研究，是追求复杂的编排还是极简的框架，这个问题或许对做研究的人来说是个契机，评估和验证层面的工具可能比执行层面的工具有更大的改进空间。

3. 自适应简化
五个开放问题里我最感兴趣的是这一个。未来的 harness 会不会变成一个能够自动优化自己的系统？这和模型量化有点像，但针对的是工程层。如果这个方向有突破，harness 工程可能会从手工硬编排转向根据模型的能力进行自动优化。

4. 从框架到平台的转变
这个趋势其实已经在发生了——Cursor、Hermes 这些产品本质上是把 LangChain 级别的能力包装成了持久化产品。如果这个转变加速，未来 harness 工程的门槛会降低，但深度定制的门槛会提高。

以上就是我对这期论文的所感所想，欢迎指导交流～

论文信息：Li et al., “Agent Harness Engineering: A Survey”, 2026.
论文链接：https://picrew.github.io/LLM-Harness/
开源项目目录：https://github.com/Picrew/awesome-agent-harness

![[LLM-Harness.pdf]]