之前在做 AI 應(yīng)用落地時(shí)我經(jīng)常遇到一個(gè)很典型的問題單智能體在簡(jiǎn)單問答場(chǎng)景表現(xiàn)很好但一旦把“收集資料、拆解大綱、寫初稿、審校潤(rùn)色”這些任務(wù)全部交給同一個(gè) Agent它就開始顧此失彼——上下文一長(zhǎng)早期內(nèi)容被遺忘既要搜索又要寫作角色指令互相干擾輸出格式也經(jīng)常不穩(wěn)定。后來把所有任務(wù)拆分到多個(gè)子 Agent交給 Coze 工作流統(tǒng)一調(diào)度整個(gè)鏈路才真正穩(wěn)定下來。這篇文章會(huì)圍繞 Coze 平臺(tái)的多 Agent 協(xié)作展開從核心設(shè)計(jì)模式講起再用一個(gè)“技術(shù)文章創(chuàng)作團(tuán)隊(duì)”的完整案例帶你走通項(xiàng)目空間配置、子 Agent 創(chuàng)建、工作流編排、調(diào)試發(fā)布的全流程。文中會(huì)重點(diǎn)拆解“主從調(diào)度”思想以及為什么把子 Agent 當(dāng)作“另類工具”來調(diào)用是當(dāng)前多 Agent 設(shè)計(jì)里最實(shí)用的思路。如果你已經(jīng)熟悉 Coze 基礎(chǔ)操作想進(jìn)一步把智能體做成真正的“AI 團(tuán)隊(duì)”這篇文章正好適合你。1. 背景為什么需要多 Agent 協(xié)作1.1 單智能體的能力邊界先看一個(gè)最常見的場(chǎng)景用戶要求“寫一篇關(guān)于 Spring Security 的技術(shù)文章”并且給出關(guān)鍵詞和字?jǐn)?shù)。如果用一個(gè) Agent 完成這件事會(huì)出現(xiàn)幾個(gè)問題。第一是上下文壓力。一次完整的寫作鏈路至少包含選題、資料補(bǔ)充、正文撰寫、格式調(diào)整四步。單 Agent 在同一個(gè)會(huì)話里反復(fù)切換任務(wù)早期輸入的信息會(huì)被后續(xù)內(nèi)容稀釋尤其當(dāng)用戶要求“參考第一輪討論的結(jié)論”時(shí)Agent 很可能已經(jīng)記不清楚。第二是角色沖突。同一個(gè)提示詞里既要讓 Agent 扮演“嚴(yán)謹(jǐn)?shù)馁Y料搜集員”又要讓它扮演“有文采的寫作教練”這兩個(gè)角色天然有張力。結(jié)果往往是資料部分不夠扎實(shí)正文部分又顯得生硬。第三是工具調(diào)用混亂。單 Agent 同時(shí)綁定了搜索插件、知識(shí)庫、代碼解釋器等工具后Agent 容易在錯(cuò)誤的時(shí)機(jī)調(diào)用錯(cuò)誤的工具。比如寫技術(shù)文章時(shí)頻繁調(diào)用搜索卻忘了先根據(jù)知識(shí)庫中的寫作規(guī)范來約束輸出。第四是可維護(hù)性差。所有邏輯都堆在一個(gè)巨型提示詞里改一句角色描述可能影響整個(gè)輸出風(fēng)格。項(xiàng)目一旦需要多人協(xié)作或復(fù)用這種“超級(jí) Agent”很難維護(hù)。1.2 多 Agent 協(xié)作的核心價(jià)值多 Agent 協(xié)作的本質(zhì)是把一個(gè)復(fù)雜任務(wù)拆解成多個(gè)邊界清晰的子任務(wù)每個(gè)子任務(wù)交給獨(dú)立的 Agent 完成再由上層調(diào)度邏輯統(tǒng)一組合結(jié)果。這樣做有三個(gè)直接收益。一是職責(zé)聚焦。每個(gè) Agent 只需要專注一件事提示詞可以寫得非常具體不需要在“角色切換”上消耗模型能力。二是上下文隔離。子 Agent 只接收自己需要的最小輸入集不會(huì)把無關(guān)信息帶進(jìn)上下文這也從根源上減少了信息污染。三是可編排與可復(fù)用。任務(wù)流程可以用工作流固定下來某個(gè)子 Agent 調(diào)優(yōu)后其他環(huán)節(jié)不受影響。而且同一個(gè)子 Agent比如“審校優(yōu)化 Agent”可以復(fù)用到文章寫作、PPT 生成、測(cè)試用例審核等不同項(xiàng)目里。1.3 適合多 Agent 的場(chǎng)景并不是所有任務(wù)都需要多 Agent。適合用多 Agent 的場(chǎng)景通常有三個(gè)特征鏈路長(zhǎng)、步驟之間可以拆分、不同步驟對(duì)角色能力要求不同。典型場(chǎng)景包括內(nèi)容生產(chǎn)流水線選題策劃、資料檢索、正文撰寫、審校潤(rùn)色。復(fù)雜報(bào)告生成數(shù)據(jù)采集、指標(biāo)分析、可視化建議、報(bào)告撰寫。AI 軟件測(cè)試工作臺(tái)測(cè)試用例設(shè)計(jì)、測(cè)試執(zhí)行、缺陷分析、測(cè)試報(bào)告生成?？头翁幚碛脩粢鈭D識(shí)別、知識(shí)庫匹配、答案生成、合規(guī)復(fù)核。學(xué)習(xí)輔導(dǎo)助手知識(shí)點(diǎn)講解、出題練習(xí)、作業(yè)批改、學(xué)習(xí)計(jì)劃制定。以內(nèi)容生產(chǎn)為例單 Agent 也能寫但寫出來的文章往往結(jié)構(gòu)松散、事實(shí)性信息缺乏支撐。多 Agent 后每個(gè)環(huán)節(jié)由更專業(yè)的角色完成產(chǎn)出質(zhì)量會(huì)明顯提升。1.4 Coze 平臺(tái)的多 Agent 能力概覽Coze 是一站式智能體開發(fā)平臺(tái)核心資源包括項(xiàng)目空間、Agent、工作流、知識(shí)庫、插件、變量和發(fā)布渠道。在 Coze 上落地多 Agent通常有兩條路徑在工作流中直接編排多個(gè) Agent 節(jié)點(diǎn)讓不同的子 Agent 按順序或并行執(zhí)行。用主 Agent 作為調(diào)度入口主 Agent 負(fù)責(zé)拆解用戶需求把子 Agent 當(dāng)作能力模塊來調(diào)用。兩條路徑并不互斥實(shí)際項(xiàng)目中往往組合使用。這篇文章的實(shí)戰(zhàn)案例會(huì)以“主工作流 多個(gè)子 Agent”的方式演示。需要提醒的是Coze 的界面入口和功能名稱迭代比較快你看到的按鈕位置可能和我描述的有差異但核心概念和設(shè)計(jì)思路是通用的。2. 多 Agent 協(xié)作的核心模式2.1 串行流水線模式串行模式是最直觀的協(xié)作方式Agent A 的輸出作為 Agent B 的輸入依次傳遞。例如用戶輸入標(biāo)題 ↓ 選題策劃 Agent 生成大綱 ↓ 內(nèi)容撰寫 Agent 根據(jù)大綱生成初稿 ↓ 審校優(yōu)化 Agent 輸出終稿這種模式的優(yōu)點(diǎn)是邏輯清晰、容易調(diào)試。缺點(diǎn)是鏈路耗時(shí)較長(zhǎng)而且前面節(jié)點(diǎn)如果輸出質(zhì)量差會(huì)直接影響后面所有節(jié)點(diǎn)。串行模式適合步驟之間存在強(qiáng)依賴關(guān)系的場(chǎng)景。比如“先有大綱才能寫正文”兩個(gè)步驟無法并行。2.2 并行分發(fā)模式在很多任務(wù)里子任務(wù)之間并不存在依賴關(guān)系。比如收集資料和設(shè)計(jì)大綱可以同時(shí)進(jìn)行。并行分發(fā)模式由一個(gè)分發(fā)節(jié)點(diǎn)把任務(wù)拆開多個(gè)子 Agent 并行運(yùn)行最后再匯總結(jié)果。用戶輸入標(biāo)題 ↓ 分發(fā)節(jié)點(diǎn)同時(shí)調(diào)用 ├── 選題策劃 Agent ├── 資料檢索 Agent └── 素材整理 Agent ↓ 匯總節(jié)點(diǎn)合并所有輸出這種模式可以顯著縮短整體耗時(shí)但要注意子 Agent 數(shù)量不要太多否則會(huì)產(chǎn)生較高的并發(fā)調(diào)用成本也容易讓匯總節(jié)點(diǎn)處理不過來。2.3 主從調(diào)度模式主從調(diào)度模式是當(dāng)前多 Agent 設(shè)計(jì)里很主流的一種做法。主 Agent 類似于“項(xiàng)目負(fù)責(zé)人”它負(fù)責(zé)理解用戶需求、拆解任務(wù)、選擇合適的子 Agent、驗(yàn)證中間結(jié)果最后匯總輸出。從調(diào)用關(guān)系上看主 Agent 是調(diào)用方子 Agent 是被調(diào)用方。主 Agent 不關(guān)心子 Agent 內(nèi)部具體怎么推理只關(guān)心輸入輸出是否符合約定。這種模式在實(shí)際應(yīng)用中更靈活。用戶直接和主 Agent 對(duì)話不需要感知背后有幾個(gè)子 Agent。主 Agent 可以根據(jù)不同問題動(dòng)態(tài)決定調(diào)用哪些能力而不是把整個(gè)流程寫死。2.4 將子 Agent 視為“另類工具”很多人在設(shè)計(jì)多 Agent 時(shí)容易把子 Agent 想象成“團(tuán)隊(duì)成員”給每個(gè) Agent 特別擬人化的設(shè)定結(jié)果反而忽略了接口設(shè)計(jì)。在最新的多 Agent 設(shè)計(jì)中有一個(gè)非常實(shí)用的視角把子 Agent 當(dāng)作另類的 Tool 進(jìn)行調(diào)用。傳統(tǒng)插件工具是確定性的 API 調(diào)用輸入固定參數(shù)返回固定結(jié)構(gòu)。子 Agent 表面上是一個(gè)“智能體”但站在上層調(diào)度邏輯的角度它同樣是一個(gè)封裝好的能力函數(shù)只是內(nèi)部由大模型驅(qū)動(dòng)可以處理更復(fù)雜的非結(jié)構(gòu)化輸入。用這個(gè)視角設(shè)計(jì)系統(tǒng)你會(huì)更關(guān)注三件事子 Agent 的輸入輸出契約是否清晰。子 Agent 的調(diào)用成本是否可控。子 Agent 的失敗模式是什么上層如何兜底。這種“工具化”思維能讓多 Agent 系統(tǒng)更穩(wěn)定、更容易工程化落地。3. 實(shí)戰(zhàn)案例技術(shù)文章創(chuàng)作團(tuán)隊(duì)3.1 為什么選“技術(shù)文章創(chuàng)作團(tuán)隊(duì)”選這個(gè)案例有三個(gè)原因。第一寫技術(shù)文章是很多開發(fā)者熟悉的場(chǎng)景理解成本低。第二寫作鏈路足夠長(zhǎng)能體現(xiàn)多 Agent 分工的價(jià)值。第三案例可以復(fù)用到其他內(nèi)容類應(yīng)用比如生成 PPT 大綱、生成測(cè)試報(bào)告、生成產(chǎn)品方案。這個(gè)案例的目標(biāo)是用戶輸入一個(gè)技術(shù)主題和關(guān)鍵詞系統(tǒng)自動(dòng)輸出一篇結(jié)構(gòu)清晰、有事實(shí)支撐、格式規(guī)范的技術(shù)文章。3.2 整體協(xié)作流程案例整體流程采用“并行 串行”混合編排用戶輸入標(biāo)題、關(guān)鍵詞、目標(biāo)讀者 ↓ 主調(diào)度入口 ↓ 并行執(zhí)行 ├── 選題策劃 Agent輸出標(biāo)題候選和大綱 └── 資料檢索 Agent輸出事實(shí)清單和示例 ↓ 內(nèi)容撰寫 Agent根據(jù)大綱和資料生成初稿 ↓ 審校優(yōu)化 Agent檢查質(zhì)量、優(yōu)化表達(dá)、輸出終稿你可以在 Coze 中把它實(shí)現(xiàn)為一條主工作流前面兩個(gè)分支并行后面兩個(gè)節(jié)點(diǎn)串行。3.3 子 Agent 的職責(zé)與輸入輸出契約在開始創(chuàng)建 Agent 之前先把每個(gè)角色的職責(zé)和輸入輸出約定清楚。這一步非常重要工作流編排是否順暢完全取決于契約設(shè)計(jì)是否清晰。子 Agent職責(zé)輸入字段輸出字段選題策劃 Agent拆解用戶主題生成大綱title, keywords, audiencetitle_list, outline, word_count_plan資料檢索 Agent補(bǔ)充事實(shí)性信息outline, keywords, search_scopefacts, examples, source_notes內(nèi)容撰寫 Agent根據(jù)大綱和資料生成初稿outline, facts, examples, styledraft審校優(yōu)化 Agent檢查質(zhì)量并潤(rùn)色draft, review_rulesfinal_article, issues我建議在 Coze 的提示詞里直接用字段名描述輸入輸出例如“輸出格式必須包含 draft 字段”這樣后續(xù)工作流映射字段時(shí)不會(huì)混亂。3.4 協(xié)作流程中的并行與串行選題策劃和資料檢索之間沒有依賴關(guān)系適合并行執(zhí)行。但內(nèi)容撰寫必須等前兩者都結(jié)束才能開始審校優(yōu)化必須等初稿完成才能執(zhí)行。從性能角度考慮并行可以讓第一個(gè)版本的整體耗時(shí)降低約三分之一。從穩(wěn)定角度考慮串行環(huán)節(jié)越少出錯(cuò)時(shí)越容易定位。所以這個(gè)案例是一個(gè)比較平衡的設(shè)計(jì)。4. 環(huán)境準(zhǔn)備與項(xiàng)目空間配置4.1 注冊(cè)賬號(hào)與新增項(xiàng)目空間在開始創(chuàng)建 Agent 前需要先注冊(cè) Coze 賬號(hào)并完成登錄。登錄后第一步不是直接創(chuàng)建 Agent而是先規(guī)劃項(xiàng)目空間。項(xiàng)目空間是管理智能體、工作流、知識(shí)庫、插件、變量等資源的地方。推薦按“團(tuán)隊(duì) 項(xiàng)目”的維度來劃分空間。例如你可以創(chuàng)建一個(gè)名為“AI 內(nèi)容創(chuàng)作中臺(tái)”的項(xiàng)目空間專門承載所有內(nèi)容類智能體。創(chuàng)建項(xiàng)目空間時(shí)通常只需要填寫空間名稱、簡(jiǎn)介和成員權(quán)限。如果你只是個(gè)人練習(xí)可以先用單成員空間重點(diǎn)是理解空間的資源組織邏輯。4.2 項(xiàng)目空間內(nèi)的資源規(guī)劃進(jìn)入項(xiàng)目空間后建議先規(guī)劃好要?jiǎng)?chuàng)建哪些資源而不是想到什么創(chuàng)建什么。以本文案例為例規(guī)劃如下Agent1 個(gè)主調(diào)度 Agent4 個(gè)子 Agent。工作流1 條主工作流承載整個(gè)協(xié)作流程。知識(shí)庫1 個(gè)“技術(shù)寫作規(guī)范庫”存放文章結(jié)構(gòu)模板和表達(dá)規(guī)范。插件搜索插件供資料檢索 Agent 使用。變量寫作風(fēng)格偏好、目標(biāo)讀者默認(rèn)值。如果把所有 Agent 都放在同一個(gè)空間調(diào)試時(shí)找資源會(huì)方便很多。但如果項(xiàng)目進(jìn)入生產(chǎn)階段建議把開發(fā)環(huán)境和正式環(huán)境拆成不同的空間。4.3 成員權(quán)限與環(huán)境隔離Coze 的項(xiàng)目空間支持配置成員權(quán)限。即使你是個(gè)人練習(xí)也應(yīng)該養(yǎng)成最小權(quán)限的習(xí)慣每個(gè)成員只分配完成工作所需的最小權(quán)限組合。涉及外部系統(tǒng)調(diào)用時(shí)API Token 等敏感信息建議通過變量管理不要在提示詞或代碼節(jié)點(diǎn)中硬編碼。版本方面Coze 迭代頻繁發(fā)布功能變化較快。生產(chǎn)環(huán)境變更前建議在獨(dú)立測(cè)試空間中驗(yàn)證再通過發(fā)布流程同步到正式環(huán)境避免直接修改線上可用的智能體。5. 創(chuàng)建子 Agent 與角色分工5.1 子 Agent 的通用創(chuàng)建步驟在 Coze 中創(chuàng)建子 Agent 的常見路徑是在項(xiàng)目空間的 Agent 管理頁面點(diǎn)擊創(chuàng)建填寫名稱和描述再配置提示詞、模型、知識(shí)庫、插件等。子 Agent 雖然可以被工作流調(diào)用但它本身也可以獨(dú)立對(duì)話。為了讓其適合被調(diào)度創(chuàng)建時(shí)應(yīng)重點(diǎn)配置兩件事清晰的人設(shè)、嚴(yán)格的輸出格式。下面我會(huì)給出四個(gè)子 Agent 的提示詞配置示例你可以在實(shí)際創(chuàng)建時(shí)根據(jù)自己的業(yè)務(wù)調(diào)整。示例中用到的字段名需要與工作流中的變量名保持一致。5.2 選題策劃 Agent 配置示例這個(gè) Agent 負(fù)責(zé)把用戶模糊的主題變成可執(zhí)行的文章大綱。你是「選題策劃 Agent」負(fù)責(zé)把用戶給出的技術(shù)主題拆解成結(jié)構(gòu)清晰的文章大綱。 輸入字段 - title用戶輸入的主題 - keywords相關(guān)關(guān)鍵詞列表 - audience目標(biāo)讀者 處理要求 1. 根據(jù)受眾判斷文章的深度和側(cè)重點(diǎn)。 2. 輸出 3 個(gè)候選標(biāo)題要求具體、有信息量。 3. 設(shè)計(jì)一級(jí)和二級(jí)大綱每個(gè)部分給出目標(biāo)字?jǐn)?shù)。 輸出格式嚴(yán)格 JSON { title_list: [標(biāo)題1, 標(biāo)題2, 標(biāo)題3], outline: [ {section: 一級(jí)標(biāo)題, subsections: [二級(jí)標(biāo)題1, 二級(jí)標(biāo)題2], word_count: 800} ], word_count_plan: 全文目標(biāo)字?jǐn)?shù)與各部分分配說明 } 注意不要編寫正文不要編造引用來源。5.3 資料檢索 Agent 配置示例資料檢索 Agent 的核心職責(zé)是給后續(xù)寫作提供事實(shí)性素材。它需要綁定搜索插件也可以掛載你自己的知識(shí)庫。你是「資料檢索 Agent」負(fù)責(zé)根據(jù)文章大綱和關(guān)鍵詞補(bǔ)充可靠的事實(shí)性信息。 輸入字段 - outline文章大綱 - keywords關(guān)鍵詞列表 - search_scope檢索范圍說明例如“僅使用本文檔庫”或“使用互聯(lián)網(wǎng)搜索” 處理要求 1. 每個(gè)大綱小節(jié)至少補(bǔ)充 2 條相關(guān)信息。 2. 每條信息必須注明來源無法確認(rèn)的信息標(biāo)為“待確認(rèn)”。 3. 禁止編造統(tǒng)計(jì)數(shù)據(jù)和引用。 輸出格式嚴(yán)格 JSON { facts: [ {section: 對(duì)應(yīng)大綱小節(jié), fact: 事實(shí)內(nèi)容, source: 來源說明, confidence: high/medium/low} ], examples: [可直接使用的示例片段], source_notes: 檢索過程中的補(bǔ)充說明 }5.4 內(nèi)容撰寫 Agent 配置示例內(nèi)容撰寫 Agent 是整個(gè)流程中最核心的角色。它負(fù)責(zé)把大綱和事實(shí)清單轉(zhuǎn)化成一篇可讀性高的技術(shù)文章初稿。你是「內(nèi)容撰寫 Agent」負(fù)責(zé)根據(jù)大綱和資料清單生成結(jié)構(gòu)化技術(shù)文章初稿。 輸入字段 - outline文章大綱 - facts事實(shí)清單 - style寫作風(fēng)格偏好例如“教程式”“筆記式”“工程復(fù)盤式” 處理要求 1. 嚴(yán)格按照 outline 組織章節(jié)結(jié)構(gòu)。 2. 正文中使用 facts 中的事實(shí)不要自行編造。 3. 每個(gè)章節(jié)至少包含一個(gè)可運(yùn)行示例或配置片段。 4. 代碼塊使用 Markdown 格式并標(biāo)注語言。 輸出格式嚴(yán)格 JSON { draft: 完整的 Markdown 格式文章初稿, used_facts: [正文中實(shí)際使用的事實(shí)條目ID] }5.5 審校優(yōu)化 Agent 配置示例審校優(yōu)化 Agent 負(fù)責(zé)最后一道質(zhì)量關(guān)口主要包括結(jié)構(gòu)檢查、事實(shí)核對(duì)、表達(dá)潤(rùn)色、格式規(guī)范。你是「審校優(yōu)化 Agent」負(fù)責(zé)對(duì)技術(shù)文章初稿進(jìn)行質(zhì)量檢查和表達(dá)優(yōu)化。 輸入字段 - draft待審校的文章初稿 - review_rules審校規(guī)則列表例如“標(biāo)題層級(jí)正確”“代碼塊完整”“無重復(fù)段落” 處理要求 1. 先輸出問題清單再輸出優(yōu)化后的全文。 2. 修改時(shí)必須保留原意不改變技術(shù)結(jié)論。 3. 如果初稿引用了“待確認(rèn)”信息必須在問題清單中突出提醒。 輸出格式嚴(yán)格 JSON { issues: [ {type: 結(jié)構(gòu)/事實(shí)/表達(dá)/格式, description: 問題描述, suggestion: 修改建議} ], final_article: 優(yōu)化后的完整 Markdown 文章 }5.6 約定子 Agent 的輸入輸出契約四個(gè)子 Agent 創(chuàng)建完成后建議用一個(gè)統(tǒng)一契約文檔記錄字段定義。即使是個(gè)人項(xiàng)目這個(gè)文檔也能幫你減少調(diào)試時(shí)“字段對(duì)不上”的問題。契約文檔可以用 Markdown 表格維護(hù)放在項(xiàng)目空間的知識(shí)庫或本地代碼倉庫里。后續(xù)新增子 Agent 時(shí)先補(bǔ)充契約再寫提示詞和節(jié)點(diǎn)編排。6. 工作流編排將子 Agent 當(dāng)作工具調(diào)度6.1 創(chuàng)建主工作流創(chuàng)建主工作流后你會(huì)看到一個(gè)畫布左側(cè)是可以拖拽的節(jié)點(diǎn)類型。本案例需要用到以下節(jié)點(diǎn)開始節(jié)點(diǎn)接收用戶輸入。Agent 節(jié)點(diǎn)調(diào)用已創(chuàng)建的子 Agent。并行節(jié)點(diǎn)讓多個(gè) Agent 節(jié)點(diǎn)同時(shí)執(zhí)行。結(jié)束節(jié)點(diǎn)返回最終文章。開始節(jié)點(diǎn)一般需要三個(gè)輸入字段title、keywords、audience。字段類型可以設(shè)置為文本類型并為 audience 設(shè)置一個(gè)默認(rèn)值方便調(diào)試。6.2 字段映射與節(jié)點(diǎn)連接拖入“選題策劃 Agent”節(jié)點(diǎn)后需要把開始節(jié)點(diǎn)的字段映射到該 Agent 的輸入。這里的映射規(guī)則是開始節(jié)點(diǎn).title → 選題策劃Agent 輸入 title 開始節(jié)點(diǎn).keywords → 選題策劃Agent 輸入 keywords 開始節(jié)點(diǎn).audience → 選題策劃Agent 輸入 audience同樣地拖入“資料檢索 Agent”節(jié)點(diǎn)時(shí)需要把開始節(jié)點(diǎn)的 keywords以及選題 Agent 輸出的 outline 作為它的一部分輸入。這里的關(guān)鍵點(diǎn)是字段名必須和子 Agent 提示詞中約定的字段名一致。如果子 Agent 提示詞里寫的是 outline而工作流節(jié)點(diǎn)里傳的是 article_outline就會(huì)導(dǎo)致子 Agent 收到空值。6.3 并行節(jié)點(diǎn)讓兩個(gè)子 Agent 同時(shí)干活在開始節(jié)點(diǎn)之后拖入一個(gè)并行節(jié)點(diǎn)把“選題策劃 Agent”和“資料檢索 Agent”都放進(jìn)并行分支里。需要注意的是資料檢索 Agent 依賴 outline而 outline 是選題策劃 Agent 的輸出。如果嚴(yán)格串行執(zhí)行資料檢索只能等選題完成后才能開始。但在實(shí)際項(xiàng)目中你可以先讓資料檢索 Agent 根據(jù)關(guān)鍵詞做第一輪泛檢索等大綱出來后再補(bǔ)充一次定向檢索。如果暫時(shí)不想做兩輪檢索也可以讓兩者完全并行資料檢索 Agent 只根據(jù)關(guān)鍵詞檢索不依賴大綱。這樣實(shí)現(xiàn)更簡(jiǎn)單適合案例演示。等流程跑通后你再優(yōu)化為兩輪檢索。6.4 用編程思維理解主從調(diào)度如果用偽代碼描述這個(gè)主工作流會(huì)更接近“將子 Agent 當(dāng)作工具”的編程思維main(input) { // 并行執(zhí)行兩個(gè)子Agent類似并發(fā)調(diào)用兩個(gè)工具函數(shù) const outlineResult specAgent.call(input) const searchResult searchAgent.call(input) // 串行執(zhí)行內(nèi)容撰寫 const draft writeAgent.call({ outline: outlineResult.outline, facts: searchResult.facts }) // 串行執(zhí)行審校 const final reviewAgent.call({ draft: draft.draft }) return final }這段偽代碼不是 Coze 里的實(shí)際配置但思維模型完全一致每個(gè)子 Agent 就是一個(gè)可調(diào)用的函數(shù)輸入輸出由契約約束上層只負(fù)責(zé)調(diào)度和匯總。6.5 設(shè)置最終輸出主工作流的結(jié)束節(jié)點(diǎn)需要組合多個(gè)來源的結(jié)果。推薦把審校 Agent 的 final_article 作為返回主體的內(nèi)容同時(shí)把 issues 列表也返回給調(diào)用方方便你判斷是否需要人工介入。如果需要在輸出里追加其他信息可以用一個(gè)代碼節(jié)點(diǎn)做拼接。代碼節(jié)點(diǎn)的用法會(huì)在下一節(jié)詳細(xì)說明。7. 代碼節(jié)點(diǎn)與外部系統(tǒng)集成示例7.1 JavaScript合并多 Agent 結(jié)果當(dāng)并行節(jié)點(diǎn)返回多個(gè)子 Agent 的結(jié)果時(shí)你可能會(huì)想把這些結(jié)果整理成一份摘要方便后面節(jié)點(diǎn)統(tǒng)一處理。這時(shí)可以插入一個(gè) JavaScript 代碼節(jié)點(diǎn)。以下代碼是一個(gè)典型的“合并 格式化”示例// 文件路徑工作流代碼節(jié)點(diǎn) // 輸入parallel_result 并行結(jié)果對(duì)象 function main({ parallel_result }) { const spec parallel_result.spec_agent || {}; const search parallel_result.search_agent || {}; const merged { titles: spec.title_list || [], outline: spec.outline || [], facts: search.facts || [], examples: search.examples || [], }; return { output: JSON.stringify(merged), summary: 已合并選題結(jié)果 ${merged.titles.length} 條資料結(jié)果 ${merged.facts.length} 條, }; }在代碼節(jié)點(diǎn)中main函數(shù)的入?yún)⑹巧嫌喂?jié)點(diǎn)傳入的字段集合返回值會(huì)作為后續(xù)節(jié)點(diǎn)的輸入。建議在調(diào)試時(shí)先打印summary快速確認(rèn)合并結(jié)果是否符合預(yù)期。7.2 Python校驗(yàn)輸出完整性內(nèi)容撰寫 Agent 輸出 draft 后可以在進(jìn)入審校節(jié)點(diǎn)前增加一個(gè)校驗(yàn)節(jié)點(diǎn)避免空文章或字段缺失進(jìn)入下一步。# 文件路徑工作流代碼節(jié)點(diǎn) # 輸入draft_result 由內(nèi)容撰寫Agent返回 def main(draft_result: dict) - dict: draft draft_result.get(draft, ) required_sections [背景, 環(huán)境準(zhǔn)備, 總結(jié)] missing_sections [] for section in required_sections: if section not in draft: missing_sections.append(section) is_valid len(missing_sections) 0 and len(draft) 100 return { is_valid: is_valid, missing_sections: missing_sections, draft_length: len(draft), }這種節(jié)點(diǎn)不直接生成內(nèi)容但能顯著提升工作流的穩(wěn)定性。遇到輸出異常時(shí)你能快速定位是生成環(huán)節(jié)的問題還是契約字段的問題。7.3 調(diào)用外部 API 與敏感信息管理Coze 工作流支持通過 HTTP 請(qǐng)求節(jié)點(diǎn)調(diào)用外部 API。常見的場(chǎng)景包括把生成的文章同步到自己的 CMS、調(diào)用內(nèi)部服務(wù)生成圖片、發(fā)送到飛書群通知等。調(diào)用外部 API 時(shí)建議遵循以下規(guī)范API 地址和請(qǐng)求參數(shù)使用變量管理不要寫死在節(jié)點(diǎn)配置里。密鑰 Token 使用 Coze 的變量或密鑰管理能力不要在提示詞、代碼和日志中明文展示。外部接口調(diào)用失敗時(shí)增加錯(cuò)誤分支或重試機(jī)制而不是讓工作流直接失敗。請(qǐng)求第三方服務(wù)前確認(rèn)對(duì)方接口的授權(quán)范圍和調(diào)用限制避免觸發(fā)越權(quán)或?yàn)E用風(fēng)險(xiǎn)。由于 Coze 的開放 API 地址在不同地域和版本中存在差異具體請(qǐng)求地址、鑒權(quán)方式和參數(shù)格式請(qǐng)以當(dāng)前 Coze 平臺(tái)的接口文檔為準(zhǔn)示例只是通用思路。7.4 擴(kuò)展Markdown 轉(zhuǎn) Word 或 PPT很多技術(shù)博主會(huì)希望把生成的文章直接導(dǎo)出成 Word 或 PPT。在 Coze 中實(shí)現(xiàn)這類轉(zhuǎn)換一般走兩種思路用代碼節(jié)點(diǎn)實(shí)現(xiàn)轉(zhuǎn)換但要先確認(rèn)代碼節(jié)點(diǎn)的運(yùn)行環(huán)境是否包含對(duì)應(yīng)的轉(zhuǎn)換庫。不同迭代版本中運(yùn)行環(huán)境支持情況不一樣需要以實(shí)際環(huán)境為準(zhǔn)。將 Agent 輸出格式統(tǒng)一為規(guī)范 Markdown再通過外部轉(zhuǎn)換服務(wù)或插件把 Markdown 轉(zhuǎn)成 docx、pptx。更推薦第二種思路。因?yàn)?Agent 負(fù)責(zé)生成內(nèi)容轉(zhuǎn)換任務(wù)交給更穩(wěn)定的確定性服務(wù)職責(zé)邊界更清晰。如果以后要接入文章發(fā)布平臺(tái)這種設(shè)計(jì)也能復(fù)用同一套內(nèi)容流。8. 調(diào)試、測(cè)試與發(fā)布8.1 在調(diào)試面板中逐節(jié)點(diǎn)驗(yàn)證工作流創(chuàng)建完成后先在調(diào)試面板中運(yùn)行一次。建議用真實(shí)輸入測(cè)試?yán)鐦?biāo)題Spring Boot 整合 Apollo 配置中心實(shí)戰(zhàn) 關(guān)鍵詞Spring Boot, Apollo, 配置中心 目標(biāo)讀者有 Spring Boot 基礎(chǔ)的后端開發(fā)者運(yùn)行后逐個(gè)點(diǎn)擊節(jié)點(diǎn)查看輸入輸出。你可以發(fā)現(xiàn)哪些節(jié)點(diǎn)輸出異常是提示詞問題還是字段映射問題。需要注意Coze 工作流的調(diào)試面板通常會(huì)記錄每個(gè)節(jié)點(diǎn)的詳細(xì)運(yùn)行日志你應(yīng)養(yǎng)成“先看日志、再改配置”的習(xí)慣。日志里的報(bào)錯(cuò)信息遠(yuǎn)比表面現(xiàn)象更有排查價(jià)值。8.2 避免輸出格式漂移的調(diào)試技巧大模型輸出的格式不穩(wěn)定是多 Agent 工作流最常見的問題。即使提示詞里寫了“嚴(yán)格 JSON”偶爾還會(huì)出現(xiàn)多余的解釋文本。解決思路有三個(gè)在提示詞中給出一個(gè)“最小示例”模型會(huì)更容易模仿。在代碼節(jié)點(diǎn)中增加解析容錯(cuò)邏輯比如用正則提取 JSON 片段后解析。把“格式校驗(yàn)”作為一個(gè)獨(dú)立節(jié)點(diǎn)校驗(yàn)不通過時(shí)走分支重新生成。不要指望提示詞一次寫完美多輪調(diào)試是正常的。建議把調(diào)試過程中調(diào)整過的提示詞版本記錄下來方便對(duì)比效果。8.3 發(fā)布到 WebApp 或 API流程調(diào)通后可以發(fā)布到 WebApp得到一個(gè)可分享的網(wǎng)頁鏈接適合內(nèi)部測(cè)試或給非技術(shù)人員體驗(yàn)。如果希望外部系統(tǒng)調(diào)用這條多 Agent 流程需要了解平臺(tái)提供的開放接口能力。發(fā)布后通常需要配置 API Token并在請(qǐng)求中攜帶 Bot ID 或工作流 ID。調(diào)用方身份、請(qǐng)求頻率、數(shù)據(jù)范圍都需要在平臺(tái)側(cè)做好限制。發(fā)布到生產(chǎn)環(huán)境前建議再檢查一遍是否測(cè)試過異常輸入密鑰是否已經(jīng)替換為生產(chǎn)變量知識(shí)庫版本是否最新這些檢查項(xiàng)看起來基礎(chǔ)卻能避免線上事故。9. 常見問題與排查9.1 高頻問題速查表問題現(xiàn)象常見原因解決思路子 Agent 節(jié)點(diǎn)長(zhǎng)時(shí)間無響應(yīng)子 Agent 內(nèi)部工作流復(fù)雜或模型響應(yīng)慢精簡(jiǎn)提示詞、更換更快模型、降低并行 Agent 數(shù)量輸出 JSON 格式不穩(wěn)定提示詞約束不夠或沒有提供示例補(bǔ)充輸出示例增加格式校驗(yàn)節(jié)點(diǎn)工作流返回字段為空字段映射錯(cuò)誤或子 Agent 輸出字段名不一致檢查提示詞中的字段名與節(jié)點(diǎn)映射是否一致資料檢索內(nèi)容偏少搜索關(guān)鍵詞太少或知識(shí)庫未正確配置增加同義詞關(guān)鍵詞檢查知識(shí)庫分段方式文章風(fēng)格不符合預(yù)期寫作風(fēng)格字段傳空或默認(rèn)值不合理在變量中配置默認(rèn)風(fēng)格并在子 Agent 提示詞中強(qiáng)化風(fēng)格要求9.2 典型問題詳細(xì)排查如果你遇到“內(nèi)容撰寫 Agent 生成的文章引用來源是編造的”需要重點(diǎn)排查資料檢索 Agent 的輸出。事實(shí)核查通常不能只靠“審校優(yōu)化 Agent”自己判斷因?yàn)閷徯?Agent 也無法知道哪些信息是真實(shí)的。更穩(wěn)妥的方案是在資料檢索 Agent 中強(qiáng)制輸出 source 和 confidence 字段在內(nèi)容撰寫 Agent 中提示“只允許使用 facts 中 confidence 為 high 的信息”。這樣可以在源頭控制風(fēng)險(xiǎn)而不是等到最后再糾錯(cuò)。如果遇到“工作流運(yùn)行失敗但日志顯示每個(gè)節(jié)點(diǎn)都成功”則問題大概率出在節(jié)點(diǎn)間的返回值傳遞上。你可以在代碼節(jié)點(diǎn)中增加 try-catch把異常信息轉(zhuǎn)為工作流輸出避免失敗原因被吞掉。10. 最佳實(shí)踐與工程建議10.1 從單 Agent 到多 Agent 的遷移路徑不建議新項(xiàng)目直接堆五個(gè)子 Agent。即使你理解了多 Agent 的好處也應(yīng)該控制復(fù)雜度。推薦路徑是先用一個(gè) Agent 跑通主流程。找到最容易出問題的環(huán)節(jié)把它拆成獨(dú)立子 Agent。驗(yàn)證拆分后效果確實(shí)提升再繼續(xù)拆分下一個(gè)環(huán)節(jié)。多 Agent 不是越多越好。每個(gè)子 Agent 都意味著一次額外的大模型調(diào)用成本和一次出錯(cuò)風(fēng)險(xiǎn)。只有當(dāng)一個(gè)環(huán)節(jié)因?yàn)椤敖巧?fù)擔(dān)過重”而明顯影響質(zhì)量時(shí)才值得單獨(dú)拆出來。10.2 子 Agent 契約與提示詞管理把提示詞當(dāng)成代碼來管理。為每個(gè) Agent 維護(hù)獨(dú)立的版本記錄修改時(shí)間和修改原因。子 Agent 的輸入輸出契約要像接口文檔一樣明確。尤其是項(xiàng)目進(jìn)入多人協(xié)作階段后契約不清晰會(huì)造成大量返工。一個(gè)人約定了 camelCase另一個(gè)人用了 snake_case兩個(gè) Agent 對(duì)接時(shí)自然失敗。10.3 成本、性能與模型選型多 Agent 工作流的成本由兩部分組成模型調(diào)用次數(shù)和單次調(diào)用 token 量?？刂瞥杀镜某Ｓ檬侄伟懿⑿械娜蝿?wù)盡量并行減少等待時(shí)間。簡(jiǎn)單任務(wù)使用更快、更便宜的模型復(fù)雜推理任務(wù)才使用更強(qiáng)模型。盡量向子 Agent 傳遞最小化文本避免把整篇長(zhǎng)文重復(fù)傳給每個(gè)子 Agent。緩存重復(fù)查詢的結(jié)果比如知識(shí)庫檢索結(jié)果避免多次調(diào)用大模型。在 Coze 中不同模型的上下文長(zhǎng)度和計(jì)費(fèi)方式有差異。你要根據(jù)任務(wù)復(fù)雜度選擇合適的模型而不是所有 Agent 都默認(rèn)用最強(qiáng)的模型。10.4 安全、權(quán)限與發(fā)布規(guī)范多 Agent 系統(tǒng)涉及多個(gè)子 Agent 和外部資源安全邊界需要格外注意。操作規(guī)范如下敏感 Token 不進(jìn)入提示詞、代碼節(jié)點(diǎn)或日志。子 Agent 不需要的知識(shí)庫和插件不要綁定給它遵循最小權(quán)限原則。發(fā)布到公開 WebApp 前先確認(rèn)是否有信息泄露風(fēng)險(xiǎn)。涉及外部 API 寫入操作時(shí)先在小范圍測(cè)試環(huán)境中驗(yàn)證確認(rèn)無誤后再開放生產(chǎn)權(quán)限。如果工作流涉及用戶上傳的文檔或數(shù)據(jù)要確保數(shù)據(jù)使用范圍符合平臺(tái)規(guī)則和你的合規(guī)要求。10.5 版本管理與灰度發(fā)布Coze 平臺(tái)迭代很快智能體發(fā)布和版本管理能力會(huì)逐步增強(qiáng)。即使當(dāng)前用的是簡(jiǎn)單流程也應(yīng)該保持“先測(cè)試、再發(fā)布”的習(xí)慣。建議按照“開發(fā)空間 → 測(cè)試空間 → 生產(chǎn)空間”的思路來組織項(xiàng)目空間。開發(fā)階段可以隨意調(diào)試測(cè)試空間驗(yàn)證完整流程生產(chǎn)空間只承載穩(wěn)定版本。當(dāng)你調(diào)整了某個(gè)子 Agent 的提示詞后先在測(cè)試空間跑一遍典型用例觀察是否會(huì)影響到其他環(huán)節(jié)的輸出。不要為了節(jié)省時(shí)間而跳過回歸測(cè)試。11. 總結(jié)與學(xué)習(xí)路線這篇文章從單智能體的能力瓶頸出發(fā)介紹了多 Agent 協(xié)作的三種核心模式重點(diǎn)講解了“將子 Agent 當(dāng)作另類工具”的主從調(diào)度思想。接著用一個(gè)技術(shù)文章創(chuàng)作團(tuán)隊(duì)案例帶你走通了項(xiàng)目空間配置、四個(gè)子 Agent 的創(chuàng)建、主工作流編排、代碼節(jié)點(diǎn)調(diào)試、發(fā)布以及常見問題排查。下一步你可以嘗試把這個(gè)方案復(fù)用到自己的場(chǎng)景里。比如構(gòu)建一個(gè)“AI 軟件測(cè)試工作臺(tái)”拆解出測(cè)試設(shè)計(jì) Agent、測(cè)試執(zhí)行 Agent、缺陷分析 Agent 和報(bào)告生成 Agent整體設(shè)計(jì)邏輯和本文案例幾乎一致。也可以做“PPT 生成工作流”讓選題 Agent 負(fù)責(zé)拆大綱內(nèi)容 Agent 負(fù)責(zé)輸出每頁要點(diǎn)再由外部插件渲染成 PPT 文件。建議你先從兩個(gè)子 Agent 的小實(shí)驗(yàn)開始調(diào)通之后再逐步增加角色。過程中重點(diǎn)觀察兩件事子 Agent 的輸出質(zhì)量是否真的因?yàn)榉止ざ嵘约罢w耗時(shí)和成本是否處于可接受范圍。多 Agent 協(xié)作不是銀彈但它確實(shí)是突破單智能體能力局限的一條有效路徑。如果你在 Coze 上折騰多 Agent 時(shí)卡在某個(gè)環(huán)節(jié)歡迎留言交流。