当软件工程的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，让 AI 智能体能够可靠地工作时，会发生什么？
引言：一个改变认知的实验
2025 年 8 月，OpenAI 内部启动了一项大胆的实验：从一个空的 Git 仓库开始，不手写任何一行代码，完全由 Codex 智能体驱动，在 5 个月内交付了一款拥有约 100 万行代码的真实产品。3 名工程师推动 1500 个 PR，平均每天每人 3.5 个 PR，产品已在内测用户中稳定运行。
这个实验揭示了一个深刻的转变：工程师的角色正在从"写代码的人"变成"设计系统的人"。人类掌舵，智能体执行。而支撑这一切的，正是被称为 Harness Engineering 的一套新兴工程实践。
与此同时，Anthropic、LangChain、ThoughtWorks（Martin Fowler）以及 Mitchell Hashimoto（HashiCorp 创始人）等行业领袖，几乎在同一时期提出了相似的概念和框架。这不是巧合，而是 AI 辅助编程进入深水区后的必然共识。
什么是 Harness Engineering
如果把 AI 编码智能体比作一匹烈马，那么 Harness（马具/驾驭系统）就是让它安全、高效、可预测地跑起来的全套装备。用 LangChain 的简洁公式表达：
Agent = Model + Harness
Martin Fowler 团队的 Birgitta Böckeler 进一步将其定义为：围绕编码智能体构建的一整套工具和实践，目的是增加我们对智能体产出的信任，减少审查负担，提升系统质量。
Mitchell Hashimoto 在他的 AI 采用旅程中将其描述为："每当我发现智能体犯了某个错误，我就投入工程能力去确保它永远不再犯同样的错误。"
Harness Engineering 的本质，是将人类工程师的经验、品味和判断力，以可执行、可验证、可迭代的方式编码到系统中，让智能体在约束中创造，在反馈中成长。
行业共识：六大支柱
通过对 OpenAI、Anthropic、ThoughtWorks 和 Mitchell Hashimoto 等实践的梳理，我们可以提炼出 Harness Engineering 的六大核心支柱。
一、上下文工程：给智能体一张地图，而非一本百科全书
OpenAI 团队最早尝试的做法是写一份巨型的 AGENTS.md，把所有规则和知识塞进去。结果可想而知：智能体要么错过关键约束，要么针对错误的约束进行优化。大文件会迅速腐烂，变成陈旧规则的坟场。
他们的解决方案是将 AGENTS.md 视为内容目录，而非百科全书。真正的知识库位于结构化的 docs/ 目录中，包含：
•ARCHITECTURE.md：架构顶层地图，定义领域分层和模块边界•design-docs/：设计文档目录，记录核心信念和验证状态•exec-plans/：执行计划，活跃计划、已完成计划和技术债务都进行版本控制•references/：外部依赖和框架的精简参考
Anthropic 在解决长运行智能体的连续性问题时，采用了类似的思路：Initializer Agent 负责搭建初始环境（包括 feature_list.json、claude-progress.txt、初始 Git 提交），后续每个 Coding Agent 接手时，通过阅读进度文件和 Git 历史快速进入状态，实现跨 session 的"工作交接"。
关键洞察：智能体在运行时无法访问的知识，对它来说就是不存在的。Slack 讨论、Google Docs、人类头脑中的隐性知识，如果不以 Markdown 形式编码到仓库中，智能体就像一个迟到三个月的新员工，一无所知。
二、前馈引导（Feedforward Guides）：防患于未然
前馈引导是指在智能体行动之前，就通过规则、文档和工具引导它朝着正确方向前进。Martin Fowler 团队将其分为两类：
计算型引导（Computational）——确定性、快速、由 CPU 执行：
•自定义 Linter 和结构测试（如 ArchUnit 检查模块边界）•类型检查器、静态分析工具•脚手架脚本和代码模板
推理型引导（Inferential）——语义化、由 GPU/NPU 执行：
•AGENTS.md 中的原则性描述•Skills（技能文件），定义如何完成特定任务•设计规范和架构决策记录
OpenAI 的实践尤其强调"品味不变式"（taste invariants）。他们通过自定义 Linter 强制执行结构化日志、命名约定、文件大小限制和可靠性要求，而且 Linter 的错误信息中会直接注入修复指令——这是一种巧妙的"正向提示注入"。
Mitchell Hashimoto 的 Ghostty 项目中，AGENTS.md 的每一行都基于一次糟糕的 Agent 行为。"每一行规则，都对应着一个被修复的错误模式。"
三、反馈感知（Feedback Sensors）：让智能体自我纠错
如果说前馈引导是"不要走错路"，那么反馈感知就是"走错路了立刻知道"。同样分为两类：
计算型感知：
•单元测试、集成测试、端到端测试•代码覆盖率检查、突变测试（Mutation Testing）•依赖扫描、死代码检测•浏览器自动化测试（Anthropic 使用 Playwright MCP 让智能体像真实用户一样点击、截图、验证 UI）
推理型感知：
•AI 代码审查 Agent（Generator-Evaluator 模式中的 Evaluator）•日志质量评估•响应质量采样
Anthropic 在前端设计和全栈开发中的突破，很大程度上来自于分离生成器和评估器。当模型评估自己的工作时，往往会过于宽容；而独立的 Evaluator Agent 可以被调校得更严格、更具批判性。生成器-评估器之间形成的对抗循环，能够驱动输出质量持续提升。
OpenAI 更进一步，将整个可观测性堆栈（日志、指标、追踪）接入智能体运行时。智能体可以用 LogQL 查询日志，用 PromQL 查询指标，用 Chrome DevTools 协议驱动 UI 验证。这意味着像"确保服务启动在 800ms 内完成"这样的提示，可以直接被智能体验证和修复。
关键洞察：只有当智能体拥有自动验证自己工作成果的能力时，它才能真正自主运行。单次 Codex 运行在单个任务上持续工作超过六小时（通常是在人类睡眠时间）——这是反馈回路闭环后的自然结果。
四、架构约束：速度的前提是边界
OpenAI 团队明确提出了一个反直觉的观点：智能体在严格边界和可预测结构的环境中最为高效。他们为每个业务域定义了固定的分层架构（Types → Config → Repo → Service → Runtime → UI），依赖方向经过严格验证，横切关注点（认证、遥测等）只能通过单一的 Provider 接口进入。
这些约束通过自定义 Linter 和结构测试机械地强制执行。在传统工程流程中，这些规则可能会让人感到束缚；但在智能体优先的范式中，它们成为了倍增器——一旦编码，就能立即应用于所有地方。
Martin Fowler 团队用" fitness functions"（架构适应度函数）来描述这类约束：它们定义了架构的预期特征，并在每次变更时进行验证。比如性能要求、模块边界、可观测性标准等。
这指向了一个重要的趋势：为了获得 AI 的可维护性和可靠性，我们可能需要放弃一部分"生成任何东西"的灵活性，转而拥抱更受限但更易驾驭的技术栈和架构模式。
五、对抗熵增：持续清理与垃圾回收
完全自主的智能体会不可避免地复现代码库中已有的模式——包括那些不均衡或不够理想的模式。OpenAI 团队最初每周五要花 20% 的时间手动清理"AI 残渣"，这显然不可扩展。
他们的解决方案是将"黄金原则"编码到代码库中，并建立循环清理流程：定期运行后台 Codex 任务，扫描偏差、更新质量等级，并发起有针对性的重构 PR。大多数 PR 可以在一分钟内审查并自动合并。
这就像垃圾回收机制。技术债务就像一笔高息贷款：不断地以小额贷款的方式偿还，总比让债务累积到无法收拾要好。人类的品味一旦被捕捉，就会持续应用于每一行代码。
六、Harness Templates：从项目到组织的规模化
Martin Fowler 提出了一个极具前瞻性的概念：Harness Templates。大多数企业只有几种主要的服务拓扑——暴露 API 的业务服务、事件处理服务、数据看板等。如果团队可以基于预定义的 Harness 模板启动新项目，就能从第一天起获得一套完整的引导（Guides）和感知（Sensors）系统。
这与今天工程组织中的"Golden Path"（黄金路径）或服务模板一脉相承，但更进一步：Harness 模板不仅包含项目结构和技术栈，还包含让 AI 智能体可靠工作的完整控制体系——自定义 Linter、结构测试、代码审查 Agent、可观测性集成等。
Ashby 的必要多样性定律指出：调节器必须拥有至少与被调节系统同等的多样性。让智能体承诺一个受约束的拓扑结构，就是在做"多样性缩减"，从而使全面的 Harness 成为可能。
对我们的启示
Harness Engineering 的兴起，标志着 AI 辅助编程从"玩具阶段"进入了"工程化阶段"。以下是几点值得深思的启示：
第一，工程师的核心竞争力正在转移。 未来的软件工程师，比拼的不是打字速度或语法熟练度，而是设计约束系统、构建反馈回路、以及将人类判断力编码为可执行规则的能力。OpenAI 团队称之为"设计环境、明确意图和构建反馈回路"。
第二，代码库的可读性需要重新定义。 我们过去谈代码可读性，是针对人类新同事。现在，我们需要考虑智能体可读性（Agent Readability）——代码库中的知识是否以智能体能够直接推理的形式存在？仓库本地的、版本化的工件（代码、Markdown、Schema、可执行计划）就是智能体能看到的全部。
第三，质量左移的极致形态。 CI/CD 时代我们讲"Shift Left"，Harness Engineering 将其推向了极致：在智能体写代码的同时，就在本地运行完整的测试、Linter、结构验证、甚至浏览器自动化测试。错误在产生的第一秒就被发现和修正。
第四，技术选型需要考虑"Harness 友好度"。 强类型语言、清晰的模块边界、稳定的 API、良好的测试框架——这些对人类友好的特性，对 AI 同样友好。我们在做技术决策时，或许应该新增一个维度：这个技术栈的 Harnessability 如何？
思考与讨论：Harness 是新瓶装旧酒，还是值得投入的下一站？
在深入梳理了 OpenAI、Anthropic、ThoughtWorks 和 Mitchell Hashimoto 的实践经验之后，一个无法回避的问题浮现出来：Harness Engineering 到底是必要的范式跃迁，还是一场精心包装的焦虑贩卖？
围绕这个问题，行业内的态度正在形成两派鲜明对立的阵营。
支持派：值得投，Harness 是当前放大模型能力的必要杠杆
这一派的底气来自扎实的实践数据。OpenAI 团队用 5 个月、100 万行代码、零手写代码的实验，证明了 Harness 能够将 Codex 的吞吐量提升到人类 10 倍以上的水平。3 名工程师推动 1500 个 PR，平均每天每人 3.5 个 PR——这不是概念验证，是真实交付。Mitchell Hashimoto 在亲身走过的六步旅程中，只有在进入"Engineer the Harness"阶段后，才真正感受到"无法回头"的效率跃迁，从此"始终有 Agent 在后台运行"。Anthropic 的三 Agent 架构（Planner-Generator-Evaluator）将单一模型的能力边界向外推了整整一个数量级，从 20 分钟/$9 的粗糙原型，推进到 6 小时/$200 的可用产品。
支持派的核心论点是：Harness 不是锦上添花，而是让大模型从"玩具"变成"工具"的必经之路。 当前的大模型存在三个结构性短板，而 Harness 正是针对它们的精准补偿——上下文窗口的硬边界（记不住）、自我评估的乐观偏差（看不清自己）、长程一致性的缺失（管不住漂移）。在模型能力存在明确天花板的当下，否认 Harness 的价值，等于否认工程化的必要性本身。
支持派还引用 Martin Fowler 团队的观点：Harness 的 Feedforward（前馈引导）和 Feedback（反馈感知）构成了一个控制论意义上的闭环调节系统，这是人类工程经验的外显化和可执行化。它不是对旧技术的简单重复，而是将原本分散在人类头脑中的判断力，编码为可复用、可验证、可迭代的系统级能力。
反对派：没必要投，新瓶装旧酒的焦虑贩卖
反对派则从另一个角度切入：Harness 并没有创造任何新的底层技术。
自定义 Linter 和结构测试早在静态分析时代就已存在；CI/CD 流水线、代码审查、可观测性堆栈是 DevOps decade 的成熟产物；文档驱动开发、架构约束和模块边界治理是软件工程几十年来的基本常识。Harness 所做的，不过是将这些既有技术按照 Agent 的认知特点重新编排——把 Linter 的错误信息改造成"正向提示注入"，把测试套装修缮成智能体可以自主执行的验证回路，把文档知识库设计成渐进式披露的导航地图。
这不是技术突破，而是技术迁移——把人类工程师多年积累的质量保障手段，从"辅助人类"的语境切换到"约束 Agent"的语境。瓶确实是新的（Agent 优先的世界），但酒（Linter、测试、CI、文档、脚手架）几乎全是陈酿。
反对派的第二个论据是落地成本与收益的不对称。各家方案的差异之大，几乎到了"各说各话"的程度。OpenAI 走的是严格架构约束路线，Anthropic 探索多 Agent 协作范式，Martin Fowler 团队从控制论出发做矩阵抽象，Mitchell Hashimoto 则是逐错修复的进化路径——没有统一标准，没有行业共识，每个人都在黑暗中摸索。Anthropic 的全栈 Harness 运行一次 6 小时/$200，单 Agent 方案只需 20 分钟/$9，18 倍的成本差距换来的质量提升，在模型快速迭代的背景下是否值得？
反对派的第三个论据更为锋利：模型能力的进化速度，正在让 Harness 的价值快速折旧。 Mitchell Hashimoto 在脚注中写道："Due to the rapid pace of innovation in models, I have to constantly revisit my priors on this one."（由于模型创新的速度极快，我不得不持续重新审视自己之前的假设。）OpenAI 自己也承认："我们也不知道，随着时间的推移，模型的功能不断增强，这一系统将如何演变。"如果今天的最优 Harness 明天就被更强的模型所绕过，那我们现在的大规模投入，岂不是在为一个注定被替代的中间层买单？
回顾历史，类似的"补偿层被模型吸收"的故事已经反复上演：早期的 Prompt Engineering 需要复杂的 Chain-of-Thought 模板，而现在前沿模型已经内化了推理能力；曾经的 RAG 需要精细的文档分块和重排序逻辑，而长上下文能力正在让"把整个代码库塞进去"成为可能。Harness 会不会是下一个被模型内化的补偿层？
我的立场：过渡阶段——不是"投不投"的二元选择，而是"怎么投"的策略问题
两派的论据都有道理，也都有盲区。支持派看到了当下 Harness 能带来的真实杠杆效应，但容易忽视其底层技术的"旧酒"本质和长期折旧风险；反对派敏锐地指出了 Harness 缺乏技术原创性和模型迭代带来的替代压力，但容易滑向"因噎废食"——否定一切中间层投入的价值，等待一个"完美的未来模型"，而这个等待可能遥遥无期。
我的判断是：Harness Engineering 是一个过渡阶段，但这个"过渡"可能持续数年，且过渡期内它产生的价值是真实且可观的。
"过渡"不等于"虚假"。铁路在航空时代是过渡技术，但在它存在的百年间重塑了人类社会。Harness 也是如此——它可能在 5-10 年后被更强大的模型大幅简化，但在这 5-10 年间，率先建立 Harness 能力的团队将获得显著的生产力优势。
关键在于理性投入、区别对待。
对于那些模型短期内难以内化的能力缺口，值得重仓投入：与组织内部系统的深度集成（CI/CD、可观测性、审批流）、具有法律合规属性的硬约束（安全规则、审计要求）、以及随业务快速变化的人类意图对齐。这些不是模型的"常识缺陷"，而是组织的"独特语境"，即使模型再强大，也需要显式接入。
而对于那些明显属于模型能力缺口的补偿（如基础代码风格、常见架构模式、通用测试策略），则不必过度工程化。模型很可能在下一个版本中就自行掌握，今天你花三个月建设的自定义 Linter 规则集，明天可能就是模型默认行为的一部分。
最终，Harness 的理想形态不是越来越复杂，而是越来越薄。当模型足够强大时，我们或许只需要像今天对待资深工程师那样，提供一份简洁的 README、几个关键约束、以及清晰的验收标准——剩下的，交给它自己。
正如 OpenAI 团队所说，他们当前最棘手的挑战是"设计环境、反馈回路和控制系统"。但我想补充一句：我们设计这些系统的最终目的，应该是让未来的自己不再需要设计它们。
结语：构建软件仍然需要纪律，只是纪律的落点在变
OpenAI 团队在文章结尾写道："构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。保持代码库一致性的工具、抽象和反馈回路变得越发重要。"
Mitchell Hashimoto 的六步旅程，从"放弃聊天机器人"到"始终让智能体在后台运行"，每一步都建立在前一步的认知积累之上。他的核心方法论是：看到错误 → 工程化地防止错误 → 持续迭代 Harness。
这不是关于 AI 是否会取代工程师的辩论。这是关于工程师如何进化自己工具和范式的务实探索。Harness Engineering 给了我们一个框架、一套语言、一个方向——让我们从"和 AI 聊天"走向"为 AI 设计系统"。
正如 Martin Fowler 团队所说："一个好的 Harness 不应该试图完全消除人类的输入，而是将人类的输入引导到最有价值的地方。"
参考阅读
1.OpenAI - Harness engineering: leveraging Codex in an agent-first world[1]2.Anthropic - Effective harnesses for long-running agents[2]3.Anthropic - Harness design for long-running application development[3]4.LangChain - The Anatomy of an Agent Harness[4]5.Mitchell Hashimoto - My AI Adoption Journey[5]6.Martin Fowler - Harness Engineering - first thoughts[6]7.Martin Fowler - Harness engineering for coding agent users[7]
References
[1] Harness engineering: leveraging Codex in an agent-first world:https://openai.com/index/harness-engineering/[2]Effective harnesses for long-running agents:https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents[3]Harness design for long-running application development:https://www.anthropic.com/engineering/harness-design-long-running-apps[4]The Anatomy of an Agent Harness:https://www.langchain.com/blog/the-anatomy-of-an-agent-harness[5]My AI Adoption Journey:https://mitchellh.com/writing/my-ai-adoption-journey[6]Harness Engineering - first thoughts:https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html[7]Harness engineering for coding agent users: https://martinfowler.com/articles/harness-engineering.html