harness工程演进

以往对Agent讨论，大家关注的是模型够不够强/工具够不够多。

随着Agent大量在复杂任务景落地，大家对Agent的讨论已经从“能不能做”，变成了“能不能稳定/安全/可靠的做完”。

这就是harness的价值。

harness是一套帮助Agent稳定可靠运行的闭环系统。

它就像一套让Agent自动运行的FSD，具备了全链路监控与持续优化的能力。

从数据采集与处理，到实验管理，到监控告警，到可观测性，到版本与变更的回归，到全流程的自动化策略，实现了执行-采集-反馈-评估-优化的自闭环循环。

复杂任务场景落地Agent，架构上分为两类，一类是workflow形式，一类是agent形式。

很多人觉得基于workflow驱动的agent不够高级，但反而我认为复杂业务场景最好不要一上来就搞高度自治的agent，很多任务workflow其实更合适。

抽象的来说，建立workflow的过程，是我们建立业务与agent信任的过程。

比如用户提交文本，系统做分类，生成摘要，结构化知识抽取。或者一些客服类业务场景，都是偏固定流程的，比如检索信息，生成答案，转人工处理等。

这些任务的处理路径相对明确，不需要模型基于上下文探索，所以选取workflow形式往往更稳定，效率更高，有问题也更容易排查。

真正需要高度自治agent的场景，往往具备以下几个特征。

比如任务路径无法提前完全枚举，任务需要根据中间结果继续推进决策，任务需要调用多个工具并基于工具反馈调整下一步，或者任务执行时间比较长中间可能出现状态的不断变化。

比如coding agent，research agent等都具有以上特点。

所以agent工程化的第一步，是需要思考的是选取什么样的agent架构驱动形式。

如果任务适合workflow，却强行采用自治agent，结果就是简单问题复杂化，效果不好。同样，如果任务场景天然开放，却采用了固定workflow的架构，反而会在面对异常/分支时失败。

这就引出了什么样的agent架构需要harness，显而易见的是高度自治的agent需要，harness就是给系统套上了安全带（比如状态记录/断点恢复/避免重复等）。而workflow驱动的agent整个过程是可控的，harness不是必选项。

Agent的能力半径由工具决定。

工具的设计需要面向模型设计，而非面向人类开发者设计。

传统的api是面向人类设计的，人类会读文档，理解上下文，调试参数，fix bug。

agent调用工具，则是依赖于工具的名称，描述，参数结构，返回值，上下文提示等，如果工具描述语义模糊，参数过多，错误信息隐晦，就会导致工具误用。

好的工具是：

1.名称清晰：模型一眼就知道它解决什么问题；

2.参数少而明确：避免让模型在大量可选参数中猜测；

3.返回结构稳定：方便模型继续推理；

4.错误反馈可行动：不只是抛出底层异常；

5.权限边界清楚：危险操作要显示提示；

6.工具粒度合适：不要太原子，也不要太笼统；

所以anthropic的建议是：工具不是暴露API，而是设计模型可理解，可选择，可恢复的行动接口。

对于harness来说，需要对模型调用的工具进行拦截和验证。

如何让agent可靠完成一个任务呢？

光有模型和工具还不够，openai认为，如何通过约束，验证，反馈，是构建任务可靠完成的关键。

以往，我们评估模型，是看它的输出是否正确。

但在agent中，模型的一次输出通常不是最终答案，而是中间动作，比如读一个文件，修改一段代码，执行一次接口，总结当前进度等。

这些中间动作本身没有对错，需要将它们放在完整的执行链路里面判断。

harness就是为模型构建这样一个可检查的环境，为模型提供任务所需的上下文，为模型定义可选工具，限制工具执行的权限，记录每一步动作，对运行测试和验证，把结果反馈给模型，在执行失败时重试/回滚/恢复。

也就是说，harness是把大模型的不确定性装进一个可检查/可回滚/可复现/可观测的工程闭环中。

对agent来说，执行长任务光有上下文是不够的，还需要外部状态管理。

任务变长之后，系统必须记住什么/忘掉什么/压缩什么/恢复什么都很重要，因为长任务agent过程中会不断产生新状态，比如已经尝试过的方案，工具调用的结果，文件的改动历史，失败的命令和报错，模型的中间判断等。

如果这些都塞进上下文窗口，系统很快变得又贵又笨。

所以短任务需要推理质量，而长任务需要外部状态管理。

harness为了支持长任务，至少需要考虑几个点：

1.session log：记住任务全过程；

2.checkpoint：把关键阶段保存可恢复状态；

3.state summary：把冗长过程压缩成可用摘要；

4.workspace：维护真实工作产物，比如代码/文件/配置；

5.recovery policy：失败/中断/超时后如何继续；

6.validation loop：每个阶段如何判断是否真的完成；

对于长任务agent，需要关注的是系统不要偏离原始目标，所以harness需要用session log/阶段摘要/checkpoint，把当前进展和原始约束持续拉到同一条线上。

在完成以上harness需求之后，harness工程已经开始变得越来越复杂了，这就回到了软件工程的问题上了，即模型推理/工具执行/运行循环/任务日志应该如何解耦。

anthropic建议可以把agent拆成几块：

1.brain：模型本身，负责理解/推理/规划/动作选取；

2.hands：执行动作的工具层，如文件系统/终端/浏览器/api/sandbox；

3.session log：记录任务全过程，支持审计/恢复/上下文重建；

4.harness loop：调度brain和hands，把执行结果反馈给模型；

5.sandbox：隔离执行环境，限制风险；

这样brain可以随时换模型，让不同任务跑在不同模型和环境里，工具也可以随时换。

log可以单独保存和审计，它不仅仅是聊天的记录更应该是记录目标/动作/工具结果/关键决策/失败原因，以让系统在中断后重建上下文，追溯agent为什么这样做。

loop中可以加入策略，比如重试/压缩/验证等。

sandbox可以独立控制权限与风险。

所以harness的价值，不再将agent看成一个黑盒，而是将agent拆成一个由多个可替换/可观测/可恢复的组件，包括稳定的项目工作区，文件读取和编辑能力，命令执行环境，预览或测试反馈，错误日志管理，变更记录，用户确认与中断机制，失败恢复能力。

比如做一个简单的todo app，agent不只是生成一段组件代码，而是要先理解需求，再查看项目结构，修改页面和状态逻辑，启动预览，发现报错之后继续修复，最终对最终任务结果负责。

当agent能执行真实操作后，需要回答的问题是到底哪些动作可以自动执行，哪些动作需要问用户。

Claude Code auto mode提供了一种方式，用分类和策略系统来判断操作风险，这部分能力可以变成harness的一层安全能力。

对于低风险的操作，自动批准；中风险操作，则根据上下文或策略判断；高风险操作，进行拦截或需要用户确认；对于不确定的操作，保守处理。

危险操作通常包括删除文件/安装依赖/访问网络/修改环境变量/改动配置/提交代码/调用外部服务等，它们需要被识别/分级/记录。

也就是说，对于高度自治agent来说，安全问题不止来自于模型判断，更合理的方式是将审批机制系统化/策略化/可观测化/可审计化，用sandbox限制影响范围，用日志留下证据，用撤销或恢复机制兜底。

langchain发表过一篇文章，harness可以显著提升agent的基准表现。

这很好理解，因为完成一个任务，并不由模型单独决定，还取决于上下文如何组织，任务如何拆分，工具是否好用，执行循环是否稳定，错误是否被恢复，中间状态是否被正确保存，失败信号能否反馈给模型。

这也就回答了同一个模型，换了一套harness表现完全不同。

因为工具描述清楚，模型就少走弯路；状态更稳定，长任务就不易丢失目标；错误反馈可行动，失败就容易被修复。

agent执行的过程不是一次输出，而是一段轨迹，所以执行过程是否可靠和结果是否正确同样重要。

比如它是如何理解任务？它调用了哪些工具？它有没有重复走弯路？它遇到错误后是否恢复？它是否保持了用户目标？它是否越权执行了危险操作？它最终完成任务的成本是多少？

所以agent评测至少应该覆盖三层，最终结果是否完成，中间步骤是否合理，状态/工具/权限/恢复机制是否可靠。

以上这些东西加起来，组成了需要的harness架构，大概是这样：

Harness需要回答的是能更好地组织长任务状态？能让工具更容易被模型稳定调用？能更安全地放大自治能力？能在失败后恢复，而不是从头再来？能把 Agent 的运行过程评测清楚？