現在談 AI Agent，很容易把焦點放在模型能力：哪個模型會寫程式、哪個模型工具呼叫比較準、哪個模型可以連續跑更久。

這些都重要，但如果從正式導入看，真正會吃掉預算與信任的，常常不是「回答一次」本身，而是上下文失控。

Anthropic 先前談 context engineering 時提過一個很務實的觀念：context 是有限資源。這句話放到 agent 場景會更明顯。Agent 不只是回答問題，它要讀文件、看歷史紀錄、查工具結果、理解使用者意圖、保留中間狀態，甚至決定下一步要不要寫入系統。每多塞一段資料，表面上是讓它更聰明，實際上也增加 token 成本、延遲、雜訊、權限風險與判斷錯誤的機率。

比較反直覺的判斷是：AI Agent 不是資料越多越安全，而是上下文越可控越安全。

很多團隊的第一反應，是把文件庫、Slack、Notion、GitHub、CRM、工單、資料庫都接給 agent，期待它像一個全知同事。Demo 時看起來很強，因為它真的能找到很多東西。但正式環境裡，這會變成另一種問題：它可能讀到過期文件，把草稿當政策，把私人訊息帶進回答，或在一堆相似資訊中選錯來源。更麻煩的是，當回答錯了，很難知道錯在模型、檢索、資料版本、權限，還是工具結果。

所以 agent 導入的第一個工程問題，不該是「要不要換更強模型」，而是「每個任務到底需要哪一種上下文」。客服查詢需要最新政策與客戶狀態，不需要整個公司 Slack。程式碼 agent 需要相關檔案、測試、錯誤訊息與架構約束，不需要把整個 monorepo 都塞進去。財務分析 agent 需要資料來源、口徑與計算規則，不需要所有未審核草稿。

較穩健的做法，是把上下文當成預算管理，而不是資料堆疊。每個 agent 任務都要有三個邊界：哪些資料可以讀，哪些資料必須附來源，哪些動作需要人類確認。接著再看成本與品質：同樣任務是否能用摘要、索引、引用、快取或固定規格取代暴力塞全文。

這也解釋為什麼 2026 年很多 AI 團隊會從 prompt engineering 轉向 context engineering、eval、observability、permission design。不是 prompt 不重要，而是 prompt 只管單次對話的表面；上下文才決定 agent 在什麼資訊環境裡做判斷。

結論很簡單：下一波 AI Agent 的競爭，不只是誰模型更強，而是誰能用更少、更準、更可追溯的上下文完成任務。 對團隊來說，現在最值得做的不是把所有工具一次接上，而是先挑三個高頻任務，明確定義上下文清單、來源規則、審核邊界與失敗追蹤。Agent 的可靠度，通常就是從這些看起來不性感的地方長出來。

參考資料：

• Anthropic: Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents