北京
你的同事在周二下午三点发出那声哀嚎之前，整个工单系统已经安静了整整四天。一个生产环境的代理在某次长达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.
