從提示工程到任務編排：開源代理平台的轉向
開源代理編排平台 multica 反映了一個轉向：AI 代理的瓶頸不在推理，而在任務協調和進度管理。
提示詞不是瓶頸，協調才是
我最近看到一個開源項目 multica，它的定位很有意思：不是在優化單個 AI 代理的能力，而是在解決多個代理如何作為「真正的團隊」協作的問題。
這反映了我在實踐中的觀察：當我們說「AI 代理」時，大多數團隊的痛點其實不在模型的推理品質，而在於任務的分解、進度的追蹤，以及不同代理之間的技能複合。問題從「怎麼讓 AI 更聰明」轉向了「怎麼讓 AI 聽指揮」。
任務管理層的必要性
multica 的核心設計是在代理之上加一層任務管理抽象。你可以分配任務、監控執行狀態、定義技能組合。
生產環境不是單個 agent 完成單個任務。你需要：
- 拆解複雜任務成可並行或序列執行的子任務
- 在執行時實時觀察哪些步驟卡住了
- 根據結果動態調整後續步驟
這些需求不是「prompt engineering 做得更好」能解決的。你需要一個明確的任務圖、執行引擎，和可觀測性。
開源編排工具的意義
multica 選擇開源。編排層的邏輯高度依賴於具體業務——你的任務流程、失敗重試策略、代理間的通信協議，這些都很難被一個通用的 SaaS 完全滿足。
開源意味著你可以 fork、修改、內化這套思路。你不是被鎖在某個廠商的工作流定義裡。
但開源也有代價：你得自己維護、理解代碼、在必要時貢獻回來。這對小團隊可能太重。對大團隊，反而是個機會——你可以根據自己的架構選擇性地集成。
我的保留
我還沒有看到 multica 在生產環境的案例。任務編排工具看起來簡潔，實際用起來會面臨什麼問題？
- 當代理執行失敗時，誰決定重試策略？是硬編碼還是動態的？
- 多個代理的輸出格式不一致時怎麼辦？
- 成本控制——如何避免一個任務流程跑出天價的 token 消耗？
這些問題不是技術問題，是工程問題。開源項目通常在前者做得不錯，在後者留下空白。
值得試試的角度
如果你的團隊已經在用多個 AI 代理，或者在考慮這麼做，multica 的思路值得參考——即使你最後不用這個具體的工具。它迫使你思考一個更基礎的問題：代理的能力邊界在哪裡，編排層應該負責什麼。
這個轉向從「我用什麼提示詞」到「我怎麼設計任務流程」，可能比優化單個模型的效果還大。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。