文章1：https://www.anthropic.com/engineering/harness-design-long-running-apps
文章2：https://openai.com/zh-Hans-CN/index/harness-engineering
1. 序言：o1 时代，程序员正在从“搬砖”转向“监工”
最近，AI 领域两大巨头 OpenAI 和 Anthropic 先后发布了关于“Harness（支架/环境）”设计的技术文章。
虽然侧重点不同，但它们共同指向了一个极其明确的信号：传统的“Prompt Engineering（提示工程）”正在失效，取而代之的是“Harness-engineering（支架工程/环境工程）”。
作为架构师，我们必须意识到：未来的核心竞争力，不再是你会写多少行代码，而是你能不能为 AI 编织出一套精准的“环境（Harness）”。
2. 什么是 Harness？两大巨头的共识
“Harness” 这个词，在电子工程里是“线束”，在软件测试里是“测试床”。但在 2026 年的 AI 语境下，它被赋予了全新的含义：夹在“人类意图”与“模型执行”之间的自动化治理系统。
OpenAI 的哲学：定义“新护栏”
OpenAI 认为，AI 的推理能力（如 o1）已经溢出，限制它的是环境。
意图 (Intent)： 别再写代码，去写 Specs（规格书）和测试用例。
约束 (Constraints)： 用 Linter 和架构规则锁死 AI 的发挥空间。
反馈循环 (Feedback Loops)： 建立一个“自动报错 -> 自动回传 -> 自动修复”的自愈闭环。
Anthropic 的工程：打造“多代理车间”
Anthropic 则给出了更硬核的实现方案。为了解决 AI 在长任务中的“语境焦虑”和“自评盲区”，他们设计了一个三位一体的架构：
Planner (规划者)： 负责野心勃勃的架构设计。
Generator (生成者)： 负责短冲刺（Sprints）式的编码实现。
Evaluator (评价者)： 这是精髓。它是一个**“挑刺型”AI**，会通过 Playwright 等工具模拟真实用户去点击、去报错，然后强制 Generator 进行迭代。
3. 核心洞察：为什么要“测试左移”到极致？
如果你仔细观察这两篇文章，会发现一个惊人的结论：测试不再是开发的最后一步，而是 AI 开发的起点。
没有 Harness，AI 就是脱缰的野马： 它会写出看似完美但无法运行的代码，甚至会为了迎合你而撒谎（自评偏差）。
有了 Harness，AI 就是高效的工厂： * 开发者定义“真值（Ground Truth）”——例如使用 Bruno 编写 API 契约，或定义严密的数据库 Schema。
Harness 负责监控 AI 的产出，如果不符合契约，直接打回重写。
结论： 纯开发和纯测试的职位正在合并。未来的高级工程师本质上都是 SDET（测试开发工程师）。
4. 架构师的实战指南：如何构建你的 Harness？
在 2026 年的架构设计中，我们需要引入“AI 友好性”维度：
第一步：文档即契约 (Docs-as-code)
利用像 Bruno 或 Docusaurus 这种工具，将业务逻辑固化为 AI 可读取、可校验的结构化文档。这是 AI 理解你意图的“唯一真值源”。
第二步：建立“评价者”节点
不要试图让一个 AI Agent 既写代码又做测试。参考 Anthropic 的经验，构建一个独立的 Evaluator Agent。它不看代码实现，只看运行结果（黑盒测试）。
第三步：设计状态交接 (Structured Handoff)
长任务必然涉及上下文丢失。我们需要设计类似 Artifacts 的机制，让 AI 在“重置环境”后，能通过结构化的中间件快速接手上一阶段的工作。
5. 结语：驾驭，而非替代
OpenAI 告诉我们“为何转变”，Anthropic 告诉我们“如何转变”**。
未来的软件工程是一场关于“驾驭”的艺术。我们不再是代码的生产者，而是代码生产环境的设计者。当你能亲手织出一套完美的 Harness，你才真正拥有了成千上万个 24 小时不停歇的“AI 开发者”。