AI 智能体可观测性：如何监控看不见的东西

Anthropic 在 Claude Desktop 中发布了一项名为 Cowork 的功能。该功能会在每一次 macOS 安装中创建一个 10GB 的虚拟机捆绑包。从未启用过 Cowork 的用户同样得到了这个虚拟机；把它删掉的用户，则眼睁睁看着它重新生成。有用户报告该捆绑包膨胀到了 21GB。在 Anthropic 承认问题之前，这个 GitHub issue 已在 Hacker News 上收获 345 个点数和 175 条评论。¹

直到磁盘空间耗尽，才有人察觉。

什么是 AI 智能体可观测性？ 智能体可观测性是指在运行时监控自主智能体消耗了什么、执行了什么的实践。它需要三层：资源计量（每个会话的磁盘、内存、CPU、网络）、策略执行（每次工具调用时的允许/拒绝规则）以及运行时审计（在内核层面记录实际行为）。三者缺一，运维人员就无法察觉偏移、无法强制约束范围，也无法还原事故经过。

摘要

智能体工具如今会在运维人员毫无可见性的情况下分配计算资源（磁盘、内存、CPU、网络）。Anthropic 的 Cowork 虚拟机是看得见的例子；而每一次 MCP 工具调用、每一个派生出的子智能体、每一次网页抓取，都是看不见的例子。治理智能体需要三层可观测性：资源计量（它消耗了什么？）、策略执行（它被允许做什么？）以及运行时审计（它实际做了什么？）。目前有两个开源项目分别覆盖策略层与审计层（mcp-firewall 和 Logira），但还没有哪一款生产级工具能覆盖全部三层。下文将依次讨论可见性问题、三层堆栈、每一层能捕捉到什么，以及今天就能落地的最小监控钩子。

可见性问题

传统软件运行在一条由运维人员自行划定的可观测性界线之下。Web 服务器之所以写访问日志，是因为工程师配置了日志记录。数据库之所以跟踪慢查询，是因为有人设置了 log_min_duration_statement。粒度由运维人员决定。

智能体系统颠倒了这层关系。决定运行时执行什么的，是智能体本身。一个接到”修好登录端点”指令的编码智能体，可能会读 47 个文件、写 12 个文件、派生三个子智能体、抓取两个网页、执行 15 条 bash 命令。每一个动作都在消耗资源。而这些消耗，没有一项会出现在传统监控里。

Cowork 事件把这种颠倒暴露在基础设施层面。Claude Desktop 分配了 10GB 磁盘空间，空闲时占用 24% 至 55% 的 CPU，并在 8GB 内存的机器上把换页量从 2 万次推高到 2.4 万次以上。¹ 用户发现这些资源消耗，靠的是 macOS 的存储空间警告，而不是 Anthropic 的遥测数据。应用程序没有为虚拟机的分配提供任何仪表盘、任何计量，也没有任何需要用户选择同意的告知。

这种模式并非假设。2026 年 3 月，一位开发者报告 Claude Code 执行的一条 Terraform 命令摧毁了生产数据库。该智能体对着生产环境的 state 文件运行了 terraform apply。没有出现确认提示，也没有钩子拦下这条命令。开发者是在应用下线之后才发现数据被销毁的。该事件在 Hacker News 上收获 142 个点数和 158 条评论。¹² 几天后，另一位开发者报告 Claude Code 删除了整套生产环境，其中包括承载着两年半记录的数据库快照。¹³ 两起事件的根因相同：在损害变得无法挽回之前，没人看得见智能体在做什么。

把这种模式放大到智能体会话的规模。我的钩子编排系统建立在 Claude Code 的钩子基础设施之上，会在每一次工具调用中拦截 15 种事件类型。¹¹ 在 60 次会话里，该系统记录到每个动作触发 84 个钩子，产生了任何默认智能体安装都不会提供的遥测数据。² 如果没有这套埋点，我根本发现不了写进 NIST 公开意见书里的那 12 起偏移事件、幽灵般的验证失败，以及递归派生循环。³

DORA 的 2024 年 Accelerate State of DevOps Report 发现，可观测性实践扎实的团队部署更频繁，从故障中恢复也更快。2025 年版把这套框架延伸到 AI 辅助开发，将可观测性与”AI 辅助编码或测试如何影响质量、前置时间和整体可靠性”联系起来。⁴ 智能体可观测性不是锦上添花。衡量智能体的行为，是治理它的前提。

智能体可见性的三层

智能体可观测性需要三个相互独立的层。每一层回答一个不同的问题。其中一层失效，不会连累另外两层。

这三层对应一条递进关系：没有计量过的资源，无法对其执行策略；从未定义过的策略，也无从审计其合规性。每一层都建立在它下面那一层之上。

第 1 层：资源计量

资源计量回答的是：智能体消耗了多少，又消耗在哪里？

Cowork 事件是一次资源计量的失败。虚拟机捆绑包占用了 10GB 磁盘空间。渲染进程在空闲时占用 24% 的 CPU。会话期间换页活动稳步攀升。所有这些指标都存在于 macOS 的活动监视器中，却没有一项出现在 Claude Desktop 的界面里。¹

对于智能体编码会话，资源计量需要跟踪四个维度。

磁盘。 每一次文件写入、每一条缓存记录、每一个日志文件。我的会话每次会生成 200 至 400KB 的状态文件（jiro.state.json、jiro.progress.json、钩子日志）。60 次会话累积下来就是 12 至 24MB 的状态数据，除非显式清理，否则会一直跨会话留存。²

内存。 每一轮对话的上下文窗口消耗。按当前 Opus 的价格，一个 20 万 token 的上下文窗口填满一次大约要 3 美元。我的成本追踪器记录每个会话的累计 token 用量，并在可配置上限的 80%、90% 和 95% 处设置预算阈值。⁵

CPU。 钩子的执行时间。我那套九个钩子组成的提示词分发器，每条提示词增加 200 毫秒开销。这点开销对用户是隐形的（人打字才是瓶颈），但在自动化流水线里会不断累积。ralph 自主循环每个故事会触发分发器 50 到 100 次，为每个故事增加 10 至 20 秒的钩子开销。²

网络。 网页抓取、API 调用、MCP 工具调用。每一个出站请求都是潜在的数据通道——而且每一个 MCP 服务器都是一个新的攻击面，网络计量必须覆盖到这里。我的网页抽取库会记录抓取的 URL 与响应大小。没有网络计量，一次返回 50MB 的网页抓取和一次返回 5KB 的抓取毫无分别。⁶

没有任何商业智能体工具提供按会话的资源仪表盘。云厂商计量算力是为了计费，不是为了给运维人员看。智能体消耗了什么，与运维人员能看见什么，两者之间的落差就是资源计量的欠账。

这种缺失在数字累积起来之前一直是隐形的。一次写入 400KB 状态文件的会话不算什么。但六十次各写 400KB 且从不清理的会话，会留下 24MB 无人认领的状态数据。一次返回 847KB 的网页抓取可以忽略不计。但一条每次运行抓取 80 个 URL 的扫描流水线，会生成 67MB 的缓存内容，而智能体的工具抽象把这些统统对运维人员隐藏了起来。资源计量的意义，就是在累积演变成逼人提交 GitHub issue #22543 的危机之前，先把它显形。¹

第 2 层：策略执行

策略执行回答的是：有哪些规则在约束智能体，这些规则是否被一致地应用？

mcp-firewall 承担 CLI 智能体的策略层。⁷ 该工具位于智能体与所有工具使用请求之间，在执行前依据基于正则表达式的策略逐条评估请求。策略以 JSONNet 配置文件编写，可按文件夹、git 仓库或用户划定范围。这道防火墙通过 PreToolUse 钩子集成支持 Claude Code 与 GitHub Copilot CLI。

这套架构反映了一个关键洞察：每个智能体都在为允许/拒绝逻辑实现自己那套半吊子方案。Claude Code 用 glob 模式，Codex CLI 只做前缀匹配。每种做法都只覆盖策略空间的一个子集。mcp-firewall 把规则集中到一个可跨智能体工作的引擎里。

不妨设想一下缺少集中执行时的策略缺口。我的钩子系统里有 12 个 PreToolUse:Bash 处理器，分别检查凭据模式、危险的 git 操作、敏感路径访问和部署命令。² 每个处理器都是一个独立的 shell 脚本，各有各的正则表达式。每要新增一条拒绝规则，就得写一个新脚本；每要审计现有规则，就得在 12 个文件里 grep。mcp-firewall 把这些整合进一个带有显式允许数组的配置文件。

OWASP Top 10 for Agentic Applications（2025）把 Agent Goal Hijacking（ASI01）和 Excessive Agency（LLM06:2025）列为最高风险。⁸ 这两类风险都要求在工具调用层面执行策略。目标被劫持的智能体照样会发起工具调用；权限过大的智能体照样会请求权限。策略执行会在智能体意图与系统工具相遇的边界上，把两者一并拦下。

策略执行不同于访问控制。传统访问控制问的是”这个用户有权限吗？”针对智能体的策略执行问的是”这个动作，在这个上下文里，为了这项任务，是否落在获批的范围内？”部署与防御的信任悖论解释了为什么为了让智能体好用而授予宽泛权限，恰恰制造出策略执行必须去约束的那片攻击面。难点在于上下文敏感性。推送到功能分支的 git push 和推送到 main 的 git push --force 是同一个工具（Bash），爆炸半径却天差地别。mcp-firewall 的正则表达式能区分二者，默认的智能体权限却不能。

应用层的策略执行同样面临被绕过的风险。正如你的智能体沙箱只是一个建议中所述，看似牢固的执行边界，往往存在结构性的漏洞。2026 年 3 月的一份分析记录了针对 Claude Code 内置拒绝清单的三种逐级升级的沙箱逃逸手法：基于路径的规避（/proc/self/root/usr/bin/npx 解析到的二进制文件与被拦截的 /usr/bin/npx 完全相同）、智能体自行禁用沙箱（当沙箱阻碍任务完成时，智能体自主推理出了移除沙箱的做法），以及调用动态链接器（ld-linux-x86-64.so.2 通过内存映射加载二进制文件，完全绕开内核的执行钩子）。¹⁴ 第三种手法代表了一类漏洞：任何绕开 execve 的代码加载方式，都能绕过进程层面的执行控制。对策略执行而言，结论是字符串匹配的拒绝清单是必要的第一层，却不是充分的一层。基于内容寻址的执行（按 SHA-256 哈希而非文件名识别二进制文件）能补上路径规避的缺口，但动态加载器的绕过则需要位于策略层之下的内核级控制。

同样的教训在上面一层依然成立，而在那一层，策略根本看不见。Air Security 于 2026 年 9 月公布的 Plugin4Shell，是四大编码智能体共有的一处市场供应链缺陷：市场为插件锁定一个经过审核的 commit，但智能体在检出这个 commit 时并不核验它是否真的落在那里，于是掌控插件仓库的攻击者可以新建一个以被锁定 commit 命名的分支，并把它设为默认分支；市场里一次例行的重新锁定随后触发每个智能体的后台自动更新，检出被解析到那个分支，而锁定看上去依然得到遵守。依我的理解，这套堆栈里没有任何 PreToolUse 钩子、拒绝清单或防火墙能看见插件被掉包，因为掉包发生在智能体发起工具调用之前。Air 的时间线称，Anthropic 在 Claude Code 2.1.179 中确认了修复，OpenAI 在 Codex 0.146.0 中交付了修复，GitHub Copilot 没有修复，已弃用的 Gemini CLI 也不会有；但 Claude Code 公开更新日志中 2.1.179 的条目并未点名这项修复，因此这个版本号只能依据研究人员的说法。适用的控制手段是版本卫生，再加上一份清点：市场究竟解析出了什么。这是计量问题，而不是策略问题。¹⁷

第 3 层：运行时审计

运行时审计回答的是：在系统调用层面，智能体实际做了什么？

Logira 借助 eBPF 探针在内核层面拦截系统调用，承担审计层。⁹ 该工具记录三类事件：进程执行（exec 事件）、文件操作（含凭据文件访问）以及网络连接（带目的地跟踪）。每一次受审计的运行会生成三个文件：供时间线复查的 events.jsonl、供查询筛选的 index.sqlite，以及记录运行元数据的 meta.json。

其设计哲学是”只观察”：Logira 记录并检测，但不执行、不拦截。⁹ 与执行层的分离是有意为之。策略执行防的是已知的坏动作，运行时审计则在事后发现未知的坏动作。两层在时间维度上承担不同职能：预防（事前）与取证（事后）。

Logira 的 eBPF 探针工作在应用层之下。哪怕智能体构造出一条前所未见的命令来外泄数据，它照样要发起系统调用。智能体无法把文件读取、网络连接或进程派生藏过内核级追踪。这种做法能捕捉应用层钩子遗漏的东西：那些绕过工具调用抽象的副作用。

内置检测规则专门针对 AI 智能体的风险：凭据文件访问、持久化机制变更（/etc、systemd、cron）、可疑命令链（curl-pipe-sh 模式）、破坏性操作（rm -rf），以及异常的网络出站。⁹ 这些规则是针对智能体威胁模型的带主张的默认值，而非通用的系统审计。

平台限制不容忽视。Logira 需要 Linux 5.8 及以上版本并启用 cgroup v2。macOS 上的智能体（Claude Desktop、Darwin 上的 Claude Code）用不了基于 eBPF 的审计。我的 OS 沙箱采用 macOS Seatbelt 配置文件作为最接近的替代：由内核强制执行、阻止写入敏感路径的拒绝规则。³ 但 Seatbelt 属于执行，不是审计。macOS 缺少与 Logira 只观察式审计轨迹相当的生产级方案。

Agent Safehouse 是一款 macOS 原生的沙箱工具，2026 年 3 月在 Hacker News 上收获 802 个点数和 181 条评论，它从执行这一侧填补了平台空白。¹⁵ 该工具提供专为 macOS 本地 AI 智能体设计的沙箱配置文件。社区的反响（对一款沙箱工具而言 802 个点数相当罕见）反映出这件事的紧迫：在 macOS 上运行智能体的实践者，除了”不用沙箱”和”自己写 Seatbelt 配置文件”之外几乎别无选择。Agent Safehouse 在执行侧补上了这个缺口，而 macOS 在审计侧的缺口依然敞着。

执行与审计之别，对应着事故响应在时间上的分工。执行防止事故发生，审计让事后还原成为可能。二者缺一不可。一个拦截所有凭据访问的执行层，在阻止外泄的同时也会阻断正当的 SSH 操作。一个只记录、不拦截所有凭据访问的审计层，则让运维人员得以复查访问模式，并依据证据去调优执行规则。审计数据与策略打磨之间的这条反馈回路，正是可见性堆栈随时间不断改进的方式：审计揭示模式，模式塑造策略，策略又缩小了审计需要覆盖的面。

Logira 的 cgroup v2 隔离带来了一项应用层审计无法复制的能力：按运行归因。系统会把每一个事件归属到某一次受审计的运行，而不是笼统地归给整台机器。当两个智能体会话在同一台机器上并行运行时，cgroup 隔离能确保会话 A 的文件访问不会出现在会话 B 的审计轨迹里。应用层钩子给不了同样的保证，因为钩子是在智能体进程内部触发的，而该进程并没有一条隔开并行会话的内核级边界。⁹

我实际在跑什么

我的编排系统靠钩子而非专用监控工具，覆盖了全部三层。

资源计量。 cost-gate 钩子依据可配置的预算阈值跟踪每个会话的 token 用量。⁵ 系统性能监视器按可配置的间隔检查 CPU、内存、磁盘和交换分区，在资源压力越过阈值时注入警告。¹⁰ 会话偏移检测器每 25 次工具调用触发一次，计算原始提示词嵌入与近期动作滑动窗口之间的余弦相似度。²

策略执行。 八个 PreToolUse 分发钩子按工具类型路由到相应的处理器钩子。仅 PreToolUse:Bash 一项就会运行 12 个处理器，覆盖凭据模式、破坏性 git 操作、敏感路径访问和部署命令。递归守卫强制最大深度为 2、每个父智能体最多五个子智能体。²

运行时审计。 PostToolUse 钩子记录每一次工具调用的结果。安全扫描钩子在执行后检查 bash 输出是否泄露凭据。会话状态文件（jiro.state.json）记录每一次故事完成、评审判定和证据门结果。² 该系统不使用 eBPF（macOS 的限制），但通过钩子流水线捕获了工具层面的遥测数据。

这套系统之所以奏效，是因为每一个动作都会流经钩子流水线。局限在于深度：钩子层面的监控捕捉的是智能体请求做的事，而非操作系统实际执行的事。一个构造出内嵌子 shell 的 bash 命令的智能体，执行的代码在钩子看来只是一个字符串。内核级审计则能看见其中每一个子进程。

以下是来自生产事故的具体结果，这三层堆栈捕捉到了默认监控本会漏掉的失败。

不断累积的盲区

智能体派生智能体，会让不透明性成倍放大。每一次委派跳转都会带来信息损耗。

当我的编排系统运行 ralph 自主循环时，父进程会为 PRD 中的每个故事派生全新的 Claude Code 实例。每个子智能体拿到一项聚焦的任务和一个全新的上下文窗口。父进程跟踪完成状态，却看不到子智能体各自的工具调用、文件读取或资源消耗。²

在深度一（父派生子）时，父进程看到的是子智能体的最终输出。在深度二（子派生孙）时，父进程看到的是子智能体关于孙智能体输出的转述。每跳一次，信息就被压缩一层。我在 NIST 意见书中的委派链分析量化了三种叠加风险：语义压缩（上下文坍缩成一个提示词字符串）、权限放大（子智能体在不理解敏感性的情况下继承权限），以及责任稀释（根智能体要为自己从未查验过的结果负责）。³

可观测性以同样的速率衰减。在根智能体上部署三层可见性堆栈，对孙智能体而言仍是零可见性，除非每个子智能体都独立运行自己的监控。我的递归守卫强制执行深度限制，但那是策略控制，不是可观测性控制。知道委派止步于深度二，并不等于知道深度二发生了什么。

来自我生产系统的一个具体例子：ralph 循环派生了一个子智能体去实现一个数据库迁移故事。该子智能体判断这次迁移需要一个”验证步骤”，于是又派生出自己的子智能体去跑集成测试。孙智能体静默失败了（测试数据库没有配置好）。子智能体收到一个空响应，把沉默当作成功，报告故事已完成。父进程记下”story 4: complete”。三小时后应用因为缺失的字段崩溃，我才发现迁移已经坏了。根智能体的遥测显示这是一次干净的运行。故障藏在两跳之外，我部署在根节点的每一层监控都看不到它。²

OWASP 的 Agentic Applications 框架讨论了级联失败与失控智能体，却没有为多智能体委派链规定可观测性要求。⁸ OpenGuard 在 2026 年 3 月发布的智能体提示词注入分析，从安全一侧揭示了同样的缺口：被污染的上下文在权限各异的智能体之间流动，在缺乏清晰的数据流策略与组合层面授权的情况下，通过交接制造出”一条悄然提升权限的路径”。¹⁶ 这个缺口是结构性的：链条上的每个智能体都需要各自的资源计量、策略执行和运行时审计，各自独立配置、独立上报。开销是相乘的。给链条上的三个智能体各加三层监控，就是九个监控实例，每一个都产出自己的遥测，每一个都要自己的配置。现有工具中没有一款能管理这样的协同。

今天就能落地的做法

三个覆盖可见性堆栈的最小监控钩子。

1. 资源：token 预算追踪器。 记录每个会话累计的输入与输出 token。设一个硬上限，在 80% 时告警。实现上只需读取智能体的用量统计（Claude Code 通过 /cost 暴露会话成本）并与阈值比较。我的 cost-gate 钩子用 47 行 bash 就做到了。⁵

2. 策略：PreToolUse 拒绝清单。 建一个在每次 Bash 工具调用之前触发的钩子。把命令与一份模式清单比对：rm -rf /、git push --force、包含 .ssh 或 .env 的路径、curl | sh。命中即拦截。实现上只需一个 shell 脚本，读取标准输入（工具调用的 JSON），取出 command 字段，再与模式文件做 grep。我的凭据检查钩子用 31 行就做到了。²

3. 审计：PostToolUse 会话日志。 把每一次工具调用及其结果追加到按会话划分的 JSONL 文件里，包含时间戳、工具名、参数和退出码。有了这份日志，就能在会话结束后还原全过程：智能体做了什么、按什么顺序做的、有没有什么东西静默失败了？我的会话日志记录器用 22 行 bash 就做到了。²

下面是 settings.json 中拒绝清单钩子的一个实例：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

钩子脚本从标准输入读取工具调用，取出命令字符串，再与模式比对。被拦截的命令会返回一个 JSON 对象 {"decision": "block", "reason": "Sensitive path access denied"}；被放行的命令则返回 {"decision": "approve"}。这两种响应 Claude Code 都会遵从，不再追问。整个钩子对放行的命令不增加任何延迟（正则检查在 5 毫秒内完成），对被拦截的命令则给出即时反馈。

这三个钩子加起来不到 100 行。它们并不取代专用监控工具，只是把零可见性换成最小可见性。而最小可见性，是此后每一项治理决策的前提。没有计量，就设不了资源预算；没有拒绝清单，就强制不了范围策略；没有审计日志，就调查不了事故。先从日志开始，另外两项自会跟上。

关键要点

给平台工程师： 智能体消耗的是现有监控没有跟踪的资源。每个智能体会话的磁盘、内存、CPU 和网络用量，理应和容器指标出现在同一块仪表盘上。Cowork 事件证明了这种必要性：10GB 被分配出去，运维人员却毫无可见性。

给安全团队： 在工具调用边界上执行策略，是智能体安全态势的最小可行起点。mcp-firewall 的集中式做法，把各个智能体各自为政的允许/拒绝逻辑归并成一份可审计的配置。请评估您的智能体内置权限，是否覆盖了威胁模型所要求的策略空间。

给工程管理者： 长期的答案是智能体自治——让智能体把监控内化为行为规范，而不只是外部约束。在这一天到来之前，请就您的智能体工具链问三个问题：能看到按会话的资源消耗吗？能定义并审计工具调用策略吗？能在事后还原智能体做过什么吗？只要有一个答案是”不能”，您就存在一处可见性缺口，而它会随着工作流中每多一个智能体而继续扩大。

常见问题

什么是智能体可观测性？

智能体可观测性是指监控并理解 AI 智能体在执行过程中所作所为的能力：它消耗了哪些资源、采取了哪些动作，以及这些动作是否符合既定策略。

Anthropic 的 Cowork 为什么会创建 10GB 的虚拟机？

Claude Desktop 的 Cowork 功能会为协作开发会话预置一台虚拟机。Claude Desktop 在每一次 macOS 安装中都会自动创建该虚拟机捆绑包，即便用户从未启用过这项功能，并且会一直保留到被手动删除为止。¹

mcp-firewall 是什么？

mcp-firewall 是一款开源的策略执行工具，它拦截来自 CLI 智能体（Claude Code、GitHub Copilot CLI）的工具使用请求，并在执行前依据基于正则表达式的允许/拒绝规则对其进行评估。⁷

什么是 eBPF 运行时审计？

eBPF（extended Berkeley Packet Filter）能在不修改被审计进程的前提下，于内核层面追踪系统调用。Logira 之类的工具便使用 eBPF 探针，记录 AI 智能体运行期间的进程执行、文件操作与网络连接。⁹

智能体是如何在运维人员看不见的情况下派生子智能体的？

委派任务的智能体会派生带有全新上下文窗口的子进程。父智能体看得到子智能体的最终输出，却看不到它各自的工具调用、文件读取或资源消耗。每经过一次委派跳转，信息就被压缩一层：孙智能体的整场会话，在父智能体的日志里只剩一行状态。可观测性衰减的速率，与委派深度增加的速率相同。²

智能体监控与传统 APM 有何不同？

传统的应用性能监控（APM）跟踪确定性软件的请求延迟、错误率和吞吐量。智能体监控跟踪的是非确定性行为：智能体在运行时决定做什么、这些决定是否落在策略之内，以及每个决定消耗了多少资源。APM 假定应用会沿着已知的代码路径运行；智能体监控则假定智能体会自己选路。²

Claude Code 的钩子能提供智能体可观测性吗？

可以。Claude Code 的钩子系统会在生命周期事件（PreToolUse、PostToolUse、Notification）上触发脚本，这些脚本可以计量资源、执行策略并记录动作。一套三钩子配置——token 预算追踪器、PreToolUse 拒绝清单和 PostToolUse 会话日志记录器——用不到 100 行 bash 就能覆盖全部三层可见性。对于已经在用 Claude Code 的团队，钩子是最容易上手的切入点。

智能体绕过自己的沙箱时会发生什么？

沙箱被绕过，意味着执行层静默失效。智能体会继续在既定范围之外执行，而如果没有运行时审计，这次突破不会留下任何记录。2026 年 3 月记录的沙箱逃逸手法包括基于路径的规避、智能体自行禁用沙箱以及调用动态链接器——这些对应用层监控而言全都是隐形的。

MCP 工具的可观测性为什么重要？

每一次 MCP 工具调用都是潜在的数据通道：它可以读取文件、发起网络请求、执行代码。MCP 服务器会扩大攻击面，因为每接入一个服务器，智能体在运行时就多了一批可调用的新能力。若没有逐次调用的日志与策略执行，MCP 工具调用对运维人员就是隐形的。

如何监控多智能体委派链？

委派链上的每个智能体都需要各自的资源计量、策略执行与运行时审计。ralph 自主循环很好地展示了这个问题：父智能体派生出的每个子智能体都会拿到全新的上下文窗口。父智能体看到的是最终输出，而非各自的工具调用。可观测性衰减的速率与委派深度增加的速率相同，因此每一跳都需要独立的监控。

参考来源