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