微信公众号文章《Harness Engineering：让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点：Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的，但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”，还是太窄。

更准确的定义是：Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环，让 Agent 能跨越单个上下文窗口，持续推进真实任务，并在失败时留下可恢复的证据。

这不是 Prompt Engineering 的升级版，也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说，Context 解决一次请求里放什么，Harness 解决的是任务生命周期怎么被系统托住。

一、为什么 2026 年突然轮到 Harness

OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验：团队从空 Git 仓库开始，用 Codex 构建并发布一个内部 beta 软件产品，约五个月后仓库达到百万行量级，约 1500 个 PR 被合并，小团队平均吞吐达到每位工程师每天 3.5 个 PR。OpenAI 对这个实验的解释不是“Codex 会写很多代码”，而是工程师的工作重心变了：人负责设计环境、表达意图和构建反馈循环，Agent 负责执行。

Anthropic 的 long-running agents 文章从另一个角度讲同一件事。长程任务的核心问题不是模型不会写代码，而是模型必须工作在离散 session 里。每个新 session 如果没有外部状态，就像一个刚接班的工程师完全不知道上一班发生了什么。上下文压缩可以缓解这个问题，但不能替代可恢复的工程状态。

两篇文章合在一起看，结论很清楚：模型能力继续上涨以后，稀缺资源不再只是“会不会生成代码”，而是人类注意力、系统可读性和验证闭环。Agent 能跑得越久，越需要 Harness。

二、Harness 不是记忆，而是控制系统

很多文章把 Harness 讲成“记忆系统”，比如 progress.txt、feature list、git commit、任务日志。这些都重要，但它们只是 Harness 的一层。

一个可用的 Agent Harness 至少包含六类部件：

部件 作用 典型形态
入口指令 让 Agent 知道当前仓库的工作方式 AGENTS.md、CLAUDE.md、项目规则
状态持久化 让新 session 接上旧 session progress 文件、任务列表、git 历史、决策日志
环境启动 让 Agent 快速恢复可运行现场 init.sh、dev server、worktree、沙箱
工具边界 让 Agent 能做事但不能乱做事 文件权限、MCP、浏览器自动化、shell 白名单
验证闭环 让 Agent 知道“真的完成了” 单测、E2E、截图、录屏、eval、CI
熵减机制 防止长期运行后系统漂移 lint、架构规则、后台重构任务、质量评分

其中最容易被低估的是最后两项。没有验证闭环，Agent 会把“代码写完了”误判成“任务完成了”。没有熵减机制，Agent 会复制仓库里已有的坏模式，长期把代码库推向越来越难读、越来越难维护的方向。

OpenAI 的实践尤其强调“让应用对 Agent 可读”。他们为每个 worktree 启动独立应用实例，接入 Chrome DevTools Protocol，让 Codex 能看 DOM、截图、导航页面、复现 bug、验证 UI 行为。Anthropic 也在网页应用实验里要求 Claude 使用 Puppeteer MCP 按真人用户路径做端到端验证。这里的关键不是“用了浏览器工具”，而是验证对象从“代码看起来对”变成“系统行为真的对”。

三、长程 Agent 的四个失败模式

Anthropic 总结的失败模式很有解释力，基本覆盖了今天 coding agent 的大多数翻车现场。

第一，Agent 试图一次做太多。它拿到一个大任务后会倾向于 one-shot，写到上下文快耗尽时留下半成品。下一个 session 不知道哪些完成、哪些失败，只能猜。

第二，Agent 过早宣布胜利。项目里已经有一些功能后，新 session 很容易环顾仓库，看到“差不多能跑”，就把整个任务判定为完成。

第三，Agent 留下带 bug 的现场。没有 git 提交、进度日志和基础冒烟测试，下一次接手时先要修前一次留下的坏状态。

第四，Agent 不知道怎么启动应用。它把大量 token 花在“怎么跑起来”这种低价值探索上，而不是推进功能。

Anthropic 的解法很朴素：第一轮 initializer agent 负责建立 init.sh、进度文件、功能清单和初始提交；后续 coding agent 每次只做一个功能，开始时读 git log 和进度文件，启动应用并跑基础端到端测试，结束时提交代码并更新进度。这个方案不神秘，但它把“接力”从聊天窗口里的自然语言承诺，变成了文件、脚本、测试和提交历史。

四、OpenAI 路线：仓库本身成为系统记录

OpenAI 文章里最值得借鉴的一点，是把 repository knowledge 设成 system of record。Google Docs、Slack、口头约定、人脑里的背景知识，对 Agent 来说都可能是不可见的。不可见的信息等同于不存在。

所以 OpenAI 把知识沉到仓库里：设计文档、执行计划、产品规格、技术参考、架构约束、验证方式，都尽量变成 Agent 可以读、可以改、可以被 CI 校验的文本或代码。AGENTS.md 更像目录，不是百科全书。它告诉 Agent 去哪里找知识，而不是把所有知识都塞进上下文。

这和 Codex 官方 AGENTS.md 文档的设计是一致的。Codex 会在工作前读取 AGENTS.md，并按全局、项目、子目录逐层合并指令。越靠近当前目录的规则越晚出现，也就越能覆盖上层规则。这种分层规则本身就是一种轻量 Harness：它把团队规范从“人记得”变成“Agent 每次启动都会看到”。

但规则文件只是入口。真正的 Harness 要继续把规则往确定性系统里推进。比如“不要跨域调用”最好不只写在文档里，还要用 linter、类型边界、测试夹具和 CI 拦住。OpenAI 在文章里提到，随着团队把架构品味编码进机械规则，人才逐渐从逐行 review 退到设计约束、验收标准和异常升级上。

五、吞吐量会改变工程管理的默认值

一旦 Agent 产出速度高过人类 review 速度，传统合并哲学会被迫变化。OpenAI 的实验仓库采用了更少的阻塞门、短生命周期 PR，对 flaky test 更倾向用后续运行修复，而不是让所有进度长期阻塞。

这套做法不能直接照搬。OpenAI 自己也提醒，这种策略在低吞吐环境里可能是不负责任的。它成立的前提是修正成本低、验证闭环强、回滚路径清楚、生产影响受控。如果没有这些前提，“快合并”只是把问题更快送进主干。

更稳妥的判断是：Agent 时代的合并策略会从“人工仔细审每一行”转向“系统自动拦高风险，人类审关键判断”。人类 attention 用在需求边界、架构方向、安全例外、用户影响和不可逆操作上；格式、样板、局部重构、测试补齐、低风险修复交给机器流水线。

六、2026 趋势：从单 Agent 到 Agent 团队

Anthropic 的《2026 Agentic Coding Trends Report》把趋势分成八类，其中与 Harness 最相关的是三条。

第一，软件开发生命周期正在从“人写代码”变成“人编排 Agent 写代码”。报告认为工程师的价值会更多转向系统架构、Agent 协调、质量评估和问题拆解。

第二，单 Agent 会演化为协调团队。复杂任务不再塞进一个上下文窗口，而是拆成多个专门 Agent 并行处理，再由 orchestrator 汇总。多 Agent 的难点不是“多开几个窗口”，而是任务边界、状态同步、冲突解决和验证责任。

第三，长程 Agent 的任务时长会从分钟扩展到天或周。报告引用 Rakuten 的案例：工程师让 Claude Code 在 vLLM 这个 1250 万行级别开源库中实现特定 activation vector extraction 方法，单次 autonomous work 用时 7 小时，数值准确率达到 99.9%。这类案例说明长程能力已经开始越过 demo 边界，但仍依赖明确目标、可验证输出和良好的工程约束。

报告也给了一个必要的降温判断：开发者在大约 60% 的工作里使用 AI，但真正能完全委托的任务仍只占一小部分。有效的 AI 协作仍需要设置、监督、验证和人类判断。换句话说，Harness 不是让人退出系统，而是让人从低价值监工位置上移。

七、落地清单：小团队先补这六件事

对普通研发团队来说，不需要一上来复刻 OpenAI 的百万行实验。更现实的起点是把当前仓库改造成“Agent 可接手”的工作现场。

第一，写一份短的项目入口规则。 入口文件只放地图：项目结构、启动命令、测试命令、危险操作、常见坑、文档位置。不要把它写成百科全书。

第二，建立任务状态文件。 长任务必须有外部状态。可以是 plans/xxx.md、progress.md、issue checklist，也可以是结构化 JSON。关键是让新 session 不靠聊天记录猜进度。

第三，固定启动路径。 一个 init.sh 或等价脚本要能把开发环境拉起来。Agent 不该每次重新研究项目怎么启动。

第四，把完成条件写成可运行验证。 单测、集成测试、E2E、截图、接口契约、日志查询都可以。没有验证的任务清单，只是愿望清单。

第五，给工具设边界。 文件访问、shell 命令、外部网络、数据库写入、部署操作都要有权限层。越接近生产，越不能只靠“请小心”。

第六，定期做熵减。 每周或每个迭代留出自动化重构和规则升级时间。Agent 会复制模式，仓库里坏模式越多，后续输出越容易继续坏。

八、真正的护城河是可编码的工程品味

Aakash Gupta 那句“model is commodity, harness is moat”有夸张成分，但方向成立。模型会继续变强，也会继续趋同。真正难复制的是团队把自身工程品味编码进系统的能力：哪些边界不能破，哪些输出必须验证，哪些行为要升级给人，哪些债务要每天清掉。

Harness Engineering 的价值不在于给 Agent 加一层漂亮包装，而在于把过去依赖资深工程师直觉的那套东西外化出来。它把“怎么接手项目、怎么判断完成、怎么避免破坏、怎么把坏模式纠正回来”变成文件、脚本、测试、规则和自动化循环。

长程 Agent 的上限不只取决于模型能思考多久，更取决于系统能不能让每一次思考留下可继承的结果。没有 Harness，Agent 再强也只是一次性执行器；有了 Harness，它才开始接近一个能被管理、能被审计、能被长期改进的工程劳动力。

参考资料