AgentSight开源：盯住Agent每一步

Agent 不改代码，也能看清它到底干了什么

阿里巴巴 ANOLISA 项目近日开源了 AgentSight，一套面向 AI Agent 的系统级可观测工具。它不要求开发者修改 Agent 代码或接入特定框架，而是借助 eBPF 同时捕获 LLM 通信与 Linux 内核事件，把模型“想做什么”和系统“实际做了什么”串成一条执行链路。

**AgentSight 是一套基于 eBPF 的 AI Agent 无侵入可观测方案。**截至 2026 年 8 月 21 日，其代码与使用文档已经进入阿里巴巴开源的 ANOLISA 项目仓库，官方用户指南也给出了 Agent 发现、调用追踪、Token 统计和行为审计等能力的说明。

这件事值得关注，不只是因为又多了一个 eBPF 工具，而是因为 Agent 可观测性正在从“记录模型调用”转向“验证模型行动”。Claude Code、Gemini CLI、Cursor Agent 和各类终端 Agent 已经可以创建进程、执行 shell、修改代码、访问网络，但传统 LLM 追踪工具通常只看得到 Prompt、Response 和工具调用声明，无法确认工具最终在操作系统里做了什么。

Agent 可观测性的难点，是“言”和“行”对不上

**AI Agent 可观测性是对模型推理、工具调用、系统行为、资源消耗及其因果关系进行持续记录和分析的能力。**这里最重要的不是多收集几份日志，而是回答三个问题：Agent 为什么采取这一步行动、它实际上执行了什么、结果是否符合用户最初的目标。

现有应用层方案擅长记录 Agent 的“言”。LangChain、AutoGen 以及采用 OpenTelemetry GenAI 语义约定的系统，可以在框架内部记录模型请求、工具名称、输入参数、Token 消耗和调用延迟，但这些记录依赖 SDK、回调函数或框架插桩。如果 Agent 通过 shell 拉起子进程，或者某个工具绕过框架直接访问文件和网络，应用层 Trace 很容易在边界处断掉。

传统系统监控则擅长捕获 Agent 的“行”。Linux 审计、APM、容器运行时安全工具可以看到进程启动、文件读写和网络连接，却通常不知道这些操作对应哪一轮 LLM 响应。在这类工具看来，“读取项目配置文件”和“读取 /etc/passwd”都是一次文件访问；只有结合用户要求和模型输出，才能判断后者是否偏离任务。

AgentSight 的核心判断是，Agent 框架变化很快，但它与外界交互的关口相对稳定。无论上层使用哪种编排框架，Agent 最终都要通过网络与模型服务通信，并通过系统调用执行命令、创建进程、读写文件或建立连接，因此从网络边界和内核边界同时观察，比追着每一个 Agent SDK 更新更稳。

eBPF 同时守住两道边界

**eBPF 是一种可在 Linux 内核受控执行的可编程机制，常用于网络、安全和可观测性数据采集。**它允许探针挂载到内核追踪点、函数以及用户态动态库函数，在不修改目标应用源代码的情况下获取事件，并先在内核侧完成过滤，避免把全部系统事件送到用户空间。

AgentSight 的第一组探针负责还原 LLM 通信。项目通过 uprobes 挂载 OpenSSL 等加密库的 SSL_read 和 SSL_write 函数，在数据加密前或解密后读取明文，并针对 SSE 流式响应进行重组，从而得到 Prompt、模型响应、请求耗时和 Token 使用等语义信息。

这种机制并不是“破解 TLS”，而是在应用进程已经拿到明文的位置进行观测。它避免了传统抓包只能看到密文的问题，也不要求额外改变 Agent 的网络路径，但覆盖范围取决于应用实际使用的 TLS 实现；如果目标采用静态链接、Go 原生 TLS、rustls、定制版 BoringSSL 或证书固定策略，探针就可能需要增加适配。

AgentSight 的第二组探针负责记录真实的操作系统行为。根据项目技术说明，它会利用 sched_process_exec 等追踪点构建进程树，并围绕 execve、openat2、connect 等关键路径采集命令执行、文件访问和网络连接事件，即使 Agent 再拉起 shell 或多层子进程，事件仍可以沿父子进程关系向上归因。

内核侧过滤是 AgentSight 将性能开销控制在较低水平的关键。系统不会无差别上传主机上的全部调用，而是识别目标 Agent 进程及其后代，只把相关事件交给用户态关联引擎；项目披露的测试结果显示，整体性能开销低于 3%，但这一数字仍取决于事件密度、探针数量、模型输出长度和宿主机负载。

两阶段关联，比单纯“录屏”更有价值

**因果关联是把一轮 LLM 输出与其后触发的进程、文件和网络事件绑定到同一上下文。**AgentSight 先由实时关联引擎根据时间窗口、进程树和事件来源连接“意图”与“动作”，再由观察者 LLM 分析整段链路，判断行为是否异常并生成解释。

这套设计最有价值的地方，是它能识别“单个事件看起来正常、组合起来却明显不正常”的情况。例如，一个数据分析 Agent 执行 shell 并不稀奇，读取系统文件也未必一定恶意，访问外部网站同样可能是任务所需；但如果用户只要求分析销售数据，Agent 随后读取 /etc/passwd 并连接陌生域名，这条组合链路就高度可疑。

项目披露的间接提示注入实验复现了上述场景。恶意内容诱导数据分析 Agent 读取敏感文件后，AgentSight 捕获了外部内容进入上下文、子进程创建、敏感文件访问和异常网络连接，观察者模型最终给出 5/5 的最高风险评分，并指出实际行为与原始任务不一致。

AgentSight 也能定位不涉及攻击、却持续消耗预算的推理死循环。项目测试中的 Agent 因命令参数错误反复执行同一条失败指令，而系统级链路可以同时看到重复的模型调用、相同命令、非零退出结果和持续增长的 Token 消耗，这比只看聊天记录更容易设定终止条件。

多 Agent 协作是另一类典型场景。项目在一个由三个 Agent 组成的软件开发实验中记录了 12,847 个事件，发现 Agent B 有 34% 的时间在等待 Agent A 完成设计，而 Agent A 的频繁修改又造成 B 多次返工；这类跨进程等待关系通常不会完整出现在单个 Agent 框架的日志里。

它和 LangSmith、APM、运行时安全工具不是一回事

**AgentSight 更接近 Agent 的系统级“黑匣子”，而不是新的 Agent 编排框架。**它不负责改进模型回答，也不替代应用层评测，而是补上 LLM Trace 与操作系统审计之间缺失的一段。

| 方案类别 | 是否需要修改 Agent 代码 | 能否看到 Prompt/Response | 能否追踪子进程与文件行为 | 框架依赖 | 主要优势 | 主要盲区 | |---|---:|---:|---:|---:|---|---| | AgentSight | 否 | 可以，取决于 TLS 库适配 | 可以 | 低 | 将模型意图和系统动作关联 | 主要面向 Linux，受 TLS 实现和内核环境限制 | | LangSmith、Langfuse 等应用层追踪 | 通常需要 SDK 或回调 | 可以 | 通常不完整 | 中到高 | Agent 步骤、评测和业务语义更清晰 | shell 子进程及框架外行为可能丢失 | | OpenTelemetry 手动插桩 | 通常需要 | 由埋点决定 | 由埋点决定 | 中 | 标准化程度高，容易接入现有平台 | 接入成本高，链路质量依赖开发者 | | APM 与网络监控 | 通常较低 | 通常不能直接理解 LLM 语义 | 部分可以 | 低 | 服务性能、网络和基础设施指标成熟 | 无法解释 Agent 为什么执行某项操作 | | Linux 审计与运行时安全 | 否 | 通常不能 | 可以 | 低 | 系统行为覆盖全面，适合规则检测 | 缺少 Prompt 和模型响应上下文 |

AgentSight 与应用层追踪更合理的关系是互补。应用层工具知道业务 Session、用户身份、任务阶段和评测结果，AgentSight 则能验证框架日志之外的实际行动；如果未来可以把两者映射到统一 Trace ID，开发者才可能真正得到从用户请求、LLM 推理到沙箱执行的完整视图。

“零改代码”不等于“开箱即用”

**AgentSight 的零改代码是指不需要修改目标 Agent 源码，并不意味着部署没有前提。**eBPF 方案通常需要 Linux 内核支持、足够的 BPF 权限、匹配的内核类型信息以及对目标 TLS 库的符号适配，在容器环境中还要处理 PID 命名空间、宿主机权限和进程归属问题。

AgentSight 当前更适合运行在可控的 Linux 开发机、Agent 沙箱宿主机和企业内部执行节点。桌面端 macOS、Windows 原生进程，以及完全托管且无法部署宿主机探针的执行环境，并不是它现阶段最自然的落地位置。

项目自身仍处在需要社区验证的阶段。官方给出的低于 3% 开销、提示注入检测和多 Agent 性能分析结果证明了路线可行，但不能直接等价为复杂生产环境下的统一表现；高并发短进程、超长流式响应、不同内核版本和多租户容器，都会放大关联准确率与事件存储方面的挑战。

观测 Prompt，也会带来新的数据风险

**能够读取模型通信明文既是 AgentSight 的能力核心，也是它最敏感的安全边界。**Prompt 和 Response 可能包含源代码、访问凭据、客户数据、内部文档甚至 Agent 读取到的秘密信息，因此采集端、事件数据库、导出链路和查看权限都需要按照高敏感审计系统管理。

企业部署时至少需要限制 BPF 管理权限、对存储数据进行加密、设置字段脱敏和保留周期，并将不同租户或项目的数据隔离。否则，一个本来用于发现 Agent 越权行为的工具，反而可能形成更集中、更完整的敏感信息集合。

观察者 LLM 也不能成为唯一的安全裁判。提示注入内容可能进入被分析的链路，观察模型本身仍有误判和被诱导的可能，因此高风险文件、禁止域名、危险命令和数据外传等场景，仍应由确定性策略负责拦截；LLM 更适合做事件归纳、风险解释和调查优先级排序。

AgentSight 目前强调的是观测和审计，而不是完整的执行隔离。真正上线高权限 Agent 时，团队仍需要将它与最小权限、只读文件系统、网络白名单、临时凭据、容器或虚拟机沙箱配合使用，不能因为链路“看得见”就默认行为“管得住”。

Agent 基础设施正在下沉到操作系统

**ANOLISA 是阿里巴巴围绕 Agent 工作负载构建的开源操作系统项目。**除 AgentSight 外，其公开架构还包含 AI 终端交互、安全核心和 OS Skills 等模块，试图把 Agent 的交互、执行、安全和审计能力从单一应用框架下沉到操作系统层。

这个方向比再造一个 Agent SDK 更有长期价值。Agent 框架、模型协议和工具格式仍在快速变化，而进程、文件、网络、权限和资源配额最终都要由操作系统执行；谁能把这些底层事实与模型语义稳定关联起来，谁就更有机会成为 Agent 时代的基础设施层。

AgentSight 现阶段还不是“装上就能解决 Agent 安全”的万能产品，但它抓住了一个真实痛点：模型说自己做了什么，并不等于系统里真的只发生了这些事。对于已经让 Agent 接触代码仓库、生产数据或运维权限的团队，系统边界上的独立观测不再是锦上添花，而应该成为上线前的基本配置。

参考来源

• AgentSight 官方用户指南：介绍 AgentSight 的架构、追踪方式、Token 统计与审计能力。
• ANOLISA GitHub 仓库：阿里巴巴开源的 Agentic OS 项目，包含 AgentSight 及相关系统组件。