我花了大量時間在 AI 領域——閱讀論文、實際開發，以及與真正部署系統的工程師交流。目前示範與實際生產系統之間存在落差，但沒有人願意完全誠實面對。

以下是我對現況的真實看法。

談論 AI 代理的問題

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

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

當你無法精準定義正在建置的東西，就容易對簡單流程過度工程化，對真正複雜的系統卻工程不足。我見過團隊花數週時間為本來只需單一結構化提示就能完成的流程，加入「代理式」編排。

我一再使用的定義是：代理是一個有目標而非只有指令的系統。它決定下一步該做什麼、處理失敗，並知道何時完成。

其他都只是華麗的函式呼叫。

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

🔵 如果系統能在工具呼叫失敗後恢復並嘗試其他方法，代表你正在進步。

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

目前生產環境的實際情況

我追蹤與交流的團隊給出的真實圖像如下：

大多數真實的代理部署都很窄，專注做好一件事。像是客服分類、文件擷取、特定程式碼庫的程式碼審查。它們不是通用推理引擎，而是決策層帶有部分智慧的專用流程。

取得良好成效的團隊，不是追逐最新模型版本，而是專注於：

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

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

☑️ 可觀測性——能否精準追蹤代理做出該決策的原因

得到不良結果的團隊，則是只把 GPT-4 換成最新前沿模型，卻未改變其他任何東西，卻期望行為不同。

最近常見的新聞： Google 25 年來首次重新設計搜尋框——其重要性超乎想像。 (VentureBeat AI)。25 年來，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 是一家舊金山雲端平台，已默默累積 200 萬開發者且未花費任何行銷費用，週四宣布募資 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 系統的人。這與微調或提示工程是不同的技能組。

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

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