十月九日，Anthropic 给托管智能体加了一个测试能力：动态工作流。说人话就是，你可以让一个智能体自己写一段程序，把成百上千份文档的审阅拆成多个阶段，派出一群子智能体并行干，最后把结果合并回来。服务端在后台跑这段工作流，你不用一直盯着。
这解决了多智能体最头疼的老问题：编排。以前想让一群智能体协作，要么是手工写死流程，要么靠人来回倒腾。现在智能体能根据任务自己决定什么时候起一个工作流、怎么分阶段、谁先谁后。开启方式是在智能体上把多智能体字段设为开启，并在系统提示里告诉它何时启动；之后通过事件流跟踪每一次运行。
同一周 Anthropic 还发了两篇配套材料，把这件事说得更透。一篇讲如何写出靠谱的智能体自动化，给了一套带配置文件的参考实现，外加六条躲坑规则。核心就一条：别让自动化在没人看的时候悄悄跑偏。另一篇讲用模型自动设计评测并做逐坡爬升，强调的是别骗自己，评测升了，到底是真变好还是钻了空子，得能分辨。
这对正在搭智能体系统的人是个实在的信号。多智能体从听起来很美走向能交付，关键不在单个模型多强，而在编排层是否可靠、失败模式是否可控。Anthropic 明显在把这块能力产品化，和谷歌同一个星期发的同事智能体，方向上殊途同归：都认定未来不是人跟一个聊天框对话，而是人管理一群各有身份的智能体。
但坑也明摆着。工作流一旦能自我生成，调试难度指数级上升。你不仅要看懂智能体的输出，还要看懂它写的程序。权限、成本、失控回滚，这些在单智能体时代就难，到了多智能体只会更难。更现实的是，当几十个子智能体并行跑，一个卡死可能拖垮整条流水线，而定位是哪个环节出的问题，比单线程调试麻烦一个量级。
举一个能落地的例子：法律团队要初审五百份供应商合同，找关键条款和冲突点。过去是一个人加搜索硬看，或者写个一次性脚本。现在可以让一个主智能体生成工作流，把合同按风险类型分堆，派子智能体并行抽取，最后汇总成一张表。量大、规则清晰、可并行，正是动态工作流最舒服的甜区。
也别神话这套能力。动态工作流不是让你彻底撒手，而是把编排的复杂度从人手转移到了智能体自己身上。好处是快，坏处是一旦生成的程序有逻辑漏洞，你很难一眼看出哪里错。所以第一批落地，建议把工作流限制在那些错了能轻易发现的任务上，并且保留人工抽查的节点。说到底，多智能体解决的是量的问题，不是信任的问题。量上去了，信任的边界反而要收得更紧。
好在这家公司在可观测性上没偷懒。每一次工作流运行都会通过事件流吐出进度，你能看到哪个阶段在跑、派了多少子智能体、卡在哪一步。这听起来基础，却是多智能体能不能进生产环境的关键。没有这层可见性，并行跑几十个智能体等于蒙着眼睛管工厂。所以如果你打算用，第一批就把事件流接进你现有的监控，别等出事才临时翻日志。能看见，才敢放手。
别忘了触发工作流的那个人还是你。系统能自己写程序、自己派活，但什么时候启动、目标写多清楚，依然取决于你给的系统提示。一个模糊的目标会生成一堆含糊的子任务，最后合并出一锅粥。所以真正值钱的技能变了：不再是会写代码，而是会把大目标拆成机器能稳稳接住的小指令。这恰恰是非技术团队最容易忽略的一步。多智能体降低了执行的门槛，却抬高了描述的门槛，把话说清楚，比把活干完更重要。
最后提醒一句，这项能力目前还是测试阶段，接口和行为都可能变。别急着把核心业务压上去，先拿边缘流程练手，等它转正、文档稳定之后再考虑关键路径。技术尝鲜的代价往往是返工，而返工在多智能体场景下尤其贵，因为你要改的不止一段代码，而是一整套自动生成的协作关系。慢半拍上车，比提前翻车划算。
长远看，会管智能体的人会成为新岗位。不是写代码，而是设计目标、设边界、看日志。这个能力越早练，越值钱。
说到底，工具越强，越要人清醒。把重复活交给 swarm，把判断权留给自己。
跟你有啥关系：如果你已经在用或打算用这家模型搭自动化，这个动态工作流值得第一时间试，尤其适合量大、规则清晰、但要并行的活儿，比如批量合同初审、大规模代码迁移。但第一批务必加好预算上限和人工抽查节点，别让一群智能体在后台自由发挥，等出事才发现账单和错误都堆成了山。