上下文再长，也绕不开一个老问题：交接 。上一轮干了啥、做到哪、坑踩到哪了，下一轮往往并不知道。Anthropic 这篇写得比较直：把"长程执行"从"靠模型记"改成"靠工程交接"------用 git + feature list + progress 把状态摆到明面上，让每一轮都像接手一个还能继续合的分支，而不是从零猜现场。[1]
先看主线
- 主线：为什么会断档 -> 怎么分工 -> 交接制品是什么 -> 哪些场景值得用全套。
- 跳读位 ：文内
### 深度解析与「官方叙事与可核对事实」。
一、背景：长程任务为什么会"越跑越乱"
长程任务要跨多个 context window 、多段会话；新会话默认不记得 上一段发生了什么------像轮班 时新人到岗却零交接。[1]
Compaction 等上下文管理能延长单次窗口，但原文指出：单靠 compaction 不够 ；即便强模型在多窗口循环里只拿一句高层 prompt，也容易做不满生产级交付。[1]
二、演进：从"一个 Agent 跑到底"到"初始化 + 增量接力"
一口吃成胖子 ：一次想实现太多，窗口中途耗尽；下一班接手时功能半截 、无文档 ，只能猜与返工。
过早宣布完工 ：后面某次实例看到「已有进展」就误判项目完成。[1]
拆解为两件事：先搭好能支撑全量需求 的初始脚手架，让后续按功能增量 推进；每段结束把环境留在可合并主分支的干净状态------无明显大坑、结构清晰、他人可接着做新功能。[1]
三、机制：Initializer + Coding 到底在分担什么
面向 Claude Agent SDK （官方文档 · 概览 ）的双折做法（同一套 harness / 工具 ，仅首轮用户 prompt 不同 ------见原文脚注）。可跑代码 在 GitHub anthropics/claude-quickstarts 的 autonomous-coding 目录，便于对照首轮脚手架与后续增量 prompt。[1][2][3]
多窗口工作流的更多 prompt 结构，另见官方 Claude 4 提示指南 · Multi-context window workflows。[1][4]
Initializer agent（首轮） ：专用 prompt，初始化环境------例如 init.sh 、 claude-progress.txt （各轮做了什么的日志）、以及展示新增文件的 初始 git commit 。
Coding agent（后续每轮） ： 增量推进，并留下结构化交接物。[1]
说白了跟人上班一样：交接靠 git + 进度说明。[1]
3.1 环境四件套（深化）
1. Feature list
Initializer 把用户一句话需求扩成结构化功能清单 （文中 claude.ai 克隆示例量级为 200+ 条细粒度行为），初始 passes: false ，避免「以为做完了」。用 JSON 承载（实验上比 Markdown 更不易被模型误改）；Coding agent 只允许改 passes 等状态，并用强约束禁止乱删测试项。[1]
深度解析：功能清单 vs 产品验收
事实：原文用 JSON feature list + git + progress。[1]
原文观点：防假完工。[1]
本文解读 ：清单通过 ≠ 用户体验通过------E2E 与可访问性 仍可能缺项；宜在清单外保留 少量「冒烟路径」 人工或自动门禁。
2. 增量与干净收尾
一次只做一个 feature ；改完要求 git 提交 （信息可读）+ progress 摘要，便于回滚与恢复可工作状态。[1]
3. 测试
若不显式要求，模型容易「改了代码甚至跑了单测」却仍未端到端验证 。文中 Web 场景在明确要求用浏览器自动化、按人类路径测 后表现明显提升（Puppeteer MCP 截图等）；视觉与自动化仍有盲区 （例如浏览器原生 alert 类问题更难发现）。[1]
3.2 每轮上岗「先摸清现场」
文中建议会话开场固定套路（节选）：[1]
pwd确认可写目录；- 读 git log 、claude-progress.txt；
- 读 feature 列表 ，选最高优先级未完成的一项；
- 配合 init.sh 起 dev server，必要时先做基础 E2E 冒烟，确认上一棒没留「坏掉的主路径」再开新功能。
文中给出典型会话开头对话模板（Assistant / Tool 交替）。[1]
3.3 失败模式对照
原文表格概括：过早完工 / 脏状态 / 假完成 / 不会起服务 等与 Initializer、Coding 各自职责的对应关系------核心是 清单 + git + 进度文件 + 可重复启动与测试。[1]
四、应用边界：这套方法在哪些任务最值钱
- 单一 coding agent 和多 agent 分工（测试、QA、清理）哪个更优，仍是开放问题。
- 当前示例偏全栈 Web；迁移到科研或金融建模时，需要替换等效的测试与验收基元。[1]
官方叙事与可核对事实：demo 叙事与「你的长程域」
事实：示例偏 Web 与 Claude Agent SDK。[1]
原文观点：清单+git+进度可迁移。[1]
本文解读（推断） ：金融/科学建模的「功能清单」可能难以穷举 ------需配合 领域模型与仿真，否则 harness 只剩形式。
结论与讨论
技术坐标
一句话收尾：长程 Agent 先把交接跑通，再谈"更聪明"。把状态外化到 git + 结构化清单 + 进度文件，等于把 Agent 拉回能复盘、能回滚、能续写的工程轨道。
批判性问题
- 多会话 身份与密钥 是否泄漏在 progress / 日志？
- JSON 清单 谁有权改 schema------模型还是人？
- E2E 自动化 假阴性（如 alert 框）如何进清单？
独立判断（事实 / 原文观点 / 本文解读）
| 类型 | 内容 |
|---|---|
| 事实 | 原文 URL；Initializer/Coding 双 prompt 与四件套为文内方案。[1] |
| 原文观点 | compaction 不够；交接靠工程制品。[1] |
| 本文解读 | 最可迁移的是 状态外化 + 小步可合并 ，而不是具体 demo 形态。批判性补一句 ：demo 里 200+ 条 feature 是「防一口吃完」的极端示范；小任务硬抄全套会 治理过载 ------可先借 git + progress + 冒烟 三板斧，清单粒度按团队承受力缩放。[1] |
参考文献与延伸阅读
-
1\] Effective harnesses for long-running agents --- Anthropic Engineering，2025-11-26
-
3\] claude-quickstarts / autonomous-coding --- **GitHub** 示例，对应文中 quickstart
-
5\] Building effective agents --- harness 总览，和本篇互补