我們經常聽到 2025 年將是 AI Agents之年，但這到底意味著什么？
實際上， AI Agents已經存在了幾十年。只是最近，大型語言模型（LLMs）消除了創建代理系統的最大障礙之一：編寫自定義算法和從零訓練模型。現在，復雜的推理只需一個 API 調用即可實現。
然而，在追隨這一技術熱潮之前，我們應該了解整個背景： AI Agents是什么、它們為何出現、如何工作，以及——最重要的——它們能做什么，不能做什么。
AI Agents的定義
AI Agents是一種軟件系統，能夠在極少的人為干預下運行，主要具備以下能力：
- 感知并影響其所處的動態環境
- 評估環境并決定采取的行動
- 自主執行最佳決策
- 在循環過程中持續運行，并記憶其觀察和執行的內容
例如，一個持續監測 Web 應用性能、識別問題并向相關團隊報告的系統，不僅僅是一個簡單的功能調用。它能夠循環運行、處理不斷變化的數據，并基于數據做出決策。
為什么需要 AI Agents？
AI Agents解決了四大人類難以規模化處理的問題：
- 碎片化系統：代理能夠連接原本孤立的數據流或工具（如安全團隊手動交叉比對防火墻、入侵檢測系統（IDS）和安全信息管理系統（SIEM）日志）。
- 無盡的決策：代理可以全天候處理重復性的決策，而不會疲勞（如自動回滾失敗的部署）。
- 指數級復雜度：代理可以處理變量過多、人類難以掌握的場景（如在電網負荷緊張時智能調度能源）。
- 實時自適應：代理可以在事件之間的毫秒級時間內調整規則（如在金融交易之間實時更新欺詐檢測策略）。
雖然 AI Agents的概念由來已久，但支撐其規模化運行的基礎設施才剛剛成熟。如今的 AI Agents不再是死板的規則集合，而是更靈活的推理系統，未來可能會變得更加智能。
AI Agents的演進
AI Agents并非新興趨勢，早在 20 世紀 50 年代，就已經有出色的智能系統出現：
1956：邏輯理論家（The Logic Theorist）
1970s：醫學診斷系統 MYCIN
1980s：專家系統 XCON
1990s：國際象棋 AI Deep Thought
2010s：Jeopardy! 冠軍 Watson、圍棋 AI AlphaGo
2020s：GPT-3、2024 年 PharmaAI 藥物研究 AI
過去 70 年，我們主要通過手工編寫規則和數據來構建 AI Agents。然而，自 2020 年以來，LLMs 讓我們能夠創建更智能的 AI Agents，而無需：
- 硬編碼所有規則（如 Deep Thought 的國際象棋邏輯）
- 嚴格篩選訓練數據（如 Watson 備戰 Jeopardy!）
- 手動特征工程（如 AlphaGo 的圍棋招法預測）
如今，只需 API 調用，開發者就能構建能夠推理新場景的 AI Agents，而過去這需要博士團隊數月的努力。
我的觀點？即使不再推出新的 LLMs，我們也尚未見證 AI Agents的最佳表現——并非因為 LLMs 不夠智能，而是我們尚未像優化傳統 AI Agents那樣，充分優化其基礎設施、規則和數據。
AI Agents的工作原理（以及它們與 AI 模型的區別）
雖然 LLMs 提升了 AI Agents的推理能力，但 AI Agents的核心不在于是否使用 LLM。相較于單純的 AI 模型， AI Agents還具備以下特點：
- 自主性：代理能夠持續運行，幾乎無需人為干預，而模型僅執行一次任務。例如，Web 監控代理可以自主觸發警報，而普通 AI 模型僅在收到查詢時才會響應。
- 輸入處理：代理能夠主動感知環境并更新自身狀態，而模型每次調用都需要完整的上下文。例如，智能客服 AI 可以保持對話記憶，而普通語言模型則需要在每次 API 調用時提供完整對話記錄。
- 適應性：代理可以實時調整行為，而模型僅處理靜態輸入。例如，動態推薦系統會根據用戶點擊不斷調整推薦，而靜態模型則需要額外輸入才能更新結果。
簡單來說，** AI Agents = AI 模型 + 用于循環運行的粘合代碼（Glue Code）**。
這一“粘合代碼”才是關鍵所在，我們已經花費 70 年優化它，而 LLM 時代的 AI Agents仍處于早期階段。優秀 AI Agents與普通 AI Agents的區別，主要取決于以下核心組件的整合：
- 個性化數據
- 實時記憶
- 感知—思考—行動的循環機制
- 工具調用能力
未來， AI Agents的突破將更多取決于這些基礎能力的優化，而不僅僅是 LLM 的迭代。
1. 個性化數據：基礎構建塊
從無狀態的通用 AI 到真正的自主 AI，關鍵在于讓模型能夠訪問你的特定上下文。開發者通常通過以下方法實現個性化，按照影響力和投入程度從低到高排序：
檢索增強生成（RAG）
RAG 使用向量數據庫，讓模型可以“回憶”來自外部來源的相關信息（例如你的 Slack 聊天記錄或代碼庫）。
向量數據庫會將數據轉換為嵌入（高效的數值表示），然后將相關的文本片段注入到 AI 模型的提示詞中。
然而，RAG 受限于隱式信息關聯。例如，問 AI 關于你的蜥蜴時，它可能會提取你的寵物 Scaleb 的數據，但如果你問“我的好朋友是誰？”，除非數據庫中明確注明“好朋友是一只爬行動物”，否則不會返回 Scaleb。
直接提示注入
最直接的方法是通過提示詞提供個人化的上下文：直接告訴 AI。
相比 RAG，這種方法更可靠——模型處理的所有細節都來自提示詞，而無需檢索。但它存在上下文長度限制（即使是 Gemini Pro 也最多只能處理約 3000 頁文本）。此外，每次調用時都需要提供新上下文，可能比設置 RAG 還麻煩。
用戶還可以覆蓋注入的上下文（如輸入“忽略之前的指令……”），這對處理敏感規則來說是個風險。
直接提示注入適用于小型、臨時數據集，準確性比規模更重要的場景。
系統提示工程
修改 AI 的系統提示，可以將核心規則寫入模型的“操作系統”中，例如：
- 強調安全性規則（“始終引用來源”）
- 規范工具使用（“將單位轉換為英尺”）
系統提示優先級高于用戶提示（無法通過“忽略之前的指令”繞過），但數據過多可能導致模型忽略特殊情況。
平衡至關重要——定義“如何思考”（例如“使用 Markdown 標題結構化答案”），同時讓 RAG 和用戶請求決定“參考什么”（如代碼庫文件）。
這種方法適用于保持品牌語調或合規要求，而無需反復重新提示。
微調現有 LLM
微調比提示詞或 RAG 復雜，但它能永久改變模型的行為，使其在收到提示之前就具備特定能力。例如，將通用的“LawyerLLM”調整為你的法律顧問。
對于 AI 不是核心業務但能增強業務的企業（如 H&M 的客服 AI），微調能極大提升其在特定領域的表現，而且不需要深入的機器學習專業知識。
微調使用監督學習，例如提供輸入/輸出對（如法律問題及律師事務所的標準回答），以調整模型的文本生成方式。
訓練專門模型
這與從零構建自定義模型不同，更適用于關鍵、可重復的任務，而通用 LLM 在這些任務上表現不佳。
例如，在 Builder，我們訓練了一個專門的模型，用于將設計轉換為代碼，它比通用 LLM 快 1000 倍、成本更低。這種方法允許不斷優化，以超越現有大模型提供的通用解決方案。
自定義模型構建
這是終極選擇：完全從頭開始訓練模型。
這通常需要 10 億以上的特定領域數據（如 BloombergGPT 的 3630 億金融文本）、PyTorch/TensorFlow 專業知識，以及普通初創公司難以承受的 GPU 計算成本（約 $100 萬/月）。
盡管定制模型可以在特定領域表現出色，但它面臨被淘汰的風險——今天的最先進技術可能明天就變成過時產品（如 Claude Sonnet 可能取代 GPT-4）。
因此，自定義模型適用于 AI 驅動型企業，例如 AlphaGo 之于強化學習。
2. 實時記憶： AI Agents如何學習
AI Agents可以利用記憶，根據預設目標自動改進，這通常被稱為“評測”（evals）。例如，Builder 的 Micro Agent 生成測試（作為評測），然后不斷嘗試編寫代碼以通過測試。它會記住哪些方法失敗了，并持續優化，直到所有測試通過。這是通過簡單的提示注入到模型的上下文窗口中實現的。
這種方法很有效，但大多數 AI Agents需要比無狀態 LLM API 更高級的記憶機制。目前，大部分 LLM API 在每次請求時都會重新傳輸整個聊天記錄，而有狀態的記憶可以讓代理在多個交互中動態進化。
** AI Agents的記憶存儲方式包括：**
- 向量數據庫：用于語義回憶（如“Scaleb 對某些食物過敏”→ 避免推薦面包蟲）。
- 知識圖譜：用于映射關系（如“用戶的母親”→“每周日都會打電話”）。
- 操作日志：用于重試策略（如“API 調用失敗”→“每 5 分鐘嘗試新參數”）。
相比無狀態系統，記憶系統帶來的優勢包括：
- 自適應學習：記錄行為模式（如“用戶拒絕面包蟲推薦”→“自動隱藏爬行動物相關內容”）。
- 推理循環：通過遞歸工作流進行自我校正（如“API 失敗”→“調整參數”→“成功”）。
- 用戶連續性：避免重復提供上下文（如“仍然不吃面包蟲嗎？” vs. “再告訴我一次 Scaleb 的信息”）。
常見的記憶系統使用類似 RAG 的流程：
用戶查詢 → 檢索記憶 → 判斷是否相關
- 否 → 存儲新記憶
- 是 → 增強提示
→ 生成響應
更復雜的系統還可以加入：
- 時間衰減（自動讓記憶隨時間過期）
- 命名空間隔離（支持多用戶系統）
- 記憶驗證（清理 LLM 生成的記憶，減少幻覺信息）
未來， AI Agents的進化不僅依賴于更強大的 LLM，更取決于個性化數據和記憶系統的優化。
3. “感知-思考-行動”循環
AI Agents的核心機制是“感知-思考-行動”循環——一個讓靜態 AI 調用變成動態、自我糾正工作流的閉環。
這不僅僅是理論概念，而是代理執行任務的實際方式。
感知（Sense）
在第一階段， AI Agents會主動觀察環境。
它不會等待所有必要信息一次性輸入，而是持續監測更新，例如用戶輸入、個性化數據和記憶、外部 API 數據等。
思考（Think）
在獲取最新上下文后，代理會進行深思熟慮，解析信息、權衡行動選項，并評估其上一次嘗試是否達成目標。
這個“思考”步驟允許代理將自身輸出與硬編碼的評測標準或更靈活的抽象性能指標進行比較（這些評測可以由代理自身或另一個 LLM 進行）。在 OpenAI 的 o1 和 Deepseek 的 R1 這樣的 LLM 中，你可以看到這種機制的實際應用。
行動（Act）
最終，代理執行最佳行動，這可能包括生成輸出、調用外部工具，或觸發另一個代理。
這個行為會改變代理的環境，生成新的數據進入“感知”階段，形成循環。每一次迭代都為改進和穩定輸出提供機會。
循環退出（Loop Exit）
代理循環會在滿足明確的退出條件時停止——比如 CI/CD 流水線只有在通過所有測試后才會部署代碼。
如果需要額外的退出方式，可以設置最大重試次數。例如，在 OpenAI 的 o3 模型中，低、中、高推理強度的區別只是重試次數的不同。
4. 工具調用：連接現有系統
AI Agents的另一個核心組件是工具調用。工具是任何外部編碼函數，代理可以調用它們并獲取結果，就像與用戶聊天一樣。
工具可以：
- 從外部 API 獲取數據
- 調用任意編程語言編寫的函數
- 調用專門的 AI Agents（通常比單個代理執行所有任務更高效）
- 讀取或存儲數據
- 其他操作
工具讓 AI Agents能夠與環境交互，具體能力取決于你為其提供的工具，例如任何 API 服務提供商。
示例：工具調用流程
一個 AI Agents的工具調用流程可能是這樣的：
- 用戶輸入 → 代理決定是否需要調用工具
- 如果需要調用工具 → 代理調用 Notion、Gmail、Playwright、Slack、Postgres、Finder、GitHub 等外部服務
- 工具返回數據 → 代理分析并決定是否需要更多調用
- 如果不需要工具，直接生成最終答案
例如，你可以設計一個小型代理工作流，掃描你的電子郵件并將旅行計劃整理到文件夾中。這個代理需要訪問兩個 Gmail 工具：
- 一個工具用于接收新郵件并觸發代理工作流
- 另一個工具用于判斷郵件是否與旅行相關，如果是，則存入“旅行”文件夾
工具調用的挑戰
不幸的是，每個 AI Agents要使用的工具，都需要手動教會它如何使用——代理必須構造結構化請求（如 JSON）并填入正確的函數參數。
代理如何決定何時使用工具？這依賴于初始編程（提示詞或微調）以及當前輸入的分析。代理通常會被訓練識別特定關鍵詞、模式或情境，以決定是否調用某個工具。
然而，工具調用存在一些問題：
- 占用模型上下文窗口：每個工具的調用邏輯都需要存儲在上下文中，增加了 AI Agents的負擔。
- 接入多個工具較復雜：為代理連接多個工具可能變得非常麻煩。
- 工具調用失敗時需重試：如果模型難以正確調用工具，你可能需要實現重試機制或對返回的 JSON 進行驗證。
模型上下文協議（MCP）如何改進工具調用
為了解決這個問題，Anthropic 推出了模型上下文協議（MCP），它是一種開放標準，允許模型學習“統一的 MCP 工具調用”規則，而不是為每個 API 單獨編寫調用邏輯。
MCP 的優勢：
- 只要有開發者維護某個服務（如 Notion 或 Slack）的 MCP 服務器，你的 AI Agents就可以無縫訪問這些服務。
- 你可以查看最新的 MCP 服務器列表，看看有哪些工具可用。
但要注意，MCP 仍然處于發展階段，并非所有模型或服務都完全支持它。此外，MCP 工具調用會將數據發送到外部服務器，存在安全隱患，所以要謹慎處理敏感信息。
代理 vs. 傳統 AI 模型：權衡考量
到目前為止，我們已經介紹了個性化數據、實時記憶、自主循環、工具調用，它們共同讓 AI Agents比無狀態 LLM 更強大。
然而，在全面自動化之前，我們需要考慮一些現實問題：
錯誤傳播 ??
AI 容易產生幻覺，如果代理在循環中沒有自我修正機制，錯誤會被放大。例如，在第一輪錯誤的假設，可能在第三輪變成“既定事實”。搭建成本 ??
代理的構建需要時間，一旦建成，它們往往缺乏靈活性，無法輕松擴展到其他用途。因此，可能需要多個代理來處理不同任務。-
復雜性 ??
代理的高度靈活性也帶來了決策困難，比如：- 該用哪個模型？
- 每個提示詞的溫度參數如何調整？
- 如何最佳地編寫提示詞？
這些問題的學習曲線陡峭，而且輸出結果的不可預測性可能讓開發者感到“不公平”。
成本波動 ??
傳統的 LLM 任務可以通過匹配模型大小和任務復雜度來優化成本，但 AI Agents的 API 調用次數遠高于單次請求，導致費用激增。維護負擔 ??
LLM 版本迭代快，更便宜、更強的模型不斷出現。要構建可持續的 AI Agents系統，必須采用抽象架構，避免模型依賴性過強。安全性 ??
代理和工具調用 API 時，需要謹慎管理共享數據。由于非確定性系統很難完全清理數據，所以要控制代理訪問的上下文，避免泄露敏感信息。數據依賴 ??
AI Agents的表現取決于數據質量和規則定義（無論是訓練、微調還是提示詞）。如果提供的數據不相關，代理也無法提供有價值的輸出。
未來：更依賴 AI Agents？
那么，我們會進入“ AI Agents元年”嗎？
關鍵并不在于模型是否變得更聰明，而是我們如何用更自適應的系統替代 70 年來的僵硬規則。
真正的 AI Agents應該：
? 能跨環境推理
? 在工作中不斷改進
? 注重實際應用，而非科幻幻想
謹慎擴展代理，每個 API 集成和反饋循環都會增加維護成本。今天成功的 AI Agents，往往專注于人類不擅長的任務——例如服務器監控、欺詐檢測——而不是假裝自己是“全知全能的 AI 天才”。
LLM 并沒有發明代理，但它讓代理從“實驗室展品”變成了“工作坊工具”。
我們不是要打造 HAL 9000，而是讓現有系統更智能，一次優化一個閉環。
