Context Engineering 是什麼？AI agent 每一步該看到哪些資料

舉個例子。一家做五金零件的公司，讓客服 agent 處理退貨申請。某天一位合作多年的客戶提出今年第三次退貨，agent 很快回覆：「依退貨政策，收貨後 14 天內可申請，本次符合資格，已為您建立退貨單。」

問題是公司去年已經把期限改成 7 天，這位客戶的貨是 10 天前收到的。追查下來，提示詞寫得沒有問題，錯在 agent 那一步看到的東西：系統把整本產品手冊都塞了進去，裡面同時有新舊兩版退貨政策；三年來和這位客戶的 40 段對話全部附上；25 個工具的說明也一個不漏。模型在這堆資料裡抓到了舊版那段，還順手呼叫了建立退貨單的工具。

這類問題，業界這一兩年開始用 context engineering 來稱呼。怎麼寫一段清楚的指令，我在 提示詞怎麼寫 整理過；這篇處理的是下一層：agent 執行任務時，每一步放進模型的資料要怎麼挑。

Context Engineering 是什麼：決定每一步讓模型看到什麼

Anthropic 在 2025 年 9 月的工程文章裡，把 context engineering 定義為：在模型推論時，挑選並維持一組最合適的資訊（token）的一整套做法。這組資訊不只是提示詞，還包括系統指令、工具、MCP、外部資料和對話紀錄。

中文常見的譯名有「上下文工程」「情境工程」「脈絡工程」，指的是同一件事。

把開頭的退貨任務拆開來看，agent 每一步收到的上下文大概有這幾類：

表格最後一列最容易被忽略。一般聊天只有一問一答，agent 卻會連續呼叫好幾個工具，每一次的回傳結果都留在上下文裡。LangChain 的整理也提到，長任務加上不斷累積的工具回傳，agent 常常會用掉大量 token，超過上限，或讓成本和回應時間一起變高。

所以 context engineering 要回答的問題很具體：這一步，模型需要看到什麼，才做得出對的判斷。

和提示詞差在哪：一個寫一次，一個每一步都在變

提示詞和 context engineering 常被放在一起比較。我的理解是，前者是後者的一部分：

Anthropic 把 context engineering 形容為提示工程自然的延伸。Agent 做的事從單次問答，變成要跑好幾輪、呼叫好幾個工具的任務，要管的東西就從「那段話怎麼寫」，擴大到「整個上下文怎麼組」。

回到退貨的例子。提示詞寫的是「依公司政策處理，超過退貨期限就轉人工」，這句話完全正確，但政策文件放了新舊兩版，模型就得自己猜哪一版才算數。這時候再怎麼改提示詞，效果都有限，要改的是放進去的文件。

網路上有些文章把 context engineering 說成提示工程的「取代者」，彷彿提示詞不重要了。實務上兩者都要做：指令寫不清楚，資料挑得再好，模型也不知道要拿它做什麼。

為什麼不能全部塞進去：上下文越長，模型越容易漏

現在的模型動輒可以讀進幾十萬個 token，很多人的直覺是：那就全部放進去，讓模型自己找。

這個做法有兩個代價。

第一個是準確度。Anthropic 把這個現象叫做 context rot（上下文腐化）：上下文越長，模型準確找回其中資訊的能力就越差。它的解釋是，模型處理文字時，每個 token 都要和其他所有 token 建立關聯，n 個 token 就有 n² 組關係，上下文越長，注意力被分得越薄。它用「注意力預算」來形容：每多放一段資料，就從這筆有限的預算裡扣一點。

更早的研究也看到類似的現象。史丹佛等單位 2023 年的論文〈Lost in the Middle〉發現，關鍵資訊放在上下文的開頭或結尾時，模型的表現通常最好；放在中間時，表現會明顯下降，即使是專門為長上下文設計的模型也一樣。

第二個是成本。多數 API 依輸入的 token 計費，agent 又會一步接一步地呼叫模型，每一步都要把上下文重送一次。Anthropic 在說明自家多 agent 研究系統時提到，agent 用掉的 token 大約是一般聊天的 4 倍，多 agent 系統更達到約 15 倍。

把兩個代價放在一起，Anthropic 給的原則是：找出能讓模型做出正確結果的最小一組高價值資訊。模型本身的上下文限制，LLM 是什麼 有另外說明；這裡要記住的是，上下文放得越多，對 agent 的幫助不一定越大，很多時候反而是負擔。

改前改後：同一個退貨任務，上下文怎麼裁

回到開頭的退貨任務。下面是同一個 agent、同一個提示詞，只改上下文的對照：

改後的版本，模型看到的資料少了九成以上，但判斷需要的東西都在：現行政策寫 7 天，訂單顯示 10 天前收貨，結果就是轉人工處理，而不是直接建單。

這張表裡的每一列，其實都在回答同一個問題：這份資料不放，模型會不會少了判斷依據？會，就放；不會，就留下查詢方式，需要時再拿。

歷史對話那一列值得多說一句。摘要要保留什麼，本身就是一個判斷。Anthropic 談壓縮時建議，一開始先盡量保留，確認重要的東西沒被丟掉，再逐步精簡。退貨的例子裡，前兩次退貨的原因和日期一定要留，因為第三次退貨可能就是同一個問題沒解決。

五個常用做法

Anthropic 的工程文章與 LangChain 的整理，用詞不同，做法高度重疊。我把它們整理成企業導入時最常用的五個：

以下逐項補充。

按需載入：先給地址，要用時再去拿

Anthropic 稱這種做法為 just-in-time（即時載入）：上下文裡只放輕量的識別資訊，例如檔案路徑、查詢條件或網址，agent 判斷需要時才用工具把資料讀進來。它舉的例子是 Claude Code，會先讀專案說明檔，再用搜尋指令找需要的檔案，而不是一開始就把整個專案載入。

企業流程裡最常見的版本就是 RAG：問題進來，先檢索相關段落，再放進上下文。檢索怎麼設計、每一步會在哪裡出錯，RAG 是什麼 有完整的整理，這裡不重複。

精簡工具：工程師自己都選不出來，agent 也選不出來

Anthropic 的建議是維持一組最小、夠用的工具，避免功能重疊。它給了一個很好用的判斷方法：如果工程師看著工具清單，都說不出這個情況該用哪一個，agent 也不會知道。

舉個例子，同時開放「查詢訂單」和「查詢訂單狀態」兩個工具，名稱和說明又很接近，agent 就可能在兩者之間亂選。合併成一個，或把說明寫到不會混淆，錯誤就少很多。透過 MCP 接工具時，工具說明也會進上下文，裝了十幾個 MCP server，光是說明就可能占掉一大塊，MCP 是什麼 裡有接 server 前該檢查的事。

壓縮與摘要：對話快滿時整理一次

長任務跑到一半，上下文快滿了，就把目前為止的內容整理成摘要，用摘要開始新的一段。Anthropic 提到，最安全、最輕量的壓縮是清掉舊的工具回傳結果：agent 已經用過那筆資料、做完判斷，原始的回傳內容就可以拿掉。Claude 的開發平台也把這件事做成功能，可以依設定自動清除較舊的工具結果。

要注意的是摘要本身的品質。開頭退貨的例子裡，如果摘要只寫「老客戶，曾退貨兩次」，漏掉兩次的原因，agent 就少了判斷第三次退貨的關鍵依據。

筆記式記憶：讓 agent 自己記下進度

agent 把重要的事寫在上下文之外的地方，例如一個固定的筆記檔，下一輪或下一次任務開始時先讀它。Anthropic 舉過一個例子：讓 Claude 玩寶可夢遊戲時，它會在筆記裡記錄幾千步的訓練進度與地圖探索，上下文重置後讀回筆記，還能接著原本的策略玩下去。

企業流程裡，這可以是一張跨天處理的客訴單：第一天查了哪些資料、問了客戶什麼、還在等哪個部門回覆，都寫進筆記，第二天接手的 agent（或人）先讀筆記就知道進度。

子 agent 分工：各自處理，只回報結論

把一個大任務拆給幾個子 agent，每個子 agent 在自己的上下文裡深入處理一塊，最後只把精簡的結論交回主 agent。Anthropic 的說法是，子 agent 可能用掉幾萬個 token 探索，但回報的摘要通常只有 1,000 到 2,000 個 token，主 agent 的上下文就能保持乾淨。

代價是總用量。前面提過，Anthropic 的多 agent 系統 token 用量約是一般聊天的 15 倍。所以我會把子 agent 留給真正需要平行查很多資料的任務，例如同時比對十家供應商的規格與交期；一般的客服或資料整理，一個 agent 加上按需載入通常就夠。

上下文也會出錯：四種常見狀況

LangChain 的文章引用 Drew Breunig 的整理，把上下文出錯分成四種。我用同一個客服情境逐一對照：

第一種要特別小心。錯的內容可能來自模型自己編出來的推論，也可能來自有人刻意藏進去的指令。前者的成因和處理，在 AI 幻覺是什麼；後者屬於 prompt injection，要從權限和系統設計去防。寫進記憶或筆記的東西，影響會延續到之後的每一步，所以什麼可以寫、誰能改，要在設計時就想好。

我們自己的例子：給 AI 協作的說明文件，先寫「什麼時候讀哪份」

我們內部有一份給 AI 協作用的流程說明，規定一項工作要依序做哪些檢查、參考哪些文件。這份說明原本的寫法，是列出一串開工前要讀的文件，遇到新狀況就再加一份進去，清單越來越長。

這樣做吃過虧。舊紀錄裡已經被取代的寫法、已經決定不公開的資訊，只要還在要讀的範圍內，就有機會被當成現行規則沿用。

2026 年 9 月，我們在說明的開頭加了一張表，每份文件寫清楚三件事：什麼情況下才讀、讀它是為了什麼、和其他文件衝突時誰優先。例如語氣規範只在寫正文時讀，圖片流程只在做圖時讀，公司事實表只在提到公司或產品時讀。同一個月也把一次性的舊紀錄移到封存區，重複的文件合併。

這張表做的事，就是這篇講的按需載入加上衝突處理：

• 每次工作開始時，只載入這項工作需要的文件，其他文件留著名稱與用途，需要時再讀
• 文件之間說法不同時，依表上的優先順序判斷，模型不用自己猜哪一份才算數
• 過期的文件刪除或移到封存區，不留在清單裡當干擾

上下文裡同時存在新舊兩套規則，本身就是一種錯誤來源，這和開頭退貨政策新舊兩版並存是同一個問題。整理上下文，有一半的工作其實是把該退場的東西移走。

導入 agent 時，先檢查這四件事

多數企業的第一個 agent 流程，還用不到子 agent 或複雜的記憶設計。上線前先確認下面四件事，就能避開大部分上下文造成的錯誤：

1. 每一步的上下文都留紀錄。答錯時，要能回頭看到那一步模型實際收到了什麼：放了哪幾段文件、哪些工具、多少歷史對話。沒有這份紀錄，就只能猜是提示詞還是資料的問題。
2. 文件只放現行版本，並標明日期。放進檢索範圍的文件，舊版要移出或標示作廢。退貨政策這類會改的規則，最好只有一個來源。
3. 測一個「很長」的案例。測試集裡放一位往來紀錄很多、訂單很多的客戶，確認上下文變長之後，答案仍然正確、成本仍在預期內。
4. 估算每一步的 token 用量。記錄一次完整任務用了多少 token，乘上每天的量，看看成本是否合理；用量明顯偏高的步驟，通常就是上下文放太多的地方。

測試集怎麼建、成功率要到多少才上線，可以看 AI agent 專案怎麼驗收。

我們能協助的部分

我們的企業 AI 營運方案在需求診斷時，工程團隊會協助梳理資料現況，先挑一個關鍵流程切入，只整理這個流程會用到的資料。這和這篇講的原則一致：先確定這個流程每一步需要什麼，再決定要準備哪些資料。

模型可以依任務接入 OpenAI、Claude 與 Gemini，依難度調配；資料異常或高風險的判斷設計成先暫停，交由專人確認後再執行。

常見問題

參考來源

• Anthropic：Effective context engineering for AI agents
• Anthropic：How we built our multi-agent research system
• Claude Developer Platform：Context editing
• LangChain：Context Engineering
• Liu et al.：Lost in the Middle: How Language Models Use Long Contexts