iT邦幫忙

2026 iThome 鐵人賽

DAY 11
0
AI Engineering

打造具備記憶與執行能力的常駐 AI Agent:Hermes Agent × Gemini × MCP 的 Harness 設計系列 第 11 篇

【Day 11】Context Engineering:把 context 當成會演化的 playbook

  • 分享至 

  • xImage
  •  

Context engineering 是四個範式裡的第二個,它與 prompt engineering 的分界在各自處理的對象。以下整理兩份一手資料各自怎麼界定這件事、提出哪些具名機制,再對照 Hermes 這一側現成的實作。


兩個名詞的分界

Anthropic 的文章把兩者放在同一段裡界定:

prompt engineering 指的是為了取得最佳結果而撰寫與組織 LLM 指令的方法

context engineering 指的是在 LLM 推論期間,策展並維護那一組最佳 token(資訊)的策略

兩者處理的對象不同:

  • prompt engineering:這一次要怎麼問
  • context engineering:問的時候,模型手上有哪些東西

第二個問題的對象涵蓋指令以外的內容:檢索到的段落、工具描述、先前的對話、寫在檔案裡的記憶。


長時間任務的三種具名做法

同一篇文章針對跑很久的任務列出三種技術,各自的原文定義如下:

技術 原文定義 處理的問題
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 會滿,差別在滿了之後把什麼留下來。


ACE:把 context 當成會演化的 playbook

Zhang 等人 2025 年的論文提出 ACE(Agentic Context Engineering),摘要裡的定義是:

一個把 context 視為會演化的 playbook 的框架,透過生成、反思、策展這個模組化流程,累積、精煉並組織策略

論文先界定它要解決的兩種問題,兩者都出現在「每一步都把整份 context 重寫一次」的做法裡:

  • brevity bias:最佳化朝短而通用的 prompt 收斂,犧牲多樣性、略去關鍵的啟發式規則
  • context collapse:模型在每次調整時被要求整份重寫,傾向把它壓成更短、資訊更少的摘要,造成資訊大量流失

對應的分工是三個角色:

角色 論文裡的職責
Generator 產生推理軌跡,藉此讓策略與陷阱浮現出來
Reflector 從成功與錯誤中提煉出具體的洞察
Curator 把這些洞察整合成結構化的 context 更新

避免整份重寫的機制有兩層:

  1. incremental delta updates:由 Reflector 提煉出小批候選條目,Curator 整合成精簡的 delta,舊知識保留、新洞察附加
  2. grow-and-refine:帶新識別碼的條目附加進去,既有條目就地更新,再以語意嵌入比對條目來去除重複

論文回報的結果是 agent 類基準 +10.6%、金融領域 +8.6%,同時降低調整延遲與 rollout 成本,並且靠自然的執行回饋就能調整。

兩份資料指向同一個動作:把有用的東西留在 context window 之外,需要時再放回去


對照 Hermes 現成的機制

這三類做法在 Hermes 都有對應的位置:

機制類型 Hermes 這一側 進入 context 的方式
Compaction 內建的 context 壓縮 觸發後把先前內容換成摘要
Structured note-taking memories/MEMORY.md、USER.md 搭配 FTS5 索引 寫在 context window 之外的檔案,需要時讀回
反思後策展 hermes curator 整理的是技能檔,技能再透過索引進入 context

curator 的官方說明是由輔助模型執行的背景任務,職責為:

  • 定期檢視 agent 自己建立的技能
  • 修剪長期閒置的
  • 合併重疊的
  • 封存已過時的

內建與 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 拆開。


上一篇
【Day 10】可替換性實測:一次端點替換與一次兩層 agent 的衝突
下一篇
【Day 12】固定 prompt 預算:量出每一項實際佔多少
系列文
打造具備記憶與執行能力的常駐 AI Agent:Hermes Agent × Gemini × MCP 的 Harness 設計 共 13 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言