最近 devtool 與 agent 圈一直在講 context engineering。這個詞很容易被誤解成「prompt engineering 換皮」，好像只是把 system prompt 寫長一點、把範例塞多一點、把文件丟進 RAG 裡就算完成。我的判斷剛好相反：context engineering 代表的是 AI agent 從聊天玩具進入正式工作流後，大家終於承認「模型吃到什麼」本身就是一套基礎設施。

這件事代表什麼？代表 agent 的可靠性不再只由模型能力決定。當它要讀 repo、查 CRM、看工單、用瀏覽器、呼叫內部 API、記住使用者偏好、遵守公司政策時，真正影響結果的是整條輸入供應鏈：哪些資料被選進上下文、哪些記憶被保留、哪些工具結果被信任、哪些規則優先、哪些內容該壓縮、哪些資訊必須隔離。這些做不好，再強的模型也只是比較有說服力地犯錯。

誰該在意？第一是正在把 agent 放進開發、客服、營運、銷售或資料分析流程的團隊。只要任務超過單輪問答，context 就會變成產品行為的一部分。第二是平台工程與 AI infra 團隊。過去你們管的是 API、權限、log、資料庫；現在還要管模型每一步決策前看到的資訊環境。第三是內容與知識管理團隊，因為文件不再只是給人讀，也是在餵一個會行動的系統。

最常見的錯誤理解，是以為 context engineering 等於「把更多資料塞進去」。這非常危險。上下文太少，agent 會瞎猜；上下文太多，agent 會分心、混淆，甚至把過期規則當成最新規則。真正的問題不是量，而是選擇、排序、來源、時效、權限與可驗證性。另一個錯誤理解，是把它全交給向量資料庫。RAG 只是取資料的一種方式，不會自動解決工作記憶、工具輸出、流程狀態、政策優先權與敏感資訊隔離。

採用建議很務實：先不要急著成立一個「context engineering 平台」。從一條高頻 workflow 開始，把 agent 每一步需要的資訊列成清單：任務目標、可用工具、必要文件、使用者狀態、公司規則、歷史紀錄、失敗時的 fallback。接著替每種 context 標上來源、更新頻率、權限等級與驗收方式。能被測試的就寫測試，不能被測試的至少要能留下 trace。

判斷一個團隊有沒有真的理解 context engineering，可以看它問的問題。如果只問「context window 多大」，多半還停在模型參數思維；如果開始問「這段資訊為什麼進來、誰批准、過期怎麼辦、錯了如何回放」，才是在做 agent 工程。

所以 context engineering 不是新 buzzword，而是 agent 時代的供應鏈管理。未來能把 AI 放進核心流程的團隊，不一定是 prompt 最會寫的人，而是最早把 context 當成產品責任管理的人。模型負責推理，但你負責餵它看見世界的方式；餵錯了，就別怪它長歪。