大模型可以推理、生成文本、理解语言和编写代码，但把一个模型放进聊天窗口，并不会自动得到一个能够长期工作的 Agent。
模型知道“应该做什么”，不代表它能看到当前工作区；它能生成命令，不代表命令真的执行过；它说“已经完成”，也不代表测试、日志和现实环境证明了结果正确。
真正让模型进入现实环境的，是包围在模型周围的一套运行时系统，也就是 Agent Harness。
本文不讨论某个产品的内部实现细节，而是建立一套分析框架：哪些机制让 Agent 看见信息、组织任务、改变环境、保存状态、与人协作、接受治理并最终交付可验证结果。
一、模型能力和 Agent 能力不是一回事
模型能力主要存在于模型本身：语言理解、推理、生成、视觉理解、代码生成等。Agent 能力则是整个系统表现出来的行为：
- 能读取项目并理解当前状态；
- 能选择合适工具完成动作；
- 能跨多个步骤推进任务；
- 能记住之前发生过的事情；
- 能根据测试失败继续修复；
- 能在需要授权时暂停等待人类；
- 能把结果、证据和风险交付出来。
这些行为通常不是一个模型调用完成的，而是多个原语组合的结果。
| 最终能力 | 可能依赖的 Harness 原语 |
|---|---|
| 长期自主执行 | 持久化目标、计划、重试、预算、恢复和停止条件 |
| 修改代码 | 文件读取、结构化编辑、Shell、Git、测试和回滚 |
| 记住项目规则 | 文件记忆、检索、上下文注入、摘要和优先级 |
| 安全操作 | 身份、沙箱、权限、审批、Secrets 和审计 |
| 多 Agent 协作 | 任务拆分、通信、共享状态、结果汇总和冲突处理 |
因此，“模型很强”不能直接推出“Agent 很可靠”。模型负责提出判断和动作，Harness 负责把判断放进一个可观察、可约束、可恢复的运行环境。
二、什么是 Harness 原语
原语可以理解为构成 Agent 系统的基础机制。它们不是面向用户的完整功能，而是可以组合出更高层能力的积木。
例如，“长期自主执行”不是一个按钮，而是由这些原语共同构成：
持久化目标
+ 计划状态
+ 上下文压缩
+ 工具执行
+ 错误重试
+ 中间检查点
+ 预算和停止条件
+ 最终验证
同一个原语也可以服务多个能力。文件系统既是感知界面，也是行动目标和长期记忆；测试既能发现错误，也能作为持续执行的反馈信号；审批既是人机协作机制，也是治理边界。
三、八类原语总览
可以从 Agent 与信息、环境、人类和其他 Agent 的关系出发，把 Harness 拆成八类：
- 感知原语：让 Agent 看见文件、网页、日志、界面和外部数据。
- 认知与编排原语：让 Agent 形成目标、计划、工具选择和任务分解。
- 记忆与上下文原语：让信息跨越有限上下文窗口和多个会话。
- 行动原语：让 Agent 修改文件、执行命令、调用 API 和操作浏览器。
- 协作原语：让 Agent 与用户和其他 Agent 共享进度、任务和结果。
- 治理原语：限制身份、权限、网络、Secrets 和高风险动作。
- 持续执行原语：让任务跨越多个 Turn、故障、等待和上下文窗口。
- 验证与交付原语：用测试、日志、Diff、产物和回滚证明结果。
这八类不是八个孤立模块，而是一个闭环：
感知 -> 认知与编排 -> 治理检查 -> 行动 -> 验证
^ |
| v
+---- 记忆与上下文 <- 持续执行 <- 协作与反馈
任何一层缺失，系统都会出现明显短板。没有感知，Agent 只能依赖用户复制粘贴；没有行动，它只能当顾问；没有治理，它不适合进入真实环境；没有验证，它可能把错误结果当成成功。
四、一个最小 Harness 需要什么
如果只做一个最小的编码 Agent，至少需要：
输入：用户目标和项目目录
感知：读取文件、搜索文本、查看 Git 状态
认知：生成计划和下一步
行动：修改文件、运行测试
反馈：读取命令输出和失败日志
状态：保存当前任务和已完成步骤
治理：限制工作区和高风险命令
交付：展示 Diff、测试结果和剩余风险
它不需要一开始就拥有复杂的多 Agent 编排、语义检索和异步调度。关键是每一个动作都能回到一个可观察结果：文件发生了什么变化，命令返回什么，测试是否通过，任务是否真的结束。
可以用伪代码表示一个最小循环：
while not goal.completed:
context = observe_workspace(goal)
decision = model.plan_next_step(context)
if policy.requires_approval(decision):
pause_for_user(decision)
result = execute(decision)
record_event(decision, result)
if result.failed:
update_failure_state(result)
elif verify(result):
goal.advance()
这里的 model.plan_next_step 只是整个系统中的一个环节。observe_workspace、policy、execute、record_event 和 verify 同样重要，甚至更适合由确定性软件负责。
五、为什么“工具调用”不等于 Agent
给模型增加一个天气工具，它就能查天气；给它一个搜索工具，它就能搜索。但单个工具调用不等于完整 Agent。
一个 Agent 至少需要处理：
- 什么时候使用工具；
- 工具返回的数据是否可信；
- 下一步是否依赖上一步结果；
- 工具失败要不要重试；
- 失败重试会不会造成重复副作用；
- 是否需要用户审批；
- 什么时候算完成；
- 如何交付证据。
工具是行动原语，Agent 是围绕目标组织多个原语的系统。把工具列表堆得很长，也不能自动解决选择、权限、状态和验证问题。
六、用成熟度判断系统处在哪一步
可以把 Harness 粗略分成六个层级：
Level 0：对话模型
只有文本输入输出，不能访问真实环境，也不保存跨会话状态。
Level 1：工具 Agent
能够读取文件、调用工具和执行简单命令，但主要还是单轮任务。
Level 2：有状态 Agent
具备持久化会话、项目规则、计划状态和上下文压缩，可以恢复之前的任务。
Level 3：可靠 Agent
具备权限控制、审批、测试反馈、超时、重试和部分失败处理。
Level 4：协作 Agent
支持用户中途调整方向，支持子 Agent 委派、消息和结果汇总。
Level 5：长周期自治系统
目标跨会话持久化，能在预算和治理边界内长期运行，并用外部证据检查完成条件。
这不是能力排行榜，而是工程检查表。一个系统不一定要追求 Level 5；如果只是修改个人项目，Level 2 或 Level 3 可能已经足够。复杂度应该由任务风险和持续时间决定。
七、怎样比较两个 Harness
不要只比较“支持多少工具”或“模型看起来多聪明”。可以从以下维度提问：
| 维度 | 需要检查的问题 |
|---|---|
| 感知 | 能读哪些环境，信息是否带来源和时间 |
| 状态 | 任务能否恢复、分叉和审计 |
| 行动 | 工具参数是否明确，失败是否可观察 |
| 治理 | 是否有沙箱、审批、Secrets 和网络边界 |
| 持续执行 | 是否支持超时、重试、预算和取消 |
| 验证 | 是否有测试、Diff、日志和完成审计 |
| 协作 | 用户能否中途纠正，子任务能否归并 |
| 交付 | 是否能产出可下载、可审查、可回滚的结果 |
一个只展示模型回答、不展示中间状态和工具结果的系统，很难客观评估可靠性。长期工作的关键证据，往往在模型最终回复之外。
八、常见误区
误区一：把更长上下文当成记忆
上下文窗口能放更多内容，但不等于这些内容会被正确选择、更新和引用。长期记忆还需要持久化、检索、优先级和过期治理。
误区二：把自主性等同于不需要人
高质量 Agent 应该在高风险动作前暂停，在低风险重复动作上自主推进。人类的作用从逐步遥控变成目标设定、异常处理和最终验收。
误区三：把工具数量当成系统能力
没有工具选择、权限和验证，工具越多，错误面越大。少量高质量工具往往比一大堆语义重复的工具更容易控制。
误区四：忽略交付
生成一段回答不是交付。真正交付需要文件、Diff、测试、日志、来源、版本和回滚路径。
结论
Agent Harness 是模型进入现实世界所需的运行时系统。它把感知、推理、工具、状态、权限、协作、持续执行和验证连接起来，让模型不只是生成建议，而是围绕一个持久目标完成可观察、可恢复、可交付的工作。
理解 Harness 的意义，不是为了给系统贴更多概念标签，而是为了在设计 Agent 时知道缺什么：看不见环境，就补感知；任务总是跑丢，就补状态；总是误操作，就补治理；总说完成但结果错误，就补验证。
参考资料
- Anthropic：Building Effective Agents，用于理解工作流、工具和 Agent 系统的组合方式。
- Model Context Protocol Specification，用于理解模型与外部工具/数据连接的协议边界。