答案正确，路径却错了

数字 420 可能因为两个相互矛盾的原因而显得正确。在这个示例中，两个代理返回同一联系人受众，都说有 420 名客户。一个使用获批的商店受众，并检查了同意状态。另一个从不同工作区复制了过时的导出数据，碰巧得到了同样的数量。

只评最终结果，两者都会得满分。这是错误的评分。

关于代理环境验证的讨论区分最终输出与得到它的路径。在其中的电子表格示例中，正确数字只是任务的一部分；公式、来源引用和要求的格式也重要。对集成来说，区别更尖锐：结果的来源决定它是否从一开始就被允许。

最终数值不能证明来历

假设代理提出从商店客户对象到营销系统的字段映射。它把 email 对应到邮箱，firstName 对应到名字，把同意字段对应到目标系统的营销状态。预览看上去合理。

它根据什么做出选择？是当前模式、旧样本，还是另一账户的文档？它查看了同意字段的含义，还是只凭标签猜测？它把空值当作“未订阅”，还是“不知道”？

不同答案会改变同一最终映射的可信度。映射是输出，证据路径是采用它的理由。

路径必须说明做决定时每个来源的版本。后来修正的模式截图，无法解释昨天提出的映射。把相关模式或文档版本与决策一起保存，并保留版本与获批规则之间的联系。目的是重建决策过程，不是保存代理看过的每一页。

因此，工具调用轨迹可能比自信的解释更重要。轨迹记录实际调用和使用的标识符。文字摘要有用，却不能证明某个来源曾被查阅。集成中的证据应指向源对象、目标系统的契约，以及移动数据的具体规则。

业务工具集成指南从字段归属入手，因为两边的名字很少能决定谁有权负责。过程检查要问：代理拟定写入前，真的查看了归属决定吗？

把允许的路径写进任务

好的测试案例有两个部分。先写明目标系统应包含什么，再写明到达该状态时允许使用的证据和动作。

对示例受众，预期结果也许是 420 名联系人；获批路径还可能要求限定商店范围的查询、当前的同意映射，以及列明排除记录的预览。它可以禁止跨工作区读取和直接发送营销活动。

这样验证器就有了具体规则。它可以机械地拒绝跨工作区标识符，检查启用前是否调用过预览，确认输出中声称的数据源与轨迹中的来源一致。这些是规则，不是模型的意见。

剩下的问题可能需要判断：选中的同意字段，真的意味着这个营销活动的许可吗？此时应由人或范围很窄的决策模型查看字段定义和用途。规则与判断各司其职。

测试也能给出有用的失败说明。“答案错误”只让团队猜测。“数量正确，但受众来自跨工作区读取”指出数据边界失败。“映射正确，但没有同意定义”指出证据缺失。验证器应报告失败条件及对应轨迹，让修复改变路径，而不只是润色最终措辞。

执行轨迹能证明什么？

1. 获批来源及必要检查

   接受路径

   结果具有任务要求的证据。

2. 跨工作区来源

   拒绝路径

   数量相同不能授权那次读取。

3. 缺少必要证据

   暂缓并审核

   仅凭输出无法证明它如何得出。

别把轨迹变成仪式

合理的反对意见是：“代理可以调用要求的工具，却完全忽略结果。”没错。调用列表只证明调用发生过，不能证明返回的证据影响了决策。

一种测试方法是改变证据。提供两条其他方面相似、同意状态不同的记录。如果代理对两者给出相同的映射和解释，看似查阅来源可能只是表演。另一种方法是移除必要来源，要求代理停止。从记忆填补空白的代理没有遵守路径。

代价是测试材料需要更多工作。必须有人定义获准来源、预期差异和禁止的捷径。笼统地问“答案看起来好吗”更容易制作，教会团队的却更少。

反向 ETL把映射变为重复的数据移动。映射获批后，普通代码可将其应用到每一行，无需代理逐行重新查看证据。路径审核应放在创建或修改规则的决策处，以及契约变化使规则受到质疑时。

通过错误账户得到正确答案，并非差一点成功，而是完成了另一项任务。