context-fundamentals

情境工程基礎

情境是語言模型在推論時可取得的完整狀態：系統指令、工具定義、檢索文件、對話歷史以及工具輸出。情境工程是一門學問，旨在策劃最小的高訊號 token 集合，以最大化期望結果的機率。

此技能是集合中所有其他技能的基礎概念。它解釋什麼是情境、注意力機制如何運作、為什麼情境品質比數量更重要，以及理解其他情境工程決策所需的思維模型。它不負責操作型工作：除錯注意力失效屬於 context-degradation，token 效率策略屬於 context-optimization，對話摘要屬於 context-compression，基於檔案的卸載屬於 filesystem-context，專案架構決策屬於 project-development。

何時啟用

當工作屬於概念性質時啟用此技能：

• 解釋什麼是情境以及注意力機制如何限制代理行為。
• 為新進貢獻者進行入門培訓，讓他們在深入操作技能前先建立思維模型。
• 從基本原理推理情境相關的設計決策（這個限制意味著什麼？為什麼存在這個取捨？），然後再選擇具體策略。
• 撰寫或審閱需要將操作指引建立在底層機制上的文件。

請勿為操作型工作啟用此技能。專門技能負責執行：

• 診斷 lost-in-middle、情境中毒或注意力失效：context-degradation。
• 透過遮罩、分割、前綴快取、預算等方式降低 token 成本：context-optimization。
• 將長對話壓縮成交接摘要：context-compression。
• 卸載大型工具輸出或維護持久暫存區：filesystem-context。
• 決定 LLM 專案或管線的架構：project-development。

核心概念

將情境視為有限的注意力預算，而非儲存空間。每增加一個 token 都會與模型注意力競爭，並消耗一個在推論過程中無法補充的預算。工程問題在於在三個限制下最大化每個 token 的效用：硬性的 token 上限、較軟的有效容量天花板，以及 U 型注意力曲線——它會懲罰放在情境中間的資訊（參見 claim-context-degradation-lost-middle-ruler）。

組裝情境時應用四項原則：

1. 資訊性重於詳盡性——只包含對當前決策重要的內容；設計可在需要時動態檢索額外資訊的系統。
2. 位置感知擺放——將關鍵限制放在情境的開頭和結尾，因為長情境評估顯示中間位置的資訊比邊緣位置的資訊更難可靠恢復（claim-context-degradation-lost-middle-ruler）。
3. 漸進式揭露——啟動時只載入技能名稱和摘要；只有當技能被特定任務啟用時才載入完整內容。
4. 迭代策劃——情境工程不是一次性的提示撰寫練習，而是每次將內容傳遞給模型時都應持續應用的紀律。

詳細主題

情境的結構

系統提示
使用 XML 標籤或 Markdown 標題將系統提示組織成不同區段（背景、指令、工具指引、輸出格式）。系統提示在整個對話中持續存在，因此將最關鍵的限制放在注意力最強的開頭和結尾。

校準指令高度以平衡兩種失敗模式。高度太低會硬編碼脆弱的邏輯，在條件改變時失效。高度太高則提供模糊的指引，無法為期望行為提供具體訊號。目標是啟發式驅動的指令：具體到足以引導行為，靈活到足以泛化——例如，帶有判斷空間的編號步驟。

從最小開始，然後根據觀察到的失敗模式被動添加指令，而不是預先塞入所有邊界情況。策劃多樣化、經典的少樣本範例來展示期望行為，而不是列出所有可能情境。

工具定義
撰寫工具描述時回答三個問題：工具做什麼、何時使用、以及回傳什麼。包含使用情境、參數預設值和錯誤情況——如果人類工程師無法區分工具，代理也無法區分。

保持工具集合最小化。合併重疊的工具，因為臃腫的工具集會造成模糊的決策點，並在 JSON 序列化後消耗不成比例的情境（工具 schema 通常比等效的純文字描述膨脹 2-3 倍）。

檢索文件
維護輕量級識別符（檔案路徑、儲存查詢、網頁連結），並使用即時檢索動態載入資料到情境中。這模仿人類認知——維護索引，而非副本。強識別符（例如 customer_pricing_rates.json）讓代理即使沒有搜尋工具也能定位相關檔案；弱識別符（例如 data/file1.json）則會強制不必要的載入。

在對大型文件進行分塊時，應在自然的語義邊界（章節標題、段落分隔）處分割，而不是在任意字元限制處切斷概念。

對話歷史
對話歷史作為代理的暫存記憶，用於追蹤進度、維護任務狀態以及跨回合保留推理過程。對於長時間運行的任務，它可能成長到主導情境使用量——請監控並在它排擠活動指令之前進行壓縮。

循環精煉歷史：一旦工具在對話深處被呼叫過，原始結果通常不需要逐字保留。將過時的工具輸出替換為緊湊摘要或參考，以減少低訊號的內容。

工具輸出
工具輸出通常在代理軌跡中主導情境（claim-context-optimization-tool-output-dominance）。應用觀察遮罩：一旦代理處理完結果，將冗長的輸出替換為緊湊參考。只保留最近相關的檔案內容；壓縮或淘汰較舊的內容。

情境窗口與注意力機制

注意力預算
對於 n 個 token，注意力機制計算 n 平方的成對關係。隨著情境增長，模型維持這些關係的能力會下降——不是硬性懸崖，而是效能梯度。主要在較短序列上訓練的模型，用於全域依賴的專門參數較少，因此有效容量遠低於名義窗口大小。

為此梯度設計：假設有效容量在針對目標工作負載進行測量之前，實質上低於廣告窗口。大的名義情境窗口並不能免除針對特定任務進行退化測試的需求（claim-context-degradation-lost-middle-ruler）。

位置編碼限制
位置編碼插值將序列處理擴展到訓練長度之外，但會引入位置精確度的退化。與較短輸入的效能相比，在擴展情境下，資訊檢索和長程推理的準確度預計會降低。

漸進式揭露實務
在三層級實施漸進式揭露：

1. 技能選擇——啟動時只載入名稱和描述；按需啟用完整技能內容。
2. 文件載入——先載入摘要；僅當任務需要時才提取詳細區段。
3. 工具結果保留——完整保留近期結果；壓縮或淘汰較舊結果。

保持邊界清晰：如果技能或文件被啟用，應完整載入而非部分載入——部分載入會造成混淆的缺口，降低推理品質。

情境品質與數量

拒絕認為更大的情境窗口能解決記憶問題的假設。處理成本隨著情境長度不成比例地增長——不僅是線性成本擴展，還有超過有效容量閾值時模型效能的下降。即使使用前綴快取，長輸入仍然昂貴。

應用訊號密度測試：對於每一塊情境，問問移除它是否會改變模型的輸出。如果不會，就移除它。冗餘內容不僅浪費 token，還會主動稀釋對高訊號內容的注意力。

實務指引

本節提供概念性應用建議。對操作技能的指引是明確的。

推理情境決策

當需要做出情境相關的設計決策時，將概念性問題與操作性問題分開。概念性問題是「這意味著什麼以及為什麼重要」；操作性問題是「我們應用哪種具體技術」。使用此技能回答前者；將後者導向擁有該技術的專門技能。

例如，決定是否要摘要一個長代理對話包含兩部分：(1) 為什麼需要摘要（注意力預算有限，U 型曲線會降低中間內容，訊號密度比數量更重要——此技能）以及 (2) 什麼壓縮策略能保留正確狀態，以及在什麼使用率閾值下觸發它（context-compression）。

新進貢獻者閱讀順序

首次接觸情境工程的貢獻者應閱讀：

1. 此技能，以內化注意力預算框架和 U 型曲線。
2. context-degradation，了解情境失敗在實務中的樣貌以及如何診斷。
3. 根據專案最相關的操作關注點，選擇 context-optimization、context-compression、filesystem-context、memory-systems 中的兩到三個。

跳過步驟 1 會產生只會應用技術而不理解原因的運營者；跳過操作技能則會產生不知道哪種技術適合哪種失敗模式的理論家。

範例

範例 1：組織系統提示

說明概念性觀點：關鍵限制應放在注意力偏好的位置（開頭和結尾），且明確的區段邊界有助於模型解析提示：

<BACKGROUND_INFORMATION>
你是一位協助開發團隊的 Python 專家。
當前專案：Python 3.9+ 的資料處理管線
</BACKGROUND_INFORMATION>

<INSTRUCTIONS>
- 撰寫乾淨、慣用的 Python 程式碼
- 為函式簽名加入型別提示
- 為公開函式加入 docstring
- 遵循 PEP 8 風格指南
</INSTRUCTIONS>

<OUTPUT_DESCRIPTION>
提供帶有語法高亮的程式碼區塊。
在註解中解釋非顯而易見的決策。
</OUTPUT_DESCRIPTION>

範例 2：注意力預算作為思維模型

一個大情境模型並不會均等關注所有情境。有效容量是工作負載特定的，且 U 型曲線會懲罰放在中間的資訊。在決定要載入多少上游知識庫時，這是思維模型：不要問「放不放得下」，而要問「模型是否仍會關注重要的部分」。

對應的操作性問題（哪種技術應減少載入量）屬於 context-optimization。

指南

1. 將情境視為有限資源，具有遞減回報
2. 將關鍵資訊放在注意力偏好的位置（開頭和結尾）
3. 使用漸進式揭露以延遲載入直到需要時
4. 用清晰的區段邊界組織系統提示
5. 在開發過程中監控情境使用量
6. 在 70-80% 使用率時實施壓縮觸發
7. 為情境退化做設計，而不是希望避免它
8. 偏好較小的高訊號情境，而非較大的低訊號情境

注意事項

1. 名義窗口不等於有效容量：廣告大情境窗口的模型可能在複雜檢索或推理任務上遠低於該限制就退化。在你自己進行的退化測試證明之前，預算應低於名義窗口。

2. 基於字元的 token 估算會悄悄偏移：英文散文約 4 字元/token 的經驗法則在程式碼（2-3 字元/token）、URL 和檔案路徑（每個斜線、點和冒號都是單獨 token）以及非英文文字（通常 1-2 字元/token）上會失效。對於任何預算關鍵的計算，請使用提供者的實際 tokenizer（例如 OpenAI 模型的 tiktoken、Anthropic 的 token 計數 API）。

3. 工具 schema 在 JSON 序列化後膨脹 2-3 倍：在原始碼中看起來緊湊的工具定義在序列化後會顯著膨脹——括號、引號、冒號和逗號各自消耗 token。十個中等 schema 的工具在發送任何訊息之前就可能消耗 5,000-8,000 token。請審計序列化後的 token 數量，而非原始碼行數。

4. 對話歷史在代理迴圈中悄悄膨脹：每次工具呼叫都會將請求和完整回應加入歷史。經過 20-30 次迭代後，歷史可能消耗 70-80% 的窗口，而代理在推理品質崩潰前不會顯示明顯症狀。設定歷史的硬性 token 上限，並主動觸發壓縮。

5. 中間的關鍵指令會遺失：U 型注意力曲線意味著情境中間的召回準確度比開頭和結尾低 10-40%。切勿將安全限制、輸出格式要求或行為護欄放在長系統提示的中間——將它們錨定在頂部或底部。

6. 過於積極載入的漸進式揭露會適得其反：在第一次暗示相關性時就載入所有「可能相關」的技能或文件，會重現情境塞滿的問題。設定嚴格的啟用閾值——技能僅在任務明確符合其觸發條件時才載入，而不是當主題僅是鄰近時。

7. 混合指令高度會導致不一致行為：在同一提示中結合超具體規則（「總是使用恰好 3 個項目符號」）與模糊指令（「要有幫助」）會產生衝突訊號。按高度分組指令，並保持每個區段內部一致——要麼是啟發式驅動，要麼是規範性，不要交錯混合。

整合

此技能是概念基礎。它不負責操作型工作；它提供操作技能所假設的思維模型。

操作型工作的路由圖：

• context-degradation：診斷注意力失效、lost-in-middle、中毒、分心。
• context-optimization：token 效率策略（遮罩、分割、快取、預算）。
• context-compression：壓縮長對話同時保留決策、檔案、風險。
• filesystem-context：卸載大型輸出並使用檔案作為持久暫存區。
• memory-systems：跨對話記憶架構，包含實體追蹤。
• multi-agent-patterns：何時將工作拆分給多個代理以實現情境隔離。
• tool-design：撰寫能正確路由的工具描述和 schema。
• project-development：決定 LLM 適用性並塑造多階段管線。

先閱讀此技能以建立思維模型；在實際執行工作時閱讀適合該任務的操作技能。

參考資料

內部參考：

• 情境元件參考 - 閱讀時機：除錯特定情境元件（系統提示、工具定義、對話歷史、工具輸出）或實作分塊、觀察遮罩、預算分配表時

本集合中的相關技能：

• context-degradation - 閱讀時機：代理效能隨著對話增長或情境超過 60% 容量而下降時
• context-optimization - 閱讀時機：token 成本過高或需要壓縮/壓縮策略時

外部資源：

• Anthropic 的「AI 代理的有效情境工程」——壓縮、子代理和混合檢索的生產模式
• 關於 Transformer 注意力機制和 lost-in-the-middle 效應的研究
• 關於代理軟體工程 token 分佈的 Tokenomics 研究

---

技能元資料

建立日期：2025-12-20
最後更新：2026-05-15
作者：情境工程貢獻者的代理技能
版本：2.2.0