什么是 Agent Harness？

harness 原意是指马具，在 2026 年 Agent 的语境中泛指除了大语言模型（LLM）本身之外，所有用于约束、支撑、度量和纠正 Agent 行为的工程化基础设施。

harness 的出现是自然而然的，就像 function_calling、skills 这些概念一样：

function_calling：解决如何让 LLM 和外界环境发生交互并获取交互的结果。
skills：如何将特定领域的人类经验适时地提供给 LLM，让 LLM 更好地完成在特定领域中的工作。

Harness 则是为了解决如何让 Agent 长时间可靠地运行，处理多步骤的真实世界的复杂任务这个问题而出现的。模型的能力通过 API 调用的方式被商品化、精细的 prompt engineering 被更长上下文的模型抛弃，下一个期待被吞噬的护城河可能就是 “Agent Harness”。

真实的 coding agent 场景

让我们思考一下一个通过 coding agent 进行代码开发的程序员在没有 harness 时的工作流程：

old fashion coding agent workflow

现在物美价廉的 model 们：qwen、minimax、glm，都完全可以胜任其中的每一项任务，所以是什么在阻止这一切全部自动化起来？问题本质：不是“能不能做”，而是“能不能稳定地一直做”：

模型没有“过程约束”，只能靠概率生成。
缺乏可验证的执行闭环，机器可判定的 success criteria。
变更方向发生错误后难以自我纠正：忘记之前做了什么、重复修改同一段代码、回滚不了错误决策。
不可控的行为：
1. 随意删改文件导致环境崩溃
2. 跳过指定步骤，忽略指定规范
难以观测和度量 agent 的行为

如果把 Agent Harness 看成一个“洋葱式系统”，很多问题就会变得清晰：越靠内是模型智能，越靠外是工程约束。Harness 的作用，不是替代 LLM 思考，而是一层一层把不稳定的模型包裹成一个可控系统。

用洋葱模型理解 Agent Harness

从内到外看，Agent Harness 可以拆成 8 层,越靠内越接近模型本身的智能，越靠外越接近工程系统施加的约束、反馈和治理。

LLM Core: 负责理解任务、生成代码、完成推理。这是 Agent 的“大脑”，但它天然无状态，也天然不稳定。
   ↓
Reasoning & Planning：负责把“直接回答”变成“先想再做”，比如先定位问题、再决定下一步动作，常见形式包括 ReAct、Plan-Execute 等。
   ↓
Skills / Tools：负责把读写文件、执行命令、调用 API 这类能力接给模型，让它不只是会说，而是真的能动手。
   ↓
Execution Loop：负责把一次性回答变成 plan、act、observe、decide 的闭环，这也是 agent 真正开始持续工作的地方。
   ↓
State & Memory：负责保存短期任务记忆和长期规则记忆，记录进度、上下文和历史尝试，避免 agent 失忆和反复试错。
   ↓
Evaluation & Feedback：负责用测试、lint、规则校验甚至 judge 来判断结果是否正确，决定继续迭代还是停止。
   ↓
Environment & Constraints：负责通过沙箱、权限、目录范围、命令白名单等机制给 agent 加护栏，限制它的行动边界。
   ↓
Observability & Governance：记录日志、trace、成本、成功率和审计信息，让整个系统可观测、可回放、可治理。

更准确地说，Agent Harness 本质上是工程化解决垂类 Agent 和通用 Agent 的稳定性、扩展性问题。