代理可观察性:用结果合同捕获虚假的成功

经理可观察性应回答一个比"运行结束了吗?"更困难的问题: 是否存在预期结果,属于这个运行,并通过其接受性检查? 实际默认是在执行之前定义该结果,观察它在经理自己的完成消息之外,并记录一个紧的结果收据. 终端事件可以引发验证;它不能取代验证. 这种区别在不需要第二个模型重新阅读整个转录的情况下取得了错误的成功. 它也避免了相反的错误:对待合法的批准等待是失败的. 下面描述的收据记录了一个不透明的文物标识符,新鲜度,适当时进行内容消化,以及确定验证结果. 缺少证据仍然是 unverified 或特定的失败状态,而不是被圆满归结为健康. 终端事件是执行的证据,而不是交付 痕迹是理解工作的正确地点. 它们并不是自动证明所需的外部状态现在存在的证据. 目前的对GenAI代理范围的OpenTelemetry语义公约描述了 invoke agent , plan 和 execute tool 等操作,加上代理,提供商,模型,时间和错误属性. 这份文件明确标记为发展. 这些信号可以表明一个操作发生了,并且是否报告了错误. 他们不能知道您的特定账单存储了,您的撤销请求包含了所要求的变更,或者您的报告与批准的方案匹配. 接受的规则属于申请. 采用开放AI代理 SDK追踪参考来制造相同的边界混凝土. 它的默认追踪可以包括模型代,功能调用,护卫,交付和定制范围. 这是丰富的处决证据. SDK还警告说,生成和功能跨度可能包含敏感的输入和输出,并允许操作员禁用该捕获. 因此,结果收据可以变得更加狭窄,而且更有决定性:保留需要判断可交付的证据,而不是每一个提示和工具有效载荷的第二份副本. 一个良好的运营模式使用了以下两种方式: 痕迹说明了路径,重试,工具和故障位置; 结果收件证明预期结果或命名缺失证据; 一个等待信号记录已知依赖性或批准性,而不是假装任务完成; 一个进步信号显示在工作仍在活跃期间有所有用的运动. 混杂这些信号会产生坏的警报. 活动不是有用的进步. 清洁的终端事件不是一个验证的结果. 一个宣布的等待不是一个停滞. 在运行前写出结果合同 结果合同是足够小的,可以在任务创建时进行审查,而且足够严格,可以在不问代理人它意味着什么的情况下进行评估. 首先是最便宜的确定性检查,与实际结果相匹配. 领域 目的 举个例子 artifact id 预期结果的名称,而不揭露秘密或绝对的路径 monthly report run started at 确定新鲜度的边界 2026 07 25T14:00:00Z observed at 显示证据收集时间 2026 07 25T14:08:12Z modified at 拒绝了之前运行遗留的文物 2026 07 25T14:07:55Z expected sha256 当字节身份重要时, 准字节 一个64个字符的消化 validator 认可检查的名称 report schema v3 validator exit code 记录决定性的判决 0 evidence source 据说观察来自哪里? local file stat 不需要每一个工作都需要每一个领域. 数据库迁移可能需要一个方案查询而不是文件消化. 一个部署的页面可能需要HTTP状态,正规内容和浏览器声明. 在授权事件发生之前,人类批准任务应保持为 waiting . 合同应该代表结果,而不是强迫每一个工作负载成为一个文件型模型. 默认分类命令是重要的. 首先检查没有证据,然后检查身份,新鲜性,消化和验证结果. 这会产生可操作的状态: 1. missing 没有被观察到的文物; 2. wrong artifact 观察属于不同的目标; 3. stale 该文物在运行之前; 4. 要求并不同的是 hash mismatch 的确切字节; 5. validator failed 文物存在,但不符合接受标准; 6. unverified 所需的检查未进行,或者没有证据; 7. verified 所有要求都通过了. 保持收据的隐私最小. 不透明的标识符比客户名字或文件系统路径更安全. 一个消化可以证明字节身份,但一个简单的哈希不能隐藏一个可预测的秘密. 如果值敏感且值低,则使用键式HMAC,或者避免完全保留值. 据了解,在原材料附近收集证据,以便原材料不需要离开主机. 运行六次错误成功测试 我测试了这个规则,对抗了合成的六圈固定器件. 每个运行都具有相同的运行时间终端状态: completed . 两项观测是新鲜且有效的. 四个代表了不同的虚假成功模式:没有文物,比运行更老的文物,内容不匹配和验证器失败. 这种分类器是故意无聊的. 它以固定顺序评估事实: 运行包含的装置产生: 可伪造的索赔很窄:对于此供应的装置,一个终端状态规则接受了六次运行,而结果合同验证了两次,拒绝了有具体证据的四次运行. 这不是测量生产故障率. 这是一个边界测试,表明相同的终端状态可以隐藏显著不同的结果. 有用的指标不是完成的运行百分比. 这是 verified outcomes / runs expected to deliver an outcome ,报告在检查覆盖次数旁边. 如果只有一半的任务类型有确定性验证器, 不要默默地将未使用仪器的半个归类为健康. 在完成边界添加验证 当运行时间暴露完成限度时,支票本身仍然是独立的, 在这个边界,收集证据,运行验证器,继续收到, 克劳德法典提供了一个具体的实施点. 现在的子参考表示 TaskCompleted 在标记完成任务时运行. 一个命令可以用代码 2 退出,以防止测试或其他接受检查失败时完成并返回反. 这使得一个确定性门是可能的,而不需要相信散文的说法. 这是一个克劳德代码的具体机制,而不是一个普遍的代理标准, 一个成功运行的仍然需要测试正确的文物. 对于没有阻塞完成的运行时间,使用两个阶段的状态过渡: 不要自动重新尝试所有未经验证的状态. 已知上传延迟后, missing 可能需要一个短限的观察窗口. 如果使用者已经授权, validator failed 可能会证明一个可逆的修复尝试是合理的. unverified 意味着证据道失败;它并不证明可交付的产品是坏的. 一项等待不可逆决的任务属于 waiting 或 needs human ,而不是恢复循环. 也将指挥成功与结果成功分开. 验证器的过程,从 0 中退出,只证明验证器实际检查的东西. 版本验证器名称,记录其证据来源和观察时间,并在可交付的变化时审查合同. 一个旧的接受规则可以产生一个完美记录的虚假阳性. 增加不确定性;不要制造成功 结果合同只能达到其声明的预期. 它可能会错过一个未上市的文物, 接受一个弱的验证器, 这些是揭露覆盖率和信心的理由,而不是默认增加模特法官的理由. 使用一个 LLM 只有在不能确定性检查的标准上进行评估,保持其条款和版本的可见性,避免让同一代理人生产和最终评分自己的作品. 如果证据存在冲突,请优先考虑 uncertain ,并在改变外部状态之前要求权威. Sidewisp 目前处于私密预览阶段。 公共网站和文章图书馆在线;生产代理健康收集,运行时间适配器和恢复通常不出货. Sidewisp是与现有运行时间相结合的健康层,而不是替代运行时间或自动固定器. 操作规则很简单:让运行时间终端事件启动检查,让外部证据决定结果, 如果你的健康模式与你运营代理的方式相匹配, 私人预览注册是适当的下一步.