你用大語(yǔ)言模型做會(huì)議摘要時(shí)，很可能只發(fā)了一輪對(duì)話。一個(gè)提示詞塞進(jìn)去：這是會(huì)議記錄，給我一個(gè)摘要、把行動(dòng)項(xiàng)拎出來(lái)、再告訴我每個(gè)人的情緒怎么樣。一次調(diào)用，一個(gè)模型，返回一大塊文字。演示跑通了，一到真實(shí)會(huì)議記錄就掛。這三個(gè)任務(wù)形狀完全不同。摘要是流暢的段落，行動(dòng)項(xiàng)是帶責(zé)任人的嚴(yán)格列表，情緒判斷要給每個(gè)發(fā)言人一個(gè)結(jié)論。把它們擠在一個(gè)提示詞里，它們會(huì)互相打架——模型把摘要的句子塞進(jìn)行動(dòng)項(xiàng)，或者忘記標(biāo)注發(fā)言人，或者返回的行動(dòng)項(xiàng)是一段需要你手動(dòng)解析的文本。你還為所有內(nèi)容串行付費(fèi)，得到的是非結(jié)構(gòu)化文本，而你想要的有一半是結(jié)構(gòu)化數(shù)據(jù)。

更干凈的形狀是這樣：跑三個(gè)專(zhuān)職代理，每個(gè)只做一件事，每個(gè)用自己的溫度參數(shù)，其中兩個(gè)返回的是有類(lèi)型的對(duì)象，而不是自然語(yǔ)言。而且它們同時(shí)運(yùn)行，因?yàn)檎l(shuí)也不需要等別人的輸出。最后，第四個(gè)代理把三個(gè)結(jié)果合并成一份報(bào)告。這篇文章就搭建這么一個(gè)系統(tǒng)，素材來(lái)自 open-multi-agent 項(xiàng)目里的會(huì)議摘要入門(mén)示例。整個(gè)實(shí)現(xiàn)大約 280 行 TypeScript，并行是它的核心。

最終產(chǎn)出的是一份形狀固定的 Markdown 報(bào)告：一段散文化的摘要，一張行動(dòng)項(xiàng)表格，逐人的情緒判斷，以及歸納出的下一步安排。這里展示的是針對(duì)一段 21 行的工程站會(huì)記錄實(shí)際運(yùn)行后得到的行動(dòng)項(xiàng)部分——每一行都是作為有類(lèi)型數(shù)據(jù)返回的，而不是腳本還需要去解析的散文。

這份完整報(bào)告還帶著三段式的摘要、按發(fā)言人的情緒解讀，以及一個(gè)歸納出來(lái)的“下一步動(dòng)作”清單。所有這些內(nèi)容由四個(gè)代理生成，其中三個(gè)是并發(fā)運(yùn)行的。接下來(lái)就拆解它是怎么接線的。

三個(gè)專(zhuān)職代理接收同一份會(huì)議記錄。每個(gè)專(zhuān)職代理都是一個(gè)普通的 Agent，擁有自己的系統(tǒng)提示詞和溫度值。先從摘要代理講起——它輸出的是散文，沒(méi)有模式約束，溫度略高，好讓文字讀起來(lái)自然。配置代碼大致是：
名稱(chēng)設(shè)置為 ‘summary’，模型是 ‘claude-sonnet-4-6’，系統(tǒng)提示詞寫(xiě)的是：“你是一個(gè)會(huì)議記錄員。給你一份會(huì)議記錄，生成一個(gè)三段式摘要：1. 討論了什么（議程）；2. 做出的決定；3. 團(tuán)隊(duì)需要記住的重要背景或風(fēng)險(xiǎn)。純散文，不要列表要點(diǎn)。總共 200-300 詞。”允許的最大對(duì)話輪次是 1，溫度設(shè)為 0.3。

另外兩個(gè)專(zhuān)職代理讓這套方案從“給大模型打三次電話”變成了可靠的工程管道：它們返回的是有類(lèi)型的對(duì)象，不是文本。你聲明一個(gè) Zod 模型，把它作為 outputSchema 交給代理，然后從 result.structured 上讀取解析好的結(jié)果。

行動(dòng)項(xiàng)是一個(gè)列表，而且每一條必須攜帶責(zé)任人。截止日期是可選的，因?yàn)檎鎸?shí)的會(huì)議很多時(shí)候不會(huì)明確提及日期。對(duì)應(yīng)的模式定義是：一個(gè)對(duì)象，其中 items 是一個(gè)數(shù)組，數(shù)組里每個(gè)元素包含一個(gè)用字符串描述的任務(wù)（“要采取的行動(dòng)”）和一個(gè)字符串代表的責(zé)任人。這些字段都有相應(yīng)的 .describe() 注釋來(lái)指導(dǎo)模型生成。

情緒判斷專(zhuān)職代理同樣返回一個(gè)結(jié)構(gòu)化結(jié)果。它為每個(gè)發(fā)言人輸出一個(gè)情緒標(biāo)簽，并且可以附帶一句簡(jiǎn)短的評(píng)估。模式可能是每個(gè)發(fā)言人的名字映射到一個(gè)情緒對(duì)象，或者是一個(gè)發(fā)言人數(shù)組，其中包含名字、情緒值以及置信度或依據(jù)。這個(gè)模式會(huì)迫使模型對(duì)每個(gè)發(fā)言人做出一個(gè)判斷，而不是在段落里泛泛地提幾句“氣氛積極”。

三個(gè)代理各拿一份相同的會(huì)議記錄，各自獨(dú)立工作。摘要代理用 0.3 的溫度產(chǎn)出自然段落；行動(dòng)項(xiàng)代理用更低的溫度（比如 0.1）來(lái)保證結(jié)構(gòu)的嚴(yán)格性；情緒代理則可能用適中的溫度（比如 0.2），在標(biāo)簽判定上既保持穩(wěn)定又允許一定靈活性。由于它們互不依賴(lài)，可以在同一個(gè)時(shí)間窗口內(nèi)同時(shí)發(fā)起請(qǐng)求，而不是一個(gè)接一個(gè)地等待。

第四個(gè)代理負(fù)責(zé)合并。它接收其它三個(gè)代理已經(jīng)處理好的結(jié)構(gòu)化結(jié)果和摘要文本，以自己的系統(tǒng)提示詞和輸出模式，生成最終的報(bào)告。在這個(gè)合并階段，摘要的散文可以直接拼接，行動(dòng)項(xiàng)列表可以規(guī)范化為 Markdown 表格，逐人情緒可以按發(fā)言人在表格中呈現(xiàn)，而下一步動(dòng)作則是綜合行動(dòng)項(xiàng)和情緒的新推斷。合并代理的模式也聲明為 Zod 對(duì)象，包含摘要字符串、行動(dòng)項(xiàng)數(shù)組、情緒數(shù)組、下一步數(shù)組等字段，這樣報(bào)告的結(jié)構(gòu)就被鎖死。

這種設(shè)計(jì)解決了一個(gè)關(guān)鍵困境：當(dāng)你讓一個(gè)提示詞同時(shí)干三件事，就必須面對(duì)非結(jié)構(gòu)化輸出和結(jié)構(gòu)化需求之間的矛盾。通過(guò)把每個(gè)子任務(wù)拆成專(zhuān)職代理，并且對(duì)需要結(jié)構(gòu)的部分顯式地聲明 Zod 模式，你從大模型那里拿到的就不再是需要后續(xù)用正則去抓取的模糊文本，而是可以直接用的對(duì)象。摘要任務(wù)仍然保持散文形式，因?yàn)樗烊贿m合散文；而行動(dòng)項(xiàng)和情緒則變成可以被下拉菜單、數(shù)據(jù)庫(kù)直接消費(fèi)的數(shù)據(jù)行。

并行的意義不止于縮短端到端耗時(shí)。它還讓每個(gè)專(zhuān)職代理的溫度調(diào)優(yōu)變得獨(dú)立可控。摘要需要一定創(chuàng)造性，用它 0.3 的溫度；行動(dòng)項(xiàng)要絕對(duì)精確，用接近 0 的溫度；情緒判斷介于兩者之間。如果把它們混在一個(gè)提示詞里，你只能設(shè)置一個(gè)統(tǒng)一的溫度，這就必然在某些子任務(wù)上妥協(xié)。拆開(kāi)之后，你可以為每個(gè)子任務(wù)精確設(shè)置生成參數(shù)，而且因?yàn)椴l(fā)執(zhí)行，并不會(huì)增加總等待時(shí)間。

這段實(shí)現(xiàn)只有大約 280 行 TypeScript，核心部分是用 open-multi-agent 框架定義 Agent 配置并跑起一個(gè)多代理工作流。每個(gè) Agent 的定義都集中在幾個(gè)關(guān)鍵字段：名字、模型、系統(tǒng)提示詞、maxTurns、溫度，以及對(duì)于要返回結(jié)構(gòu)化數(shù)據(jù)的代理，還要加上 outputSchema。這些配置對(duì)象隨后被一個(gè)編排器一次性啟動(dòng)，編排器負(fù)責(zé)向大模型服務(wù)發(fā)送請(qǐng)求并收集結(jié)果。三個(gè)代理同時(shí)跑，等到全部返回后，再觸發(fā)合并代理。合并代理拿到摘要文本、行動(dòng)項(xiàng)數(shù)組、情緒數(shù)組，以及原始的會(huì)議記錄，然后按照最終報(bào)告的模式組裝輸出。

真實(shí)運(yùn)行在一段 21 行的工程站會(huì)記錄上的結(jié)果顯示了這種模式的穩(wěn)定性。返回的行動(dòng)項(xiàng)列表每一條都有清晰的任務(wù)描述和責(zé)任人，沒(méi)有任何多余的文字需要?jiǎng)冸x。摘要部分三個(gè)段落分別覆蓋議程、決定和風(fēng)險(xiǎn)，字?jǐn)?shù)控制在 200-300 之間，不會(huì)出現(xiàn)突然膨脹到一大段的情況。情緒部分則為每位發(fā)言人帶來(lái)了一個(gè) verdict，不會(huì)遺漏誰(shuí)，也不會(huì)把幾個(gè)人的感受混在一起說(shuō)。這些都是結(jié)構(gòu)化約束帶來(lái)的直接好處。

在工程層面，這種做法還引入了一個(gè)重要的副產(chǎn)品：失敗隔離。如果摘要生成因?yàn)樯舷挛奶L(zhǎng)而失敗，行動(dòng)項(xiàng)和情緒提取依然可以成功，因?yàn)樗鼈冞\(yùn)行在獨(dú)立的請(qǐng)求里。你不需要為了一個(gè)子任務(wù)的崩潰而重新跑整個(gè)管線，可以針對(duì)出錯(cuò)的專(zhuān)職代理重試，而其他部分保持不變。在串行單提示詞的方案中，任何一部分的異常都意味著整個(gè)調(diào)用需要重來(lái)，浪費(fèi)了之前已生成的所有內(nèi)容和相應(yīng)的計(jì)算資源。

另外，成本模型也變得更清晰。你可以為不同的專(zhuān)職代理選用不同能力的模型，例如摘要用強(qiáng)寫(xiě)作能力的大模型，行動(dòng)項(xiàng)和情緒判別用輕量且推理快的模型，合并用中等模型。這樣每一分錢(qián)都不浪費(fèi)在不對(duì)口的子任務(wù)上。在單提示詞方案里，你往往只能為了滿足最難的那個(gè)子任務(wù)而選擇一個(gè)整體更貴的模型，然后讓它在簡(jiǎn)單部分空轉(zhuǎn)。

這套架構(gòu)的復(fù)用性也很高。一旦你把行動(dòng)項(xiàng)、摘要、情緒這三個(gè)代理的配置抽象成可組合的模塊，就可以用類(lèi)似的骨架去搭建復(fù)盤(pán)助手、客戶(hù)訪談分析工具，或者醫(yī)療記錄結(jié)構(gòu)化流水線。只要遵循“分拆子任務(wù)、聲明輸出結(jié)構(gòu)、并發(fā)執(zhí)行、最后合并”的原則，就能把原本只能產(chǎn)出散文的大模型管道，改造成同時(shí)產(chǎn)出結(jié)構(gòu)化數(shù)據(jù)和自然語(yǔ)言文本的混合系統(tǒng)。

從開(kāi)發(fā)者的角度看，280 行 TypeScript 里，真正花在業(yè)務(wù)邏輯上的并不多。大量的行數(shù)用來(lái)聲明 Zod 模式、定義 Agent 配置對(duì)象，以及拼接合并邏輯。這些代碼可讀性極高，幾乎就是在用一種配置語(yǔ)言描述業(yè)務(wù)規(guī)則。相比在單提示詞里靠話術(shù)去約束輸出格式——比如反復(fù)強(qiáng)調(diào)“請(qǐng)務(wù)必以 JSON 格式返回”——用模式聲明的方式更不易漂移，因?yàn)榇竽Ｐ驮谶@個(gè)模式下受到更強(qiáng)的結(jié)構(gòu)誘導(dǎo)，而不是單純依賴(lài)提示詞里的文字請(qǐng)求。

會(huì)議摘要這個(gè)場(chǎng)景天然地暴露了混合輸出的痛點(diǎn)。人們?cè)跁?huì)議里產(chǎn)生的信息是多模態(tài)的：有討論的脈絡(luò)（適合散文）、有待辦的責(zé)任劃分（適合表格）、有氣氛和態(tài)度（適合標(biāo)簽或打分）。如果堅(jiān)持用一個(gè)提示詞一次性全部輸出，就必須在后續(xù)用解析器去提取。而解析器脆弱，只要模型稍微變動(dòng)措辭，格式就可能走樣。用并行專(zhuān)職代理加模式聲明，從根本上把下游的解析負(fù)擔(dān)往前移，讓大模型自己把結(jié)構(gòu)化部分按要求打包好，下游只需要做校驗(yàn)和組裝。

這種“多代理、有類(lèi)型輸出”的方式，并不是在否定單一提示詞的簡(jiǎn)單場(chǎng)景。如果你只是偶爾處理一個(gè)短會(huì)議，并且能夠接受一點(diǎn)后續(xù)的人工格式化，那么一個(gè)提示詞仍然是最省事的。但當(dāng)你的系統(tǒng)需要批量處理每天幾十場(chǎng)會(huì)議記錄，并且要把行動(dòng)項(xiàng)自動(dòng)同步到項(xiàng)目管理工具，把情緒統(tǒng)計(jì)匯總到團(tuán)隊(duì)健康儀表盤(pán)時(shí)，穩(wěn)定可靠的結(jié)構(gòu)化輸出就成了剛需。那時(shí)候，把這 280 行代碼放進(jìn)你的管線，所帶來(lái)的可靠性提升，會(huì)遠(yuǎn)比每次祈禱模型不要亂寫(xiě)格式要?jiǎng)澦恪?/p>

此外，并行化對(duì)某些部署環(huán)境還有額外好處。在一些 serverless 平臺(tái)或邊緣運(yùn)行時(shí)中，同時(shí)對(duì)大模型服務(wù)發(fā)起多個(gè)請(qǐng)求，可以利用連接池和并發(fā)處理能力來(lái)攤薄延遲。如果你用串行調(diào)用，網(wǎng)絡(luò)往返時(shí)間的累加會(huì)讓總耗時(shí)變得很高；并行之后，只要最慢的那個(gè)代理返回，整個(gè)階段就結(jié)束。對(duì)于只有幾秒差距的任務(wù)，并行幾乎能讓三個(gè)代理的花費(fèi)等同于一個(gè)代理的時(shí)長(zhǎng)。這對(duì)于需要準(zhǔn)實(shí)時(shí)反饋的交互式產(chǎn)品，比如用戶(hù)在會(huì)議結(jié)束后立刻想看到摘要的場(chǎng)景，就顯得十分關(guān)鍵。

關(guān)于提示詞設(shè)計(jì)，這里也暴露出一個(gè)常見(jiàn)反模式。很多人在寫(xiě)提示詞時(shí)會(huì)試圖用一個(gè)“全能型”角色描述，比如“你是一個(gè)專(zhuān)業(yè)的會(huì)議記錄和分析師，請(qǐng)總結(jié)會(huì)議并提取行動(dòng)項(xiàng)并評(píng)估情緒”。這種復(fù)合角色讓模型的注意力在幾個(gè)互斥的目標(biāo)之間游移，尤其在長(zhǎng)上下文中，模型容易遺漏結(jié)構(gòu)要求。拆成三個(gè)單一職責(zé)的角色，每個(gè)只用關(guān)注自己那部分，相當(dāng)于給模型減輕了認(rèn)知負(fù)載。這在長(zhǎng)會(huì)議記錄的處理中表現(xiàn)得尤為明顯——當(dāng)記錄超過(guò)幾千字時(shí)，單一提示詞丟失信息的概率明顯上升。

將這個(gè)思路推及到其他領(lǐng)域，比如代碼審查。你可以把一次 PR 審查拆成幾個(gè)并行代理：一個(gè)專(zhuān)職檢查代碼風(fēng)格和命名規(guī)范，一個(gè)檢查潛在的錯(cuò)誤模式和安全漏洞，一個(gè)總結(jié)改動(dòng)意圖和影響范圍，最后一個(gè)合并成審查意見(jiàn)。每個(gè)代理可以獨(dú)立使用不同的靜態(tài)分析提示或知識(shí)庫(kù)，溫度也可以分別配置。最終產(chǎn)出既有散文式的總結(jié)，也有列表式的具體建議，還有關(guān)于風(fēng)險(xiǎn)的結(jié)構(gòu)化字段。相比于一個(gè)龐大提示詞，這種架構(gòu)更容易維護(hù)和調(diào)優(yōu)。

回到會(huì)議摘要系統(tǒng)本身，它的輸出模式定義其實(shí)比表面看起來(lái)更講究。行動(dòng)項(xiàng)模式里 owner 字段的 .describe() 注釋是“行動(dòng)的責(zé)任人”，這促使模型從會(huì)議記錄中提取出具體姓名或角色，而不是填“團(tuán)隊(duì)”。如果會(huì)議記錄中出現(xiàn)了“我來(lái)跟進(jìn)這個(gè)”這樣的表述，模型需要將它映射到發(fā)言人的名字上，這就要求在系統(tǒng)提示詞中配合給出映射規(guī)則或者至少提示模型注意人稱(chēng)與發(fā)言人的關(guān)系。這些細(xì)節(jié)不是在代碼里寫(xiě)死的業(yè)務(wù)邏輯，而是通過(guò)提示詞和模式描述傳遞給模型的信號(hào)，其有效性依賴(lài)于模型對(duì)這些指令的理解和執(zhí)行。而這只有在子任務(wù)足夠單一的情況下，模型才能更可靠地完成。

情緒分析代理的模式設(shè)計(jì)也需要斟酌。單純輸出一個(gè)情緒標(biāo)簽（如“正面”“負(fù)面”“中性”）可能丟信息。增加一個(gè)可選的理由字段，比如“情緒理由”，可以讓模型同時(shí)輸出它做出該判斷的依據(jù)，比如“提到了項(xiàng)目延期，語(yǔ)氣沮喪”。這個(gè)理由字段不是給最終報(bào)告直接展示的，而是可以用于后續(xù)審計(jì)或者增強(qiáng)對(duì)情緒判斷的可解釋性。由于它是結(jié)構(gòu)化的，你可以自由選擇是否在合并階段保留它。結(jié)構(gòu)化輸出的靈活性就在這里——你有明確的字段，但可以決定顯示哪些。

合并代理的生成邏輯其實(shí)遵循一個(gè)固定模板，但又不完全是死板的字符串拼接。它被要求綜合三個(gè)子任務(wù)的結(jié)果來(lái)生成“下一步動(dòng)作”。這個(gè)步驟利用了模型的一點(diǎn)推理能力：如果一個(gè)行動(dòng)項(xiàng)截至日期很緊，而相關(guān)責(zé)任人的情緒顯示壓力大，合并代理可能會(huì)在下一步建議中增加“檢查是否有阻塞項(xiàng)”之類(lèi)的提醒。這種跨子結(jié)果的關(guān)聯(lián)推理，在單一提示詞方案中也許能自發(fā)產(chǎn)生，但沒(méi)有保障；在并行專(zhuān)用代理架構(gòu)中，因?yàn)榍懊嬉呀?jīng)把每部分的可靠結(jié)構(gòu)結(jié)果穩(wěn)定下來(lái)，再喂給合并代理，它有了干凈的輸入，產(chǎn)生這種關(guān)聯(lián)判斷的成功率就更高。

最后看一下這個(gè)項(xiàng)目的出處：open-multi-agent 的會(huì)議摘要示例。它是一個(gè)展示多代理并發(fā)和結(jié)構(gòu)化輸出的 cookbook。280 行 TypeScript 證明了這類(lèi)系統(tǒng)并不需要龐大的框架。只要用好框架提供的 Agent 配置接口和 outputSchema 能力，平時(shí)用大模型干活的工程師可以很快上手改造自己的流水線。很多團(tuán)隊(duì)其實(shí)都在遭受“一次提示詞輸出混合內(nèi)容”的折磨，他們可能已經(jīng)寫(xiě)了不少正則或自定義解析器，但還是時(shí)不時(shí)被模型輸出的格式變化絆倒。轉(zhuǎn)向把每個(gè)任務(wù)拆開(kāi)、顯式聲明模式的方式，原則上只要照著示例把業(yè)務(wù)模型替換掉，就能把不穩(wěn)定的管道變牢靠。

所以回到標(biāo)題：你的會(huì)議摘要工具可能正在一個(gè)提示詞里悄悄地做三份工作，而這三份工作在互相拖后腿。用三個(gè)并行的專(zhuān)職代理，各司其職