Google在2026年将Agent Anomaly Detection推入Gemini Enterprise Agent Platform的Private Preview，提供面向自主代理的运行时监督与审计，通过多层检测分析推理轨迹、工具调用与OpenTelemetry traces以识别权限滥用、资源耗尽等异常。该功能可将发现结果接入Security Command Center和自动化响应流程，但目前仅在满足特定遥测与区域前提的环境中可用，效果依赖于数据完整性与企业治理策略。
Google于2026年9月16日宣布，Agent Anomaly Detection已在Gemini Enterprise Agent Platform进入Private Preview。它并不是又一个只检查最终答案的模型评测工具，而是一层面向自主代理的运行时监督与审计机制：系统读取代理在一次会话中的推理轨迹、工具调用、执行流程、日志和OpenTelemetry traces，判断其是否偏离预期边界。
这一变化回应了企业部署AI代理时越来越明显的风险。代理可能成功完成任务，却在过程中调用了不应访问的工具；也可能没有触发传统意义上的错误，但通过多次看似合理的操作，逐步扩大权限、抓取过量数据或消耗过多资源。对这类行为而言，最终输出正常并不等于执行过程安全。
从全量扫描到单次调用的三层检测
根据Google Developers Blog的公告，Agent Anomaly Detection采用异步、分层的分析流程。第一层使用轻量统计和机器学习检测器扫描全部流量，寻找异常的调用量、重复行为和遥测趋势，并筛选出需要进一步分析的会话。
第二层使用基于大语言模型的推理分析被标记的会话。它不只是判断某个调用是否符合预设格式，还会结合上下文、代理意图和执行路径，分析行为是否构成可疑的工具使用、权限滥用或策略违规。第三层则深入到具体工具调用，重建执行状态、参数变化和调用历史，以便说明异常究竟发生在哪里。
Google在公告中给出的例子是一个带有list_inventory工具的库存代理。用户要求代理每次列出100件商品，代理随后不断跳过不同偏移量批量读取整个库存。每一次调用本身都没有报错，也没有明显超出工具能力，但连续的批量调用构成了系统性抓取行为。
在这个演示中，系统将其归类为“资源耗尽”，严重程度为Critical，给出95%的概率，并建议对该工具实施限速或阻断、增加授权检查，以及针对大偏移量分页行为发出警报。这个概率和严重程度属于官方产品演示结果，不应理解为对所有代理部署环境都适用的普遍检测保证。
结果可以进入安全响应流程
检测结果不会停留在一个单独的观测面板中。Google表示，异常发现会进入Security Command Center，供安全团队集中分流和跟踪。官方Agent Anomaly Detection文档还列出了工具误用、身份与权限滥用、代理级联故障、失控代理和资源耗尽等风险类别，并将其中一部分映射到OWASP Agentic Top 10的相关分类。
系统也提供API，让开发者在特定会话中读取异常结果。ADK回调或插件可以根据发现的严重程度和概率，在达到预设阈值后阻止后续工具调用，或暂停代理的下一轮执行。换句话说，Agent Anomaly Detection虽然在分析层面异步运行，但检测结果可以被接入后续的运行时控制流程。
这种设计把“发现异常”和“采取行动”分成两个阶段。它并未承诺每一次高风险行为都能在发生前被拦截，也不等同于一个已经全面部署的自动关停开关。企业仍需要自行决定哪些结果触发人工审批、哪些结果可以直接暂停工具，以及如何处理误报和漏报。
私有预览有明确前提，尚未普遍可用
目前该功能面向部署在Gemini Enterprise Agent Platform Agent Runtime上的团队，并要求使用ADK 1.2或更高版本；Google文档建议使用ADK 2.1或更高版本。官方文档同时列出多项限制：日志与观测数据桶目前需要位于美国多区域，并且处于同一美国区域；代理必须通过ADK启用OpenTelemetry日志和追踪，遥测还需要捕获提示输入和响应输出内容。
此外，代理需要有实际的遥测数据，相关服务账号也必须拥有读取日志和观测数据桶的权限。符合条件的代理会先被识别为“monitored agents”，但只有明确启用后才会执行主动异常分析。Agent Anomaly Detection目前仍是Private Preview，并非面向所有Gemini Enterprise Agent Platform用户开放的正式版本。
这些前提揭示了一个容易被忽视的事实：行为审计的效果取决于企业是否记录了足够完整的运行上下文。如果工具参数、用户身份、提示输入或响应输出未被捕获，系统能够分析的内容就会受到限制；而更完整的遥测又会带来数据治理、隐私保护和存储成本问题。
代理安全从“结果评测”转向“行为审计”
Gemini Enterprise Agent Platform早期将Agent Evaluation、Agent Observability和治理能力放在同一套平台框架内。Google Cloud在平台介绍中将其定位为用于构建、扩展、治理和优化企业代理的基础设施。此次新增的异常检测，进一步把关注点从“代理是否完成任务”推进到“代理是如何完成任务的”。
这一区别对于长流程和工具密集型代理尤其重要。IBM Research近期的一项研究指出，代理在同一任务上重复执行时，平均成功率可能掩盖明显的不稳定性；其在AIFlux此前报道的一致性分析研究中，研究人员建议同时观察平均成功率和多次执行全部成功的比例。前者衡量能力，后者更接近企业对可依赖性的要求。
异常检测处理的是另一个维度：即使代理最终完成了任务，工具链和执行轨迹仍可能显示出不正常的行为。类似地，AIFlux此前关于AI Agent审计与保险基础设施的报道也显示，企业正在尝试把代理的实际行为纳入审计、认证和责任管理体系。
仍待回答的问题
Google目前披露的是产品架构、示例结果和接入条件，尚未公布在不同代理框架、工具类型和业务场景下的独立误报率、漏报率或检测延迟。官方示例中的95%概率也只是单个演示场景的产品输出，不代表真实生产流量中的统计准确率。
另一个问题是，异常发现如何转化为稳定的治理规则。暂停一次工具调用可能阻止风险，但也可能中断合法的批量任务；如果企业把过多决策交给基于模型的判断，又会引入新的可解释性和责任边界。对于涉及支付、客户数据、代码仓库或外部网络的代理，最小权限、人工审批、凭证隔离和可回滚能力仍不能由观测工具单独替代。
Agent Anomaly Detection的推出表明，企业代理的安全边界正在从模型本身和最终答案，扩展到持续的行为记录、工具调用控制和跨会话风险分析。它能否成为可靠的生产级防线，还需要更多公开的部署数据和第三方评估来证明；但对正在把代理接入真实业务系统的企业而言，“它有没有完成任务”已经不再是唯一需要回答的问题。
来源： Google Developers Blog：Agent Anomaly Detection进入Private Preview，Google Cloud文档：Agent Anomaly Detection概览。