Claude自己组队查Bug：11.6万行代码里埋了70个坑，单干最好只翻出27个，组队三次都是66个

2026年10月12日

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

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

两项更新指向同一个变化：除了执行任务，分活、盯进度、交接结果，这些原本需要人操心的事，Claude也开始接手了。

你提目标，Claude自己分活

同时开几个AI窗口不难，麻烦的是给每个窗口重讲一遍背景、把一边的发现送到另一边，再挨个追问做到哪了、卡在哪里、还缺什么。窗口一多，人反而忙成了传话员。

Projects想接下这部分工作。你在同一个项目对话里持续提需求，Claude判断该新开一条任务线程，还是交给已经在处理相关工作的线程。每条线程可以理解为一段独立推进任务的工作对话。

Anthropic举过一个例子：让API、网页端和移动端一起停用旧接口。这件事涉及多个代码仓库，各处修改还得互相配合。Claude可以按代码仓库拆出任务，分别修改、运行测试、提交代码合并请求，再告诉你哪些改动需要先合并。每条云端线程有自己的上下文和代码副本，在自己的分支上工作，再把结果报回项目对话。

你仍能进某条线程看细节、纠正方向。项目总览则把正在工作、等待回答、可以审查的任务分开列出。离开一会儿再回来，也不必挨个窗口问进度，直接从需要处理的地方接上。云线线程还能在你合上电脑后继续工作；需要本机工具或本地数据库的任务，也能通过Remote Control在电脑上运行，但电脑必须保持唤醒。

要省下反复沟通的时间，之前交代过的事就必须记得住，所以Projects会积累项目记忆。需求改了什么、做过什么决定、哪些地方踩过坑，都可以记录下来供后续线程读取。官方举了个日常工作场景：发布日期改到了周五、某项功能为什么被砍掉、修改某个服务前要先找谁确认，这些都能留在项目记忆里。新版Projects在9月17日已开启分批公测，这次扩大的是准入范围，功能本身仍在公测阶段。

300份合同，把分工写成程序

项目有人协调之后，一项复杂任务内部该怎么拆？Managed Agents动态工作流处理的就是这类问题。

官方给的示例是：检查300份合同，找出哪些包含控制权变更条款。逐份读懂已经很费工夫，还得确保每份都查过、结论有据可查。Claude会为任务写出一段工作流程序，安排哪些Agent读材料、哪些步骤处理结果，以及后续怎样继续。分工和交接都写进了程序，可以直接运行：一个Agent读完材料，结果交给程序，程序再传给后续Agent，或据此决定下一步走哪个分支。需要反复修改的工作也能把循环安排进去，比如稿件审校，持续修改直到审核通过或达到预设轮数。

普通子Agent委派时，主Agent要读汇报、接着决定下一步；动态工作流则把大量中间交接写进程序在后台推进。也因此，工作流中的线程交回结果后，主Agent不能像调用普通子Agent那样继续向同一线程追问，核对和返工最好提前安排进流程。官方合同审查指令就规定：第一轮每份合同交给一个Agent，第二轮由另一个Agent重新检查全部合同，连首轮未发现目标条款的也不能跳过，复核未通过的返工后再复核。这给首轮漏掉的条款多留了一次被发现的机会。

官方举的合同案例展示的是工作方式，Anthropic并未在Bug测试帖子中披露具体分工，不能据此认定那66个Bug也是通过同样流程找出来的。

1000个Agent，也得排好队

单次最多1000个Agent，是这次公测最抢眼的数字，它指的是一次工作流在整个运行期间累计最多启动的Agent数量。当前文档列出的同时工作线程上限是64，官方也说明这个并发数可能调整。每个Agent有独立的对话历史，同时共享会话中的文件和沙箱。开发者可以提前配置专门的Agent，也可以让工作流根据任务临时定义；接入时在multiagent配置中将type设为multiagent_20261001。

会分工还不够，还得把没做完的地方交代清楚。官方一条指令样例要求：某个Agent读不了合同，就把这份合同列为「未覆盖」，其余任务继续。「没查出问题」和「根本没查到」必须分开，否则一份整齐的汇总很容易把任务缺口藏起来。

Agent多了既要安排好执行顺序，也要看清哪些任务完成、哪些仍有缺口。这里还得区分：最多启动1000个Agent、三次均查出66个Bug，说的都是Managed Agents动态工作流，并非Projects。

省下协调时间，账单继续跑

查出的Bug更多了，但为此多花了多少时间和费用还不清楚。官方没有披露所用模型、实际Agent数量、耗时、Token用量和误报情况，暂时无法判断这套工作流是否更快、更划算。

实际使用时，两项功能的费用要分开看。Projects使用现有套餐额度，工作线程和协调对话都会消耗用量，并行任务越多额度用得越快。Managed Agents则按模型Token用量计费，此外每个会话每小时另收0.08美元运行费，只计算会话处于运行状态的时间。开发者可以设置会话预算，工作流的模型消耗计入其中；达到预算后运行暂停，但已发出的模型请求仍会完成，最终费用可能超出预算。

官方建议先从范围明确的任务开始，摸清消耗再逐步增加复杂度。Agent多了并不自动等于更划算——多找出多少真实问题、增加多少模型调用费用、又需要人花多少时间复核修错，都得算进同一笔账。少花时间分活，如果换来更多收尾工作，项目未必更快结束。

这两项更新让Claude开始承担更多组织工作，用户交代目标、预算和验收标准，Claude负责分工、推进和交接。接下来的考验是：把活分出去之后，Claude能不能少让人操心，把经得起检查的结果交回来。

你提目标，Claude自己分活

300份合同，把分工写成程序

1000个Agent，也得排好队

省下协调时间，账单继续跑

相关链接