先说个真实的数字。
群里某位朋友最近跟我吐槽：他组里一个 senior 工程师，这个月 Claude Opus 的账单已经烧了 2700 美元。不是因为他用了什么高级功能，就是字面意义地在那儿让 AI 写代码。日均 2-3 亿 token 的消耗，已经成了他们团队的常态。
然后你猜怎么着？他们的部署故障率反而比去年同期高了。
这不是孤例。根据某 Harness 工具厂商的内部数据，AI 编程重度用户（heavy users）的部署故障率比传统开发流程高出 69%。不是降低，是提高。
这个数字让很多人懵了。代码写得更快了，怎么交付反而更慢了？
答案很简单，但大多数人都没反应过来：你的 Agent 很聪明，但你的系统很蠢。
Martin Fowler 年初发过一篇文章，里面有个公式我认为是 2026 年关于 AI 编程最准确的定义：
Agent = Model + Harness
Model 是大脑，Harness 是神经系统。大多数人还在纠结"选哪个模型"，但真正的竞争已经转移到了"谁能把 Harness 设计的更好"。
这就是今天要聊的主题——Harness Engineering：AI 编程的下一个范式。
问题：你的 Agent 很聪明，但你的系统很蠢
回到那个 69% 的数字。
2024 年到 2025 年初，所有人都在为 AI 编程的承诺买单：给开发者配上 coding agent，velocity 翻 2-3 倍不是梦。数字也确实上去了——代码产出肉眼可见地快，PR 合并的速度让老板眉开眼笑。
但然后呢？
下游的成本把收益全部吃掉了。代码写得更快的代价是更多集成失败、更多生产环境故障、更多时间花在调试那些"语法完全正确但架构一塌糊涂"的 AI 生成代码上。
群里做 QA 的朋友说了一句很经典的话："我其实已经是 QA 了，Agent 写完代码我来测试。"——他不是在抱怨，是在描述一个普遍的现实：当你把代码生产的速度提高 3 倍，质量保证的基础设施没有跟上，那个速度反而成了负担。
速度悖论：代码写得更快，交付反而更慢。
这不是模型的问题。Claude 3.5 Sonnet、GPT-4o、o1/o3，每一代模型都在进步。问题在于，把模型变强解决不了"系统设计"的问题。你可以把 1.0 版本的引擎装进任何车，但如果没有转向、没有刹车、没有仪表盘，你只是在一台无法控制的赛车里以更快的速度撞墙。
Harness 就是那套转向刹车仪表盘。它不是优化项，是必选项。
什么是 Harness Engineering？（不是又一个 Buzzword）
Harness Engineering 是 AI agent 系统中除了模型本身之外的所有东西的刻意设计。
这个定义比很多人理解的"prompt engineering"或"context engineering"更宽泛：
- Prompt Engineering：关注模型的输入——怎么问问题、怎么给指令
- Context Engineering：关注模型能看到什么——RAG、上下文窗口管理、memory
- Harness Engineering：关注整个 scaffold——agent 能做什么、怎么做、怎么衡量成功
用一个汽车的类比来说：
- Model = 发动机。马力越大越好，但一台 1000 马力的发动机装在没有方向盘、刹车、仪表盘的车里，只能让你以更快的速度撞墙
- Context = 燃料。好燃料让发动机跑得更顺，但你优化燃料一整天，车还是不会自己开
- Harness = 方向盘、刹车、仪表盘、悬挂、安全系统。这就是把原始发动机动力转化为有方向运动的东西
所以一个完整的 Harness 包括：
- 工具定义（tool definitions）和编排逻辑——什么时机调用什么工具
- 成功标准，表达为可验证的约束，而非角色描述
- 反馈机制——检测 drift 并触发纠正
- 状态管理——让长时任务保持一致性
- 多 agent 协调协议
区分这些很重要。那些把 Harness Engineering 当作事后来做（"我们有 harness 了"——其实只是加了点 prompt template）的团队，最终得到的 agent 很强大但是漫无目的——产生了大量活动但没有有用的产出。
一个最简化的 harness 配置长这样——一个 AGENTS.md 文件，定义了 agent 的约束环境：
# AGENTS.md — Harness 配置
## 成功标准
- 所有函数必须有类型标注
- 提交的代码中不允许有 TODO 注释
- 所有新函数的圈复杂度低于 15
- 所有公开 API 必须有文档字符串
## 约束
- 禁止使用 `as any` 或 `@ts-ignore`
- 禁止用空的 catch 块压制错误
- 新文件必须遵循现有目录约定
## 验证
- 提交前运行 `npm run lint`
- 提 PR 前运行 `npm test`
- 所有 PR 必须通过 CI 才能合并
## 上下文管理
- 搜索文件前先读 WORKSPACE.md
- 遵循代码库中的现有模式
- 不确定时主动询问
注意，这不是 prompt——这是约束规格。Agent 不需要"记住"这些规则，因为 linter 和 CI 会自动验证它们。关于 Harness 的历史渊源，可以看之前的 Harness Engineering 完全指南，那篇从珍妮纺纱机讲到现代 AI 系统。
三个维度 Scaling 框架
每个 AI coding agent 系统都会遇到 scaling 问题。而且这些问题不是因为模型，是因为模型周围的基础设施。
研究完 Anthropic、Cursor、OpenAI 和其他几十个组织的生产部署，一个清晰的模式浮现出来：Scaling 问题可以归结为三个维度，每个维度需要完全不同的架构方法。
三个维度
1. 时间 Scaling（Time Scaling）—— 如何让单个 agent 在长时间跨度内保持高效？
问题不是智能，是连贯性。连续工作 4 小时后，agent 开始失去对原始目标的追踪，追求那些加在一起也无法产生有意义进展的子任务，或者重复同样的错误模式而不自知。
时间 scaling 的关键是：在扩展执行过程中保持方向感。
2. 空间 Scaling（Space Scaling）—— 如何协调多个 agent 同时处理同一个问题？
naive 的做法——共享状态、共享 context——在 agent 数量增加时迅速退化。Cursor 在 20 个并发 agent 时就碰到了瓶颈。协调开销的增长速度快于并行性的收益。
空间 scaling 的关键是：当你增加 agent 时保持吞吐量。
3. 交互 Scaling（Interaction Scaling）—— 如何在不逐个写 prompt 的情况下操控大量 agent？
如果你有 500 个 agent，却要给每个 agent 单独写指令，你没有 scale——只是把瓶颈移动了位置。
交互 scaling 的关键是：在系统层面指定意图，让 agent 自我组织。
三家公司分别解决了什么问题
本文三家公司分别独立解决了这三个维度：
- Anthropic → 时间 Scaling
- Cursor → 空间 Scaling
- OpenAI → 交互 Scaling
这不是巧合。Anthropic 的主要用例是单个 Claude Code 实例跑几小时做大型重构，所以时间问题是他们第一个遇到也是第一个解决的。Cursor 面对的是"我们想让 100 个 agent 同时在同一个 codebase 上工作"的问题，所以空间问题是核心。OpenAI 的 agent 团队有 3 个人要推动 1500 个 PR，必须用系统级约束而不是人肉管理，所以交互 scaling 是关键。
但框架是通用的——每个 AI coding 系统在 scale 过程中都会遇到全部三个维度。
时间 Scaling：Anthropic 怎么让一个 Agent 连跑 4 小时不跑偏
Drift 问题是每个长时运行 agent 都会遇到的第一个坎。
让一个 agent 重构一个 5 万行的巨石应用，单 session 搞定——听起来很美好。但可预测的事情发生了：大约 2-3 小时后，agent 开始做出"局部连贯但全局矛盾"的决策。它失去了对原始架构目标的视野，把模块 A 重构成跟模块 C 不兼容的样子，引入了那些孤立看正确但放到上下文里就错误的设计模式。
2025 年初的标准解决方案是 self-reflection：让 agent 定期停下来问自己"我还在线吗？"这不管用。
Agent 是自身连贯性的糟糕评判者，因为它们没有外部 ground truth。它们看不见自己在 codebase 里已经改了什么——只能看见当前在做什么。
Anthropic 的解法：独立的 Evaluator Agent
Anthropic 给 Claude Code 的方案是一个通过 Playwright 操作运行中应用的独立 Evaluator agent。
架构把 Harness 分为两个完全隔离的组件：
- Generator——做实际代码工作的 agent。接收 context、写代码、提出变更
- Evaluator——与 Generator 共享零内部状态的独立 agent。通过 Playwright 观察运行中的应用，点击 UI，检查预期行为是否存在，向 Generator 报告失败
Evaluator 不知道 Generator 想干嘛。它只知道成功标准："当我点击这个按钮，这个 modal 应该出现。"如果 modal 没出现，它标记一个失败。Generator 用那个失败信号来纠正航向，而不需要理解为什么失败。
这个分离有效，因为 Evaluator 和 Generator 共享零内部状态。Generator 不能"幻觉"一个 modal 没出现的借口。Evaluator 不能被 Generator 的自评操控。它们之间唯一的共享产物是运行中的应用本身。
Auto-Dream 机制：后台记忆整理
Anthropic 还实现了一个内部叫 auto-dream 的机制：一个在空闲周期运行的后台记忆整合进程。
当 agent 不在活跃接收用户输入时，它会回顾最近的 action 历史，提取关于什么有用、什么没用的顶层原则。这受生物系统里睡眠巩固的启发——大脑回放一天的经历，巩固模式。
推测执行和 Pipelining
Claude Code 还用了一个很少有人提到的优化：推测执行（speculative execution）和 pipelining。
不是等上一个任务彻底完成才提交变更，而是让 agent 在"看起来对"的假设下继续推进。如果最后验证失败，回滚的成本比串行执行低得多。这类似于 CPU 的 pipeline 架构——不要让流水线停下来等确认，而是保持吞吐。
核心洞察：时间 scaling 的本质是"如何在长时间尺度上保持方向感"。Anthropic 的答案是外部化评估——把判断留给独立于生成者的 Evaluator。自我评估永远不会准，因为 agent 无法看见自己的全局状态。
空间 Scaling：Cursor 的四次架构迭代
Cursor 面对的问题正好相反：不是长时间单个 agent 的方向保持，而是短时间大量 agent 的吞吐量。
他们的 use case 很明确：同一个 codebase 上同时跑 100 个 agent，峰值 1000 commits/hour。要做到这个，他们花了四次架构迭代。
第一版：平等 Agent + 共享状态文件
最初的设计是经典的"大家都是平等的 agent"，通过共享状态文件来协调。听起来简单直观。
结果：当 agent 数量超过 20 个时，系统彻底崩溃。不是慢慢退化——是断崖式下跌。20 个 agent 的吞吐量退化到了 1-3 个的水平。
问题在于共享状态文件。当 20 个 agent 同时读写同一个文件，冲突和锁等待成了主导因素。并行性的收益被协调开销完全抵消。
群里做过这个的开发者回忆说：当时觉得"不就是共享状态嘛，加个锁就好了"。后来发现，锁的粒度太粗就变成串行，太细又有一致性问题，而且 agent 的决策依赖的上下文和实际 filesystem 状态之间会产生微妙的 race condition，根本没法通过简单加锁解决。
第二版：消息队列
第二版引入了消息队列——agent 之间不直接通信，而是通过一个中心队列来协调任务分发。
这个方案解决了共享状态的问题，但也引入了新的问题：协调开销。队列本身成了瓶颈。当 agent 数量增加，队列的进出调度复杂度以超线性的速度增长。
结果是：比第一版好，但没好多少。吞吐量依然无法 scale。
第三版：事件溯源
第三版尝试了事件溯源（Event Sourcing）：所有操作都记录为不可变的事件，通过事件回放来重建状态。
这个方案有优雅的一面——最终一致性保证了永远可以回到任何历史状态。但复杂性问题随之而来：当需要"当前状态的一个一致视图"时，事件回放的代价非常高。而且状态冲突的解决需要复杂的业务逻辑，这个逻辑本身又引入了新的 bug 来源。
第四版：递归 Planner-Worker
最终版是递归 Planner-Worker 架构，峰值做到了 1000 commits/hour。
核心设计：Worker 完全隔离在独立 repo 副本中。
Planner agent 负责任务分解，把大的工作单元拆成小的可执行任务。每个 Worker 拿到的是一个完整的、与其他 Worker 隔离的 repo 副本。它在副本上工作，提交 commit，然后通过一个合并层把变更同步回主分支。
关键洞察：协调开销以二次方速度增长，隔离才是答案。当 agent 之间不共享任何内部状态，只通过 commit 来交流时，协调成本从 O(n²) 降到了 O(n)。
为什么有效：隔离 + 分层
Cursor 第四版的核心教训是：不要试图减少协调（coordination），而是消除协调（coordination）。
当 Worker 在完全隔离的环境中工作时，它不需要跟任何人协调。它只需要在完成后提交一个 commit。Planner 负责解决冲突——但 Planner 只在 commit 层面工作，不在执行层面。
这个模式和版本控制的核心思想一致：分支隔离开发，通过 merge/pull request 来协调。Git 能 scale 到 thousands of contributors，就是因为每个 contributor 都在独立工作，不需要实时协调。
交互 Scaling：OpenAI 的 Symphony 和工单驱动的 Agent
OpenAI agent 团队面对的问题又不一样。他们只有 3 个人，却要在 5 个月内合并 1500 个 PR。
这不是一个"提高单 agent 效率"的问题——你需要操控大量的 agent 行为，而不可能给每个 agent 单独写 prompt。
他们的方案很有意思：Symphony，一个基于 Elixir/BEAM 构建的 agent 协调系统，加上 Linear 作为 job scheduler。
BEAM 的选择
BEAM（Erlang 虚拟机）是为电信级并发设计的——数万甚至数十万并发连接，99.999% 的可用性要求。OpenAI 选择它不是炫技，是因为他们的 agent 系统需要类似的可靠性：大量并发的 agent 任务，不能因为一个 agent 崩溃影响全局。
Linear 作为 Agent 的 Job Scheduler
关键设计：工程师写工单，移动状态。
不是给 agent 写指令，而是通过 Linear 的 ticket 状态来传达意图。Agent 看到的是一个工单队列，它自己 pick up 工单、执行、提交 PR、附上 proof of work（CI 结果、复杂度分析、walkthrough 视频）。
Proof of Work 是关键。每个 PR 必须附上 CI 通过的证据、代码复杂度分析、还有演示修改效果的短视频。这就是 harness——不是人肉审核，而是自动化验证。
结果
3 人团队，5 个月，1500 个 PR 合并。
这不是 10x engineer，这是 100x harness。
为什么有效：用约束来规范 Agent
群里有人总结了 OpenAI 方案的核心洞察：用约束代替指令。
自定义 linter 强制架构不变量，lint 错误信息就是修复指引。Agent 看到 linter 报错，不需要理解"为什么这样不好"，只需要修复错误。错误信息本身就是修复指令——不需要人肉 prompt。
这和 Cursor 的"no TODOs, no partial implementations"哲学一致。与其告诉 agent"记得完成后清理"，不如让编译器报 error："你还有未实现的 partial function"。
约束可验证，指令有歧义。这是三个公司方案的共同核心。
三家公司的共识：约束比指令有效
把三个案例放在一起看，一个清晰的模式浮现出来。
OpenAI 的做法
自定义 linter 强制架构不变量。当 agent 提交不符合架构规范的代码，CI 会 fail。错误信息不是"你违反了架构原则"，而是具体的"在 module X 中，函数 Y 应该在 Z 层，不应该被 A 调用"。
Lint 错误信息 = 修复指引。Agent 不需要理解架构哲学，只需要修 linter error。
一个简化版的跨域 import 约束规则长这样：
// custom-lint-rules/no-cross-domain-imports.js
module.exports = {
create(context) {
const domainPattern = /src\/(auth|billing|catalog)\/.*/;
return {
ImportDeclaration(node) {
const sourceFile = context.getFilename();
const importPath = node.source.value;
const sourceDomain = sourceFile.match(domainPattern)?.[1];
const importDomain = importPath.match(domainPattern)?.[1];
if (sourceDomain && importDomain && sourceDomain !== importDomain) {
context.report({
node,
message: `跨域导入: ${sourceDomain} → ${importDomain}。` +
`请使用 ${importDomain} 的 API 接口。` +
`修复: 将此 import 替换为 ${importDomain}/api.ts 中的调用`
});
}
}
};
}
};
注意错误信息不只是说"别这样做"——它告诉 agent 具体怎么修。这就是约束驱动设计：linter error 本身就是指令。
Cursor 的做法
"no TODOs, no partial implementations"是一套硬约束，不是一个建议。当 agent 尝试提交未完成的代码，pull request 会自动被标记为 draft 或者直接被 CI 挡住。
比起告诉 agent"remember to finish your implementation before submitting"——这是模糊的指令——"你的 CI 会在未实现方法处 fail"是硬的事实。
Anthropic 的做法
约束交付物，而非过程。当 Generator 完成任务，Evaluator 会检查运行结果是否符合成功标准。Generator 不知道 Evaluator 会检查什么——它只知道"如果应用不工作，Evaluator 会报 failure"。
这强迫 agent 自己找路径，而不是按指令亦步亦趋。
群里宝玉的实践
宝玉（群里某位 AI 实践者）说过一句话很到位："我其实已经是 QA 了，Agent 写完代码我来测试。"
但他和传统 QA 不一样的是——他没有在测试流程里手动找 bug。他的工作变成了"设计 Evaluator"：定义什么是"工作正常"，让自动化去验证。
人的角色从测试者变成了 harness 设计者。这是 AI 编程时代工程角色的转变。
结论
约束有效是因为： 1. 可验证：编译器会报错，CI 会 fail，Playwright 会检测到 modal 没出现 2. 无歧义：错误就是错误，不需要理解意图 3. 可组合：多个约束可以叠加，不需要彼此了解
指令的弱点正好相反： 1. 难以验证：你怎么知道 agent"真的理解"了指令？ 2. 有歧义：同一个指令，不同模型、不同上下文，理解可能完全不同 3. 脆弱：一旦情况变化，指令可能不再适用
模型更强了，Harness 就更薄了吗？
一个自然的疑问：如果模型足够强，是不是就不需要复杂的 harness 了？
Anthropic 的经验给出了一些答案。Opus 4.6 的能力确实让一些 sprint 结构变得不必要——之前需要显式设计的子任务分解，现在模型可以自主完成。
但是。
300-500 步的问题依然存在。在这个尺度上，误差逐级放大，人工干预的速度跟不上 agent 出错的速度。
Google 和 MIT 的联合研究数据很有意思：独立 agent 之间的错误放大 17.2 倍——当多个 agent 各自为战时，一个错误会级联放大。但如果加入协调者角色，错误放大倍数降到 4.4 倍。
这说明什么？即使模型变强了，agent 之间的协调和外部验证依然不可替代。
群里用 XSD（XML Schema Definition）做 agent 通信验证的实践者分享过他的观察："99% 正确率在单个 agent 看起来很美好，但当你有 10 个 agent 互相通信，每个都要调用 10 次时，1-0.99^100 ≈ 63.4%——超过 1/3 的概率至少有一次失败。次数多了总会出错。"
这个数学很残酷但很真实。
编译器是最自动化的形式化验证
群里有人说过一句让我印象很深的话："写代码尽量写 Rust，因为编译器要求最高。"
Rust 的 borrow checker 本质上是一套形式化验证系统——它用编译时检查来保证内存安全，不需要 runtime overhead。你没办法"绕过"编译器，只能按规则来。
编译器 = 自动化的形式化验证。这也是为什么 Rust 生态里的 agent 工具（如 Rusticgpt）相对更稳定—— harness 的验证成本被编译器承担了。
XSD 验证方法
对于 agent 之间的通信，用 XSD 做验证是一个有意思的方向。在 agent 层间插入形式化验证关卡，确保 agent 输出的结构化数据符合预期 schema。
这不是银弹——但它提供了一个硬边界，让 harness 的行为可以预测。
Token 经济学：Harness 设计背后的隐形成本
Jensen Huang 年初说过一句话：未来每个工程师的年 token 预算至少 25 万美元——大约是硅谷 senior 工程师年薪的一半。
这不是在吓你。群里已经有团队在认真做这件事：他们的 infra 会追踪每个 engineer 的 token 消耗，按项目、按 agent session 拆账。目的是让工程师意识到：每一次不必要的上下文重载都是真金白银。
现实数字
让我们算一下：
- 群里日均 2-3 亿 token 的团队已经不是个案
- Claude Opus 4.6 的价格大约是 $30/M 输入 token（上下文越长单价越高）
- 2 亿 token = $6,000/天
- 一个月下来 $180,000
当然这是最极端的情况。大多数团队的日均消耗在几千万到一亿 token 量级。但即使按 5000 万 token/天 计算，一个月也是 $45,000。
关键是：这些消耗里有多少是 harness 设计不当造成的浪费？
Token 价格趋势
好的一面：Token 价格在以惊人速度下跌。
2023 年 GPT-4 的时代，$30/M 输入 token 是常态。2025 年中，Claude 3.5 Sonnet 是 $3/M 输入，降幅 90%。而 o3-mini 和 Gemini Flash 系列已经把价格打到了 $2.5/M 以下。
三年跌了 92%。
Prompt caching 进一步降低了一些场景的成本：Anthropic 的缓存命中打一折，Cursor 的 context 复用机制也把重复消耗降了下来。
但问题是：消耗量也在以更快的速度增长。当你的 token 消耗从每天 1000 万增长到 2 亿时，即使单价跌了 90%，你的账单可能还是涨了 10 倍。
Harness 设计就是成本设计
每一次不必要的上下文重载——比如每次都重新加载整个 codebase 而不是增量变化、比如让 agent 反复重新理解同一个模块的结构、比如没有 cache 机制导致相同上下文被重复发送——都是真金白银的浪费。
马工（群里的 infra 大佬）有一个换算："1B token 听起来很大，其实就是 1000 个 1M 上下文的对话。"
当你按这个逻辑去拆解，会发现大多数团队的 token 浪费惊人。一段 100 行的代码被放进了 80 次上下文调用，每次都完整加载——这不是模型的问题，是 harness 的问题。
优化 harness 设计是降低 AI 编程成本最快的方式，比等待模型降价更快，比切换到更便宜的模型更可靠（因为你不用牺牲能力）。
全球视野：不同生态的 Harness 实践
Harness Engineering 不是硅谷的专属。中文 AI 生态圈也在快速演进。
飞书与钉钉的 CLI
飞书和钉钉都在 2025 年初发布了各自的 CLI 工具——不是 MCP，是更贴近国内开发者工作流的 agent 集成方案。（关于 CLI vs MCP 的深度对比，可以看之前的分析。）
飞书 CLI： - 覆盖 2500+ 飞书 API - 11 个业务域，19 个 AI Agent Skills - 已开源
群里对飞书 CLI 的反馈总体正面：文档质量不错，API 覆盖全面，开源策略让透明度有保障。
钉钉 CLI： - 10 项核心能力 - 闭源
这个差异引发了群里不少讨论。有人吐槽："钉钉的 API 封装那么垃圾还闭源，有问题都不知道是 SDK 的 bug 还是我自己用的不对。"
这反映了一个普遍问题：没有透明度，harness 的信任成本会很高。当 agent 行为不符合预期时，你需要能够追踪"是 harness 的问题还是模型的问题"——闭源方案让这个追踪变得困难。
MCP 的分裂
MCP（Model Context Protocol）作为"AI 应用的 USB 标准"，本意是解决生态割裂的问题。但现实是骨感的。
OpenAI 的 Apps SDK 用 _meta 域来绕 context window 限制，跟 Anthropic host 不兼容。各家实现无法互换——就像 SQL，虽然有 ANSI SQL 标准，但 PostgreSQL、MySQL、Oracle 的实现细节各有不同。
群里的判断：MCP 在 2026 年会继续分裂，直到有一个真正落地的竞争标准胜出。在此之前，"你用 MCP 吗"这个问题，答案很可能是"看场景"。
微信接入 OpenClaw
微信生态里跑 AI agent 是个有意思的方向。央视新闻都报道了 OpenClaw 接入微信的消息。
这代表了一个不同的 harness 思路：不是从零构建 agent 环境，而是把 agent 能力嫁接到已有的超级 app 里。
相比从头构建，微信的 UI 层、用户交互层、支付层都已经成熟。Agent 需要做的是"学会操作微信"，而不是"重新发明微信"。
这可能是国内 AI 编程的一个差异化路径。
构建你的第一个 Harness：实操清单
说了这么多理论，怎么开始？
第一步：定义成功标准（不是角色）
很多人第一步就错了。他们写的第一个 harness 定义是这样的：
"你是一个资深的 Python 后端工程师，擅长 FastAPI，有 10 年经验..."
这是废话。角色描述不产生约束。
正确的做法是从可验证的成功标准开始：
- "当用户访问
/api/users/{id}时，返回的 JSON 包含id、name、email三个字段，且id是 UUID 格式" - "所有数据库写操作必须在事务内完成，事务失败时返回 500 错误"
- "任何未捕获的异常必须写入
/logs/errors.log，并返回 500 错误"
成功标准不是告诉 agent 你是谁，而是告诉 agent 做到什么才算对。
第二步：选你的 Scaling 维度
三个维度里，哪个是你当前最痛的瓶颈？
- 时间维度：你的 agent 会跑 2 小时以上吗？会 drift 吗？→ 关注 Evaluator 分离和状态管理
- 空间维度：你需要多个 agent 并行吗？20+ agent 时吞吐量退化吗？→ 关注隔离设计
- 交互维度：你要操控大量 agent 吗？人肉 prompt 已经成了瓶颈吗？→ 关注约束驱动
从最痛的开始，不要试图一次性解决所有维度。
第三步：先设计约束，再写 Prompt
这条很多人知道但做不到。
正确的顺序： 1. 设计 linter 规则（什么代码结构是不可接受的） 2. 设计 CI 检查（什么行为是失败） 3. 设计 Evaluator 标准（什么是"工作正常"） 4. 然后才写 prompt，让 agent 在这些约束内自由探索
错误的顺序： 1. 写一堆 prompt 描述 agent 应该怎么做 2. 然后发现 agent 不听话 3. 加更多 prompt 解释 4. Prompt 越来越长，agent 越来越困惑
约束先行，prompt 补位。
第四步：构建验证闭环
每个约束都需要有对应的验证机制：
- UI 行为 → Playwright 测试
- 代码质量 → Linter + 类型检查
- 业务逻辑 → 单元测试 + 集成测试
- 性能 → 自动化 benchmarks
没有验证的约束是空头支票。
第五步：从第一天开始衡量 Token 经济学
不要等到月底看到账单才惊讶。从第一天就追踪：
- 每个 session 的 token 消耗
- 每个 agent 的平均执行步数
- 上下文复用的命中率
- 每千行代码的 token 成本
这些数字会告诉你 harness 哪里需要优化。
FAQ：Harness Engineering
Q: Harness Engineering 就是 Prompt Engineering 换个名字吗？
不是。Prompt Engineering 关注的是"怎么问问题"——措辞、格式、例子。Harness Engineering 关注的是"整个系统设计"——约束、验证、反馈、状态、协调。
Prompt Engineering 是 Harness Engineering 的一部分，但不是全部。你可以把 prompt 写得完美，但如果 harness 没有验证机制，你不知道 agent 是否真的按你的意图执行了。
类比：Prompt Engineering = 教人怎么问问题。Harness Engineering = 建造一个让人能够高效工作的环境。
Q: 我就用 ChatGPT 写写代码，需要 Harness 吗？
不需要。如果你只是偶尔用 ChatGPT 帮个忙，harness 是过度工程。
Harness Engineering 解决的是规模化的问题：长时任务、多 agent 协作、需要可重复的质量标准。如果你每天只跟 AI 对话 10 分钟，没有复杂任务，没有质量门槛，简单的 prompt 就够了。
Q: 三个 Scaling 维度，我该先关注哪个？
先诊断：哪个维度是你当前的瓶颈？
- 你的任务经常跑偏、agent 2 小时后开始乱来？→ 时间
- 你想并行跑多个 agent，但超过 5 个就开始冲突？→ 空间
- 你要给每个 agent 单独写 prompt，人肉管理成了瓶颈？→ 交互
从最痛的维度开始。
Q: Harness Engineering 跟 MCP 是什么关系？
MCP（Model Context Protocol）是一个协议标准，目的是让不同的 agent 框架可以互操作。MCP 定义了"agent 和工具之间怎么通信"。
Harness Engineering 是设计实践——怎么构建有效的约束、验证、反馈系统。
关系：MCP 是 Harness 的基础设施层之一。但好的 Harness 不需要 MCP（你可以用自定义集成），而只有 MCP 没有 Harness 设计也不会自动产生好的 agent 系统。
MCP 是工具，不是答案。
Q: 开源模型能用 Harness Engineering 吗？
完全能。Harness Engineering 跟模型开源闭源没关系。
实际上，开源模型的 harness 往往更重要——因为没有官方 best practice，你需要自己设计约束体系。
Llama、Qwen、DeepSeek 的社区都在探索各自的 harness 方案。核心原则不变：约束比指令有效，验证比信任可靠。
Q: Harness 和 Agent 框架（LangChain、AutoGen）有什么区别？
这是最常见的混淆。
Agent 框架（LangChain、AutoGen、CrewAI 等）是开发工具：提供了构建 agent 的抽象（chat prompt、tool call、memory 管理）。它们回答的是"怎么写一个 agent"。
Harness Engineering 是设计原则：关注的是"怎么让 agent 产生有用的结果"。它回答的是"你的 agent 系统凭什么能 scale"。
类比：Agent 框架是汽车制造的各种零件（发动机零件、轮子、方向盘）。Harness Engineering 是整车的工程设计——怎么把零件组装成能跑的车。
你可以用 LangChain 写一个 agent，然后用糟糕的 harness（没有验证、没有约束、共享状态），最后得到一辆能发动但会撞墙的车。
参考资料
- Martin Fowler, "Agent = Model + Harness", 2025
- Anthropic Claude Code Architecture Documentation, 2025
- Cursor Engineering Blog, "1000 Commits/Hour: Our Fourth Architecture Iteration", 2025
- OpenAI Symphony Documentation, 2025
- Google/MIT Joint Research, "Error Propagation in Multi-Agent Systems", 2025
- Jensen Huang, NVIDIA GTC 2026 Keynote
- 群聊记录（多位匿名实践者），2025-2026
- XSD Validation in Multi-Agent Communication, 社区实践案例
如果你也在做 AI 编程的 harness 实践，欢迎来群里交流。真实的数据和踩坑经验，比任何官方文档都有价值。