Context engineering 是四個範式裡的第二個,它與 prompt engineering 的分界在各自處理的對象。以下整理兩份一手資料各自怎麼界定這件事、提出哪些具名機制,再對照 Hermes 這一側現成的實作。
Anthropic 的文章把兩者放在同一段裡界定:
prompt engineering 指的是為了取得最佳結果而撰寫與組織 LLM 指令的方法
context engineering 指的是在 LLM 推論期間,策展並維護那一組最佳 token(資訊)的策略
兩者處理的對象不同:
第二個問題的對象涵蓋指令以外的內容:檢索到的段落、工具描述、先前的對話、寫在檔案裡的記憶。
同一篇文章針對跑很久的任務列出三種技術,各自的原文定義如下:
| 技術 | 原文定義 | 處理的問題 |
|---|---|---|
| Compaction | 把接近 context window 上限的對話取出、摘要其內容,再以該摘要重新初始化一個新的 context window | 對話長度超過上限 |
| Structured note-taking | agent 定期把筆記寫到 context window 之外的記憶體,這些筆記稍後再被拉回 context window | 資訊需要跨越 context window 存活 |
| Sub-agent architectures | 與其由單一 agent 維持整個專案的狀態,改由專門的子 agent 以乾淨的 context window 處理聚焦的任務 | 單一 context 裝不下多個任務的狀態 |
三者的共同前提是 context window 會滿,差別在滿了之後把什麼留下來。
Zhang 等人 2025 年的論文提出 ACE(Agentic Context Engineering),摘要裡的定義是:
一個把 context 視為會演化的 playbook 的框架,透過生成、反思、策展這個模組化流程,累積、精煉並組織策略
論文先界定它要解決的兩種問題,兩者都出現在「每一步都把整份 context 重寫一次」的做法裡:
對應的分工是三個角色:
| 角色 | 論文裡的職責 |
|---|---|
| Generator | 產生推理軌跡,藉此讓策略與陷阱浮現出來 |
| Reflector | 從成功與錯誤中提煉出具體的洞察 |
| Curator | 把這些洞察整合成結構化的 context 更新 |
避免整份重寫的機制有兩層:
論文回報的結果是 agent 類基準 +10.6%、金融領域 +8.6%,同時降低調整延遲與 rollout 成本,並且靠自然的執行回饋就能調整。
兩份資料指向同一個動作:把有用的東西留在 context window 之外,需要時再放回去
這三類做法在 Hermes 都有對應的位置:
| 機制類型 | Hermes 這一側 | 進入 context 的方式 |
|---|---|---|
| Compaction | 內建的 context 壓縮 | 觸發後把先前內容換成摘要 |
| Structured note-taking | memories/MEMORY.md、USER.md 搭配 FTS5 索引 |
寫在 context window 之外的檔案,需要時讀回 |
| 反思後策展 | hermes curator |
整理的是技能檔,技能再透過索引進入 context |
curator 的官方說明是由輔助模型執行的背景任務,職責為:
內建與 hub 安裝的技能一律保留原狀,封存可以還原,自動化的動作止於封存,每一次變更都寫進稽核軌跡。
這與 ACE 的 Curator 動作相同、對象不同。ACE 的 Curator 寫的是 context playbook 裡的條目,Hermes 的 curator 管的是磁碟上的技能檔案,兩者都在做累積、去重與淘汰。
實機上跑一次 hermes curator status,讀到的狀態是:
curator: ENABLED
runs: 0
interval: every 7d
stale after: 30d unused
archive after: 90d unused
consolidate: off (prune-only; LLM merge pass opt-in)
curator-managed skills: 58 total (agent-created=0 bundled=58)
58 個技能全部是內建的,agent 自己建立的是 0 個。 機制已啟用、週期是七天,但可以整理的對象目前是空集合。合併那一段預設關閉,只做修剪,用輔助模型做合併需要另外開啟。
自我改進的迴圈要先有東西可以改進,機制啟用之後仍要有輸入才會運作
context collapse 這個詞第一次讀到時覺得抽象,直到把它對到一次實際的錯誤才具體起來。
那次的現象是 agent 在群組頻道裡用別人的名字自稱。追下去的原因是身分宣告只寫在 system prompt 裡出現一次,對話變長觸發壓縮之後,那段宣告被換成摘要的一部分而消失,模型剩下唯一能判斷身分的線索是訊息開頭的顯示名稱。
論文描述的是同一種機制:整份重寫會把細節磨掉,被磨掉的往往是當下看起來次要、實際上關鍵的那幾行。
差別在於論文處理的是策略條目被壓縮掉導致準確率下降,而身分宣告被壓縮掉的後果是答的人變成別人。
只存在於 context window 裡的內容,存活期就等於一次壓縮的間隔
量測固定 prompt 的實際佔用,把 system prompt、技能索引與工具 schema 各佔多少 byte 拆開。