Google开放Agent Anomaly Detection私有预览：AI任务完成了，还要查哪些操作？

Google在2026年9月16日公布Agent Anomaly Detection私有预览，面向Gemini Enterprise Agent Platform上的代理，通过执行记录识别异常行为。这项产品为上面的检查提供了自动分析能力，但它与执行前的权限控制承担不同工作。Google开发者公告

本文按9月21日可读资料解释其机制与接入条件，再用一个自拟网站询盘任务说明如何调查和处置，不将示例描述为部署实测。

它怎样从执行记录里找出异常

Agent Anomaly Detection在实时请求路径之外异步处理日志与OpenTelemetry执行轨迹。其分析分层进行：先寻找统计异常，再分析被标记的会话，必要时深入具体工具调用、参数和执行状态。这样调查对象就不只有最后一句回复，还包括任务实际走过的路径。产品概览

这里“异步”很关键：代理可能已经返回结果，分析才继续给出线索。它适合发现和调查过程中的异常，不能被理解成每一个危险动作都先等待它审查。

官方发布举了库存查询的例子：请求每次列出较大数量商品，随后反复翻页、跨偏移量获取目录。工具本身没有报错，操作组合却可能超出了普通浏览。这样的例子说明，单次调用是否合法、连续调用是否符合任务目的，需要分别观察。

对网站团队，把问题从“请求有没有成功”往前追一层，通常就会发现新的验收项。读了一条询盘与导出了所有询盘，都可能支持同一句回复；只有调用对象和数量记录能把它们区分开。

回答质量、操作权限和异常发现各管什么

除了回答质量、权限和异常分析，还要回到业务系统核对结果。四项检查各自回答一个问题。

检查	主要回答的问题	网站询盘助手中的例子
回答质量评测	答案是否正确、完整、对用户有用	是否准确整理了该客户的型号与需求
执行前权限与参数控制	当前用户能否做这个动作	是否可以读取该客户记录，能否修改状态
执行过程异常分析	任务实际执行得是否异常	为找一条记录却遍历全库，或持续重复调用
业务结果核对	实际系统最后发生了什么	是否重复建单，是否把别人的资料改掉

权限适合用明确规则约束。例如只读角色不能调用修改接口，应在工具或后端执行前判断，而不必等待一次异常分析。Google ADK提供工具执行前的回调控制点，可以检查请求参数并选择跳过工具调用；它是实现控制的位置，业务授权规则仍要由应用提供。ADK工具回调说明

异常分析则用于理解一串操作是否值得追查。正常管理员执行获准的批量维护，也可能表现为大量调用，所以“数量多”并不能直接等于攻击。对最终回答的测试，可结合AI助手评测中怎样检查测试题质量进行，两者互相补充。

用一条询盘任务，分清哪一步出了问题

假设员工的要求是：“查看客户A最近一次关于设备X的询盘，整理需要补问的参数。”一个合理实现可能是按获准客户标识和设备条件查询，再读取匹配记录，最后生成待补充的问题。

以下是同一任务的三种结果。它们是自拟教学场景，其中的查询与写入动作是业务示意，不代表 Google 提供这些业务接口。

看到的调用	对任务的判断	应检查或修改的位置
按客户A和设备X查找，读取一条匹配询盘	路径符合查询目的，仍需核对记录归属	查询工具的对象权限
先分页拉取全体客户，再寻找客户A	查询范围过大，可能是工具设计缺陷	增加受权限约束的精准查询，减少全量接口暴露
查到记录后将状态改成“已处理”	原任务未要求修改状态	查询与写入工具分开，写入前验证任务授权

大量调用还可能是已获准的批量维护，调查时要把原任务附在调用旁边。如果工具只有“列出全部”一个入口，单纯在提示词里禁止大量读取，会让代理无从完成查询。应先修查询能力，再复测原任务。

一份完整的执行记录应该怎样看

把一次会话整理成下面这样的时间顺序，最后一句“已完成”就有了可核对的上下文。这是一份虚构的失败记录，不是预览产品截图，也不是实际告警输出。

顺序	调用或事件	已知结果	验收判断
1	员工请求整理客户A设备X的待补参数	仅授权读取与整理	没有授权改状态或建任务
2	查询匹配询盘	返回一条记录Q17	核对Q17确属客户A
3	读取Q17	获得参数，状态原为“待补充”	足以完成原要求
4	写入Q17状态“已处理”	业务记录确认写入成功	超出本次任务，需核对恢复
5	创建待联系任务	请求超时，结果暂不明	先查业务系统是否已建成
6	再次创建待联系任务	查到T31与T32两条任务	重复建单，不能把超时当作未写入

记录时把Q17、T31这类示例编号换成真实对象ID，并补会话ID、发起者、时间、工具参数范围和业务结果。原始日志与业务记录通过这些标识互相找到，才有办法核对；只保存一段告警描述不够。

这里有两个不同的修复：状态误改需要补写入授权；超时后的重复创建需要核对已有结果，并设计同一业务动作的去重机制。异常检测可以帮助发现线索，具体修复仍落在工具和业务系统里。

告警出现后，先还原动作，再处理已经发生的结果

Google发布说明介绍，应用可以通过API获取会话异常结果，再由ADK回调或插件按阈值限制后续调用。对于上面的案例，停止会话后，Q17已经被改过，T31和T32也仍然存在。

这份处置表可以接在执行记录后面，供开发和业务人员共同验收：

处置项	本例应做什么	完成证据
停止继续执行	暂停该会话后续写入	停止时间之后没有新的写入记录
核对错误状态	确认Q17是否仍应为“待补充”，按业务授权更正	更正后的状态及操作记录
核对重复任务	检查T31、T32是否已被处理，再按业务规则处理重复项	留存有效任务及处理依据
修正工具	查询角色不能调用未授权写入；重试前核对结果	对应权限与去重检查通过
复测原任务	在隔离数据中再次要求整理参数	得到待补问题，没有多余写入

不要在不核对业务进展的情况下直接删除重复项：其中一条可能已经有人跟进。先确认状态，再执行获得授权的修正，才能避免修复动作又覆盖有效工作。

对于没有写入、只是调用数量异常的会话，处置会轻一些：先确认是否为获准批量任务；若是正常工作，调整监测区分方式；若是查询工具过宽，缩小工具能读取的数据范围。

当前覆盖哪些风险，不覆盖什么保证

官方把默认检测与OWASP智能体安全风险中的工具误用、身份与权限滥用、级联失败和偏离职责等类别关联，也关注资源消耗异常。这些类别用于组织调查，不表示预览产品已经解决所有智能体安全问题。OWASP智能体风险项目

例如，“连续失败”可以帮助发现无止境重试，但业务团队仍需决定何时停止、是否已经产生重复操作。“工具误用”指出需要检查调用方式，具体用户究竟能否操作某条订单，仍要由身份与权限系统回答。

自定义业务逻辑检测在发布公告中属于后续计划，不能提前写成已经普遍可配置的功能。如果你的要求是“某类折扣必须主管批准”，目前就应在应用中明确实施这条业务规则，不把尚未开放的检测当成交付依赖。

同样，没有出现异常结果不等于所有操作都正确。要结合日志是否完整、任务有没有被实际分析、业务结果是否经过核对理解，尤其不能只用“告警为零”宣布自动化已经安全上线。

申请预览前，先核对能否被系统发现

当前文档要求代理部署在Agent Runtime，使用ADK for Python 1.2或以上版本，并推荐2.1.0或以上。还包括US多区域的日志与观测桶、遥测与内容记录配置、读取权限和实际数据流等前提。符合条件被识别为可监测代理，与明确开启分析是两个状态；发现代理并不等于已经开始分析。当前接入条件

可以先让开发人员回答三个问题：代理运行在什么环境，日志和执行轨迹存在哪里，是否已经有一条完整任务产生了数据。普通WordPress聊天插件仅仅调用Gemini模型，不足以证明满足这些条件。

如果环境不符合，先完善自己的基本执行记录也有价值。至少能把同一次任务的用户请求、工具调用和业务结果关联起来，后续才有依据判断是否值得接入更完整的分析产品。不要为了试用一个预览功能，把已经稳定运行的全部业务匆忙迁移。

试用时，怎样判断告警对团队有帮助

在隔离环境里先写好预期，再看实际记录。可以从这四项开始：

测试任务	预期允许行为	实际需要填写
整理一条询盘	读取获准记录，不写入	读取对象、是否产生写入
获准批量维护	只处理授权范围	调用量、告警理由、是否误限正常任务
写入请求超时	核对已有结果，再决定重试	业务对象数、重复项、停止条件
未获准修改状态	执行前拒绝写入	拒绝记录、业务状态是否未变

验收同时看两个结果：系统有没有执行正确，异常解释能不能让人找到相应对象。若告警给出解释却没有可关联的业务记录，应先补日志；若权限检查就能解决问题，应先修权限。产品试用是否值得继续，由这些实际结果决定。