真实的智能体流量里，多智能体几乎不存在

一条请求进入智能体应用，绕了好几圈：读了文档、调了检索、跑了一次代码、又回头改了一遍参数。从人的角度看，这已经是一套流程。可从服务调用上看，它从头到尾只碰了一个服务。Datadog 分析自家一千多家客户的智能体遥测后发现，59% 的智能体请求只做了一次服务调用，做到3 次以上的只占 18%。挂在架构图上的多智能体，在真实流量里很少出现。这意味着讨论架构时用的那张图，和生产里跑的东西并不是一回事。这句话值得你确认一次。这也是你的预算比上一轮更早用完的原因之一。你的服务图不会告诉你这件事。你要的是图之外的那张表，记的是同一个服务内部转了几圈、每圈带走多少 token。

这两个数是怎么算出来的

先看口径，因为它决定了这两个数能推到多远。Datadog 统计的是端到端的智能体应用，只算至少发生过一次服务调用的那些，然后数一条完整请求跨了几个服务。样本是使用它 LLM 可观测产品的客户，报告自己写明这类公司基础设施相对成熟，偏向云原生，因此不等于全行业普查。

即便打了这个折扣，59 比 18 的差距仍然值得看。如果多智能体真的普及，占比更高的应该是3 次以上的那一头。实际情况正好相反，接近 60% 的流量停在单服务上。这不是说多智能体没用，而是说它还没进入多数人的生产路径。真正跑在生产的，是一个进程内部的循环：读、调工具、看结果、再读。也就是说，复杂度并没有消失，它换了一个地方待着。取舍就落在3 个域上，没有第四个。

单服务循环具体长什么样，做过的团队都认得。请求进来，先调一次检索工具拿候选文档，再调一次数据库查询补字段，读到一条格式不对就重试，参数改一版再跑，最后合成答案。十几步里每一步都是一次模型调用加一次工具调用，但它们都在同一个服务进程里，服务图上看只有一个框。这种形状本身没有问题，问题在于它把所有成本压在一个配额、一张账单、一条日志流上。

报告同时给了一个佐证。只有 18% 的请求跨了三个以上服务，说明剩下80%不是在服务之间交接，而是在同一个服务内部绕圈。绕的圈数不在服务拓扑上体现，只在 token 数和延迟上体现。这也解释了为什么很多团队的服务图看起来很干净，账单和响应时间却很难解释。原因是圈数只落在 token 和延迟上，不落在拓扑上。也就是说，你量的是服务，痛的是循环。这两件事的比例，才是你真正的架构成熟度。所以第一步是量，不是拆。

复杂度没有消失，它搬进了一个进程内部

复杂度从哪来的。Datadog 的另一个发现是框架采用率一年内接近翻倍：2025 年初还只有 9% 多的组织在用智能体框架，到 2026 年初接近 18%，使用框架的服务数量同期翻倍以上。框架让常见模式写起来很容易，工具扇出、重试、分支，一次 import 就到手。

问题在于，这几种模式每一个都会让循环变长，而循环变长之后，工程师对运行时的理解就落在了后面。报告的原话是，框架带来的样板代码会让工具扇出、重试和分支随手可用，成本和延迟随之向上漂移，失败变得更难复现。这不是框架的缺陷，是它的定价方式：你省下的是编写时间，付出的是可解释性。换句话说，便利是先付后用的。原因是框架把复杂度藏在了默认值里。真正的问题是，没人把循环当成一个需要被计量的对象。所以我们建议你先补一条按步骤的耗时序列。

框架还有一层更隐蔽的影响。它把常见做法提前实现好了，于是团队会顺手续用那些并不适合自己的逻辑：过度的工具扇出、无条件的重试、为通用场景准备的分支。报告的建议是把这些导入的逻辑换成自己写的工作流，前提是你先看得见它们在运行时的样子。看不见的时候，框架的默认值就成了你的架构。这是最容易被忽略的一层技术债。所以我们建议把单服务调用的占比当成架构指标，一个季度看一次。这意味着你可能在为一个用不到的拓扑付费。你想要的那张协作图，得等这3 个域先说话。

可见性缺口正好在这个位置。服务级监控看得见一次调用进了哪个服务、花了多久。它看不见这个服务内部转了几圈、每圈带了多少上下文、第几圈开始重复。把这两层混在一起看，场面会变得熟悉。面板上一切正常，账单和用户投诉同时到。这就是你要找的那条缝。真正的问题是，中间那一层根本没有人记录。所以先看循环，再看边界。

失败长什么样：不是答错，是被限流

Datadog 统计的失败分布有点出人意料。2026 年 2 月，5% 的模型调用报了错，其中 60% 是超出速率上限。到了 3 月，整体错误率降到 2%，限流类错误仍然接近 840 万次、占了其中约 1/3。也就是说，生产里最常见的故障不是模型答得不好，而是请求根本进不去。这和你为模型能力做的所有优化都不在一条线上。这意味着你花在提示上的那几周，改不了这件事。原因是重试会把一次失败放大成三次请求。

这条因果很容易被低估。智能体撞上限流就会重试，重试抬高并发，并发再去撞上限，一次局部抖动因此变成持续故障。单体架构在这里格外脆弱，因为所有步骤共用一个配额：检索那一步的突发流量，会把后面每一步都拖住。如果这些步骤分在不同的服务里、各有各的配额，故障的传播路径就短得多。这是拆分的第一个真实收益，而且它与“多智能体更聪明”没有关系。它省下的是故障传播的路径长度。这句话有两种读法，你要的是后一种。你要先回答的是哪一步必须先隔离，而不是哪套框架更流行。这个答案决定了后面 3 个月的钱花在哪里。这也是我们把它排在观测之后、而不是之前的原因。

共享配额这件事往往跨团队。组织级的并发上限由几个团队共担，任何一方的批量任务都能把别人的智能体挡在门外，而这种相互踩踏在各自的监控面板上看起来只是自己的超时。要定位它，需要把配额按应用和团队切开看，否则谁都找不到原因，只能统一加机器。这意味着配额本身也该是一条被监控的序列。真正的问题是，配额通常没有主。你要找的那个人，往往不在平台团队里。

对应的解法也不新：队列、退避、备用容量、按循环长度设上限。报告的建议是让平台把预算和背压做进运行时，并且在循环超过最大调用数或 token 数时强制终止。这些都是分布式系统的老办法，只是现在要作用在一个由模型驱动控制流的程序上。

该不该拆：看3 个域，不看先进程度

拆不拆是个隔离问题，不是先进性问题。判断可以落到3 个域上。故障域：某一步崩了，会不会把其他步骤一起拖下去。权限域：不同步骤是否需要不同的数据授权，比如读工单和写付款账户不该共用一个身份。预算域：不同任务是否需要各自独立的限额，避免一个开放式任务吃掉整月的额度。

实际先撞墙的通常是权限域。一个智能体既要读客户资料又要写付款指令，这两个动作在任何一个成熟组织里都不该共用一个身份；一旦审计提出这个问题，拆分就从可选项变成必须项。故障域和预算域晚一步，它们通常在第一次配额事故或第一次预算超支之后才被认真对待。

3 个域里有一个必须隔离，拆服务就有理由；3 个都不需要，留在单体更划算，因为跨服务要付的代价是真实的：上下文要在边界上传递，追踪要跨进程串起来，工具也要出现在服务图里。报告在讲多智能体时提到这一点：调试这类应用需要跨服务边界传播上下文和追踪，管理这类平台需要把工具也算进服务图。

反过来也有代价被低估的例子。有团队为了让架构图好看，把一个循环拆成3 个服务，结果追踪在边界上断掉，一次失败要从三个日志流里拼时间线，定位时间从小时级变成天级。拆分换来的隔离是真的，观测成本上升也是真的，两者要在同一个决定里算。否则拆分会变成一次用可观测性换隔离的交易，而账没人记。这笔账要你自己记。

按这个标准回头看 59%，结论就变了。多数团队还没有到需要隔离的阶段，他们的复杂度在循环内部，而不是在服务之间。此时引进编排层，买到的是一套用不上的拓扑能力，付出的是一层新的、需要被观测的中间件。真正该先做的是把单体的循环看清楚。这也是为什么我们把观测放在拆分之前。

多模型其实也是一种编排

还有一条常被忽略的线索。Datadog 发现 70% 以上的组织在用三个以上模型，用六个以上的比例一年内接近翻倍。模型组合本身就是一个编排问题：哪个步骤交给哪个模型、失败时降级到谁、版本退役时怎么迁移。它的收益比多智能体更早兑现，因为它直接改变成本和质量，而不需要先改变拓扑。

网关放在谁手里，是个组织问题。放平台团队，应用团队改一次策略要排期；放应用团队，每个团队各建一个，等于把多模型问题变成多网关问题。折中的做法是网关由平台统一托管，路由策略按应用下放，评测结果回流到同一张表。这件事的难度不在技术，在谁有权改路由。换句话说，网关是一个组织问题伪装成的技术问题。

这条路也有它的坑。同一套提示和工具在不同模型上会给出不同结果，每多一个模型就多一份质量、延迟和成本的指纹，评测负担跟着涨。报告把这称为模型层面的技术债，团队的普遍做法是快速试新版本，却慢于下线旧版本。结果不是选择困难，而是同时在维护好几条互不相干的路径。

所以编排的第一层不是智能体之间的协作，是请求在模型之间的路由。一个网关，一套在线评测，按步骤定策略。这3 样在单体里就能做。这些东西在单体里就能做，不需要先拆服务。等到某一步真的需要独立扩容、独立授权、独立限额，再把它拆出去，那时拆分是有理由的迁移，不是架构表演。

据此选平台，问4 个问题

选型时容易被功能清单带走。多智能体支持多少种协作模式、能画多复杂的图，这些问题在 59% 这个数面前价值有限。更有用的4 个问题：能不能把一条请求的每一步留痕，包括工具返回和重试；能不能在运行时设上限并强制终止失控的循环；能不能按步骤设置不同的模型和配额；模型版本退役时，迁移路径是不是可枚举的。

这4 个问题的共同点，是它们都指向可观测性和约束，而不是拓扑。一个平台如果答得上这四条，你可以在单体里用它很久。需要拆的时候，它也拆得动。你要算的是这四条能答上几条，不是功能清单有多长。反过来，一个只会画协作图的平台，在你还没到那个阶段时会不断增加你要维护的表面。

也不用把 59% 读成“多智能体是错的”。它是一个时间坐标：多数组织还没有走到需要它的那一步，而少数已经走到的，通常是因为权限或配额先撞了墙，不是因为想让架构图好看。

我们的判断

我们的判断是：智能体编排现在被当成拓扑问题在讨论，实际是个观测与隔离问题。真实流量显示，绝大多数应用还是一个进程在绕圈，它们的痛点在循环内部看不见，不在服务之间接不上。先把循环看清楚，再决定要不要拆，顺序反了就会买到用不上的能力。这也是我们对这一轮编排热的全部态度。

由此有3 条动作。第一，这周量一个数：你的智能体请求里，单服务调用占多少，3 次以上占多少。这个比例就是你的架构现实，与采购清单上的能力无关。第二，把失败按类型分开，限流、超时、解析失败、被下游拒绝各占多少；如果限流在最前面，先做背压和循环上限，别急着上编排层。第三，写下三条隔离判据，故障域、权限域、预算域，只在有一步真的需要独立时才拆，并把这个理由留在架构文档里。

留给买家的问题是：你的多智能体架构里，有哪一步是因为必须独立授权或独立限额才被拆出去的？如果一条都说不出来，那它现在解决的是演示效果，不是生产问题。

参考来源

Datadog，《State of AI Engineering 2026》，遥测窗口至 2026 年 3 月（59% 单服务调用与 18% 3 次以上、框架采用率 9% 到 18%、70% 用三个以上模型、2 月 5% 错误率与 60% 限流占比、3 月 2% 与约 840 万次限流错误、跨服务追踪与工具纳入服务图的建议均出自该报告）