GoalPipeline 是由一个执行者与一个验证者组成的流水线:执行者产出结果,验证者对照目标判定,不通过则带着理由退回重做,直到通过或用尽次数。
其中的循环如下所示:
Agent,不是某种特殊对象。它的结论通过结构化输出给出,因此一个需要读文件、跑命令、甚至请人确认的验证,走的是和执行完全相同的机制。
运行流水线
以下示例让两个智能体协作完成一个编程任务,执行者写代码,验证者检查:goal_pipeline.py
构造参数
GoalPipeline 的构造参数如下:
目标不在构造时给出,而是随任务一起进入
reply_stream:流水线第一次收到的消息既是交给执行者的任务,也是验证者对照的目标。验证与重试
执行者与验证者都通过结构化输出向流水线交付结果,字段如下:message 会被原样转交给执行者,因此它必须写清楚缺什么,而不是只说「有问题」。一轮的完整流程如下:
1
执行者工作
执行者收到任务开始干活,产出留在共享工作区里,最后交出
report。2
验证者判定
验证者对照目标检查产出,给出
result 与 message。3
通过则结束
result 为 pass 或 impossible 时,流水线结束,事件流关闭。4
不通过则退回
message 包在一段提醒里交给执行者,回到第一步重做。max_iters:
第二种是故障不是判决,算进预算会让执行者平白少几次机会。达到
max_iters 后流水线停止,事件流结束,最后一次 message 留在验证者的对话里。
中断与恢复
执行者或验证者停在工具授权上时,reply_stream 直接结束,不占用协程、不持有锁、不轮询等待。开发者把结果重新喂回来即可继续:
中断后恢复
reply_id 指明了当时是哪一方被挂起,流水线据此把结果交给对应的智能体。
reply_stream 接受的输入如下:
迭代预算记在流水线实例上,而不是
reply_stream 的局部变量里,因此中断恢复不会让已经用掉的次数回满。终端调试
调试流水线最省事的方式,是把它整个交给终端 UI,不需要任何适配代码:在终端中运行流水线
在确认提示上按
Ctrl+D 会发出 UserInterruptEvent:被挂起的那个智能体关掉未决的工具调用,整条流水线随之结束。中断是放弃,不是继续。