將流程建模為故事線 — 正確做法

將複雜的流程轉化為 Storyline 是一種建模練習，而非單純的抄錄。相關機制請參閱 將流程編譯為 Storyline；本文旨在說明 如何思考，以確保結果可靠，而非僅是一個「大致能運作」的圖形。

從設定檔（profile）開始，接著是決策點

在繪製節點之前，請決定 您要追蹤的內容 —— 即 profile_schema（例如 docs_ready、risk_flag、attempts）。接著映射 真實的決策點，而不僅僅是順暢路徑（happy path）。對話可能分支或失敗的每個地方都是一個帶有出口（exits）的節點；僅對理想路徑進行建模的流程，會在用戶做出意外行為的第一時間失效。

一個節點 = 一個連貫的步驟

節點應該只做一件事，且這件事是人類會命名為的（「收集文件」、「確認身分」）。不要將整個子流程塞入單一節點的 task 中並指望模型能將其排序——這樣會喪失分支、恢復和測量的能力。如果節點的任務包含「然後做這個，然後做那個」，那代表這是多個節點。

在結果必須可靠的情況下，使分支具有決定性

• 當分支必須可預測時，請根據 rule（針對 profile 維度）或 user_choice 進行路由。僅在需要真正判斷時才保留 ai 出口（「他們是否真的描述了問題？」）。
• 出口是 依優先順序排列 的——將決定性的一項放在前面，ai 後備選項放在最後。
• 使用帶有反向邊（back-edge）以及 writes 計數器（op: "inc"）和 rule 上限來建模重試循環。切勿依賴模型來決定它已循環足夠次數。

將身分與安全機制保留在 agent 上，而非節點上

agent 的 soul 和安全邊界在整個 Storyline 中保持不變——這正是其重點。不要嘗試在每個節點中重新陳述人格或重新施加安全限制；節點僅添加任務/技能/知識庫/工具並寫入 profile 維度。

保持 node_keys 穩定；發布前進行驗證

node_key 是出口的標識以及漏斗的參考點。當您使用 update_storyline 進行編輯時，請保持它們的穩定性——靜默地重新命名節點會使其出口孤立。在 publish_storyline 之前，請務必執行 validate_storyline；它能捕捉不可達的節點、死胡同以及懸空的出口。

不要過度建模

如果任務僅是一個問題和回答，那麼它 不是 Storyline——它只是一個帶有知識庫的 agent。當存在真正的多步驟狀態需要攜帶時（例如：資料收集、輔導、引導式申請），才使用 Storyline。將一次性的問答建模為圖形，除了增加成本和失敗模式外，沒有任何好處。

常見的錯誤方式（請避免這些）

• 僅有順暢路徑 —— 沒有為「用戶感到困惑」或「未提供資訊」設置出口，導致流程卡住。
• 所有出口都是 ai —— 路由變成一場賭博；相同的輸入會走上不同的路徑。
• 巨型節點 —— 單一節點的 task 描述了整個流程；無法分支或恢復。
• 無限循環 —— 帶有反向邊但沒有計數器和上限。
• 在每個節點中重新陳述安全機制 —— 這些噪音會與 agent 實際的安全邊界競爭。

透過命名真實的狀態並將每個決策移至決定性出口來修正這些問題。