别再给 AI 编程 Agent 堆「软件工厂」：好 Harness 的第一步是做减法

说明：本文主要依据 OpenAI 于 2026 年 2 月发布的 Harness engineering: leveraging Codex in an agent-first world 撰写，并结合近期围绕 Claude Code、Codex、并行 Agent 的公开社区讨论。OpenAI 文中关于代码规模、开发周期和团队吞吐量的数据，属于其内部项目披露，适合用来理解方法和取舍，不等同于其他团队可以直接复现的效果。

最近几个月，AI 编程圈里常能看见一种配置单：Claude Code 外面包一层调度器，调度器下面挂 Planner、Reviewer、Tester、Memory，再接几组 MCP 和并行 worktree。

跑起来以后，终端确实很热闹。好几个任务同时改不同分支，日志不断滚动，最后还能汇总成一份像模像样的报告。可真正开始排错时，麻烦也随之出现：某个任务为什么停住了？是谁让它改了不该改的文件？一条结论到底来自测试、浏览器验证，还是另一个 Agent 的猜测？

角色加到第四个、第五个之后，团队很容易失去一件东西：对失败原因的判断。

我不反对 Harness Engineering（支架工程）。OpenAI 那篇讲 Codex 的文章反而说明，Agent 能稳定工作，离不开工具、规则和反馈回路。只是这些东西不是按角色数量取胜。每一层脚手架都该回答一个很朴素的问题：它拦住过什么错误？

如果答不上来，它可能只是让系统显得更像「软件工厂」。

OpenAI 的实验，容易被读成「多 Agent 万能论」

OpenAI 的文章给出了很容易被截成标题的材料：少量工程师驱动的内部产品，在约五个月里积累了百万行量级的代码；代码、测试、CI、文档、可观测性和内部工具都由 Codex 生成。人类把时间放在定义目标、搭建环境和处理例外上。

只摘到这里，很容易得出一个轻快的结论：以后工程师不写代码，只管调度 Agent。

原文的重点其实落在更琐碎的地方。早期进度慢，不是因为 Codex 写不出代码，而是因为它面对的环境信息不够用。它不知道哪些仓库规则仍有效，不具备确认应用行为的手段，也无法从日志和指标里得到运行反馈。

所以团队补上的，是每个 Git worktree 可独立启动的应用、可被 Agent 驱动的浏览器、隔离的日志和指标，以及能被检查的文档和架构规则。页面能不能点、服务是否启动、依赖方向有没有被改坏、文档是否过期，这些问题都能落到具体信号上。

OpenAI 原文：Codex 通过 Chrome DevTools MCP 驱动应用并循环验证修复

这里没有一份「标准软件工厂角色表」。先有问题，再有工具和规则。把顺序颠倒，得到的往往是一张漂亮的架构图，而不是可靠的工程流程。

别先列工具，先翻返工记录

不少 AI 编程工作流是从工具清单开始搭的。

看到别人用了 multi-agent，就补一个；看到 MCP 能接外部服务，就多接几个；看到某个项目做了长期记忆，也想在自己的仓库里放一层。组件越来越齐，任务却不一定更好交付。

不妨先翻一翻最近十次让人返工的任务。

有些团队的问题是需求没写清。Agent 没有偷懒，它只是把「优化登录流程」理解成了重构鉴权模块。这时应先让任务在执行前给出可确认的验收条件，而不是再找一个 Agent 来复述需求。

有些团队卡在验证。单元测试绿了，PR 也绿了，页面却打不开。那就让应用启动起来，跑一遍关键路径。浏览器验证不花哨，但它提供了单元测试之外的事实。

AI 编程 Agent 的任务规格、权限边界、真实验证和人工升级闭环

还有些问题来自权限和操作边界。Agent 为了修环境连续换命令、下载工具，甚至读取不该碰的凭据。多加一位会朗读安全原则的 Reviewer 没有帮助。收紧权限、保留高风险动作记录，并在不可逆步骤前让人确认，才会改变结果。

一个新 Planner、Memory、MCP 或 Reviewer，如果说不清它要防住哪一种经常发生的错误，就先不要急着上线。它会带来更多上下文、更多运行成本，也让排障路径更长。

规则得落到执行处

我之前写过一篇文章，讨论 Agent 为什么不能只靠 Prompt，而需要工具、权限、验证和反馈组成的 Harness。那篇文章回答的是：模型能力为什么不等于 Agent 的可靠性。

这里再往前走一步。Harness 不是搭起来以后就只会增加层数。

Prompt Engineering（提示词工程）处理的是这次任务怎么说明白。Harness Engineering 处理的是同类任务怎样稳定完成。前者可以写得细，也可以拆成多段；后者要看它是否让失败更难发生、出现后更容易被发现，或者修复成本更低。

例如，把「请运行测试」写进 prompt，只是在提醒。让 CI 因测试失败而拒绝合并，才会在任务真实发生时起作用。

同样地，Reviewer Agent 在总结里写「注意权限」只是一个建议。高风险命令没有明确授权就无法执行，才是边界。

Memory Agent 每次产出长复盘也不必然有用。只有当其中的经验能在下一次被找到、被检查，甚至被转成规则或测试时，它才不只是存档。

OpenAI 对 AGENTS.md 的处理也能说明这一点。他们试过把所有信息写进一个大文件，结果上下文被挤占、规则互相淹没、文档很快过期，也无法机械检查。后来保留一个短入口，指向结构化 docs/。Agent 先知道去哪里找，再按需要读取。

少放无关信息，少保留过期规则，反而会让关键约束更容易被看见。

留下一个组件前，先拿出证据

不是所有工作流组件都要删。只是每一层都应该能经得起一点工程审计。

它拦住过真实问题吗

最好有失败样本。

比如某个项目里，Agent 改完接口经常漏掉调用端，就可以补类型检查、契约测试或依赖图校验。之后如果它拦下了同类改动，留下它就有充分理由。

相反，一个「架构审查 Agent」连续一个月都在输出笼统建议，既没阻止错误，也没有触发后续动作。它更接近昂贵的日报。

可以直接回看它上一次的产出：发现了什么？没有它会怎样？

它带来新证据吗

三个 Agent 轮流读同一份 diff，不一定是三重验证。

使用相同上下文、规则和工具时，它们往往会共享盲点。独立信号应当来自不同的观察方式：静态检查、测试结果、浏览器实际操作、日志和指标，或者人工业务验收。

OpenAI 给 Codex 接 Chrome DevTools Protocol、日志、指标和 trace，不是为了把工具栏拉长，而是让 Agent 能接触此前看不见的运行事实。它不必只看 diff 猜测页面是否正常，可以启动应用、点击路径、观察网络和运行时事件。

OpenAI 原文：为每个本地 worktree 提供日志、指标与 trace 的可观测性栈

新增一层组件前，先分辨它给出的究竟是新证据，还是旧结论的换一种说法。

它真的省下时间吗

多 Agent 的开销不只有 token。维护 prompt、处理互相矛盾的输出、定位任务卡在哪个环节，以及让新成员理解整套系统，都会花时间。

如果原本十分钟的人类检查，变成三十分钟的 Agent 协调，那么「自动化」本身不值得奖励。

当然，发布验证、数据迁移审批和安全检查本来就不该只追求快。要看那段额外时间换回了什么：明确的风险降低，还是一个更复杂的流程图。

最容易变成摆设的四种结构

下面四类组件，不一定要删，但很值得优先审查。

对 Planner、Memory、MCP 与 Reviewer 的组件审计

重复的 Planner。

一个任务已经有明确需求、验收条件和依赖关系，却又让两个 Agent 分别生成计划、再让第三个比较计划。除非计划分歧本身是高风险信号，否则这往往只是把决策往后拖。对小改动来说，一个可确认的计划和一份清晰的任务边界已经足够。

没有消费者的 Memory。

很多系统很擅长「存」。会话摘要、偏好、决策、工具结果全都写入数据库或 Markdown，却没有人知道下次任务会读取什么、如何判断是否过期、冲突时听谁的。这样的记忆会逐渐变成噪声源。记忆应该有明确消费者：某条规则会被启动脚本读取，某个决策会被测试校验，某类故障会在同类任务开始前被提示。没有消费者的信息，先别急着永久保存。

边界模糊的 MCP。

MCP 很适合把外部能力交给 Agent，但每增加一个工具，也增加一组权限、失败方式和上下文负担。一个能读写所有文档、发消息、创建工单、改数据库的「万能工具」，在演示里很爽，在排错和治理上却很难处理。相比之下，参数清楚、权限有限、输出可验证的小工具，更容易被 Agent 正确使用，也更容易在出问题时收紧。

只会赞同的 Reviewer。

最危险的 Reviewer 不是严格，而是礼貌。它总能找出一点格式建议，却很少挑战需求、边界、回滚或真实行为。这样的 Agent 会制造「已经审过」的完成感。好的审查不是多写几条建议，而是能在关键时候提出可证伪的问题：这个改动用什么证据证明有效？失败时怎样恢复？它是否改变了不该改变的接口？

先从五件小事开始

个人项目和小团队不需要先复制大公司的平台能力。把下面五件事做清，通常比继续扩充 Agent 队伍更有用。

任务规格要能确认。 不用写成冗长文档，但至少说清目标、明确排除项、验收方式和风险点。Agent 可以起草，人应在执行前确认边界。

权限默认收窄。 Agent 只拿到完成当前任务所需的仓库、目录和工具。发送、删除、生产变更或敏感数据访问，应该走升级流程，而不是在任务开始前一次性放开。

验收动作要接近真实使用。 它可以是一条测试命令、浏览器关键路径、接口契约检查，或者一段可重复的手工验证。重要的不是数量，而是它是否能证明用户在乎的功能真的可用。

失败记录要能被下次任务使用。 不必保存每一轮对话。把重复出现的问题写成简短约束：为什么失败、怎样识别、该由谁或什么机制拦住。否则下次 Agent 仍会从同一个坑里爬出来。

要留一个人工升级点。 大多数小问题可以由 Agent 自行处理；但影响范围超出任务描述、需要新高风险权限、连续验证失败，或关键事实无法确认时，它应该停下并交还判断。

这些安排听起来很普通。它们的价值也正在于普通：出了问题时，能找到边界、证据和下一步，不必翻遍一串 Agent 的总结。

规则少一点，Agent 反而更好做事

规则、测试和权限看起来会限制 Agent。实际交付里，最让 Agent 原地打转的往往不是约束，而是不确定性：哪份文档可信，什么改动能接受，怎样才算完成。

架构边界清楚、入口文档短而稳定、测试能跑、应用状态可观察，表面上是在加限制，实际上减少了无效探索。Agent 不必每次猜项目习惯，也不用花大量 token 解释为什么自己大概做对了。

所以「做减法」减掉的不是验证、纪律或必要工具。该减的是模糊的职责、重复的结论，以及没有后续动作的自动化装饰。

Agent 负责执行、探索和迭代；Harness 负责提供工具、边界、证据和刹车。Agent 越能行动，Harness 越需要让人看得懂。

下次准备加第六个 Agent、第十二个 Skill 或另一层记忆系统时，先把问题写在纸上：它要消灭的是哪一种已经出现过的失败？没有答案，先不加。

参考来源

以上来源主要用于核验厂商公开方法、工程实践和社区讨论。厂商披露的内部项目数据与视频中的个人工作流，不等同于独立基准测试，也不能直接推导到所有团队。