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

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

為什么大多數(shù)團(tuán)隊(duì)一開(kāi)始就錯(cuò)了

在深入探討這五個(gè)層級(jí)之前，我想先談?wù)劄槭裁催@個(gè)漸進(jìn)式的方法如此重要。我觀(guān)察到一個(gè)有趣的現(xiàn)象：在 AI agent 領(lǐng)域，技術(shù)門(mén)檻的降低反而導(dǎo)致了更多的過(guò)度設(shè)計(jì)。因?yàn)榇笳Z(yǔ)言模型讓構(gòu)建 agent 看起來(lái)很容易，很多團(tuán)隊(duì)誤以為只要堆砌足夠多的功能，就能得到一個(gè)強(qiáng)大的系統(tǒng)。這種想法從根本上就是錯(cuò)誤的。

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

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

Level 1：給 Agent 裝上手腳

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

我特別認(rèn)同這個(gè)最小化的起點(diǎn)。很多人在設(shè)計(jì) agent 時(shí)，會(huì)一口氣給它配備十幾種甚至幾十種工具，認(rèn)為工具越多能力越強(qiáng)。但實(shí)際情況往往相反。工具太多會(huì)導(dǎo)致 agent 在選擇時(shí)犯錯(cuò)，它可能會(huì)用錯(cuò)誤的工具，或者在多個(gè)相似工具之間搖擺不定。從認(rèn)知負(fù)荷的角度看，這就像讓一個(gè)人同時(shí)學(xué)習(xí)二十種樂(lè)器，結(jié)果可能是一種都學(xué)不好。

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

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

Level 2：賦予 Agent 記憶和知識(shí)

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

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

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

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

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

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

Level 3：Agent 開(kāi)始學(xué)習(xí)和進(jìn)化

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

第三層引入了 Learning Machine（學(xué)習(xí)機(jī)器）。Agent 獲得了 save_learning 和 search_learnings 兩個(gè)工具，它自己決定什么值得記?。河行У木幊棠Ｊ?、要避免的錯(cuò)誤、用戶(hù)偏好。這些學(xué)習(xí)成果被存儲(chǔ)在一個(gè)獨(dú)立的 knowledge base（知識(shí)庫(kù)）中，并在未來(lái)的會(huì)話(huà)中被調(diào)用。同時(shí)，agentic memory（agent 記憶）讓 agent 能夠隨時(shí)間構(gòu)建用戶(hù)畫(huà)像：你偏好的編程風(fēng)格、你使用的框架、你喜歡的解釋方式。

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

Ashpreet Bedi 給出了一個(gè)"兩次會(huì)話(huà)測(cè)試"的例子。在第一次會(huì)話(huà)中，用戶(hù)表達(dá)了對(duì)函數(shù)式編程風(fēng)格的偏好——不用類(lèi)，使用純函數(shù)和不可變數(shù)據(jù)。在第二次會(huì)話(huà)中，當(dāng)用戶(hù)要求編寫(xiě)日志解析器時(shí)，agent 應(yīng)該搜索它的學(xué)習(xí)記錄，找到函數(shù)式編程偏好，并寫(xiě)出函數(shù)式代碼。這個(gè)測(cè)試很好地展示了學(xué)習(xí)的價(jià)值：agent 不需要每次都重新告知偏好，它能夠記住并應(yīng)用。

什么時(shí)候應(yīng)該使用第三層？當(dāng) agent 反復(fù)服務(wù)同一批用戶(hù)，并且應(yīng)該隨時(shí)間改進(jìn)時(shí)。個(gè)人編程助手、具有共享學(xué)習(xí)的團(tuán)隊(duì)工具、任何"按我們喜歡的方式做"很重要的場(chǎng)景。我認(rèn)為這是 AI agent 真正開(kāi)始展現(xiàn)價(jià)值的層級(jí)。前兩層更多是效率工具，而第三層開(kāi)始具備了個(gè)性化和適應(yīng)能力，這讓它從工具變成了助手。

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

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

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

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

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

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

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

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

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

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

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

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

最重要的建議：從簡(jiǎn)單開(kāi)始

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

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

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

我的個(gè)人觀(guān)點(diǎn)是，這種漸進(jìn)式方法的價(jià)值不僅在于技術(shù)層面，更在于認(rèn)知層面。當(dāng)你從簡(jiǎn)單開(kāi)始時(shí)，你被迫真正理解問(wèn)題的本質(zhì)。你不能用復(fù)雜架構(gòu)來(lái)掩蓋對(duì)問(wèn)題的模糊認(rèn)識(shí)。你必須清楚地定義：這個(gè) agent 要解決什么問(wèn)題？它需要什么能力？如何驗(yàn)證它是否成功？這些基礎(chǔ)問(wèn)題的答案，比任何花哨的架構(gòu)都重要。

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

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

結(jié)尾

也歡迎大家留言討論，分享你的觀(guān)點(diǎn)！

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

歡迎關(guān)注深思圈，一起探索更大的世界。

- END -

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

速度將成為AI時(shí)代唯一的護(hù)城河

a16z重磅預(yù)測(cè)：Vibe coding贏(yíng)者通吃？錯(cuò)了，垂直專(zhuān)業(yè)化才是未來(lái)