编排 Claude Code 智能体：幕僚长模式

📌 One-Sentence Summary 一份实用指南，介绍如何以编排者-执行者模式运行长周期 Claude Code 工作：一个会话负责协调与验证，其他会话负责执行，并由一块持久化看板保存状态。 📝 Summary 长时间运行的 AI 编程会话之所以失败，并不是因为智能体不会写代码，而是因为上下文是短暂的，且自我汇报不可靠。作者提出了幕僚长模式：一个长期存在的协调会话从持久化看板拉取工作、撰写任务简报、通过重新运行命令来验证声明、阅读 diff，而独立的短生命周期会话负责实现。这种模式在其他地方也被称为编排者-执行者、协调者-实现者-验证者，或 maker-checker。文章详细介绍了运行循环（拉取、阅读、红门、委派、证明、观察、门禁、交付）、将每份智能体报告视为证据而非指令的验证纪律，以及一系列失败模式目录，例如空洞断言、静默无匹配和错误引用。文章还涵盖了实用机制，例如验证被启动的会话是否真的启动、使用持久化通道而非短暂消息，以及用时间盒来暴露进展而非停止工作。作者认为，协调开销正是重点：你买到的是信任结果的能力。 💡 Main Points 将编排与执行分离，才能让长周期智能体工作变得可靠。 单个会话大约一小时后就会退化，原因是上下文压缩、自我汇报漂移以及经验教训丢失。让一个协调者负责撰写简报、验证声明并阅读 diff，同时由独立会话负责实现，可以防止整个模式坍缩为一个过载的会话。 把状态放在持久化的外部存储中，而不是对话上下文里。 带有 API 的看板或任务系统能够经受压缩、会话死亡和交接。任务充当构建契约，包含问题陈述、接口和验证标准，状态随工作原子式翻转，而不是在最后批量更新。 把每份智能体报告都当作证据，而不是指令，并重新运行其声称已执行的命令。 智能体汇报的是意图和回忆，而不是新鲜观察。协调者必须重新运行命令并信任退出码，因为被报告的对象和被检查的对象常常不是同一个东西，例如提交哈希是针对 shell 变量验证的，而不是针对文件内容验证的。 最常见的缺陷类别，是某个工具为它并未完成的工作报告成功。 空洞断言、静默无匹配、报错的检查、错误引用、过期前提和范围不匹配，都会产生绿色结果却什么也没有证明。防御措施包括让零计数与失败可区分，以及在相信否定结论之前先证明肯定结论。 持久化通道胜过短暂通道，时间盒应当暴露进展，而不是停止工作。 直接消息可能延迟、被扣留或过期，因此任何必须送达的内容都要放进已提交的文件或看板卡片中。时间盒决定的是多久汇报一次，而绝不是在哪里停止；在事项中途切断，会让工作停留在半应用、未验证的状态。 💬 Key Quotes 解决办法是组织性的，而不是技术性的：一个会话负责协调与验证，其他独立会话负责执行，一块持久化的外部看板保存状态，每一条声明在被相信之前都要重新运行。 把每份智能体报告都当作证据，而不是指令。 智能体工程中最常见的失败，是某个工具为它并未完成的工作报告成功。 消息是提醒。文件是契约。 衡量它是否奏效的标准，不是写了多少代码，而是无论何时你都能问「这项工作现在处于什么状态？」并得到一个真实的答案。 📊 Article Meta AI Screening： 90 Featured： Yes Source： Hacker News: Front Page Author： Mithushan Jalangan Category： 软件编程 Language： 英文 Read Time： 15 min Word Count： 3739 Tags： 编程与工程 , AI 编程 , 开发者工具 , 上下文工程 , Agent编排 Read Full Article