你的同事在周二下午三点发出那声哀嚎之前,整个工单系统已经安静了整整四天。一个生产环境的代理在某次长达11分钟的会话中,先是调了三个内部工具、穿过两个沙箱边界、等了一次人工审批、在一个子代理那里卡了47秒——最后返回了一个结果,没人知道对不对。他把原始事件日志从头翻到尾,七千三百行,像一个21世纪初期查Apache日志的运维。
我把这个事告诉了一个做SRE的朋友。他把自己的屏幕分享给我看:左边是Honeycomb在2026年创新周上推出的代理可观测性初版界面,右边是那个同事本周打开的第八个grep窗口。同一时间线上的两种职业画像。
![]()
代理监控这件事,我已经把它从“报表类”那栏挪到了“SRE生产基础设施”那栏。心情是有点不爽,但这种不爽很真实。你以前拿到一条追踪链路,是用来看懂一个请求发生了什么。现在这条链路要扛着一次代理运转的全过程跑:工具调用、子代理、沙箱、服务边界、审批节点、重试策略、副作用链。你得把每一步的决策和副作用同时追下去,追到跨越工具边界、MCP边界、沙箱边界和其他所有运行时边界的地步。
这件事的尴尬之处在于,链路还是那条链路,但对它的期待已经变了。它不再是给开发者在调试时随手翻翻的调试器,而是一条在事故发生一周后,当没有人记得那次会话的任何细节时,由SRE或安全调查人员作为证据去回溯的记录。它必须支持回滚操作。它必须能讲清楚一个从未通读过全量原始事件日志的SRE,也能一眼看明白这个代理到底干了什么、在哪一步跑偏了。
针对这个趋势,要把几个人的话按顺序看完。莎拉·卡特第一个点破核心问题:管理和监控代理需要对基础设施做彻底的重想,因为现有的系统在设计之初就不是为代理这种规模准备的。哈里森·蔡斯随后补了一句,相同的逻辑也完全适用于监控侧。然后查瑞蒂·梅杰斯把可观测性这一层的矛盾磨到了最锋利的状态——她说,用传统的交易和追踪构建块去追踪长时间运行的异步AI会话,存在一个巨大的问题。
这句话值得暂停几帧。什么叫“长时间运行的异步AI会话”?就是你发出一个指令之后,代理自己去做了十几分钟甚至几个小时的事,期间它做决定、调用外部系统、产生副作用、修改状态——这些都不是一个同步请求-响应的模型能装得下的。一段Web请求的形状很简单:请求进到处理器,调个数据库,可能走个队列,然后把响应返回给发起方。围绕这个形状,人们构建了他们的可观测性工具全家桶:跨度、日志、指标、单个范例、服务地图、仪表盘。现在你让一个异步跑了好一阵子的代理会话塞进这套架构,它就漏了。
那代理可观测性到底应该长什么样?朗链的可观测性文档给了一个很直白的答案:代理需要可见性覆盖到工具、提示、决策、工具调用、模型交互和决策点。朗史密斯的仪表盘文档又把这个界面翻译成了一套运营指标:追踪计数、延迟、错误率、令牌用量、成本、工具运行次数、工具错误、工具延迟、运行类型和反馈评分。把这行列表慢慢读一遍。你没有在看一份监控需求清单,你是在读一个代理控制面的雏形。
我自己喜欢追踪工具,我喜欢仪表盘。但有一点我非常不买账:假装原始日志就是记录本身。一次代理运转期间打出来的日志,把它当日志来读,完全没问题。可一旦进入生产环境的监控语境,这些日志变成了SRE事后复查的证据,链路就不止要跟着日志里的命令跑,还得跟着决策和副作用跑,跨过上述所有边界。所以这个结论很残忍:长时间运行的代理会话,就是会打破请求形态的思考框架。一个交易的追踪链路太小了,装不下它。
把这个逻辑推到底,针对长时间运行的代理会话的可观测性体系,正在演变成一套关于AI代理行为的底座系统:存储、身份、留存、关联和控制面。你可以继续叫它“监控”,如果这个标签让组织内部更好达成共识的话。但配人的时候不要照着报表系统来配。因为链路正在搬运一个比以前大得多的对象,而你还得保证一个不认识这个代理的SRE,能在事故记录里跑通整场复盘。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.