Skip to main content
GoalPipeline 是由一个执行者与一个验证者组成的流水线:执行者产出结果,验证者对照目标判定,不通过则带着理由退回重做,直到通过或用尽次数。 其中的循环如下所示:
验证者是一个普通的 Agent,不是某种特殊对象。它的结论通过结构化输出给出,因此一个需要读文件、跑命令、甚至请人确认的验证,走的是和执行完全相同的机制。

运行流水线

以下示例让两个智能体协作完成一个编程任务,执行者写代码,验证者检查:
goal_pipeline.py

构造参数

GoalPipeline 的构造参数如下:
目标不在构造时给出,而是随任务一起进入 reply_stream:流水线第一次收到的消息既是交给执行者的任务,也是验证者对照的目标。

验证与重试

执行者与验证者都通过结构化输出向流水线交付结果,字段如下: message 会被原样转交给执行者,因此它必须写清楚缺什么,而不是只说「有问题」。一轮的完整流程如下:
1

执行者工作

执行者收到任务开始干活,产出留在共享工作区里,最后交出 report
2

验证者判定

验证者对照目标检查产出,给出 resultmessage
3

通过则结束

resultpassimpossible 时,流水线结束,事件流关闭。
4

不通过则退回

message 包在一段提醒里交给执行者,回到第一步重做。
两种「重来」性质不同,只有第一种消耗 max_iters 第二种是故障不是判决,算进预算会让执行者平白少几次机会。达到 max_iters 后流水线停止,事件流结束,最后一次 message 留在验证者的对话里。

中断与恢复

执行者或验证者停在工具授权上时,reply_stream 直接结束,不占用协程、不持有锁、不轮询等待。开发者把结果重新喂回来即可继续:
中断后恢复
恢复时不需要说明该找谁。事件自带的 reply_id 指明了当时是哪一方被挂起,流水线据此把结果交给对应的智能体。 reply_stream 接受的输入如下:
迭代预算记在流水线实例上,而不是 reply_stream 的局部变量里,因此中断恢复不会让已经用掉的次数回满。

终端调试

调试流水线最省事的方式,是把它整个交给终端 UI,不需要任何适配代码:
在终端中运行流水线
运行起来之后,各部分的分工如下: 在确认提示上按 Ctrl+D 会发出 UserInterruptEvent:被挂起的那个智能体关掉未决的工具调用,整条流水线随之结束。中断是放弃,不是继续。