李雯和多 Agent 协作那条线上的新瓶颈

李雯的办公室在第三车间二楼，挨着楼梯口。

房间不大，一张办公桌、一把椅子、一台厂里标配的联想台式机。墙上贴着一张 A0 尺寸的手绘图——她自己画的产线节拍图。每个工位是一个方框，方框之间用箭头连接，箭头上方标着时间：上料 12 秒、粗加工 45 秒、精加工 38 秒、检测 15 秒、下料 10 秒。每个数字都是她拿着秒表现在场测的，测了三轮取中位数。

这张图是她管产线的"总谱"。十年了，图换过四次——每次设备更新或产线调整，她就重画一张。旧的四张没扔，卷起来放在柜子里，从 2016 年到 2024 年，时间轴清晰可读。

最新这张图的右下角，有五个带问号的方框，用红笔画的，和旁边黑笔标注的工位时间格格不入。每个红框里写着同一行字——"Agent 响应时间不稳定"。

---

李雯是工业工程专业出身，2014 年进华岳精密，先在第一车间干了两年计划员，2016 年调到第三车间当产线主管，一直干到现在。

她的手艺是排节拍。

一条产线上有若干工位，每个工位的加工时间不一样。排产线要做的核心事情是——让每个工位的节拍匹配起来，不出现"上游干完了等着下游、下游被上游堵住"的情况。这事的难点从来不是某个工位太慢，是工位和工位之间的衔接没调好。缓冲区设多大、在制品存量多少、异常品怎么旁路、换型时间怎么压缩——这些"工位之间的事"，才是产线主管真正的战场。

她在这件事上干了十年，从没失过手。厂里几条最复杂的产线都是她排的，第三车间的 OEE（设备综合效率）在她手上从 72% 做到了 89%。

去年秋天，郑总找她谈话。

"李雯，厂里要上一条 AI Agent 产线。五个 Agent 串起来做订单处理。你来做产线负责人。"

她当时没多想。在她看来，Agent 也是产线上的一个"工位"——输入什么、输出什么、节拍多少、异常怎么处理，和管一台加工中心没什么本质区别。

后来她发现，区别比她想象的大。但最大的区别不在 Agent 本身，在 Agent 和 Agent 之间。

---

第一条 Agent 产线

这条产线处理的是大客户的定制化订单——老周牵头造的那个 V-2 系统。

V-2 是老周从零搭的，能处理单一规格的标准件订单。但郑总的目标不止于此——他要把 V-2 扩展成一条完整的"订单处理流水线"：客户发来订单（PDF、邮件、微信截图都有），Agent 要一路处理到底——识别需求、评估技术可行性、算报价、排产、承诺交期。

老周把 V-2 拆成了五个子 Agent：

Agent A · 需求解析——把客户发来的各种格式文件统一识别成结构化数据：什么产品、什么规格、多少数量、什么时候要。

Agent B · 技术评估——拿到结构化数据后，对照厂里的工艺能力库，判断能不能做、有没有特殊工艺要求。

Agent C · 报价计算——根据技术评估结果，查物料价格、算加工成本、生成报价单。

Agent D · 排产匹配——拿到报价单后，对照产能和物料库存，排入生产计划。

Agent E · 交期承诺——综合以上所有信息，给客户一个确定的交期。

五个 Agent，每个都是老周用他"造设备"的方法一个个调试好的。单个拆开看，每一个都过了验收——A 的识别准确率 96%，B 的评估准确率 94%，C 的报价误差率低于 2%，D 的排产冲突检出率 98%，E 的交期预测偏差在 ±1 天以内。数字都好看。李雯的工作是把这五个"单机设备"串成一条"产线"。她以为这事不难。

---

第一天全线联调

全线联调那天，李雯、老周、IT 部两个工程师，四个人坐在李雯的办公室里，对着屏幕看五个 Agent 首次串联运行。

前三个订单跑通了。从 A 到 E，端到端平均 47 秒完成一个订单处理——比人工快了二十倍。李雯在节拍图上记了一笔："全线节拍 47 秒，首跑通过。"

第四个订单出了问题。

Agent A 正常输出，2.3 秒。Agent B 接到 A 的输出，开始技术评估——然后停在那里。等了 15 秒，30 秒，40 秒。Agent B 没有返回结果。

下游全卡住了。Agent C 在等 B，D 在等 C，E 在等 D。就像产线上一个工位突然停机——后面全线停摆。

IT 工程师查了日志，发现 Agent B 不是坏了。它在处理这个订单时，碰到了一个涉及"异形件"的技术评估——需要调取厂里工艺能力库里的非常规数据。这个查询花了 38 秒。但系统设的超时阈值是 30 秒。B 没在 30 秒内返回结果，C 就认为 B "挂了"，进入等待状态。D 和 E 依次等待。

李雯盯着屏幕看了两分钟，说了一句："这不是任何一个 Agent 的问题。这是它们之间的问题。"

---

接下来一周，类似的事反复发生。

有时是 Agent A 解析一个手写扫描件 PDF 花了 25 秒（正常 2 秒），B 等不到 A 的输出，超时。有时是 Agent C 在算一个特殊合金材料的报价时调了外部价格接口，接口响应慢，C 卡住，D 等 C，E 等 D。有时是 Agent D 排产时发现产能冲突，需要重新计算，这一算就是 45 秒。

每次出问题，单独看那个 Agent，它都在"正常工作"——只是比平时慢了。但它一慢，整条线就断了。

李雯把一周的运行日志全部拉出来，画了一张"故障分布图"——不是按 Agent 分的，是按"衔接处"分的。A→B 之间出了 3 次超时，B→C 之间出了 5 次，C→D 之间出了 2 次，D→E 之间出了 1 次。

她盯着这张图看了很久，然后用红笔在自己那张 A0 节拍图的右上角写了一行字：

瓶颈不在最慢的那个工位，在衔接最差的那两个工位之间。

这句话她说了十年。但直到这一刻，她才真正意识到——这句话对 Agent 同样成立，甚至更致命。

---

用排产线的办法排 Agent

李雯没有学过什么 Orchestration 框架，不懂 LangGraph 也不懂 CrewAI。她知道的是——一条产线上，工位和工位之间必须有三样东西：缓冲区、异常路由、节拍匹配。

她决定把这三样东西原封不动搬到 Agent 产线上。

第一件事：加缓冲区。

原来五个 Agent 是"直连"的——A 干完了直接把结果传给 B，B 干完了直接给 C。这种结构在产线上叫"零库存串联"，任何一个工位停机全线停摆。

李雯要求在每个衔接处加一个"中间队列"——A 的输出先进一个缓冲区，B 从缓冲区里取。这样 A 如果慢了，B 不会直接超时，而是等缓冲区里的数据。缓冲区设多深？她算了一下——按 A 的最大延迟 25 秒、平均处理间隔 3 秒来算，缓冲区深度设 10 个订单就够。这和她管产线时设的"在制品缓冲"是同一套逻辑。

老周看了这个方案，点了点头："这不就是产线上的 WIP 缓冲嘛。只不过现在的'在制品'是数据不是零件。"

第二件事：设异常路由。

产线上如果某个工位出了故障，标准做法不是"停下来等"，是"旁路"——把半成品先转到备用工位或暂存区，让产线继续跑。

李雯给 Agent 产线设了同样的东西。每个衔接处设一个超时阈值（不是统一 30 秒，而是根据各 Agent 的响应时间分布分别设定），超过阈值的订单自动走"异常路由"——转入人工处理队列，同时触发一条通知给对应的负责人。

B→C 之间超时最多（5 次），她分析发现主要原因是 C 调外部价格接口时偶尔超时。解决方案不是改 C，是在 C 后面加一个"报价缓存"——常用材料价格每天预加载一次，C 先查缓存，查不到再调接口。这和产线上"提前备料"是同一件事。

她去找张师傅聊过一次——张师傅管着十三个 support agents 的维护，对这种"缓存 + 降级"的策略很熟悉。"李雯，你这个思路和我们管 support agents 一样——主通道卡住了，得有旁路。"张师傅指着墙上那张依赖关系图说，"你看，S-1 的输出是 S-2 的输入，S-1 慢了，S-2 不能干等，得有个队列缓冲。"李雯看着那张图，忽然明白了自己的 Agent 产线和张师傅的 support agents 依赖图，本质上是一回事。

第三件事：调节拍。

这是她最擅长的事。

她把五个 Agent 两周内所有请求的响应时间拉成了一张分布图——每个 Agent 的平均响应时间、P95 响应时间、最大响应时间。然后画成一张甘特图，横轴是时间，纵轴是各 Agent 的调用链。

图一画出来，瓶颈一眼就看出来了——Agent B（技术评估）是整条线的"窄口"。它的平均响应时间 4.2 秒，但 P95 到了 22 秒。其他四个 Agent 的 P95 都在 8 秒以内。整条线的"理论节拍"是 5 个 Agent 的平均响应时间之和——大约 16 秒。但实际节拍受 B 的尾巴影响，经常被拉到 40 秒以上。

解决方案不是让 B 变快（那是老周的事），是在 B 这里做"节拍分离"——把 B 的任务拆成"快速评估"和"深度评估"两档。80% 的常规订单走快速评估（2 秒以内），20% 的非常规订单走深度评估（可能 20 秒以上），深度评估的不阻塞下游，走异常路由。

这和产线上"快线/慢线分流"是同一套逻辑。

---

三个改动上线之后

三个改动上线之后，李雯跑了三天观察期。

第一天，全线超时事件从日均 11 次降到 3 次。第二天，2 次。第三天，0 次。

端到端平均处理时间从 47 秒（含超时等待）降到 19 秒（不含异常路由的订单）。异常路由每天走 4-6 个订单，人工复核平均 8 分钟一个。

她在节拍图上把那五个红框里的问号擦掉，改成了具体的节拍数字：

Agent A → B：3.2 秒（P95：7.1 秒） Agent B → C：4.2 秒（P95：5.8 秒，快速评估模式下） Agent C → D：2.8 秒（P95：6.4 秒，含缓存命中） Agent D → E：3.5 秒（P95：7.9 秒） 异常路由：日均 4.3 单，人工处理 8 分钟/单

还有两个红框没擦。一个标着"异常路由人工处理效率"，一个标着"Agent 节拍漂移监控"。这两个她还没完全搞定，但已经不急着擦了——她知道这是长期的活儿，和产线一样，节拍调好了还得持续盯着。

---

一张新图

三周后，李雯从柜子里翻出 2016 年画的第一张节拍图。

那张图上只有三个工位，标注潦草，时间是用铅笔记的，橡皮擦过的痕迹还看得见。那时候她刚当产线主管，排第一条线的节拍，排了三个通宵才定下来。

她看了看那张旧图，又看了看墙上最新的那张——现在上面有十几个方框，黑色的是传统工位，红色的是 Agent 工位，蓝色的是她加的缓冲区和异常路由。三类方框混在一起，箭头交错，像一张正在被重新画的地图。

她在图的空白处写了一行字：

产线换了零件，调线的逻辑没换。

然后把 2016 年那张旧图重新卷好，放回柜子里。