[Harness] Four pillars define harness engineering - Alex Lavaee
Link: How to Harness Coding Agents with the Right Infrastructure
OpenAI：百万行代码的零手写实验
GPT-5-Codex是在2025年9月15日发布的，是进一步针对 Codex 中的 Agentic Coding 优化的 GPT-5版本
方法论是 深度优先：把大目标拆成小积木（设计、代码、评审、测试等）
“缺的是哪个能力？怎么让它对 Agent 既可读又可强制执行？”
他们不是从零搭 Codex 的基础 Agent Loop，而是在搭第二层：
== 项目级 Harness ==
可以把它分成两层。
第一层：Codex通用Harness
这是 OpenAI Codex团队已经提供的：
Codex CLI
├── 调用模型
├── Agent Loop
├── 读取文件
├── 编辑文件
├── 运行Shell
├── 管理上下文
├── 权限控制
├── Sandbox
└── 返回Diff和结果这是通用能力，任何代码项目都可以使用。
第二层：项目专属Harness
三名工程师逐步构建的是：
Project Harness │ ├── 1. 项目知识与导航 │ ├── AGENTS.md │ │ └── 告诉 Agent：这是一个什么项目、从哪里开始找资料、 │ │ 使用什么命令、必须遵守哪些最高优先级规则。 │ │ │ ├── 架构细节 │ │ └── 告诉 Agent：系统由哪些模块组成、数据怎么流动、 │ │ 各层之间允许怎样依赖。 │ │ │ └── 产品细节 │ └── 告诉 Agent：系统为什么存在、功能应该表现成什么样、 │ 用户真正需要什么、什么结果才算完成。 │ ├── 2. 任务规划与长期状态 │ ├── Execution Plans │ │ └── 把复杂任务拆成步骤，记录进度、决策、风险和验证方式。 │ │ │ └── PR 工作流 │ └── 保存一次修改的代码、解释、审查意见和修改历史。 │ ├── 3. 正确性验证与架构护栏 │ ├── CI（测试的流程） │ │ └── 每次修改后自动运行统一检查，防止 Agent 跳过验证。 │ │ │ ├── 测试系统（定义成功的条件 即Jira完成：bug消失 或 需求已实现） │ │ └── 用可执行方式定义“正确行为”，让 Agent 能判断修改是否成功。 │ │ │ ├── Custom Linters（能debug） │ │ └── 自动发现普通测试不容易覆盖的项目专属违规行为。 │ │ │ └── 依赖结构检查 │ └── 阻止模块之间形成错误依赖，避免架构逐渐腐烂。 │ ├── 4. Agent 的观察与操作能力 │ ├── UI 操作工具 │ │ └── 让 Agent 真正打开应用、点击页面、重现问题并验证修复。 │ │ │ ├── Logs / Metrics / Traces │ │ └── 让 Agent 看见运行时发生了什么，而不只是阅读静态代码。 │ │ │ └── Repository Skills │ └── 封装项目中反复使用的工作方法、命令和专用流程。 │ ├── 5. 质量控制与协作 │ ├── Agent Review 流程 │ │ └── 让另一个 Agent 从安全、测试、架构等角度检查修改。 │ │ │ └── PR 工作流 │ └── 让实现、审查、反馈和修复形成可追踪的闭环。 ----> 审查、反馈 │ └── 6. 长期维护（定期清理垃圾，保持整体方向，需一个单独的Agent） └── 定期技术债务清理 AI Slop. └── 持续扫描坏模式、过期文档和架构漂移，
防止大量 Agent 生成代码后质量逐渐下降。
审查、反馈：Martin Fowler 提到了 ArchUnit 等结构测试框架的潜力——它们可以验证 代码库的架构约束 是否被遵守，这对于 AI Agent 生成的代码尤其重要。
分层架构依赖方向 强制执行（OpenAI 实践）：Types → Config → Repo → Service → Runtime → UI
Anthropic：16 个 Agent 构建 C 编译器
两阶段解决方案：
初始化 Agent：使用专门的 prompt 建立初始环境，包括 init.sh 脚本、claude-progress.txt 进度日志和初始 git 提交。
编码 Agent：每次后续会话要求模型做出增量进展，然后留下结构化更新。
Huntley: Backpressure as the Core Primitive
什么叫“背压”？这个词原本来自流体和数据流系统：
下游处理不过来或不接受输入时，会产生一种反向作用，阻止上游继续无控制地输出。
不是“写一个无限循环就能让 AI 自动编程”，而是：
Agent 的自主性，不主要来自循环本身，而来自围绕循环建立的约束、验证和纠错系统。
Stripe
Agent的上限，不只是模型有多聪明，而是企业能向它开放多少高质量、标准化、可审计的开发能力。
Stripe Minions 重点体现什么？
|
观察维度 |
Stripe 的具体做法 |
它真正体现的价值 |
|
核心目标 |
让 Agent 从接到任务开始，独立完成调查、修改、测试、修复 CI 和创建 PR；人主要在最终审查阶段介入。 |
把 Coding Agent 从“代码助手”升级为“端到端交付单元”。 |
|
Agent 是一等开发者 |
Agent 从系统设计之初就能访问与人类工程师相近的代码、文档、构建、测试和内部工具，而不是事后临时拼接。 |
效率来自完整工作条件，而不只是模型聪明。（放权） |
|
预热、隔离 Devbox |
每项任务进入标准化、已安装依赖的开发环境；与生产和公网隔离。 |
减少环境配置时间，同时限制错误影响范围，因而 可以安全放权。 |
|
Toolshed MCP |
通过 集中式 MCP 服务 向 Agent 提供数百个内部系统及 SaaS 工具。 |
Agent 可以自己查文档、CI、任务和内部信息，减少人工搬运上下文。 |
|
Blueprints / 结构化流程 |
确定性步骤由程序控制，开放性步骤交给 Agent 推理；例如环境创建、检查和 PR 创建采用固定流程。 |
不是“一切交给 LLM”，而是确定部分用代码，不确定部分用 Agent。 |
|
快速测试与 CI |
依靠成熟的 Lint、Build、选择性测试和 CI，为 Agent 提供快速、清晰的错误反馈。 |
形成高质量 Backpressure，使 Agent 能连续自我修复。 |
|
任务级并行 |
大量任务分别进入独立 Agent 和独立 Devbox，并行形成 PR。 |
规模主要来自标准化任务流水线和环境并行，不一定依赖复杂的 Agent 相互对话。 |
|
人类责任边界 |
Agent 负责中间执行过程；人类保留最终 Review、合并及高风险决策。 |
无人值守执行不等于无人负责。 |
一句话记忆：Stripe 的独到之处不是某个神奇 Agent，而是把成熟的企业开发平台改造成了 Agent-ready Developer Platform。
Hashimoto
不要只修复Agent这一次的错误，要修改Harness，让以后所有Agent都不再犯同一种错误。
Hashimoto 的 Ghostty 实践重点体现什么？
|
观察维度 |
Ghostty 的具体做法 |
它真正体现的价值 |
|
核心目标 |
不是追求完全自动化，而是持续提高 Agent 在真实项目中的可靠性，并利用人的非工作时间推进任务。 |
强调长期协作质量，而不是一次性最大吞吐。 |
|
失败驱动的 Harness |
Agent 每出现一种可重复失败，就分析失败原因并补充规则、工具或验证器。 |
Harness 不是一次性设计完成，而是由真实错误逐步生长。 |
|
AGENTS.md 作为经验记忆 |
文件中的规则对应过去发生过的具体失败，例如错误命令、错误 API、错误构建方式。 |
把个人经验变成后续所有 Session 都能使用的持久化记忆。 |
|
规则与工具分工 |
简单且稳定的问题写入 AGENTS.md；无法靠文字可靠避免的问题，则建设脚本、工具或自动验证。 |
从“提醒 Agent”逐步升级为“让错误方案无法通过”。 |
|
目录级局部上下文 |
在相关子目录中放置针对该区域的规则，而不是把所有知识塞进一个巨大文件。 |
体现渐进式 Context：Agent 只在需要时获取相关项目知识。 |
|
下班前启动 Agent |
每天最后一段时间启动一个或少量后台任务，让 Agent 在人离开后做研究、尝试或部分实现。 |
把人的休息时间转换为第二天的“暖启动”。 |
|
克制的自动化 |
只选择适合 Agent 的任务，并不追求始终运行大量 Agent；人仍决定方向和是否采纳结果。 |
说明有效 Agent 工作流不一定需要庞大 Multi-Agent 平台。 |
|
工程棘轮效应 |
每次解决一个失败模式后，项目不应再次退回同一种错误。 |
系统能力只向前积累：一次改进，未来所有 Agent 受益。 |
一句话记忆：Hashimoto 的独到之处是：不要只修复 Agent 这一次的错误，而要修改 Harness，让以后不再重复同一种失败。
案例总结与反思
与之前五个案例相比，它们补上了什么？
|
原有案例 |
原案例的核心重点 |
Stripe 补上的视角 |
Hashimoto 补上的视角 |
|
Huntley / Ralph |
极简持续循环、文件化状态和 Backpressure；重点是 Agent 怎样持续运行。 |
把循环和 Backpressure 放大成企业级、可隔离、可并行的任务生产平台。 |
补充“每次失败如何变成永久规则”，让下一次循环比上一次更可靠。 |
|
Horthy / HumanLayer |
Research → Plan → Implement；重点是复杂任务内部的上下文质量与人工高杠杆审查。 |
补充企业级工具接入、标准 Devbox、CI 和任务分发，关注大规模持续交付。 |
补充个人长期使用节奏：小步积累规则、工具和后台暖启动。 |
|
OpenAI Agent-first 项目 |
从新项目出发，将仓库、文档、测试、可观测性和 Review 建设成 Agent-first 环境。 |
证明大型既有企业组织也能把已有开发平台接入 Agent，并形成千级 PR 吞吐。 |
证明不需要一开始建设庞大平台，也可以从单个项目的真实失败渐进演化。 |
|
Anthropic / Carlini |
多 Agent 共同攻克一个大型目标；重点是并行协作、共享 Git、任务锁与测试 Oracle。 |
补充另一种规模化：大量相对独立的企业任务分别并行交付，而非围绕单一超大目标协作。 |
补充低规模、轻量、以个人注意力和非工作时间为核心的实用工作方式。 |
|
Vasilopoulos / Codified Context |
三层知识架构、专业 Agent 和 MCP Knowledge Base；重点是项目知识如何形式化组织。 |
补充实时企业工具和执行能力：不只是“知道什么”，还能够真正操作内部开发系统。 |
补充最轻量的知识形成方式：规则不必预先完备，可以由一次次真实失败沉淀。 |
最成功的案例是 Stripe? 类比的，我能学到什么？或者说“迁移”些什么。
适合你的第一版，不要一开始就做完全自动化。第一版可以只实现：
Slack需求 ↓ 需求澄清 ↓ 生成 requirements/change-xxx.md ↓ 人工确认 ↓ 调用 Cloud Coding Agent ↓ 修改独立 Git Branch ↓ 运行固定测试 ↓ 生成 PR ↓ 人工 Review
- 增加一个API；
- 修改一个配置项；
- 增加一种Camera消息；
- 修复一个有明确复现步骤的Bug；
- 更新代码并同步文档。
这一版成功以后，再逐渐加入：
- 自动选择相关文档；
- 自动模拟测试；
- Review Agent；
- 自动更新架构图；
- 自动发布低风险版本。
理解四大支柱
支柱一：上下文架构（Context Architecture）
支柱二：Agent 专业化（Agent Specialization）
支柱三：持久化记忆（Persistent Memory）
支柱四：结构化执行（Structured Execution）
1. 上下文架构
Context Architecture
核心问题：Agent 当前应该知道什么？
不是把所有资料都塞给 Agent，而是根据任务提供最相关的信息。
重点：
-
核心规则每次加载
-
当前任务资料按需加载
-
大量历史资料需要时再查询
-
避免上下文过长和信息污染
一句话：
在正确的时间，给 Agent 正确的信息。
2. Agent 专业化
Agent Specialization
核心问题：这项工作应该由谁完成？
不同 Agent 可以负责不同任务，例如：
-
需求澄清
-
架构分析
-
编写代码
-
测试验证
-
代码审查
真正的专业化不仅是角色名称不同，还包括不同的：
-
职责
-
上下文
-
工具
-
权限
-
完成标准
一句话：
让合适的 Agent，只负责自己擅长的事情。
3. 持久化记忆
Persistent Memory
核心问题：Session 结束后，什么必须留下？
不能依赖聊天记录保存项目状态。重要信息应写入：
-
Git
-
需求文档
-
架构决策
-
Execution Plan
-
进度记录
-
测试结果
-
PR 和 Release Notes
一句话：
对话可以结束，但项目知识和进度不能丢失。
4. 结构化执行
Structured Execution
核心问题：任务怎样可靠地从需求走到完成？
复杂任务需要分阶段执行：
需求澄清
→ 方案设计
→ 代码实现
→ 自动测试
→ Review
→ PR
→ 发布
每个阶段都应该有：
-
明确输入
-
明确输出
-
完成条件
-
失败后的返回路径
一句话：
让 Agent 按可检查、可验证的流程完成任务。
四大支柱的整体关系
给正确的信息
↓
交给合适的 Agent
↓
把过程和结果保存下来
↓
按照可靠流程执行和验证
最简记忆
| 支柱 | 核心问题 |
|---|---|
| 上下文架构 | Agent 应该知道什么？ |
| Agent 专业化 | 应该由谁来做？ |
| 持久化记忆 | 什么必须长期保存？ |
| 结构化执行 | 怎样可靠完成？ |
浙公网安备 33010602011771号