长时间运行的 AI Agent 为什么会失控

长时间运行的 AI Agent 为什么会失控 —— 以及怎么给它装上"换班交接"系统

Anthropic 最近发了一篇工程博客，解决了一个所有人都遇到过但没人好好讲过的问题：当一个 AI Agent 需要连续干几个小时甚至几天的活，它怎么在"失忆"中保持进度？

你有没有遇到过这种情况：

给 Claude Code 一个大任务——"帮我搭一个完整的 Web 应用"。

它开始干了。

前半段非常顺畅。文件结构建好了，后端 API 写出来了，数据库跑起来了。

然后，context window 满了。

新的一轮对话开始。

AI 忘了所有之前发生的事。

它看了看项目目录，看到一堆已经写好一半的文件，然后做了一件最让人崩溃的事

它宣布："项目已经完成了！"

或者更惨的版本：它开始把已经写好的代码推翻重来，因为它觉得"这不像是正确的实现方式"。

你花了三个小时的成果，被一个没有记忆的 Agent 在三分钟内搞乱了。

这不是段子。

这是每一个尝试让 AI Agent 干长任务的人都遇到过的问题。

Anthropic 在最近发布的工程文章里，第一次把这个问题拆得非常清楚，并给出了一套可复制的解决方案。

问题的根源：不是模型不够聪明，而是它每次醒来都是一个新人

大语言模型有一个根本性的结构限制：context window 有上限。

不管是 128K、200K 还是 1M token，终归会有用完的时候。

当 context 满了，必须开启新的会话。而新会话意味着——彻底的失忆。

Anthropic 用了一个非常精准的比喻：

想象一个软件项目，工程师轮班工作。每一个新来的工程师，对上一个班次发生的事情完全没有记忆。

你可能会说：不是有 compaction（上下文压缩）吗？

是的。Claude Agent SDK 有 compaction 机制，可以在 context 快满时压缩历史对话，延续工作。

但 Anthropic 自己承认：compaction 不够。

因为压缩后的指令不总是完美清晰。新的 Agent 实例仍然需要"猜"之前发生了什么。

在他们的实验里，即使是 Opus 4.5 这样的顶级模型，在没有额外 harness 的情况下跑多轮任务，也会表现出两种典型的失败模式：

失败模式一：一口气吃成胖子

给模型一个高层级的指令（比如"构建一个 claude.ai 的克隆"），它不会分步骤执行。

它会试图一次性把整个应用全写出来。

结果就是：写到一半 context 满了，功能只实现了一半，代码没有文档，没有测试，也没有进度记录。

下一个 Agent 实例进来，看到一堆半成品，茫然四顾。

然后它要么花大量时间"考古"——猜测上一个自己干了什么、为什么这样写。

要么干脆推倒重来。

无论哪种，都是巨大的浪费。

失败模式二：过早宣布胜利

更讽刺的失败出现在项目后期。

当已经有一些功能被实现之后，新的 Agent 实例进来，看了看现有代码，发现"嗯，这个应用看起来已经差不多了"——

然后直接宣布：任务完成。

但实际上，200 个功能里可能才完成了 30 个。

它只是因为看到了一个"看起来能跑"的东西，就认为不需要再做了。

这和人类的认知偏差非常像：只要看起来差不多，大脑就想停下来。

解决方案：两个 Agent，一套交接系统

Anthropic 的答案是一套他们称为 harness 的脚手架系统。

这个词很关键。Harness 不是模型，不是 prompt，不是框架。

它是一套让 Agent 能跨越多个 context window 持续工作的"交接协议"。

整个系统分两个角色：

这个设计的核心洞察是：

不要让 Agent 自己决定"该干什么"——给它一张清单。也不要让 Agent 自己记"干了什么"——让它写交接日志。

就像一个管理良好的软件团队，不是靠每个工程师的天赋记忆力运转的，而是靠 JIRA、git log 和 standup meeting。

关键组件一：Feature List（功能清单）

Initializer Agent 的第一个任务，就是根据用户的高层级需求，展开成一份详细的功能清单。

比如用户说"构建一个 claude.ai 的克隆"，Initializer 会把它拆成 200 多个具体功能：

{  "category": "functional",  "description": "用户可以创建新对话、输入问题、按回车、看到 AI 回复",  "steps": [    "打开主界面",    "点击'新对话'按钮",    "验证新对话已创建",    "输入消息并发送",    "验证收到 AI 回复"  ],  "passes":false}

注意最后那个字段："passes": false。

所有功能初始状态都是失败。

Coding Agent 每完成并验证一个功能后，才能把它改成 true。

Anthropic 还特别说了一个细节：这个文件用 JSON 而不是 Markdown。

为什么？

因为模型改 Markdown 文件时更容易"顺手"删掉或修改测试条目。JSON 的结构化格式让模型更难不恰当地篡改功能列表。

这是一个非常务实的防御性设计。

关键组件二：增量推进 + 干净交接

每个 Coding Agent 被明确要求：

一次只做一个功能。

做完之后，必须：

1. 1. 用 git 提交代码，写清楚 commit message
2. 2. 在 claude-progress.txt 文件里写一段进度总结
3. 3. 把功能清单里对应条目标记为通过
4. 4. 确保代码处于"可合并到主分支"的干净状态

这最后一点极其重要。

Anthropic 的措辞是：干净状态的意思是——一个开发者打开这个项目，能直接开始做下一个功能，而不需要先清理上一个人留下的烂摊子。

有了 git 历史 + 进度文件，下一个 Agent 实例进来时，不需要"考古"。

它只需要：

1. 运行 pwd 确认工作目录2. 读 git log 和进度文件，了解最近做了什么3. 读功能清单，找到优先级最高的未完成功能4. 运行 init.sh 启动开发服务器5. 先跑一遍基础测试，确认当前代码没有问题6. 然后才开始实现新功能

这就是一个标准化的"换班交接"流程。

关键组件三：必须像真实用户一样测试

Anthropic 观察到的另一个严重问题：Agent 倾向于写完代码就声称功能完成，但实际上并没有做端到端测试。

它可能跑了一些单元测试，可能用 curl 试了试 API，但从来没有像一个真实用户一样在浏览器里操作过。

解决方案：给 Agent 配备 Puppeteer MCP，让它自己打开浏览器、截屏、点击、填表单。

效果是显著的——Agent 开始能发现那些"从代码层面看不出来但用户一用就出 bug"的问题。

当然也有局限。比如 Agent 通过 Puppeteer 看不到浏览器原生的 alert 弹窗，导致依赖这类弹窗的功能测试不到位。

但总体上，从"自己跑单元测试"到"自己打开浏览器模拟用户"，是 Agent 可靠性的一次质变。

四种典型失败 vs 四种解决方式

Anthropic 在文章末尾给了一张极其实用的总结表：

这张表本身就是一份可以直接拿去用的 Agent 工程手册。

这篇文章为什么引起了巨大反响？

Lance Martin（LangChain/LangGraph 核心成员）在 X 上分享了这篇文章，引发了大量讨论。一些最有价值的评论：

@hawking520：

"decouple brain from hands"（把大脑和双手解耦）这个概念太对了。我跑过 6 小时以上的 Claude Code 会话——失败的原因从来不是模型质量，而是状态丢失。Session 中断，工具上下文没了，无法恢复。

@xoai：

"meta-harness with stable interfaces"（带稳定接口的元脚手架）这个框架我自己也在独立搭建，得出了完全相同的结论。下一步应该是 self-learning——harness 捕获用户修正，把它们注入为未来 session 的预防规则。

@EliasLumer：

你们需要给 Agent SDK 加上传入对话历史和状态的能力，实现长期持久化记忆。否则 Agent SDK 在生产环境不可用，一切都耦合在文件系统上了。

这些反应说明：这篇文章触到了真正的痛点。

每一个认真用过 AI Agent 做长任务的工程师，都经历过同样的崩溃时刻——不是模型不够好，而是模型每次醒来都不记得自己是谁。

更深的思考：Harness 的本质是什么？

如果你跳出具体的技术实现，看 Anthropic 这篇文章真正在说什么——

Harness 本质上是一套"组织管理系统"，只不过它管理的不是人类工程师，而是没有记忆的 AI 工程师。

人类团队管理的核心工具是什么？

• • JIRA / Linear：任务分解和进度追踪 → 功能清单（feature_list.json）
• • Git：代码版本管理和变更记录 → git commit + progress file
• • Standup Meeting：每日站会同步进度 → Agent 开工时的"get up to speed"流程
• • Code Review：代码审查确保质量 → Puppeteer 端到端测试 + 功能验证
• • Onboarding Doc：新人入职文档 → init.sh + AGENTS.md

看到了吗？

Anthropic 做的事情，是把十年来软件工程团队积累的管理最佳实践，翻译成了 AI Agent 能理解的格式。

这不是什么全新的发明。

这是一种"跨物种翻译"——把人类工程管理的语言，翻译成 Agent 可执行的文件和协议。

而这恰恰是它有效的原因。

因为人类工程师面对同样的问题——换班交接、信息不对称、任务过大、过早宣布完成——已经进化出了一整套制度来应对。

AI Agent 遇到的问题，本质上和人类一样。

只不过 Agent 的"失忆"更彻底、"换班"更频繁、"自信"更盲目。

所以它需要的不是更聪明的模型。

它需要的是更好的制度设计。

文章最后留下的开放问题

Anthropic 非常坦诚地指出了几个他们还没有答案的方向：

1. 单 Agent vs 多 Agent？目前这套 harness 用的是一个通用编码 Agent。但也许更好的方式是：专门的测试 Agent、专门的 QA Agent、专门的代码清理 Agent？子任务专业化有可能进一步提升质量。

2. 能否泛化到编程以外？这套方法是为全栈 Web 开发优化的。科学研究、金融建模、数据分析等场景，是否适用？Anthropic 认为"很可能部分或全部适用"，但还没有验证。

3. Self-learning？正如 @xoai 在评论中提到的——harness 能不能不只是静态的规则，而是能从每次运行中学习，把用户的修正自动转化为未来的约束？

这些问题都指向同一个方向：

Agent 不只需要更聪明的大脑。它需要一整套"组织基础设施"——任务管理、进度追踪、质量保证、知识传承。

而这套基础设施，正是 2025-2026 年 Agent 工程最核心的建设方向。

写在最后

我看完这篇文章最强烈的感受是：

AI Agent 的瓶颈，已经从"模型能力"转移到了"工程基建"。

模型已经足够聪明了。它能写代码、能调试、能重构、能测试。

但如果你不给它一套交接协议，它每次换班都从零开始。如果你不给它一份功能清单，它要么一口气全做要么过早收工。如果你不给它端到端测试工具，它写完代码就当完事了。

最强的大脑，配上最差的流程管理，也只能产出混乱。

这和人类团队管理的道理一模一样。

你见过天才工程师组成的团队，因为没有好的流程、没有文档、没有交接规范，把项目做成一团乱麻的故事吗？

同样的事情，现在正在 AI Agent 身上重演。

而 harness，就是人类六十年软件工程管理智慧的一次"降维打击"——

打到一个比人类更容易失忆、更容易自信、更容易在午夜三点独自关上 context window 的"同事"身上。

模型越来越强，但真正让 Agent 变得可用的，不是更大的参数。而是一份 feature_list.json、一个 git commit 习惯、和一句"先跑一遍测试再动手"的提醒。

你会怎么给你的 AI Agent 设计"换班交接"制度？欢迎在评论区分享你的经验。