我花了大量時間在 AI 領域——閱讀論文、實作專案、與實際在部署系統的工程師交流。示範展示的內容與生產系統實際呈現的樣貌之間，存在著一個沒人完全誠實面對的落差。

以下是我對目前實際情況的坦率看法。

我們談論 AI 代理的方式出了什麼問題

現在大家把所有東西都稱為「代理」。一個呼叫工具的函式？代理。一個有記憶的聊天機器人？代理。一個帶有迴圈的腳本？代理。

這種稀釋不只是語意問題。它正在造成真正的工程錯誤。

當你對正在建構的東西沒有精確的定義時，你最終會對簡單的管線過度工程化，卻對真正複雜的管線工程不足。我見過團隊花了數週時間為工作流程加入「代理式」編排，而這些工作流程原本只要單一結構良好的提示就足以應付。

這是我一直回到的定義：代理是一個擁有目標，而不僅是指示的系統。它決定下一步要做什麼。它處理失敗。它知道什麼時候完成。

其他一切都只是花俏的函式呼叫。

🟢 如果你的系統需要人類告訴它每一步，它就不是代理。它是一個聊天介面。

🔵 如果你的系統能從失敗的工具呼叫中恢復並嘗試不同的方法，你已經有進展了。

✅ 如果你的系統能將目標分解成子任務並委派執行，那就是真正的代理。

目前生產環境中實際發生什麼事

我追蹤和交談的團隊所呈現的真實情況：

大多數真正的代理部署都很狹窄。它們只把一件事做好。客戶支援分類。文件擷取。特定程式碼庫的程式碼審查。它們不是通用推理引擎。它們是決策層帶有一定智慧的專用管線。

獲得良好結果的團隊並不是在追逐最新的模型發布。他們專注於：

☑️ 工具設計 —— 代理實際能呼叫什麼，以及介面有多乾淨

☑️ 失敗處理 —— 當工具回傳無用的結果時該怎麼辦

☑️ 可觀測性 —— 你能否精確追蹤代理為何做出該決定

獲得不良結果的團隊是那些把 GPT-4 換成最新的前沿模型，卻期望在不改變其他任何東西的情況下得到不同行為的團隊。

最近我一直看到的消息： Google 25 年來首次重新設計搜尋框——這裡為什麼比你想像的更重要。 (VentureBeat AI)。四分之一個世紀以來，Google 搜尋框一直是運算領域最容易辨識的介面之一：一個細長的白色矩形、一個閃爍的光標、幾個輸入的字詞，以及一份清單……

值得閱讀： https://venturebeat.com/technology/google-just-redesigned-the-search-box-for-the-first-time-in-25-years-heres-why-it-matters-more-than-you-think

最近我一直看到的消息： Railway 獲得 1 億美元融資，以 AI 原生雲端基礎設施挑戰 AWS (VentureBeat AI)。Railway 是一家舊金山的雲端平台，在沒有花費一分錢行銷的情況下悄然累積了兩百萬開發者，週四宣布募資 1 億美元……

值得閱讀： https://venturebeat.com/infrastructure/railway-secures-usd100-million-to-challenge-aws-with-ai-native-cloud

最近我一直看到的消息： Claude Code 每月最高花費 200 美元。Goose 用免費的方式做同樣的事。 (VentureBeat AI)。人工智慧程式碼革命伴隨著一個缺點：它很貴。Claude Code 是 Anthropic 的終端機 AI 代理，能撰寫、偵錯並部署程式碼……

值得閱讀： https://venturebeat.com/infrastructure/claude-code-costs-up-to-usd200-a-month-goose-does-the-same-thing-for-free

框架之戰是一種分心

LangChain。LangGraph。CrewAI。AutoGen。Semantic Kernel。每個月都會有一個新的框架出現，有人會發文說明為什麼舊的已經死了。

我真正的想法是：框架的重要性不如模式。

無論使用哪個框架，持續有效的模式：

✔️ 先規劃再執行。有一個推理步驟產生計畫，以及一個獨立的執行步驟來遵循它。不要把兩者混在一起。

✔️ 將檢索與推理分開。擷取上下文和使用上下文是不同的工作。把兩者混為一談的系統會感到困惑。

✔️ 明確的交接。當一個代理將工作傳遞給另一個代理時，交接應該有結構且被記錄，而不是透過提示傳遞字串。

我曾在三個不同的框架中重建相同的架構，每次結果都很相似。框架是鷹架。架構才是建築。

沒有人解決的檢索問題

RAG 現在已是標準。幾乎所有觸及專有資料的生產 AI 系統都會使用某種形式的 RAG。但有一個教學文件沒有很好涵蓋的問題。

區塊邊界是錯的。

當你將文件分割成區塊並嵌入時，你對哪些上下文片段應該歸類在一起做出了假設。這些假設往往是錯的。一個只有在看前一段才能理解的段落被獨立檢索出來，模型就會幻覺出缺失的上下文。

🟢 更好的區塊策略有幫助。重疊視窗、語意區塊、父文件檢索。

🔵 但真正的解決方法是重新思考你儲存什麼。有時正確的儲存對象不是原始文字，而是資訊的結構化表示。

✅ 如果你的 RAG 管線回傳技術上正確但上下文無用的結果，問題幾乎肯定出在區塊或中繼資料，而不是嵌入模型。

我認為這一切將走向何方

模型將持續變得更好。上下文視窗將持續擴大。每個 token 的成本將持續下降。

這些都不會改變根本的工程挑戰：建構當你不看著時也能信任其正確行為的系統。

這才是值得解決的問題。治理、可觀測性，以及可靠的工具使用。不是追逐基準測試。

兩年後重要的工程師，是那些能建構其他工程師可以維護和信任的 AI 系統的人。這是一套不同於微調或提示工程的技能。

它更接近系統設計，而不是模型研究。

如果這些內容與你正在建構的東西產生共鳴，或者你有完全不同的看法，我很想聽聽。請在留言區分享你的經驗。這個領域有趣的對話不在主題演講中——而在人們真正誠實討論什麼有效的討論串中。