Claude多Agent协作实测：三次查出66个Bug 完胜单Agent

Anthropic近期公布了一组代码查错测试数据：在11.6万行预先植入70个漏洞的代码样本中，单个智能体单次测试最多仅能找出27个Bug，检出率不足四成；而通过动态工作流组织多智能体协作，连续三次测试均能定位66个问题，检出率超过九成。

这一亮眼的测试结果，来自10月10日推出的两项Claude功能更新：一是Managed Agents动态工作流开启公测，二是Claude Code Projects扩大了公测范围，所有此前加入等待名单的Pro和Max用户均可使用。

过去同时开启多个AI对话窗口并不困难，但麻烦的是需要反复向每个窗口重复交代任务背景，在不同对话间传递工作成果，还要逐个跟进进度、确认卡点，随着窗口数量增加，用户很容易沦为传递信息的中间人。这两项新功能正是为了解决这一痛点，让Claude自主承担起任务分配、进度跟踪和结果交接的工作。

项目对话自动协调任务线程

在Claude Code Projects中，用户可以围绕同一个项目持续提出需求，系统会自动判断是开启新的任务线程，还是将需求分配给正在处理相关工作的已有线程。每条云端线程都拥有独立的上下文和代码副本，可以在专属分支上推进任务，最终将结果汇总回项目总对话中。

举个例子，当用户要求同步停用API、网页端和移动端的旧接口时，Claude会按照不同的代码仓库拆分任务，分别完成代码修改、运行测试、提交合并请求等步骤，并提示用户哪些改动需要优先合并。用户可以随时进入任意线程查看细节、调整方向，项目总览页面会清晰区分正在进行、等待回复和待审核的任务，无需再逐个窗口询问进度。

为了避免重复沟通，Projects还会积累完整的项目记忆，记录需求变更、历史决策、踩过的坑等信息，供后续所有任务线程读取。比如发布日期调整、某项功能被取消的原因，或是修改特定服务前需要确认的对接人，这些内容都会被妥善保存，让后续任务可以直接沿用已有成果，无需重复询问背景。

该功能自9月17日开始分批公测，本次扩大了准入范围，尚未报名的用户仍可加入等待名单。云端线程可以在用户离线后继续运行，需要本地工具或数据库的任务则可以通过Remote Control在本地电脑上执行，但需要保持电脑处于唤醒状态。

动态工作流把分工写成可执行程序

如果说Projects解决的是多对话窗口的协调问题，那么Managed Agents动态工作流则专注于复杂任务内部的智能分工。官方以300份合同的审查任务为例，展示了该功能的工作流程：要求从300份合同中找出包含控制权变更条款的文档，逐份阅读本身就需要大量精力，还要确保每份都被覆盖、结论有据可查，避免遗漏。

Claude会为该任务编写完整的工作流程序，安排不同智能体负责读取材料、处理结果、衔接后续步骤，所有分工和交接逻辑都被固化为可直接运行的程序。一个智能体完成阅读后，结果会自动传递给下一个环节的智能体，系统还可以根据中间结果动态调整后续流程，甚至支持循环迭代的工作，比如稿件审校可以持续修改直到通过审核或达到预设轮次。

与普通的子智能体委派不同，动态工作流将大量中间交接步骤放在后台自动完成，主智能体无需在每一步都读取汇报再做决策，仅需要在等待期间与用户沟通进度，任务完成后直接汇总结果。不过需要注意的是，工作流中的线程提交结果后，主智能体无法直接向该线程追加追问，因此核对和返工步骤需要提前写入流程中。

官方给出的合同审查指令样例就设置了双重检查机制：第一轮由智能体逐份阅读合同，第二轮由另一组智能体重新检查全部文档，包括第一轮未发现目标条款的合同，复核未通过的需要返工后再次检查，这给首轮遗漏的条款多了一次被发现的机会。

单次最多启动1000个智能体

本次公测最引人关注的参数之一，是单次工作流累计最多可启动1000个智能体。不过当前同时工作的线程上限为64个，官方表示该并发数可能会根据实际使用情况调整。工作流可以分批执行，也可以等待前一阶段结果返回后再启动下一阶段。

每个智能体拥有独立的对话历史，但共享会话中的文件和沙箱运行环境。开发者既可以提前配置专用智能体，也可以让工作流根据任务需求临时定义智能体。接入时只需要在multiagent配置中将类型设为multiagent_20261001，再配置对应模型、工具和任务要求即可。

为了避免任务出现缺口，工作流需要明确区分“未查出问题”和“根本未覆盖”的情况。官方指令样例中规定，如果某个智能体无法读取某份合同，需要将其标记为“未覆盖”，其余任务继续推进，避免整齐的汇总结果隐藏了未完成的任务。开发者可以查看各阶段的运行记录和线程日志，快速定位问题所在。

成本与使用注意事项

虽然多智能体协作的检出率显著高于单个智能体，但目前官方并未披露测试所用的模型、实际智能体数量、耗时、Token用量和误报率，暂时无法判断该工作流是否在效率和成本上更具优势。

两项功能的计费规则有所不同：Projects使用用户现有的套餐额度，工作线程和协调对话都会消耗用量，并行任务越多，额度消耗越快，用户可以调整模型参数、推理强度或线程数量来控制消耗，当套餐额度用尽后工作线程会暂停，等待额度重置后继续。

Managed Agents则按照模型的Token使用量计费，此外每个运行中的会话每小时会收取0.08美元的运行费，仅计算会话处于活跃状态的时间。需要注意的是，这0.08美元仅为运行费，多智能体读取材料、生成回答的Token消耗需要另行计算。开发者可以设置会话预算，工作流的模型消耗会计入该预算，达到预算后运行会暂停，但已发出的模型请求仍会完成，最终费用可能超出预设预算。

官方建议用户先从范围明确的小任务开始测试，摸清实际消耗后再逐步增加任务复杂度。更多的智能体并不自动等于更高的性价比，需要综合考虑多找出的问题数量、增加的模型调用成本，以及后续需要投入的复核和修复时间，避免节省了协调时间却带来更多的收尾工作。

这两项功能更新，让Claude从单纯的任务执行者，转变为任务的组织者和协调者。用户只需要交代目标、预算和验收标准，剩下的分工、推进和交接工作都可以由Claude完成。接下来的核心考验是，在将任务分配出去后，Claude能否减少用户的后续干预，产出经得起检验的最终成果。