Context Engineering
Context Engineering 是在固定的 context window 和記憶體預算下，透過寫入、選擇、壓縮、隔離，讓 agent 把「當下需要的資訊」放進 context，而不是把所有資訊都塞進去。AIHAO 引用 SemiAnalysis 的記憶體短缺分析，直接把長 context 的問題拉回物理限制：KV cache 會隨 token 線性成長，HBM / DRAM 供給不會因為大家想要就自動變多。
四個基本動作
- 寫入 context：把偏好、歷史結論、可重用知識放到 context window 外，需要時再取回。
- 選擇 context：用檢索、記憶提取、工具策展，只載入當下任務所需的資訊。
- 壓縮 context：長對話要 compaction，只保留執行任務必要的 token。
- 隔離 context：把支線工作拆給 sub-agent，各自用自己的 context 執行。
指令化壓縮與可恢復狀態
BusinessNext 2026-08-19 對 Claude Code 指令的整理，把四個動作落成可操作的控制面：/compact 壓縮對話、/context 顯示使用量、/clear 開新脈絡、/rewind 回到 checkpoint。這種明確指令比用自然語言描述「回到剛才」更容易產生可預期、可回溯的狀態；但它仍是產品操作整理，指令名稱與行為要以當期官方文件重驗。
可重用的 context gate 是 先判斷要保留什麼 → 用明確操作壓縮或隔離 → 確認狀態 → 再繼續執行，而不是為了省 token 直接刪掉未驗證的工作脈絡。這把 agent-experience 的控制面、loop-engineering 的 checkpoint 與 agent-trace-observability 的可回查狀態接在一起。
為什麼重要
這不是純成本優化，而是品質問題。當 context 變長，推理成本、重送成本和 retry 成本都會上升；而且模型也不會真的把每個 token 都用滿。這表示 context 的價值在密度，不在長度，agentic-ai-cost-management 與 model-harness-fit 都要把這件事當成基本假設。
BusinessNext 對 Fable 5 的整理補上一個可操作的 context gate：完整描述最終目標，要求只回報有證據的結果，先分清是「給建議」還是「直接執行」，資訊足夠就行動而不要過度分析。成本控制則包括大型檔案先搜尋再取片段、切換任務時清空舊上下文，以及低難度工作降低 effort；這把「上下文密度優先」落成可操作的工作流。
Voice-first context capture
BusinessNext 轉述 Andrej Karpathy 的 voice ramble 做法：當使用者懶得先寫出完整 prompt 時，先用語音把背景、目標、限制、卡住的地方與猶豫倒出來，再讓 LLM 整理。這是 context engineering 的輸入策略，不是把「講得亂」本身當成品質保證；文章只有 Karpathy 的個人觀察，不能直接推論修正率或任務成功率。
可重用的最小 gate 是：先 capture，再要求模型用自己的話重述任務、列出不確定處並反問 2–3 個問題；人確認對頻後，才讓它寫文件、程式或企劃。這把長輸入的整理成本交給模型，但把事實、數字、權限與不可逆行動的確認留給人，並與 ai-cognitive-offloading-and-agency、agent-experience 和 prompt-debugging-eval-checklist 相連。語音轉錄可能錯字、模型可能補入未提供的內容，且錄音可能上傳雲端，因此機敏內容與關鍵名詞要先檢查。
2026-07-30 的 BusinessNext 操作整理補充了實作細節：Mac 可用系統聽寫快捷鍵，Windows 可用 Win + H，並在開頭標示「接下來是語音轉文字，可能說得比較跳」。這些只是降低輸入摩擦的入口；真正的 context gate 仍是回述任務、列出不確定處、反問 2–3 題，並在執行前由人確認數字、名稱與未被模型超譯的限制。
Persistent thread 與多模態 context capture
BusinessNext 整理 Jason Liu 的 Codex workshop，補上一個長時程 agent 的 context pattern：不要把每次喚醒都當成新任務，而是讓同一條 thread 透過 compaction 持續累積上下文，再用專案命名、記憶庫與工作日誌保存跨輪狀態。這把 context engineering 從「這一輪要塞哪些 token」延伸到「哪些狀態值得跨輪留下」；長對話仍可能遺失細節、快取失效並增加成本，因此是否重開 thread 要由任務風險、context 品質與 agentic-ai-cost-management 一起判斷。
同一案例也把 context capture 分成低摩擦輸入與可機器讀取的環境感知：語音 ramble 先提供背景與模糊線索，Appshots 再把視窗畫面和 accessibility 文字附加到對話。這種做法可降低輸入成本，但不代表模型自動取得正確權限或完整事實；應接回 agent-experience 的介面設計、agent-instruction-files 的常駐邊界，以及不可逆動作前的人工確認。
Claude 5 世代：從過度約束轉向模型判斷
BusinessNext 2026-07-29 引述 Anthropic 工程團隊對 Claude 5 世代的整理：Claude Code 刪減超過八成系統提示詞後，內部編碼評測沒有可測量下滑；其可重用的方向不是「永遠少寫規則」，而是減少互相衝突的 overconstraining，讓模型依任務與既有程式風格判斷。這是產品／官方文件的歸納，不是跨模型、跨任務的獨立 benchmark，舊模型或高風險領域仍可能需要更強的護欄。
實作上可把常駐的 agent-instruction-files 縮成模型無法自行發現、且每輪都必須遵守的專案規則；把流程、團隊觀點與參考資料放進 agent-skills，透過 progressive disclosure 按需載入；再用 model-harness-fit 與任務級 eval 驗證刪減後是否真的改善成本、延遲或成功率。清楚的工具介面、測試碼、HTML prototype 與 rubric 可作為高保真參照物，但不能把「範例減少」誤讀成「所有範例都該刪除」。
Data agent：context collection 比主迴圈更關鍵
Hex 的資料 agent 將 context 分成動態專案狀態／warehouse schema 與靜態 guide／規範；受訪者認為真正的工程含量在於 context collection pipeline，而不是「LLM 迴圈呼叫工具」本身。工具太多時可合併重複操作、移除重複說明，或以 tool search 按需載入；ephemeral SQL 則把背景探索與使用者可見的 notebook 產出分開，但必須用 eval 管住證據缺口與無限查詢。
同一案例也補上 context 的來源隔離：資料團隊的 semantic model／guide 與個人 memory 不應混成一層，否則過期或錯誤記憶會和治理定義衝突。長時程 agent 不應因為 1M context 就填滿窗口；較穩的做法是保留較大的存取上限，但以 eval 找到較早的 compaction threshold，並觀察 context 累積後是否真的改善後續回合。
AI 記憶體階層：硬體不是 context 的替代品
BusinessNext 2026-08-06 更新的 HBF 報導，補上一個硬體層的 context 邊界：HBF 被定位為 HBM 與 SSD 之間的近端大容量層，以 NAND 承接較慢但較大的 warm data，讓 HBM 保留給低延遲熱資料。這可連到 ai-memory-hierarchy，但 HBF 的規格、量產與系統效能仍是來源報導／廠商資料，不能直接視為已驗證的部署方案。
這不會取消 context engineering。把資料搬到更大的 memory tier 仍有延遲、頻寬、控制器與 cache miss 成本；agent 仍應先選擇、壓縮與隔離當下需要的資訊，再決定哪些狀態值得寫入較遠的層。agentic-ai-cost-management 因此要把 KV cache、資料搬移與任務級完成率一起算，而不是只看可用容量。
Context scarcity 是產品瓶頸
BusinessNext 2026-08-24 整理 Sam Altman 的自我診斷：即使模型已經足夠聰明，Codex 仍未成為他的日常工作方式，部分原因不是模型能力不足，而是 agent 掌握的個人與組織脈絡太少。理想中的 agent 應能讀取內部 Slack、客戶回饋與尚未閱讀的論文，並在決策時把相關脈絡端上來；這是「模型會不會做」之外的 context acquisition 與 productization 問題，不是使用者把 prompt 寫長就能解決。
可重用的 context gate 是 列出決策所需的來源 → 先做權限與新鮮度篩選 → 以可回查摘要或 evidence 供 agent 使用 → 讓人確認脈絡是否足夠再執行。把更多資料直接塞進 context 會放大隱私、過期資訊與錯誤推論風險，因此要和 agent-experience 的控制面、agent-ready-data-governance 的資料範圍及 model-harness-fit 的任務級驗證一起設計。
Persistent memory：把 context 寫入變成可控資產
Anthropic 2026-08-25 宣布 Claude Chat 與 Claude Cowork 共用記憶：雲端 Cowork 讀得到聊天累積的專案脈絡，任務中產生的新資訊也能回到聊天；本機 Cowork session 不使用這套共用記憶。這把 context engineering 的「寫入 context」從單一對話的摘要，推進到跨工作面、受 runtime 約束的 persistent context；產品情境仍不是記憶正確率或任務效益證據。
來源同時把記憶做成 Topics 下的個別短檔案，並讓使用者逐則閱讀、編輯、刪除、暫停或重設；敏感主題預設不存，開啟後仍有通知、只向前保存與不可儲存類型的限制。可重用的 gate 是 來源／範圍 → 寫入時機 → user-visible memory → edit／delete／pause／reset → runtime check：可編輯不等於正確，跨 Chat／Cowork 也不等於所有本機或遠端 session 都共享同一脈絡；Team／Enterprise 的組織控制還要按當期方案與文件重查。