大多数团队都会以相同的顺序发现同一个令人不安的事实。首先他们意识到 AI 智能体已经在自己的环境中四处运行，调用模型、打开 MCP 服务器、伸进数据库和对象存储。接着他们试图清点这些智能体，却发现根本没有一份清单。独立的行业研究（CSA/Token，n=418）为这一缺口给出了量化数据：大约 82% 的组织运行着自己并不知道的智能体，而仅有约 21% 维护着实时清单。在治理这一切之前，您必须先看见它。问题在于，如何在不让情况变得更糟的前提下获得这种可见性。
有两个诚实的答案，它们分处风险谱系的两端。
查看智能体的两种方式
第一种是内联代理。您将智能体的流量路由经过一个由您掌控的组件，由于每个请求和响应都会经过它，您便可以实时查看、整形和拦截。这是一种合理而强大的设计。如今大量的出口过滤、密钥代发和请求级策略正是这样实施的。
第二种是被动发现。您不站在数据流之中，而是从旁观察它：智能体本就发出的 OpenTelemetry、它所触及系统的原生审计轨迹（PostgreSQL pgAudit、AWS CloudTrail 等云审计日志、Kubernetes 审计），以及通过 eBPF 获取的内核级信号作为真实基线（ground-truth）的兜底。您从不终结连接。您观察已经发生的事情，并重建出谁触及了什么。
真正重要的差别不在于在最佳情况下各自能看见多少，而在于当可见性层自身发生故障时会怎样。
影响半径才是真正的衡量轴
内联代理在结构上就位于数据路径之中。这换来了实时控制，代价却是与生产共享了一种失败模式。如果代理变慢，您的智能体也会变慢。如果它崩溃，安全的默认行为通常是失败即关闭（fail closed），意味着您的智能体停摆；或者失败即放开（fail open），意味着您的控制在最糟糕的时刻悄然消失。无论哪种方式，可见性组件如今都与生产共享了同一个影响半径。它还为每一次调用增加了一跳延迟，并在关键路径上增加了一个需要有人去运维、扩容和打补丁的部署面。
被动发现则恰恰相反。采集器是带外且读优先的：它读取遥测数据、审计轨迹和内核事件；它不转发也不改写智能体的流量。如果它降级或宕机，请求路径中的任何环节都不会改变。在它恢复之前，您失去的是最新的可见性，而不是吞吐量，也不是可用性。这正是读优先、低不对称风险在实践中的含义：那个唯一职责就是观察的组件，对生产不构成任何上行风险。
| 内联代理 | 被动发现 | |
|---|---|---|
| 位置 | 位于数据路径之中 | 带外，处于其旁侧 |
| 实时拦截 | 原生支持 | 需要在访问点上实施 |
| 增加的延迟 | 有，每次调用 | 无 |
| 若发生故障 | 智能体停滞或控制消失 | 可见性变陈旧；智能体不受影响 |
| 静默路径覆盖率 | 高（它终结数据流） | 取决于所发出的信号 + eBPF 兜底 |
这正是为什么产品立场是不强制代理，而非「代理毫无用处」。确实存在内联组件是正确选择的路径，它们也能彼此组合。但发现这一环节，绝不应被允许搞垮它正在清点的对象，因此把它硬塞到关键路径上是个错误的安排。
诚实陈述这一权衡
被动发现确实有一个真实的弱点，假装它不存在就会沦为那种让设计被悄悄不信任的稻草人论证。终结数据流的代理能看到其中的每一个字节。而被动采集器只能看到智能体、其运行时或资源所选择发出的内容。在一条完全非协作的路径上，即很少记录日志、也不发出有用遥测数据的路径，应用层的发现就会变得稀薄。您可以推断出某件事发生了，但归因会变得更困难。
有两点让这种状况保持诚实，而非致命。
第一点是 eBPF 内核兜底。应用日志可能不完整、被延迟，或者在对抗场景下被刻意抑制。但内核无法被礼貌地请求去遗忘一次系统调用。一个打开通往数据库套接字或写入文件的智能体，无论其日志选择记录什么，都会在系统调用边界上留下痕迹。这使得 eBPF 成为反规避的真实基线：当上层信号互相矛盾或陷入沉默时，内核视图就是相互印证的那一层。这也是为什么诸如 readOnlyHint 和 destructiveHint 这样的 MCP 工具注解尽管作为提示有用，却依据 MCP 规范被视为不可信。一个声称只读、却被观测到正在写入的工具，正是值得浮现出来的那种不一致；而您只有把这个声称与实际发生的事情相互印证，才能捕获到它。
第二点是诚实的置信度等级。并非每一次观测都应享有同等的权重，因此访问关系图不会假装如此。一条由内核信号和相匹配的审计条目支撑的边会被标记为已归因；一条从部分遥测数据推断出的边会被标记为近似。产品绝不会把猜测洗白成事实。审阅者应当能够一眼看出每一条记录该信任到何种程度。
从观察到真正要紧的差异
发现只是输入。输出则是已许可（PERMITTED，即策略所允许的）与已观测（OBSERVED，即采集器实际看到的）之间的比较。这一差异就是最小权限漂移，其中最典型的情形是：一次被观测到的写入，策略从未授予，也无人审阅过。
来自访问数据流的几行记录让它变得具体。读取属于常规操作；被标记的写入才是关键所在：
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged attributed
support-rag READ internal-wiki-mcp allowed approximate一个导出作业读取生产数据库，并不值得大惊小怪。但当策略一向只授予读取权限时，同一个作业却写入它，这正是绝不应未经审阅便放行的那种边。由于这次写入在内核边界上得到了印证，它被标记为 attributed，而非一种含糊其辞的折中标注。
看见漂移只是一半的工作；闭合它才是另一半。实施应当落在访问点上，以策略即代码（policy-as-code）的形式表达，这样规则可被审阅，违规也会被处置，而非仅仅被记录：
policy "data-export-readonly" {
agent = "data-export-job"
resource = "prod-postgres"
allow = ["read"]
deny = ["write"]
on_violation = "block + alert"
}被动发现找出未经许可的写入；策略则把智能体重新锁定回最小权限，并拦截下一次违规。可见性与控制始终是各自独立的关注点，这恰恰是发现层得以承担读优先角色的原因。
要点总结
对 AI 智能体的可见性，首先是一个风险决策，其次才是一个功能决策。内联代理以与生产共享影响半径为代价，换来了实时控制。被动发现在静默路径上让出了一些触达能力，以此换取永远不会搞垮生产的保证，随后又用 eBPF 真实基线兜底和对实际所见保持诚实的置信度等级，闭合了其中的大部分触达缺口。对于一份清单而言，对于那个唯一职责就是观察的层而言，这种不对称性才是正确的默认选择。
如果您想全面了解采集器、访问关系图与审计账本是如何协同运作的，架构总览将从头到尾完整地讲解这一切。