工作流

工作流是用自然語言聊天搭建的可複用 Minara 自動化。Agent 根據你 的提示起草工作流定義（步驟、觸發器、通知渠道），你在聊天面板裡 實時看著它構建，畫布在草稿通過校驗時更新。

工作流可以：

• 監控價格（BTC、AAPL、EUR/USD……），跨越閾值時提醒。
• 監控錢包、Polymarket 交易者、或鏈上事件，行為符合規則時通知你。
• 跑每日 / 每週 / cron 調度的投資組合簡報。
• 下單（標準的"預覽再確認"兩步流程，絕不會有靜默的資金變動）。

搭建一個工作流

兩個入口：

• 著陸頁表單。粘貼一段自然語言描述，提交後 agent 起草工作 流並在成功後保存。
• 工作流詳情聊天面板。打開一個已有工作流，描述你想要的改 動（"在告警之後加一個郵件 send_message"、"把每小時改成每 天"），agent 重寫定義。

兩種方式都會在聊天界面實時流式展示工作日誌。你能看到每個步驟 的原始 JSON 在模型生成時逐字出現，等步驟的必填字段全部到位後 立刻摺疊成規範的卡片。只有當 agent 的草稿通過校驗，畫布才會 變化。

Agent 犯錯時會發生什麼

工作流寫作子 agent 每次請求最多跑 3 輪。如果第一輪草稿有 斷鏈（next 指向不存在的步驟）、缺必填字段（tool_call 沒有 tool）、或條件表達式無法解析，結構校驗器會捕捉到，聊天面板 把出錯的草稿摺疊成 Attempt 1 · fixed K issues 摘要，下 方打開一個新的 Attempt 2 ▪ ●●● building… 區段。

摺疊的草稿不會被刪。展開它能看到 agent 嘗試了什麼、以及導致 失敗的結構化錯誤列表。你可以審計這次失誤，但它不會汙染當前視 圖。

重試期間永遠不會發生的三件事：

1. 畫布絕不會從出錯的草稿更新。 畫布的真相來自 workflow.commit 事件，只有通過校驗的那一輪才會觸發。中間 的 workflow.patch 事件只是預覽；畫布會忽略它們。
2. 被丟棄的草稿不會以卡片形式進入聊天面板。 子 agent 在服 務端緩衝每輪的事件，校驗失敗就丟掉緩衝。只有通過校驗那一 輪的卡片會進入聊天曆史。
3. 保存下來的工作流定義永遠不會是損壞的形狀。 如果 3 輪都 失敗，網關發出回滾事件並跳過持久化；你已有的定義保持原樣。

畫布上方的工具欄會反映當前階段：第一輪時 Drafting…，進入 重試時 Retrying, attempt N of 3…，校驗通過保存時 Saving…。聊天沒結束之前 Run / Schedule / Publish 都保持禁 用。

編輯已有工作流

Refine 流程會保留你的現有參數。Agent 只動你消息裡要求改動的 字段。未改動的步驟上的 token 地址、webhook ID、自定義參數值、 條件表達式都按原樣穿過。如果你只是要改通知渠道， tool_call 步驟裡的地址不會被順手改掉。

如果你的請求缺一個 agent 構建可運行工作流必需的參數（你沒指 定的鏈、你還沒連接的 provider），它會返回一句簡短的助手消息 問你缺什麼，而不是猜。不會有靜默的零地址佔位符，也不會有 "你沒說我就默認用 ETH" 的意外。

流中刷新

在 refine 流式輸出過程中刷新聊天面板，會重新連接到正在進行的 會話，並回放已經落地的事件。已摺疊的草稿區段以你之前看到的樣 式重新載入；工作日誌骨架圖會在聊天曆史加載完成的那一刻清掉， 就算底層的 refine 還在某一輪中間。

順序執行模型

每個工作流都按順序運行。沒有數組形式的 next，沒有原生 fan-out，沒有並行分支。如果你讓 agent "告警之後同時發 Telegram 和郵件"，它會串行：notify_tg → notify_email。實 際上兩個連續的 send_message 之間的延遲在亞秒級，從用戶視角 看和並行沒區別。

這是有意為之。fan-out 語義會給監控工作流引入雙觸發的 bug （價格監控 webhook 在波動期間觸發兩次，如果工作流有並行分支 就會觸發兩次 buy）。順序模型 + 資金動作步驟上的持倉檢查， 保證了失敗模式的簡單可控。