知名開源大佬爆料：Agent 設計依舊很難、很混亂！只有手動管理緩存，才能做到性能最優！ 原創
編輯 | 聽雨
出品 | 51CTO技術棧（微信號：blog51cto）
如何設計和構建一個既可靠又高效的 AI Agent？表面上看，似乎只要接入幾個 SDK、調用幾行代碼就行，但實際操作遠比想象復雜得多。
最近，小編刷到一篇博文，作者是 Web 框架 Flask 的創造者、Sentry 的首批工程師之一 Armin Ronacher，他分享了自己在構建 AI Agent 過程中的實戰經驗，以及遇到的各種坑。
圖片
這篇文章也被 Django 聯合創始人、Datasette 開源項目作者 Simon Willson 轉發，他指出：Armin 的總結對于正在嘗試構建 Agent 的開發者來說，非常有參考價值。
圖片
在 Armin 看來，構建 Agent 依舊是一件“混亂”的事情：
- SDK 抽象一旦遇到真實工具調用就容易崩潰；
- 緩存如果自己管理效果更好，但不同模型行為差異巨大；
- 強化信號承擔的工作量比預期更大，而失敗案例必須嚴格隔離，否則整個循環可能被帶偏；
- 基于類似文件系統的共享狀態是關鍵基礎設施；
- 輸出工具設計意外的復雜；
- 模型選擇依舊取決于具體任務。
選擇哪個 Agent SDK？
當你要構建自己的 Agent 時，你可以選擇直接使用底層 SDK，例如 OpenAI SDK 或 Anthropic SDK，也可以使用更高一層的抽象，比如 Vercel AI SDK 或 Pydantic。
我們之前選擇了 Vercel AI SDK，但只用它的 provider abstraction，其余的 Agent loop 則自己實現。如果現在再選，我們不會再做同樣的決定。
這并不是說 Vercel AI SDK 有什么問題，完全沒有。問題是當你真正開始構建 Agent，會出現兩個我們當初沒有預料到的現象：
1. 不同模型差異巨大，迫使你必須自己做 Agent 抽象
我們至今沒有看到任何一個 SDK 提供的抽象能真正適合 Agent 的需求。雖然從表面看 Agent 就是一個循環（loop），但一旦你給模型綁定工具，這個循環會變得微妙而復雜。這些差異決定了你是否能找到“正確的抽象層”（例如 cache 控制、強化機制需求、工具提示詞、provider 側工具、等等）。
由于正確抽象尚未清晰，直接使用各平臺原生 SDK 可以保持絕對掌控。反之，一些高層 SDK 讓你必須疊加在它們已有的抽象之上，這些抽象最終可能并不適用于你。
2. Vercel SDK 與 provider-side tools 搭配非常困難
我們發現 Vercel SDK 在處理“模型提供方內置工具”（例如 Anthropic 的 web search）時非常困難。
統一消息格式的嘗試并沒有真正成功。例如：
- Anthropic 的 web search 工具經常破壞消息歷史（history 會被打亂或結構被毀）
- 我們仍不知道根因是什么
- 在使用 Anthropic 原生 SDK 時，這些問題完全沒有出現
- Anthropic 自家 SDK 在緩存管理上也簡單得多
- 出錯時原生 SDK 的錯誤信息清晰太多
也許未來會改善，但就當前來說，在構建 Agent 時我們不會依賴抽象層。現在的實際情況是：這些抽象層帶來的成本遠高于收益。
如果有人已經解決了這些問題、覺得我錯了，請務必給我發郵件。我很想學習。
緩存：只有手動管理，才能做到性能最優
不同平臺在緩存方面的策略差異巨大。外界已經討論過不少，比如 Anthropic 會對緩存收費，并要求你顯式管理緩存點。這一點極大改變了 Agent 工程中的交互方式。
起初我覺得這種手動管理方式很蠢，“平臺為什么不替我做掉？”但現在我完全改變了想法，并且強烈偏好顯式緩存管理。因為它讓成本可預測、緩存命中可控。顯式緩存讓一些原本很難實現的事情變得容易。例如：
- 你可以從某個對話點分叉，讓兩條路徑并行運行。
- 你可以編輯上下文（context editing）。
最佳實踐尚不明確，但顯然顯式緩存讓你擁有更大靈活性。我很喜歡這種操控感。同時，也大幅提升了你預測 Agent 成本的能力——你能基本確定緩存是否能被有效利用，而在其他平臺上，這件事完全是運氣。
在 Anthropic 中，我們的 Agent 緩存策略大致如下：
- 一個緩存點放在 system prompt 后面；
- 兩個緩存點放在對話開頭，最后一個隨著對話尾部往上移動；
- 中間對緩存還可以做一些優化。
因為 system prompt 和工具選擇必須保持大致靜態，所以我們把動態信息（如當前時間）放在后面單獨輸入，否則會破壞緩存。我們也在循環中更積極地使用強化機制。
在 Agent Loop 中使用強化
每當 Agent 調用一個工具，你不僅可以返回工具的結果，還可以把更多信息注入循環。例如：
- 提醒 Agent 它的總體目標
- 更新任務進度
- 在工具失敗時，給出成功可能需要的提示
- 如果有并行處理，在背景狀態變化后同步信息
有時 Agent 自我強化就足夠了。例如 Claude Code 里的 todo write tool 本質上就是一個回顯工具，只會回顯 Agent 提出的任務列表。盡管非常簡單，但它能幫助 Agent 持續前進，比只在上下文開頭列出任務要好得多。
我們還會在環境發生變化、可能導致錯誤恢復失敗時，注入信息提醒 Agent：“你可能需要回退幾步重新來。”
隔離失敗：不要讓一次錯誤毀掉整個 Agent
如果你預期在代碼執行中會出現大量失敗，有兩種方式把失敗從上下文中隔離掉：
- 把容易反復失敗的任務交給子 Agent單獨跑等它成功后，再把成功結果和少量失敗總結反饋回主 Agent。這樣既能學習失敗經驗，又不會污染主循環。
- 使用上下文編輯（并非所有平臺支持）你可以從上下文中刪除那些“只會讓 Agent 亂掉”的失敗輸出，從而把 token 留給后續循環使用。但缺點是：一旦編輯上下文，緩存必然失效。是否值得，是一筆要精算的 trade-off。
子 Agent / 子推理
我們的大多數 Agent 都依賴代碼執行與代碼生成，因此必須有一個共享數據的地方。我們選擇了一個虛擬文件系統（VFS）。
如果你有 subagent 或 subinference，這尤其重要。
關鍵原則是：避免死胡同。
一個“死胡同”的例子：你有一個生成圖片的工具，但它只能把圖片傳給另一個工具，而不能被 code execution 工具訪問，這樣你就無法把圖片打包成 zip、轉碼、分析等等。
解決方法是：所有工具都能讀寫同一個文件系統，ExecuteCode和 RunInference能共享文件路徑。
這么一來：
- 你可以用 code execution 解壓 zip
- 再回到 inference 去描述圖片
- 再繼續返回 code execution 做下一步處理
- 整個流程順暢循環
文件系統就是讓各種工具交互的基礎結構。
“輸出工具”比想象的更難做
我們設計的 Agent 并不是聊天機器人。它最終確實會向用戶輸出內容，但中間所有消息通常不會展示給人類。
那么它是如何生成最終輸出的？我們有一個專門的輸出工具，Agent 通過它向用戶（或外部系統）發送最終結果。在我們的系統中，輸出工具的作用是發送郵件。
但這帶來了幾個意料之外的挑戰：
1. 輸出工具的措辭出奇地難控制
比用普通的文本響應困難得多。原因不明，但可能與模型訓練方式有關。
2. 用另一小 LLM 修飾語氣失敗了
我們曾讓輸出工具調用一個小模型（如 Gemini 2.5 Flash）進行語氣微調，但結果不好：
- 延遲變大
- 輸出質量變差
- 小模型上下文不足
- 傳更多上下文會貴且仍然不夠好
- 有時還會泄露內部 Agent 步驟（我們不希望被用戶看到）
3. 有時 Agent 壓根不會調用輸出工具
為解決這個問題，我們會記錄是否調用過輸出工具。如果循環結束還沒調用，我們就注入強化消息鼓勵它調用。
模型選擇：Haiku/Sonnet 是最好用的工具調用模型
總體來說，我們的模型選擇最近沒有出現特別大的變化。我認為 Haiku 和 Sonnet 依然是最優秀的工具調用模型，因此非常適合作為 agent loop 的核心模型。它們的強化學習（RL）機制也相對透明。
另一個顯而易見的選擇是 Gemini 系列。而我們的經驗是：GPT 系列在主循環上并沒有取得太多成功。
對于一些需要推理的子工具（sub-tools），我們目前傾向使用 Gemini 2.5，特別是在處理大文檔摘要、PDF 解析等場景。它在圖像信息提取方面也很不錯，尤其是因為 Sonnet 系列模型經常觸發安全過濾器，比較煩人。
另外，還有一個顯而易見但經常被忽視的事實：
Token 單價并不能真正決定 Agent 的成本。一款更聰明的 tool caller 會用更少 token 完成任務。
市面上確實有比 Sonnet 更便宜的模型，但在循環結構里它們可能反而更貴。
總體而言，這幾周在模型選擇上并沒有太多變化。
測試與評估：整個 Agent 工程最痛的部分
在所有問題中，我們發現測試和評估是最難的部分。這并不意外，但 Agent 的特性讓這件事情變得更困難。
與普通 Prompt 不同，你不能簡單把 Agent 扔到外部評估系統里做測試，因為它依賴太多動態輸入、工具調用、狀態變化。所以評估必須基于：
- 可觀察性數據（observability data）
- 或對真實測試運行進行詳細的 instrumentation
遺憾的是，我們嘗試過的所有方案目前都無法讓我們滿意。這件事正在成為構建 Agent 最令人沮喪的環節之一，希望未來能找到正確的解法。
Coding Agents 的趨勢：Amp 與 Claude Code 依然是標桿
關于 coding agents，我們的看法沒太大變化。唯一的新進展是，我最近開始更多嘗試 Amp。
為什么？不是因為 Amp 明顯比我現用的方案更好，而是因為我很喜歡他們在博客里對 Agent 的思考方式，子 Agent（如 Oracle）與主循環的協作設計非常優雅，很少有框架今天能做到這一點。這對我來說也可以作為比較不同 Agent 設計的參考
Amp 和 Claude Code 一樣，給人的感覺是：
這是由真正使用自己工具的人打造出來的產品。
我不能對所有 Agent 產品都這么說。
一些值得分享的東西
以下是一些零散但可能有參考價值的閱讀內容：
1. 如果你根本不需要 MCP？
Mario 認為，許多 MCP 服務器設計過度，工具集合太大、太復雜、消耗大量上下文。他提出一種更“極簡主義”的瀏覽器代理方案：只依賴簡單的 CLI 工具（start、navigate、evaluate JS、screenshot），通過 Bash 執行，既省 token 又靈活。
文章鏈接：https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/
2. “小型”開源項目的命運
作者認為：微小、單用途的開源庫時代正在結束。因為平臺內置 API 和 AI 工具已經可以按需生成這些小工具。謝天謝地。
文章鏈接：https://nolanlawson.com/2025/11/16/the-fate-of-small-open-source/
3. Tmux is love
雖然沒有專門的文章來詳細闡述，但簡單來說就是：Tmux 非常出色。如果你有任何看起來像是需要智能體交互的系統，都應該讓它具備一些 Tmux 的功能。
github鏈接：https://github.com/mitsuhiko/agent-commands/tree/main/skills/tmux
4. LLM API 是一個同步問題
內容太長，我在另一篇文章里寫了。
文章鏈接：https://lucumr.pocoo.org/2025/11/22/llm-apis/
網友：當下的 Agent 技巧很快就會過時
在這篇文章的HN評論區里，許多網友都分享了自己的經驗和故事。有部分網友指出，技術變化太快，當下的 Agent 技巧很快會過時。
一位網友分享了自己的經驗：
我兩年前在這個領域創辦了一家公司，現在運營得不錯。我們這段時間最大的體會是：很多“Agent 技巧”其實只是為了解決 LLM 當前階段的一些缺陷。這些問題今天存在，不代表明天還存在——因為技術變化很快。過去兩年已經發生過很多次類似的變化。
比如：緩存、各種優化——幾個月后可能就全被更好的方法或更強模型替代。
我以前在 AWS 還不支持磁盤加密時，團隊花了 3 個月自己實現了一套磁盤加密方案，非常痛苦。結果剛做完 AWS 就推出了“一鍵啟用加密”。我們白忙活了三個月。
所以現在我學到的一個經驗是：很多時候最好的做法是不做任何事。
也有網友表示，自己收到過很多關于人工智能和智能體的研討會邀請，但大多數人沒有意識到，他們“發明”的這些巧妙模式下周可能就過時了。即便是“最近網上很火的一篇 Agent 架構文章”，到了下個月就沒人提了。
有網友指出，在動態環境下，很多工作最終都會被模型能力升級吞掉。
如果把時間線拉到 3 年，最大的技術變化是：上下文窗口從 4k → 16k → 128k → 256k。
過去我們要花大量精力做文本 chunking、分塊、摘要、復雜 RAG，現在根本不需要。
此外：
（1）多模態 LLM 徹底改變文檔處理
以前 PDF 文本提取是噩夢，需要花大量時間寫規則。現在給 LLM 一張 PDF 就能讓它識別內容，效果更好。
（2）向量檢索地位下降
很多場景中，讓 Agent 直接“grep”文檔，比向量數據庫更便宜、更好。
Boris Cherny 曾爆料 Claude Code 就是這么干的。
一位網友總結了這一觀點：完全可以等 AI 的風潮慢下來再跟進。
因為到那個時候，“業內專家”對新技術的理解也只不過是 1、2 個月前才學會的東西。你一點也不難補上進度。
但也有人反駁，自己寫 Agent 才能理解工具的本質。
以前的工匠必須自己做工具。雖然可以買現成的，但自己做工具會讓你對工具的理解更深、用得更好。
AI Agent 和模型 API 的迭代速度很快，但我仍然選擇自己寫、自己造輪子。我職業生涯里每一次突破都是別人說“這不可能做”而我去做了。
如果你依賴一個 Agent 框架，那會把你限制得非常死，而且你還意識不到自己被限制了。
至于“浪費三個月”這種說法——如果某件事是你產品的核心價值，那就去做，不要等。如果不是核心價值，那根本不應該做。
很多時候我們自己做的方案比 AWS 后來推出的通用方案更適合產品。
也有開發者認為，爭論的焦點在于“這些智能體在競爭環境中能夠擁有多大的自主權”。
爭論的核心其實是：
一派認為 Agent 應該由人類完全驅動（只自動化一些你知道結果的小任務）。
另一派認為 Agent 應該能“端到端”處理復雜任務，只需最少監督。
雙方都有道理，也許答案只是：It depends（取決于你的工程場景）。
一位網友則表示：
分歧很簡單。
世界上有兩類專業人士：能看到 AI 的巨大變革潛力，愿意花時間學，并且已經做出很厲害的東西抱怨、批評、質疑，但不愿投入時間去學的人。
如果你用這些工具都不能提高生產力，你應該換職業了。
說了這么多，大家對 AI Agent 的看法是什么呢？
你認為未來的 Agent 是應該完全自動化、獨立完成任務，還是只做輔助、由人類掌控主導？
在實際工作中，你遇到過哪些讓你哭笑不得的 Agent 體驗？
歡迎在評論區分享你的經歷和觀點。
參考鏈接：
??https://news.ycombinator.com/item?id=46013935??
??https://lucumr.pocoo.org/2025/11/21/agents-are-hard/??
本文轉載自??51CTO技術棧??，作者：聽雨
