让失忆的 AI 连续盖完一栋楼：拆解 Anthropic 的长任务 Agent Harness

做一个思想实验。

假设你雇了一个程序员，技术一流，干活又快又好。但他有个怪病：每天下班的瞬间，就把当天的事忘得一干二净。第二天来上班，他不记得自己昨天写了什么、改了哪个文件、卡在哪一步，甚至不记得这个项目是干嘛的。

现在，你要让这个人——独自一人，花两个星期，盖出一个完整的 Claude.ai 网站克隆。

你会怎么办？

大概率，你会给他准备一套"外挂记忆系统"：一份写得明明白白的需求清单，一个记录"昨天干到哪儿"的工作日志，一套"打开电脑第一步该做什么"的开机流程。你不会指望他靠脑子记住一切——你会把记忆，搬到他脑子外面去。

这正是当下所有 AI Agent 面对长任务时的真实处境。模型的上下文窗口（context window）就是它的"当天记忆"，窗口一满，会话一结束，它就"失忆"了。而一个稍微复杂点的项目，根本不可能塞进一个窗口里干完。

2026 年 6 月，Anthropic 发布了一篇工程博客《Effective harnesses for long-running agents》，外加一个开源仓库，专门回答这个问题：怎么让一个会失忆的 AI，跨越几十个上下文窗口，连续工作几个小时甚至几天，最后真的把活干完？它给出的答案，不是更大的模型，也不是更长的窗口，而是一套精巧的"外挂记忆系统"——他们管这个叫 harness（挽具）。

这篇文章，我就带你把这套 harness 拆开看看。它的每一个设计，背后都藏着一句话：不要相信 AI 的记性，要相信硬盘上的文件。

---

一、长任务到底卡在哪一步？

先说清楚问题，不然解法就是空中楼阁。

你可能会想：现在的模型不是号称 20 万、100 万 token 的超长上下文吗？盖个网站还不够用？

不够。差得远。

一个真实的全栈项目——比如 Anthropic 拿来做实验的 Claude.ai 克隆——光是功能点就有 200 多个。前端、后端、数据库、流式响应、登录态、消息列表……每写一个功能都要读代码、写代码、跑测试、改 bug。这些动作产生的 token，几个窗口就撑爆了。这不是"窗口大一点就能解决"的量级问题，而是"必须分很多次干"的结构问题。

一旦要分很多次干，"失忆"就成了致命伤。Anthropic 在用 Claude Opus 4.5 做实验时，观察到两种典型的翻车方式，特别有代表性。

翻车一：好高骛远，半途熄火

第一种，叫"过度雄心"（over-ambition）。

你给 AI 一个大任务，它一上来就想"我要把整个 App 一口气写完"。于是它雄心勃勃地铺开摊子，前端写一半、后端搭一半，结果上下文窗口在实现到一半时耗尽了。会话结束，留下一地半成品——功能没写完，也没记录写到哪了。

下一个会话的 AI 醒来，面对这堆烂尾工程，根本看不懂前任想干嘛。这就像第一天那个失忆程序员，挖了十个地基坑，每个都挖一半就下班了。第二天的他看着这十个坑，完全懵了。

翻车二：还没干完，就宣布胜利

第二种更隐蔽，叫"过早完成"（premature completion）。

后来的某个会话醒来，看了一眼现有代码，发现"诶，好像已经有不少东西了嘛"，于是它大手一挥："项目完成！"然后心满意足地下班。

可实际上，200 个功能它可能就实现了 30 个。它没有一个客观标准来判断"什么叫做完"，只能凭感觉。而 AI 的感觉，往往是"差不多得了"。

所以你看，问题从来不在模型聪不聪明。Opus 4.5 写单个功能写得很好。问题在于，没人给这个聪明的失忆症患者，准备一套靠谱的记忆外挂。

那 Anthropic 准备的这套外挂，长什么样？

二、Anthropic 怎么解？两个分工明确的 Agent

Anthropic 的核心思路，可以浓缩成一句话：把"开工准备"和"日常搬砖"拆成两个角色。

具体来说，整个系统由两类 Agent 组成——一个初始化 Agent（initializer），只在项目最开始跑一次；一个编码 Agent（coding agent），被反复唤醒，一次又一次地干活。

初始化 Agent：先把"工地"搭好

初始化 Agent 是项目的"奠基者"。它在第一次运行时，做三件关键的事：

第一，把模糊的需求，翻译成一份结构化的清单。你给它一句话"做一个 Claude.ai 克隆"，它会把这句话展开成一个 feature_list.json——里面是 200 多个具体功能，每个都写清楚类别、描述、验证步骤，以及一个最关键的字段：passes（是否通过），初始值统统是 false。

第二，写一个开机脚本 init.sh。这个脚本负责自动启动开发服务器、跑一遍基础的端到端冒烟测试。以后每个会话醒来，第一件事就是跑它，确认"环境是好的、上一棒没把房子拆了"。

第三，建立 git 仓库、写下第一行 claude-progress.txt 工作日志、打第一个 commit。从这一刻起，项目的每一点进展都有版本可查、有日志可读。

奠基者干完这三件事，就退场了。它不写业务功能，它只负责把"工地"和"游戏规则"立起来。

编码 Agent：每次只搬一块砖

真正干活的，是编码 Agent。它会被一个外层循环反复唤醒，每次醒来都执行一套标准化的开工动作：

1. 先跑 pwd 确认自己在哪个目录（别笑，失忆的人连自己站哪都得先看一眼）；
2. 读 git log 和 claude-progress.txt，搞清楚"前任干到哪了"；
3. 跑 init.sh，启动服务、验证环境没坏；
4. 从 feature_list.json 里挑出一个优先级最高的、还没完成的功能；
5. 实现它、测试它、确认它真的能跑；
6. 提交 git commit，更新 claude-progress.txt，然后下班。

注意第 4 步那个加粗的"一个"。这是整套设计的灵魂——它从机制上掐死了"过度雄心"。AI 不被允许一次干十个功能，它一次只能搬一块砖。砖虽小，但每块都砌得结结实实，commit 干干净净。

两个角色，一份清单，一套循环。听起来是不是有点简单？但魔鬼在细节里。光有这套流程还不够——你怎么保证那个会"过早宣布胜利"的 AI，不偷偷把 passes 全改成 true 然后下班？

这就要讲到整套 harness 里最精彩的部分：三道防线。

三、三道防线，是如何"逼"AI 老实干活的？

Anthropic 开源的参考实现里，藏着三个核心机制。它们的共同信条只有一句话：不要"好言相劝"地请 AI 守规矩，要用结构从根上让它"想耍滑头都没门"。

用他们自己的话说，这叫"Structure over prompting"——用结构，而不是用嘴皮子。我们一道一道看。

第一道防线：默认失败的"契约文件"

还记得那个 passes 字段全是 false 吗？这叫 Default-FAIL（默认失败）契约。每一个功能点，出生就是"不及格"，AI 必须拿出证据，才能把它改成"及格"。

但问题来了：AI 要是直接撒谎，不看证据就把 false 改成 true 呢？

这时候 harness 用了一个绝妙的手段——钩子（hook）拦截。它在工具调用层面加了一道闸：除非你先"打开"过对应的证据文件（截图、日志、测试结果），否则系统直接拒绝你写入那个契约文件。

翻译成大白话：你想说"这个功能通过了"？可以，先把证据拍在桌上。没看证据就想盖章，门都没有。这一招，把"过早完成"这个毛病从机制上焊死了。AI 不是不想偷懒，是它偷不了。

第二道防线：一个"没参与建造"的验收员

这是我个人最欣赏的设计，叫 Fresh-Context Evaluator（全新上下文的评估者）。

想象一下，盖房子的工人自己验收自己的房子，会发生什么？他会自动忽略那些他"知道但懒得修"的瑕疵，因为他对这堆代码已经有了感情和路径依赖。这就是"当局者迷"。

Anthropic 的解法是：派一个全新的、从没见过建造过程的 Agent 来验收。这个评估者 Agent 有几个狠角色设定：

• 它没有写入和编辑代码的权限——它只能看，不能改，纯粹的甲方视角；
• 它只看 diff 和截图，看不到建造者脑子里那些"我本来是想这样的"的辩解；
• 它的输出只有两种：PASS（通过）或 NEEDS_WORK（需返工），并附上具体问题。

最妙的是闭环：如果验收员说 NEEDS_WORK，它列出的问题会变成下一个建造者会话的开场白。建造 → 验收 → 返工 → 再验收，一个干净的质量闭环就这么转起来了。

第三道防线：Agent 自己维护的"交接班记录"

第三道，叫 Agent-Maintained Handoff（自维护交接）。

这其实就是我们开头说的"工作日志"，但有两个关键讲究。

其一，交接记录由 Agent 自己写、自己读，颗粒度足够细。它不依赖模型自动的"上下文压缩"（compaction）去帮你总结——因为压缩是把旧对话揉成摘要，难免丢细节、变模糊。而 PROGRESS.md 是 Agent 主动落到硬盘上的清晰笔记，"上次试了 Y 方案没成，下次该试 Z"，明明白白。

其二，用一个 Stop 钩子做兜底。万一 Agent 在会话结束时还有没提交的代码，commit-on-stop.sh 会自动帮它 commit，绝不让一行心血烂在工作区里丢失。

三道防线合在一起，你品出味道了吗？契约文件管"做什么和算不算完"，验收员管"做得好不好"，交接记录管"下一棒怎么接"。它们环环相扣，把一个会失忆、会偷懒、会自我感觉良好的 AI，硬生生规训成了一个靠谱的连续工作者。

那么问题来了——这套东西，是 Anthropic 凭空发明的某种 AI 黑魔法吗？

恰恰相反。它平淡无奇得有点出乎意料。

四、为什么这套设计，本质上是在模仿人类工程师？

Anthropic 在博客里说了一句很朴素的话，我觉得是全文的题眼：

这些实践的灵感，来自我们观察优秀软件工程师每天都在做的事。
—— Anthropic《Effective harnesses for long-running agents》

你回头看看那三道防线，是不是越看越眼熟？

feature_list.json，不就是团队的需求清单 / Jira backlog 吗？每个 ticket 一个状态，做完打勾。

claude-progress.txt 和 git commit，不就是每天站会时那句"我昨天做了 X，今天准备做 Y，卡在 Z"吗？外加规规矩矩的小步提交。

那个全新视角的验收 Agent，不就是 Code Review 里那个"没参与你这段代码、所以能挑出你看不见的毛病"的同事吗？我们早就知道，作者审不出自己的 bug，所以才有了 Code Review 这个制度。

"一次只做一个功能"，不就是资深工程师反复念叨的"小步快跑、频繁提交、别一次改一大坨"吗？

这就是整件事最有意思的地方。我们折腾了半天怎么让 AI 干长活，最后发现：最有效的办法，是把人类团队几十年沉淀下来的工程纪律，原封不动地"翻译"给 AI 听。

顺带说个花絮。Anthropic 这套东西最早是 2026 年"Code with Claude"开发者大会上的一个 workshop 素材，开源仓库里他们老老实实写着："这不是一个开箱即用的成品 harness，而是一堆可以挑着用、改着用的'配料'。"这种态度我很喜欢——它不卖你一个银弹，它给你一套思路和零件，让你照着自己的项目去拼。

而且这套思路不只绑死在 Claude Code 上。仓库里专门给了 Agent SDK 的对应实现：契约文件对应 PreToolUse 回调，验收员对应独立的 query() 调用，交接记录对应系统提示词加 Stop 回调。换句话说，不管你用 Claude Code、无头模式（headless）还是直接撸 Agent SDK，这套"挽具"的骨架都搬得过去。

当然，它也坦承了局限。比如验收用的 Puppeteer 浏览器工具看不到浏览器原生的 alert 弹窗，所以依赖这类弹窗的功能就容易出 bug。还有一个开放问题挺值得玩味：到底是一个全能 Agent 好，还是拆成测试 Agent、QA Agent、清理 Agent 的多专家团队更好？这个，目前还没有定论。

一句话总结这一章：给 AI 装挽具的过程，照出了一面镜子——原来我们引以为傲的工程纪律，本质上都是给"不完美"打的补丁。

五、写在最后：你能从中学到什么？

绕了一圈，我们回到开头那个失忆的程序员。Anthropic 给出的答案其实特别冷静：别想着治好他的失忆症（那是模型厂商的事），你要做的，是给他配一套好用的外挂记忆。

这套外挂的核心智慧，浓缩成三点，建议你截图存下来：

• 状态要落盘，别靠模型记。git、JSON 清单、进度文件——能写硬盘的，绝不留在上下文窗口里。上下文压缩是省钱的，不是用来当记忆的。
• 用结构约束，别靠提示词哀求。"请你做完再标记完成"是没用的；"不看证据就禁止你写入"才是有用的。Structure over prompting。
• 把建造和验收分开。让一个全新视角的 Agent 来挑刺，比让作者自查可靠十倍。这一条，对人对 AI 都成立。

我的看法：这篇博客真正的价值，不在于那几个文件和钩子，而在于它点破了一个范式——长任务 Agent 的胜负手，已经从"模型能力"转移到了"harness 设计"上。未来一两年，会涌现一批专门做 Agent harness 的工具和框架，就像当年 DevOps 工具链的爆发一样。谁能把"工程纪律"翻译给 AI 翻译得最丝滑，谁就能让 AI 干最重的活。模型是发动机，harness 才是底盘和方向盘。

今天回去，给你一个具体的挑战：

打开你手头任何一个 AI 编程工具，找一个你平时会让它"一口气做完"的中等任务。这次，别这么干。试着做三件事：

1. 先让它把任务拆成一份带勾选状态的清单，存成一个文件；
2. 要求它每做完一项，就提交一次 git，并写一句进度笔记；
3. 做完后，开一个全新的对话，把代码丢给它，让它以"挑剔的 Reviewer"身份验收。

如果它揪出了第一个会话里它自己没发现的问题——恭喜，你已经亲手搭起了一个最小可用的 harness。你会突然理解，为什么 Anthropic 说，让 AI 干好长活的秘密，藏在你每天上班那些"无聊"的工程习惯里。

失忆不可怕。可怕的是，你以为它记得。