单一Agent表现最佳时，仅能发现27个漏洞。

而当Claude自行组建团队后，连续三次测试，每次均能定位66个漏洞。

这是Anthropic最新披露的一组实验数据：在包含11.6万行代码的程序中预先设置了70个Bug，分别让单个Agent和动态工作流各执行三次测试。

结果显示，独立作战的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能否减少让人操心的事务，并交出经得起检查的结果。

参考资料：

https://x.com/ClaudeDevs/status/2108591328732856655

https://x.com/ClaudeDevs/status/2108591330129523146

https://x.com/ClaudeDevs/status/2108591331660468538

编辑：元宇 摩西

本文来自微信公众号“新智元”（ID：AI_era），作者：ASI启示录，36氪经授权发布。