纵向分析：关键决策逻辑与制度化过程
纵向叙事讲完“发生了什么”，这一节更像“拆发动机罩”：把几个关键节点背后的决策逻辑还原出来——为什么是这些选择，而不是另外一些更直觉的路。
从“换更强模型”转向“补系统短板”
Hashimoto 的表述很能代表一线工程师心态的变化：他在 Step 5 的动机并不是“模型不够聪明”，而是“agent 更高效的前提是：第一次就做对，或至少能快速被工具告知哪里错了”。因此最稳的路径不是让它‘更努力’，而是给它高质量、快速的校验工具。
OpenAI 的 Codex 实验把这一点制度化成团队哲学：遇到失败，修复几乎不是‘再试一遍’，而是追问“缺了什么能力？怎样让它对 agent 可见且可执行？”这是一种典型的软件工程归因方式：把不稳定行为视为系统缺陷，而不是单次输出质量问题。
LangChain 在 Terminal Bench 的改进路径则给出更细颗粒度的证据：最常见失败模式是 agent 写完自我检查一遍就停了、不跑测试；他们用系统提示 + PreCompletionChecklist 这类中间件强制代理进入 build-verify-fix 循环，等于把“质量门禁”从软约束升级为硬机制。
这些案例共同指向一个决策逻辑：模型能力提升会带来更高上限，但 harness 工程化能显著抬高下限；现实交付里，下限往往比上限更值钱。
“把知识写进 repo”而不是“把人装进群聊”
一旦你接受“agent 看不到就等于不存在”，你就会理解 OpenAI 在 Codex 实验里为什么强调“repository knowledge 是 system of record”：他们发现大而全的 AGENTS.md 会失败，因为上下文稀缺、信息过载、规则快速腐烂且难验证；更好的方式是给 agent 一张地图，让它按需深入到结构化文档、计划与参考资料里，并通过 linters/CI 去机械地检查这些知识库是否新鲜、互链、结构正确。
这个选择背后有非常现实的约束：人类团队可以靠“口口相传 + 资深工程师审阅”维持隐性知识，但 agent 的可见世界极其狭窄。于是 harness engineering 的一个核心工作变成“把组织知识外显化、版本化、可测试化”。
这也解释了为什么 AGENTS.md 这种看似朴素的文件会在 2025–2026 年迅速扩散：它提供一个“可预测的位置”存放项目约束，使不同工具能读取一致的指引。AGENTS.md 官网强调它是开放格式、像给 agent 的 README，并指出已被超过 6 万个开源项目使用。OpenAI 在 AAIF 的表述里也回溯了它的起点：Codex 需要一种可预测方式获取项目规范（编码风格、构建步骤、测试要求）以更安全高效地工作；从 2025 年 8 月发布以来，AGENTS.md 被 6 万+ 项目采用。
用“确定性系统”承接“非确定性智能”：为什么蓝图、门禁、沙箱会变成基础设施
两家对照非常鲜明的案例能说明这一点：
OpenAI 在 Responses API 的 agent 基础设施里，几乎把“harness 的基础设施层”写成了产品：shell tool、托管容器工作区、文件系统/SQLite 等结构化存储、受控网络访问、以及内置 compaction 来支撑长任务。其中网络访问部分尤其体现 harness 思维：容器不应直连互联网，而应通过 egress proxy 走集中策略层，做 allowlist 与访问控制；凭证通过域名范围的 secret 注入，让模型可见的只是占位符，降低泄漏风险。这不是“更聪明的提示词”能解决的问题，而是典型的系统安全工程。
Stripe 的 Minions（从公开二手整理稿与工程社区镜像可见）同样走向“确定性编排 + agent 创造力”的混合结构：以蓝图（blueprints）把 git 操作、lint、测试、CI、PR 模板等流程固化为可重复执行的确定性序列，再把不确定的创造性部分交给模型；并强调“shift feedback left”，尽量把会在 CI 里失败的检查左移到本地、在几秒内完成，减少昂贵的迭代成本。
这条路线背后有一条非常硬的工程约束：一旦 agent 的吞吐上来，传统 PR 审批、等待、讨论会变成瓶颈。OpenAI 在 Codex 实验里甚至提到，高吞吐下许多传统规范会变得“反生产力”，因此他们采用更少阻塞的合并哲学，并通过后续运行与清理流程修正。换句话说，吞吐提升迫使治理方式改变：你不能用“低吞吐时代的手工控制”管理“高吞吐时代的自动生成”。
Harness 不是越大越好：它必须能“随模型变强而拆掉”
Anthropic 的故事提供了一个非常重要、也很容易被忽略的视角：harness 的每个组件都在编码一个假设——“模型自己做不好”。当模型升级后，这些假设可能过期。
在《Harness design for long-running application development》里，Anthropic 写到：他们早期 harness 需要 context resets 来对抗 Sonnet 4.5 的 context anxiety；但 Opus 4.5 在模型能力层面大幅缓解这一行为后，他们就能把 context resets 整个从 harness 里移除，并依赖 Claude Agent SDK 的自动 compaction 在单次长会话里持续推进。
LangChain 的《Anatomy of an Agent Harness》也把这种“共演化”讲得很直白：当 agent 产品把 harness 组件放进训练/后训练回路，模型会对某类 harness 语义产生适配甚至过拟合；因此 harness 与 model 会互相牵引、互相塑形。
这意味着 Harness Engineering 的成熟标志之一，是它不只是不断加护栏，还要能判断哪些护栏已经成了累赘，并在适当时候删掉。可拆卸性在 2026 年很可能会成为顶级 harness 团队的核心能力（这是基于上述实践的推断）。
从“个人技巧”到“生态标准”：AAIF 的出现意味着什么
当一个范式开始产生跨组织协作的“接口层”，它就会从技能变成基础设施政治。
2025 年 12 月 9 日，Linux Foundation 宣布成立 Agentic AI Foundation（AAIF），并在新闻稿里把 MCP、goose、AGENTS.md 作为三大奠基项目纳入：MCP 作为连接工具/数据/应用的协议，goose 作为本地优先 agent 框架，AGENTS.md 作为为编码代理提供项目指引的通用格式；同时列出包括 AWS、Google、Microsoft、OpenAI、Anthropic、Block 等在内的白金成员。
OpenAI 在同日的中文公告里也明确：开放标准之所以关键，是为了避免生态碎片化，帮助智能体系统从实验走向生产；并回溯 AGENTS.md 的起点与扩散速度。
这一步的深层含义是：Harness Engineering 不再只是“你家工程团队怎么写脚本”，它开始拥有类似 Kubernetes / LSP 那样的“公共底座”。而一旦底座公共化，竞争就会上移到更高层：谁能提供更好的 harness 模板、验证体系、观测体系、以及更快的闭环迭代。
