Prompt Engineering 沒有過時；它仍負責把指令寫清楚。但 Agent 的成敗還取決於每輪提供哪些工具、資料、狀態、歷史與記憶。管理這整組可見資訊，才是 Context Engineering（上下文工程）的工作。
Prompt 是指令，Context 是模型當下看見的世界
Anthropic 在 2025 年的官方工程文章中，把 Context Engineering 描述為 Prompt Engineering 的自然延伸：除了 prompt，也要策劃推論時進入 context window 的 system instructions、工具、MCP、外部資料與訊息歷史。Anthropic：Effective context engineering for AI agents
可以把兩者分成：
| 層次 | 核心問題 | 例子 |
|---|---|---|
| Prompt Engineering | 要模型怎麼做？ | 「先列假設，再提供 SQL」 |
| Context Engineering | 模型這一輪需要看見什麼？ | schema、指標定義、可用工具、Plan 狀態、最近查詢 |
好 prompt 放在錯 context 裡仍會失敗。例如指令寫著「沿用已核准口徑」，但模型根本沒看到核准版 Plan；或工具 schema 還提供寫入能力，狀態卻只是唯讀探索。問題不在措辭，而在模型所見世界與真實工作環境不一致。
同一句「分析轉化率」，有無 context 差多少
只有 prompt
請分析本月轉化率下降原因，提供結論與建議。
模型必須猜測資料表、漏斗 stage、分母、時區與輸出格式。即使回答流暢，也很可能把通用做法當成公司的實際定義。
有結構化 context
狀態：PlanPlanning，不得正式執行
資料：events(event_time, user_id, session_id, event_name)
指標：checkout conversion = paid sessions / checkout_started sessions
時間：Asia/Taipei，完整日，截至 2026-06-30
排除：employee、test、full_refund
Plan：尚有一則 open annotation，要求確認跨日付款窗
可用工具：讀 schema、驗證查詢、修訂 Plan
第二種 context 不保證結論正確，但把模型的選擇空間縮到可審閱範圍：它知道現在不能正式跑、哪個定義有效，以及還缺哪個人類決策。
Agent Context 的六個組件
- Instructions： 角色、品質標準與禁止事項。
- State： 任務在探索、規劃、執行或交付哪一階段。
- Tools： 當輪能讀什麼、寫什麼、如何回傳結果。
- Data： schema、文件、查詢結果與錯誤訊息。
- History： 最近決策、工具軌跡與尚未解決的問題。
- Memory： 跨對話仍有效、且經治理的規則或業務知識。
設計時不要問「最多能塞多少」，而要問「最小哪組高訊號資訊足以做對下一步」。Anthropic 將 context 視為有限資源，主張找出能提高目標行為機率的最小高訊號 token 集合。這不代表 context 越短越好，而是每個 token 都要有任務價值。
三個常見反模式
把整個工作區每輪重送
好處是「可能都在裡面」，代價是 token 成本、舊內容污染與重要資訊被淹沒。更好的做法是小型 Summary 常駐，完整 schema 或文件按需讀取。
把權限只寫在 prompt
「請不要修改資料」若只是文字提醒，模型或工具整合錯誤時仍可能越界。權限應在工具白名單、唯讀查詢層與人工授權共同落實；prompt 是一層，不是唯一防線。
把所有對話當長期記憶
對話包含暫時假設、錯誤嘗試與敏感內容。真正跨任務的 Memory 應有來源、生命週期與核准流程，而不是自動把每句話永久注入。
Lantide Data 如何配置分析 Context
Lantide Data 採 Summary／Detail 分層：每輪提供精簡工作區、專案、active tab 與快取摘要；需要完整 schema、Plan、Report 或 Reference 時，再由工具按需取得。System prompt 依 NoProject、Planning、Executing 等狀態組裝，當輪工具 schemas 也隨狀態過濾。詳細設計可見Prompt 與 Context 工程及Agent runtime 架構。
對分析而言，這能讓同一句需求同時看見 Plan 狀態、查詢環境、最近步驟與已核准知識；Queued Knowledge 在使用者 Apply 前不會注入。優點是 Context 與 IDE 真實狀態對齊，而不是依賴一條愈來愈長的聊天。
邊界同樣明確：Context Engineering 只能改善模型取得與使用資訊的條件，不能保證模型推理正確，也不能替代資料品質、Plan 審閱或 Execute 授權。若 schema 本身錯、指標定義彼此衝突，系統仍需要人處理。
結語
Prompt Engineering 沒有退場，只是從主角變成 Context 系統的一部分。建置或評估 Agent 時，除了看 prompt 模板，也要檢查狀態、工具、資料、歷史與 Memory 如何進入每一輪；真正的分水嶺，是模型是否在正確時刻看見正確世界。