ANOLISA AgentSight：让 Agent 的每一次“沉默”都无处躲藏

你的 Agent 可能正在“装忙”——不报错、不吭声却在原地空转、闷声烧钱。ANOLISAAgentic OS的可观测组件 AgentSight 就专治这个而且代码已经开源https://github.com/alibaba/anolisa src/agentsight/ 目录。下面就讲它怎么把这些“沉默故障”一个个揪出来。觉得有用顺手点个 star。AI Agent 有一个共同的弱点它不会主动告诉你它卡住了。进程可能还在跑端口探活依然有响应可对话早就跑偏了反复调用同一个工具却没有任何推进中途被打断却没有任何报错甚至进程已经崩了都没人发现。这类问题有个共同特征没有报错就没有日志可翻进程没死传统的存活探活也够不着。这不是假设。Agent 会把工具结果不断回填进对话历史循环调用、多轮推理“无错误但无推进”就是其中一类真实存在、又很难归类的故障它不触发任何错误码进程日志里也不留痕迹只有逐行比对对话历史才看得出来。AgentSight 就是为了填补这个盲区。什么是 AgentSight它跟传统监控有什么本质区别AgentSight 是ANOLISAAgentic OS的可观测组件。它装在你自己的机器上观测你自己跑的 Agent采集到的数据也只落在这台机器上。工作方式是零代码接入不用 Agent 主动上报不用 SDK 埋点不用改一行代码也不用重启进程就能把 Agent 全链路的数据细粒度地采下来、关联起来。这是它跟传统监控最根本的不同。传统做法无非三种让 Agent 主动打日志它不说你就不知道、在代码里插埋点每换一个 Agent 框架都得重新集成一次、在网络出口架代理流量多走一跳还可能因为加密握手方式变了就失效。AgentSight 走的是另一条路在内核层面采集本机 Agent 的流量。不管 Agent 用什么框架、什么语言写的只要在这台机器上发过网络请求就能被完整覆盖而且对业务零打扰不需要 Agent 那边做任何配合。这里有个绕不开的问题Agent 和大模型之间的流量几乎都是 TLS 加密的在网卡或网络出口上抓到的只是密文。AgentSight 把观测点放在加密之前取到的就是应用自己正在收发的内容。应用的 TLS 配置不用改中间也不必加代理原有的加密链路保持不动。Node、Python、Go 等主流 Agent 技术栈都覆盖得到。采集在内核里做开销控得很紧超长响应会被截断并打上标记不会因为一条大响应拖慢机器。部署上有个前提需要较新的 Linux 内核并开启 BTF 调试信息探针本身一次编译就能适配不同内核版本不用为每台机器单独编译。上面这套内核层采集只在 Linux 上跑。macOS 没有 eBPFAgentSight 在那边换了一条路直接扫本地 Agent 留下的会话文件Claude Code、Codex、Cursor 这类工具都认得转成统一格式后同样存进本机数据库用同一个面板查看。不需要 root也不挑内核版本。代价是拿不到内核层的进程和网络事件。AgentSight 也不会盯着机器上所有流量。它先弄清楚哪些进程是 AI Agent自动识别出来只给匹配上的挂探针别的一概不碰。这既是零侵入的一部分也把观测开销压在了真正该关注的目标上。抓到的原始流量AgentSight 会完整还原、解析出来。每次请求的内容、模型的返回、消耗的资源还有每一步工具调用的结果全存在本机可视化面板Dashboard里能实时查看。面板本身还管着 Agent 的实时健康监控、离线告警和卡死进程重启也能看会话级、对话级的 Token 消耗和 Agent 轨迹。采集完只是第一步。AgentSight 还会主动诊断故障逐条分析记录判断正不正常再把结论连同上下文一起存好。等你排查问题的时候就不用再凭感觉去翻海量原始记录了。四层诊断把问题从“说不清”变成“查得到”AgentSight 把故障诊断拆成四层每一层对应一个核心问题逐层缩小排查范围第 1 层进程还在不在Agent 在凌晨悄悄崩了没有告警也没有日志你却要等下次用的时候、发现活儿没干完才反推出它早就挂了。第一层是可用性监控也是最直接的一层可视化面板上随时能看到每个 Agent 当前的状态是活着、挂了、卡了、空转还是烧钱不推进。它盯三个最基本的问题进程还在不在、对话还能不能推进、Token 有没有在合理消耗。这里最关键的一处设计不是“怎么判断进程死没死”而是判断这次死亡到底有没有影响到用户。多数工具在进程消失时只会记一条“下线”日志AgentSight 会多查一步这个进程消失的那一刻是不是正好有一次对话请求还没处理完。如果有才算一次真正的故障没有就说明 Agent 是正常干完活退出的不记为异常。就这一步判断把绝大多数“正常退出被误报成崩溃”的噪音挡掉了。跟单纯做存活探测比这是最大的不同不是每一次进程死亡都值得关注只有真正打断了对话的那种才值得。内存不足是最常见的崩溃原因之一。AgentSight 会判定一次崩溃是不是因为内存不足被终止并保证这类记录不会因为极端情况而丢失——就算整机内存被打满事后回看崩溃历史依然是完整的。第 2 层调用失败了该找谁一次调用失败你翻了半小时日志才拼出“大概是被限流了”可到底该找模型服务商、还是自己的配额用光了——日志里没写。每一次向大模型发起的请求AgentSight 都会分析结果。失败了就根据返回内容、错误信息、响应耗时这些特征把失败精确归类再转成对应的责任方向是模型服务商出了问题是网络传输环节是 Agent 自己是用户输入超出了限制还是权限、配置有误。可视化面板上一目了然还按严重程度用颜色区分。这套分类能做到“一眼看出该找谁”关键在分类逻辑怎么设计。一次失败往往同时满足好几种判断条件比如既像限流又像服务超时要是把所有可能原因都列出来用户反而更难判断该信哪个。所以 AgentSight 只给一个最精确的结论而不是甩一堆疑似原因让你自己猜。排查时的噪音会明显少很多。工具调用失败的识别也是类似的思路。不同工具报错的格式千差万别有的用状态码有的用退出码有的用系统错误号。要是给每种工具单独写一套解析维护成本会随工具种类线性上涨永远追不上新工具冒出来的速度。AgentSight 选了一套跨工具通用的关键词识别不管是哪个工具报错只要错误信息里出现了指向“权限不足”或“依赖缺失”的典型表述就归进对应类别新增一个工具时不用专门给它写适配。更进一步就算 Agent 没集成任何上报接口只要它把工具执行结果放进了跟大模型的对话历史AgentSight 也能从对话内容里反向认出工具执行失败做到零接入成本的工具可观测性。第 3 层没报错但什么都没做到一个任务跑了很久还没结束你以为它在埋头干活点开一看它在同一个工具上来回空转、Token 一直在烧、进度却纹丝不动——这是最难排查的一类问题因为没有任何“出错”的证据。这一层是 AgentSight 跟普通监控拉开差距的地方。普通监控只抓得到“报错了”的问题抓不到“没报错但一直空转”的而后者在 AI Agent 场景里偏偏最常见也最烧钱。AgentSight 会跨越多轮调用分析整段对话的行为模式认出几种典型的“空转”信号反复调用同一批工具却毫无新进展连续多轮输出高度重复、几乎在自我复读或者上下文越堆越大输出却一点没变这通常意味着 Agent 一直在往上下文里塞历史实际什么都没推进。还有一种更隐蔽的Agent 遇到某类错误后闷头一遍遍重试却从不告诉用户表面一切正常其实早卡在原地。判断“这段输出是不是在重复”是这一层最核心的技术难点。AgentSight 用的是确定性的轻量算法不额外引入模型调用零成本、低延迟同一段内容判多少次结论都一致而且能明确指出重复出现在哪里。像中文这种没有天然分词边界的语言也做了对应处理。一旦确认 Agent 真陷进了死循环还能配上自动止血先给它一次温和退出的机会不理会就强制终止别让资源无限烧下去。这种“先礼后兵”的两级处理比一上来就强杀进程多给了 Agent 一个自行清理、保存状态的窗口也少了强制中断带来的副作用。第 4 层对话结束了结果到底能不能用一天几百个会话跑完老板问“质量怎么样”你只能一个个点开看看到第十个就眼花——尤其在需要批量巡检大量会话质量的场景下根本给不出一个拿得出手的结论。前三层告诉你哪里出了问题这一层给的是一份完整的评分卡。每次对话完成后可以触发一次质量评估从几个维度综合打分有没有给出可用的最终结果、运行过程健不健康、工具调用顺不顺、资源消耗合不合理、有没有触发安全相关的问题。综合下来给出通过、需要关注或未通过的结论再指出最主要的问题在哪附一条具体的排查建议。这套评估为什么用固定规则打分而不是让大模型来“评判”一段对话好不好出于几个很现实的考虑。用模型评判每评一次就多一次模型调用在频繁巡检大量会话时这笔开销累起来相当可观而且模型判断天生带不确定性同一段对话在不同时间评结论可能有细微出入没法当成稳定可靠的质量指标用。固定规则就没这个问题同一段对话评多少次结论都一致可以放心当成大规模巡检的基础指标而且几乎瞬间出结果不用等。代价是它读不出那种“回答看着挺完整、逻辑其实有问题”的语义瑕疵。规则打不出的那部分交给离线的因果分析来补。它不往 Agent 运行时里插手只读已经采集好的轨迹把一条扁平的会话重建成因果图再从最终产物往回追找出最早偏离的那一步。到了判断结论跟证据对不对得上这类语义问题才调用大模型并且要求它凭证据说话。跑通了但结果不对的情况像结论跟自己看到的证据矛盾、声称做完其实没做、产物里冒出输入里根本没有的东西都归这一步管。结论还会分清楚谁是元凶谁只是被上游连累。所有诊断数据全部保留在本机观测对象是你自己部署的 Agent数据也就停在你自己的机器上。AgentSight 不依赖任何外部服务采集到的数据和诊断结果直接落在本机不往外传。网络断了、远程服务挂了都不影响你翻历史、查现场。打开可视化面板就能顺着一次会话往下钻调用了几次模型、消耗了多少资源、异常前后发生了什么、最终的质量结论是什么。数据存在本机的一个嵌入式数据库SQLite里重启不丢写入的同时也能查。调用记录、Token 明细和异常事件分开存放按时间段、按 Agent、按会话都能快速查到。容量到了阈值会自动淘汰最旧的记录长期跑着的机器不会被它撞满磁盘。把这些记录串起来的那套标识是稳定的就算 Agent 崩溃重启同一段对话也能重新归并到一起不会因为进程号变了就断成两截。Token 消耗因此既能按会话汇总又能下钻到单条对话乃至某个 Skill异常也能定位到是哪一次调用、发生在对话的哪一步。对隐私敏感的场景可以只留元数据对话正文不落盘。必须留正文时AgentSight 支持落盘前加密用一次性对称密钥AES-256-GCM加密正文再用配置的公钥RSA-OAEP把密钥封起来。磁盘上始终是密文数据库文件被拷走也读不出原文。用户场景速查你遇到的情况AgentSight 帮你做了什么Agent 突然崩了记录一次崩溃事件并判断是否因内存不足导致对话到一半断了识别出流式响应被异常截断并关联到具体的调用记录工具调用失败了自动识别工具执行失败记录工具名称和具体错误信息大模型返回了空响应识别出请求成功但没有任何有效输出的异常情况调用响应特别慢标记出耗时超过阈值的调用帮助定位性能瓶颈服务配额用完了区分账单或配额耗尽与普通限流提示对应处理方式Agent 反复做同样的事检测到死循环模式记录具体的循环特征Agent 一直报错但不说检测到反复重试的异常行为标记为严重问题不知道调用为什么失败归类到具体的责任方向帮助判断该找谁排查这次对话结果好不好给出多维度质量评估结论、主要问题和排查建议想追溯某次异常的完整上下文顺着会话线索查询完整的调用链和异常记录前面这些能力AgentSight 里都已经落地了。我们诚挚邀请各位开发者试用体验若在实践中遇到不够顺手之处或是期待哪些新功能欢迎随时在仓库中提交 issue您的每一条反馈都将帮助它变得更好。快速使用指南如何安装和使用两处入口可供参考1、想从源码编译、看更多用法去 GitHub 仓库的 src/agentsight/ 目录https://github.com/alibaba/anolisa2、在阿里云上开箱即用参考 Alibaba Cloud Linux 4 Agentic 版入门文档本文档指导用户从购买ECS实例到体验Alibaba Cloud Linux 4 Agentic Edition的自然语言交互功能全程仅需几分钟。-Alibaba Cloud Linux(Alinux)-阿里云帮助中心—— 完 ——阿里云智能体操作系统 Agentic OSAgent 系统管家致力于打造更高效更安全的 Agent Native 环境。我们正在进入新的智能操作系统范式 Agentic OS 时代「阿里云智能体操作系统Agentic OS」是传统操作系统上叠加的一层转换层能更好地支持 Agent 使用操作系统并且使 Agent 获得更好的性能。我们重新定义了操作系统为您带来完整的 Agentic OS 体验。开源使用如果喜欢这个项目请点 Star ⭐支持。https://github.com/agentic-os-org/ANOLISA阿里云产品上使用https://help.aliyun.com/zh/alinux/agentic-os-getting-started