小刘和一面墙那么大的 AI 仪表盘
小刘的世界是一面墙。确切地说,是中控室里那面 4.8 米宽、2.2 米高的监控大屏。屏幕被切成了十几个区域——一车间的设备运行状态、二车间的温湿度监控、三车间的产线节拍、空压站的压力曲线、配电房的负荷分布、消防系统的状态灯、污水处理的水质指标……
200 多个实时指标,几十条报警线,每台关键设备一盏状态灯。绿色是正常,黄色是预警,红色是报警。任何一个指标越过报警线,屏幕右上角弹一条告警,同时他桌上的电脑也弹一条通知——两条确认才消除。
这就是小刘的日常。他盯着这面屏幕三年了。
桌上永远放着几杯咖啡。不是一杯——是几杯。早班一杯、午班一杯、晚班一杯、凌晨异常排查一杯。不同时段的咖啡放在不同位置——左边是当班的,右边是备用的,杯子旁边贴着时间标签。这个习惯是他第二年养成的,因为有一次凌晨三点排查异常时找不到咖啡,顶着困意多花了四十分钟。
他今年 29 岁,是华岳精密中控室调度员。全厂最年轻的技术岗之一。他的工作用一句话概括就是——让所有该看见的东西被看见。
设备温度在升高?他比车间主任先看见。产线节拍在变慢?他比产线主管先看见。空压机压力在波动?他比设备维护的人先看见。他不是做决策的人,他是让做决策的人"能看见"的人。
看不见的东西管不了。这句话是他入职第一天师傅教的,三年后他把它当成了信仰。
一块空白
去年秋天,厂里的 Agent 系统陆续上线。V-1 视觉质检、V-2 订单处理、T-1 文档处理主 Agent 加上十三个 support agents……
小刘等着仪表盘上多一块 Agent 监控区。等了一个月。没有。等了两个月。还是没有。
他问 IT 部:"Agent 系统的可观测性谁在做?"
IT 部的人想了想:"目前主要是看系统可用性——有没有宕机、API 有没有报错。详细的监控的话……还没排上。"
"没排上?"小刘有点不可思议。"一套在生产环境跑的系统,没有 observability?延迟多少?成功率多少?token 消耗多少?每个 Agent 每天烧多少钱?什么时候会挂?这些你们都不知道?"
"知道一些基本的数据。但没有实时的仪表盘,要看的话得去云平台后台查日志。"
小刘回到中控室,坐在那面 4.8 米宽的大屏前面,看着右上角那块空白区域。
那块区域原本是留给未来扩展的——黑色的背景,什么都没有。厂里所有的系统都在这面屏上有了自己的位置,只有 Agent 没有。
他想了两天。第三天,他去找了老周。
"老周,你管的那几个 Agent,每次请求的响应时间、token 消耗、成功失败状态,这些数据有没有?"
老周说:"有。云平台的 API 可以拉。我自己偶尔看一下,没有做成实时监控。"
"我能不能接?"
"什么意思?"
"我想把 Agent 的运行数据接到中控室的大屏上。和你看设备状态一样看 Agent 状态。"
老周看了他一眼。这个 29 岁的年轻人,眼睛里有种他熟悉的光——和他自己年轻时第一次调试新设备时一样。
"可以。我帮你对接 API。"
两周
小刘用了两周时间拼那块仪表盘。
第一周,他做了一件事——搞清楚"该看什么"。
他找老周聊了一次,找李雯聊了一次,找张师傅聊了一次,找陈姐聊了一次。问了每个人同一个问题:"你负责的那个部分,你最想看到什么数据?"
老周说:"每个 Agent 的响应时间分布。平均值不够,我要看 P50、P95、P99。因为 Agent 的'慢'不是均匀的,是偶尔突然慢——尾巴才是关键。"
李雯说:"端到端的 Trace——一个订单从 Agent A 到 Agent E,每一步花了多少时间,在哪一步卡住了。就像产线上追踪一个零件的流转路径。"
张师傅说:"Support agents 的异常率。不是总体的,是每个 S-Agent 单独的。S-4 映射错了多少次、S-2 OCR 校对失败了多少次——我需要看到每个 Agent 的'健康状态'。"
陈姐说:"每个 Agent 的输出质量评分。我定的那三个指标——基线准确率、高置信度错误率、变更回归率——我要能实时看到趋势。如果某个指标突然变差了,我得第一时间知道。"
小刘把所有需求汇总起来,画了一张草图——仪表盘分成四个区域:
Trace 区:单次请求的完整调用链。一个订单从进来到出去,经过了哪些 Agent,每一步的输入输出是什么,花了多少时间。点击任何一个节点可以展开看详情。
Metrics 区:每个 Agent 的核心运行指标——响应时间(P50/P95/P99)、成功率、错误率、队列深度。折线图,最近 24 小时。
Cost 区:每个 Agent 的 token 消耗和费用。按天、按周、按月。总计和分项。哪个 Agent 烧了多少钱,一眼就能看到。
Eval 区:每个 Agent 的输出质量评分趋势。陈姐定那三个指标的折线图——基线准确率、高置信度错误率、变更回归率。
四个区域占了屏幕右上角大约 1/5 的面积。和他现有的设备监控区并列。
第二周,他做第二件事——把数据接进来。
这一步比他想象的难。不是因为技术复杂,是因为数据分散——Agent 的日志在云平台、token 消耗在计费系统、运行指标在 APM 工具、质量评分在陈姐那个活页夹(还没电子化)。
他花了一周时间,一个一个接。先接最容易的——云平台的 API 拉 Agent 的请求日志和响应时间。再接 APM 的指标数据。然后接计费系统的 token 消耗。最后花了一天时间把陈姐活页夹里的质量评分数据手动录入了一个简单数据库,设了自动更新流程。
"这个过程就像给一台新设备接线——传感器在哪儿、信号线走哪条、怎么接入 PLC、画面怎么排布。"他对老周说。"我干了三年接线活了。只不过这次接的不是设备传感器,是 Agent 的数据接口。"
老周帮他调通了最后几个 API 接口。两个星期的晚上和周末,小刘基本上住在了中控室。
上线第一天
Agent 监控仪表盘上线那天,是周三下午两点。
小刘把四个区域的数据流全部打开,看着数字开始跳动。
Trace 区:一个订单正在经过 Agent A → B → C → D → E,每一步的时间在实时刷新。3.1 秒,4.5 秒,2.8 秒,3.2 秒,2.1 秒——全线通过,端到端 15.7 秒。
Metrics 区:每个 Agent 的 P50 响应时间在 2-5 秒之间,P95 在 8-15 秒之间。V-2 订单处理 Agent 的 P99 出现了一个 28 秒的尖峰。
Cost 区:今天到目前为止,所有 Agent 合计消耗 token 约 47 万,对应费用 234 元。
Eval 区:陈姐录入的最近两周的质量评分——V-1 基线准确率稳定在 97.1%-97.3%,V-2 高置信度错误率 0.2%-0.3%,T-1 主 Agent 的数据还不多。
一切看起来正常。小刘松了一口气。然后他注意到了一件事。
他习惯性地看了一眼 Metrics 区的 24 小时趋势图。V-2 订单处理 Agent 的响应时间曲线,白天平稳,但在凌晨 3 点有一个明显的尖峰——平均响应时间从白天的 3 秒左右跳到了 12 秒。
他点进去看详情。凌晨 3 点的尖峰不是偶发的一两次——是每天凌晨 3 点都出现,连续五天了。
他查了 Trace 区凌晨 3 点的记录。V-2 在那个时间段的请求都正常处理了,没有报错,但每次都多花了 8-9 秒。
他去找老周。
"老周,V-2 每天凌晨 3 点延迟飙升到 12 秒,你注意过吗?"
老周想了想。"凌晨 3 点?那个时间段基本没有订单进来,我没看过那个时段的数据。"
小刘把趋势图调出来给他看。老周盯着那个每天凌晨 3 点准时出现的尖峰看了半天。
"我查一下。"
查了半小时,找到原因了——每天凌晨 3 点是模型热更新的时间窗口。云平台在那个时段推送模型微调更新,V-2 在更新过程中响应时间会变长。影响不大——白天的正常业务不受影响,因为更新在凌晨完成。但小刘发现的这件事本身很重要:如果没有这块仪表盘,没有人会知道这件事在发生。
老周看着小刘拼出来的仪表盘,说了一句:"你这块屏,比我自己的监控工具还好用。"
小刘没接话。他在仪表盘的 Metrics 区给 V-2 加了一条新的报警线——凌晨时段响应时间超过 10 秒自动告警。然后他在桌上又放了一杯咖啡。
凌晨 3 点的异常排查,成了他的第五个高峰时段。
五杯咖啡
仪表盘上线三周后,小刘已经发现了四个以前没人注意到的 Agent 运行问题。
除了 V-2 凌晨 3 点的延迟尖峰,还有:
S-4 术语映射 Agent 的响应时间在每周一下午 2 点到 3 点之间规律性升高——追查发现是因为每周一上午集中上传的一批客户文档在下午触发了一波映射高峰,S-4 的并发处理能力不够。他报给了张师傅,张师傅给 S-4 加了个队列缓冲。
T-1 主 Agent 的 token 消耗在过去两周以每天 8% 的速度增长——没人注意到,因为绝对金额还不算大。但趋势不对。他调了 Cost 区的 30 天趋势图,把截图发给了老周和郑总。后来发现是某个外部 API 的返回数据格式变了,Agent 每次处理都多消耗了一倍的 token。
V-1 视觉质检 Agent 的识别准确率在某次模型更新后,P95 响应时间从 1.2 秒变成了 2.8 秒——陈姐的抽样检测没测出来(因为抽样的是准确率不是速度),但仪表盘的 Metrics 区一眼就看到了。
四个问题,全是他从那块仪表盘上"看见"的。如果这块屏不存在,这四个问题要么不会被发现,要么要等到变成事故才会被发现。

有天下午,王工来找他做日常安全交接。
王工看着屏幕右上角新增的那块 Agent 监控区,站了一会儿。
"小刘,你这块屏做得好。安全监控也是一样——看不见的东西管不了。"
小刘说:"王工,你那面安全墙和这面屏,本质上是一回事。你是把事故案例变成看得见的教训,我是把运行数据变成看得见的状态。手段不同,目标一样——让问题在变成事故之前被看见。"
王工点了点头,走了。
小刘看着那面 4.8 米宽的大屏。右上角那块新区域现在挤满了数据——Trace 的调用链、Metrics 的折线图、Cost 的柱状图、Eval 的趋势线。和左边的设备监控区、右边的产线监控区放在一起,它不再是空白了。
桌上放着五杯咖啡。最早的那杯标签写着"早班 7:00",最新的那杯标签写着"凌晨 3:00 异常"。五杯咖啡,五个盯屏的高峰时段。
他师傅教他的那句话——"看不见的东西管不了"——现在有了下半句。
看见了,才管得了。
相关手记
郑总 55 岁,从基层干到副总。他不写代码,但要决定工厂怎么建 AI——什么时候招什么人、每月 token 烧多少钱、哪些 Agent 的 ROI 为正。前面七个工位的故事在这里汇合,他要拼出一座能算清账的工厂。
吴师傅 58 岁,精密装配的"手艺人",三次自动化都没替代的异常判断高手。技术团队找他帮贷款审批 Agent 设计人工复核节点——他们假设"AI 能做的都交给 AI",吴师傅的标准是"出错了谁负责、谁能兜住"。
王工管了十五年工厂安全。直到发现客服 Agent 在测试环境访问了财务系统——没人认为这是安全问题,他直接断网了。然后开始建一套"AI 版 HAZOP",依据不是 AI 安全框架,是十五年的 EHS 逻辑。