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 調度依賴此框架