一个新的研究信号：Agent 评测开始引入“时间”
8 月 2 日发布的一项最新预印本研究提出了一个很有现实感的问题：如果企业应用中的数据持续变化，我们如何判断 Agent 在 19:05 看到的内容、采取的动作，是否符合 19:05 的真实业务状态？
研究者构建了一个可以随时间演化并在指定时点回放的企业场景，用于评估不同角色的 Agent。其核心不是再增加一批固定问答，而是同时恢复某一时刻的数据状态、人物关系、可见范围和事件历史，再观察 Agent 的结果与行为。
这项研究目前仍是预印本，不能被视为成熟行业标准，也不能据此断言某类 Agent 已经安全可用。但它指出了一个值得企业立即重视的评测缺口：传统测试集往往冻结了问题和答案，真实企业却始终处于变化中。
这与近期产品和标准实践形成了呼应。Google Cloud 的 Agent 评测文档已经把最终响应与工具调用轨迹分开评估；Microsoft 今年开始为 Agent 提供独立身份、权限可见性以及登录和审计记录；NIST 的零信任实践则强调，访问决策应依据请求发生时的身份、设备、资源和环境状态动态判断。
这些信号共同指向一个变化：企业 Agent 的验收对象，正在从“一次输出”扩展为“特定现场中的完整行为”。
为什么普通回归测试会漏掉真实风险
假设一个销售 Agent 被要求：“整理本周有续约风险的客户，并把建议发给相关负责人。”
在测试环境中，它可能准确检索 CRM、识别风险、生成建议并发送消息，因此获得高分。但在生产环境里，至少有四种时间变化会改变正确答案：
这里没有一个问题能靠“模型回答得更像专家”解决。错误来自业务世界在 Agent 感知、推理和执行期间发生了变化。
如果企业只保存最终结果，很难事后判断：Agent 当时读到了什么版本的数据？以谁的身份获得了哪些权限？调用工具时适用哪版规则？动作发生前是否重新确认过关键状态？它究竟是推理错误，还是依据了一个已经过期但看似合理的现场？
因此，生产级 Agent 至少要面对三种不同的正确性：
- 客户刚刚签署补充协议，风险状态已经更新，但检索索引尚未同步。
- 某位员工当天转岗，仍在群组缓存中，却不应继续看到该客户信息。
- 负责人已在几分钟前撤销发送指令，Agent 的长任务仍按旧计划执行。
- 公司刚调整折扣规则，Agent 引用了旧规则生成续约方案。
- 事实正确性：使用的是当时有效的数据，而不是晚到、错序或过期的副本。
- 权限正确性：每次访问和动作都符合发生时的授权状态，而不是沿用任务启动时的权限。
- 流程正确性：在审批、撤回、转交和异常发生后，Agent 能停止、重算或升级，而不是机械完成原计划。
日志很多，不等于可以还原现场
不少企业已经保存模型输入输出、API 日志和业务操作记录，却仍无法复盘一次 Agent 事故。原因是这些记录通常分散在不同系统，时间基准不一致，也没有被连接成同一个业务事件。
例如，CRM 记录显示字段何时修改，身份系统显示权限何时撤销，Agent 平台保存工具调用，消息系统记录发送结果。但如果无法回答“在 Agent 发起这次调用的准确时点，它可见的数据快照和有效权限分别是什么”，这些日志只能证明若干动作发生过，不能证明动作为什么在当时被允许。
真正可回放的业务现场，不等于把所有数据永久复制一份。它需要围绕关键任务保存足够的上下文指纹：
这套记录的目标不是“收集得越多越好”，而是让企业能够在不暴露无关敏感数据的前提下，回答三个问题：当时发生了什么、为什么这样决定、同一现场能否被重新验证。
- 任务发起时间、执行阶段和关键事件顺序；
- Agent、委托用户及实际操作主体的身份；
- 每次工具调用使用的权限、策略版本和授权结果；
- 关键业务对象、知识来源和规则的版本或快照标识；
- Agent 的计划、调用轨迹、返回结果与最终动作；
- 审批、撤回、超时、人工接管和外部状态变化。
把固定测试集升级为“时间情景回放”
企业不必先建设昂贵的数字孪生平台。可以选择一条状态变化频繁、错误后果明确的流程，从最小可行的时间情景开始。
第一步，找出会让正确答案改变的事件。常见事件包括权限授予与撤销、订单状态变化、合同版本更新、审批通过与反悔、库存锁定与释放、客户归属调整。不要从系统字段出发，而要从“哪种变化会使原动作不再成立”倒推。
第二步，为一个真实任务构造多个时间切片。例如在权限撤销前、撤销后但缓存未刷新、Agent 计划完成后但动作提交前，分别执行同一请求。企业要观察的不是回答措辞是否一致，而是 Agent 是否在正确时点拒绝、重查、停止或请求人工确认。
第三步，同时评估结果和轨迹。最终没有发错邮件，并不能证明系统可靠——它可能只是偶然失败；最终内容正确，也不能掩盖中途访问了无权读取的数据。工具选择、调用顺序、权限检查和关键动作前的再次确认，都应进入验收范围。
第四步，把生产事件转成回归情景。权限延迟、索引不同步、撤回未生效和规则切换等问题一旦出现，就应成为后续版本必须通过的时间测试，而不是仅写进事故报告。
第五步，为不可重放的流程设置替代证据。支付、生产控制等动作不能在真实系统中任意重演，可以使用脱敏快照、仿真工具和干运行模式验证决策，并把外部动作替换为可检查的拟执行记录。
企业真正需要的是“可证明的当时正确”
Agent 越能跨系统自主完成任务，企业越不能把一次成功演示当作上线依据。传统软件测试倾向于问：给定输入，输出是否符合预期。企业 Agent 还必须回答：给定某一时刻的身份、数据、规则和未完成任务状态，它是否只看到了应该看到的内容，并采取了当时允许采取的动作。
这也是企业选择平台和实施伙伴时值得新增的一组问题：系统能否标识 Agent 的独立身份？能否追踪委托人与实际执行者？权限变更对运行中任务何时生效？关键数据和策略是否有可引用版本？是否能回放工具轨迹？外部动作前能否重新验证现场？
一个务实的起点，是选取一条包含权限变化和审批撤回的高价值流程，制作 10 至 20 个时间情景，在 Agent 每次模型、提示词、工具或权限策略变更后重复验证。相比继续扩充静态问答题库，这更接近企业真正需要购买的能力：不是 Agent 曾经做对，而是企业能够证明，它在业务不断变化时仍知道何时执行、何时重查、何时停下。
