你的 Agent 可能正在“装忙”——不报错、不吭声，却在原地空转、闷声烧钱。ANOLISA（Agentic OS）的可观测组件 AgentSight 就专治这个，而且代码已经开源：https://github.com/alibaba/anolisa （src/agentsight/ 目录）。下面就讲它怎么把这些“沉默故障”一个个揪出来。觉得有用，顺手点个 star。
AI Agent 有一个共同的弱点：它不会主动告诉你它卡住了。
进程可能还在跑，端口探活依然有响应，可对话早就跑偏了：反复调用同一个工具却没有任何推进，中途被打断却没有任何报错，甚至进程已经崩了都没人发现。这类问题有个共同特征：没有报错，就没有日志可翻；进程没死，传统的存活探活也够不着。
这不是假设。Agent 会把工具结果不断回填进对话历史，循环调用、多轮推理，“无错误但无推进”就是其中一类真实存在、又很难归类的故障：它不触发任何错误码，进程日志里也不留痕迹，只有逐行比对对话历史才看得出来。
AgentSight 就是为了填补这个盲区。
什么是 AgentSight，它跟传统监控有什么本质区别
AgentSight 是ANOLISA（Agentic OS）的可观测组件。它装在你自己的机器上，观测你自己跑的 Agent，采集到的数据也只落在这台机器上。工作方式是零代码接入：不用 Agent 主动上报，不用 SDK 埋点，不用改一行代码，也不用重启进程，就能把 Agent 全链路的数据细粒度地采下来、关联起来。
这是它跟传统监控最根本的不同。传统做法无非三种：让 Agent 主动打日志（它不说，你就不知道）、在代码里插埋点（每换一个 Agent 框架都得重新集成一次）、在网络出口架代理（流量多走一跳，还可能因为加密握手方式变了就失效）。AgentSight 走的是另一条路，在内核层面采集本机 Agent 的流量。不管 Agent 用什么框架、什么语言写的，只要在这台机器上发过网络请求，就能被完整覆盖，而且对业务零打扰，不需要 Agent 那边做任何配合。
这里有个绕不开的问题：Agent 和大模型之间的流量几乎都是 TLS 加密的，在网卡或网络出口上抓到的只是密文。AgentSight 把观测点放在加密之前，取到的就是应用自己正在收发的内容。应用的 TLS 配置不用改，中间也不必加代理，原有的加密链路保持不动。Node、Python、Go 等主流 Agent 技术栈都覆盖得到。
采集在内核里做，开销控得很紧，超长响应会被截断并打上标记，不会因为一条大响应拖慢机器。部署上有个前提，需要较新的 Linux 内核并开启 BTF 调试信息，探针本身一次编译就能适配不同内核版本，不用为每台机器单独编译。
上面这套内核层采集只在 Linux 上跑。macOS 没有 eBPF，AgentSight 在那边换了一条路，直接扫本地 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/anolisa
2、在阿里云上开箱即用，参考 Alibaba Cloud Linux 4 Agentic 版入门文档：
本文档指导用户从购买ECS实例到体验Alibaba Cloud Linux 4 Agentic Edition的自然语言交互功能，全程仅需几分钟。-Alibaba Cloud Linux(Alinux)-阿里云帮助中心
—— 完 ——
阿里云智能体操作系统 Agentic OS：Agent 系统管家，致力于打造更高效更安全的 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
