张师傅和十几个没人看见的 Sub Agent

张师傅的手机响了。

凌晨两点十七分，第六个监控 App 弹了一条告警——"术语映射异常，疑似匹配冲突"。他闭着眼睛摸到手机，划开看了三秒，把告警截了图发到维护群，翻身继续睡。

这不是第一次了。他的手机里有六个监控 App，分别对应厂里 AI 系统的六类运行指标。每天平均弹 12 条告警，其中 10 条和主 Agent 无关，全部来自背后的十几个 Sub Agent。这些 App 是他自己找 IT 部装的，没人要求他装。

张师傅全名张国民，45 岁，华岳精密设备维护班组长。2005 年进厂，从学徒干起，现在管着全厂 200 多台设备的日常维护——从加工中心到检测仪器，从空压机到空调机组。没人比他更清楚什么设备什么时候会坏，因为他维护的方式不是"坏了再修"，是"快坏了之前换"。

他有一套自己总结的方法——每台设备一份维护台账，记录"上次检查时间"、"易损件寿命"、"异常前兆模式"。200 多台设备，200 多份台账，全在他电脑里，备份两份。

去年开始，他的"设备"多了十几个新成员。

---

十三台看不见的设备

厂里的文档处理系统是去年春天上的。这套系统用来处理客户发来的技术文档——工艺规范、质量标准、检验报告——把它们统一翻译成厂里内部格式，录入系统。

系统的"门面"是一个主 Agent，负责理解文档内容、提取关键信息、生成结构化输出。这个主 Agent 用的是某大厂的 API，每月更新一次模型。每次更新，IT 部都会发一条通知："T-1 主 Agent 已更新至 v3.x，本次优化了……"——然后发在厂里公众号上，标题类似"华岳精密 AI 系统再升级"。

张师傅不管这个主 Agent。他管的是背后的十三个 Sub Agent。

厂里的人叫它们 Support Agent——"S"就是 Support。但行业里有个更通用的叫法：Sub Agent，子代理。它们做的是主 Agent 没空做、不该做、或做不好的那些事——格式转换、OCR 校对、术语映射、单位换算。老周在设计这套系统的时候定了一条规矩：一个 Agent 只做一件事。 主 Agent 擅长的是理解和生成，但格式转换需要专门工具，OCR 校对需要专门规则库，术语标准化需要映射表。把这些全塞进主 Agent 里，它会变慢、变不可控。拆出来，十三道预处理工序，每一道变成一个独立的 Sub Agent——这就是为什么是十三个，不是八个也不是二十个。

这十三个 Agent 没有名字，只有编号。S-1 到 S-13：

S-1：格式转换——把 PDF、Word、Excel、扫描图片统一转成结构化文本。

S-2：OCR 校对——扫描件的 OCR 结果做二次校验，纠正识别错误。

S-3：错别字修正——识别并修正文档中的常见错别字和输入错误。

S-4：术语统一——把不同客户使用的不同表述统一映射到厂里的标准术语。比如甲方叫"表面粗糙度 Ra≤0.8"，乙方叫"光洁度 ▽7"，要统一映射成厂内标准"表面粗糙度 Ra0.8"。

S-5：单位换算——英寸到毫米、磅到公斤、psi 到 MPa。

S-6：公差解析——把各种公差标注格式统一转换成"名义值±偏差"的标准格式。

S-7：合规检查——对照行业标准和法规，检查文档中的合规性条款是否完整。

S-8：内部术语映射——把行业标准术语进一步映射到华岳精密的内部工艺编码。

S-9：版本比对——对比新旧两版文档，标注差异部分。

S-10：图表提取——把文档中的表格和图表数据提取成结构化数据。

S-11：签名验证——检查文档上的签章和审批流程是否完整。

S-12：语言检测——识别文档语种，非中文文档触发翻译流程。

S-13：完整性校验——检查文档是否包含所有必要章节和字段。

十三个 Sub Agent，每一个都是老周带着他的团队一个个搭的。老周管"造"，张师傅管"养"。

张师傅很快发现了一件事：主 Agent 的工作量大约占整个系统的 30%，剩下 70% 是这十三个 Sub Agent 在干。但 70% 的故障也出在这十三个身上。

这个数字是他自己统计的。系统上线两个月后，他开始给每个 Sub Agent 单独记故障日志——和管 200 台设备一样的做法。

第一个月的数据：

• 主 Agent T-1：故障 2 次（一次模型 API 超时，一次输出格式异常）
• S-1 到 S-13 合计：故障 31 次

故障最多的三个：S-4（术语映射）11 次，S-2（OCR 校对）8 次，S-5（单位换算）6 次。

张师傅把这个数据写在维护台账的首页：

T-1 文档处理系统维护台账

运行首月故障统计：主 Agent 2 次，Sub Agent 31 次。

主 Agent 占工作量 30%，故障占比 6%。 Sub Agent 占工作量 70%，故障占比 94%。

结论：系统的风险不在主 Agent，在 Sub Agent。

他把这份统计抄送了三个人——老周、陈姐、郑总。

老周看了，说："张师傅，你比我们 IT 部还清楚这套系统的真实状况。"

陈姐看了，说了一句："这和我管质量一样——主材出问题大家都知道，辅料出问题往往到最后才发现。"

郑总看了，没说话。第二天让 IT 部给张师傅开通了所有 Sub Agent 的独立监控权限。

十三个 Sub Agent 不是各干各的。它们之间有一条依赖链——S-1 的输出是 S-2 的输入，S-4 的术语映射结果影响 S-8 的内部编码，S-12 如果检测到非中文，会触发翻译流程后再回到 S-3 做错别字修正。张师傅画了一张依赖关系图，贴在办公桌前的墙上。每个 Sub Agent 是一个节点，节点之间用线连接。他指着这张图说："这和工厂的设备布局图是一回事——哪台设备停了会影响哪条产线，一眼就能看出来。"

---

热处理变成了热镀锌

但真正让所有人意识到问题严重的，是两个月后的一个凌晨。

凌晨两点十七分，张师傅的手机响了。S-4（术语映射）弹了一条告警——"映射冲突"。他闭眼看了一眼，截图发到维护群，翻了个身。

早上八点到厂，他打开 S-4 的日志看昨晚的告警详情。看到的瞬间，手里的茶杯放下了。

S-4 在前一天下午四点的一次更新中，把"热处理"的映射规则改了——从原来的"热处理 → heat-treatment"变成了"热处理 → 热镀锌"。

这个改动不是人做的，是 S-4 的自动学习模块根据最近的映射数据"自作主张"调的。最近一批客户文档里"热镀锌"这个词出现频率突然升高（因为一个新客户的工艺规范大量涉及镀锌工艺），S-4 的统计模型认为"热处理"和"热镀锌"是相关术语，自动把映射拉近了。

这个错误在下午四点到晚上十点之间，影响了三份技术文档——把三份标注"需经热处理"的工艺要求，错误地映射成了"需经热镀锌"。

热处理和热镀锌是完全不同的两种工艺。热处理是加热冷却改变材料性能，热镀锌是表面防腐涂层。搞混了，零件做出来性能不达标，严重的会出安全事故。

这三份文档已经发给了一个客户的对接人。第二天上午客户就打来了电话——"你们发来的工艺方案里，热处理写的是热镀锌？这是怎么回事？"

---

上午十点，紧急会议。老周、张师傅、IT 部、陈姐，还有郑总。

IT 部先解释了原因——S-4 的自动学习模块触发了错误的映射调整。老周当场关掉了 S-4 的自动学习功能，改回人工审核映射变更。

陈姐问了一个问题："这个错误在 S-4 的运行日志里有记录吗？"

张师傅说："有。S-4 每次映射变更都会记一条日志。但这条日志混在每天几百条 S-4 的日常日志里，没有人设告警规则去筛它——因为从来没人觉得 S-4 需要单独监控。"

陈姐转头看了看郑总："郑总，这就是我一直在说的事。我们的质量体系只覆盖了主 Agent，Sub Agent 在体系外面。"

郑总沉默了几秒，说了一句："张师傅，你的台账里有没有记录过类似的风险？"

张师傅翻开电脑里的维护台账，找到 S-4 的那一页。上面有一条三周前的记录：

3 月 8 日，S-4 术语映射

近期映射变更频率升高（日均 3 次→7 次），自动学习模块似乎在加速调整。

建议：对涉及工艺关键术语的映射变更，增加人工审核环节。

状态：已提交 IT 部。

这条建议三周前就提交了。IT 部排了优先级，排在"中"，还没排到。

张师傅看着那条记录，说了一句："主设备坏了大家都看得见，流水线上那些小支架断了，只有我知道。"

会议室安静了十秒。

这件事里其实有两个问题。一个是设计问题：S-4 被赋予了自动学习能力，但没有任何护栏——什么术语可以自动调、什么术语必须人工确认，当初老周把它设计出来的时候没有界定这条线。另一个是维护问题：自动学习模块的变更日志已经存在，但没人设告警去筛它，张师傅三周前的预警也排不上优先级。

前一个是老周该管的，后一个是张师傅该管的。两个问题撞在一起，才变成了客户投诉。

---

设备是这样养出来的

那天之后，张师傅开始正式把十三个 Sub Agent 纳入他的设备维护体系。

做法很简单——和管 200 台设备一模一样。

第一，给每个 Sub Agent 单独建台账。 S-1 到 S-13，每个一份。记录内容和其他设备一样："上次检查时间"、"已知问题"、"依赖关系"（哪些 Agent 的输出会影响其他 Agent 的输入）、"变更历史"（每次映射规则或参数调整的记录）。

第二，给每个 Sub Agent 定"巡检周期"。 高风险的（比如 S-4 术语映射、S-7 合规检查）每天巡检一次，中风险的每周一次，低风险的每月一次。巡检内容不是看日志，是"主动测试"——和设备巡检一样，用标准样品跑一遍，看结果对不对。

第三，建立"变更冻结"机制。 任何 Sub Agent 的参数、映射规则、模型版本发生变更，必须先在测试环境跑一遍标准测试集，通过后才能上线。这和设备换零件要"先测后装"是同一套逻辑。

---

做完这些之后，张师傅的监控 App 从六个变成了七个。

新加的那个是 Sub Agent 专用监控面板——IT 部按他的需求做的，把十三个 Sub Agent 的关键运行指标集中在一个界面。他设了两类告警：一类是"硬故障"（Agent 崩溃、超时、无响应），一类是"软异常"（输出分布偏离基线、映射变更频率异常、依赖链中断）。

"硬故障"弹通知，"软异常"每天早上八点发一份摘要到他的邮箱。

他说："管 200 台设备也是这样——有些故障必须立刻响应，有些只要每天看一眼就行。关键是你得'看'，不能不看。"

有天老周路过他的办公室，看到墙上那张依赖关系图，站住看了半天。

"张师傅，你这张图画得比我清楚。我这造设备的，都没你这么细地梳理过依赖关系。"

张师傅正在给 S-9 的台账写备注，头也没抬："老周，你管造，我管养。造一台设备三个月，养一台设备三十年。我们干维护的，看的从来不是设备有多先进，是它会在哪里出问题。"

老周笑了笑。他知道张师傅说的是对的——2005 年他进厂那会儿，就是老周带的他的第一个徒弟。二十年过去，老周还在造设备，张师傅在养设备。两个人一造一养，把厂里的设备体系撑了起来。

只不过现在，"设备"的定义又扩大了一圈。

---

张师傅办公桌的抽屉里，有一张照片。2005 年拍的——他刚进厂时，穿着崭新的蓝色工装，腰间挎着崭新的工具腰带，站在一台加工中心前面笑。工具腰带早就换成了笔记本电脑包。但他走路的姿势还是老师傅的——微微弯腰，步子不大不快，眼睛习惯性地扫着两边的设备状态灯。只是现在他扫的不仅仅是设备状态灯了。