经纪人在重新启动中可观察性:交付收件模式

在一个运行中发生的事情通常会得到答案. 这很有用,但当一个代理人委托工作,离开,重新启动或等待另一个代理时还不够. 实际解决方案是 持久交付收据 :在任何过程之外写出一个小记录,其中说明谁接受了工作,预期结果是什么,以及什么证据将关闭它. 保持痕迹,以便调试. 加入收据,以保持连续性. 一个痕迹可以证明交付工具成功返回;收据告诉操作员接收者是否接受了任务,以及承诺的文物是否后来被验证. 简单的答案是:观察边界,不仅仅是跑步 只有在四种不同事件中才能区分交给才是健康的: 1. 发送者委托了一个局限任务; 2. 收件人承认同样的任务; 3. 记录了有用的进展或合理的等待; 4. 预期结果得到了验证. 这些事件可能发生在不同的过程和不同的痕迹中. 他们可能会被排队延迟,主机重新启动或人类批准分开. 处理它们作为一个内存跨度,就会产生脆弱的依赖性:解释工作的环境可能随着过程而消失. 作为允许不同过程的跨度组合成一个痕迹的机制,OpenTelemetry描述了文本传播. 它还为因果相关的异步操作提供跨度链接,后续工作不能是简单的儿童跨度. 这解决了相关性. 它没有定义您的申请承诺,接受或结果验证规则. 收据填补了这个空白. 它是故意比转录更小,比日志更明确. 在一个普通的痕迹停止帮助 举个例子,一个研究人员将检查来源的任务交给另一个员工. 发送者记录成功的 handoff 跨度和出口. 10分钟后,工人开始进行新的过程,找到一个不可访问的来源, 现在有三个州看起来很相似: 任务仍在排队中,并从未被接受; 工人接受了并正确等待; 工人完成了命令,但从来没有提供要求的证据文件. 交付的跨度不能决定它们之间的跨度. 它的成功结束意味着传递操作没有错误返回. 开放Telemetry明确表示,跨度状态描述了该跨度追踪的操作. 这并不是证据表明后期业务结果存在. 开放AI代理 SDK 从另一个方向说明了相同的边界. 它是内置的追踪记录运行,工具调用,交付,护卫,和定制事件. 一个 group id 可以关联多个痕迹,而一个 handoff span 可以显示代表. 此外,SDK还指出,随时出口的痕迹是大量的,并且可能需要明确的清除,当即时交货问题出现时. 丰富的追踪改善了可用于调试的证据;它仍然需要一个外部规则 可交付的经过检查. 这就是为什么代理观察性不应该使命令完成变成结果完成. 最低的交付收据合同 每个状态过渡时只存储一个附录记录. 存储可能是数据库表,一个持久的队列日志,或一个单个主机上的NDJSON文件. 重要特点是,任何参与过程都没有唯一的副本. 这是一个紧的事件形状: 六个字段拥有大部分值: operation id 是用户可见的工作的持久身份. 它能在重试中生存下去. handoff id 确定一个代表性尝试. 一个重新尝试的人会得到新的传递身份证,而不是覆盖历史. event 是一个 delegated , accepted , progress , waiting , completed 或是 outcome verified . expected artifact 指定确定性验证目标. 它还可以命名一个测试,API条件或审查决定. trace id 指出了详细的远程测量,但没有使收据依赖于此远程测量. 预期,拒绝或验证失败的 reason 在有限的操作术语中解释. 不要把提示,凭证,模型输出或原始工具的有效载荷放在此记录中. 收据是指数和状态机,而不是第二个追踪后端. 合理的默认是仅添加的转换加上衍生的当前状态. 更新一个可变的行是诱惑的,但它破坏了需要的证据, 在选择警报之前复制故障情况 这篇文章的附加装置包含四项操作:一个经过验证的交付,一个未经认可的委托,一个合法的批准等待, 这种分类器是故意决定性的. 用: 预期结果是: 这次小测试中,有两项观察结果. 首先,确认延迟和结果验证是独立的. op 101 可以迅速接受,但后来仍然失败; op 102 在任何模型调用或工具执行开始之前已经不健康. 在接收者执行时开始的跟踪中心仪表板不会看到孤儿. 第二,等待需要公开依赖. 虽然 op 103 没有最近的进展, 但将它视为被困的将是错误的, 因为收据名称它需要的批准. 只有与状态和期望相结合, 设置中的120秒的确认限制是一个例子,而不是一个普遍的门. 根据排队的观察到的交付延迟和任务的紧迫性设置. 批量工作可能能承受数分钟; 交互式交换可能承受数秒. 不变量是过渡,而不是数量. 保持因果关系,而不将元数据转化为泄露 使用追踪身份证作为指标, 仅将下游工人实际需要的标识符传播. OpenTelemetrys 行李指南警告说,行李通常以HTTP标题发送,可能会接触未经意图的第三方,并且没有内置的完整性检查. 这使得原始目标,客户文本,文件系统路径和凭证的传播值特别差. 一个更安全的边界是这样的: 传播不透明的 operation id 和 handoff id ; 在运行时间支持时,从接收痕迹到委托痕迹建立一个跨度链接; 保持预期的文物和批准状态在可靠的持久存储中; 仅在授权主机界限内处理敏感语境的识别符; 证明收件作者身份,因为相关性元数据不是身份证明. 现在有个交易. 一个最小的收据不能解释为什么模型选择了一种工具或重建整个对话. 这是故意的. 使用痕迹和日志进行详细调查, 根据您的保留和隐私规则. 用收据可靠地回答一个较小的运营问题:责任是否移动, 将收据转换为运营商状态 避免一个红色或绿色的状态. 收件历史支持五个不同反应的州: Working :最近取得了有用进展. 不要打断它. Waiting :一个名为外在的依赖性或人类的决定未确定. 转向请求,而不是再尝试. Stuck :被接受,没有等待,在任务证据窗口内没有有用的进展. 准备一个有限的恢复. 不确定 :记录不同意,作者不值得信任,或要求的证据无法获得. 在演出之前问. 失败结果 :执行完成,但文物检查失败或从来没有发生. 恢复结果,而不是全部的痕迹. 恢复界限是重要的. 如果行动无效,并且已知重试限度,孤儿转让可能会证明重新交付是合理的. 一个等待的交付不应该仅仅是因为时间表过期而重新尝试. 错误成功状态应运行缺失验证器或要求缺失文物;重复整个药物可以重复副作用. 每个自动响应,记录权力,最大尝试,成本或时间限制,以及将恢复成功的证据. 当原始承诺是发布的报告,合并的变化或传递的消息时,退出命令是不够的. 这对Sidewisp意味着什么 这种收件模式与Sidewisp的运营问题相匹配, 它还尊重一种必要的产品界限:诊断是任何恢复之前的,后续行动需要明确的权威. Sidewisp 目前处于私密预览阶段。 它的公共网站和文章系统是活跃的,而生产代理健康收集,运行时间适配器和自动恢复通常不出货. 因此,上述模式是您今天可以实现和测试的运行时间中立设计,而不是Sidewisp已经收集这些收据的说法. 如果您的代理人不透明, 加入私人预览, 描述您需要的运行时间, 收据存储和批准界限. 这种证据比寻找更多痕迹的一般要求更有用.