Harness Engineering：Agent First 时代的软件工程控制面

2025 年末到 2026 年初，两家最具影响力的 AI 实验室——OpenAI 和 Anthropic——几乎同时发表了关于编码智能体工程化实践的深度文章。

OpenAI 的 Ryan Lopopolo 在 Harness engineering: leveraging Codex in an agent-first world 中，披露了一个小团队用五个月时间、零手写代码、让 Codex 生成百万行级产品代码库的完整工程体系。

Anthropic 则先后发表了 Effective harnesses for long-running agents 和 Harness design for long-running application development，从跨会话连续性和生成-评估分离两个维度，揭示了让 Claude 在多小时自主编码中持续交付可靠软件的关键设计。

两篇文章的出发点不同，但殊途同归地指向一个共同结论：当编码智能体开始承担越来越多的执行工作，软件工程的核心能力从 "写代码" 转向了 "为智能体设计可靠工作环境"。

这个工作环境，就是 Harness。

本文深度融合 OpenAI 与 Anthropic 的第一手工程实践，提炼出一套完整的 Harness Engineering 框架。

一、什么是 Harness Engineering

先给一个融合两家实践后的工程化定义：

Harness Engineering，是为编码智能体设计一整套可执行、可验证、可迭代的工作环境与反馈系统，使其在较少人工介入的前提下，仍能跨多个会话持续交付可靠的软件。

这里的 Harness，不只是提示词，不只是沙箱，也不只是一个简单的循环脚本。它是一个组合系统，至少包含八类能力：

1. 任务表达：人类如何把目标、约束和验收标准说清楚
2. 上下文工程：智能体如何在离散会话之间保持连续性和记忆
3. 增量执行：智能体如何逐步推进而非一次性尝试全部完成
4. 运行态感知：智能体如何启动应用、驱动 UI、观察系统状态
5. 知识路由：智能体如何快速找到正确的设计、规范与历史决策
6. 结构约束：系统如何机械化地限制架构漂移与低质量模式扩散
7. 生成-评估分离：如何用独立的评估智能体替代自我评价
8. 熵控制：系统如何持续清理残留物并维持代码库健康

如果这些能力不存在，模型再强，也只能在一个模糊、脆弱、不可验证的环境里碰运气。如果这些能力足够强，模型能力会被成倍放大。

二、软件工程的瓶颈正在迁移

过去十几年，工程团队的典型瓶颈是开发带宽：需求很多，人手有限，所有事情都在抢同一批工程师的时间。

在 Agent First 模式下，代码生产突然不再稀缺。两家实验室的数据都在印证这一点：

• OpenAI：一个小团队在五个月内，从空仓库推进到百万行量级，累计合并约 1500 个 PR，核心约束是 "人工不直接写代码"。单个 Codex 任务经常连续运行超过 6 小时。
• Anthropic：使用三智能体架构（Planner-Generator-Evaluator），一个简单的一句话提示可以在 4-6 小时内生成功能完整的全栈应用，包含数十个特性。

但新的瓶颈随之出现：

• 人类没法手工 QA 所有变更
• 智能体在跨会话时会丢失上下文，导致重复劳动或遗忘关键决策
• 智能体倾向于自我肯定——标记功能 "已完成" 时往往没有真正验证
• 人类没法靠主观审美维持大规模代码库的一致性

于是，真正稀缺的东西变成了三样：

1. 人类的注意力：应该把判断力花在哪些高杠杆环节
2. 系统的可验证性：智能体做完后能否自己证明 "确实对了"
3. 跨会话的连续性：智能体是否能在新的上下文窗口中无缝接续前序工作

这就是为什么 Harness Engineering 会成为新的核心能力。它解决的不是 "如何多生成一点代码"，而是 "如何让高吞吐生成不迅速失控"。

三、工程师的角色，正在从作者变成系统设计者

传统软件工程里，工程师最直接的产出是代码。Agent First 软件工程里，工程师最直接的产出，越来越像下面这些东西：

正如 OpenAI 团队总结的：人类越来越像系统的 "产品经理 + 架构师 + 控制面维护者"。而 Anthropic 的实践进一步揭示：人类还需要成为评估标准的设计者——把主观品味翻译成可评分的结构化维度。

四、支柱一：让任务可以被可靠执行

智能体最怕的不是难题，而是模糊题。

4.1 目标必须可验收

一个有效任务，至少要回答四个问题：

1. 要做什么
2. 在哪个上下文里做
3. 不能违反什么约束
4. 如何验证已经完成

比如，"修一下启动慢的问题" 是一个坏任务。"把服务启动时间压到 800ms 以内；不得破坏现有健康检查；补充基准测试；若启动路径新增缓存需附带失效策略"，这就是一个更适合交给智能体的任务。

4.2 用 Planner 智能体自动展开规格

Anthropic 发现，即使是一句话的高层提示，也可以通过 Planner 智能体自动展开为完整的产品规格。例如输入 "Build a fully featured DAW in the browser using the Web Audio API"，Planner 会生成包含十几个特性、跨多个 Sprint 的详细计划。

关键设计原则：

• Planner 应该聚焦产品上下文和高层技术设计，而非底层实现细节
• 如果 Planner 在前期就指定了过于细粒度的技术方案且出错，错误会级联到下游实现
• 约束交付物，放开实现路径——让执行智能体自己选择最佳实现方式

4.3 增量执行：一次只做一个特性

OpenAI 和 Anthropic 都独立发现了同一个关键模式：任务必须增量推进，而非一次性完成。

Anthropic 明确观察到两种失败模式：

• 一次性尝试（One-shotting）：智能体试图一口气完成整个应用，导致上下文耗尽，半成品状态无法恢复
• 过早宣告完成：智能体在部分功能完成后，环顾四周就认为任务已结束

解决方案是引入 结构化特性列表（Feature List），将所有需求拆解为独立特性，每个标记为 passing/failing 状态。Anthropic 特别指出：用 JSON 而非 Markdown 存储特性列表，因为模型更不容易篡改 JSON 文件的结构。

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": [
    "Navigate to main interface",
    "Click the 'New Chat' button",
    "Verify a new conversation is created"
  ],
  "passes": false
}

配合强约束指令："It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality。"

4.4 失败时不要让人类下场补代码

这是一个极其关键的观念变化。在 Agent First 模式里，任务失败后的首选反应不应该是 "我来改两行"，而应该是：

• 缺了什么工具？
• 缺了什么文档？
• 缺了什么约束？
• 缺了什么反馈信号？

如果每次失败都靠人类手工兜底，系统不会进化，只会形成越来越贵的人工补丁层。 真正高杠杆的修复方式，是把这次失败抽象成环境能力缺口，再把补丁沉淀回 Harness 本身。

五、支柱二：上下文工程与跨会话连续性

这是 Anthropic 的核心贡献之一，也是 OpenAI 文章中相对隐含但同样重要的维度。

5.1 离散会话问题

想象一个软件项目由轮班工程师完成，每个新来的工程师对前一个班次的工作毫无记忆。这就是长时间运行智能体面临的核心挑战：上下文窗口是离散的，而复杂项目无法在单个窗口内完成。

即使有上下文压缩（compaction）机制，也不够。Anthropic 发现两个关键问题：

• 压缩不等于干净的状态：压缩保留了连续性，但没有给智能体一个"干净的起点"。残余的上下文噪声会导致注意力漂移。
• 上下文焦虑（Context Anxiety）：某些模型在接近它们认为的上下文限制时，会过早地开始收尾工作，而不是继续深入。

5.2 结构化工件交接

解决方案是设计一套结构化交接协议：每个智能体会话结束时，必须留下清晰的工件供下一个会话使用。

Anthropic 的 Initializer-Coder 双智能体方案：

1. Initializer Agent：首次运行时设置环境——创建 init.sh 脚本、claude-progress.txt 进度文件、初始 git 提交
2. Coding Agent：每次后续会话先读取进度文件和 git 日志，选择一个未完成特性，实现并测试后，写入 git 提交和进度更新

典型会话启动序列：

1. pwd — 确认工作目录
2. 读取 progress 文件和 git log — 了解最近进展
3. 读取 feature list — 选择最高优先级的未完成特性
4. 运行 init.sh 启动开发服务器
5. 执行基础端到端测试 — 确认应用未处于损坏状态
6. 开始实现新特性

5.3 上下文重置 vs 上下文压缩

Anthropic 在实践中发现了一个重要的权衡：

• 上下文压缩（Compaction）：在同一会话中压缩历史，保持连续性，但不能消除上下文焦虑
• 上下文重置（Context Reset）：完全清空上下文窗口，启动全新智能体，通过结构化交接传递状态

在使用 Sonnet 4.5 时，上下文焦虑严重到仅靠压缩无法支撑长任务，上下文重置成为必需。但 Opus 4.6 显著改善了这一行为，使得可以在单一连续会话中完成整个构建，由 SDK 的自动压缩管理上下文增长。

关键启示：Harness 的每个组件都编码了一个关于模型能力边界的假设。当模型改进时，这些假设需要被重新检验。

5.4 OpenAI 的知识版本化方案

OpenAI 从不同角度解决了同样的问题：他们把所有关键上下文——包括设计决策、架构共识、执行计划——全部版本化并沉淀到仓库内。Slack 讨论中对齐的架构模式、会议上的口头结论，如果没有被编码到仓库中，对智能体来说就等于不存在。

两家方案的共同本质：让智能体的"记忆"不依赖于上下文窗口本身，而是外化为结构化、可版本化、可检索的工件。

六、支柱三：让运行态对智能体可见

代码可读，不等于系统可理解。智能体如果只能看静态文件，看不到真实运行态，它对系统的理解永远是不完整的。

6.1 为每个任务准备独立工作区

OpenAI 让应用能够按 git worktree 独立启动。每个变更都有自己的隔离运行环境：独立代码副本、独立服务实例、独立日志与指标、独立调试与验证流程。这极大降低了并行任务之间的互相污染。

6.2 让智能体直接操作 UI

两家实验室都独立发现了端到端 UI 验证的巨大价值：

• OpenAI：将 Chrome DevTools Protocol 接入智能体运行时，创建了处理 DOM 快照、截图和导航的 Skills
• Anthropic：通过 Puppeteer MCP 让智能体直接操作浏览器，截图并分析页面状态

Anthropic 特别强调：没有端到端测试工具的智能体，倾向于只做单元测试或 curl 命令验证，但无法发现真实的功能缺陷。提供浏览器自动化工具后，智能体能够识别并修复那些仅从代码层面无法发现的 Bug。

局限性依然存在：智能体无法看到浏览器原生的 alert 弹窗、无法真正 "听到" 音频输出、视觉判断能力有限。但相比 "请相信我已经修好了"，这已是质的飞跃。

6.3 让日志、指标和链路成为一等上下文

OpenAI 将完整的可观测性栈暴露给 Codex：日志通过 LogQL 查询、指标通过 PromQL 查询、traces 直接可检查。这使得过去只属于资深工程师的性能与可靠性任务，可以被形式化为明确的验收语句：

• 启动必须在 N ms 内完成
• 某关键链路的 span 不得超过 2s
• 错误率必须回落到阈值以下

你是在把 "观察系统" 这件事，从人类专属能力，变成智能体的基础感知能力。

七、支柱四：把仓库变成唯一可信知识源

智能体最怕上下文散落在外部世界。两家实验室在这一点上高度一致。

7.1 AGENTS.md 应该是目录，不应该是百科全书

OpenAI 明确分享了他们的经验教训—— "one big AGENTS.md" 方案失败了：

• 上下文太重，真正与当前任务相关的信息被淹没
• 所有规则都显得同样重要，等于没有优先级
• 文件极易陈旧，而且没人愿意长期维护
• 很难做 freshness、覆盖率、交叉引用等机械检查

更合理的做法，是让 AGENTS.md 只承担 "入口地图" 的职责（约 100 行），真正的知识库放到可结构化组织的 docs/ 体系中：

AGENTS.md              — 仓库级入口地图（~100 行）
ARCHITECTURE.md        — 系统边界、分层、依赖方向
docs/
├── design-docs/       — 核心设计决策与原则
│   ├── index.md
│   └── core-beliefs.md
├── exec-plans/        — 执行计划、进度、决策记录
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/         — 自动抽取的结构化事实
│   └── db-schema.md
├── product-specs/     — 产品行为与验收标准
├── references/        — 智能体高频查阅的稳定参考
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

• AGENTS.md（仓库级入口地图，~100 行）：只放 “路由信息” 和最小规则（怎么开始、去哪找、什么不能做）。把细节拆到 docs/ 与专项规范文件，避免维护成本指数级上升。
• ARCHITECTURE.md（系统边界/分层/依赖方向）：定义不可违背的架构不变量（模块边界、依赖流向、关键约束），用于防止智能体高吞吐修改下的架构漂移。
• docs/design-docs/：沉淀关键设计决策与原则；
  • index.md 做目录与索引；
  • core-beliefs.md 写长期稳定的 “工程信条/原则”（为什么这么设计）。
• docs/exec-plans/：放执行过程工件（计划、里程碑、决策记录、变更日志）。
  • active/ 管进行中计划；
  • completed/ 归档已完成计划；
  • tech-debt-tracker.md 记录技术债清单与偿还策略。
• docs/generated/：放可机械生成/校验的结构化事实（schema、API surface、依赖图快照等）。db-schema.md 作为数据库/数据模型 “权威快照”，通常由脚本从迁移/模型生成，避免手写漂移。
• docs/product-specs/：定义产品行为与验收标准（用户路径、边界条件、非功能需求），让 “完成” 的定义可被测试与评估智能体直接引用。
• docs/references/：高频稳定参考（命令速查、约定、术语、常见问题、运行手册），作为智能体随时可取的 “短答案库”。
• DESIGN.md：设计系统与交互/视觉准则（组件风格、可用性规则、信息层级），约束前端体验一致性。
• FRONTEND.md：前端工程边界与规范（技术栈、目录结构、状态管理、路由、性能/可访问性要求）。
• PLANS.md：高层路线图入口（指向 docs/exec-plans 的具体计划）；保持短小，避免与执行计划重复。
• PRODUCT_SENSE.md：产品判断准则（取舍原则、默认策略、优先级排序），减少 “看似合理但偏离目标” 的功能扩张。
• QUALITY_SCORE.md：质量量化口径（评分维度、权重、门禁阈值、示例），让评估从主观品味变成可复用的结构化标准。
• RELIABILITY.md：可靠性/运维约束（SLO/SLI、错误预算、降级策略、可观测性要求、故障演练与回滚原则）。
• SECURITY.md：安全基线与威胁模型（数据分类、密钥与权限、输入校验、依赖风险、审计要求），作为涉及安全区域修改时的强约束。

7.2 渐进式披露（Progressive Disclosure）

好的知识系统不是把所有内容直接塞给智能体，而是：

• 先给它稳定入口
• 再给它明确路由
• 再让它根据当前任务深入相关局部

OpenAI 通过机械化手段强制执行这一点：专用 linter 和 CI 任务验证知识库的时效性、交叉引用和结构正确性。一个定期运行的"doc-gardening"智能体会扫描过时文档并自动提交修复 PR。

Anthropic 的 Initializer Agent 实际上也在做类似的事情：它在首次运行时自动生成项目的"导航地图"（进度文件、特性列表、初始化脚本），使后续智能体可以快速定位。

八、支柱五：把架构与品味编码成可执行约束

只靠文档，守不住一个高速增长的智能体代码库。智能体天然会复制现存模式，只要仓库里已经存在某种不够好的写法，这种写法就会不断被放大、复用、扩散。

8.1 约束重点不在 "怎么写"，而在 "什么不能破"

高质量 Harness 会避免过度规定实现细节，而是聚焦于必须守住的 invariant，例如：

• 数据边界必须先解析再使用
• 依赖方向不得逆流
• 日志必须结构化
• 文件复杂度不能突破阈值

OpenAI 的做法很有代表性：他们要求 Codex 在边界处解析数据，但不规定用什么库（模型自己选了 Zod）。约束交付物，放开实现路径。

8.2 分层架构对智能体尤其重要

在人类团队里，分层混乱往往还能靠资深工程师脑补修正。在智能体团队里，边界模糊会快速转化为依赖方向污染、责任漂移、相同逻辑在多个层次复制。

OpenAI 在项目早期就建立了严格的分层模型：每个业务域分为固定层次（Types → Config → Repo → Service → Runtime → UI），跨切关注点通过 Providers 单一接口引入，其余一律禁止。

架构不是为了美观，而是为了让智能体在高速生成时仍然不越轨。

8.3 Linter 不只是检查器，也是反馈注入器

自定义 linter 的错误信息不要只写 "哪里错了"，还要写 "应该如何修"。因为对智能体来说，这些错误信息会重新回到上下文里，直接影响下一轮修改行为。linter 不再只是拦截器，它还是一种低成本、高频次、可自动复用的反馈注入器。

九、支柱六：生成-评估分离

这是 Anthropic 最独特也最深刻的贡献，OpenAI 文章中以 agent-to-agent review 的形式隐含了类似思路，但 Anthropic 将其提升到了方法论层面。

9.1 自我评价偏差

Anthropic 发现了一个核心问题：当智能体被要求评价自己的工作时，它们倾向于自信地赞美——即使在人类观察者看来，质量明显平庸。

这在主观任务（如前端设计）上尤为突出，因为没有二元检查等价物。但即使在有可验证结果的任务上，智能体也经常表现出导致判断失误的自我肯定倾向。

9.2 GAN 启发的生成-评估架构

受 GAN（生成对抗网络）启发，Anthropic 设计了分离的 Generator-Evaluator 架构：

• Generator：负责编码实现
• Evaluator：独立审查，使用浏览器自动化实际操作应用，按结构化标准评分

分离本身不会立即消除宽容倾向——评估者依然是倾向于对 LLM 生成内容宽容的 LLM。但调优一个独立的评估者使其变得严格，远比让生成者对自己的工作保持批判性容易得多。 一旦外部反馈存在，生成者就有了具体的迭代目标。

9.3 结构化评分标准

将主观判断转化为可评分的结构化维度，是让评估者可靠工作的关键。Anthropic 在前端设计任务上定义了四个维度：

关键洞察：Claude 在工艺和功能性上默认表现不错，但在设计质量和原创性上往往平庸。通过对评分标准的措辞进行调优，可以直接影响生成者的输出方向。 例如，"the best designs are museum quality" 这样的措辞会推动设计朝特定视觉方向收敛。

9.4 Sprint 契约：协商式验收

在全栈开发场景中，Anthropic 引入了 Sprint 契约机制：Generator 和 Evaluator 在每个 Sprint 开始前协商 "完成" 的定义。

• Generator 提出要构建什么，以及如何验证成功
• Evaluator 审查提案，确保方向正确
• 双方迭代直到达成一致
• 然后 Generator 按契约实现，Evaluator 按契约验收

这在产品规格有意保持高层级的情况下尤为重要——Sprint 契约弥补了用户故事与可测试实现之间的鸿沟。

9.5 OpenAI 的 Agent-to-Agent Review

OpenAI 从另一个角度实践了类似理念：Codex 在完成代码后，会在本地和云端请求多个独立智能体评审，并在循环中迭代直到所有评审者满意（Ralph Wiggum Loop）。人类可以参与评审，但不是必需。随着时间推移，几乎所有评审工作都推向了 agent-to-agent 处理。

十、支柱七：重新设计评审与合并哲学

当 PR 吞吐变高到某个量级，很多传统团队约定会开始变成阻力。

OpenAI 的仓库以最小阻塞合并门禁运作。PR 生命周期短暂。测试 flake 通常用后续运行解决而非无限期阻塞进度。

这并不意味着 "可以乱合并"。它真正意味着：合并策略必须和验证自动化水平、回滚成本、系统可观测性一起设计。

• 等待很贵，修复可能很便宜
• 阻塞会吞噬人类的注意力，而不是保护人类的注意力
• 如果回滚、补丁和后续修复极低成本，最优策略未必是事前极致保守

当系统已经具备高密度反馈能力、短周期修正能力和持续清理能力时，最优流程会比传统工程更轻、更快，也更偏向小步快跑。

十一、支柱八：为智能体系统建立"垃圾回收机制"

完全自治的智能体系统，会不可避免地产生一种新型技术债：不是代码写不出来，而是代码会越来越像 "能跑但不够好" 的模式复印机。

OpenAI 团队曾经 "每周五花 20% 的时间清理 AI slop"。这无法扩展。

可扩展的做法，是建立后台垃圾回收流程，把人类的审美和经验沉淀成一组 golden principles（黄金原则），再由周期性智能体任务持续执行：

1. 扫描偏离规则的模式
2. 更新质量评分或技术债清单
3. 自动生成小而聚焦的修复 PR
4. 用极低人工成本完成审阅与自动合并

这个过程和 JVM 的垃圾回收很像：你不等堆炸了再处理，你用持续的小成本回收，避免长期高利率技术债复利。

对 Agent First 团队来说，持续重构不是锦上添花，而是保持智能体未来仍然可用的基础设施。

十二、Harness 进化论：与模型共同演进

这是 Anthropic 第二篇文章最深刻的洞察，值得单独成节。

12.1 每个组件都是一个假设

Harness 中的每一个组件，都编码了一个关于模型当前无法独立完成什么的假设。这些假设值得被压力测试——因为它们可能是错误的，也可能随着模型改进而快速过时。

这是 Anthropic 从实践中提炼出的一条元原则。

12.2 实证：从 Opus 4.5 到 Opus 4.6

Anthropic 的迭代经历提供了一个教科书级案例：

• Opus 4.5 时代：需要 Sprint 分解、上下文重置、严格的增量执行约束——因为模型存在严重的上下文焦虑和注意力漂移
• Opus 4.6 时代：Sprint 结构可以完全移除，模型能在单一连续会话中工作超过 2 小时。评估者在某些任务上变成了不必要的开销

12.3 实操原则

1. 新模型落地时，逐个移除 Harness 组件，观察对最终输出的影响
2. 不要一次性大幅删减——很难判断哪些组件真正承重
3. Harness 有趣的组合空间不会随模型改进而缩小——它只是移动了。旧的约束变得不再必要，新的约束空间随之打开
4. Evaluator 的价值取决于任务是否处于模型能力边界：边界内的任务不需要评估者，边界外的任务评估者仍有巨大价值

十三、一个可落地的 Agent First 工程蓝图

如果你希望把这种模式真正落到自己的项目里，我建议按下面的顺序建设。

十四、一个更符合现实的工作流

融合 OpenAI 与 Anthropic 的实践后，一个完整的 Agent First 工程工作流长这样：

十五、这条路的前提、边界与误区

Harness Engineering 很强，但它不是任何团队都能直接复制的捷径。

15.1 没有基础工程纪律，就没有高自治

如果你的项目连清晰目录结构、可重复构建流程、可运行测试、基本可观测性都没有，更强的智能体只会更快地放大混乱。

15.2 Harness 不是一次性设计

Anthropic 的经验明确表明：Harness 必须随模型能力持续演进。今天承重的组件，可能明天就变成不必要的开销。最佳实践是新模型到来时，系统地逐个检验每个 Harness 组件是否仍然承重。

15.3 评估者需要持续校准

Anthropic 发现，开箱即用的 Claude 是一个很差的 QA 智能体——它会发现合理的问题，然后说服自己这不是大问题。调优评估者是一个持续的开发循环：阅读评估日志、找到判断偏差、更新提示、重复。 这不是一劳永逸的。

15.4 "零人工写代码" 不等于 "零人工负责"

智能体拿走的是体力密集型工作，不是责任本身。人类需要为系统边界设计、验收标准定义、风险隔离、规则覆盖和质量退化检测负责。

十六、OpenAI vs Anthropic：方法论对比

两者不是互斥的，而是互补的。OpenAI 更侧重稳态运营——如何在持续增长的代码库中维持秩序。Anthropic 更侧重能力边界探索——如何让智能体在单次或多次会话中达到更高质量的输出。最佳 Harness 应该同时具备两种能力。

结语：未来的软件工程，竞争的是 Harness

软件工程不会因为智能体而消失。它只是把 "工程" 的重点，从局部代码实现，迁移到了系统级编排、约束设计、反馈回路与长期治理上。

当代码生成越来越便宜，真正贵的将是：

• 上下文是否清晰
• 约束是否明确
• 验证是否自动
• 反馈是否及时
• 评估是否独立
• 记忆是否跨会话持久
• 熵增是否被持续压制
• Harness 是否随模型一起进化

OpenAI 用一个百万行级产品证明了 Harness 的工程可行性。Anthropic 用生成-评估分离和跨会话连续性设计，揭示了 Harness 的方法论深度。两家顶级实验室的实践殊途同归地指向一个结论：

未来高性能工程团队的核心竞争力，不只是拥有强模型，而是拥有强 Harness——并且有能力让 Harness 与模型共同进化。