你让 AI 帮员工写代码、查资料、处理客户问题，它就不再只是聊天窗口，还会读取内容、调用工具，甚至执行操作。麻烦也随之而来：一段藏在网页或邮件里的恶意指令，可能诱导它忽略原有规则。这叫提示注入（prompt injection）。企业既要知道 Agent 做过什么，也要测试防线、发现威胁，并在出事前拦住危险操作。
Uber 开源的 ADR（Agentic AI Detection and Response，Agent 式 AI 检测与响应）想把这些环节接到同一套安全体系里。按照项目方说法，ADR 已用于 Uber 生产环境，配套论文《ADR: An Agentic Detection System for Enterprise Agentic AI Security》也已被 MLSys 2026 接收。不过，目前全部信息都来自 Uber 自身，尚无独立信源交叉验证。
把分散的岗哨接成安防中枢
ADR 列出四项互补能力：Observability、Benchmark、Detection 和 Prevention。可以把它们理解为监控录像、消防演习、警报筛查和门禁拦截。
Observability 是可观测性，即通过日志、调用链和指标还原 Agent 做了什么。ADR Sensor 会收集并统一 Agent 的意图、工具调用和执行轨迹。项目方称，其生产部署覆盖 macOS、Linux、Windows 上的 7 款以上 AI 编程工具，也覆盖内部自动化系统和面向客户的支持 Agent。
这一步很基础，却决定后面的调查能否成立。普通软件日志主要记录程序是否报错；Agent 安全还要追踪它收到了什么提示、给出了什么输出、调用了哪个工具。否则，即便系统做出越权操作，安全人员也可能无法还原过程。
Benchmark 是安全基准评估：用一组可重复的攻击和误用场景，检查防线会在哪些条件下失效。项目方给出的更具体口径是，ADR-Bench 包含 303 个任务和 133 个 MCP servers。MCP server 可以理解为向 Agent 提供外部工具和数据的接口。Uber 还称，该基准覆盖全部 17 种 Agent attack techniques，但没有提供外部验证。
先粗筛，再深查
ADR Detection 采用两级架构。第一层先做“高召回率”筛查，尽量少漏掉可疑会话；第二层再对这些会话进行更深入的 agentic reasoning，也就是让检测 Agent 结合上下文继续推理风险。
这像机场安检：入口设备先快速筛出异常，再由人工或更细致的检查确认。好处是，不必对每一段 Agent 活动都投入同样昂贵的分析。问题在于，Uber 没有公开足够的结果让读者判断这个平衡做得多好。材料没有检测准确率、召回率、误报率、与其他方案的对比，也没有生产事故下降幅度。因此，“高召回率”目前只是项目方对设计目标的描述，不能等同于已经证明效果领先。
为什么现在值得看？
ADR 的看点不只是又做了一个威胁检测器，而是把行为审计、防御测试和在线检测放进同一条企业安全链路。企业可以先用基准场景寻找薄弱点，再让 Sensor 持续记录真实活动，最后由 Detector 筛查风险。项目还提供了复现基准检测与论文图表的工作流。
当前仓库包含 ADR Sensor、ADR-Bench 和 ADR Detector，主体采用 Apache License 2.0；其中引入的 Detection/benchmark/agentdojo/ 第三方代码采用 MIT License。对开发者来说，这意味着观测、基准和检测部分已经可以查看和试验，但四项能力并未全部开放。
局限与未知
- ADR Prevention——在危险操作造成损害前实施阻止的部分——尚未开源，不能把当前仓库描述成完整的“检测加拦截”方案。
- 用于部署前 red teaming（红队测试，即主动模拟攻击）并强化检测的离线 ADR Explorer engine 也未公开。
- 生产部署、MLSys 2026 录用及基准覆盖范围都只有 Uber 单一信源背书；材料也缺少关键检测指标，实际效果仍待独立验证。