上周在社區(qū)里看到一個(gè)討論有人問“現(xiàn)在搞個(gè)AI應(yīng)用是不是非得搭一套復(fù)雜的Agent工作流弄幾十上百個(gè)節(jié)點(diǎn)才能做出點(diǎn)像樣的東西” 這個(gè)問題背后其實(shí)反映了一個(gè)普遍存在的誤解很多人覺得AI能力的強(qiáng)弱直接等同于系統(tǒng)架構(gòu)的復(fù)雜程度。仿佛不搞個(gè)“Agent Graph”不把任務(wù)拆解得七零八落再用各種工具和規(guī)則拼起來就體現(xiàn)不出技術(shù)的先進(jìn)性。但事實(shí)真的如此嗎最近一個(gè)名為“Replacing 223-node agent graph with a single OSS LLM”的項(xiàng)目標(biāo)題讓我眼前一亮。它沒有長篇大論卻提出了一個(gè)極具沖擊力的觀點(diǎn)一個(gè)開源的、單體的、未經(jīng)復(fù)雜編排的大語言模型LLM在某些場景下其表現(xiàn)足以替代一個(gè)由223個(gè)節(jié)點(diǎn)構(gòu)成的復(fù)雜智能體Agent圖。這個(gè)對比數(shù)字“223 vs 1”本身就充滿了故事性。它挑戰(zhàn)的正是我們對于“復(fù)雜系統(tǒng)必然優(yōu)于簡單模型”的慣性思維。這個(gè)標(biāo)題背后指向的是一種技術(shù)路線的反思。過去一年AI Agent和Graph圖的概念火遍全網(wǎng)。大家熱衷于設(shè)計(jì)精巧的工作流讓LLM扮演調(diào)度者調(diào)用各種工具Tool、訪問知識庫RAG、執(zhí)行子任務(wù)形成一個(gè)看似智能的決策網(wǎng)絡(luò)。這當(dāng)然有價(jià)值尤其在處理需要多步驟、強(qiáng)邏輯、外部交互的復(fù)雜任務(wù)時(shí)。但問題也隨之而來架構(gòu)的復(fù)雜度是否帶來了與之匹配的收益為了處理20%的邊界情況我們是否引入了80%的維護(hù)成本、延遲開銷和不確定性今天我們不談空洞的概念就從“223節(jié)點(diǎn)圖 vs 單個(gè)OSS LLM”這個(gè)具體對比出發(fā)深入聊聊什么時(shí)候一個(gè)“簡單粗暴”的大模型反而比一個(gè)“精雕細(xì)琢”的復(fù)雜系統(tǒng)更有效我們該如何判斷自己的項(xiàng)目到底需要Agent Graph還是只需要一個(gè)足夠強(qiáng)的“單體智能”這不僅僅是技術(shù)選型問題更是對AI應(yīng)用開發(fā)本質(zhì)效率的思考。1. 先拆解“223節(jié)點(diǎn)圖”與“單體LLM”到底在比什么看到“223-node agent graph”這個(gè)描述第一反應(yīng)可能是震撼于其規(guī)模。但在工程領(lǐng)域節(jié)點(diǎn)數(shù)量多往往不直接等同于能力強(qiáng)更可能意味著依賴復(fù)雜、調(diào)試?yán)щy、單點(diǎn)故障多。我們需要先理解這兩者分別代表了什么。1.1 “223節(jié)點(diǎn)Agent圖”背后是“分工協(xié)作”的工程化思維一個(gè)龐大的Agent圖其設(shè)計(jì)哲學(xué)源于經(jīng)典的軟件工程和自動化流程思想將復(fù)雜問題分解。節(jié)點(diǎn)Node通常代表一個(gè)具體的功能單元。這可能是一個(gè)純LLM調(diào)用用于理解、規(guī)劃、總結(jié)一個(gè)工具調(diào)用如代碼執(zhí)行、數(shù)據(jù)庫查詢、API請求一個(gè)條件判斷分支或是一個(gè)數(shù)據(jù)轉(zhuǎn)換步驟。邊Edge定義了節(jié)點(diǎn)之間的數(shù)據(jù)流向和控制邏輯。它決定了任務(wù)執(zhí)行的路徑比如“如果步驟A成功則執(zhí)行B否則執(zhí)行C”。圖Graph就是所有這些節(jié)點(diǎn)和邊構(gòu)成的有向無環(huán)圖DAG或狀態(tài)機(jī)。它可視化地描述了整個(gè)任務(wù)的解決流程。這種架構(gòu)的優(yōu)勢很明顯可解釋性強(qiáng)每一步輸入、輸出、執(zhí)行路徑都清晰可見便于調(diào)試和審計(jì)。模塊化設(shè)計(jì)每個(gè)節(jié)點(diǎn)功能單一易于單獨(dú)開發(fā)、測試和替換。處理確定性流程對于有固定步驟、強(qiáng)依賴關(guān)系的工作如數(shù)據(jù)處理流水線它非常高效。集成外部能力可以方便地接入各種非LLM的工具和系統(tǒng)。但它的代價(jià)同樣巨大設(shè)計(jì)成本高需要預(yù)先精確設(shè)計(jì)整個(gè)工作流對任務(wù)的理解必須足夠深入。靈活性差面對模糊、開放或需要臨場發(fā)揮的任務(wù)僵化的圖結(jié)構(gòu)可能無法適應(yīng)。維護(hù)噩夢223個(gè)節(jié)點(diǎn)意味著至少223個(gè)潛在的故障點(diǎn)任何節(jié)點(diǎn)的輸入輸出格式變化、工具API變更都可能引發(fā)連鎖反應(yīng)。延遲累積每個(gè)節(jié)點(diǎn)都有調(diào)用開銷尤其是LLM調(diào)用串聯(lián)起來總延遲可能非常可觀。1.2 “單個(gè)OSS LLM”背后是“涌現(xiàn)能力”與“指令遵循”的暴力美學(xué)“單個(gè)OSS LLM”指的是直接使用一個(gè)開源的大語言模型如Llama、Qwen、DeepSeek等通過精心設(shè)計(jì)的提示詞Prompt讓它“一口氣”完成相對復(fù)雜的任務(wù)。這里的關(guān)鍵詞是“單次調(diào)用”和“端到端”。這種方式的哲學(xué)是相信現(xiàn)代LLM特別是70B參數(shù)及以上的模型具備足夠的上下文理解、邏輯推理和指令遵循能力能夠?qū)⒃拘枰嗖讲鸾獾娜蝿?wù)在一個(gè)連貫的思維鏈中完成。它的優(yōu)勢在于極致簡單沒有復(fù)雜的編排系統(tǒng)部署和調(diào)用就是啟動一個(gè)模型服務(wù)如vLLM、TGI然后發(fā)送請求。成本透明成本基本只與模型推理的Token消耗相關(guān)沒有額外的調(diào)度和中間狀態(tài)管理開銷。靈活性極高只需修改提示詞就能快速調(diào)整任務(wù)目標(biāo)適應(yīng)新的需求無需重構(gòu)整個(gè)圖。延遲可能更低雖然單次推理時(shí)間可能不短但避免了多次網(wǎng)絡(luò)往返和序列化/反序列化開銷。它的挑戰(zhàn)也同樣明確對提示詞工程要求高模型的表現(xiàn)極度依賴提示詞的質(zhì)量。如何清晰、無歧義地定義任務(wù)、提供示例、規(guī)定格式是一門藝術(shù)。輸出穩(wěn)定性LLM的輸出具有隨機(jī)性需要設(shè)計(jì)機(jī)制如重復(fù)采樣、后處理來保證關(guān)鍵任務(wù)如代碼生成、數(shù)據(jù)提取的穩(wěn)定性。上下文長度限制雖然現(xiàn)在128K、200K上下文的模型不少但處理超長文檔或多輪復(fù)雜交互時(shí)仍需注意。缺乏外部工具調(diào)用純LLM無法直接執(zhí)行代碼、查詢數(shù)據(jù)庫或操作外部系統(tǒng)除非通過特定方式如函數(shù)調(diào)用集成但這又會引入復(fù)雜度。1.3 核心對比不是“好與壞”而是“適合與不適合”所以“223節(jié)點(diǎn)圖 vs 單個(gè)LLM”的對比本質(zhì)是兩種問題解決范式的對比圖范式強(qiáng)調(diào)確定性的流程控制和外部能力集成適合流程固定、邏輯清晰、需要與現(xiàn)有系統(tǒng)深度交互的任務(wù)。LLM范式強(qiáng)調(diào)模型的通用推理能力和指令遵循靈活性適合定義相對模糊、需要一定創(chuàng)造性、但步驟可在一個(gè)“思考過程”內(nèi)完成的任務(wù)?！?23 vs 1”這個(gè)夸張的數(shù)字其啟示在于很多被我們習(xí)慣性用復(fù)雜流程去解決的問題其核心難點(diǎn)可能并非流程設(shè)計(jì)而是對問題的理解和描述。當(dāng)一個(gè)足夠強(qiáng)大的LLM能夠通過提示詞直接理解并解決時(shí)之前那套復(fù)雜的“腳手架”就失去了大部分價(jià)值。2. 為什么“單個(gè)LLM”方案經(jīng)常被低估我們忽略了什么在追求Agent和Graph的熱潮中“直接用LLM搞定”這種簡單方案常常被視為“初級”或“能力有限”。我們可能忽略了幾個(gè)關(guān)鍵因素導(dǎo)致了對“單體LLM”能力的誤判。2.1 誤區(qū)一認(rèn)為“復(fù)雜任務(wù)必須拆解”這是最根深蒂固的思維定式。我們習(xí)慣于像編寫傳統(tǒng)程序一樣思考先定義函數(shù)再組合調(diào)用。但對于LLM而言它的“函數(shù)”就是它的推理能力。很多我們認(rèn)為需要拆解的任務(wù)在LLM看來是一個(gè)完整的語義單元。例如一個(gè)“分析競品文檔并生成對比報(bào)告”的任務(wù)。復(fù)雜圖解法可能設(shè)計(jì)為節(jié)點(diǎn)1提取文檔關(guān)鍵信息- 節(jié)點(diǎn)2信息歸類- 節(jié)點(diǎn)3對比分析- 節(jié)點(diǎn)4生成報(bào)告模板- 節(jié)點(diǎn)5填充內(nèi)容。每個(gè)節(jié)點(diǎn)可能都是一個(gè)LLM調(diào)用或規(guī)則引擎。單體LLM解法一個(gè)精心設(shè)計(jì)的提示詞“你是一名市場分析師。請仔細(xì)閱讀以下A產(chǎn)品和B產(chǎn)品的文檔從功能、定價(jià)、目標(biāo)用戶、優(yōu)勢劣勢四個(gè)維度進(jìn)行詳細(xì)對比并以Markdown表格形式輸出一份完整的對比報(bào)告。確保引用文檔中的具體描述作為依據(jù)?！?然后附上兩份文檔。后者不僅步驟更少而且因?yàn)長LM在單次推理中保持了完整的上下文其對比分析可能更連貫、更深入避免了分步處理導(dǎo)致的信息割裂。2.2 誤區(qū)二過度追求“可解釋性”和“可控性”Agent圖的可視化節(jié)點(diǎn)確實(shí)讓人安心感覺一切盡在掌握。但很多時(shí)候這種“可控”是虛假的。LLM節(jié)點(diǎn)內(nèi)部的推理過程本身就是一個(gè)黑盒你只是控制了它的輸入輸出端口。而一個(gè)設(shè)計(jì)良好的單體LLM提示詞通過要求其“分步思考”Chain-of-Thought同樣可以獲得高可解釋性的中間輸出。關(guān)鍵在于你要的控制是什么如果是流程控制先做什么后做什么那圖更合適。如果是邏輯控制如何思考如何決策那么一個(gè)要求輸出思考鏈的提示詞配合一個(gè)足夠聰明的LLM可能提供更本質(zhì)的“可解釋性”。2.3 誤區(qū)三低估了現(xiàn)代開源LLM的“零樣本/少樣本”能力早期的LLM確實(shí)需要大量的示例Few-shot才能完成復(fù)雜任務(wù)。但如今頂尖的開源模型如Qwen2.5-72B, Llama 3.1-70B, DeepSeek-V2在理解復(fù)雜指令、進(jìn)行多步驟推理、遵循輸出格式方面已經(jīng)非常強(qiáng)大。很多時(shí)候一個(gè)清晰的零樣本提示詞Zero-shot Prompt就足夠了。我們習(xí)慣于為舊工具設(shè)計(jì)復(fù)雜的工作流卻忘了評估新工具本身的能力邊界是否已經(jīng)擴(kuò)展?！坝肁gent圖”很多時(shí)候是我們基于過去經(jīng)驗(yàn)的條件反射而不是基于當(dāng)前LLM能力的最優(yōu)解。2.4 誤區(qū)四混淆了“系統(tǒng)復(fù)雜度”與“任務(wù)復(fù)雜度”這是最關(guān)鍵的認(rèn)知偏差。任務(wù)本身的復(fù)雜度是客觀存在的。但系統(tǒng)的復(fù)雜度是我們?yōu)榱送瓿扇蝿?wù)而引入的。一個(gè)優(yōu)秀的設(shè)計(jì)應(yīng)該追求用盡可能簡單的系統(tǒng)去駕馭復(fù)雜的任務(wù)?！?23節(jié)點(diǎn)圖”代表了極高的系統(tǒng)復(fù)雜度。它的存在可能源于對LLM能力的不信任所以用大量規(guī)則和工具來補(bǔ)足。任務(wù)分解得過細(xì)每個(gè)節(jié)點(diǎn)只做一件微不足道的小事。缺乏對提示詞工程的深入探索用架構(gòu)的復(fù)雜度來彌補(bǔ)提示詞設(shè)計(jì)的不足?！皢蝹€(gè)LLM”方案則試圖將復(fù)雜度壓回模型內(nèi)部讓模型自身的推理能力來承擔(dān)。如果模型足夠強(qiáng)那么系統(tǒng)就能保持極簡。這就像從“用一堆簡單機(jī)械組裝成的機(jī)器人”進(jìn)化到“一個(gè)擁有強(qiáng)大大腦的仿生人”。3. 實(shí)戰(zhàn)如何判斷你的項(xiàng)目該選“圖”還是“單體LLM”理論探討之后我們需要一個(gè)可操作的決策框架。下次當(dāng)你啟動一個(gè)AI項(xiàng)目時(shí)可以問自己下面這幾個(gè)問題。3.1 決策清單五個(gè)關(guān)鍵問題問題傾向于使用Agent Graph傾向于使用Single LLM1. 任務(wù)步驟是否固定且順序嚴(yán)格是。例如數(shù)據(jù)清洗流水線先去重再標(biāo)準(zhǔn)化再驗(yàn)證、軟件部署腳本。否。任務(wù)有核心目標(biāo)但實(shí)現(xiàn)路徑可以靈活或需要臨場推理。例如創(chuàng)意寫作、代碼審查、方案設(shè)計(jì)。2. 是否需要頻繁與外部系統(tǒng)/工具交互是且交互邏輯復(fù)雜。例如需要查詢數(shù)據(jù)庫A根據(jù)結(jié)果調(diào)用API B再將結(jié)果寫入文件系統(tǒng)C。否或交互很簡單。例如主要基于提供的文本進(jìn)行分析、生成、總結(jié)或僅需調(diào)用1-2個(gè)明確工具。3. 任務(wù)的容錯(cuò)率和可解釋性要求要求極高。每一步都必須可審計(jì)、可回滾錯(cuò)誤必須嚴(yán)格隔離。例如金融交易、醫(yī)療診斷輔助。要求中等或可接受一定模糊性?？梢酝ㄟ^多次采樣、投票或人工復(fù)核來保證質(zhì)量。例如內(nèi)容生成、初步數(shù)據(jù)分析、客服回復(fù)。4. 團(tuán)隊(duì)技能棧與維護(hù)成本團(tuán)隊(duì)熟悉工作流引擎如Airflow, Prefect、有較強(qiáng)的分布式系統(tǒng)調(diào)試能力能承受較高的長期維護(hù)成本。團(tuán)隊(duì)更擅長提示詞工程、模型微調(diào)希望快速迭代追求研發(fā)和運(yùn)維的輕量化。5. 任務(wù)邊界是否清晰且穩(wěn)定非常清晰且穩(wěn)定。需求變更慢任務(wù)范圍明確。相對模糊或可能快速變化。需要系統(tǒng)能快速適應(yīng)新指令、新格式。如果以上問題多數(shù)指向右側(cè)那么你應(yīng)該優(yōu)先嘗試“單體LLM”方案。一個(gè)簡單的啟動原則是Always start simple. 永遠(yuǎn)從最簡單的方案開始。3.2 從“單體LLM”起步的實(shí)踐路徑如果你判斷項(xiàng)目更適合“單體LLM”可以按以下路徑推進(jìn)第一步用最簡提示詞驗(yàn)證核心能力不要一開始就想設(shè)計(jì)完美的系統(tǒng)。選一個(gè)最強(qiáng)的開源模型如Qwen2.5-72B-Instruct寫一個(gè)最直接的提示詞扔給它一個(gè)最具代表性的任務(wù)樣例。看它“裸奔”的能力到底如何。目標(biāo)不是一次成功而是評估其潛力上限。第二步迭代提示詞而非架構(gòu)如果結(jié)果不理想先別急著畫圖。從這些方面優(yōu)化提示詞角色設(shè)定明確告訴模型它扮演誰資深工程師、分析師、作家。任務(wù)分解在提示詞中要求它“請按以下步驟思考1. ... 2. ...”。格式約束嚴(yán)格要求輸出格式JSON、Markdown、特定模板。少樣本示例提供1-3個(gè)高質(zhì)量的輸入輸出對。思維鏈明確要求“請一步步推理并將最終答案放在最后”。第三步引入輕量級后處理與保障單體LLM方案的工程化重點(diǎn)不在編排而在保障輸出解析與驗(yàn)證編寫簡單的解析器如Pydantic模型來提取和校驗(yàn)LLM返回的結(jié)構(gòu)化數(shù)據(jù)。解析失敗則觸發(fā)重試。重試與降級策略對于關(guān)鍵任務(wù)可以設(shè)置2-3次重試可能伴隨提示詞微調(diào)。甚至可以準(zhǔn)備一個(gè)更小、更快的模型作為降級備份。緩存對相同或相似的查詢進(jìn)行結(jié)果緩存大幅降低成本、提升響應(yīng)速度。監(jiān)控與評估記錄每次調(diào)用的提示詞、輸出、Token使用量和延遲。定期人工評估結(jié)果質(zhì)量持續(xù)優(yōu)化提示詞。第四步僅在必要時(shí)引入“圖”的元素當(dāng)以下情況出現(xiàn)時(shí)才考慮引入一些簡單的編排任務(wù)明顯可拆分為異構(gòu)階段例如第一階段用LLM做信息提取第二階段必須用Python腳本進(jìn)行數(shù)值計(jì)算第三階段再用LLM生成報(bào)告。這時(shí)可以用一個(gè)極簡的線性流程串聯(lián)。需要并行處理大量獨(dú)立子任務(wù)例如用LLM同時(shí)審閱100篇文檔。這時(shí)可以用一個(gè)“分派-收集”模式但每個(gè)子任務(wù)內(nèi)部仍是單體LLM調(diào)用。需要與外部API進(jìn)行復(fù)雜的狀態(tài)交互例如一個(gè)需要多輪確認(rèn)的訂單流程。這時(shí)可能需要一個(gè)簡單的狀態(tài)機(jī)來管理對話。記住這里的“圖”應(yīng)該是“不得已而為之”的補(bǔ)充而不是默認(rèn)的起點(diǎn)。它的節(jié)點(diǎn)應(yīng)該盡可能少邏輯應(yīng)該盡可能直白。4. 超越對比將“單體LLM”的能力工程化、產(chǎn)品化選擇“單體LLM”路徑并不意味著躺平。恰恰相反它要求我們將工程化的重點(diǎn)從架構(gòu)編排轉(zhuǎn)向能力激發(fā)與穩(wěn)定化。這同樣是一個(gè)深度的技術(shù)活。4.1 構(gòu)建你的“提示詞資產(chǎn)庫”提示詞是驅(qū)動單體LLM的核心。不能每次都是臨時(shí)編寫。需要像管理代碼一樣管理提示詞版本化使用Git管理提示詞模板的變更。模塊化將常用的角色設(shè)定、任務(wù)指令、格式規(guī)范抽離成可復(fù)用的片段。參數(shù)化使用像Jinja2這樣的模板引擎將變量部分如用戶查詢、上下文動態(tài)注入。測試與評估為關(guān)鍵提示詞建立測試集用自動化腳本評估其在不同輸入下的輸出質(zhì)量和穩(wěn)定性。4.2 實(shí)施系統(tǒng)的“模型層抽象”你不應(yīng)該將應(yīng)用代碼與某個(gè)特定模型如qwen2.5-72b的API強(qiáng)綁定。需要建立一個(gè)模型抽象層統(tǒng)一接口定義標(biāo)準(zhǔn)的generate(prompt, **kwargs)接口。多模型支持背后可以接入不同的開源模型服務(wù)vLLM, TGI甚至商業(yè)APIOpenAI, Anthropic。這便于進(jìn)行A/B測試、成本優(yōu)化和故障轉(zhuǎn)移。統(tǒng)一配置超參數(shù)溫度、top_p、最大Token數(shù)應(yīng)在這一層集中管理。# 示例一個(gè)極簡的模型抽象層 class LLMClient: def __init__(self, backendvllm, model_nameQwen2.5-72B-Instruct): self.backend backend self.model_name model_name # 初始化對應(yīng)后端的客戶端 ... def generate(self, prompt, temperature0.7, max_tokens2048): if self.backend vllm: return self._call_vllm(prompt, temperature, max_tokens) elif self.backend openai: return self._call_openai(prompt, temperature, max_tokens) # ... 其他后端 def _call_vllm(self, prompt, temperature, max_tokens): # 調(diào)用vLLM服務(wù)的具體邏輯 ...4.3 設(shè)計(jì)健壯的“輸出處理管道”LLM的輸出是半結(jié)構(gòu)化的文本。要將其轉(zhuǎn)化為可靠的數(shù)據(jù)需要穩(wěn)健的后處理格式清洗去除多余的標(biāo)記、修正明顯的格式錯(cuò)誤。結(jié)構(gòu)化解析對于JSON、XML等格式使用json.loads()等解析并做好異常捕獲?；赟chema的驗(yàn)證使用Pydantic等庫定義期望的數(shù)據(jù)結(jié)構(gòu)并驗(yàn)證LLM的輸出是否符合。不符合則觸發(fā)重試或報(bào)錯(cuò)。關(guān)鍵信息提取對于非結(jié)構(gòu)化文本可以使用正則表達(dá)式或更小的NLP模型來提取關(guān)鍵字段。4.4 建立持續(xù)的性能監(jiān)控與優(yōu)化閉環(huán)這是保證“單體LLM”方案能長期穩(wěn)定運(yùn)行的關(guān)鍵核心指標(biāo)監(jiān)控Token消耗、請求延遲、錯(cuò)誤率、輸出長度。質(zhì)量評估對于分類、摘要等任務(wù)可以定義自動化的評估指標(biāo)如ROUGE, BLEU。對于生成任務(wù)需要定期人工抽檢。成本分析監(jiān)控不同模型、不同提示詞的成本效益比。迭代驅(qū)動根據(jù)監(jiān)控和評估數(shù)據(jù)持續(xù)優(yōu)化提示詞、調(diào)整模型參數(shù)甚至考慮對特定任務(wù)進(jìn)行輕量級的模型微調(diào)LoRA。5. 結(jié)論回歸本質(zhì)讓復(fù)雜度待在它該待的地方“Replacing 223-node agent graph with a single OSS LLM”這個(gè)標(biāo)題之所以吸引人是因?yàn)樗赶蛄艘粋€(gè)更本質(zhì)的趨勢AI應(yīng)用的開發(fā)正從“外部編排復(fù)雜性”向“內(nèi)部模型能力”遷移。早期的AI能力弱我們需要用復(fù)雜的流程和規(guī)則去“輔佐”它就像給一個(gè)孩子設(shè)計(jì)一套詳細(xì)的說明書來完成家務(wù)。而現(xiàn)在模型本身已經(jīng)成長為一個(gè)可以理解復(fù)雜指令、進(jìn)行多步推理的“成年人”。我們更需要做的是清晰地告訴它目標(biāo)并信任它能找到自己的解決路徑而不是繼續(xù)事無巨細(xì)地指揮每一個(gè)動作。這并不是說Agent Graph沒有價(jià)值。對于流程剛性、需要與物理世界或復(fù)雜IT系統(tǒng)深度交互的任務(wù)它依然是無可替代的架構(gòu)。但我們必須清醒地意識到引入一個(gè)復(fù)雜架構(gòu)本身是有巨大成本的。這個(gè)成本包括設(shè)計(jì)、開發(fā)、調(diào)試、維護(hù)以及隨之而來的系統(tǒng)脆弱性。因此我的核心建議是在啟動下一個(gè)AI項(xiàng)目時(shí)將“直接用最好的開源LLM通過提示詞解決”作為默認(rèn)的基線方案。只有當(dāng)這個(gè)方案在能力、穩(wěn)定性或成本上明確無法滿足需求時(shí)才逐步、謹(jǐn)慎地引入Agent、Graph或其他編排元素。每次引入都要問自己這個(gè)額外的復(fù)雜度是否帶來了對等的、不可替代的價(jià)值技術(shù)的進(jìn)步應(yīng)該讓我們處理問題的方式變得更簡單、更直接而不是更復(fù)雜。當(dāng)一個(gè)大模型就能理解并完成你的需求時(shí)就別急著去畫那張擁有223個(gè)節(jié)點(diǎn)的、精美而脆弱的工作流圖了。把精力花在如何更好地與模型對話上你會發(fā)現(xiàn)很多時(shí)候“簡單”本身就是一種更高級的“強(qiáng)大”。