工具循环、状态与长任务

Anthropic 在《Effective harnesses for long-running agents》（2025-11-26）里打了个比方：长任务就像工程师轮班，每个新来的人对上一班发生了什么毫无记忆。

只靠压缩（第 27 讲（压缩与隔离））够吗？不够。他们让 Opus 4.5 在 Claude Agent SDK 里循环跑多个窗口，任务是「做一个 claude.ai 的克隆」，结果还是做不成。他们观察到两种失败：

1. 想一口气做完：一次做太多，做到一半上下文用完，留下一个半成品，而且没有记录。下一班只能猜上一班干了什么。
2. 过早宣布完成：后来的 Agent 看到已经有不少功能，就宣布「做完了」。

另一篇《Harness design for long-running application development》（2026-03-24）补充了两种现象：

• 窗口越满，模型越容易失去连贯；
• 有的模型会出现「上下文焦虑」：感觉快到上限时，提前草草收尾。

第 1 个会话：初始化智能体（initializer agent）

用一段专门的提示词，让第一个会话只搭架子、不写功能：

• 写一个 init.sh 脚本，用来启动开发服务器；
• 写一份功能清单 feature_list.json：200 多个功能，全部标为未通过；
• 建进度文件 claude-progress.txt；
• 做第一次 git 提交。

之后的每个会话：编码智能体（coding agent）

每次只做一个功能，结束时留下结构化的更新。

文章脚注说：这两个「智能体」其实只是第一条用户提示词不同，系统提示词、工具和 harness 完全一样。

演示：功能清单长什么样

下面是一个示例（保留 JSON 格式，并附中文说明）：

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": [
    "Navigate to main interface",
    "Click the 'New Chat' button",
    "Verify a new conversation is created",
    "Check that chat area shows welcome state",
    "Verify conversation appears in sidebar"
  ],
  "passes": false
}

（大意：「新建对话」按钮会创建一个新会话；验证步骤是进入主界面 → 点按钮 → 确认新会话出现 → 欢迎状态显示 → 侧边栏出现这个新会话。）

三个设计细节：

• 只允许改 passes 字段。提示词里写得很重：删除或修改测试是不可接受的，因为那会导致功能缺失或出 bug。
• 用 JSON 而不用 Markdown：他们发现模型不太会乱改 JSON 文件。
• 清单就是「完成的定义」，防止过早宣布完成。还有 passes: false 的项，就没做完。

演示：一个编码会话的开场流程

文章给出了每个编码会话固定的开场步骤：

1. pwd：看看自己在哪个目录；
2. 读 git 日志和进度文件，了解最近做了什么；
3. 读功能清单，挑优先级最高的未完成功能；
4. 运行 init.sh 启动开发服务器；
5. 先跑一遍基本的端到端测试，确认应用没被上一班弄坏，再开始新功能。

文章里的示例记录大致是这样（节选改写）：

[助手] 我先了解一下项目的当前状态。
[工具] pwd
[工具] 读 claude-progress.txt
[工具] 读 feature_list.json
[工具] git log --oneline -20
[助手] 检查有没有重启服务器的 init.sh……
<启动开发服务器>
[助手] 先确认基本功能还正常……
<测试基本功能>
[助手] 基本功能正常。接下来看清单，决定下一步做什么……

第 5 步很关键：如果上一班留下了 bug，先修 bug，再做新功能，避免在坏地基上继续盖楼。

会话结束时：用描述清楚的提交说明做 git 提交，并更新进度文件。下一班就能从 git 日志接上；改坏了，也能用 git 回退到上一个好的版本。git 提交就是检查点。

测试：要像真人一样测

文章发现，Claude 经常改完代码、跑个单元测试或 curl 一下，就把功能标成通过，实际在浏览器里根本不能用。给它浏览器自动化工具（Puppeteer MCP），要求「像人类用户一样」端到端测试后，效果大幅改善。局限：它看不到浏览器原生的弹窗（alert）。

四种失败与对策（对照表）

《Harness design》比较了两种跨窗口的方式：

他们的经历说明选择取决于模型：

• Sonnet 4.5 的上下文焦虑很严重，光靠压缩不够，必须重置；
• Opus 4.5 基本没有这个问题，于是他们去掉了重置，改用 SDK 的自动压缩。

交接物（handoff artifacts）就是重置时传给下一个 Agent 的东西：进度文件、功能清单、git 历史、规格文档。交接物写得好不好，决定了新 Agent 能不能顺利接上。

《Harness design》里有一组对比：同样做一个「复古游戏制作器」，单个 Agent 直接做，和用完整 harness 做。完整 harness 包括规划者、生成者、评估者三个角色，第 36 讲（权限、沙箱与错误恢复）细讲。

贵了 20 多倍，但只有后者真正可用。

演示：读懂一张长任务账单

后来用 Opus 4.6 做「浏览器里的音乐制作软件（DAW）」时，他们公布了每个阶段的耗时和花费：

怎么读这张表：

1. 构建花费合计 71.08 + 36.89 + 5.88 = 113.85 美元，约占 91%。钱主要花在干活上。
2. QA 合计 3.24 + 3.09 + 4.06 = 10.39 美元，约占 8%，但它抓出了只有界面、没有真实功能的「样子货」，比如录音功能只是个空壳。用 8% 的钱换来「真能用」，很划算。
3. 每轮构建越来越短，说明 QA 反馈让后面的修复更有针对性。

《Harness design》里有一句很重要的话：

Every component in a harness encodes an assumption about what the model can't do on its own.

（harness 里的每个组件，都暗含一个「模型自己做不到某事」的假设。）

模型升级后，这些假设可能不再成立。他们的做法是一次去掉一个组件，看效果有没有变差：

• 换到 Opus 4.6 后，去掉了冲刺（sprint）结构，模型自己就能保持连贯；
• 保留了规划者，没有它，生成者会把范围做小；
• 评估者从每个冲刺都检查，改成最后检查一次。

结论：新模型发布时，要重新审视 harness。不再需要的部分就拆掉，它们只会增加成本。这和第 34 讲（Harness 是什么）说的「harness 有一部分会被模型吸收」一致。

• Justin Young（Anthropic）, Effective harnesses for long-running agents, 2025-11-26：anthropic.com
• Prithvi Rajasekaran（Anthropic）, Harness design for long-running application development, 2026-03-24：anthropic.com