本文轉(zhuǎn)自：Coggle數(shù)據(jù)科學(xué)

隨著 Agent 概念的爆發(fā)，大量開發(fā)框架和 Agent 產(chǎn)品不斷涌現(xiàn)。從 AutoGPT 到 LangGraph，從 CrewAI 到各種開源 Agent 平臺(tái)，人們似乎正在接近“數(shù)字員工”的愿景：給定一個(gè)目標(biāo)，Agent 就能自主規(guī)劃、調(diào)用工具并完成復(fù)雜任務(wù)。

然而，當(dāng)越來越多團(tuán)隊(duì)嘗試將 Agent 推向真實(shí)業(yè)務(wù)場(chǎng)景時(shí)，一個(gè)問題逐漸顯現(xiàn)——為什么許多令人驚艷的 Demo，最終卻難以成為可靠的生產(chǎn)系統(tǒng)？

https://github.com/humanlayer/12-factor-agents/

作者 Dex Horthy 結(jié)合自己構(gòu)建 Agent 產(chǎn)品的經(jīng)驗(yàn)，對(duì)當(dāng)前流行的 Agent 開發(fā)模式進(jìn)行了反思。他認(rèn)為，很多開發(fā)者過于關(guān)注模型的自主能力，卻忽視了軟件工程的重要性。真正成功的 Agent 往往不是依靠無限循環(huán)的推理和工具調(diào)用，而是建立在成熟的軟件架構(gòu)之上。

文章首先回顧了軟件的發(fā)展歷程。傳統(tǒng)軟件系統(tǒng)本質(zhì)上是一張由開發(fā)者設(shè)計(jì)好的流程圖，每一個(gè)節(jié)點(diǎn)和路徑都被明確規(guī)定。然而現(xiàn)實(shí)情況并沒有想象中樂觀。作者指出，當(dāng) Agent 被用于真實(shí)業(yè)務(wù)后，人們會(huì)發(fā)現(xiàn)自主規(guī)劃帶來的不僅是靈活性，還有不可預(yù)測(cè)性。模型可能選擇錯(cuò)誤路徑、重復(fù)調(diào)用工具、陷入循環(huán)，甚至因?yàn)樯舷挛墓芾聿划?dāng)而產(chǎn)生完全錯(cuò)誤的結(jié)果。很多團(tuán)隊(duì)在達(dá)到 70% 到 80% 的效果后便遇到了瓶頸，而剩余的 20% 恰恰決定了產(chǎn)品是否能夠真正交付給用戶。

Agent 的理想與現(xiàn)實(shí)：為什么我們需要重新思考 Agent？

從軟件誕生開始，程序本質(zhì)上就是一張由開發(fā)者設(shè)計(jì)的流程圖。無論是早期的流程圖設(shè)計(jì)，還是今天復(fù)雜的業(yè)務(wù)系統(tǒng)，其核心思想都沒有發(fā)生根本變化：開發(fā)者預(yù)先定義好執(zhí)行路徑，程序按照既定規(guī)則運(yùn)行。后來出現(xiàn)的 Airflow、Prefect、Dagster 等工作流編排系統(tǒng)，雖然增強(qiáng)了調(diào)度、監(jiān)控、重試和可觀測(cè)性等能力，但本質(zhì)上仍然是在管理一張 DAG（有向無環(huán)圖）。在這種模式下，軟件工程師始終掌握著系統(tǒng)的控制權(quán)，每一個(gè)步驟和分支都經(jīng)過明確設(shè)計(jì)。

隨著機(jī)器學(xué)習(xí)技術(shù)的發(fā)展，軟件系統(tǒng)開始引入越來越多的智能能力。例如，在數(shù)據(jù)處理流程中增加文本分類模型，在客服系統(tǒng)中增加情感分析模型，或者在推薦系統(tǒng)中引入預(yù)測(cè)算法。雖然系統(tǒng)中的某些節(jié)點(diǎn)變得更加智能，但整體架構(gòu)并沒有發(fā)生改變。模型只是流程中的一個(gè)環(huán)節(jié)，而流程本身依然由開發(fā)者定義。因此，即使在機(jī)器學(xué)習(xí)時(shí)代，軟件仍然是一套高度確定性的系統(tǒng)。

Agent 的出現(xiàn)則帶來了完全不同的愿景。過去開發(fā)者需要設(shè)計(jì)完整的流程，而 Agent 希望開發(fā)者只需要提供目標(biāo)和工具，剩余的工作交給模型完成。換句話說，開發(fā)者不再定義“應(yīng)該經(jīng)過哪些節(jié)點(diǎn)”，而是只定義“能夠走哪些邊”。至于具體路徑如何選擇，則由大語言模型根據(jù)實(shí)時(shí)情況動(dòng)態(tài)決定。這種模式的吸引力顯而易見，因?yàn)樗馕吨浖軌驈牧鞒舔?qū)動(dòng)轉(zhuǎn)向目標(biāo)驅(qū)動(dòng)。面對(duì)復(fù)雜任務(wù)時(shí)，開發(fā)者不必提前考慮所有可能情況，而是讓模型自主規(guī)劃和調(diào)整執(zhí)行路徑。

這種思路也催生了當(dāng)前大多數(shù) Agent 框架所采用的經(jīng)典模式：模型根據(jù)當(dāng)前上下文選擇下一步行動(dòng)，系統(tǒng)執(zhí)行對(duì)應(yīng)工具，將結(jié)果寫回上下文，然后再次讓模型決定下一步操作。如此循環(huán)，直到模型認(rèn)為任務(wù)完成。從表面上看，這種模式極具通用性，因?yàn)樗軌蜻m應(yīng)各種不同場(chǎng)景。然而作者指出，問題恰恰出現(xiàn)在這個(gè)循環(huán)過程中。

隨著任務(wù)不斷推進(jìn)，系統(tǒng)會(huì)持續(xù)向上下文窗口中添加新的信息。最初只有用戶需求，隨后加入工具調(diào)用記錄、執(zhí)行結(jié)果、錯(cuò)誤信息以及各種中間狀態(tài)。上下文規(guī)模不斷膨脹，而模型需要在越來越復(fù)雜的信息中尋找真正重要的內(nèi)容。當(dāng)任務(wù)持續(xù)十幾輪甚至幾十輪之后，模型往往開始出現(xiàn)明顯的性能退化：它可能忘記最初目標(biāo)，重復(fù)嘗試已經(jīng)失敗的方法，或者陷入無意義的循環(huán)。

作者認(rèn)為，這并不是當(dāng)前模型能力不足所導(dǎo)致的暫時(shí)問題，而更像是一種結(jié)構(gòu)性的挑戰(zhàn)。即使未來模型支持百萬級(jí) Token 的上下文窗口，人們依然會(huì)發(fā)現(xiàn)，小而聚焦的上下文通常能夠獲得更好的結(jié)果。因?yàn)閱栴}不僅在于模型能夠容納多少信息，更在于模型如何有效關(guān)注真正重要的信息。隨著上下文增長，噪聲也會(huì)同步增長，而模型對(duì)關(guān)鍵信息的判斷能力反而可能下降。

正因?yàn)槿绱?，我們沒有否定 Agent 的價(jià)值，而是對(duì) Agent 的使用方式提出了不同看法。在實(shí)際生產(chǎn)環(huán)境中，表現(xiàn)最好的往往不是那些試圖解決所有問題的超級(jí) Agent，而是被嵌入到確定性工作流中的微型 Agent（Micro Agent）。在這種架構(gòu)下，整體業(yè)務(wù)流程依然由傳統(tǒng)軟件系統(tǒng)控制，而 Agent 只負(fù)責(zé)處理那些需要語言理解和靈活決策的局部環(huán)節(jié)。模型不再承擔(dān)整個(gè)系統(tǒng)的規(guī)劃任務(wù)，而是專注于解決一個(gè)范圍明確、上下文有限的問題。

建議1: 讓模型負(fù)責(zé)決策，而不是執(zhí)行

大語言模型最擅長的不是執(zhí)行，而是理解。

當(dāng)用戶提出一個(gè)需求時(shí)，模型最大的價(jià)值并不在于直接調(diào)用 API、修改數(shù)據(jù)庫或者完成業(yè)務(wù)操作，而在于理解人類自然語言中的意圖，并將這種意圖轉(zhuǎn)換成結(jié)構(gòu)化、機(jī)器能夠理解的指令。換句話說，LLM 應(yīng)該承擔(dān)“翻譯器”的角色，而不是“執(zhí)行者”的角色。

例如，當(dāng)用戶說：

請(qǐng)幫我給 Terri 創(chuàng)建一個(gè) 750 美元的付款鏈接，用于贊助二月份的 AI Tinkerers 活動(dòng)。

對(duì)于傳統(tǒng)軟件來說，這句話幾乎無法直接執(zhí)行，因?yàn)槠渲邪舜罅糠墙Y(jié)構(gòu)化信息。系統(tǒng)需要識(shí)別金額、收款對(duì)象、商品信息以及備注內(nèi)容，并最終轉(zhuǎn)換成 Stripe API 所需要的參數(shù)格式。而對(duì)于大語言模型而言，這正是它最擅長的任務(wù)——從自然語言中提取關(guān)鍵信息，并生成結(jié)構(gòu)化輸出。

因此，在作者看來，Agent 的第一步不應(yīng)該是讓模型完成整個(gè)任務(wù)，而應(yīng)該是讓模型輸出類似下面這樣的結(jié)構(gòu)化描述：

{
"function":"create_payment_link",
"parameters": {
"amount":750,
"customer":"...",
"product":"...",
"memo":"..."
}
}

此時(shí)，模型并沒有真正創(chuàng)建付款鏈接，它只是告訴系統(tǒng)：“我認(rèn)為下一步應(yīng)該執(zhí)行這個(gè)動(dòng)作，并且這些是所需參數(shù)?！?/span>

接下來，真正的業(yè)務(wù)邏輯交由確定性的代碼負(fù)責(zé)。系統(tǒng)根據(jù)模型返回的結(jié)構(gòu)化結(jié)果，調(diào)用對(duì)應(yīng)的 Stripe API，處理異常情況，記錄日志，并返回執(zhí)行結(jié)果。整個(gè)過程中，模型只負(fù)責(zé)決策，而代碼負(fù)責(zé)執(zhí)行。

這種設(shè)計(jì)思想看似簡單，卻代表著一種重要的職責(zé)劃分。過去很多 Agent 系統(tǒng)試圖讓模型同時(shí)承擔(dān)理解、規(guī)劃和執(zhí)行三種角色，但隨著系統(tǒng)復(fù)雜度提升，這種模式往往會(huì)導(dǎo)致不可預(yù)測(cè)的行為。而當(dāng)模型只負(fù)責(zé)“決定下一步應(yīng)該做什么”時(shí)，整個(gè)系統(tǒng)的穩(wěn)定性和可維護(hù)性都會(huì)顯著提高。

更進(jìn)一步地看，這也是作者重新定義 Agent 的開始。在傳統(tǒng)理解中，Tool Calling 往往被描述為一種特殊能力，好像模型擁有了調(diào)用外部世界的超能力。但作者認(rèn)為，所謂 Tool Calling 本質(zhì)上只是結(jié)構(gòu)化輸出（Structured Output）的一種形式。模型并沒有真正執(zhí)行工具，它只是生成了一段符合特定格式的數(shù)據(jù)。真正與外部系統(tǒng)交互的始終是開發(fā)者編寫的代碼。

這種理解方式能夠幫助我們擺脫很多關(guān)于 Agent 的誤區(qū)。很多開發(fā)者在設(shè)計(jì) Agent 時(shí)，會(huì)不斷思考應(yīng)該給模型增加哪些工具、開放哪些權(quán)限。然而從作者的視角來看，更值得關(guān)注的問題其實(shí)是：模型應(yīng)該輸出什么樣的決策結(jié)果，以及系統(tǒng)如何安全地執(zhí)行這些結(jié)果。工具本身只是實(shí)現(xiàn)細(xì)節(jié)，而自然語言到結(jié)構(gòu)化指令的轉(zhuǎn)換能力，才是大語言模型真正獨(dú)特的價(jià)值所在。

從工程實(shí)踐角度來看，這種模式還有一個(gè)重要優(yōu)勢(shì)，那就是可控性。因?yàn)槟Ｐ洼敵龅氖菢?biāo)準(zhǔn)化結(jié)構(gòu)，而不是直接執(zhí)行結(jié)果，所以開發(fā)者可以在執(zhí)行之前增加各種校驗(yàn)邏輯。例如檢查金額是否超過限制、確認(rèn)用戶權(quán)限是否滿足要求、驗(yàn)證參數(shù)是否合法，甚至引入人工審批流程。這樣一來，模型既能夠提供靈活的自然語言交互能力，又不會(huì)破壞系統(tǒng)原有的安全邊界。

事實(shí)上，如果觀察目前最成功的 AI 產(chǎn)品，會(huì)發(fā)現(xiàn)它們大多采用了類似思路。無論是代碼助手生成函數(shù)調(diào)用、客服機(jī)器人觸發(fā)工單流程，還是辦公助手創(chuàng)建日程和發(fā)送郵件，其核心模式都不是“模型直接完成任務(wù)”，而是“模型將用戶意圖轉(zhuǎn)換成系統(tǒng)能夠執(zhí)行的動(dòng)作”。從這個(gè)角度來看，自然語言到工具調(diào)用并不僅僅是 Agent 的一個(gè)實(shí)現(xiàn)技巧，它更像是一種新的軟件交互范式——讓人類繼續(xù)使用自然語言，而讓系統(tǒng)內(nèi)部保持結(jié)構(gòu)化和確定性。

不要讓模型直接做事，而要讓模型決定下一步應(yīng)該做什么事。

建議2: 把 Prompt 當(dāng)成代碼，而不是配置項(xiàng)

在 Agent 開發(fā)領(lǐng)域，一個(gè)非常普遍的現(xiàn)象是開發(fā)者高度依賴框架。許多框架為了降低使用門檻，會(huì)提供類似下面的抽象：

agent = Agent(...)
task = Task(...)
result = agent.run(task)

從開發(fā)體驗(yàn)來看，這種方式無疑是友好的。開發(fā)者只需要填寫角色（Role）、目標(biāo)（Goal）和工具（Tools），就能快速獲得一個(gè)能夠運(yùn)行的 Agent。對(duì)于原型驗(yàn)證或者概念演示而言，這種方式能夠極大縮短開發(fā)時(shí)間。然而，作者認(rèn)為，當(dāng)系統(tǒng)開始進(jìn)入真實(shí)生產(chǎn)環(huán)境后，這種便利往往會(huì)成為新的問題來源。

原因在于，大多數(shù) Agent 框架都會(huì)在底層隱藏大量 Prompt Engineering 邏輯。開發(fā)者看到的只是簡單的配置接口，而模型真正接收到的 Prompt 卻可能包含數(shù)百甚至上千個(gè) Token 的系統(tǒng)指令、行為規(guī)范和工具描述。這些內(nèi)容由框架維護(hù)，開發(fā)者很難完全掌握其細(xì)節(jié)。當(dāng) Agent 表現(xiàn)不符合預(yù)期時(shí)，人們往往不知道問題究竟出現(xiàn)在模型本身、上下文內(nèi)容，還是隱藏在框架中的 Prompt 模板。

因此，作者提出了一個(gè)看似簡單卻非常重要的原則：

不要把 Prompt 外包給框架。

在他看來，Prompt 不應(yīng)該被視為配置文件，而應(yīng)該被視為代碼的一部分。開發(fā)者需要像編寫業(yè)務(wù)邏輯一樣編寫 Prompt，像維護(hù)代碼一樣維護(hù) Prompt。

這種思想背后實(shí)際上反映了 Agent 開發(fā)與傳統(tǒng)軟件開發(fā)之間的重要差異。在傳統(tǒng)軟件中，程序邏輯主要存在于代碼之中；而在 Agent 系統(tǒng)中，Prompt 本身就是邏輯的一部分。它決定模型如何理解任務(wù)、如何規(guī)劃步驟、如何調(diào)用工具以及如何處理異常情況。從某種意義上說，Prompt 已經(jīng)不再是簡單的文本描述，而是一種新的編程接口。

當(dāng) Prompt 掌握在自己手中時(shí)，開發(fā)者能夠精確決定模型看到什么信息、遵循什么規(guī)則以及如何組織上下文，而不必受到框架默認(rèn)實(shí)現(xiàn)的限制。對(duì)于生產(chǎn)環(huán)境而言，這種控制能力往往比快速開發(fā)更加重要，因?yàn)楹芏鄬?shí)際問題最終都需要針對(duì)具體場(chǎng)景進(jìn)行細(xì)粒度調(diào)整。

第二個(gè)重要價(jià)值是可測(cè)試性。在傳統(tǒng)軟件工程中，我們會(huì)為核心邏輯編寫單元測(cè)試和評(píng)估指標(biāo)；作者認(rèn)為 Prompt 也應(yīng)該享受同樣待遇。如果 Prompt 是代碼，那么它就應(yīng)該能夠被版本管理、自動(dòng)測(cè)試和持續(xù)迭代。當(dāng)模型輸出出現(xiàn)異常時(shí)，開發(fā)者能夠快速定位是 Prompt 修改導(dǎo)致的問題，還是模型本身發(fā)生了變化。這種工程化能力對(duì)于長期維護(hù) Agent 系統(tǒng)尤為關(guān)鍵。

第三個(gè)價(jià)值來自迭代效率。現(xiàn)實(shí)中的 Prompt Engineering 并不存在放之四海而皆準(zhǔn)的最佳實(shí)踐。一個(gè)在客服場(chǎng)景表現(xiàn)優(yōu)異的 Prompt，未必適用于代碼生成或數(shù)據(jù)分析場(chǎng)景。因此，構(gòu)建生產(chǎn)級(jí) Agent 的過程本質(zhì)上是一個(gè)不斷實(shí)驗(yàn)和優(yōu)化的過程。如果 Prompt 被封裝在框架內(nèi)部，每一次調(diào)整都需要繞過框架限制；而當(dāng) Prompt 完全由自己管理時(shí)，開發(fā)者可以快速嘗試新的策略，不斷尋找最適合當(dāng)前業(yè)務(wù)的方案。

更深層次來看，作者實(shí)際上是在反對(duì)一種“框架萬能論”的思維方式。過去幾年軟件行業(yè)的發(fā)展證明，沒有任何框架能夠完全抽象業(yè)務(wù)邏輯。同樣，在 Agent 時(shí)代，也不存在一個(gè)能夠適用于所有場(chǎng)景的 Prompt 模板?？蚣芸梢詭椭覀兛焖倨鸩?，但最終決定 Agent 效果的，仍然是開發(fā)者對(duì)業(yè)務(wù)問題的理解，以及如何將這些理解轉(zhuǎn)化為模型能夠執(zhí)行的指令。

建議3: 真正決定 Agent 上限的，不是 Prompt，而是 Context

當(dāng)前 AI 領(lǐng)域有一個(gè)常見誤區(qū)：很多開發(fā)者把注意力集中在 Prompt Engineering 上，不斷調(diào)整系統(tǒng)提示詞、優(yōu)化角色設(shè)定或者修改輸出格式，卻忽略了模型真正接收到的信息遠(yuǎn)遠(yuǎn)不止 Prompt 本身。事實(shí)上，對(duì)于大語言模型來說，它看到的所有內(nèi)容——包括系統(tǒng)提示、歷史對(duì)話、工具調(diào)用記錄、RAG 檢索結(jié)果、長期記憶以及結(jié)構(gòu)化輸出要求——都屬于 Context 的組成部分。

因此，作者提出了一個(gè)極具代表性的觀點(diǎn)：

在 Agent 的任何一個(gè)時(shí)刻，模型面對(duì)的問題始終只有一個(gè)：

“這是目前為止發(fā)生的所有事情，下一步應(yīng)該做什么？”

從這個(gè)角度來看，LLM 本質(zhì)上是一個(gè)無狀態(tài)（Stateless）的函數(shù)。模型不會(huì)記住上一次調(diào)用發(fā)生了什么，它只能根據(jù)當(dāng)前輸入的信息生成輸出。也就是說，Agent 的能力并不來源于模型本身擁有記憶，而來源于開發(fā)者如何構(gòu)建和組織上下文。

這也是近年來越來越流行的“Context Engineering（上下文工程）”理念的核心。相比于調(diào)整 Temperature、Top-P 等參數(shù)，或者進(jìn)行復(fù)雜的模型微調(diào)，很多實(shí)際場(chǎng)景中的性能提升往往來自于更合理的上下文設(shè)計(jì)。因?yàn)槟Ｐ偷耐评碣|(zhì)量，很大程度上取決于它看到了什么信息，以及這些信息是如何組織的。

目前絕大多數(shù) Agent 框架都采用 OpenAI 所推廣的 Message 格式：

[
{"role":"system","content":"..."},
{"role":"user","content":"..."},
{"role":"assistant","tool_calls": [...]},
{"role":"tool","content":"..."}
]

這種格式已經(jīng)成為事實(shí)上的行業(yè)標(biāo)準(zhǔn)。它簡單、統(tǒng)一，并且兼容大多數(shù)模型 API。

然而作者認(rèn)為，標(biāo)準(zhǔn)并不意味著最優(yōu)。

對(duì)于簡單對(duì)話場(chǎng)景來說，這種結(jié)構(gòu)完全夠用。但當(dāng) Agent 需要處理復(fù)雜任務(wù)時(shí)，消息歷史會(huì)迅速膨脹。大量的 role 標(biāo)簽、工具調(diào)用包裝信息以及冗余字段不僅消耗 Token，還會(huì)分散模型的注意力。

從模型的角度來看，它真正關(guān)心的并不是：

{
"role":"tool",
"tool_call_id":"1"
}

而是：

調(diào)用了什么工具？

得到了什么結(jié)果？

當(dāng)前任務(wù)進(jìn)展到哪里？

因此，作者建議開發(fā)者不要被標(biāo)準(zhǔn)消息格式束縛，而應(yīng)該根據(jù)自己的業(yè)務(wù)場(chǎng)景設(shè)計(jì)最適合的 Context 結(jié)構(gòu)。

作者給出了一個(gè)非常有啟發(fā)性的思路：不要把 Context 理解為聊天記錄，而要把它理解為系統(tǒng)狀態(tài)。

例如，一個(gè)部署 Agent 的上下文可能并不是連續(xù)對(duì)話：

User: 請(qǐng)部署后端

Assistant: 好的

Tool: list_git_tags

Result: ...

而是被組織成一系列明確的事件：

<slack_message>
請(qǐng)部署最新版本后端
slack_message>

<list_git_tags>
...
list_git_tags>

<list_git_tags_result>
...
list_git_tags_result>

這種方式看起來更像日志系統(tǒng)或者事件流（Event Stream），而不是聊天記錄。

作者甚至建議開發(fā)者可以完全拋棄 Message 格式，將系統(tǒng)中的每一次事件抽象為結(jié)構(gòu)化對(duì)象，然后在調(diào)用模型時(shí)動(dòng)態(tài)轉(zhuǎn)換成最適合模型理解的形式。

這樣做的核心思想是：

不要為了適配框架而設(shè)計(jì) Context，而要為了幫助模型理解任務(wù)而設(shè)計(jì) Context。

很多開發(fā)者第一次接觸 RAG 時(shí)，會(huì)認(rèn)為 Context Engineering 就是向模型塞更多信息。

但作者認(rèn)為恰恰相反。優(yōu)秀的 Context Engineering 關(guān)注的不是信息量，而是信息密度。

建議4: 工具調(diào)用就是結(jié)構(gòu)化輸出

在 Agent 領(lǐng)域，“Tool Calling（工具調(diào)用）”幾乎已經(jīng)成為一個(gè)高頻詞匯。許多框架都會(huì)將其包裝成一種特殊能力：模型能夠調(diào)用函數(shù)、訪問數(shù)據(jù)庫、發(fā)送郵件、執(zhí)行代碼，甚至控制外部系統(tǒng)。初學(xué)者很容易產(chǎn)生一種印象，仿佛工具調(diào)用是一種獨(dú)立于文本生成之外的新能力。

Tool Calling 并不是什么特殊機(jī)制，本質(zhì)上只是結(jié)構(gòu)化輸出（Structured Output）。

這個(gè)觀點(diǎn)看似簡單，卻直接改變了理解 Agent 的方式。

當(dāng)用戶說：

幫我創(chuàng)建一個(gè) Jira 工單。

模型真正做的事情并不是調(diào)用 Jira API。

模型實(shí)際上只是在生成類似這樣的數(shù)據(jù)：

{
"intent":"create_issue",
"title":"Payment API Timeout",
"description":"...",
"assignee":"alice"
}

隨后，系統(tǒng)讀取這段 JSON：

ifresult.intent =="create_issue":
jira.create_issue(...)

真正調(diào)用 Jira API 的始終是程序代碼，而不是模型。

從這個(gè)角度來看，無論是 OpenAI 的 Function Calling、Anthropic 的 Tool Use，還是各種 Agent Framework 中的 Tool Calling，本質(zhì)上都只是讓模型按照特定 Schema 輸出 JSON 而已。

作者希望開發(fā)者意識(shí)到：

所謂工具，不過是模型輸出的一種結(jié)構(gòu)化數(shù)據(jù)格式。

模型從來沒有真正執(zhí)行任何工具。

很多 Agent 框架會(huì)建立一種強(qiáng)綁定關(guān)系：

Tool
↓
Function
↓
Execute

例如：

CreateIssue()

對(duì)應(yīng)：

create_issue()

模型輸出工具名稱后，系統(tǒng)立即執(zhí)行對(duì)應(yīng)函數(shù)。這種模式非常普遍，但作者認(rèn)為這實(shí)際上限制了開發(fā)者的想象空間。因?yàn)楫?dāng)我們把 Tool 理解為 Function 時(shí)，就會(huì)下意識(shí)認(rèn)為：

模型輸出什么工具，就必須執(zhí)行什么函數(shù)。

但如果把 Tool 看成一種結(jié)構(gòu)化意圖（Intent），事情就完全不同了。

例如：

{
"intent":"deploy_backend"
}

系統(tǒng)收到這個(gè)結(jié)果后，可以有很多種處理方式：

• 立即執(zhí)行部署；
• 先發(fā)起審批流程；
• 檢查部署窗口；
• 寫入任務(wù)隊(duì)列；
• 創(chuàng)建異步任務(wù)；
• 等待人工確認(rèn)。

換句話說：

Tool 描述的是“想做什么”，而不是“怎么做”。

如何執(zhí)行，始終由業(yè)務(wù)代碼決定。這里實(shí)際上體現(xiàn)了作者一貫強(qiáng)調(diào)的設(shè)計(jì)哲學(xué)：LLM 負(fù)責(zé)決策層。軟件負(fù)責(zé)執(zhí)行層。

因?yàn)楹芏?Agent 系統(tǒng)最終失控，恰恰是因?yàn)殚_發(fā)者把 Tool Calling 想得過于強(qiáng)大。

例如：

模型調(diào)用：
DeleteCustomer

如果系統(tǒng)立刻執(zhí)行：

delete_customer()

風(fēng)險(xiǎn)顯然非常高。

但如果系統(tǒng)理解為：

{
"intent":"delete_customer",
"customer_id":"123"
}

那么開發(fā)者可以在執(zhí)行前加入：

• 權(quán)限校驗(yàn)；
• 審批流程；
• 風(fēng)險(xiǎn)評(píng)估；
• 人工確認(rèn)；
• 審計(jì)日志；

Agent 不應(yīng)該直接控制系統(tǒng)，而應(yīng)該提出建議，由軟件系統(tǒng)決定如何落實(shí)這些建議。

這樣既保留了 LLM 的靈活性，又不會(huì)犧牲系統(tǒng)穩(wěn)定性。

從更高層次來看，作者實(shí)際上是在重新定義 Tool 的角色。工具不是能力。工具不是函數(shù)。

工具甚至不是執(zhí)行邏輯。工具本質(zhì)上只是模型輸出的一份結(jié)構(gòu)化決策結(jié)果。

而真正復(fù)雜的業(yè)務(wù)流程、權(quán)限控制、異步執(zhí)行、錯(cuò)誤恢復(fù)和狀態(tài)管理，仍然應(yīng)該掌握在軟件系統(tǒng)手中。

不要把 Tool Calling 看成模型在執(zhí)行代碼，而應(yīng)該把它看成模型在輸出下一步行動(dòng)的結(jié)構(gòu)化建議。

當(dāng)開發(fā)者接受這一視角后，Agent 就不再是一個(gè)試圖接管整個(gè)系統(tǒng)的黑盒，而變成了一個(gè)負(fù)責(zé)決策的軟件組件。這也為下一節(jié) Factor 5 埋下伏筆——既然 Tool 只是狀態(tài)變化的一種描述，那么 Agent 的執(zhí)行狀態(tài)（Execution State）和業(yè)務(wù)狀態(tài)（Business State）是否真的應(yīng)該分開管理？這正是作者接下來要討論的問題。

建議5: 讓狀態(tài)回歸單一事實(shí)來源

隨著 Agent 系統(tǒng)變得越來越復(fù)雜，開發(fā)者往往會(huì)不自覺地引入大量狀態(tài)管理機(jī)制。為了跟蹤任務(wù)執(zhí)行過程，系統(tǒng)會(huì)維護(hù)當(dāng)前步驟（Current Step）、下一步動(dòng)作（Next Step）、等待狀態(tài)（Waiting Status）、重試次數(shù)（Retry Count）、任務(wù)隊(duì)列狀態(tài)等信息；與此同時(shí)，還需要記錄用戶請(qǐng)求、工具調(diào)用結(jié)果、模型回復(fù)以及各種業(yè)務(wù)事件。久而久之，一個(gè) Agent 系統(tǒng)中便出現(xiàn)了兩套并行存在的狀態(tài)體系：一套用于描述系統(tǒng)正在如何運(yùn)行，另一套用于描述業(yè)務(wù)已經(jīng)發(fā)生了什么。

作者將這兩類狀態(tài)分別稱為執(zhí)行狀態(tài)（Execution State）和業(yè)務(wù)狀態(tài)（Business State）。

其中，執(zhí)行狀態(tài)關(guān)注的是工作流層面的信息。例如 Agent 當(dāng)前執(zhí)行到哪一步、是否正在等待用戶回復(fù)、是否需要重試某個(gè)任務(wù)、下一次喚醒時(shí)間是什么等。這類狀態(tài)通常由框架或者工作流引擎維護(hù)。而業(yè)務(wù)狀態(tài)則記錄任務(wù)本身的進(jìn)展，例如用戶發(fā)起了什么請(qǐng)求、模型調(diào)用了哪些工具、工具返回了什么結(jié)果、人工審核給出了什么反饋等。這些信息通常會(huì)進(jìn)入上下文窗口，成為后續(xù)推理的依據(jù)。

在很多傳統(tǒng)工作流系統(tǒng)中，這兩類狀態(tài)被嚴(yán)格分離。例如一個(gè)工作流引擎會(huì)單獨(dú)維護(hù)任務(wù)狀態(tài)機(jī)，而業(yè)務(wù)數(shù)據(jù)則存儲(chǔ)在數(shù)據(jù)庫中。這樣的設(shè)計(jì)在大型分布式系統(tǒng)中有其合理性，但作者認(rèn)為，對(duì)于大量 Agent 場(chǎng)景而言，這種分離往往帶來了不必要的復(fù)雜度。

如果可能，不要維護(hù)兩套狀態(tài)系統(tǒng)，而是盡可能統(tǒng)一執(zhí)行狀態(tài)和業(yè)務(wù)狀態(tài)。

作者認(rèn)為，在許多 Agent 應(yīng)用中，所謂的執(zhí)行狀態(tài)其實(shí)完全可以從業(yè)務(wù)歷史中推導(dǎo)出來。換句話說，系統(tǒng)不一定需要額外保存“當(dāng)前執(zhí)行到第幾步”這樣的字段，因?yàn)閺囊呀?jīng)發(fā)生的事件記錄中，我們往往就能夠知道 Agent 當(dāng)前處于什么階段。

如果 Agent 的所有行為都被記錄為事件流（Event Stream），那么整個(gè)系統(tǒng)實(shí)際上就變成了一個(gè)事件驅(qū)動(dòng)架構(gòu)。當(dāng)前狀態(tài)并不是存儲(chǔ)出來的，而是計(jì)算出來的。

這種設(shè)計(jì)思想與 Event Sourcing（事件溯源）有著明顯的相似之處。在事件溯源架構(gòu)中，系統(tǒng)不會(huì)直接存儲(chǔ)當(dāng)前狀態(tài)，而是存儲(chǔ)所有發(fā)生過的事件。當(dāng)需要恢復(fù)狀態(tài)時(shí)，只需重新回放這些事件即可。作者實(shí)際上是在將這一思想引入 Agent 設(shè)計(jì)之中。

這種統(tǒng)一狀態(tài)的方式首先帶來的好處是系統(tǒng)結(jié)構(gòu)大幅簡化。當(dāng)執(zhí)行狀態(tài)和業(yè)務(wù)狀態(tài)共享同一套數(shù)據(jù)結(jié)構(gòu)時(shí)，整個(gè)系統(tǒng)只需要維護(hù)一個(gè)事實(shí)來源（Single Source of Truth）。開發(fā)者無需擔(dān)心兩套狀態(tài)之間的數(shù)據(jù)同步問題，也不需要處理狀態(tài)不一致帶來的各種邊界情況。

其次，這種設(shè)計(jì)天然具備良好的可序列化能力。由于 Agent 的所有狀態(tài)都包含在事件歷史中，因此整個(gè)線程（Thread）可以輕松保存到數(shù)據(jù)庫，也可以隨時(shí)重新加載。對(duì)于需要長時(shí)間運(yùn)行的 Agent 來說，這一點(diǎn)尤為重要。無論任務(wù)中斷多久，只要重新讀取歷史記錄，就能夠恢復(fù)到原來的運(yùn)行狀態(tài)，而不需要額外恢復(fù)復(fù)雜的執(zhí)行上下文。

在調(diào)試方面，這種設(shè)計(jì)也具有明顯優(yōu)勢(shì)。傳統(tǒng) Agent 系統(tǒng)出現(xiàn)問題時(shí)，開發(fā)者往往需要同時(shí)查看日志、數(shù)據(jù)庫狀態(tài)、工作流狀態(tài)機(jī)以及消息隊(duì)列等多個(gè)組件。而在統(tǒng)一狀態(tài)模型下，所有信息都集中在同一個(gè)線程中。開發(fā)者只需要查看事件歷史，就能夠完整還原 Agent 的決策過程和執(zhí)行過程。這種可觀察性對(duì)于生產(chǎn)環(huán)境中的問題定位極為重要。

更有趣的是，統(tǒng)一狀態(tài)還為 Agent 提供了天然的“時(shí)間旅行”能力。由于所有歷史事件都被完整保存，因此開發(fā)者可以從任意一個(gè)歷史節(jié)點(diǎn)重新開始執(zhí)行。例如當(dāng)某一步?jīng)Q策出現(xiàn)問題時(shí)，可以復(fù)制某個(gè)歷史節(jié)點(diǎn)之前的全部事件，創(chuàng)建一個(gè)新的線程，讓 Agent 基于相同歷史重新嘗試另一種解決方案。這種能力類似于 Git 中的分支（Branch）機(jī)制，也類似于工作流系統(tǒng)中的回溯執(zhí)行。

此外，統(tǒng)一狀態(tài)模型對(duì)于人機(jī)協(xié)作場(chǎng)景也十分友好。因?yàn)槭录鞅旧砭途邆漭^強(qiáng)的可讀性，開發(fā)者可以很容易地將其轉(zhuǎn)換為 Markdown 報(bào)告、聊天記錄、審批流程頁面或者可視化工作流界面。換句話說，同一份數(shù)據(jù)既可以作為模型的上下文，也可以作為用戶的操作界面來源。

當(dāng)然，作者并沒有主張所有數(shù)據(jù)都必須進(jìn)入上下文窗口。一些敏感信息，例如 Session ID、訪問令牌、密碼、數(shù)據(jù)庫連接信息等，通常不應(yīng)該直接暴露給模型。這些內(nèi)容依然可以保存在系統(tǒng)層面，由業(yè)務(wù)邏輯負(fù)責(zé)管理。但作者強(qiáng)調(diào)的重點(diǎn)在于：

真正無法進(jìn)入上下文窗口的數(shù)據(jù)應(yīng)該越少越好。

因?yàn)橐坏┫到y(tǒng)維護(hù)了大量獨(dú)立于上下文之外的狀態(tài)，Agent 的行為就會(huì)越來越依賴外部環(huán)境，從而失去可恢復(fù)性和可解釋性。

前面幾個(gè)原則已經(jīng)分別解決了模型如何決策、如何組織 Prompt、如何管理 Context 以及如何理解 Tool Calling 的問題。而這一節(jié)則進(jìn)一步回答了一個(gè)工程層面的問題：

Agent 的狀態(tài)究竟應(yīng)該保存在哪里？

作者給出的答案非常直接：

最理想的情況是，Agent 的歷史記錄就是 Agent 的狀態(tài)。

當(dāng)上下文、歷史記錄和狀態(tài)逐漸融合為同一個(gè)概念時(shí)，Agent 系統(tǒng)的復(fù)雜度會(huì)顯著下降，而可恢復(fù)性、可觀測(cè)性和可維護(hù)性則會(huì)大幅提升。

建議6: 讓 Agent 像普通程序一樣運(yùn)行

一個(gè)成熟的 Agent 不應(yīng)該被封裝在復(fù)雜的編排框架內(nèi)部，而應(yīng)該像普通服務(wù)一樣擁有簡單、清晰的生命周期管理能力。無論是用戶、業(yè)務(wù)系統(tǒng)、自動(dòng)化流水線，還是其他 Agent，都應(yīng)該能夠通過簡單的 API 啟動(dòng)一個(gè) Agent，而不需要了解其內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)。

更重要的是，Agent 不應(yīng)該假設(shè)所有任務(wù)都能一次性完成。在真實(shí)業(yè)務(wù)場(chǎng)景中，很多操作都需要較長時(shí)間。例如等待人工審批、等待第三方 API 返回結(jié)果、等待異步任務(wù)執(zhí)行完成，甚至等待用戶幾小時(shí)后回復(fù)消息。如果 Agent 在等待期間始終保持運(yùn)行狀態(tài)，不僅會(huì)浪費(fèi)資源，也會(huì)增加系統(tǒng)復(fù)雜度。

因此，作者強(qiáng)調(diào) Agent 必須具備Pause（暫停）和Resume（恢復(fù)）的能力。當(dāng) Agent 遇到需要等待的情況時(shí)，可以直接暫停執(zhí)行并保存當(dāng)前狀態(tài)；當(dāng)外部事件發(fā)生后，例如收到 Webhook、用戶回復(fù)消息或異步任務(wù)完成通知，再從原來的位置繼續(xù)執(zhí)行。這種模式類似于工作流系統(tǒng)中的“掛起與喚醒”，但作者希望它能夠以更加輕量化的方式實(shí)現(xiàn)。

這里的關(guān)鍵在于，恢復(fù) Agent 不應(yīng)該依賴復(fù)雜的編排器（Orchestrator）。如果 Agent 的狀態(tài)已經(jīng)完整保存在事件歷史中，那么恢復(fù)過程實(shí)際上非常簡單：重新加載歷史記錄，將新的事件追加進(jìn)去，然后再次調(diào)用模型推理下一步動(dòng)作即可。整個(gè)過程更像是恢復(fù)一個(gè)線程（Thread），而不是恢復(fù)一個(gè)復(fù)雜的運(yùn)行時(shí)環(huán)境。

從工程實(shí)踐角度看，這種設(shè)計(jì)帶來了很大的靈活性。一個(gè) Agent 可以由 Slack 消息啟動(dòng)，由 GitHub Webhook 喚醒，由審批系統(tǒng)暫停，再由 CI/CD 流水線恢復(fù)。各種外部系統(tǒng)都能夠參與 Agent 的執(zhí)行過程，而無需與某個(gè)特定框架深度耦合。

Agent 不應(yīng)該是一段持續(xù)運(yùn)行的循環(huán)，而應(yīng)該是一種能夠隨時(shí)啟動(dòng)、暫停和恢復(fù)的任務(wù)。

當(dāng) Agent 具備這種能力后，它就不再是一個(gè)封閉的 AI 系統(tǒng)，而成為企業(yè)軟件架構(gòu)中的一個(gè)標(biāo)準(zhǔn)組件，可以自然地融入現(xiàn)有業(yè)務(wù)流程和自動(dòng)化系統(tǒng)之中。

建議7: 把人類也視為一種“工具”

傳統(tǒng) Agent 的設(shè)計(jì)通常遵循一個(gè)默認(rèn)假設(shè)：模型要么輸出自然語言回復(fù)，要么調(diào)用工具執(zhí)行任務(wù)。然而作者認(rèn)為，這種二元選擇本身可能限制了 Agent 的能力。因?yàn)樵谡鎸?shí)業(yè)務(wù)流程中，很多關(guān)鍵決策并不應(yīng)該由模型獨(dú)立完成，而是需要人類參與其中。

不要把人與 Agent 的交互看成聊天，而應(yīng)該把“聯(lián)系人類”視為一種特殊的工具調(diào)用。

例如，當(dāng) Agent 準(zhǔn)備執(zhí)行生產(chǎn)環(huán)境部署時(shí)，它不一定直接調(diào)用部署工具，而是先輸出一個(gè)結(jié)構(gòu)化意圖：

{
"intent":"request_human_input",
"question":"是否繼續(xù)部署到生產(chǎn)環(huán)境？"
}

此時(shí)系統(tǒng)并不會(huì)繼續(xù)執(zhí)行，而是暫停 Agent，將問題發(fā)送給相關(guān)負(fù)責(zé)人。等到用戶通過 Slack、郵件或其他渠道回復(fù)后，再將回復(fù)作為新的事件加入上下文，恢復(fù) Agent 的執(zhí)行流程。

這種設(shè)計(jì)的核心價(jià)值在于，它將人工反饋納入了 Agent 的標(biāo)準(zhǔn)工作流。對(duì)于模型來說，人類審批、用戶確認(rèn)和業(yè)務(wù)決策與調(diào)用 API 沒有本質(zhì)區(qū)別，都是獲取下一步行動(dòng)所需信息的一種方式。這樣不僅能夠提高系統(tǒng)安全性，也能讓 Agent 更自然地融入企業(yè)現(xiàn)有流程。

作者進(jìn)一步指出，這種模式突破了傳統(tǒng)聊天機(jī)器人的限制。在 ChatGPT 這類產(chǎn)品中，通常是“人發(fā)起對(duì)話，Agent 響應(yīng)”。但在很多企業(yè)場(chǎng)景中，流程恰恰相反。一個(gè) Agent 可能由定時(shí)任務(wù)、監(jiān)控告警或業(yè)務(wù)事件觸發(fā)，然后主動(dòng)聯(lián)系相關(guān)人員獲取信息。例如部署 Agent 主動(dòng)請(qǐng)求審批，采購 Agent 主動(dòng)詢問預(yù)算確認(rèn)，或者運(yùn)維 Agent 主動(dòng)通知故障處理人員。這種模式被作者稱為Outer Loop Agent（外循環(huán) Agent）。

當(dāng)“聯(lián)系人類”被抽象成工具調(diào)用后，整個(gè)系統(tǒng)的擴(kuò)展能力也會(huì)明顯增強(qiáng)。Agent 不僅可以向一個(gè)人發(fā)起請(qǐng)求，還可以同時(shí)協(xié)調(diào)多個(gè)審批人；不僅可以與人溝通，也可以與其他 Agent 進(jìn)行結(jié)構(gòu)化協(xié)作。從系統(tǒng)視角來看，無論是人類回復(fù)還是 Agent 回復(fù)，都只是事件流中的一種輸入。

結(jié)合前面的狀態(tài)統(tǒng)一（Factor 5）和暫?；謴?fù)機(jī)制（Factor 6），這種模式還能構(gòu)建出持久化、多參與者協(xié)同的工作流。即使任務(wù)持續(xù)數(shù)小時(shí)甚至數(shù)天，Agent 依然能夠準(zhǔn)確記錄每一次請(qǐng)求和響應(yīng)，并在需要時(shí)從原來的位置繼續(xù)執(zhí)行。

在生產(chǎn)級(jí) Agent 中，人類不是系統(tǒng)之外的參與者，而是工作流中的一個(gè)節(jié)點(diǎn)。

當(dāng) Agent 學(xué)會(huì)通過結(jié)構(gòu)化工具主動(dòng)聯(lián)系和協(xié)調(diào)人類時(shí)，它就不再只是一個(gè)聊天機(jī)器人，而開始真正融入現(xiàn)實(shí)世界的業(yè)務(wù)流程之中。

建議8: 不要把工作流控制權(quán)交給 Agent 框架

在許多 Agent 框架中，開發(fā)者通常只負(fù)責(zé)定義 Prompt 和工具，而整個(gè)執(zhí)行過程則由框架內(nèi)部的 Agent Loop 自動(dòng)管理。模型選擇工具、執(zhí)行工具、接收結(jié)果，再繼續(xù)推理下一步，直到任務(wù)結(jié)束。這種方式看起來十分方便，但作者認(rèn)為，真正的生產(chǎn)級(jí) Agent 不應(yīng)該把控制流完全交給框架。

Agent 可以負(fù)責(zé)決策，但工作流的控制權(quán)必須掌握在開發(fā)者手中。

作者認(rèn)為，不同類型的工具調(diào)用對(duì)應(yīng)著不同的處理策略。例如，當(dāng)模型需要查詢 Git 標(biāo)簽時(shí)，系統(tǒng)完全可以立即執(zhí)行工具并將結(jié)果返回給模型；但如果模型請(qǐng)求生產(chǎn)環(huán)境部署，或者需要用戶審批，那么系統(tǒng)就應(yīng)該暫停執(zhí)行，等待人工確認(rèn)后再繼續(xù)。對(duì)于需要長時(shí)間運(yùn)行的任務(wù)，例如模型訓(xùn)練、數(shù)據(jù)處理或外部審批流程，也同樣如此。

這意味著 Agent 的執(zhí)行流程不應(yīng)該只有簡單的“調(diào)用工具 → 返回結(jié)果”模式，而應(yīng)該允許開發(fā)者根據(jù)業(yè)務(wù)需求自由定義控制邏輯。什么時(shí)候繼續(xù)循環(huán)、什么時(shí)候暫停、什么時(shí)候等待事件觸發(fā)恢復(fù)，都應(yīng)該由業(yè)務(wù)代碼決定，而不是由框架預(yù)設(shè)。

這種設(shè)計(jì)帶來的最大價(jià)值是靈活性。開發(fā)者可以在控制流中加入各種工程能力，例如上下文壓縮、緩存機(jī)制、日志追蹤、性能監(jiān)控、限流控制、結(jié)果評(píng)審（LLM-as-Judge）以及長時(shí)間休眠和事件喚醒機(jī)制。這些能力往往是生產(chǎn)環(huán)境真正需要的部分，卻很難通過標(biāo)準(zhǔn) Agent Loop 實(shí)現(xiàn)。

作者特別強(qiáng)調(diào)了一個(gè)長期困擾 Agent 開發(fā)的問題：

Agent 應(yīng)該能夠在“選擇工具”和“執(zhí)行工具”之間被中斷。

例如，當(dāng)模型決定執(zhí)行刪除數(shù)據(jù)、部署系統(tǒng)或發(fā)起支付等高風(fēng)險(xiǎn)操作時(shí)，系統(tǒng)應(yīng)該能夠先暫停下來，讓人類審核這次工具調(diào)用，而不是直接執(zhí)行。遺憾的是，許多現(xiàn)有框架并不支持這種粒度的控制，模型一旦選中工具，系統(tǒng)便立即調(diào)用對(duì)應(yīng)函數(shù)。

如果缺少這種中斷能力，開發(fā)者往往只能在三種不理想的方案之間做選擇：要么讓 Agent 一直阻塞等待結(jié)果，要么將 Agent 限制在低風(fēng)險(xiǎn)場(chǎng)景中使用，要么放任 Agent 執(zhí)行高風(fēng)險(xiǎn)操作并承擔(dān)潛在后果。無論哪一種，都難以滿足生產(chǎn)環(huán)境的要求。

LLM 負(fù)責(zé)決定“做什么”，而系統(tǒng)負(fù)責(zé)決定“什么時(shí)候做、如何做以及是否允許做”。

只有當(dāng)控制流掌握在開發(fā)者手中時(shí)，Agent 才能真正融入復(fù)雜業(yè)務(wù)流程，而不是淪為一個(gè)不可預(yù)測(cè)的黑盒。

建議9: 讓錯(cuò)誤成為 Agent 學(xué)習(xí)的一部分

Agent 相比傳統(tǒng)程序的一個(gè)重要優(yōu)勢(shì)在于其具備一定的“自我修復(fù)（Self-Healing）”能力。當(dāng)工具調(diào)用失敗時(shí)，模型并不一定需要人工介入，它往往能夠通過閱讀錯(cuò)誤信息、異常日志甚至堆棧信息，理解失敗原因，并嘗試調(diào)整下一次行動(dòng)。

因此，作者建議將錯(cuò)誤信息直接作為一種特殊事件寫入上下文窗口，而不是簡單地終止任務(wù)。這樣，模型在下一輪推理時(shí)不僅能看到之前的決策過程，也能看到執(zhí)行失敗的原因，從而自主尋找新的解決方案。例如，當(dāng) API 參數(shù)填寫錯(cuò)誤、資源不存在或權(quán)限不足時(shí)，模型可能會(huì)根據(jù)錯(cuò)誤提示重新構(gòu)造正確的工具調(diào)用。

這種機(jī)制本質(zhì)上是將“錯(cuò)誤反饋”納入 Agent 的推理循環(huán)之中。傳統(tǒng)軟件中的異常通常意味著流程終止，而在 Agent 系統(tǒng)中，錯(cuò)誤可以成為下一步?jīng)Q策的重要輸入。通過這種方式，Agent 能夠在短流程任務(wù)中實(shí)現(xiàn)一定程度的自動(dòng)恢復(fù)，而無需頻繁依賴人工干預(yù)。

不過，作者也提醒，這種能力并非無限有效。如果持續(xù)把原始錯(cuò)誤不斷追加到上下文中，模型很容易陷入“錯(cuò)誤循環(huán)（Error Spin-Out）”——不斷重復(fù)同樣的失敗嘗試，卻始終無法找到新的解決方案。因此，實(shí)際系統(tǒng)中通常需要設(shè)置錯(cuò)誤閾值，例如連續(xù)失敗三次后停止自動(dòng)重試，并將任務(wù)升級(jí)給人工處理。

更進(jìn)一步地，錯(cuò)誤信息并不一定要原封不動(dòng)地進(jìn)入上下文。開發(fā)者完全可以結(jié)合前面提到的上下文工程（Factor 3）和控制流管理（Factor 8），對(duì)錯(cuò)誤進(jìn)行壓縮、總結(jié)或重構(gòu)。例如只保留關(guān)鍵失敗原因，刪除已經(jīng)解決的歷史錯(cuò)誤，甚至將多次失敗總結(jié)為一句簡潔的狀態(tài)描述，從而減少上下文污染。

作者認(rèn)為，錯(cuò)誤壓縮的真正目標(biāo)并不是讓 Agent 無限重試，而是在有限次數(shù)內(nèi)幫助模型快速定位問題并恢復(fù)執(zhí)行。當(dāng)達(dá)到恢復(fù)極限時(shí)，系統(tǒng)應(yīng)該主動(dòng)切換到人工介入或其他處理流程，而不是任由 Agent 在錯(cuò)誤中不斷循環(huán)。

不要把錯(cuò)誤視為流程終點(diǎn)，而要把錯(cuò)誤視為上下文的一部分。

合理利用錯(cuò)誤信息能夠增強(qiáng) Agent 的恢復(fù)能力，但真正避免錯(cuò)誤失控的最佳方法。

建議10: 讓 Agent 專注于一件事

在很多人剛開始構(gòu)建 Agent 時(shí)，都會(huì)產(chǎn)生一種理想化設(shè)想：既然大模型具備推理能力，那么是否可以構(gòu)建一個(gè)萬能 Agent，讓它負(fù)責(zé)所有任務(wù)、調(diào)用所有工具并處理所有業(yè)務(wù)流程。然而作者認(rèn)為，這恰恰是許多 Agent 項(xiàng)目最終失敗的重要原因。

不要構(gòu)建無所不能的大型 Agent，而要構(gòu)建多個(gè)小而專注的 Agent。

這一觀點(diǎn)的出發(fā)點(diǎn)并非軟件架構(gòu)設(shè)計(jì)，而是來自大語言模型本身的能力邊界。隨著任務(wù)復(fù)雜度增加，Agent 需要經(jīng)歷更多推理步驟，產(chǎn)生更長的上下文窗口。而上下文越長，模型越容易遺忘早期信息、混淆目標(biāo)或者陷入錯(cuò)誤循環(huán)。很多 Agent 并不是因?yàn)楣ぞ卟蛔愣。窃诓粩鄶U(kuò)展任務(wù)范圍后逐漸失去焦點(diǎn)。

因此，作者建議將 Agent 的職責(zé)控制在一個(gè)清晰且有限的領(lǐng)域內(nèi)。一個(gè) Agent 最好只負(fù)責(zé)完成某一類任務(wù)，例如代碼部署、客戶支持、故障診斷或文檔生成。其工作流程通常保持在 3 到 10 個(gè)步驟以內(nèi)，即使復(fù)雜場(chǎng)景也盡量不要超過 20 個(gè)步驟。這樣既能保證上下文規(guī)?？煽?，也能讓模型始終聚焦于當(dāng)前目標(biāo)。

從工程實(shí)踐角度看，小型 Agent 也更符合現(xiàn)代軟件設(shè)計(jì)思想。每個(gè) Agent 都擁有明確職責(zé)和邊界，便于測(cè)試、維護(hù)和調(diào)試。當(dāng)出現(xiàn)問題時(shí)，開發(fā)者能夠快速定位故障來源，而不需要在一個(gè)龐大的 Agent 系統(tǒng)中排查復(fù)雜的推理鏈路。同時(shí)，不同 Agent 還可以像微服務(wù)一樣進(jìn)行組合，共同完成更大的業(yè)務(wù)流程。

與其構(gòu)建一個(gè)什么都會(huì)做但經(jīng)常失敗的 Agent，不如構(gòu)建多個(gè)能力邊界清晰、行為穩(wěn)定可靠的小 Agent。

當(dāng) Agent 保持專注時(shí)，上下文更短、錯(cuò)誤更少、可控性更強(qiáng)，而這恰恰是生產(chǎn)級(jí) AI 系統(tǒng)最重要的品質(zhì)。

建議11: 讓 Agent 出現(xiàn)在用戶所在的地方

在很多人的認(rèn)知中，Agent 通常存在于聊天界面中：用戶打開一個(gè)對(duì)話窗口，輸入問題，然后等待模型給出答案。然而作者認(rèn)為，這種理解實(shí)際上過于狹隘。真正能夠融入企業(yè)流程和日常工作的 Agent，不應(yīng)該局限于某一個(gè)聊天產(chǎn)品，而應(yīng)該能夠在任何渠道被觸發(fā)，并通過用戶習(xí)慣的渠道與人協(xié)作。

不要要求用戶來到 Agent 面前，而應(yīng)該讓 Agent 主動(dòng)出現(xiàn)在用戶工作的地方。

在實(shí)際業(yè)務(wù)場(chǎng)景中，用戶每天使用的工具可能是 Slack、電子郵件、短信、企業(yè)微信、工單系統(tǒng)或監(jiān)控平臺(tái)，而不是專門打開一個(gè) AI 應(yīng)用。因此，一個(gè)成熟的 Agent 應(yīng)該能夠從這些渠道接收任務(wù)，并通過相同渠道返回結(jié)果。例如，用戶可以直接在 Slack 中發(fā)起部署請(qǐng)求，通過郵件審批生產(chǎn)變更，或者在手機(jī)短信中確認(rèn)某項(xiàng)關(guān)鍵操作。整個(gè)過程無需切換工作環(huán)境，Agent 自然融入現(xiàn)有工作流之中。

這一理念與前面提到的暫停恢復(fù)機(jī)制（Factor 6）和人類協(xié)作機(jī)制（Factor 7）緊密相關(guān)。當(dāng) Agent 在執(zhí)行過程中遇到關(guān)鍵決策時(shí)，可以主動(dòng)聯(lián)系相關(guān)負(fù)責(zé)人獲取反饋；獲得回復(fù)后，再自動(dòng)恢復(fù)執(zhí)行。對(duì)于用戶而言，這更像是在與一位數(shù)字同事協(xié)作，而不是操作一個(gè)復(fù)雜的軟件系統(tǒng)。

更重要的是，Agent 的觸發(fā)者不一定是人。作者提出了“Outer Loop Agent（外循環(huán) Agent）”的概念，即 Agent 可以由各種外部事件自動(dòng)啟動(dòng)。例如監(jiān)控系統(tǒng)發(fā)現(xiàn)服務(wù)異常、CI/CD 流水線完成構(gòu)建、定時(shí)任務(wù)到達(dá)執(zhí)行時(shí)間，或者業(yè)務(wù)系統(tǒng)觸發(fā)某個(gè)狀態(tài)變更，這些都可以成為 Agent 的啟動(dòng)信號(hào)。Agent 在后臺(tái)自主工作數(shù)分鐘甚至數(shù)小時(shí)，當(dāng)遇到需要判斷、審批或協(xié)助的問題時(shí)，再主動(dòng)聯(lián)系相關(guān)人員。

與此同時(shí)，當(dāng) Agent 能夠快速聯(lián)系到正確的人并獲得反饋時(shí)，企業(yè)也更容易賦予其更高權(quán)限。例如發(fā)送客戶郵件、修改生產(chǎn)環(huán)境數(shù)據(jù)、執(zhí)行系統(tǒng)部署等高風(fēng)險(xiǎn)操作。因?yàn)槊恳淮侮P(guān)鍵行為都可以通過結(jié)構(gòu)化流程進(jìn)行審批和審計(jì)，所以即使 Agent 擁有更大的行動(dòng)能力，系統(tǒng)依然保持可追蹤和可控。

最優(yōu)秀的 Agent 往往不是用戶主動(dòng)尋找的工具，而是在恰當(dāng)?shù)臅r(shí)候主動(dòng)出現(xiàn)、主動(dòng)協(xié)作、主動(dòng)推動(dòng)事情向前發(fā)展的數(shù)字同事。

建議12: 把 Agent 看成狀態(tài)轉(zhuǎn)換器

如果 Agent 本質(zhì)上只是根據(jù)已有上下文決定下一步行動(dòng)，那么它是否可以被設(shè)計(jì)成一個(gè)完全無狀態(tài)（Stateless）的組件？

這個(gè)想法來源于函數(shù)式編程中的Reducer（歸約器）概念。在 Redux、Event Sourcing 等架構(gòu)中，系統(tǒng)當(dāng)前狀態(tài)并不是保存在程序內(nèi)部，而是通過歷史事件不斷累積計(jì)算出來的。Reducer 的職責(zé)非常簡單：

輸入當(dāng)前狀態(tài)和一個(gè)事件，輸出新的狀態(tài)。

在這種架構(gòu)下，Agent 并不需要維護(hù)復(fù)雜的內(nèi)部狀態(tài)，它只需要讀取當(dāng)前上下文，然后根據(jù)這些信息生成下一個(gè)動(dòng)作即可。

換句話說，Agent 更像是一個(gè)純函數(shù)：

當(dāng)前上下文 + 新事件
↓
Agent推理
↓
下一步動(dòng)作

新的動(dòng)作執(zhí)行后會(huì)產(chǎn)生新的事件，而這些事件又會(huì)進(jìn)入上下文，成為下一輪推理的輸入。整個(gè)系統(tǒng)不斷重復(fù)這一過程，就像一個(gè)持續(xù)運(yùn)行的狀態(tài)機(jī)。

這種設(shè)計(jì)最大的價(jià)值在于簡化系統(tǒng)復(fù)雜度。由于 Agent 本身不保存狀態(tài)，因此無需考慮內(nèi)存同步、狀態(tài)恢復(fù)或分布式一致性等問題。任何時(shí)候，只要重新加載事件歷史，就可以完整重建當(dāng)前狀態(tài)，并從任意位置恢復(fù)執(zhí)行。這與前面強(qiáng)調(diào)的“統(tǒng)一狀態(tài)”“暫停恢復(fù)”“事件驅(qū)動(dòng)”等原則形成了高度一致的整體架構(gòu)。

從更深層次來看，這也是作者對(duì) Agent 本質(zhì)的一種重新定義。在很多 Agent 框架中，開發(fā)者習(xí)慣把 Agent 看作一個(gè)擁有記憶、擁有生命周期、能夠自主運(yùn)行的復(fù)雜實(shí)體。但作者認(rèn)為，這種理解容易導(dǎo)致過度設(shè)計(jì)。事實(shí)上，Agent 完全可以被簡化為一個(gè)狀態(tài)轉(zhuǎn)換器：

它不保存世界狀態(tài)，只負(fù)責(zé)根據(jù)上下文推導(dǎo)下一步。

當(dāng) Agent 被設(shè)計(jì)成無狀態(tài)組件后，它就變得更容易測(cè)試、更容易擴(kuò)展，也更容易在不同服務(wù)之間遷移和復(fù)用。系統(tǒng)真正的核心不再是 Agent 本身，而是圍繞事件流構(gòu)建的上下文和工作流。

Agent 不是魔法，也不是一個(gè)無所不能的智能體，它本質(zhì)上仍然是軟件工程。

優(yōu)秀的 Agent 系統(tǒng)并非依賴復(fù)雜的框架和龐大的自主能力，而是通過精心設(shè)計(jì)的上下文、清晰的控制流、可靠的人機(jī)協(xié)作機(jī)制以及可維護(hù)的軟件架構(gòu)，讓 LLM 在最擅長的環(huán)節(jié)發(fā)揮價(jià)值。