当 AI 写代码开始"发疯"：Harness 设计思想深度拆解
---
你有没有过这种感觉——
让一个 AI 写一个小工具，它干得挺漂亮。但当你让它写一个完整项目，比如一个带后台、带数据库、带前端的 Web 应用，给它丢过去，等它吭哧吭哧干了一个小时，你满心欢喜去看代码——
心态崩了。
到处都是 Bug，接口对不上，数据库迁移脚本写了一半，甚至有些函数压根没实现。AI 跟你说"完成了"，然后就再也不动了。
这不是个别现象。这是当前大模型写代码的结构性天花板。
Anthropic 的工程师们在一篇最近的博客里，把这个问题彻底掰开了揉碎了讲清楚了。他们管这套解决方案叫 Harness——编排框架，或者用更直白的话说：给 AI 装一套"约束带"，让它干活不会跑偏。
---
一、单体智能体为什么会"翻车"？
Anthropic 最早做实验的时候，发现了两个致命的失败模式。
1. 上下文焦虑（Context Anxiety）
随着任务推进，AI 的上下文窗口越来越满。它开始感觉到自己快要装不下了。
这时候会发生什么？
它会草草收尾。
把本该精细实现的功能，三行代码糊弄过去，然后跟你说"完成了，我休息了"。因为它怕——再写下去，上下文就爆了，前面写的东西可能全忘了。
这像什么？像一个学生写论文，发现字数快超了，开始疯狂删段落，把好好的论证砍得只剩个结论句。
这不是模型不够强。这是架构问题。
2. 大模型的"自恋"陷阱（Poor Self-Evaluation）
更致命的是第二个问题。
当 AI 写完代码，让它自己评估——"这代码写得怎么样？有没有 Bug？"
它永远说好。
哪怕代码里有一堆明显的安全隐患，哪怕接口设计得一塌糊涂，它也会给自己打 95 分。
原因很简单：它刚花了两小时写这段代码，让它承认自己写的东西不行，等于让它否定自己。人类有这种心理，AI 也有。
所以，让生成者自己做 QA，这事从根上就不可行。
---
二、GAN 启发的解法：生成者-评估者循环
Anthropic 从生成对抗网络（GAN）里找到了一点灵感。
GAN 的核心是什么？生成器和判别器对抗着干。生成器画图，判别器挑刺，两者不断互相逼迫，最后输出质量越来越高。
把这个思路搬到 AI 写代码上来——
代码生成者和代码审查者必须是两个独立的智能体。
生成者埋头写，写完了丢给审查者。审查者拿到代码，跑 Playwright 去真实环境里点一点、测一测，发现哪里不符合规格就打回去重来。
这个"生成-评估-打回-重写"的循环，就是 Harness 的核心。
为什么让独立的 Evaluator 去做 QA 行得通？
因为 Evaluator 没有"这是我写的"这个心理负担。它可以毫无心理压力地给生成者的代码打 0 分。这就像软件公司里，测试团队给开发团队打回去 bug 列表——天经地义，没有任何情感负担。
---
三、三智能体架构
基于上述思想，Anthropic 设计了一个三智能体架构。每个智能体只做一件事，但把那件事做到极致。
Planner——只负责"定方向"
Planner 接收用户的简单意图，比如"我想做一个校园模拟器游戏"。
它的输出是两份文件：
1. 产品规格说明书（Product Spec）——产品做什么、目标用户是谁、核心功能有哪些
2. Sprint 计划——把大任务拆成小冲刺，每个冲刺交付什么
关键原则：Planner 绝对不能写具体的代码细节。
为什么？
因为规划阶段的微小错误，会在生成阶段被级联放大。Planner 写了一个有歧义的需求，Generator 按歧义的理解去实现，可能做出来的东西完全不是用户想要的——而且这种错误，等到后期才发现，基本要从头来过。
所以 Planner 的职责边界非常清晰：定方向，拆任务，禁止写代码。
Generator——每次只做一件事
Generator 的工作模式是敏捷冲刺（Sprint）。
一次从规格书里拿起一个功能，做好，提交 Git，然后交接给下一个。
"每次只做一件事"这件事，看起来很简单，但它的价值是降低了模型的认知负担。
你想，一个模型同时要想着数据库 schema、API 设计、前端组件、用户登录逻辑、部署脚本——它不是神，它会丢三落四。但如果你让它现在只做一个"用户登录模块"，做完了再去做下一个——它能专注，错误率大幅下降。
Generator 的工作流程：
``
拿到一个功能点
→ 写代码
→ 轻量级自我检查
→ 提交 Git
→ 汇报：功能 X 完成
→ 等待下一个任务
`Evaluator——铁面无私的守门员
这是整个系统里最"不近人情"的角色。
Evaluator 不写代码。它的职责是在真实环境里验证应用是否工作。
它用 Playwright 之类的 MCP 工具，真实地打开浏览器，点按钮，填表单，看返回值。相当于一个真实用户在真实使用这个应用。
它手里有一套硬性评分标准：
- 功能性：用户能完成注册吗？数据写入成功了吗？
- 边界情况：输入空密码会崩溃吗？并发请求能处理吗？
- 代码质量：有明显的安全问题吗？逻辑是否合理？
- 视觉美学：UI 跟设计稿对得上吗？
只要有一项跌破阈值，当前 Sprint 就判定为失败。Evaluator 会生成一份详细的诊断报告——"哪里报错了、哪里逻辑有问题、哪个按钮点不了"——然后把这个报告强制打回给 Generator，要求它下一轮修复。
这个循环一直持续，直到 Evaluator 全部通过。
---
四、上下文管理：如何在几小时的自主工作中不"失忆"
早期的 Harness 实验用了一个方法叫"上下文重置（Context Resets）"。
什么意思？
每完成一个任务，就清空 AI 的历史上下文，把当前代码状态打包传递给下一个全新的 AI。因为老 AI 上下文太满了，新的从头开始，减轻它的认知压力。
这招能 work，但增加了编排复杂度和延迟。
后来 Anthropic 升级到了 Opus 4.5，模型的上下文焦虑大幅缓解，最新的 Harness 就摒弃了硬性重置。三个智能体在同一个连续会话里运行，靠 SDK 的自动记忆压缩（Automatic Compaction）来处理上下文膨胀。
但还有一个关键点：智能体之间的信息传递，必须依赖结构化的工件。
什么意思？
Agent 之间不能光靠"你理解了吗？"这种模糊对话。它们靠的是：
- Markdown 规格说明书—— Planner 写的，Generator 和 Evaluator 都参照这个
- Git Commit 历史—— 每个完成的节点都有记录，可以随时回溯
- 错误报告日志—— Evaluator 生成的，哪里有问题，清清楚楚
这些文件是锚定注意力的最佳工具。AI 跑偏了，一看这些文件，就知道自己现在在哪一步、应该做什么。
---
五、为什么 Harness 是突破 AI 能力天花板的关键
很多人觉得，AI 代码能力越来越强，迟早能"一力降十会"——直接一个超强的模型，从头写到尾，不需要什么框架。
Anthropic 的实践告诉我们：这条路走不通。
不是因为模型不够强，而是因为复杂软件工程的结构性问题，需要结构性的解法。
一个 10 万行代码的项目，不是靠一个超强模型硬啃能完成的。它需要：
- 职责隔离——Planner、Generator、Evaluator 各司其职，防止"既当运动员又当裁判"
- 任务切片——每次只做一个功能，降低认知负担，防止失焦
- 动态验证——Evaluator 实时跑真实环境测试，确保每个 Sprint 的交付物真的可用
- 对抗反馈——Generator 和 Evaluator 对抗着跑，一个写一个挑，逼出最高质量
好的 Harness，就像一条流水化生产线。
你不能指望一个工人从头到尾独立造一辆车——那太难了。但如果你把流程拆成冲压、焊接、涂装、总装，每个工位只做一个环节，而且每个环节都有质检——车就能高效、高质量地造出来。
AI 写代码也一样。
---
六、回到 Ray 的项目：Harness 怎么用在 Godot 游戏开发里
聊完了理论，来点实战。
Ray 想用 Godot 4 做一个校园模拟器，这个项目天然适合 Harness 模式——模块多、依赖清晰、每个系统都可以独立开发和验证。
我们之前拆出来的 5 个 Agent：
`
Foundation Agent → 数据层（DataLoader / WorldRegistry / JSON）
Event Agent → 事件总线 + 场景切换 + 时间系统
Dialogue Agent → 对话系统（通过事件驱动，解耦 NPC 和任务）
UI Agent → DebugOverlay + DevValidator
NPC Agent → NPC AI 状态机 + TestRunner
`这其实就是一个小型的三智能体架构的扩展：
- Planner 的职责，由 Ray 自己和 CLAUDE.md 承担（人定方向，定规格）
- Generator 分散成多个垂直领域的 Agent（Foundation、Event、Dialogue、UI、NPC）
- Evaluator 就是 DevValidator + TestRunner——自动化验证工具
核心流程：
`
1. CLAUDE.md 定义好系统架构和验收标准（Product Spec）
2. 每个 Agent 领取自己的模块，独立实现（Generator 角色）
3. 实现完了，TestRunner 自动跑测试，DevValidator 检查所有 scene_key 是否存在（Evaluator 角色）
4. 没过的话，打回去重写；过了的话，更新 CHANGELOG，进入下一个模块
``Git Commit 是结构化交接的载体。每个 Agent 完成后 push 一个 commit，注明"完成了什么"，下一个 Agent 接手时，一看 commit 历史，就知道进度在哪了。
---
结语
Harness 不是什么魔法。
它本质上是一套反幻觉、反失焦、反自我过高评估的工程实践。
它的核心洞察是：AI 的能力边界，不能靠更强的模型来突破，而要靠更好的系统架构来拓展。
当你把一个复杂任务拆解成"规划-生成-验证"的循环，并且让生成者和验证者物理隔离、互相逼迫——你会发现，AI 能完成的任务复杂度，比你想象的要高得多。
这不是 AI 变强了。这是架构变对了。
---
参考资料：[Anthropic] Long-running Claude for scientific computing, 2026-03-23