Agenda 模式
Agenda 用一个 Planner Agent 替换 Spec 的静态 DAG。Planner 维护 todo 列表,通过工具调用动态调度其他 Agent,读它们的输出,决定下一步派谁去——本质是一个 Agent loop。
什么时候用 Agenda 而不是 Spec:
- 流程要根据中间结果决定下一步派谁。比如"先看看用户输入有没有破规倾向,有的话才启动 Constraint Agent"——这种"有条件触发"在 Spec 的固定 DAG 里很别扭。
- 你想要更灵活的多 Agent 协作,而不是固定的 stage → node 拓扑。
- 用Function Call Runtime的能力让 Planner 自己组织调度。
Agenda 不是 Spec 的替代
Spec 的可预期性、prompt 缓存友好度、debug 友好度都比 Agenda 强。绝大多数 RP 场景固定 DAG 已经够用,Agenda 是给确实需要动态调度的场景准备的。
99% 的人不该手搓
手搓 Planner prompt 之前先看一眼 AI 迭代工作台——一句话描述需求,AI 给你一份 Planner + Agent 池的方案,逐条审。
Agenda 编辑器
切到 Agenda 模式后,从编排器面板点 打开编排编辑器。
左边是 Planner Prompt 配置区(API 预设、提示词预设、System Prompt、Planner Prompt 模板);右边是可用的 Agenda Agents 列表——Planner 通过工具调用从这个池子里挑 Agent 派任务。
Planner
Planner 是 Agenda 的核心,它做几件事:
- 读最近聊天 + 用户消息
- 维护一个 todo 列表(下一步该做什么)
- 调度 Agenda Agent 池里的 Agent 去做任务
- 收集 Agent 输出
- 根据收集到的内容决定下一步,或者认为足够了就停下,把最后一个 Agent 输出当 capsule 注入主模型
Agenda Agents
每个 Agenda Agent 类似 Spec 的 Node:有自己的 System Prompt、User Prompt Template、可选的 API / Chat Completion 预设覆写。区别在于 Agent 不绑死在某个 stage,何时被调用、被调用几次、是否被调用,都由 Planner 决定。
三个运行时上限
Agenda 是动态调度,失控容易,所以有三道闸:
- Planner 最大轮数 — Planner 调度的轮数上限
- 最大并发 Agent 数 — 同时跑的 Agent 数量上限(
Promise.all的并发度) - 总执行次数上限 — 整次跑里所有 Agent 调用次数总和
到任一上限就强制收尾。
AI 迭代工作台
和 Spec 一样,Agenda 也有 AI 迭代工作台支持——自然语言描述 Planner 行为 / Agent 池构成,AI 帮你搭。详见 AI 迭代工作台。Quick Build 也适用 Agenda。
与 Spec 的互转
编排编辑器里有 复制 Spec Agents 到 Agenda / 复制 Agenda Agents 到 Spec 按钮可以快速搬运 Agent 池(尽力而为)。注意:
- Spec → Agenda 时,stage 拓扑信息丢失,需要你重新写 Planner Prompt 描述调度逻辑
- Agenda → Spec 时,Planner 的动态调度无法完整映射到固定 DAG,需要你手动决定 stage 划分
Function Call Runtime 依赖
Agenda 模式的 Planner 调度通过 OpenAI 工具调用实现,依赖 Luker 的 Function Call Runtime框架。这意味着:
- Planner 用的连接配置必须支持 function calling(OpenAI / Claude / Gemini 都支持)
- 工具调用失败时的重试由 Function Call Runtime 处理(详见对应文档)
Trace 面板
主回复出来后在编排器面板点 查看运行态轨迹,Agenda 的 trace 弹窗会按几块铺出整次 run——顶部元信息 + 任务看板、Planner 每一轮的输入输出、流程事件时间线、原始 JSON。
面板概览 + 任务看板
顶部状态摘要里 Agenda 模式独有的一项是 节点执行次数——所有 worker 被调度的总次数,触发「总执行次数上限」那道闸时看的就是这个。REVIEW 重跑次数对 Agenda 不适用,会一直是 0。
紧跟在下面的「任务看板」是 4 列 Kanban:待办 / 进行中 / 完成 / 阻塞,每张卡片显示 todo id、目标 agent 与 goal 描述。看板逐轮更新,run 结束后保留终态——看完成列里 todo 的先后顺序就能知道 Planner 实际派活的节奏。
Planner 轮次
「Planner 轮次」是 Agenda 最有价值的排错视图。每一轮里左侧是 Planner agent 本轮的输出(todo_ops 列表:set_status / add / set_goal 等),右侧是该轮被派发的 worker 们及它们各自的输出。Planner 的「会话」也在这里:系统 块 + 用户 块就是 Planner 收到的完整 prompt。
发现 Planner 派错 agent / 漏掉某步 / 死循环时,直接对照这里的 todo_ops 与 worker 输出找根因。
流程事件
「流程事件」按时间序号铺出每个事件:Run started → 多组 worker started / worker completed(每次 Planner 调度都是一对),最后 Run completed。
事件密度比 spec 高:Agenda 一次 run 通常会有 20+ 事件,Planner 轮次 + 各 agent 调度都会留下记录。事件末尾出现的 finalizer 就是默认的 Final Agent,在配置参考里能换成其他 agent id。
原始轨迹
面板最底下「最新注入文本」是 Final Agent 的输出——也就是注入主模型的 capsule。再往下「原始运行态轨迹」是整次 run 的 JSON 形态,包含 runId、chatKey、generationType、capsuleText、note 等顶层字段。
报 bug 时点「导出本次 run」会下载这份 JSON 的 jsonl 形式,直接附给开发者。
Agenda 配置参考
Agenda 专属配置
| 设置 | 说明 |
|---|---|
| Planner 最大轮数 | Planner 调度的轮数上限 |
| 最大并发 Agent 数 | 同时跑的 Agent 数量上限 |
| 总执行次数上限 | 整次跑里所有 Agent 调用次数总和 |
| Planner API 预设 | Planner 节点用的 Connection profile |
| Planner Chat Completion 预设 | Planner 节点用的提示词预设 |
| Planner System Prompt | Planner 的 system 指令 |
| Planner Prompt 模板 | Planner 的 user prompt 模板 |
| Final Agent | 收尾时把哪个 Agent 的输出当 capsule |
| Agenda Agent 池 | 各 Agent 的预设 / prompt(可独立覆写 API 与 Chat Completion 预设) |
相关页面
- 编排器概览 — 通用配置 / 触发时机 / 角色卡绑定
- AI 迭代工作台 — AI 帮你写 Planner + Agent 池(推荐)
- Spec 模式 — 默认的 DAG 模式
- Loop 模式 — 单 Agent 工具循环
- Function Call Runtime — Planner 调度依赖此框架