別再顧 agent，先給它 context

概要

• agent 一開始什麼都不知道Brandon 把剛啟動的 agent 比成零 context 的聰明工程師，不知道組織裡有哪些服務和慣例，所以才需要人一直在旁邊補。
• 三個迷思Brandon 舉的三個是「對文件做 naive RAG 就夠」「接夠多 MCP 就好」「context window 夠大就好」，結論都是不夠。
• context engine 要做的事跨系統推理、解決來源之間的衝突、遵守權限，最後回給 agent 一份壓縮過的小回應。
• 對照實驗同一個 prompt，只接 MCP 的版本能過編譯與檢查，資深工程師卻說照做會弄壞整個系統；用 context engine 的版本只收到一個小意見。
• 三個硬教訓只顧存取、把衝突藏起來、把好答案快取起來，三條路他們都試過，都出了問題。
• 用在計畫與 code reviewBrandon 的建議是規劃時用，執行中隨時可以再問，到 code review 再用一次。

原話

• “Getting the best context up front makes all agent choices and actions after that even better.”

  先把最好的 context 備齊，後面 agent 每一個選擇和動作都會更好

  ▶ 04:06

• “The gap is not intelligence at this point, it is context.”

  現在的差距不在智力，而在 context；引自 Karpathy

  ▶ 04:39

• “They're pipes, that's great, but they don't provide understanding or reasoning across it.”

  MCP 只是管線，不提供跨資料的理解與推理

  ▶ 07:10

• “The moment you write it, it's no longer valid because things are changing.”

  答案一寫下來就不再有效，因為事情一直在變；指快取好答案的問題

  ▶ 13:14

• “An agent should write code that feels like it was written by someone who's been on your team for years.”

  agent 寫的 code 應該像團隊裡待了好幾年的人寫的

  ▶ 14:40

延伸

• 權限的例子：他們會收 Slack 與 Microsoft Teams 的對話，私訊只回給本人，別人問同樣的問題看不到；這也是他們透過 MCP 交付的原因之一，可以沿用 OAuth 的權限模型。
• Brandon 說團隊有一定規模之後，缺 context 的 agent 會傾向把東西 mock 掉，寫出來像原型，不能 merge。