從 0 到生產(chǎn)，用這個方法讓 AI Agent 少走了 3 個月彎路！

你有沒有發(fā)現(xiàn)，很多團隊在構建 AI agent 時都在犯同一個錯誤？他們一上來就搞多 agent 編排、自主推理循環(huán)、復雜的基礎設施，然后花幾周時間調(diào)試為什么最簡單的任務都無法完成。這種過度設計的問題在整個行業(yè)里普遍存在，導致大量項目半途而廢。最近我讀到 Ashpreet Bedi 分享的一篇文章，他提出了一個讓我深有感觸的觀點：構建 AI agent 應該遵循一個簡單得有些"丟人"的原則——從最簡單的開始，逐步增加能力，在每一步都驗證行為。這個理念看似平淡無奇，卻道出了軟件工程的本質(zhì)。

我在實際工作中也經(jīng)常看到這種現(xiàn)象。團隊急于展示技術實力，想要一步到位構建出復雜的 AI 系統(tǒng)，結果卻陷入了無休止的調(diào)試和重構。反而是那些從最小可行產(chǎn)品開始，一步步迭代的團隊，最終交付了真正可用的產(chǎn)品。Ashpreet Bedi 在文章中系統(tǒng)地總結了構建 agentic software（agent 化軟件）的五個架構層級：帶工具的 agent、帶存儲和知識的 agent、帶記憶和學習的 agent、多 agent 團隊，以及生產(chǎn)系統(tǒng)。他通過構建一個名為 Gcode 的輕量級編程 agent 來演示每個層級，這種循序漸進的方法論對我啟發(fā)很大。

為什么大多數(shù)團隊一開始就錯了

在深入探討這五個層級之前，我想先談談為什么這個漸進式的方法如此重要。我觀察到一個有趣的現(xiàn)象：在 AI agent 領域，技術門檻的降低反而導致了更多的過度設計。因為大語言模型讓構建 agent 看起來很容易，很多團隊誤以為只要堆砌足夠多的功能，就能得到一個強大的系統(tǒng)。這種想法從根本上就是錯誤的。

軟件工程有一個經(jīng)典原則：提前優(yōu)化是萬惡之源。在 AI agent 開發(fā)中，這個原則同樣適用。過早地引入復雜架構，不僅增加了開發(fā)和維護成本，更重要的是，它會掩蓋真正的問題所在。當你的 agent 無法完成任務時，你很難判斷是架構設計的問題，還是提示詞的問題，還是工具選擇的問題。而如果你從最簡單的版本開始，每次只添加一個能力，那么問題定位就會容易得多。

Ashpreet Bedi 的五層架構正是基于這種遞進式的思維。每一層都解決了上一層明確存在的問題，而不是預先設想可能出現(xiàn)的問題。這種務實的態(tài)度在快速變化的 AI 領域尤其重要。技術在快速演進，今天看起來必要的復雜架構，可能明天就被更簡單的方案取代了。保持架構的靈活性和可演進性，遠比一開始就追求完美重要。

Level 1：給 Agent 裝上手腳

第一層的核心理念非常直接：沒有工具的 agent 只是一個大語言模型。它能推理，但做不了任何實際的事情。Tools（工具）是將 LLM 轉變?yōu)?agent 的關鍵。Ashpreet Bedi 在構建編程 agent Gcode 時，定義了最小可行工具集：讀取文件、寫入文件、運行 shell 命令。這三個工具構成了一個編程 agent 的基礎能力。

我特別認同這個最小化的起點。很多人在設計 agent 時，會一口氣給它配備十幾種甚至幾十種工具，認為工具越多能力越強。但實際情況往往相反。工具太多會導致 agent 在選擇時犯錯，它可能會用錯誤的工具，或者在多個相似工具之間搖擺不定。從認知負荷的角度看，這就像讓一個人同時學習二十種樂器，結果可能是一種都學不好。

在第一層，agent 接收任務，使用 CodingTools（編程工具集）來編寫、編輯和運行代碼。這個過程是完全無狀態(tài)的，每次運行都從零開始。Agent 無法回憶之前的會話，無法遵循項目約定，除非你把這些信息粘貼到提示詞中。這聽起來很受限，但這恰恰是它的優(yōu)勢所在。限制迫使你專注于核心功能：agent 能否完成最基本的任務？工具的抽象是否合理？提示詞是否清晰？

我在實際項目中發(fā)現(xiàn)，很多看似需要復雜架構的問題，其實用第一層的簡單 agent 就能解決。關鍵在于明確定義任務邊界。如果你的任務確實簡單且自包含，那么一個無狀態(tài)的 agent 配合幾個精心選擇的工具，完全可以勝任。不要因為技術上"可以"做得更復雜，就真的去做。

Level 2：賦予 Agent 記憶和知識

第一層的最大問題是什么？每次運行都要重新開始，所有東西都必須放在上下文中。這在處理簡單任務時還能接受，但當你需要多輪對話、需要遵循特定規(guī)范、需要訪問大量背景信息時，這種無狀態(tài)的方式就不夠用了。第二層通過兩個關鍵添加解決了這個問題：session storage（會話存儲）和 domain knowledge（領域知識）。

Storage 的價值在于它保存了每個 agent 會話及其中的每次運行到數(shù)據(jù)庫中。這帶來兩個重要好處。一是可以將聊天歷史作為上下文，agent 能夠包含最近的 N 條消息在其上下文窗口中，知道正在發(fā)生什么。對于更長的會話，你可以運行壓縮算法來總結早期上下文，保持窗口專注于當前重要的內(nèi)容。二是創(chuàng)建了完整的行為記錄。不是所有東西都需要發(fā)送給第三方追蹤服務，把會話存在自己的數(shù)據(jù)庫里是理解 agent 做了什么、何時做的、為什么做的最簡單方式。你擁有數(shù)據(jù)，可以查詢它、審計它、在上面構建儀表板。

Knowledge 的引入則解決了另一個關鍵問題。今天的編程 agent 只能看到代碼庫中的文件，別的什么都看不到。它們無法訪問你的架構規(guī)范、團隊的設計決策、內(nèi)部會議記錄，或者某個 Slack 討論串里解釋為什么選擇 Postgres 而不是 DynamoDB 的內(nèi)容。這就是 knowledge 要解決的問題。它給 agent 提供了一個可搜索的存儲庫，里面是所有對項目重要但不需要一直待在上下文窗口中的內(nèi)容：規(guī)范、RFP、運維手冊、架構決策記錄、會議筆記、團隊對話。

這里有個關鍵洞察：大量有價值的上下文存在于代碼庫之外。如果你的團隊上個月在會議中討論了遷移策略，那么當編程 agent 處理遷移工作時，這個上下文應該是可用的。如果半年前有人決定使用庫 X 而不是庫 Y，agent 應該能夠在它準備刪掉 X 重新開始之前找到這個決策的理由。我在實際工作中深刻體會到這一點。很多技術決策的背景信息散落在郵件、文檔、聊天記錄中，新加入的團隊成員很難獲取，結果常常重復犯同樣的錯誤或者推翻之前深思熟慮的決策。

Ashpreet Bedi 在實現(xiàn)中使用了 ChromaDb 作為向量數(shù)據(jù)庫，支持混合搜索（hybrid search），既能進行語義匹配也能進行關鍵詞匹配。這種設計很聰明，因為不同類型的查詢需要不同的搜索策略。有時你需要精確匹配某個術語，有時你需要理解語義相似性。Agent 在編碼前會先搜索 knowledge，如果你的風格指南說"使用 snake_case"，agent 會找到并遵循它。這就是基礎的 Agentic RAG（檢索增強生成）。

什么時候應該使用第二層？當 agent 需要遵循它訓練時沒見過的標準，或者當用戶期望多輪對話時。這是大多數(shù)內(nèi)部工具的最佳選擇。我認為很多企業(yè)級應用其實停留在這一層就足夠了，不需要更復雜的功能。關鍵是要清楚地識別你的實際需求，而不是被新技術的光環(huán)所迷惑。

Level 3：Agent 開始學習和進化

從第二層到第三層的跳躍是最重要的一次飛躍。在第二層，agent 遵循你給它的規(guī)則。在第三層，它從經(jīng)驗中學習規(guī)則。這個區(qū)別看似微妙，實則根本。Ashpreet Bedi 提出了一個簡潔有力的標準：第 1000 次交互應該比第 1 次交互更好。這就是學習的本質(zhì)。

第三層引入了 Learning Machine（學習機器）。Agent 獲得了 save_learning 和 search_learnings 兩個工具，它自己決定什么值得記住：有效的編程模式、要避免的錯誤、用戶偏好。這些學習成果被存儲在一個獨立的 knowledge base（知識庫）中，并在未來的會話中被調(diào)用。同時，agentic memory（agent 記憶）讓 agent 能夠隨時間構建用戶畫像：你偏好的編程風格、你使用的框架、你喜歡的解釋方式。

我覺得這一層的設計哲學特別有意思。它不是簡單地記錄所有交互歷史，而是讓 agent 自主判斷什么值得學習。這種選擇性記憶更接近人類的學習方式。我們不會記住每一個細節(jié)，而是提取出模式、原則和偏好。這種抽象能力讓 agent 能夠?qū)⒔?jīng)驗泛化到新的情境中，而不只是死記硬背。

Ashpreet Bedi 給出了一個"兩次會話測試"的例子。在第一次會話中，用戶表達了對函數(shù)式編程風格的偏好——不用類，使用純函數(shù)和不可變數(shù)據(jù)。在第二次會話中，當用戶要求編寫日志解析器時，agent 應該搜索它的學習記錄，找到函數(shù)式編程偏好，并寫出函數(shù)式代碼。這個測試很好地展示了學習的價值：agent 不需要每次都重新告知偏好，它能夠記住并應用。

什么時候應該使用第三層？當 agent 反復服務同一批用戶，并且應該隨時間改進時。個人編程助手、具有共享學習的團隊工具、任何"按我們喜歡的方式做"很重要的場景。我認為這是 AI agent 真正開始展現(xiàn)價值的層級。前兩層更多是效率工具，而第三層開始具備了個性化和適應能力，這讓它從工具變成了助手。

我在思考這一層時想到一個問題：agent 的學習應該有邊界嗎？它應該學習所有用戶偏好，還是只學習某些類型的偏好？如果用戶的偏好本身是錯誤的或低效的，agent 應該盲目遵循還是提出質(zhì)疑？這些問題沒有簡單答案，但它們指向了一個更深層的設計哲學：我們希望 agent 扮演什么角色——服從的執(zhí)行者，還是能夠提供建議的顧問？

Level 4：多 Agent 協(xié)作的承諾與陷阱

有時候一個 agent 確實不夠。第四層將職責分散到由團隊領導協(xié)調(diào)的專業(yè)化 agent 之間。Ashpreet Bedi 的示例很直觀：Coder 負責編寫代碼，Reviewer 負責審查質(zhì)量、bug 和最佳實踐，Tester 負責編寫和運行測試。每個 agent 都有明確的角色和工具權限。注意 Reviewer 的工具配置：禁用了寫文件、編輯文件和運行 shell 的能力，只能讀取。這種權限控制確保了 agent 只做它應該做的事。

多 agent 團隊在概念上很吸引人。它模仿了人類團隊的工作方式，每個成員有專長，通過協(xié)作完成復雜任務。在代碼審查場景中，這種分工特別自然：一個人寫，另一個人審，第三個人測試。但 Ashpreet Bedi 在這里給出了一個非常誠實的警告：多 agent 團隊強大但不可預測。團隊領導是一個 LLM，在做委派決策。有時它委派得很好，有時不行。對于需要可靠性的生產(chǎn)系統(tǒng)，顯式工作流優(yōu)于動態(tài)團隊。團隊在有人類監(jiān)督的場景中表現(xiàn)最好，人類可以審查輸出。

這個警告很重要，因為它道出了多 agent 系統(tǒng)的核心問題：控制的喪失。當你把決策權交給一個 LLM 協(xié)調(diào)者時，你就失去了對執(zhí)行路徑的精確控制。在演示中，這種動態(tài)性看起來很酷，像是 AI 的"智能涌現(xiàn)"。但在生產(chǎn)環(huán)境中，不可預測性是可靠性的大敵。我認為這是當前多 agent 系統(tǒng)最大的局限所在。

什么時候應該使用第四層？當你需要多個視角時（代碼審查是完美例子），當任務自然分解為專家角色時，或者當你構建交互式工具、人類可以監(jiān)督團隊時。我的觀點更加保守：除非你有非常明確的理由，否則優(yōu)先考慮單個設計良好的 agent。多 agent 系統(tǒng)的復雜性成本很高，只有在收益明顯大于成本時才值得付出。

我想補充一點我的觀察。在很多宣傳多 agent 架構的案例中，真正帶來價值的往往不是"多個 agent"，而是"明確的職責分工"和"結構化的工作流程"。這些好處在單 agent 架構中同樣可以實現(xiàn)，只是方式不同。與其讓多個 agent 動態(tài)協(xié)作，不如讓一個 agent 按照明確定義的步驟工作，每個步驟使用不同的工具或提示詞配置。這種方法在可控性和可調(diào)試性上都更勝一籌。

Level 5：走向生產(chǎn)環(huán)境的最后一公里

第五層是將前四層轉變?yōu)樯a(chǎn)服務的運行時環(huán)境。你需要從開發(fā)數(shù)據(jù)庫升級到生產(chǎn)數(shù)據(jù)庫，添加追蹤，并將所有內(nèi)容作為 API 暴露出來。Ashpreet Bedi 在這里的做法很務實：用 PostgreSQL 和 PgVector 替換 SQLite 和 ChromaDb，獲得真正的連接池、真正的備份、真正的并發(fā)訪問能力。

AgentOS 的概念很有意思。它將你的 agent 包裝在一個 FastAPI 應用中，提供內(nèi)置的 Web UI、會話管理和追蹤功能。這種"開箱即用"的方法大大降低了將 agent 投入生產(chǎn)的門檻。你不需要自己搭建整套基礎設施，只需配置好 agent，AgentOS 就能幫你處理其余部分。啟用追蹤（tracing=True）讓你能夠觀察每個工具調(diào)用、每次知識搜索、每個委派決策，這對于調(diào)試生產(chǎn)問題至關重要。

什么時候應該使用第五層？當 agent 離開你的筆記本電腦時。多用戶、正常運行時間要求、需要調(diào)試生產(chǎn)問題的場景。我認為這一層的重要性常被低估。很多團隊在開發(fā)環(huán)境中做出了很棒的 agent，但在生產(chǎn)化時遇到了各種問題：性能、可擴展性、可觀測性、安全性。提前規(guī)劃這些非功能性需求，比后期打補丁要容易得多。

我想強調(diào)一個常被忽視的點：生產(chǎn)環(huán)境的 agent 需要運維。它不是部署后就能一勞永逸的。你需要監(jiān)控它的表現(xiàn)、收集用戶反饋、定期更新知識庫、調(diào)整提示詞、處理邊緣情況。這需要投入持續(xù)的人力和時間。所以在決定構建生產(chǎn)級 agent 之前，確保你有資源來維護它。

最重要的建議：從簡單開始

讀完 Ashpreet Bedi 的文章，我最大的收獲是這條建議：從第一層開始。構建能夠解決問題的最簡單 agent。運行它，看它在哪里失敗，然后只添加它缺失的那個能力。這聽起來很簡單，但在實踐中很難做到。我們總是被新技術、新架構的誘惑所吸引，想要一次性構建出最先進的系統(tǒng)。

大多數(shù)團隊直接跳到第四層，因為多 agent 架構在演示中看起來很酷。然后他們花幾個月時間調(diào)試協(xié)調(diào)失敗的問題，而這些問題一個設計良好的單 agent 加上好的指令就能避免。這種過度設計的誘惑在技術行業(yè)很普遍，但在 AI agent 領域尤其危險，因為調(diào)試成本特別高。

把這五個層級想象成能力和復雜性的層次結構。記住，每一層都增加了復雜性，而復雜性是有成本的。只在更簡單的方法明確失敗后才付出這個成本。這種紀律性的方法不僅能讓你更快地交付可用的產(chǎn)品，還能讓你更深入地理解每個能力的價值和代價。

我的個人觀點是，這種漸進式方法的價值不僅在于技術層面，更在于認知層面。當你從簡單開始時，你被迫真正理解問題的本質(zhì)。你不能用復雜架構來掩蓋對問題的模糊認識。你必須清楚地定義：這個 agent 要解決什么問題？它需要什么能力？如何驗證它是否成功？這些基礎問題的答案，比任何花哨的架構都重要。

在快速變化的 AI 領域，保持架構的簡單和靈活比追求完美更有價值。今天看起來必要的復雜功能，明天可能就被更簡單的方案取代了。與其構建一個復雜但脆弱的系統(tǒng)，不如構建一個簡單但可演進的系統(tǒng)。這種思維方式不僅適用于 AI agent，也適用于所有軟件開發(fā)。

最后我想說，Ashpreet Bedi 提供的這個框架不是教條，而是指南。你可能會發(fā)現(xiàn)你的場景需要不同的層級劃分，或者需要跳過某些層級。關鍵是理解每個能力的作用和代價，然后根據(jù)你的具體需求做出明智的選擇。盲目遵循任何框架都是危險的，但完全忽視前人的經(jīng)驗也同樣危險。在兩者之間找到平衡，才是優(yōu)秀工程師的特質(zhì)。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內(nèi)容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產(chǎn)出更好的內(nèi)容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產(chǎn)品創(chuàng)業(yè)方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業(yè)化才是未來