什么是AI代理管弦乐? 测试它的可靠性

AI代理配套是接受目标,分开或路线工作,分配所有权,承载共享状态,订单依赖,处理等待和交付,并决定下一步可以运行. 如果一个代理人不再是任务的最简单可靠的主人, 这一定义有一个重要的界限:调整状态不是证明运行时间可达,工作正在进展,工具效应发生,或者预期结果存在的证据. 一个工作流程可以正确地引导每个任务, 因此,实践测试是: 让主管证明协调事实. 需要对运行时间健康,人权,有用的进步,外部影响以及最终结果的单独证据. 这本指南将这个边界变成一个七个案例的固定. 这种装置会给出不同的裁决, 关于发送的工作, 合法批准等待, 无法达到的运行时间, 停滞, 不确定的工具效果, 错误的成功, 简短的定义:协调,而不是证明 目前美国搜索结果的定义一致. IBM 描述了AI的代理编排 为了实现共同目标,我们将作为协调专业代理人. 在 GitHub 描述它 作为分配,共享状态,检查点,政策和人为循环决策的控制层. 这两种定义不仅仅包括在列表中调用代理人. 一个管弦乐员通常拥有: - 允许具有稳定任务或运行ID的任务; - 分解成阶段或分支; - 每个工作单位的所有者分配; - 依赖性顺序和同步性规则; - 国家的传播需要继续; - 打字等待依赖或批准; - 试验和截止日期预算; - 终端工作流状态. 当工作负担真正需要协调时,这些责任变得有价值. 一个只有三种工具的支持代理不仅仅因为它被分为路由器,研究人员,作家和评论员而变得更加可靠. Azure 建筑中心推最低的复杂性,可靠地满足要求,并指出多代理调整增加了协调总费,延迟,成本和故障模式. 首先要一个老板. 在需要严格的阶段顺序,独立的并行工作,动态专家路由,单独的权限或持久的暂停和恢复界限时,添加调整. 这是一个工作量决定,而不是成熟度标志. 演唱会的词汇也延伸到相邻的系统中. 保持这些责任分开使建筑评审更加精确: 层 它能证明什么 单独不能证明的东西 --- --- --- 演唱会 任务,顺序,依赖性,交付,工作流程状态 运行时间可达性或预期的外部结果 运行时间 一个进程开始,执行代码,然后返回 有用进展或完成业务 可观察性 事件,跨度,日志,指标及其新鲜性 记录的任务结果是正确的 卫生代理 一种诊断,如工作,等待,被困,无法到达或不确定 权力进行不可逆变的变化 批准 一个人授权一项有限的行动 行动成功 结果验证 要求的文物或外部效应存在,并且超过了其声明 为什么以前的运行停滞不前 这些区别是操作性的,而不是语义上的小事. 如果一个管弦仪表板标记一个运行暂停,下一步的行动取决于哪个层提供了证据. 目前有申请批准, 拥有者和截止日期等待. 一个死去的运行时间是不可达成的. 没有输出三角形的直播运行时间重复相同的操作. 作为暂停的待遇隐藏了干预决定. 围绕管弦乐器绘制五个边界 一个有用的管弦乐记录从一个任务合同开始,而不是一个提示. 记录一个稳定的任务ID,预期结果,所有者,当前状态版本,截止日期和完成所需的证据. 在执行过程中,提示可能会发生变化; 合同应该存活路由,重新尝试和重新启动. 然后绘制五个边界. 1. 录取和所有权 管家可以证明他接受了工作并分配了它. 这并不证明处决开始了. 保持 acceptedAt , owner , assignmentEpoch 和 startReceipt 分开. 这种分离会发现一个静静的队列失败:任务是可见的,但没有运行时间承认它. 正确的判决是 发送 ,没有工作. 转让增加了所有权时代,这样一个老的工人不能以后做出效果,好像他仍然拥有任务. 2. 运行时间和进展 一个跑步时的心跳回答了这个过程是否可以报告. 有关任务的证据是否发生了变化. 你们不要互相推断. 进步收据应指定一个域名声明:一个新的测试通过,一个要求的分支完成,一个目标对象获得了有效版本,或者一个未解决的项目数量下降. 处理器活动,模型调用和工具调用是活动信号. 他们有助于解释一个运行,但它们是弱的替代品, 开发状态开放Telemetry GenAI语义公约定义了代理创建,代理和工作流调用,规划和工具执行的跨度. 那些跨度是有价值的执行证据. 它们不确定客户是否收到了所要求的退款,或者是否在承诺的URL上存在报告. 3. 等待和权威 当请求是当前的,向授权所有者转移, 有限于最后期限, 存储批准请求作为一级对象: 行动指纹将权威绑定到一个具体的操作. 过期阻止旧决定授权后续重新试验. 简历标记告诉乐队主持人继续. 开放AI代理 SDK 人类循环指南提供了一个具体的实现:工具调用会导致中断,运行状态可以串行,记录了特定调用的批准或拒绝,并恢复了原始运行. 这种机制证明了决定得到了处理. 这仍然没有证明下游效果. 4. 工具效果确定性 工具反应和工具效应是不同的事实. 在请求到达供应商后,暂停时间可能意味着没有发生任何事情,操作成功,但响应丢失,或重新尝试创建复制. 组织者应保留一个操作身份,并将模糊的结果转向和解. 它不应该把终止的工具调用转化为完成的任务.直到目的地确认效果,状态是 未确定的效果 ,自动重试在副作用边界停止. 5. 目的地结果 最终验证人应遵守任务合同中所指定的目的地. 报道,请拿到物体,验证其所需的部分. 检查预期版本和健康声明. 对于消息,将提供者收件和预期收件者相结合. 为了更改数据库,请重新阅读记录并比较预期版本. 这种验证器是故意在乐队主管的终端事件之外. 否则,声明完成的同一组件也提供了完成正确的唯一证据. 在信任绿色之前,再播放边界. 我将这些区别编码为 orchestration-boundary-cases.json ,然后通过 classify-orchestration-boundary.mjs 运行它们. 该分类器使用一个固定优先级: 使用: 所有7起案件都符合预期的判决: 案例 演唱会事实 独立的证据 判决 --- --- --- --- 发送,没有启动 分配的所有者 没有开始收据. dispatched 审批等待 暂停运行 目前的请求缺乏决定 waiting-for-approval 运行时间无法达到 任务仍然被分配 心跳不可用 unreachable 没有进步的活跃 电话继续 进步收据已过时 stuck 工具时间 终端通话记录 效果无法调和 uncertain-effect 演唱家完成 终端工作流状态 没有目的地声明 false-success 目的地验证 终端工作流状态 结果声明通过 verified-complete 最有用的对是最后两个. 它们的编排痕迹可能是一样的. 增加一个目的地声明将判决从错误成功转变为验证完整. 协调完成是某些工作流程所需的证据,但不足以证明结果. 设备还揭示了订单选择. 在启动状态之前检查运行时间可用性,因为在不可用运行时间上分配的任务需要可用性响应而不是正常的队列耐心. 在检测停机之前检查有效的批准等待,因为等待被授权的人应该被调节和升级,而不是重新启动作为局工作. 这不是一个普遍的状态机器. 这些事实是合成的, 一个收藏器可能是过时的,一个审批服务可以错误地识别所有者, 当证据冲突时,生产实施需要新鲜性,来源身份,版本相关性和明确未知的状态. 选择最小的协调层,保持诚实 在采用编排框架或平台之前,为每一个边界写一个示例记录: - 一项尚未开始的已接受任务; - 一个合法依赖或批准等待; - 一个活动的直播,但没有有用的进展; - 一个具有模糊的外部影响的工具调用; - 一个工作流程被标记为完整,而其承诺的交付值则缺失; - 一个完成,由目的地本地声明证实. 然后请候选人系统显示每项判决的证据来源,新鲜性和所有者. 它不需要拥有每一个层. 它确实需要保持稳定的身份并出口足够的状态, 一个合理的小团队架构可以保持谦虚:本地代理运行时间,一个持久的管弦乐器商店,紧的健康收据,一个范围的批准道, 痕可以在诊断中保持可用性,而不会成为完整的预言器. 在证据质量和可逆性证明更多的自动化之前,恢复可能仍然是人类批准的行动. 这一边界也使供应商的索赔可读. 包括可观测性可能意味着执行时间. 在循环中支持的人类可能意味着暂时的提示,没有持久的所有权. 轨道完成可能意味着最后一个管弦节点返回. 问哪个状态转移存储,哪个外部声明改变它. Sidewisp旨在在在现有药物运行时间周围增加一种健康层,将有用的进展,等待,工具,结果和成本与原料活动分开. Sidewisp 目前处于私密预览阶段。 它的公开网站和互动演示是现场的,但生产代理健康收集,运行时间适配器和恢复没有在当前的网站存储库中发送. 持久的答案是什么是AI代理调整? 因此比许多平台页面所示的更窄:它是谁做什么,在哪个顺序,与谁共享状态和边界的协调合同. 当该合同不再宣称只有运行时间,授权的人或目的地才能证明的事实时,可靠的系统就成为可能.