1. 項目定位與整體思路拆解1.1 agency-agents到底是什么從單Agent到多智能體協(xié)作agency-agents這個項目名如果你拆開看很有意思。agency既指代理機(jī)構(gòu)也有中介、主辦方的意思agents則是智能體。agency-agents合在一起本質(zhì)上就是一個把多個AI智能體組織成虛擬團(tuán)隊的協(xié)作框架。與單純接一個大模型API、讓它在單次對話里完成任務(wù)不同這個項目要解決的是如何把一群各有專長的AI員工像管理真實團(tuán)隊一樣編排起來讓它們各司其職、互相配合最終交付一個復(fù)雜的成果。我用這個框架的初衷很樸素單Agent在稍復(fù)雜的任務(wù)上真的會翻車。舉個例子我曾經(jīng)試圖讓一個Agent獨立完成收集市場數(shù)據(jù) → 分析競品 → 輸出調(diào)研報告這條完整鏈路。前十分鐘它表現(xiàn)得像個專家等它處理到第三四個環(huán)節(jié)時開始出現(xiàn)生成質(zhì)量明顯下滑、遺忘前面關(guān)鍵結(jié)論、甚至把一個環(huán)節(jié)的結(jié)論錯誤復(fù)用到另一個環(huán)節(jié)的情況。這不是模型能力不夠而是單線程上下文的天然短板——一個Agent既要記著最初的目標(biāo)又要處理當(dāng)下的子任務(wù)還要兼顧中間所有步驟的中間結(jié)論任何一個細(xì)小的注意力偏移都會讓整個鏈路崩掉。Agency-agents的解法是把一個大而全的Agent拆成多個小而專的Agent中間通過一個調(diào)度層連接。每個Agent只負(fù)責(zé)鏈路里的一個環(huán)節(jié)它的上下文只包含自己這一步該看的輸入和需要輸出的結(jié)果干凈、清晰、無干擾。這樣一來每個環(huán)節(jié)的執(zhí)行質(zhì)量都被拉高了整體交付的可靠性自然就上來了。這個概念不管你是做AI應(yīng)用開發(fā)的工程師、正在規(guī)劃企業(yè)級AI方案的技術(shù)負(fù)責(zé)人、還是對智能體自動化感興趣的產(chǎn)品經(jīng)理都建議你認(rèn)真了解一下——因為它代表了一種把大模型能力落地成可用系統(tǒng)的關(guān)鍵思路。多智能體這個概念近兩年借著agents anywhere這股熱度被反復(fù)討論但真正能把多Agent協(xié)作做成穩(wěn)定、可調(diào)試、可上線的系統(tǒng)不是給一堆Agent發(fā)個群聊就完事。它背后涉及角色分配、消息傳遞、狀態(tài)管理、上下文隔離、異常熔斷這些工程問題——這也是我寫這篇文章的原因我把自己踩過的坑、驗證過的實踐路徑完整拆出來供你參考。1.2 為什么不是一條提示詞解決所有問題做技術(shù)分享的時候經(jīng)常有人問我我為什么不干脆寫一條巨長的提示詞把所有要求塞進(jìn)去一次性讓模型輸出全部結(jié)果說實話這是一種典型的可行但不可持續(xù)的方案。單條超長提示詞的本質(zhì)是讓模型在一次推理里同時完成理解、拆分、執(zhí)行、校驗所有動作這等于讓一個員工同時扮演產(chǎn)品經(jīng)理、數(shù)據(jù)分析師、文案寫手和質(zhì)檢員。這個員工確實什么都會一點但每一項都做得一般而且一旦某個環(huán)節(jié)出問題你幾乎無法定位到底是哪個步驟錯了。我印象很深的一次實驗我用一條提示詞讓模型生成一份市場進(jìn)入策略報告結(jié)果模型在市場規(guī)模預(yù)測部分直接使用了競爭對手官網(wǎng)的推廣數(shù)據(jù)完全沒有做交叉驗證。如果這是一個獨立的數(shù)據(jù)Agent我一眼就能看出它接入的數(shù)據(jù)源有問題但在一整段生成的文本里要想追蹤這個錯誤源幾乎等于大海撈針。多Agent架構(gòu)把這一步拆開每個Agent只做一件事輸入和輸出都是可檢查的問題環(huán)節(jié)一眼就能揪出來。再從工程角度看多Agent架構(gòu)帶來的三個優(yōu)勢是實實在在的第一可定位性。系統(tǒng)里每個Agent的輸入輸出都是結(jié)構(gòu)化的任何一個環(huán)節(jié)出問題直接看該環(huán)節(jié)的日志即可不是在整段對話里撈線索。第二可替換性。想換某個環(huán)節(jié)的模型或者優(yōu)化某個Agent的提示詞只改那一個環(huán)節(jié)就行不影響其他部分。如果全塞在一條提示詞里每一個微調(diào)都可能引發(fā)蝴蝶效應(yīng)。第三可審計性。企業(yè)級應(yīng)用繞不開合規(guī)與審計的需求多Agent的流程天然就有任務(wù)記錄、執(zhí)行軌跡每一步做了什么、用了什么數(shù)據(jù)都可追蹤。不過話也要說回來多Agent不是銀彈Agent數(shù)量多不代表系統(tǒng)聰明。我見過有團(tuán)隊把六個Agent塞進(jìn)一個流程里光互相傳遞消息的耗時和Token開銷就拖垮了整體性能產(chǎn)出質(zhì)量反而不如兩個Agent的版本。核心問題不在于有多少個Agent而在于每個Agent是不是真的獨立承擔(dān)了不可替代的職責(zé)。拆分的粒度應(yīng)該是按職責(zé)、按上下文隔離需求來拆而不是為了看起來厲害而拆。任何Agent的加入都需要回答一個問題這個環(huán)節(jié)如果并入相鄰Agent是否會顯著增加上下文復(fù)雜度或降低結(jié)果可靠性如果不是那就不該拆出來。2. 核心機(jī)制與設(shè)計要點2.1 Agent的角色定義與職責(zé)拆分在agency-agents這類框架里Agent的角色定義是整套系統(tǒng)質(zhì)量的天花板。表面的操作是寫一段系統(tǒng)提示詞但真正寫得好的角色定義一定包含四個層次身份、職責(zé)、邊界、輸出格式。身份解決的是你是誰比如你是一位有十年消費電子行業(yè)經(jīng)驗的市場分析師職責(zé)解決的是你負(fù)責(zé)干什么比如分析給定數(shù)據(jù)集中各品牌的價格帶分布和增長趨勢邊界解決的是你不能干什么——這一層最容易被忽略但不寫清楚的后果非常嚴(yán)重Agent會越權(quán)。比如你讓它做數(shù)據(jù)分析它寫著寫著開始給你提營銷建議了。輸出格式解決的是結(jié)果長什么樣——比如返回一個JSON對象包含價格帶分段和趨勢摘要兩個字段。我常用的角色提示詞模板長這樣你是一位[身份]。 你的任務(wù)[職責(zé)描述越具體越好]。 在執(zhí)行任務(wù)時注意以下邊界 - 不要[禁止事項1如不要給出主觀建議] - 不要[禁止事項2如不要引用未經(jīng)來源標(biāo)注的數(shù)據(jù)] - 如果輸入信息不充分直接說明缺失信息不要猜測補全。 輸出要求[明確的結(jié)構(gòu)化格式如Markdown列表或JSON對象。 你需要將完整結(jié)果返回給下一個處理環(huán)節(jié)。這套模板里最關(guān)鍵的其實是邊界和輸出格式兩層。我在一個內(nèi)部分享里說過給Agent戴上邊界的枷鎖不是限制它的能力而是保護(hù)它的專注度。邊界寫清楚之后Agent就不會自作主張地擴(kuò)大工作面下游Agent也就不會被無關(guān)信息污染。2.2 Agent間的通信協(xié)議與任務(wù)流轉(zhuǎn)多Agent系統(tǒng)的骨架不是Agent本身而是Agent之間的消息通道和任務(wù)流轉(zhuǎn)機(jī)制。最初我做這個項目時天真地讓Agent之間自由對話——A把結(jié)果發(fā)給BB看完發(fā)表意見A再回復(fù)……結(jié)果兩個Agent在第七輪對話之后徹底偏離主線開始糾結(jié)一個不重要的細(xì)節(jié)最終流程因上下文溢出而崩掉。這次事故讓我確定了一件事Agent之間的通信絕對不能是自由聊天必須是結(jié)構(gòu)化消息。我在實際項目中給每個Agent定義了一套統(tǒng)一的消息格式核心字段包括message_type消息類型如task派發(fā)任務(wù)、result返回結(jié)果、error報告錯誤、review審核意見。from發(fā)送方Agent的名稱。to接收方Agent的名稱。payload實際的數(shù)據(jù)體通常是一個JSON對象包含該環(huán)節(jié)所需的全部輸入或輸出。這套結(jié)構(gòu)看起來簡單但它解決了三個核心問題一是每條消息的來龍去脈都可追蹤二是每個Agent只訂閱自己關(guān)心的消息類型不會接收到無關(guān)信息三是整個流程可以像查物流一樣隨時定位任務(wù)走到哪一步了。任務(wù)流轉(zhuǎn)模式上我通常只推薦兩種。第一種是編排者模式Orchestrator一個中心Agent統(tǒng)一調(diào)度A完成后通知調(diào)度者調(diào)度者再把任務(wù)派給B。這種模式的優(yōu)點是流程清晰、容易控制適合環(huán)節(jié)固定、邏輯明確的場景。第二種是管道模式Pipeline每個Agent只處理上游的結(jié)果并傳給下游像工廠流水線一樣。相比之下那種讓Agent自己商量下一步誰該干什么的自治協(xié)作模式我在生產(chǎn)環(huán)境里試過幾次小規(guī)模demo確實顯得很酷但一旦Agent數(shù)量超過三個調(diào)試難度就呈指數(shù)級上升最終還是要靠一堆硬編碼的規(guī)則去兜底。所以我的建議是由中心節(jié)點控制流程Agent專注于自己的節(jié)點任務(wù)不要讓Agent承擔(dān)調(diào)度職責(zé)。2.3 記憶與上下文的隔離策略——多Agent項目最容易被忽視的坑如果你只記住這篇文章里一個經(jīng)驗教訓(xùn)我希望是這個多Agent項目的上下文必須做隔離絕對不要全部共享。很多人在實現(xiàn)多Agent系統(tǒng)時習(xí)慣性地把整個會話的歷史記錄一股腦塞給所有Agent共享。這種做法表面上是讓每個Agent都有全局視野實際上是把多Agent系統(tǒng)退化回單Agent超長對話而且是token消耗翻倍版的單Agent。每個Agent都要處理跟自己無關(guān)的上下文注意力被稀釋Token開銷暴漲還經(jīng)常出現(xiàn)串味——數(shù)據(jù)分析Agent給你輸出了一段帶有文案Agent口吻的文本一眼就是被污染了。我的上下文分層策略是這樣的第一層是項目級共享記憶只有放那些所有環(huán)節(jié)都需要參考的全局事實比如項目名稱、最終目標(biāo)、關(guān)鍵約束條件。共享記憶在每個Agent啟動時注入。第二層是Agent級私有記憶只放該Agent自己產(chǎn)出的信息和需要讀取的輸入。比如調(diào)研Agent整理出的事實清單只存在于它自己的狀態(tài)里作為消息payload發(fā)給下一個Agent后表示這個環(huán)節(jié)已完成而非被所有Agent永久持有。第三層是消息級臨時記憶隨消息傳遞任務(wù)完成后即可丟棄用來承載兩個Agent之間的數(shù)據(jù)交接。這套策略落地之后我的一個五Agent調(diào)研系統(tǒng)在成本上的改善非常明顯Token消耗大約降到了原來的三分之一生成結(jié)果的穩(wěn)定性也有明顯提升。因為每個Agent的上下文都夠小、夠聚焦模型也就更不容易想東想西。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 環(huán)境準(zhǔn)備與基礎(chǔ)配置理論說再多不如親手跑一遍。下面我以LangGraph為例帶你把一個最小的多Agent系統(tǒng)搭起來。選用LangGraph的理由很簡單它原生支持狀態(tài)圖建模、自帶節(jié)點和邊管理、能實現(xiàn)條件路由非常適合做Agent流程編排。你不用非得用這個框架但它的設(shè)計思路值得參考。環(huán)境配置上需要滿足以下前提Python 3.10 的環(huán)境。安裝LangGraph和模型調(diào)用庫命令如下pip install langgraph langchain-openai準(zhǔn)備大模型API訪問。當(dāng)前主流的模型服務(wù)商OpenAI、Anthropic、DeepSeek、智譜、通義等都支持函數(shù)調(diào)用和結(jié)構(gòu)化輸出這對Agent場景是必需的。建議把API密鑰放進(jìn)環(huán)境變量或獨立的配置文件不要在代碼里硬編碼。export LLM_API_KEY你的密鑰 export LLM_BASE_URL你所用模型服務(wù)的接口地址模型參數(shù)方面我非常建議把temperature設(shè)置到 0.2 以下。Agent場景不是在寫詩而是在執(zhí)行任務(wù)溫度越低輸出確定性越高后面審核環(huán)節(jié)的壓力就越小。3.2 從零搭建一個多Agent協(xié)作流程為了演示我們搭建一個行業(yè)簡報自動生成系統(tǒng)它包含三個Agent資料收集Agent從原始文本中篩選和提煉關(guān)鍵數(shù)據(jù)。分析Agent對數(shù)據(jù)做結(jié)構(gòu)化分析輸出主要結(jié)論。寫作Agent依據(jù)分析結(jié)論撰寫簡報成稿。這三個Agent之間采用管道模式串聯(lián)再用一個小型的編排層控制流程。以下是基于LangGraph的核心實現(xiàn)from typing import TypedDict, List from langgraph.graph import StateGraph, END class BriefState(TypedDict): raw_data: str # 輸入原始資料 key_facts: List[str] # 中間收集Agent提煉的事實 analysis: str # 中間輸出分析Agent的結(jié)論 final_brief: str # 輸出寫作Agent生成的簡報 def collect_agent(state: BriefState): 資料收集Agent從原材料中提煉關(guān)鍵事實。 prompt f你是一名產(chǎn)業(yè)資料分析助手。 從以下原始資料中提取與主題相關(guān)的關(guān)鍵事實。 只輸出事實清單不要加工和評論。 原始資料 {state[raw_data]} response llm.invoke([ {role: system, content: prompt} ]) facts [f.strip() for f in response.content.split(\n) if f.strip()] return {key_facts: facts} def analysis_agent(state: BriefState): 分析Agent基于關(guān)鍵事實給出結(jié)構(gòu)化分析。 facts_text \n.join(f- {f} for f in state[key_facts]) prompt f你是一名行業(yè)研究分析師。 基于以下事實給出三個核心結(jié)論并指出一個潛在風(fēng)險。 要求結(jié)論必須有事實支撐不能無中生有。 事實清單 {facts_text} response llm.invoke([ {role: system, content: prompt} ]) return {analysis: response.content} def writing_agent(state: BriefState): 寫作Agent把分析結(jié)論寫成簡報。 prompt f你是一名資深商業(yè)寫作編輯。 根據(jù)以下分析結(jié)論撰寫一份簡短的行業(yè)簡報約300字。 風(fēng)格要求客觀、簡潔、有數(shù)據(jù)支撐。 分析結(jié)論 {state[analysis]} response llm.invoke([ {role: system, content: prompt} ]) return {final_brief: response.content} # 構(gòu)建狀態(tài)圖 workflow StateGraph(BriefState) workflow.add_node(collect, collect_agent) workflow.add_node(analyze, analysis_agent) workflow.add_node(write, writing_agent) workflow.set_entry_point(collect) workflow.add_edge(collect, analyze) workflow.add_edge(analyze, write) workflow.add_edge(write, END) app workflow.compile() # 執(zhí)行 result app.invoke({ raw_data: 這里粘貼你要分析的原始資料……, key_facts: [], analysis: , final_brief: }) print(result[final_brief])這段代碼的核心邏輯很簡單先收集事實再做分析最后成稿。每一步的輸入都是上一步的輸出Agent之間沒有多余的信息交叉。運行后你可以直接在result[final_brief]里看到成稿結(jié)果中間過程的關(guān)鍵事實和分析也都在狀態(tài)對象里方便追溯。我建議你在跑通這個例子后往這個最小系統(tǒng)里加一個審核Agent專門用于檢查簡報的事實錯誤和邏輯矛盾如果發(fā)現(xiàn)問題把修改意見退回給寫作Agent重寫。加審核環(huán)節(jié)后系統(tǒng)可靠性會有質(zhì)的提升但前提是要給退回重寫設(shè)一個循環(huán)上限不然就有可能進(jìn)入死循環(huán)。3.3 給流程加上審核與重試機(jī)制只加審核Agent不改循環(huán)上限是很多初學(xué)者踩過的坑。審核Agent發(fā)現(xiàn)一處問題退回給寫作Agent重寫寫作Agent改完再送審如果審核Agent要求更高又退回……運氣不好的話這個過程會反復(fù)循環(huán)直到Token燒穿。我的做法是給審核節(jié)點定義一個條件路由并在狀態(tài)里加一個重試計數(shù)器超過三次就強(qiáng)制通過或自動降級處理。示例如下class BriefState(TypedDict): raw_data: str key_facts: List[str] analysis: str final_brief: str draft: str # 當(dāng)前稿子 feedback: str # 審核意見 retry_count: int # 重試次數(shù) def review_agent(state: BriefState): 審核Agent檢查簡報質(zhì)量。 prompt f你是一名資深內(nèi)容審核員。 請審核以下簡報輸出PASS或FAIL如果FAIL請給出具體修改建議。 簡報內(nèi)容 {state[draft]} 審核要求 1. 是否有明顯事實性錯誤 2. 是否存在邏輯跳躍或前后矛盾 3. 是否缺少必要的結(jié)論提煉 response llm.invoke([ {role: system, content: prompt} ]) result response.content is_pass result.startswith(PASS) feedback_text if is_pass else result return {feedback: feedback_text, retry_count: state.get(retry_count, 0) (0 if is_pass else 1)} def route_after_review(state: BriefState): if state[feedback] and state[retry_count] 3: return rewrite # 有反饋且次數(shù)未到退回修改 return end # 通過或超限流程結(jié)束 def rewrite_agent(state: BriefState): 修改Agent根據(jù)審核建議修改簡報。 prompt f你是一名寫作者。請根據(jù)審核建議修改以下簡報。 審核建議{state[feedback]} 當(dāng)前簡報{state[draft]} response llm.invoke([ {role: system, content: prompt} ]) return {draft: response.content}這種審核-修改-再審核的閉環(huán)是讓多Agent系統(tǒng)走向可用的關(guān)鍵設(shè)計。生產(chǎn)環(huán)境里我會進(jìn)一步把強(qiáng)制通過和人工介入結(jié)合起來連續(xù)修改三次仍然沒有PASS就自動轉(zhuǎn)給人工審核而不是無限消耗Token。4. 常見問題與排查技巧實錄4.1 Agent答非所問、輸出不穩(wěn)定問題出在哪做過Agent項目的人一定都遇過這種情況同一個Agent、同一個輸入兩次運行的結(jié)果卻不一樣有時甚至出現(xiàn)嚴(yán)重的答非所問。碰到這問題我按下面的順序排查第一查temperature。如果你的模型參數(shù)里temperature設(shè)置得比較高比如0.7以上那兩次結(jié)果不一樣是正常的。Agent執(zhí)行任務(wù)溫度建議降下來控制在0.2以下大部分隨機(jī)性漂移都能解決。第二查提示詞邊界。如果你的提示詞沒有寫不知道就說不知道不要猜測Agent就會在信息不足時強(qiáng)行編一個答案。我給所有Agent的角色定義里都會加一句如果輸入信息不足以得出結(jié)論請明確說明缺失的信息這個改動看著小但對輸出的穩(wěn)定性影響巨大。第三查上下文污染。如果Agent的輸入里混入了與當(dāng)前任務(wù)無關(guān)的歷史信息它的輸出就會串味。比如你讓寫作Agent去寫簡報結(jié)果它的輸入里還包含了上一次某個用戶閑聊的對話記錄它可能會不自覺地改變寫作風(fēng)格。這時候需要做上下文隔離不要一股腦傳全部歷史。4.2 流程卡死、任務(wù)永遠(yuǎn)在等待怎么破多Agent系統(tǒng)最常見的運行時故障不是某個Agent出錯而是整個流程卡死。我踩過的最深的一個坑是一個Agent調(diào)用了外部API結(jié)果API超時沒有返回下游Agent一直在等待一個永遠(yuǎn)不會到的消息。整個隊列就這么掛著用戶前臺顯示生成中長達(dá)20分鐘。解決思路分兩層。第一層是單點超時控制。每個Agent調(diào)用外部模型或API時都設(shè)置一個合理的超時時間。我一般設(shè)120秒超過就自動返回重試信號或跳過?？蚣茏詭У某瑫r機(jī)制也很好用LangGraph里可以給節(jié)點設(shè)置timeout參數(shù)。第二層是全局兜底。整個流程也要有一個總超時比如整個簡報流程必須在10分鐘內(nèi)跑完。如果超時先把已完成的中間結(jié)果保存下來再返回給用戶部分結(jié)果提示稍后重試。這個設(shè)計比讓用戶對著一個加載中的按鈕干等強(qiáng)太多了。4.3 Token消耗爆炸、成本失控的深層原因做多Agent系統(tǒng)的人都很關(guān)心成本。我觀察下來Token消耗爆炸的原因就兩個一是上下文隔離沒做好二是循環(huán)沒設(shè)上限。上下文隔離的問題前面講了這里說一下循環(huán)上限——你不顯式地寫死循環(huán)次數(shù)幾個Agent真的會因為一個意見分歧無限互改下去Token消耗分分鐘讓你懷疑人生。成本控制上還有一個思路不同環(huán)節(jié)用不同級別的模型。比如寫作Agent需要創(chuàng)意和語言組織能力用頂級模型值得資料收集Agent只是做文本抽取和篩選用輕量模型完全夠。強(qiáng)模型和輕量模型的價格差可能在十倍以上合理分配能讓整體成本下降一個量級。這一點在agents anywhere的落地實踐里尤其重要——當(dāng)Agent無處不在、流程無處不在成本模型就必須精細(xì)化。4.4 上下文污染的幾種隱蔽表現(xiàn)上下文污染在排查時是最隱蔽的因為它的錯誤不報紅、不報錯只是輸出質(zhì)量在不知不覺地變爛。我總結(jié)了幾種典型表現(xiàn)角色錯亂數(shù)據(jù)分析Agent的輸出突然帶上了寫作Agent的措辭風(fēng)格甚至冒出口語化的表達(dá)。重復(fù)信息簡報里出現(xiàn)了與前一輪草稿相同的內(nèi)容說明舊版本沒有從上下文里清干凈。結(jié)論漂移兩個Agent對同一個數(shù)據(jù)的引用不一致原因是其中一個Agent引用了舊版本的數(shù)據(jù)快照。這些問題的根源都是狀態(tài)管理不嚴(yán)格。我建議從最開始就給AgentState定義清晰的字段并且嚴(yán)格約定哪些字段允許跨節(jié)點傳遞。不要讓Agent直接讀取全局的完整狀態(tài)而是像前面代碼里展示的那樣只傳它需要的字段。簡單地說狀態(tài)圖里流動的應(yīng)當(dāng)是結(jié)構(gòu)化的、最小必要的數(shù)據(jù)而不是歷史上所有發(fā)生過的事情。5. 說幾句實在話從demo到可用系統(tǒng)還差這幾步做Agent項目一年多我最大的體會是多Agent系統(tǒng)的難點從來不是把單個Agent調(diào)聰明而是把一群Agent組織成一個穩(wěn)定、可控、可迭代的系統(tǒng)。這里沒有那么多神秘的高深算法真正的功夫都在工程細(xì)節(jié)上——消息結(jié)構(gòu)、上下文隔離、異常熔斷、超時控制、成本分配。如果你想把這個demo往真實項目推進(jìn)我建議依次做三件事。第一加人工確認(rèn)節(jié)點在關(guān)鍵決策環(huán)節(jié)Agent給出建議后必須有一個人工確認(rèn)動作才能進(jìn)入下一步。這在企業(yè)級場景里是剛需也是讓各方安心的必要設(shè)計。第二打通工具調(diào)用讓Agent不只會讀文本和生成文本還能真正查企業(yè)數(shù)據(jù)庫、調(diào)內(nèi)部API、發(fā)郵件、操作表格這樣Agent才有實際生產(chǎn)力而不只是內(nèi)容生成器。第三建立流程監(jiān)控把每個環(huán)節(jié)的耗時、Token消耗、重試次數(shù)、成功率記錄下來長期積累下來這些數(shù)據(jù)會直接指導(dǎo)你優(yōu)化模型選擇和流程設(shè)計。我在跑agency-agents的過程中最后悔的一件小事是前三個月完全沒做流程版本管理。每次調(diào)提示詞都像開盲盒改那么一兩個字可能整個下游輸出的風(fēng)格都變了。后面我把每次調(diào)整都記錄下來能回溯到具體版本整個系統(tǒng)的迭代速度才真正快起來。如果你也要把這個方向往深了做流程版本管理這一課建議你一開始就補上。做一個能跑的Agent demo很酷做一個能持續(xù)迭代、穩(wěn)定產(chǎn)出的Agent系統(tǒng)很難但它值得你花時間去打磨。希望這篇文章能幫你少踩一些我已經(jīng)踩過的坑。