摘要

过去两年，AI 编程领域的大部分注意力都放在模型能力上：谁的推理更强、谁的代码生成更准、谁的上下文窗口更长。

但当 Coding Agent 真正进入大型项目后，工程团队逐渐发现了一个反直觉的事实：

模型能力已经不是唯一瓶颈。

同一个模型，换一套工具接口、上下文组织方式、测试机制和任务流程，最终表现可能相差数倍。真正决定 Agent 能否持续工作的，不只是它会不会写代码，而是周围有没有一套系统，让它知道该做什么、不能做什么、做得对不对，以及失败后如何恢复。

这套围绕 Agent 建立的工程系统，被称为 Harness Engineering。

本文不会把 Harness Engineering 讲成一个抽象的新名词，而是从 Agent 为什么会失控开始，逐步拆解它的核心机制、工程组件、典型案例以及真正可落地的方法。

关键词

Harness Engineering、AI Agent、Coding Agent、Context Engineering、AGENTS.md、多智能体、Agent 评测、软件工程

---

一、假如你招到一个能力很强，但每天都会失忆的工程师

先不要急着看 Harness Engineering 的定义。

我们做一个假设。

你招来了一名非常优秀的工程师，他阅读代码很快，能写前端、后端、数据库，也能分析报错，甚至可以连续工作几个小时。

但他有几个奇怪的问题：

第一，他每天上班都会失忆。

第二，他看见项目里有人这么写，就会认为这可能是团队规范，哪怕那段代码本身是错的。

第三，他写完代码后，容易直接宣布“任务完成”，却没有真正跑一遍完整业务流程。

第四，他不知道公司的隐性规则。哪些目录不能修改、哪些接口必须兼容、哪些数据绝对不能删除，都需要有人明确告诉他。

第五，他不会自然地感知时间。如果一个测试要运行几个小时，他可能真的在那里等几个小时。

这名工程师，就是今天的 AI Agent。

面对这样的员工，最无效的管理方式是什么？

每天告诉他：

你要认真一点。
你要考虑周全。
你要保证代码质量。
你不要犯错。

这些话听起来都对，但几乎没有工程价值。

真正有效的方式，是给他建立一套工作系统：

• 上岗前先阅读项目说明；

• 开工前必须提交计划；

• 一次只处理一个明确任务；

• 修改代码后自动运行测试；

• 违反架构规则时立即阻止；

• 每完成一步都记录当前状态；

• 下一位工程师可以读取交接记录；

• 同一种错误出现后，系统永久增加一道检查。

这一整套围绕 Agent 建立的环境、规则、工具、反馈和记忆机制，就是 Harness。

Harness 原本是“缰绳、马具”的意思。

模型像一匹力量很强的马。Harness 的作用不是让马拥有更大的力量，而是把已有力量稳定地引导到正确方向。

---

二、别把 Harness Engineering 理解成“高级提示词”

Harness Engineering 经常和 Prompt Engineering、Context Engineering 一起出现，但三者解决的不是同一个层次的问题。

1. Prompt Engineering：这一次怎么说

Prompt Engineering 关心的是：

我应该如何描述任务，模型才能更准确地理解？

例如：

请分析这个接口报错，并给出修改方案。

更进一步，可以补充角色、格式和限制条件：

你是一名资深 Python 后端工程师。
请分析以下 FastAPI 报错，只修改日期解析逻辑，
不要改变现有接口返回结构。

Prompt 主要影响单次交互。

---

2. Context Engineering：这一次让它看到什么

Context Engineering 关心的是：

Agent 在执行任务时，应该获得哪些信息？

例如：

• 当前代码文件；

• 项目目录结构；

• 数据库 Schema；

• 错误日志；

• 接口文档；

• 相关历史决策；

• 当前任务状态。

Prompt 决定“怎么说”，Context 决定“给它看什么”。

---

3. Harness Engineering：整个系统如何保证它长期做对

Harness Engineering 关心的是：

当 Agent 持续执行任务时，系统如何约束、检查、恢复和改进？

它覆盖的范围更广：

• Agent 可以调用哪些工具；

• 可以修改哪些目录；

• 执行前是否必须规划；

• 什么条件才算任务完成；

• 测试失败后如何处理；

• 跨会话状态保存在哪里；

• 多个 Agent 如何避免冲突；

• 过去的失败如何变成永久规则；

• 生成代码越来越多后如何控制技术债。

可以用一个简单的类比来理解：

Prompt 是给员工下达任务。
Context 是给员工准备资料。
Harness 是公司的制度、工具、流程、权限和质检体系。

因此，Harness Engineering 绝不是把提示词写得更长。

恰恰相反，优秀的 Harness 往往会让提示词越来越简单，因为大量规则已经被固化在系统中，不再需要每次重复提醒。

---

三、为什么模型已经很强，Agent 还是经常翻车

很多 Agent 项目失败后，团队的第一反应是换模型。

模型不够聪明，换一个参数更多的。

模型容易忘记，换一个上下文更长的。

代码质量不好，再换一个编程排行榜更高的。

但真实情况往往是：模型有能力完成任务，却被糟糕的工作环境限制了。

1. Agent 试图一步完成整个任务

给 Agent 一个大型需求：

帮我完成一个企业知识库系统，支持文档上传、OCR、向量化、检索、权限管理和后台配置。

Agent 很容易立即开始写代码。

它可能先建数据库，再写接口，再修改前端。做到一半时，上下文已经塞满，早期决策开始被遗忘。

下一次会话启动时，新 Agent 看到的是：

• 一批未完成的代码；

• 没有说明的配置；

• 不知道是否可用的数据库迁移；

• 部分通过、部分失败的测试；

• 没有记录的设计决策。

它只能先花大量时间猜测之前发生了什么。

这不是模型能力不足，而是任务没有被拆分，状态也没有被持久化。

---

2. Agent 很容易过早宣布完成

对人类工程师来说，“代码写完”和“功能完成”不是一回事。

但 Agent 经常使用下面的判断逻辑：

代码已经生成
→ 没有明显语法错误
→ 任务完成

真实的完成标准应该是：

代码能够运行
+ 接口符合约定
+ 数据写入正确
+ 用户流程可完成
+ 原有功能没有被破坏
+ 验收标准全部通过

如果系统没有明确的完成门槛，Agent 就会自己定义什么叫完成。

而模型通常会高估自己的工作结果。

---

3. Agent 会复制代码库里的坏习惯

LLM 非常擅长模仿现有模式。

这既是优势，也是风险。

如果代码库里存在清晰统一的 Repository、Service 和 Controller 分层，Agent 大概率会继续遵守。

但如果项目里已经存在三个重复的日期解析函数，Agent 可能不会主动抽象，反而会写出第四个。

在 Agent 看来：

同一种写法出现了三次，说明这可能就是团队规范。

于是，代码库中的历史问题会被快速复制。

过去，一个坏模式可能需要几个月才扩散到整个系统；在 Agent 大规模生成代码后，它可能几天内就被复制到几十个模块。

---

4. Agent 看不到真实运行世界

只看代码，很难发现所有问题。

例如：

• 按钮能够渲染，但点击后没有反应；

• 接口返回 200，但数据库没有写入；

• 页面没有报错，但数据显示错位；

• 单元测试通过，但完整业务流程失败；

• 服务可以启动，但启动耗时从 1 秒变成了 12 秒。

如果 Agent 只能读取代码，不能看到浏览器、日志、数据库状态和性能指标，它只能猜测系统是否正确。

这也是为什么可观测性会成为 Harness 的核心组成部分。

---

四、Harness Engineering 的本质：建立一个闭环控制系统

普通的 AI 编程流程通常是：

输入需求
→ 模型生成代码
→ 人工检查

这仍然是一次性生成思维。

真正可靠的 Agent 系统应该是一个闭环：

读取目标
→ 获取相关上下文
→ 生成计划
→ 执行一个小步骤
→ 观察执行结果
→ 自动验证
→ 失败则修复或回滚
→ 保存当前状态
→ 继续下一个任务

可以把 Agent 的工程可靠性写成一个近似公式：

Agent 可靠性
≈ 模型能力
× 上下文质量
× 工具可用性
× 行为约束
× 状态连续性
× 验证能力
× 错误恢复能力

这里使用乘法，而不是加法，是因为任何一项严重缺失，都可能让整个系统失效。

模型能力很强，但没有测试，错误无法被发现。

测试很完善，但没有状态记录，跨会话后重复劳动。

上下文很多，但全是无关内容，模型注意力被稀释。

规则写得很完整，但无法机械执行，Agent 仍然可以违反。

这正是 Harness Engineering 和普通 AI 调用最大的区别：

它不再把模型输出当成最终结果，而是把模型看作控制系统中的一个决策组件。

---

五、第一根支柱：上下文不是越多越好，而是要分层

很多团队刚开始做 Agent 时，会建立一个巨大的 AGENTS.md 或 CLAUDE.md。

里面什么都有：

• 项目介绍；

• 技术架构；

• API 文档；

• 数据库说明；

• 编码规范；

• 历史问题；

• 部署命令；

• 业务背景；

• 测试规则。

看起来很完整，实际却会产生新的问题。

1. 所有内容都重要，等于没有重点

模型可以读取很长的上下文，但不代表它能够同等重视所有内容。

当上下文中同时存在几十条规则时，Agent 很难判断：

• 当前任务真正需要哪几条；

• 哪些规则优先级最高；

• 哪些文档已经过期；

• 哪些内容只是背景知识；

• 哪些内容与当前模块无关。

大量无关上下文，会稀释真正关键的信息。

---

2. 更好的方式是渐进式披露

可以把上下文分为三层。

第一层：会话常驻上下文

每次启动都自动读取，但必须足够短。

AGENTS.md
├── 项目目标
├── 核心目录说明
├── 必须遵守的规则
├── 常用启动和测试命令
└── 其他文档入口

AGENTS.md 不应该成为一本百科全书，而应该像机场导航牌。

它不保存所有信息，只负责告诉 Agent：需要什么信息时，应该去哪里找。

---

第二层：领域上下文

根据任务按需加载。

docs/
├── backend_architecture.md
├── frontend_rules.md
├── database_schema.md
├── rag_pipeline.md
├── security_rules.md
└── deployment_guide.md

修改数据库时加载 database_schema.md。

开发前端时加载 frontend_rules.md。

处理知识库检索时加载 rag_pipeline.md。

Agent 不需要在每个任务中携带整个公司的知识。

---

第三层：冷知识库

只有需要时才检索，例如：

• 历史会议记录；

• 长篇技术白皮书；

• 旧版本方案；

• 故障复盘；

• 产品需求文档；

• 大规模企业知识库。

这部分适合通过 RAG、搜索工具或专业子 Agent 获取。

上下文工程真正追求的不是：

让 Agent 知道最多。

而是：

让 Agent 在正确的时间，看到完成当前任务所需的最少充分信息。

---

六、第二根支柱：把记忆放进文件系统，而不是聊天记录

长时间运行的 Agent，最大的敌人不是不会写代码，而是跨会话失忆。

一个新会话开始后，Agent通常不知道：

• 上次完成了什么；

• 当前卡在哪里；

• 哪些方案已经被否决；

• 为什么选择现在的架构；

• 哪些测试仍然失败；

• 下一步应该做什么。

因此，真正可靠的 Agent 系统不能把记忆完全放在上下文窗口中。

上下文窗口适合临时推理，文件系统适合长期记忆。

1. 功能列表

使用结构化文件记录所有功能状态：

{
  "feature_id": "F-023",
  "name": "上传扫描版PDF",
  "status": "in_progress",
  "acceptance_tests": [
    "支持PDF上传",
    "扫描版PDF自动进入OCR流程",
    "解析失败时返回明确错误",
    "解析结果可以进入知识库检索"
  ]
}

Data format: RDF-Turtle JSON-LD JSON CSV RDF/XML Markdown RSS Atom

没有通过全部验收条件，就不能把状态改成 passing。

---

2. 进度文件

{
  "last_completed": "完成普通PDF文本提取",
  "current_problem": "扫描版PDF无法获取正文",
  "next_action": "接入OCR回退流程",
  "known_risks": [
    "大文件可能导致请求超时"
  ]
}

Data format: RDF-Turtle JSON-LD JSON CSV RDF/XML Markdown RSS Atom

新 Agent 会话启动时，先读取进度文件，而不是从头猜测。

---

3. 决策日志

决定：扫描版 PDF 使用 OCR 回退机制。

原因：
普通 PDF 解析器无法读取图片中的文字。

替代方案：
纯文本 PDF 继续使用本地解析器，避免增加调用成本。

验证方式：
准备三份纯文本 PDF 和三份扫描 PDF 进行回归测试。

最终可以形成一个很实用的组合：

Markdown 负责解释，JSON 负责状态，Git 负责历史。

---

七、第三根支柱：研究、规划、执行和评估必须分离

很多 Agent 同时承担四个角色：

• 自己理解问题；

• 自己制定方案；

• 自己编写代码；

• 自己判断有没有完成。

这相当于一个学生自己出题、自己考试、自己批卷，最后自己宣布满分。

更加稳定的做法，是把工作拆成不同阶段。

1. Research：先研究，不修改

这一阶段只允许：

• 阅读代码；

• 搜索调用关系；

• 检查数据库结构；

• 分析错误日志；

• 阅读现有测试；

• 查找相似实现。

目标不是立即写代码，而是建立正确的问题模型。

---

2. Plan：先写计划

一个合格的执行计划至少应该回答：

1. 需要修改哪些文件？
2. 每个文件为什么修改？
3. 是否涉及数据库迁移？
4. 是否影响现有接口？
5. 可能破坏哪些旧功能？
6. 准备如何测试？
7. 失败后如何回滚？

审查计划通常比审查几百行代码更便宜。

如果方向错了，在写代码前纠正，只需要修改一份计划。

如果方向错了，但 Agent 已经生成了 500 行代码，后面付出的就不只是删除成本，还包括测试、回滚和重新理解。

---

3. Implement：一次只做一个可验证单元

不要给 Agent 这样的任务：

完成整个招聘匹配系统的优化。

应该拆成：

任务1：修复“至今”工作经历的日期计算
任务2：为日期解析增加单元测试
任务3：验证稳定性评分是否恢复正常
任务4：执行完整候选人评分回归测试

每个任务都应该：

• 范围清晰；

• 可以独立提交；

• 可以独立测试；

• 失败后容易回滚。

---

4. Evaluate：让独立机制判断是否正确

评估不应该完全由执行 Agent 自己完成。

可以使用：

• 单元测试；

• 集成测试；

• 浏览器自动化；

• JSON Schema；

• 数据库状态检查；

• 专门的审查 Agent；

• 人工审批节点。

生成者容易看到“我已经做了很多”，评估者则只关心“验收标准有没有通过”。

---

八、第四根支柱：规则必须机械化，不能只写在文档里

这可能是 Harness Engineering 中最有工程价值的一点。

很多团队的规范是这样的：

请保持代码整洁。
请遵守分层架构。
请不要重复实现。
请保证接口安全。
请完成充分测试。

这些要求都正确，但不可执行。

真正有效的规则，必须转化为机器可以检查的东西：

• Linter；

• 类型检查；

• 架构测试；

• JSON Schema；

• 权限控制；

• CI 流水线；

• 数据库约束；

• 自动化验收测试。

例如，文档中写：

Service 层不能直接操作数据库。

Agent 依然可能忘记。

如果转化为架构检查，反馈就可以变成：

ARCHITECTURE_ERROR: candidate_service.py

问题：
Service 层直接导入 database/session.py。

要求：
UI → Service → Repository → Database

修复方式：
1. 将数据库查询移动到 CandidateRepository；
2. 在 CandidateService 中注入 Repository；
3. 删除 Service 对 Session 的直接依赖；
4. 运行 test_architecture_dependencies.py。

这里有一个非常重要的变化：

传统 Linter 只是告诉开发者“哪里错了”。

面向 Agent 的 Linter 还应该告诉它：

• 为什么错；

• 违反了什么规则；

• 应该修改到哪里；

• 修改后运行什么测试。

换句话说：

Agent 时代的 Linter，不只是检查器，也是一套实时教学系统。

---

九、真正困难的不是“阻止 Agent 做错”，而是“确认 Agent 做对”

当前很多 Agent 系统擅长检查代码形式：

• 是否有语法错误；

• 是否通过类型检查；

• 是否违反目录规则；

• 是否存在危险依赖；

• 单元测试是否通过。

但这些只能证明代码没有明显违反规则。

它们不能完全证明业务结果正确。

例如，一个候选人匹配系统可能所有测试都能运行，但仍然存在以下问题：

• “至今”被计算成一个月；

• 缺失数据被默认填成 0.5；

• 用户设置“年龄不限制”，年龄仍然影响总分；

• must-have 条件被默认配置覆盖；

• 推荐等级和业务人员判断严重不一致。

这类问题只有业务验收测试才能发现。

因此，一个成熟的验证体系至少应该有三层。

第一层：代码正确性

• Lint；

• 类型检查；

• 单元测试；

• Schema 验证；

• 静态安全扫描。

第二层：系统正确性

• API 集成测试；

• 数据库写入验证；

• 服务启动测试；

• 跨模块回归测试；

• 浏览器自动化测试。

第三层：业务正确性

• 真实业务样例；

• 专家标注结果；

• 边界条件；

• 历史故障用例；

• 可解释性检查；

• 业务人员验收。

没有第三层，Agent 很可能生成“技术上能够运行，业务上没有价值”的系统。

---

十、先进团队到底做对了什么

1. OpenAI：工程师不再主要写代码，而是设计环境

OpenAI 曾公开一个极端实验：三名工程师在五个月内构建了约百万行代码的产品，并把“不手写代码”作为实验约束。

这个案例最值得关注的，不是百万行代码，也不是零手写。

真正重要的是工程师工作内容的变化。

当 Agent 卡住时，团队不会立刻接管并手写修复，而是先问：

Agent 为什么无法完成？
是缺少文档，缺少工具，缺少日志，缺少测试，还是缺少明确边界？

如果 Agent 不知道如何启动项目，就增加启动脚本。

如果 Agent 经常违反架构，就增加结构测试。

如果 Agent 看不到页面问题，就接入浏览器和 DOM。

如果 Agent 产生大量低质量代码，就增加周期性的清理任务。

工程师从“亲自实现功能”，逐渐转向“设计一个让 Agent 能可靠实现功能的环境”。

---

2. Anthropic：多 Agent 的关键不是数量，而是专业化

在 C 编译器项目中，多个 Agent 并行工作，最终生成了大规模 Rust 代码，并通过大量编译测试。

但这个案例真正有价值的地方，不是“16 个 Agent 很厉害”。

而是随着项目复杂度提高，不同 Agent 开始承担不同角色：

• 核心编译器实现；

• 代码去重；

• 性能优化；

• 代码质量；

• 文档维护。

其中“去重 Agent”尤其值得注意。

LLM 很容易重新实现已经存在的功能。因为它关注当前任务，不一定能意识到相同能力已经在其他模块中出现。

因此，当代码生成速度变快后，去重和清理必须成为正式工作流，而不能等人类偶尔发现。

---

3. Stripe：无人值守的前提，是基础设施足够成熟

Stripe 的 Agent 可以从接收任务开始，自动修改代码、运行测试、处理 CI，最后提交 PR。

这种无人值守模式看起来很诱人，但它建立在一整套成熟基础设施上：

• 标准化开发环境；

• 大量内部工具；

• 严格权限隔离；

• 完整 CI；

• 明确的任务入口；

• 最终人工审查。

所以，无人值守不是因为 Agent 天生值得信任。

恰恰相反，是因为系统已经通过 Harness 把可变行为限制在可接受范围内。

---

十一、为什么 Agent 系统需要“垃圾回收”

当 Agent 生成代码的速度提高十倍，技术债产生速度也可能提高十倍。

常见问题包括：

• 重复工具函数；

• 同一业务规则存在多个版本；

• 文件越来越大；

• 文档和代码不一致；

• 已废弃接口仍然被调用；

• 测试覆盖逐渐下降；

• 架构边界不断被绕过；

• 大量临时补丁永久留下。

传统团队可能每季度做一次重构。

但在高吞吐量 Agent 系统中，清理工作必须和代码生成同步进行。

可以建立周期性的“垃圾回收 Agent”，专门检查：

1. 是否存在重复实现；
2. 是否出现超大文件；
3. 文档是否已经过期；
4. 是否违反模块依赖方向；
5. 是否存在未使用接口；
6. 是否有长期未处理的 TODO；
7. 是否存在无测试的新模块；
8. 是否出现新的坏模式。

这里需要注意：清理 Agent 不能只依靠主观判断。

它必须依据明确规则、质量指标和自动测试，否则只是让一个模型用自己的偏好改写另一个模型的代码。

---

十二、三个最容易误解的地方

1. Harness 重要，不代表模型不重要

更准确的说法是：

模型能力决定理论上限，Harness 决定能力能否被稳定释放。

弱模型配上强 Harness，不会自动拥有复杂推理能力。

强模型配上弱 Harness，也可能因为工具失败、上下文污染和验证不足而表现糟糕。

---

2. 多 Agent 不一定比单 Agent 更好

多 Agent 适合：

• 任务可以独立拆分；

• 子任务依赖较少；

• 每个角色边界清晰；

• 结果可以自动验证；

• 系统具备冲突处理机制。

如果多个 Agent 都在修改同一个核心模块，或者依赖同一个阻塞问题，增加 Agent 数量只会带来：

• 重复劳动；

• 代码冲突；

• 上下文不一致；

• 修复结果互相覆盖。

多 Agent 的本质不是多开几个聊天窗口，而是任务能否被拆成低耦合、可独立验收的工作单元。

---

3. “零手写代码”不是所有团队都应该追求的目标

零手写代码可以用来验证 Agent 和 Harness 的能力边界，但不应该成为形式主义指标。

真正需要关注的是：

• 交付速度是否提高；

• 功能是否正确；

• 维护成本是否可控；

• 故障率是否下降；

• 团队知识是否得到沉淀；

• 系统是否能够长期演进。

代码是不是人亲手输入的，并不是最终价值。

---

十三、从零搭建 Harness，最应该先做什么

不要一开始就搭建复杂的多 Agent 平台。

一个普通团队可以按照以下顺序推进。

Level 1：基础可用

先建立：

• AGENTS.md；

• 标准启动脚本；

• 基础 Linter；

• 单元测试；

• Git 提交规范。

目标是让 Agent 能够正确启动项目，并遵守最基本规则。

---

Level 2：形成反馈回路

增加：

• CI；

• 自动回归测试；

• feature_list.json；

• progress.json；

• 明确完成标准；

• 错误后的自动反馈。

目标是让 Agent 不只是生成代码，而是根据验证结果持续修复。

---

Level 3：任务专业化

增加：

• 研究 Agent；

• 规划 Agent；

• 执行 Agent；

• 审查 Agent；

• 清理 Agent；

• 分层上下文。

目标是降低单个 Agent 的上下文负担，让不同角色专注于不同问题。

---

Level 4：有限自治

进一步增加：

• 隔离开发环境；

• 权限控制；

• 自动任务调度；

• 可观测性；

• 自动恢复；

• 周期性熵管理；

• 人工审批门槛。

只有达到这一阶段，才适合逐步尝试无人值守任务。

---

十四、未来最值钱的能力，不一定是写代码

Harness Engineering 暗示了一个非常明显的职业变化。

未来的软件工程师不会停止写代码，但高价值工作会逐渐向上迁移：

过去关注：

• 如何实现一个函数；

• 如何完成一个接口；

• 如何写出一段页面逻辑。

未来更关注：

• 如何定义清晰的任务；

• 如何组织 Agent 上下文；

• 如何把架构规则变成自动约束；

• 如何设计验证体系；

• 如何让失败转化为系统资产；

• 如何让多个 Agent 安全协作；

• 如何控制 AI 生成代码的长期熵增。

这不是工程能力被削弱了。

恰恰相反，工程要求变得更高了。

因为当代码生成成本快速下降后，真正稀缺的就不再是“把代码写出来”，而是：

判断应该写什么、如何验证、如何约束，以及如何让系统长期保持正确。

---

十五、总结：不要重复纠正 Agent，要改造 Agent 的工作环境

Harness Engineering 最重要的价值，不是提出了一个新术语，而是改变了我们理解 Agent 的方式。

Agent 不是一个只要写好 Prompt 就能可靠工作的超级员工。

它更像是一个能力很强，但需要外部记忆、明确边界、持续反馈和自动验证的执行引擎。

真正成熟的 Agent 工程，应当遵循四条原则：

第一，不要试图通过一个完美 Prompt 获得长期可靠性。

第二，不要把项目记忆留在聊天窗口，要把状态保存到文件、数据库和 Git 中。

第三，不要只告诉 Agent 应该怎么做，还要让系统自动判断它有没有做对。

第四，不要反复人工纠正同一种错误，要把错误转化成文档、测试、规则或工具。

同一种问题第一次发生，可以认为是 Agent 的错误。

第二次发生，通常就是 Harness 的错误。

模型会继续变强，代码生成速度也会继续提高。但模型越强、权限越大、执行范围越广，系统越需要清晰的边界和可靠的反馈。

所以，Agent 时代真正的工程分水岭，不是谁能调用最强的模型，而是谁能建立一套让模型长期、稳定、可验证地工作的系统。

这才是 Harness Engineering 真正值得学习的地方。

---

参考资料

1. OpenAI：Harness engineering: leveraging Codex in an agent-first world

2. Anthropic：Effective harnesses for long-running agents

3. Anthropic：Building a C Compiler with Claude

4. Martin Fowler：Harness Engineering

5. Martin Fowler：Context Engineering for Coding Agents

6. Mitchell Hashimoto：My AI Adoption Journey

7. Stripe：Minions: Stripe's one-shot, end-to-end coding agents

8. Dex Horthy：Advanced Context Engineering for Coding Agents