去年某头部电商把售后工单全量切给单点大模型，上线第三周，客诉率直接翻倍。业务线负责人盯了半夜系统日志，甩出一句原话：“它查退换货政策挺快，一遇到跨部门加价保补偿，就开始循环道歉和死循环报错。” 这不是算力瓶颈，是架构选型踩了红线。单点Agent被硬塞进工单流转、库存校验、财务核销的长链路，本质是让一个单线程执行的工具去背多系统协同的KPI。以前靠人工坐席拆单派工、人脑做状态兜底，现在指望一个Prompt包揽所有非标决策，监控面板上全是上下文丢失和接口重试超时。模型确实能理解自然语言指令，但业务流里的权限边界、异常分支处理和最终一致性，根本不是靠堆砌Context窗口就能抹平的。 把单兵当全能用，翻车只是时间问题。业务复杂度一旦越过单线程推理的阈值，就该果断切分层架构，别在死胡同里死磕提示词调优。接管非标复杂工作流，靠的不是更聪明的单体，而是按能力边界拆解的多角色协作。 工单死循环的日志还在监控面板上飘红，把单点模型硬塞进长链路就是反架构设计。把能力边界往下切，执行型Agent的底牌才真正露出来。这类节点就是流水线上的熟练工，你喂给它清晰的API清单和SOP，它能按部就班地调库存、对账、发通知。接口并发压到千级QPS，响应延迟死死压在两百毫秒内，跑起来确实漂亮。但它脑子里没有业务拓扑图。 上周给一家跨境供应链做报关路由改造，执行Agent接了单据解析和格式转换的活。工具链调用成功率卡在99.9%，可一旦海关临时调整HS编码规则，它照样把旧版映射表硬塞进申报接口。原因很直接，它只认JSON Schema和HTTP状态码，不认外部业务变量。上游风控切了拦截阈值，下游财务换了结算币种，执行层完全处于信息孤岛。以前靠老调度员盯着异常弹窗手动改单，现在指望执行节点自己跳出既定SOP做分支决策，属于写需求时脑补过度。 它的实战价值只在确定性动作上。批量清洗数据、重试失败接口、生成固定格式报表，这些消耗算力但逻辑封闭的脏活，交给它最稳妥。别试图用更长的上下文窗口教它顾全大局，那只会拖慢推理速度，增加幻觉概率。架构拆分时就得认账，执行层只负责把上游决策翻译成精准的数据库读写和API调用。 遇到需要状态同步或异常熔断的环节，立刻把决策权抽离到规划层。给执行型Agent定死输入输出契约，切断它越权访问其他模块的路径。承认它干不了统筹的活，才是多智能体架构接管复杂工作流的第一道门槛。 执行层卡在动态变量上只会硬刚，一遇规则跳变，上下文直接断裂。这时候必须把决策权往上提，交给规划型Agent。它不碰底层API，专干三件事：拆任务、记状态、兜底异常。上周给跨境物流做异常调度改造，旧链路遇到航班取消叠加海关查验（极端态），直接抛500错误。切到规划架构后，节点先把长链路切成运力重排、报关延期申请、客户安抚三个子目标，再把每步的执行结果写进短期记忆池。接口超时不会盲目重试，而是回滚状态树，自动切备用清关行。这套带反思循环的设计，本质是把老调度员的脑内推演过程代码化。 业务流的非标特性根本靠不住大模型的通识直觉。规划型Agent的底牌在状态机设计，不在Prompt调参。记忆模块必须严格区隔工作区快照和长期策略库，否则上下文一膨胀，推理延迟直接击穿SLA。线上压测数据显示，加上结构化记忆约束后，复杂工单拆解准确率从六成拉到九成二，代价是每次多跳决策多烧掉一点算力。拿计算成本换确定性，这笔账架构师得算清楚。 单兵作战的天花板摆在那里。超过三层交叉依赖，或者遇到需要实时状态广播的场景，规划层照样会陷入自我指涉的死循环。别试图用一个节点吞掉全量业务逻辑，遇到强协作断点就果断引入多角色路由。把规划能力锁在明确边界内做深度推理，才是接管非标复杂工作流的唯一解。技术选型别追虚名，能精准切分决策权，Agent才有实战价值。 单节点规划层一旦越过三层依赖，算力开销和容错率就撞上物理天花板。状态树膨胀直接击穿SLA，这时候再堆上下文等于给自行车装火箭发动机。业务流跨域后，必须把单体拆成多角色，靠角色隔离与消息总线重建协同链路。 给某券商做资管合规复核时踩过坑。早期让规划节点包揽尽调、风控、法务三块逻辑，每次跑完干等四十分钟，遇到监管新规直接内存溢出。后来改成三节点并行：尽调Agent抓底层持仓数据，风控Agent跑压力测试，法务Agent核对合同条款。中间不靠自然语言传话，直接走轻量级事件总线。每个节点只订阅自己关心的字段，跑完把结构化结果推回中央状态池。路由层只做一件事，根据前置条件决定下一跳交给谁。以前一个模型死磕全量上下文，现在状态变更实时广播，整体耗时压到九秒内，并发量翻了二十倍。 多智能体架构的底牌不在模型多聪明，在于读写契约和状态机设计。线上压测跑过几轮就知道，一旦放开共享内存权限，节点之间立刻陷入消息风暴和状态覆盖。我们强制规定所有状态变更走单向事件流，路由层加了一层版本校验，冲突直接打回重算。这套机制跑通后，复杂工单吞吐率稳定在每分钟三百单，幻觉率掉到百分之一以下。 别把多Agent当成技术展台。业务流只要出现明确的专业壁垒和并行断点，就该上路由同步架构。把长链路切碎，让专才干专活，状态流转靠总线而不是靠猜。架构演进到这一步，拼的是工程克制力。能管住通信开销和状态一致性的团队，才配谈接管非标工作流。 理清三类技术形态的适用边界后，选型逻辑必须往回倒，用业务指标反推技术投入。现实里太多团队看别人跑通了多Agent路由，转头就把自家审批流全拆成节点。算力账单直接翻了三倍，线上排查一次跨节点状态丢失，能熬两个通宵。技术选型不是集邮，别把业务流里的烂账全甩给架构升级。 上周跟一家做工业SaaS的架构师对齐方案，他指着流程图上三个手工核对节点说必须上多智能体。拉出近三个月的工单流转数据一看，断点根本不在模型能力，而是采购、质检、财务三套系统的字段标准压根没对齐。上游ERP吐出的是含税价，下游MES只认未税，中间全靠人工换表补漏。这种底层数据治理的缺失，你就算部署十个Agent互相发事件消息，照样会在字段映射环节互相甩锅。多智能体救不了流程设计的漏洞，它只会放大已有的协作裂缝。 上手搭路由前，先画业务断点图。把核心链路从头到尾压一遍，盯死三个硬指标：人工兜底频次、跨系统状态回滚耗时、异常分支重试率。哪个环节把这三个数字顶到红线，哪里才是该切多角色的真实缺口。断点如果只是信息不同步，上个轻量级状态看板比堆模型划算；遇到强规则冲突或高频非标决策，再考虑引入并行路由。 别拿技术架构的复杂度去掩盖业务流程的混乱。先做流程瘦身，再做系统解耦，最后才是Agent分级。把协作断点量化清楚再动手，省下的推理开销足够养一个专职的架构审计团队。