模型只是大脑，Harness 才决定 Agent 能不能完成任务

TL;DR： 7 月 22 日，我在公司内部做了一场 Harness Engineering 分享。研究 Codex 源码以后，我更确定一件事：模型给 Agent 提供推理能力，任务能否稳定完成，还要看上下文、工具、权限、运行环境、验证和失败恢复怎样配合。后端开发者过去积累的稳定性、监控、存储和权限经验，正好可以迁移到这套模型外围工程里。

---

7 月 22 日，我在公司内部分享了最近一周对 Codex 源码的学习。

我从任务进入系统开始，顺着完整生命周期往下讲：目标怎样进入上下文，模型怎样选择工具，命令在哪里执行，权限怎样限制，失败以后怎样恢复，最后又怎样确认结果。

分享里还放了两个实战课题。只有进入具体任务，我才看清一个 Coding Agent 为什么有时很强，有时又会在很小的地方反复犯错。

我当时用了一个很直接的比喻：模型只是大脑。

Harness 是围绕这个大脑搭起来的工程系统。它把上下文、工具、记忆、执行环境、安全权限、监控和反馈连接在一起，让模型有机会把能力变成一个可以验收的结果。

§聪明不等于任务能完成

平时比较模型，大家容易盯着榜单、参数和单次回答。

真实任务很少只需要回答一次。

让 Agent 修改一个代码库，它要先理解目标和约束，找到相关文件，决定改哪里，调用工具执行，再运行测试。如果测试失败，它还要读错误、修正方案并重新验证。有些操作只能读取，有些操作会改文件、发消息或影响外部系统，权限边界也要在执行前讲清楚。

模型每一步都可能做出看起来合理的选择。多走几十步以后，一个小偏差就会累积。

我使用 Codex 做长任务时，经常看到类似情况：目标写得太泛，Agent 会往错误方向做得很完整；上下文塞得太多，它会抓错重点；没有完成标准，它做完代码就停下，不会主动跑测试；工具返回信息不清楚，它可能重复尝试同一个动作。

换一个更强的模型可能会改善结果，外围流程仍然要把这些问题接住。

§Harness 具体接住什么

源码里的模块很多，我现在最关心五件事。

一是把任务说清楚。

目标、背景、约束和完成标准需要进入同一个任务描述。这里少一句，模型可能就会补一个自己认为合理的答案。OpenAI 的 Codex 使用文档也反复强调，清楚写出目标、上下文、限制和完成条件，结果会更稳定。

二是管理上下文。

Agent 需要看到相关文件、历史决定和工具结果，又不能把所有资料一次塞满。上下文太少会误判，太多也会污染判断。压缩、摘要和按需读取，决定了它能不能在长任务里一直记住主线。

三是把工具做成可理解的动作。

模型需要知道工具能做什么、输入是什么、成功和失败会返回什么。一个命令只给模糊的报错，Agent 很难继续。返回值清楚，它才有机会自己排查。

四是控制权限和运行环境。

读取文件和删除文件的风险不同，生成草稿和直接发布的风险也不同。沙箱限制 Agent 能触碰的范围，审批把高风险动作交还给人。权限设计太松容易出事，太紧又会让任务每一步都卡住。

五是验证结果并允许恢复。

代码改完要跑测试，页面改完要打开检查，数据迁移要核对前后数量。任务中断后，系统还要知道已经做到了哪里。没有验证和恢复，Agent 只能给出一段很像完成报告的文字。

这些环节加在一起，才构成我理解的 Harness Engineering。

§后端经验为什么能迁移过来

7 月 23 日，我又记了一段感受：以前做复杂业务系统，服务对象主要是人；现在做 Harness，服务对象增加了模型。

两类系统都要处理不稳定。

电商后端要面对超时、重复请求、权限、状态变化和失败重试。Agent 系统也会遇到工具超时、上下文丢失、重复执行、权限拒绝和任务中断。日志、监控、存储、状态机、幂等和错误恢复这些经验仍然有用。

模型也带来了一批新问题。

它会根据概率生成下一步，输出存在不确定性。上下文窗口有限，长任务需要压缩和记忆。工具说明写得含糊，调用结果会明显变差。系统提示词、工具协议、模型评测和任务轨迹，都是后端开发者需要补上的部分。

这条迁移路径让我很兴奋。

做了多年后端的人，不需要把过去的经验清零。先把熟悉的稳定性问题映射过来，再学习模型特有的上下文和评测问题，会比只追新的 Agent 名词更扎实。

§我现在怎么学习 Harness

我没有先做一套大而全的理论。

这次准备分享时，我选择沿着 Codex 的一次真实任务往下读。哪里接收用户目标，哪里加载上下文，哪里调用工具，哪里请求权限，哪里记录状态，哪里把错误送回模型。遇到抽象模块，就拿实战课题去找它为什么存在。

分享结束以后，下一步是继续做定制化评测。面对一个明确任务，记录模型在哪里偏离、Harness 做了什么、还有哪个环节无法恢复。只有这些结果留下来，源码阅读才会变成可复用的工程能力。

如果你也想进入这个方向，可以从自己每天会做的一项任务开始。把目标和完成标准写清楚，让 Codex 跑完整流程，保留工具记录和失败点，再回头研究对应模块。

不用急着给自己换一个新职位名称。

先让一个真实任务少犯错、能恢复、可验证。Harness 的价值会在这个过程中变得很具体。