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 是给确实需要动态调度的场景准备的。
多数情况下不该手改
手搓 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 调用次数总和
到任一上限就强制收尾。
默认编排流程
Agenda 把节奏交给 Planner Agent 来定，Planner 从 worker 池里挑人派活。默认 profile 自带 Planner 与 worker 池（distiller、lorebook_reader、planner、critic、finalizer）；Planner 派出 worker、读回结果、必要时重新规划，看板搞定后由 finalizer 产出 capsule。
默认 agent 在编排里各自负责什么：
| Agent | 作用 | 简单示例（RP 场景） |
|---|---|---|
Planner（循环驾驶员，非 worker） | 读聊天和用户消息，维护 todo 看板（add / set_status / drop），从下面的 worker 池里挑人派活，读回结果，决定是继续规划还是交给 finalizer。 | 并行派 distiller + lorebook_reader；读完输出，判断还需要 planner 与 critic；交给 finalizer。 |
distiller | 紧凑、有据可查的场景状态读取（用户意图、当前张力、即时方向）；写给 Planner 与下游 agent 看，不直接面向玩家。 | 「林晚在试探用户对洛阳话题的态度；如果用户绕开，她会彻底换话题。」 |
lorebook_reader | 只挑出本回合真的有影响的世界书 / world-info 约束，写成可执行的写作 / 行为约束，不抄世界书原文。 | 「洛阳被围 —— 林晚不可能离开。文风：别用现代词，她会说『不知怎的』而非『somehow』。」 |
planner | 场景进程分析师 —— 提下一拍该走哪些 beat / 决策点，保留因果、不让世界围着用户转。 | 节拍：「用户追问 → 她躲闪 → 换个角度再问 → 她漏出一个洛阳细节 → 回复停在那」。 |
critic | 审 Planner 派过来的材料（连续性断裂、OOC 漂移、缺失硬约束、anti-data、不合理的因果），给审计结论；不亲自改写指引。 | 「这个计划里林晚说『没什么大不了』—— 现代腔调，这角色 OOC。其它通过。」 |
finalizer（Final Agent —— 整个流程的最后一站，只跑一次） | 读完最终的 todo 状态和选定的历次 run，合成一段简洁、可直接拿来起稿下一回合的编排指引文本 —— 就是最后注入主回复的那段 capsule。 | capsule：「林晚：躲闪 → 被追问 → 漏出一个洛阳姑姑的细节。用词保持古朴；她还在被围的洛阳城内。」 |
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 处理（详见对应文档）
看一次 Agenda 跑
运行面板 会实时显示 Agenda 运行。Planner 轮次是卡片，该轮派发的 worker 是它下面的子卡片，展开就能看到完整推理和输出。Agenda 模式可以重点关注：
- Planner 输出 ——
todo_ops列表（set_status/add/set_goal等），就地展开。Planner 派错 agent、漏步、死循环时，对照这些 ops 与 worker 输出找根因。 - worker 派发 —— 该轮 Planner 调起来的每个 worker 均在这一轮的卡片下。展开能看到入参与输出。
- Final Agent 输出 —— run 末尾的最后一个 worker（默认是
finalizer）产出注入主模型的 capsule。配置参考里能换成其他 agent id。 - 事件密度 —— Agenda 一次 run 的事件记录较密（Planner 轮次与派发均会留下记录），所以面板比 Spec 看起来更密。
面板顶部的导出按钮把整次 run 下载为 JSON（便于回报问题）。
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 调度依赖此框架
- 自定义工具 — Agenda Worker 可以调用的扩展 / SillyTavern 桥接 / 手写工具
预设
本模式的配置可以保存为命名预设，并在编辑面板中切换。完整工作流见 编排预设。