真正值得学习的并不是“1,000 个 Agent”这个数字，而是它背后的系统：任务可以从手机发起，在隔离环境中并行执行，由独立角色验证，并受到时间、成本和权限边界的约束。
读完这篇文章，你将理解三件事：
-
为什么并行数量从来不是最难的问题； -
怎样让 Agent 在无人值守时仍然可观察、可验证、可停止； -
如何从 5–20 个任务开始，逐步扩展到数百甚至上千个 Agent。
原文以 Boris Cherny 的日常工作流为例：如果不了解底层架构，这套流程听起来夸张到近乎不真实。
按照原作者的描述，他的主要操作界面是手机，而不是笔记本电脑；他会同时运行 5 到 10 个活跃会话。每个会话都能生成 Sub-agent：有时一次生成几百个；在处理更深层的任务时，有时会让几千个 Sub-agent 通宵运行。后台会持续运行数十个循环，其中一些即使在他的笔记本电脑已经关闭后，仍会继续在服务器端运行。
一千个 Agent 在无人值守的情况下通宵运行，而且还是通过手机触发——听起来仿佛需要一座数据中心和一支基础设施工程团队。
其实并不需要。
你只需要理解四个特定的架构组件。每个组件单独看都不复杂，但组合起来之后，便形成了一个从外部看似乎不可能实现、实质上只是持续贯彻良好系统设计的方案。
这是一门完整的课程。读完后，你将准确理解这种规模的无人值守工作是如何运转的，哪些具体组件让你可以放心地在睡觉时让系统继续工作，以及怎样从小规模开始搭建自己的版本，再根据实际工作需要扩展到 10 个 Agent，甚至真正的 1,000 个 Agent。
先说清楚：重点不是 1,000 个
对于大多数真实工作，没有人真的需要运行 1,000 个 Agent。这个数字本身并不是重点。
真正重要的是这样一种架构：它能够让任意数量的 Agent 在无人值守的情况下通宵运行，并由手机触发，同时确保整个过程可控，而不是演变成失控风险。
一旦拥有这样的架构，从 10 个 Agent 扩展到 100 个，再扩展到 1,000 个，主要取决于你手头究竟有多少工作能够真正并行，而不是要换成一套根本不同的系统。
本课程所讲授的架构适用于任何符合你实际情况的规模。1,000 这个具体数字来自一套真实且得到确认的工作流。你可以把它当成一个值得追求的上限，而不是第一天就必须达到的目标。
四个支柱：让无人值守从危险变成可信
在开始任何配置步骤之前，首先需要理解：如果要让 Agent 在无人值守的情况下通宵工作，同时保持可信而不是带来危险，必须满足哪些条件。
1. 移动端触发
你需要能够通过手机启动任务、检查任务并重新引导任务，而不只是查看任务状态。
这和一个只能发送通知的移动应用不同。你需要的是真正可以发送指令的界面，而不仅是接收状态更新的界面。
2. 隔离的并行执行
每个 Agent，或者负责同一项任务的一组 Sub-agent，都需要在自己的上下文和工作区中运行，同时不能踩到其他 Agent 正在进行的工作。
如果做不到这一点，同时运行许多 Agent 带来的将是混乱，而不是规模化。
3. 不需要你在场的验证机制
这是大多数人都会跳过的一环，也是所有需要在你睡觉时运行的任务中最重要的一环。
每个 Agent 的输出在被认定为完成之前，都必须依据真实事物进行检查。检查可以由另一个 Agent、测试套件或者明确的规则完成，而不能因为 Agent 自己声称“已成功完成”就相信它。
4. 硬性停止条件和成本上限
任何需要在无人值守状态下连续运行数小时的任务，都必须对时间、费用和工作范围设置绝对上限。这些限制不能依赖你亲自发现系统出了问题。
正是这一部分，把“Agent 通宵运行”从一种真实风险，转变为你真正可以信任的系统。
本课程的每个步骤，最终都是为了让这四个部分协同工作。如果缺少其中任何一个，系统要么无法扩展到少数几个 Agent 以上，要么会以一种可能真正伤害你的方式扩展——无论这种伤害体现在财务上，还是最终交付出去的东西上。
图 1：移动端触发、隔离并行、独立验证与硬性边界，四者缺一不可。
第一部分：手机不是监控器，而是控制台
移动端是这个难题中最近才得到解决的部分。要理解它为什么成为可能，就值得先弄清楚究竟发生了什么变化。
Claude 的 Dispatch 界面允许你通过手机与 Cowork 保持连续对话。它不是一个只读的状态页面，而是一个完整界面：你可以分配任务、检查进度，并重新引导正在执行的工作；真正的计算则发生在服务器端或你的桌面电脑上。
在这类界面出现之前，Agent 工作基本被限制在桌面端。你可以在离开电脑前启动某个任务，但在重新坐回电脑前，几乎无法再对它进行有意义的干预。
实际配置方法是：为你正在使用的 Agent 平台安装移动应用，而且这个平台必须支持真正的双向移动交互，而不能只支持推送通知。
请明确确认，你能够通过手机完成以下三件事：
-
从零开始创建一项新任务； -
查看正在运行的任务的详细状态； -
向正在执行的任务发送重定向或纠正指令。
如果你当前的系统只支持前两项，那么你还没有获得本课程所要求的移动端触发能力。你拥有的只是一个移动端仪表盘。它很有用，但两者并不是同一回事。
第一次完成配置后，可以在手机上运行以下测试提示词：
如果系统返回的是真实、具体的答案，而不是泛泛地说“一切都运行正常”，那么你的移动端触发功能才真正达到了这门课程所要求的工作方式。
第二部分：并行的前提是隔离
这一部分真正决定了你能否让大量 Agent 同时运行，而不让它们相互干扰。它可以进一步分为两个值得分别理解的层次。
单一会话内部的 Sub-agent 隔离
一个主 Agent 可以把复杂任务分解为更小的组成部分，然后部署多个 Sub-agent 分别执行。每个 Sub-agent 在自己的上下文中工作，而不必让所有任务争抢同一个连续对话的上下文空间。
这正是一个会话能够生成数百个 Sub-agent 的原因。Cherny 的工作流已经确认可以达到这样的规模，而整个系统不会因此崩溃成一团无法理解的混乱，因为每个 Sub-agent 的工作都与其他 Sub-agent 清晰隔离。
面向真正独立任务的 Git Worktree
有些工作彼此足够独立，更适合作为完全独立的会话运行，而不是作为同一会话中的 Sub-agent。对于这类工作，Git Worktree 可以让多个会话同时在不同分支或目录中运行，而不会因为某个会话尚未完成的修改，干扰另一个会话。
这就是同时运行许多并发、独立循环所依赖的底层工程基础。它不是让一个 Agent 工作得更快，而是让许多 Agent 真正同时处理彼此独立的事情。
实际判断规则如下：
如果一项工作需要实时查看另一项工作的状态，并在其结果之上继续构建，那么它应该作为同一会话中的 Sub-agent 运行。
如果两项工作真正相互独立，可以分别启动、检查和完成，而不需要知道对方正在做什么，那么它们应该作为独立会话，在不同 Worktree 中运行。
将大型任务拆分为隔离 Sub-agent 的提示词：
第三部分：Builder 不能给自己打分
这一部分决定了让 Agent 通宵运行究竟是真正的生产力突破，还是一个新的风险源。因此，它比本课程的任何其他部分都更值得认真对待。
这里的核心原则已经由 Anthropic 自己的 Harness Engineering 实践直接证实：永远不要让一个 Agent 给自己的工作打分。
模型在生成输出的同一上下文中审核自己的结果时，往往会给出偏正面的评价，即使人类审核者一眼就能看出其中的缺陷。
对于通宵运行的无人值守任务，这个问题比你实时观察的任务更加重要，因为在第二天早晨之前，没有人类处于循环之中，能够及时发现一份信心十足但实际上错误的“任务已完成”报告。
实际可用的架构是：把生产工作成果的角色和验证工作成果的角色分开。
Builder Agent 负责真正执行任务。另一个独立的 Judge 则负责检查工作。理想情况下，Judge 应该能够访问 Builder 没有接触过的内容，例如真实的测试套件输出、原始需求文档或实际执行结果。
Judge 必须依据真实证据检查工作，而不是重新阅读同一份输出，然后再形成一个新的主观意见。
适用于任何通宵任务的验证提示词模板：
对于真正高风险的通宵任务，还应该增加第二次独立验证。启动一个全新的会话或 Sub-agent，让它完全不知道工作是怎样完成的，然后从头开始，依据最初目标检查最终输出。
这种做法能够捕获一种特殊的失败模式：Builder 和紧随其后的自检过程拥有相同的盲点。
第四部分：停止条件必须成为硬规则
这是最后一个组成部分，也是第一次尝试让 Agent 通宵运行的人最容易忽略的部分。
每一项无人值守任务都需要三个明确限制。它们必须以硬性规则的形式写下来，而不能只是 Agent 可以自行解释甚至突破的软性建议。
第一，设置最长运行时间或最大迭代次数。达到限制后，任务应当停止并报告当前状态，而不是无限继续。
第二，设置最大成本上限。你需要根据所运行的 Agent 数量以及最坏情况下的 Token 使用量，提前计算这个上限。无论系统感觉距离完成只差多近，都不允许突破它。
第三，设置明确的范围边界。系统在没有先叫醒你的情况下，永远不能执行某些特定操作，例如部署到生产环境、删除数据、花费预先批准预算之外的真实资金，或者以你的名义发送外部消息。
每项通宵任务都应该加入以下停止条件模板：
工程提醒：提示词不是保险丝。 上面的模板定义的是任务合同，但真正的时间、成本与权限上限，必须由 Manager、调度器或运行时在代码层强制执行。模型不能拥有绕过硬限制的权限。
请在第一次真正的通宵运行之前计算最坏情况下的成本，而不是等运行结束后再计算。
将预期的并行 Agent 数量，乘以每个 Agent 在你配置的时间限制内可能消耗的最大费用。如果这个总数出现在真实账单上会让你感到惊慌，那么当前限制还不够严格。
应该在睡觉之前收紧限制，而不是在醒来面对账单后再处理。
第一次通宵运行：从 5–20 个任务开始
四个组成部分全部就位后，下面来看看一次真正的通宵会话是怎样组合起来的。我们会从现实可行的规模开始，而不是第一天就直接跳到 1,000 个 Agent。
睡觉前，通过手机或桌面电脑定义一批真正相互独立的任务，即这些任务不依赖彼此的输出。
第一次测试应该从 5 到 20 个任务开始，而不是 1,000 个。规模应该足够小，让你第二天早晨能够实际审核每一个结果。这样，你才能在把系统托付给更大规模之前，真正确认它是否按照预期工作。
对于每项任务，都要明确应用第三部分中的验证模板和第四部分中的停止条件模板。不能只是想当然地认为“它大概会正常工作”。
启动这一批任务。根据任务是否需要看到彼此的进度，可以把它们作为同一协调会话中的 Sub-agent 运行，也可以作为分布在不同 Worktree 中的独立会话运行。
然后去睡觉。
第二天早晨，通过手机上的 Dispatch 或你所使用平台的同类移动界面查看任务状态。
不要只检查任务是否报告成功，还要检查每项任务附带的验证证据，确认这些证据能否通过你自己的快速复核。
在最初几次运行中，早晨审核并不是可选项。你需要通过这种方式确认验证层确实能够发现它应该发现的问题，而不能在它尚未赢得信任之前就盲目信任它。
图 2：手机只负责发起与纠偏；Manager 编排任务，Builder 执行，Judge 用独立证据验证，硬性护栏约束整个运行过程。
扩展路径：20 → 200 → 1,000
当最初几批小规模任务能够稳定运行，验证机制可以在真实问题出现时发现它们，停止条件在测试中确实能够触发，而且成本始终保持在计算出的上限以内之后，继续扩大规模主要取决于你对系统的信心以及真正可并行的工作数量，而不是采用一套不同的架构。
真正重要的扩展纪律是：只有在你拥有一批具体、真实并且确实相互独立的工作时，才增加并行 Agent 数量。不要只是为了展示规模而扩展。
Cherny 所说的“一夜运行数千个 Agent”，专门发生在更深入的研究或探索工作中，因为这些工作值得同时尝试大量真正独立的路径。它不是一个不管每天晚上实际需要完成什么，都应该默认套用的数字。
随着规模扩大，应当持续跟踪任务升级率，以及触发成本上限的比率。这也是通常针对任何循环型系统所推荐的诊断信号。
如果越来越多的并行 Agent 在完成任务之前就触发停止条件，那么系统是在告诉你：应该先调整任务范围或限制，再继续增加并行 Agent。不要在一个已经开始挣扎的模式上继续叠加更多 Agent。
图 3：规模必须由验证可靠性、停止条件、成本控制和真实的并行需求逐级解锁。
一个中等规模案例：评估 100 个合作伙伴
为了让上面的架构更加具体，同时又不直接跳到 1,000 个 Agent 的极端规模，我们来看一次真正有用的 100 Agent 通宵任务会是什么样子。
这是一个现实的中间点。大多数搭建这类系统的人，在考虑是否还需要更多 Agent 之前，都可能先达到这个规模。
假设你正在研究一个包含大量真正独立子问题的宽泛主题，例如，依据一套明确标准评估 100 个潜在商业合作伙伴。
每个合作伙伴的评估都完全独立于其他合作伙伴，不共享状态，也不存在顺序依赖。这正是适合大规模并行处理的任务形态。
睡觉之前，你需要明确规定评估标准、第三部分所讲的验证标准，以及第四部分所讲的单 Agent 成本上限。你只需把它们定义一次，形成一个由全部 100 个 Agent 以完全相同方式遵守的模板。
接着启动 100 个会话，每个合作伙伴对应一个会话。每个会话都隔离在自己的上下文中，并携带同样的验证指令和停止条件。
通宵运行期间，每个 Agent 都会研究自己负责的合作伙伴，根据标准进行评估，并依据真实且明确引用的来源验证自己的发现，而不是依靠假设。
最终，它要么提交一份完整评估，要么明确标记“信息不足，需要人工审核”，绝不能把一个自信的猜测包装成研究结论。
第二天早晨，你通过手机查看 100 份结构化评估，而不需要亲自花费几天时间逐一研究 100 个合作伙伴。
被标记为不确定的评估应当优先得到你的直接关注。拥有有力且引用充分的研究发现，则只需要进行快速确认，而不需要从头完整复查。
这才是“1,000 个 Agent”标题的现实版本。
它不是让 1,000 个 Agent 混乱地处理 1,000 种不同类型的事情，而是让大量 Agent 针对大量相互独立的对象，执行同一种定义清晰、验证充分的任务。
这种工作形态才真正能够在这套架构下平稳扩展。
规模化最容易踩的四个坑
人们在尝试扩大系统规模时，会反复遇到一些具体错误。提前了解它们非常有价值。
在验证机制真正经过测试并获得信任之前扩大并行规模
如果你还没有确认验证层能够在包含 5 个 Agent 的小批次中发现真实问题，就让 100 个 Agent 通宵运行，那么你是在依据希望进行扩展，而不是依据证据。
把停止条件当成一种形式，而不直接测试它
在信任任何规模的任务批次之前，应该有意给一个测试 Agent 分配一项必然会触发停止条件的任务，然后确认系统确实能够干净地停止，而不是继续运行。
如果系统在小规模下没有按要求停止，那么它在大规模下同样不会停止。
为了让数字看起来更惊人，把真正存在依赖关系的任务并行运行
如果任务实际需要看到彼此的输出，就应该按顺序运行，或者在它们之间建立明确的协调机制。
把这些任务强行塞进纯并行执行，会产生不一致且难以调试的结果。并行只会帮助那些真正相互独立的工作。
系统稳定运行一段时间后，跳过早晨审核
当系统连续几周稳定运行后，自满才是真正的风险。
坚持通宵任务后的审核习惯，可以发现系统正在发生的漂移，例如验证标准悄悄变松，或者成本上限逐步上升。应该在它们演变成真正问题之前发现，而不是等问题发生以后再处理。
常见故障及其真正原因
人们第一次构建这种规模的系统时，遇到的大部分阻力都来自少数几个具体问题。提前知道解决办法，要比凌晨两点才发现问题好得多。
Agent 报告成功，但实际输出是错的
这几乎总是验证机制存在缺口，而不是底层模型的能力问题。
检查 Judge 或验证流程是否真正能够独立访问真实基准（Ground Truth），例如实际测试结果或原始源文档；还是仅仅重新阅读 Builder 自己写的摘要，然后不加判断地盖章通过。
如果验证步骤没有任何独立证据可以进行检查，那么无论提示词听起来多么复杂，它都会让那些自信但错误的工作通过验证。
手机端检查只显示模糊状态，而没有具体进度
这通常说明，在任务初始化时，你没有预先要求系统生成结构化进度报告。
应该明确要求每个 Agent 以一致、可解析的格式报告进度，包括当前步骤、适用时的完成百分比估计，以及遇到的所有阻塞问题，而不能任由格式随机变化。
移动端检查的价值，取决于它所汇总的信息本身是否拥有良好结构。
已经设置停止条件，但费用仍然高于计算出的上限
检查停止条件究竟是由 Manager 以机械方式检查并执行的硬逻辑，还是仅仅写在提示词中、模型可能会在完成任务的压力下通过推理绕过去的软指令。
在提示词里写一句“达到限制时停止”，和设置一个真正的代码级检查并不是一回事。代码级检查必须在达到限制后终止执行，无论系统感觉距离完成还差多近。
按相同标准评估的并行 Agent 给出了不一致结果
这说明不同 Agent 实际收到的模板指令存在差异，即使差异非常细微，而不是在整个批次中使用完全一致的副本。
只要不同 Agent 收到的验证标准或成功条件措辞不同，它们的输出就会产生差异，因为你实际上运行的是一组略有不同的评估，却期待它们产生一致结果。
系统在 10 个 Agent 时运行正常，扩展到 100 个时却崩溃了
这通常说明，在把任务划分为独立任务时，你忽略了某种真实依赖关系。
回过头去检查那些在更大规模下失败的任务，看看它们是否实际需要来自同一批次中另一个任务的信息或上下文。
大规模下的并行失败，通常是顺序问题。只是在同时运行的任务太少时，这种冲突并没有真正显现出来。
真正的成本：模型路由与失败预算
在把规模明显扩大到小型测试批次以上之前，值得先理解真实的成本结构。这样你是在有意识地做出选择，而不是事后才发现账单上的数字。
单个 Agent 的成本取决于你为该项具体任务选择的模型，而不是整个任务批次都以相同方式增长。
这正是本课程前面讲到的模型路由纪律，在大规模运行中直接产生回报的地方。
如果在 100 个 Agent 中，有许多任务其实足够常规，完全可以交给更便宜的模型，你却默认让全部 Agent 使用最昂贵、能力最强的模型，这将是导致通宵任务成本远高于必要水平的最常见原因。
应该只把最强的模型分配给批次中真正困难的 Sub-agent 或任务；对于常规且规范明确的部分，则路由到速度更快、价格更低，同时能够在直接、定义清晰的工作中同样可靠的模型。
在确定批次规模前，应当计算现实的单 Agent 成本范围，而不是采用乐观的最佳情况。
首先使用实际计划采用的配置，运行一批包含 5 到 10 个 Agent 的小规模测试。然后依据测试中真实发生的单 Agent 成本，预测完整批次的费用，而不是只根据文档进行估算。
真实使用模式、任务实际需要的工具调用次数，以及验证过程中需要多少次往返交互，往往会以重要方式偏离理论估算。当这个偏差再乘以 100 或 1,000 时，影响就会变得十分明显。
还应当为达到停止条件但没有完成的任务预留成本缓冲。
一项任务即使在没有完成的情况下运行到时间或迭代次数上限，依然已经产生了真实成本。如果一个批次中有相当比例的任务在达到限制时仍未完成，那么按每个已完成任务计算的成本，将高于简单的单任务估算。
如果测试批次中有很高比例的任务因达到限制而无法完成，说明你应该稍微放宽某项具体限制，或者缩小任务范围，而不能只把这种低效率当成规模化必然产生的成本。
最终价值：把白天的等待变成夜间批处理
这套系统的真正价值并不是那个听起来很惊人的数字，而是它实际替你拿回了多少时间。
过去需要数天手工完成的研究，可以被压缩成一次通宵运行；第二天早晨，你只需在喝咖啡时花 20 分钟审核结果。
那些过去会争夺你白天注意力的、相互独立且定义清晰的任务，可以在你睡觉时完成并得到验证。等你醒来后，需要做的是快速检查，而不是把所有工作重新做一遍。
这里值得再次提到 Cherny 自己的说法：“我们只完成了 1%。”
本课程所描述的具体架构——移动端触发、隔离的并行执行、真正的验证机制，以及硬性停止条件——并不是一套固定的最终系统。
它只是当前实践所处的状态。随着底层工具不断增强，这种实践也在持续演进。
请按照你今天实际拥有的工作，以诚实合理的规模把这四个部分搭建好。以后，当你真正拥有足够多的并行工作、值得继续扩大规模时，扩展过程依赖的将是你对一套已经经过测试的系统所建立的信心，而不是一次跳向未知世界的冒险。
参考资料
原始长文：How to Run 1,000 AI Agents Overnight From Your Phone – full course
地址：https://x.com/cyrilXBT/status/2087004391777656878
Claude Code 官方文档：Create custom subagents
地址：https://code.claude.com/docs/en/sub-agents
Git 官方文档：git-worktree
地址：https://git-scm.com/docs/git-worktree
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
