你有没有经历过这个场景：让一个 AI Agent 去改个 bug，它倒是改了，顺手”优化”了三个不相关的文件，删了一段它没看懂但实际很重要的注释，最后告诉你”任务完成”。

你看着 diff，陷入了沉默。

这不是个笑话。这是 Andrej Karpathy 在 X 上吐槽过的真实痛点。他说 LLM 模型会在你没有意识到的情况下做出错误假设，然后一路狂奔，不去管理自己的困惑，不主动澄清歧义，不暴露矛盾，不呈现 tradeoff，该 push back 的时候也不 push back。更糟糕的是，它们喜欢过度设计，100 行能搞定的事情，它能给你膨胀到 1000 行。

这就是为什么 2026 年出现了一个新词：Harness Engineering（约束工程）。核心公式只有一个：

Agent = Model + Harness

模型你控制不了，但 harness 可以。两个团队用同一个 Claude 或 GPT 模型，任务完成率可以是 60% vs 98%，差别完全在 harness 的质量。

这篇文章讲的就是 harness 怎么设计。不是概念空谈，而是三层纪律框架：流程管控、并发调度、验证纠错。每一层都有已经跑通的项目案例和具体实现。

第一层：流程管控 —— 结构先于执行

流程管控要解决的核心问题是：让 Agent 的执行路径是确定的，而不是概率性的。

Archon：用 YAML 写 AI 工作流

Archon（17,620 stars）自称是”第一个开源的 AI coding harness builder”。它的做法很直接：用 YAML 定义开发流程，就像 Dockerfile 定义基础设施、GitHub Actions 定义 CI/CD 一样，Archon 定义 AI 编码工作流。

它把节点分成四种类型：

• AI 节点：prompt 驱动的推理（分析需求、生成代码、写 PR 描述）
• 确定性节点：bash 脚本、git 操作（运行测试、lint、提交）
• 循环节点：迭代直到满足条件（测试失败就重试）
• 交互节点：暂停等待人工审批

看一个典型的 plan → implement → test → review → PR 工作流：

nodes:
 - id: plan
   prompt: "Explore the codebase and create an implementation plan"
 - id: implement
   depends_on: [plan]
   loop:
     prompt: "Read the plan. Implement the next task. Run validation."
     until: ALL_TASKS_COMPLETE
     fresh_context: true
 - id: run-tests
   depends_on: [implement]
   bash: "bun run validate"
 - id: review
   depends_on: [run-tests]
   prompt: "Review all changes against the plan. Fix any issues."
 - id: approve
   depends_on: [review]
   loop:
     prompt: "Present the changes for review. Address any feedback."
     until: APPROVED
     interactive: true
 - id: create-pr
   depends_on: [approve]
   prompt: "Push changes and create a pull request"

这不是玩具。Archon 内置了 17 个默认工作流，从 archon-idea-to-pr（想法到 PR 的完整链路）到 archon-comprehensive-pr-review（5 个并行审查员 + 自动修复），覆盖了日常开发的绝大多数场景。每个工作流运行在独立的 git worktree 里，可以并行跑 5 个任务不冲突。（该项目在 2026-04-07 刚完成从 Python 到 TypeScript 的完全重写，从任务管理器转型为工作流引擎。）

核心设计哲学是：混合 AI 节点和确定性节点，AI 只在有价值的地方运行。跑测试、lint、提交这些不需要 AI 做决策的事情，交给 bash 脚本。

get-shit-done：spec-driven 的结构化周期

get-shit-done（52,111 stars）走的是另一条路。它的标准周期是：discuss → plan → execute → verify → ship。

每个阶段都有明确的输入输出：

• discuss 阶段捕获实现偏好，分析灰色地带，输出 CONTEXT.md
• plan 阶段创建 2-3 个原子任务计划，验证是否符合需求，循环直到通过
• execute 阶段是重点——后面讲并发调度时会展开
• verify 阶段提取可测试的交付物，逐项验证，自动诊断失败

GSD 解决的痛点叫 context rot——随着上下文窗口填满，LLM 输出质量会退化。它的做法是每个任务用全新的 200k token 上下文窗口执行，零累积垃圾。

Anthropic 的 Initializer Agent 模式

Anthropic 在长程 Agent 工程实践中提出了一个类似的思路：Initializer Agent + Coding Agent 双模式。

Initializer Agent 第一个进场，负责建立环境：写 init.sh、创建 feature_list.json（标记所有功能为 failing）、初始化 claude-progress.txt、做初始 git commit。后续的 Coding Agent 只做增量进展，每次 session 结束前留下结构化更新。

这三个项目的共同点只有一个：结构先于执行。没有结构的 Agent 就像没有 Dockerfile 的部署——能跑，但没人敢在生产环境用。

第二层：并发调度 —— 隔离、并行、上下文纪律

单个 Agent 跑通了，下一步是多 Agent 协作。这里的核心难题是：怎么让多个 Agent 同时干活，又不互相踩脚？

GSD 的 Wave 执行模型

GSD 的并发调度用的是 Wave 模型。它先分析任务依赖，然后把独立的任务分到同一个 wave 并行执行，有依赖的任务放到后面的 wave。

PHASE EXECUTION
├── WAVE 1 (parallel)    WAVE 2 (parallel)    WAVE 3
│   Plan 01 │ Plan 02    Plan 03 │ Plan 04    Plan 05
│   User    │ Product    Orders  │ Cart       Checkout
│   Model   │ Model      API     │ API        UI

Plan 03 依赖 Plan 01，所以不能放同一个 wave。Plan 05 依赖 Plans 03 和 04，所以排在最后。这个模型的本质是拓扑排序 + 依赖分组。

更关键的是，每个 plan 执行时用的是全新的 200k token 上下文窗口。这就是所谓的”上下文纪律”——不让 Agent 带着前一个任务的垃圾进下一个任务。

Archon 的 worktree 隔离

Archon 的并发方案更底层：每个工作流运行在独立的 git worktree 里。5 个 Agent 同时改 5 个分支，互不干扰，完成后合并。

这种方式的好处是天然可并行、天然可回滚。一个 Agent 搞砸了，删掉那个 worktree 就行，不影响其他 Agent 的工作。

为什么 Orchestrator 不干活

GSD 有个很有意思的设计原则：Orchestrator 不干活。它只负责生成 Agent、等待、整合结果。主上下文窗口保持在 30-40% 使用率，不会越填越多。

这和 Martin Fowler 在 Harness Engineering 文章里提到的观点一致：好的 harness 应该像一个好的 CI/CD pipeline，orchestrator 只负责路由和状态管理，实际工作交给专门的 executor。

第三层：验证纠错 —— 验证先于提交

流程有了，调度有了，最后也是最关键的一层：怎么知道 Agent 做对了？

Karpathy 的 Goal-Driven Execution

回到整理自 Karpathy 观察的那份 CLAUDE.md 合集（forrestchang/andrej-karpathy-skills，17,019 stars）。他将 LLM 编码行为的约束浓缩为四个原则：

原则	解决的问题
Think Before Coding	错误假设、隐藏困惑、缺少权衡分析
Simplicity First	过度设计、膨胀的抽象
Surgical Changes	无关修改、破坏性副作用
Goal-Driven Execution	模糊指令导致反复沟通

其中 Goal-Driven Execution 是最有工程价值的。Karpathy 的原话是：

“LLMs are exceptionally good at looping until they meet specific goals… Don’t tell it what to do, give it success criteria and watch it go.”

“添加验证”是一个模糊的命令式指令。把它改成”为非法输入编写测试，然后通过”——这就是一个可验证目标。Agent 知道自己要做什么，你也知道怎么判断它做对了。

效果检验标准也很工程化：diff 中不必要的变更更少、因过度设计导致的重写更少、澄清问题出现在实现之前、简洁的 PR 没有附带的重构。

GSD 的 Gate 系统

GSD 把验证做成了一个完整的 Gate 分类系统，包含 4 种 canonical gate 类型：

• pre-flight：执行前的前置检查
• revision：验证失败后的修复流程
• escalation：无法自动修复时升级
• abort：判定为不可行时中止

它还能检测 schema drift（ORM 变更缺少 migration）、范围缩减（规划器悄悄删需求）、静默丢弃的 hunks（三向合并后 patch 验证）——这些都是实际开发中 Agent 最容易翻车的地方。

Anthropic 的端到端验证

Anthropic 的方案更狠：用浏览器自动化工具做端到端测试，通过后才标记功能为 passing。feature_list.json 初始化时所有功能标记为 failing，Agent 修一个、测一个、通过一个、标记一个。

配合 claude-progress.txt 做跨 context window 的状态桥梁，就算 Agent 的上下文窗口被重置了，它也能从进度文件里恢复状态。

RMAX 的 Harness 五核心组件

RMAX 把验证纠错总结为 harness 的五个核心组件：

1. Loop Controller — 设置迭代预算和停止条件，防止无限重试和”死亡螺旋”
2. Tool Gateway — 最小权限（默认拒绝），工具能力整形
3. Verifier — 将主观”看起来对”转为客观 pass/fail
4. Retry Policy — 区分瞬态失败和确定性失败，要求重试之间改变策略
5. Tracing & Artifacts — 捕获工具调用、决策、中间文件和结果

他们用这套方法在 Terminal Bench 2.0 上把 deepagents-cli 从 52.8 提升到 66.5，没有更换模型，纯 harness 改进。

Martin Fowler 的 Feedforward + Feedback 双层控制

Martin Fowler 在 Harness Engineering 文章里提出了一个更抽象的框架：Feedforward（事前引导）+ Feedback（事后反馈）双层控制。

计算型任务（代码规范、类型检查、linter）适合 feedforward——提前定好规则，让 Agent 照着做。推理型任务（架构决策、代码审查）更适合 feedback——做完之后用 AI 审查或语义判断来验证。

只用 feedback，Agent 会重复同样的错误。只用 feedforward，你永远不知道规则是否有效。两层结合才行。

他还提出了 harness 的三个监管维度：

• Maintainability harness — 内部代码质量，现有工具最多，最容易构建
• Architecture fitness harness — 架构适应度函数，性能要求、可观测性标准
• Behaviour harness — 功能行为正确性，最大挑战，目前依赖 AI 生成测试 + 人工测试

最后一个维度他提到了一个有趣的概念：Harnessability——不是每个代码库都同样容易”被套住”。强类型语言天然有类型检查传感器，遗留系统技术债重，最需要 harness 的地方反而最难构建。

实践建议：给你的 Agent 加约束

如果你现在就要给团队里的 AI Agent 加约束，按这个优先级来：

立即可做的（今天就能开始）

1. 写一个 CLAUDE.md 或 AGENTS.md。参考 Karpathy 的四原则，定义你的编码规则。不需要完美，先有一个比没有强 100 倍。
2. 给 Agent 写 init.sh。让它知道怎么跑起来。这是 Anthropic 的 Initializer Agent 模式的最小化版本。
3. 把命令式指令改成可验证目标。”加个缓存”改成”加缓存，QPS 从 100 提升到 500，测试通过”。

短期可做的（一周内）

1. 用 Archon 或 GSD 的 YAML/spec 定义你的核心工作流。从最常用的场景开始，比如 PR review 或 bug fix。
2. 加一个 feature_list.json。追踪 Agent 完成了什么、没完成什么。
3. 设置迭代预算。Loop Controller 防止 Agent 在同一个问题上死循环。

中期可做的（一个月内）

1. 构建 Behaviour harness。为你的核心功能编写自动化测试，让 Agent 的每次修改都有验证标准。
2. 实现 Gate 系统。pre-flight 检查、revision 修复、escalation 升级、abort 中止。
3. 加上 Tracing & Artifacts。记录 Agent 的每次决策，方便复盘和调试。

结语：约束不是限制，是赋能

2026 年有两个数据值得记住：

• Stripe 用 fork 的 Goose harness，每周合并 1,300 个 AI 生成的 PR，零人工编写代码（但保留人工审查环节），月均 5,000+ 合并 PR。
• OpenAI 用 Codex 构建了超过 100 万行代码的生产应用，零行由人类编写。

它们的共同点不是用了更好的模型，而是设计了更好的 harness。

模型能力在收敛——Anthropic Claude、OpenAI GPT、Google Gemini 的能力差距在缩小。2026 年的差异化竞争点不在模型，在 harness 设计。

约束不是限制 Agent 的能力，而是让它的能力可预测、可重复、可信赖。这就是从玩具到工具的区别。

玩具偶尔能给你惊喜。工具每次都能给你结果。