给 Claude 一个足够大的任务，它就会中途放弃，还自以为已经完成了。工作并没有做完，只是它不记得自己开始过。
Agent 执行长任务的方式和你想象的不同。它实际上是轮班工作。
想象一个软件项目，由轮班工作的工程师负责，每个新来的人对上一班发生的事一无所知。这并非比喻 Agent 的感受，而是它们的工作原理。上下文窗口是有限的，大多数实际工作无法塞进一个窗口内，因此 Agent 会分多个离散的会话工作——而每个新会话开始时，都不记得上一个会话的内容。
Anthropic 做了这个实验并公布了问题所在。这部分值得一读，因为这不是某个博主在说工具不好用，而是 Claude 的构建团队在记录 Claude 哪里容易出问题。
为什么一个窗口无法完成任务
给一个前沿编码模型一个高层级提示——"构建一个 claude.ai 的克隆版"——让它在多个上下文窗口中循环执行，结果它无法生成一个能用的应用。不是偶尔失败，而是稳定失败。这还是 Opus 在 Anthropic 自己的 Agent 框架上运行，启用了上下文压缩，整个设置就是为了让它持续运行而建的。
它以两种具体方式失败，两者都是交接班问题。
第一种：Agent 试图一次性做完所有事。它尝试在一个窗口内一次性完成整个应用，中途某个功能做到一半上下文就用完了，会话结束，留下一个半成品且没有文档。下一班的人上班，看到一团乱，不是自己造成的，只能猜测之前发生了什么。于是它整个会话都花在让基础应用重新工作，而不是推进进度。
第二种出现在后期，当某些功能已经存在时。一个新的 Agent 环顾四周，看到确实取得了一些进展，就断定整个事情已经完成了。但实际上并没有——一半的功能从未构建，也没有人记录哪些功能完成了。这一班的人没检查清单就宣布完工了。
两种失败根源相同。离开的那一班什么也没留下，于是到来的那一班只能盲目飞行。解决办法不是更聪明的模型，而是那一班在下班前写下的东西。
离开的那班写下什么
Anthropic 得出的答案有两部分：一个 Agent 在开始工作前设置好环境，然后轮班工人一个接一个地出现并推进进度。
设置 Agent 只在最开始时运行一次。它的全部工作就是让环境处于一种状态，使得未来每一班都知道"完成"是什么样子。它写下的关键部分是一个功能列表——一个结构化的文件，详细列出最终应用需要做的每一件事。
对于 claude.ai 的克隆版，这意味着超过 200 个功能。比如"用户可以打开一个新聊天，输入查询，按回车，看到回复"。每一项在开始时都标记为"未通过"。每个条目大致如下：
1{2 "description": "新建聊天按钮能创建一个全新的对话",3 "steps": ["点击\"新建聊天\"", "验证全新的对话", "检查欢迎状态"],4 "passes": false5}
每个条目上的 "passes": false 就是关键点。这是一个未勾选的复选框，而且有 200 个这样的复选框。
这个失败的列表正是阻止 Agent 过早宣布胜利的东西。一班人不能环顾四周就断定工作做完了，因为就有一个文件放在那里，上面有 200 个未勾选的复选框。在写第一行代码之前，工作就已经被定义好了。
一个小细节能让你知道这必须有多谨慎：他们用了 JSON 来存储这个文件，而不是 Markdown。原因是模型不太可能悄悄重写或删除 JSON 文件，却有可能会动 Markdown 文件。而围绕它的指令也故意写得很直接——删除或修改测试是不可接受的，因为删除一个测试就等于让一个功能无声无息地消失。这一班人可以勾选复选框，但不允许擦除一个。
桌上的便条
设定工作是其中一半。另一半是确保每一班离开时把环境整理得足够干净，让下一班的人能直接接手。
两样东西能实现这一点。Agent 用一条有意义的提交信息描述更改了什么，将工作提交到 git；同时它还会写一个简单的进度文件——一个正在进行的日志记录已完成的内容。这个日志和 git 历史一起，让一个新 Agent 在冷启动时，能在几分钟内了解现状，而不是花一小时反向工程。
Git 在这里还有另一个作用。当一班做出了糟糕的更改，下一班可以回滚到最后一个可工作的版本，而不是试图理清损坏。进度文件告诉我们当前在哪。提交历史就是撤销按钮。
而"干净"有特定的含义。它指的是那种你可以放心合并到主分支的代码——没有重大 bug、有序、有文档。不是"技术上我有点进展"。标准是：下一个人可以直接开始一个新功能，而不需要先清理你的烂摊子。
下一班如何上班
把这两样东西放在一起，每一班都以同样的方式开始。在接触任何新东西之前，Agent 先运行一个固定的开场程序来掌握情况——这和一位优秀工程师接手一个许久未见的项目时的做法一样。
1运行 pwd 查看当前目录——这是你唯一能编辑的地方2读取进度文件和 git 日志，了解最近发生了什么3读取功能列表，选择优先级最高且尚未完成的项4启动应用并运行基本检查，确保核心功能仍然可用5只有在这之后，才开始构建
第四步比看起来更重要。在写任何新功能之前，Agent 启动应用并确认基础功能仍然可用——打开聊天、发送消息、获得回复。如果上一班留下了什么损坏的东西，这能立即发现，避免新的一班在不牢固的基础上堆叠新工作，让情况变得更糟。
这就是全部诀窍，简单得近乎无聊。离开的那班写下做了什么以及还剩下什么。到达的那班在做任何事之前先读这个。交接就是一切。
你的长任务也有轮班
这些实际上并非只关于构建 Web 应用。Anthropic 在代码上测试是因为代码易于验证，但底层的模式适用于你交给 Agent 的每一个长任务。
任何无法在一个窗口内完成的任务都有轮班。逐章写一份长报告、在十几个聊天中运行一个研究项目、花数天时间完成一个大分析。每次你为同一任务开始一个新会话，一个新工人就会在完全不记得上一个的情况下上班——如果你没有留下交接信息，它就会从猜测开始。
所以，留下一个交接信息吧。在长会话结束前，让模型写下完成了什么、还有什么未完成、以及下一个会话应该从什么开始接上。把这条便条放在它上班时会读到的地方。这就是一个项目每次会话都能向前推进，与每次都反复重建相同东西之间的区别。
今晚和明天的模型是一样的。唯一变化的，是明天的会话是盲目进入，还是读着昨晚的便条进入。
从来都不是班次有多聪明的问题，而是它为下一班留下了什么。
更多同类深度解析——https://t.me/+xYv1MgmIuds5YTli
