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

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

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

為什么大多數團隊一開始就錯了

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

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

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

Level 1：給 Agent 裝上手腳

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

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

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

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

Level 2：賦予 Agent 記憶和知識

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

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

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

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

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

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

Level 3：Agent 開始學習和進化

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

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

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

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

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

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

Level 4：多 Agent 協作的承諾與陷阱

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

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

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

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

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

Level 5：走向生產環境的最后一公里

第五層是將前四層轉變為生產服務的運行時環境。你需要從開發數據庫升級到生產數據庫，添加追蹤，并將所有內容作為 API 暴露出來。Ashpreet Bedi 在這里的做法很務實：用 PostgreSQL 和 PgVector 替換 SQLite 和 ChromaDb，獲得真正的連接池、真正的備份、真正的并發訪問能力。

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

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

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

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

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

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

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

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

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

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

結尾

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

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

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

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

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

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