Claude自己组队查Bug

单Agent最好的一次，找出27个Bug。 换成Claude自己组队，连跑三次，每次都查出66个。

这是Anthropic刚公布的一组测试结果：在11.6万行代码中预先埋入70个Bug，让单Agent和动态工作流各跑三次。 结果，单打独斗，最好也没查出四成；而组队协作，三次都查出了九成以上。

Anthropic公布的单Agent与动态工作流查错结果对比。 这组结果背后，是Claude开始自己安排分工、组织多个Agent协作。 10月10日，Claude Managed Agents动态工作流开启公测。 有了这项功能，主Agent接到任务后，可以自己编写分工程序，安排其他Agent分阶段完成任务，最后汇总结果。 同一天，Claude Code Projects也扩大了公测范围：所有此前加入等待名单的Pro和Max用户，现在都已获得使用资格。

在Projects里，你可以围绕一个项目持续提出需求，Claude负责拆任务、协调多条线程并行推进。 一个让开发者把多Agent协作接进自己的应用，一个让用户在项目对话里直接交代工作、跟进进展。 两项更新指向同一个变化：除了执行任务，分活、盯进度、交接结果，这些原本需要人来操心的事，Claude也开始接手了。 你提目标 Claude自己分活 同时开几个AI窗口不难。 麻烦的是，给每个窗口重讲一遍背景，把一边的发现送到另一边，再挨个追问：做到哪了，卡在哪里，还缺什么？ 窗口越来越多，人反而忙成了传话员。 Projects想接下这部分工作。 你在同一个项目对话里持续提出需求，Claude判断该新开一条任务线程，还是交给已经在处理相关工作的线程。 每条线程可以理解为一段独立推进任务的工作对话。

Projects协调对话与任务总览 Anthropic举过一个例子：让API、网页端和移动端一起停用旧接口。 这件事涉及多个代码仓库，各处修改还得互相配合。 Claude可以按代码仓库拆出任务，分别修改、运行测试、提交代码合并请求，再告诉你哪些改动需要先合并。 每条云端线程有自己的上下文和代码副本，在自己的分支上工作，再把结果报回项目对话。 你仍能进入某条线程看细节、纠正方向。项目总览则把正在工作、等待你回答、可以审查的任务分开列出。 如果离开一会儿再回来，你也不必挨个窗口问进度，可以直接从需要你处理的地方接上。 要省下反复沟通的时间，之前交代过的事就必须记得住。 Projects会积累项目记忆。 需求改了什么、做过什么决定、哪些地方踩过坑，都可以记录下来，供后续云端线程读取。 官方举了一个日常工作场景：发布日期改到了周五，某项功能为什么被砍掉，修改某个服务前要先找谁确认，这些信息都可以留在项目记忆里。 资料库也会保存上传的资料和Claude生成的文件，让后续任务接着已有成果往下做。

需求分配到右侧线程，相关决定和工作结果逐步积累，供后续任务使用。 新版Projects在9月17日已开启分批公测。 这次扩大的是准入范围，功能本身仍处于公测阶段，尚未报名的用户仍可加入等待名单。 云端线程可以在合上电脑后继续工作。需要本机工具或本地数据库的任务，也能通过Remote Control在电脑上运行，但电脑必须保持唤醒。 项目有人协调之后，一项复杂任务内部又该怎样分工？ 300份合同 把分工写成程序 Managed Agents动态工作流，处理的就是这类问题。

官方给出了一个具体任务示例： 检查300份合同，找出哪些包含控制权变更条款，也就是公司控制权发生变化时，合同该如何处理的约定。 逐份读懂已经很费工夫，还得确保每份都查过、结论有据可查，漏掉的也能及时补查。 Claude会为任务写出一段工作流程序，安排哪些Agent读材料、哪些步骤处理结果，以及后续怎样继续。

合同阅读任务并行展开，再进入核对与汇总 分工和交接都写进了程序，可以直接运行。 一个Agent读完材料，结果交给程序。程序再把结果传给后续Agent，或者据此决定下一步走哪个分支。 需要反复修改的工作，也能把循环安排进去。 官方文档举的例子是稿件审校：持续修改，直到审核通过，或者达到预设轮数。 普通子Agent委派中，主Agent要读汇报、接着决定下一步。动态工作流则把大量中间交接写进程序，在后台推进。 等待期间，主Agent仍可以和用户交流、查看进度。运行结束后，再读取结果，答复用户或发起下一轮工作。 不过，工作流中的线程交回结果后，主Agent不能像调用普通子Agent那样，继续向同一线程追问。因此，核对和返工最好提前安排进流程。

官方的合同审查指令样例就规定： 第一轮，每份合同交给一个Agent；第二轮，由另一个Agent重新检查全部合同，连首轮未发现目标条款的也不能跳过；复核未通过的，返工后再次复核。 这给首轮漏掉的条款，多留了一次被发现的机会。 当然，合同案例展示的是工作方式。 Anthropic并未在那组Bug测试帖子中披露具体分工，不能据此认定，这66个Bug也是通过同样的流程找出来的。 1000个Agent 也要排好队 单次最多1000个Agent，是这次公测最抢眼的数字之一。

它指的是一次工作流在整个运行期间，累计最多启动1000个Agent。 当前文档列出的同时工作线程上限为64，官方也说明，这个并发数可能调整。 工作流可以一批接一批地执行，也可以等前一阶段交回结果，再安排后一阶段。 每个Agent有独立的对话历史，同时共享会话中的文件和沙箱，也就是运行代码、处理材料的工作环境。 开发者可以提前配置专门的Agent，也可以让工作流根据任务需要临时定义。 接入时，在multiagent配置中将type设为multiagent_20261001，再配置模型、工具和任务要求。

启用动态工作流后，向Claude交代任务，便可让它编写分工计划。图中示例为筛查300份合同中的控制权变更条款。 不过，会分工还不够，还得把没做完的地方交代清楚。 官方的一条指令样例要求：某个Agent读不了合同，就把这份合同列为「未覆盖」，其余任务继续。 「没查出问题」和「根本没查到」必须分开。否则，一份整齐的汇总，很容易把任务缺口藏起来。 开发者可以查看运行阶段和各条线程的记录，沿着记录定位问题。

以合同审查为例，开发者可以跟踪阅读、核对等阶段，并查看每条任务线程的执行记录。 Agent多了，既要安排好执行顺序，也要看清哪些任务完成了、哪些仍有缺口。 需要区分的是：最多启动1000个Agent、三次均查出66个Bug，说的都是Managed Agents动态工作流，并非Projects。 省下协调时间 账单继续跑 回到开头的测试：单Agent三次找出14、15、27个Bug，动态工作流三次都是66个。 查出的Bug更多了，但为此多花了多少时间和费用，还不清楚。 官方没有披露所用模型、实际Agent数量、耗时、Token用量和误报情况，暂时还无法判断这套工作流是否更快、更划算。 实际使用时，两项功能的费用也要分开看。 Projects使用现有套餐额度，工作线程和协调对话都会消耗用量。并行任务越多，额度也会用得越快。 用户可以调整模型和推理强度，或让Claude少开一些线程。通常，工作线程达到套餐用量上限后会暂停，等额度重置再继续。 Managed Agents则按模型Token用量计费。此外，每个会话每小时另收0.08美元运行费，只计算会话处于运行状态的时间。

这0.08美元只是运行费，多Agent阅读材料、生成答案消耗的Token还要另算。 开发者可以设置会话预算，工作流的模型消耗也计入其中。达到预算后运行暂停，但已发出的模型请求仍会完成，最终费用可能超出预算。

会话预算覆盖动态工作流中的模型消耗，方便控制多Agent协作的支出。 因此，官方建议先从范围明确的任务开始，摸清消耗，再逐步增加复杂度。 Agent多了，并不自动等于更划算。 多找出多少真实问题，增加了多少模型调用费用，又需要人花多少时间复核、修错，都得算进同一笔账。 少花时间分活，如果换来更多收尾工作，项目未必更快结束。 这两项更新，让Claude开始承担更多组织工作。用户交代目标、预算和验收标准，Claude负责分工、推进和交接。 接下来的考验是：把活分出去之后，Claude能不能少让人操心，把经得起检查的结果交回来。