一个 Agent 连续干了四个小时，写了不少代码，跑过测试，还留下了几条看上去挺像样的日志。第五个小时，新会话接手。它看着半成品，猜错了前一轮的意图，又补了一层实现，最后把原本能启动的服务弄挂了。

这不是模型突然变笨了。

这是一次没有交接班的工程事故。

Anthropic 最近公开了一篇很值得开发者细看的工程文章 Effective harnesses for long-running agents。它没有宣传某个模型又能自主干几天活了，反而承认了一件更接近现实的话，哪怕是把 Opus 4.5 放进 Agent SDK 的循环里，只有一句「做一个 claude.ai 的 clone」这种高层需求，也造不出生产质量的 Web 应用。

我挺喜欢这种承认。因为今天很多 Agent 演示最容易把人带偏的地方，正是把一次漂亮的长轨迹，当成了可重复的工程能力。

模型能写代码，只是起点。一个任务跨过多个 context window 之后，谁来保存项目状态，谁来约束它别乱改验收标准，谁来在新功能之前发现旧功能已经坏了，这些问题才决定一个 Agent 是临时的代码生成器，还是能进入研发流程的协作者。

这篇文章给出的答案不玄乎。它把成熟工程团队每天都在做的交接、验收、提交和回归测试，认真地做成了 Agent 的工作环境。

先别迷信长上下文，断片才是常态

很多人看到 context window 变长，会自然推导出一个结论，既然模型能记住更多东西，长时程 Agent 的问题就快解决了。

我觉得这个判断有点乐观。

长上下文解决的是一次会话里能装下多少信息，不等于它自动拥有一个可靠的项目记忆。真正的工程任务会持续数小时甚至数天，期间有依赖更新、服务重启、测试失败、需求调整，也会有那种很烦的半完成状态。人接手一个仓库都要先看 issue、提交记录和运行说明，凭什么要求一个新 Agent 会话一眼看懂昨天的残局。

Anthropic 在内部实验里观察到两个典型失败。第一个是 Agent 想一口气把应用全做完，context 用完时正卡在半个功能里。下一轮没有明确交接，只能先花时间猜项目到底能不能运行。第二个更离谱，后续 Agent 看到页面已经有点样子，就宣布整个项目完成。

这两个问题听着很像模型问题，其实更像流程设计没有把失败当回事。

如果团队里每位新同事到岗时，既看不到昨天的进度，也没有待办清单，还允许自己修改验收标准，这个团队也会很快失控。Agent 只是把这个荒谬的协作方式放大了。

所以这篇文章的第一层价值，不是教你多写几句 Prompt，而是提醒我们换一个视角。不要问「这个模型能连续工作多久」，先问「它每次失去上下文后，能不能用低成本恢复正确的工作状态」。

后一个问题更工程化，也更难糊弄。

把初始化和干活拆开，给第一轮一个完全不同的任务

Anthropic 的方案用了两个角色。名字听起来很朴素，一个 initializer agent，一个 coding agent。它们不一定要是两套不同的模型或工具，关键在于第一轮和后续每一轮收到的任务根本不该一样。

第一轮不急着堆功能。它要搭一个让后来者能工作的现场。

在官方的 claude.ai clone 实验中，initializer 会生成一个 init.sh，用于统一启动开发环境。它还会留下 claude-progress.txt 记录已经完成什么、当前有什么风险，并做出第一个 Git commit。更重要的是，它会把原本很宽泛的需求拆成一份完整的 feature_list.json。

这份列表里有两百多条端到端功能。每一条不只是一句「支持新建聊天」，还会写清用户怎样操作、应该看到什么结果，并把 passes 先标成 false。

这份文件的地位很像测试计划，也像一份不能随便动的合同。

文章里有个细节非常实在。后续 Agent 被明确要求，只能修改 passes 的状态，不能删除或改写测试定义。Anthropic 经过试验后还发现，JSON 比 Markdown 更不容易被模型随手重写。看起来只是文件格式的小选择，背后却是在防一件常见的事，Agent 不是把功能做完，而是把完成的定义改简单。

你想想看，很多自动化翻车都不是执行失败，而是评判体系被执行者悄悄污染了。对于能修改文件、修改测试、修改配置的 Coding Agent，这条边界必须显式写出来。

第一轮的职责，是把模糊意图压缩成可续跑的工程状态。后面的每一轮，才是在这个状态上推进一个明确的小目标。

一次只做一个 feature，慢一点反而更快

有经验的开发者大概都见过这种 PR。标题写着改一个按钮，实际顺手重构了状态管理、改了路由、升级了依赖，最后 reviewer 根本不知道该从哪看。

Agent 也很容易干这事，而且速度更快，破坏面也更大。

Anthropic 要求 coding agent 每一轮只挑一个最高优先级且还没通过的 feature。先实现，再做端到端验证，确认无误后才把 passes 改为 true。结束前更新进度文件，再做一个带描述的 Git commit。

这套动作没有任何魔法，却正好卡住了长时程任务最危险的扩张冲动。

一次只完成一个 feature，表面上损失了并行感，实际换来了三样很贵的东西。改动范围小，失败时更容易定位。每轮都有可恢复点，下一轮不用从废墟里考古。更关键的是，项目完成度不再取决于 Agent 自己的主观感觉，而是取决于还剩多少验收项没有通过。

对于 Java 和 Spring 项目，这个思路尤其能落地。把一个大需求拆成接口契约、迁移脚本、服务层行为、异常分支、前端交互和可观测性检查。每一项都写成用户或调用方能验证的行为。别给 Agent 一张「把订单模块做好」的纸条，让它自由发挥。

可以把验收项写成下面这种人话，而不是技术实现的愿望清单。

  • 用户重复提交同一个幂等键，只会生成一笔订单
  • 库存不足时，接口返回可识别的业务错误，事务不会留下半条记录
  • 服务重启后，未完成的补偿任务仍能被扫描到
  • 管理员在页面上能看到失败原因，而不只是一个红色的失败提示

这样的清单未必优雅，但很抗误解。Agent 选错框架、写错分层，至少还会被行为验收拦住。

回到主线，长时程 Agent 的单位不该是一段很长的对话，而应该是一个可以独立验证、可以安全交接的小闭环。

Git 和进度文件不是文档，它们是 Agent 的外部记忆

很多团队把 Git 当作代码备份，把日报当作管理动作。放到 Agent 工作流里，这两个东西需要换个身份。

它们是跨 context 的记忆系统。

每次新会话启动，Anthropic 建议 Agent 先确认当前目录，读取进度文件和功能列表，再看最近二十条 Git commit。然后用 init.sh 拉起服务，跑一遍最基础的 smoke test。官方案例会让 Agent 新建聊天、发消息、收到回复，确认核心流程没有断，再去碰下一项功能。

为什么顺序这么死板。

因为先动手再确认现场，是最容易让问题滚大的方式。假如上一轮留下的服务已经坏了，你直接开始新功能，最后看到的失败可能来自旧 bug，也可能来自新改动。到那一步，Agent 很可能为了让测试变绿，做出更多没有根据的修改。

人类开发里有一句有点土但一直有效的话，先让基线绿起来。

Agent 更应该遵守。它没有疲劳感，却有很强的继续行动倾向。你不给它一个「发现基线坏了就先停下修复」的关卡，它就会把每一轮当成新战场。

claude-progress.txt 也不该记流水账。比较有用的内容是本轮完成的 feature、验证命令或验证路径、已知不稳定点、下一轮推荐从哪一项开始。Git commit 则负责保留代码级的因果线索。二者放在一起，才让新会话既能知道「改了什么」，也能知道「为什么到这里停」。

这和 LangGraph 一类 Agent 框架里的 checkpoint 有点像，但工程仓库不能只存序列化状态。真正能让人和 Agent 都接得住的，是可读的进度、可回退的变更、可执行的启动方式，再加一份不会被随手漂移的验收契约。

单测全绿，不等于 Agent 真的把功能做出来了

这部分我特别认同。

Anthropic 观察到，Claude 如果没有被明确要求验证，通常会改代码、跑 unit test，或者用 curl 打一下开发服务，然后就把 feature 标成完成。但用户真正点击页面时，流程仍可能断在某个状态、某个按钮，或某个错误处理分支。

这并不稀奇。单元测试验证的是局部假设，curl 验证的是一个 HTTP 响应。用户看到的是一条穿过浏览器、接口、状态管理、权限和数据的完整路径。

文章的做法是给 Agent 浏览器自动化工具，并要求它像用户一样进行 E2E 测试。官方示例使用 Puppeteer MCP 截图，让 Agent 能发现只读代码时看不出的 UI bug。Anthropic 的结论也很克制，加入这类工具后表现明显改善，不是所有问题都消失。

比如 Puppeteer MCP 看不到浏览器原生的 alert modal。依赖这种弹窗的功能仍然更容易出错。这个限制很值得写在流程里，别把截图能力当成万能 QA。

如果你在给 Spring Boot 服务接 Agent，我会建议把验证分成三层。第一层是编译、单测和静态检查，便宜而且快。第二层是接口级集成测试，确认数据库、消息队列和鉴权这类边界没有破。第三层才是 Agent 以真实用户路径做的 E2E 验收。

缺任何一层都可能出事。

尤其不要让同一个 Agent 既随意改测试，又根据自己改过的测试宣布成功。测试可以协助生成，验收边界需要由团队保留控制权。这话听着保守，但在能自主执行的系统里，保守不是效率的反义词，是不返工的前提。

真正要设计的不是 Prompt，是一个能交接的工作台

这篇文章最容易被误读成「两个 Agent 加一份 JSON 就能做长时程开发」。不是。

Anthropic 自己写得很清楚，这仍是内部实验的方案，目标场景主要是全栈 Web app。compaction 也不是万灵药。单一通用 coding agent 是否优于测试、QA、清理各自分工的多 Agent 体系，文章也没有下结论。

所以别急着把现有 CI/CD 推倒重来。

更现实的起步方式，是先找一类边界清楚、可回滚、验收标准明确的任务。比如给一个 Spring 服务补一组管理后台页面，给内部平台增加一个完整的 API 流程，或者把积压的小需求整理成 feature list。让 Agent 在受限目录和命令 allowlist 里工作，强制经过 Git commit 和 E2E 验收。观察几周，再判断它究竟省下了哪些时间，又制造了哪些新成本。

我自己的判断是，Agent 时代最稀缺的能力会慢慢从「把 Prompt 写得更长」变成「把工作拆成可验收的交接单元」。需求写得清不清、状态留得全不全、验证是不是贴着真实用户路径，这些原来就重要，只是以前一个人脑子里能兜住的东西，现在必须显式交给系统。

那位第五个小时接手的 Agent，真正需要的不是更长的上下文。

它需要一间收拾干净的工位，一张不能擅自涂改的验收清单，和一条已经跑通的回归路径。

这才是让 Agent 继续干活，而不是继续猜的开始。

参考资料