Harness 架构正在成为 AI 编程时代真正的护城河

最近几个月，OpenAI 和 Anthropic 在一个词上出现了非常明显的收敛：harness。

它不是模型，不是 prompt，也不是某个 CLI 的包装壳。
它更像是一个把模型、工具、权限、上下文、验证、协议和状态管理绑在一起的“外循环操作系统”。

如果说 2024 年大家还在问“哪个模型更会写代码”，那么到了 2026 年，真正拉开差距的问题已经变成：

你给模型配了一套怎样的 harness？

什么叫 harness

用最直白的话说，harness 就是包在模型外面、负责让模型“真正干活”的那一层系统。

它通常至少包含这些部分：

• 用户输入如何进入模型
• 模型如何发起工具调用
• 工具结果如何回流到下一轮推理
• 会话状态如何保存、压缩、恢复和切换
• 权限、安全边界和审批如何控制
• 评估、测试、回归验证如何自动化
• 客户端、IDE、云端运行时如何接到同一套 agent loop

所以 harness 不是小配件。
它就是 agent 真正能不能落地的软件工程骨架。

OpenAI 的答案：把 Codex 做成一套可运行的工程系统

OpenAI 在 2026 年 1 月的文章《Unrolling the Codex agent loop》里把事情说得非常清楚：所谓 Codex harness，本质上就是那条负责协调“用户、模型、工具、结果回流”的核心 agent loop。

它的基本循环非常朴素：

用户提出任务
-> 模型决定直接回答，或者请求调用工具
-> harness 执行工具
-> 把工具输出追加回上下文
-> 再次调用模型
-> 一直循环到模型停止调用工具并返回最终消息

看起来简单，但真正的工程价值不在“循环”本身，而在 OpenAI 后面做的几层强化。

1. 把应用本身变得对 agent 可读

OpenAI 在《Harness engineering: leveraging Codex in an agent-first world》里强调，他们的瓶颈已经不是写代码速度，而是人的 QA 时间。所以他们做的不是继续堆 prompt，而是让应用本身对 agent 更“可见”。

他们做了几件非常关键的事：

• 每个 git worktree 都可以独立启动应用
• 把 Chrome DevTools Protocol 接进 agent runtime
• 给 agent 提供 DOM snapshot、截图、导航能力
• 把日志、指标、trace 通过本地可观测性栈暴露给 agent

这背后的思想非常重要：

不要只让 agent 看源码，还要让它看见运行中的系统。

当 UI、日志、指标都变成 agent 可读对象以后，“修一个 bug”就不再只是改文件，而是：

复现问题 -> 观察界面或指标 -> 修改代码 -> 重启应用 -> 回归验证

也就是说，harness 把“调试”从一句自然语言愿望，变成了可执行闭环。

2. 把仓库知识做成 system of record

OpenAI 还提到一个很有代表性的经验：不要搞一个巨无霸 AGENTS.md，那样很快就会失控。

他们后来把仓库知识拆进结构化 docs/，而把简短的 AGENTS.md 只当作目录和入口。这个思路我非常认同，因为它解决的是 agent 系统里最常见的一个问题：

上下文不是越多越好，而是越有层次越好。

一个好的 harness，不应该把一千页说明书一次性塞进上下文；它应该给模型一个“地图”，让模型在需要的时候自己去读更细的 source of truth。

3. 用“机械约束”而不是“口头约束”保住架构

OpenAI 还强调了另一个极容易被忽略的点：对于 agent 来说，架构规则不能只靠文档约定，必须尽量机械化。

他们的做法包括：

• 固定业务域分层
• 限制依赖方向
• 通过自定义 lint 和结构测试强制执行边界

这其实是在把“代码风格”升级成“系统不变量”。
因为 agent 吞吐很高，如果边界全靠人盯，架构会比人工时代崩得更快。

所以 OpenAI 给出的结论几乎可以概括成一句话：

高吞吐 agent 时代，架构不是锦上添花，而是防止系统熵增的最低配置。

4. 用协议把 harness 从单一 CLI 升级成平台能力

OpenAI 最近另一篇文章《Unlocking the Codex harness: how we built the app server》又往前走了一步。

它讨论的重点已经不是“agent loop 怎么工作”，而是：

如何把同一套 harness 同时提供给 Web、CLI、桌面应用和 IDE。

他们的答案是一个长期运行的 Codex App Server：

• 对外暴露双向 JSON-RPC 风格协议
• 对内托管 thread/session
• 把 agent 的逐步事件流稳定地翻译给不同客户端

这件事的意义很大。

很多团队做 agent，到最后还是“一个 CLI + 一坨脚本”。
而 OpenAI 的方向明显是把 harness 协议化、服务化，让 UI 只负责消费事件流，而不是自己重写一套 agent 内核。

这意味着，未来真正强的 agent 产品，不一定是“模型最好”的那个，而很可能是谁最先把 harness 抽象成一层稳定平台。

Anthropic 的答案：给 Claude 一台电脑，再给它一个会持续进化的外循环

Anthropic 这边的表述路线不完全一样，但落点几乎一致。

在《Building agents with the Claude Agent SDK》里，他们把核心原则总结得非常直接：

给 Claude 一台电脑。

这不是营销话术，而是架构判断。

Anthropic 认为，Claude 之所以在 Claude Code 里能工作，不是因为它只会补全代码，而是因为它拿到了程序员平时就在用的那套能力：

• 查文件
• 搜文件
• 写文件
• 跑命令
• 调试
• 迭代修复

一旦 agent 拿到了这些能力，它能做的就不只是 coding，还包括研究、分析、自动化、报告、工作流编排等一大类“数字工作”。

这和 OpenAI 的思路高度一致：
关键不是把模型包进产品，而是把模型接到真实工作环境。

Anthropic 最近更进一步：harness 设计本身决定长任务上限

更值得看的是 Anthropic 2026 年 3 月的文章《Harness design for long-running application development》。

这篇文章很有价值，因为它不是在讲“Claude 很强”，而是在讲：

为什么长时任务里，harness 往往比模型本体更决定结果。

文章里提到了几个非常关键的判断。

1. 长任务的第一问题不是不会做，而是会慢慢跑偏

Anthropic 观察到，长时间 autonomous coding 的两个常见失败模式是：

• 上下文窗口越来越满，模型逐渐失去连贯性
• 模型会过早“想收工”，也就是他们说的 context anxiety

为了解决这个问题，他们早期 harness 的关键设计不是更长 prompt，而是：

• 把大任务拆成可控子任务
• 用结构化 artifacts 在 session 之间做交接
• 必要时进行 context reset，而不是盲目累积上下文

这特别值得团队警惕。
很多人以为长任务失败是模型“不够聪明”，但更常见的情况其实是：

外循环没有设计好，导致模型在错误的状态管理里被慢慢耗死。

2. 自评往往不可靠，所以要把“执行”和“评判”拆开

Anthropic 明说了一个大家都能体感到、但很少系统承认的问题：

agent 对自己做出来的结果通常过于宽容。

特别是在设计、体验、质量这类不完全二值可验证的任务里，单个 agent 做完再自评，经常会高估自己。

所以他们把 harness 演化成三代理结构：

• planner：把模糊需求扩成产品规格
• generator：真正实现
• evaluator：像 code review / QA 一样做独立评估

这就是文章里最重要的启发之一：

真实世界里的 harness，不应该只有“干活的人”，还应该有“挑毛病的人”。

换句话说，好的 harness 不是把一个超级 agent 拉到极限，而是把多个角色之间的摩擦设计出来。

3. 会话管理已经从“保存聊天记录”升级成“管理认知负担”

Anthropic 还提到了一个很细但很关键的点：

• 早期某些模型上，compaction 还不够，必须配合 context reset
• 到后来的 Opus 4.5/4.6，一部分问题缓解，于是 harness 可以减少 reset，更多依赖自动 compaction

这意味着 session management 已经不是单纯“续聊”问题，而是在管理模型的认知负担。

从工程视角看，这很像操作系统里的内存管理：

• 什么时候压缩
• 什么时候切新进程
• 什么信息必须保留
• 什么状态可以丢弃

所以说 harness 像操作系统，一点也不夸张。

OpenAI 和 Anthropic 正在收敛到什么共识

如果把两边最近的文章放在一起看，我觉得已经能看出一条非常清晰的共识路线。

共识一：模型只是内核，harness 才是整机

OpenAI 讲 agent loop、App Server、仓库知识和架构约束。
Anthropic 讲给 Claude 一台电脑、会话工件、planner-generator-evaluator。

两边说法不同，但都在表达同一件事：

单个模型能力决定下限，harness 设计决定上限。

共识二：上下文工程比 prompt 工程更重要

不是谁更会写一句咒语式 prompt，而是谁能把这些东西组织好：

• 哪些知识常驻
• 哪些知识按需读取
• 哪些状态跨 session 继承
• 哪些结果需要结构化 handoff
• 哪些反馈必须回流进下一轮执行

这其实就是 context engineering，只不过现在它越来越体现为 harness design。

共识三：验证能力必须内建，而不是事后补

真正可用的 coding agent，不能只会“生成”，还必须会：

• 启动应用
• 跑测试
• 看 UI
• 读日志
• 查指标
• 做回归
• 接 review

如果这些能力没有内建到 harness 里，模型写出来的代码再强，也很难持续稳定地产生可交付结果。

共识四：多角色结构会越来越常见

过去大家喜欢追求“一个最强 agent”。
但现在越来越清楚的是，更稳的路线通常是角色分工：

• 规划
• 执行
• 验证
• 审批
• 恢复

这和真实工程团队的组织方式本来就一致。
harness 的工作，就是把这种组织方式系统化。

如果你要自己搭一套 harness，最值得先做什么

如果你准备在团队里真正落地 agent，我建议优先做这几件事，而不是先追最新模型。

1. 先把知识地图整理好

准备一份短 AGENTS.md 或 CLAUDE.md 当目录，再把真正的 source of truth 分散到结构化文档里。
让 agent 能定位，而不是把所有规则一次性灌进去。

2. 给 agent 一个可重复启动的执行环境

至少做到：

• 独立 worktree 或隔离工作目录
• 可一键启动应用
• 可稳定运行测试
• 可读取关键日志

没有这层环境，再聪明的模型都只是在“猜”。

3. 把验证链路接进来

能接测试接测试，能接截图接截图，能接浏览器快照接浏览器快照。
一定要让 agent 能自己验证，而不是每轮都靠人肉验收。

4. 让架构边界自动执行

靠口头说“别这样写”没用。
最好把边界做成 lint、检查脚本、结构测试、类型约束。

5. 早点设计 handoff artifact

无论你叫 session summary、task spec、run report 还是 work log，都要尽早让 agent 学会把状态结构化交接出去。
这会直接决定长任务能不能稳定跑下去。

结语

我越来越觉得，2026 年的 AI 编程竞争，真正比拼的已经不是“模型能不能写代码”，而是：

你有没有把模型放进一套足够好的 harness 里。

模型负责生成智能，
harness 负责把智能变成稳定、可审计、可恢复、可扩展的生产力。

OpenAI 和 Anthropic 最近的文章，几乎都在指向同一个结论：

未来最强的 coding agent，不会只是一个更大的模型，而会是一套更成熟的外循环工程系统。

而这套系统的名字，就是 harness。

参考资料

• OpenAI: Harness engineering: leveraging Codex in an agent-first world
• OpenAI: Unrolling the Codex agent loop
• OpenAI: Unlocking the Codex harness: how we built the app server
• Anthropic: Harness design for long-running application development
• Anthropic / Claude: Building agents with the Claude Agent SDK