上下文管理，先至係真正嘅瓶頸
做數據同埋寫報告呢類嘢嘅生產 AI agent（AI 代理），真正卡住你嘅，好多時唔係模型夠唔夠勁，而係佢個上下文窗口（context window，模型一次性能「睇到」嘅資訊範圍）擺唔夠。
2026 年 11 月 4 日，AWS Machine Learning Blog 刊出一篇「上下文工程四層框架」技術文，並喺開源嘅 Deep Insight——一個建基於 Strands Agents SDK 同埋 Amazon Bedrock AgentCore 嘅多代理數據分析專案——逐層示範咗個代碼點樣落地。
上下文工程係乜嘢
「上下文工程」（context engineering）就係點樣喺模型有限嘅上下文窗口入面，將資訊排好，令 agent 做到最佳。AWS 指，Anthropic Claude Sonnet 4.5（喺 Amazon Bedrock 提供）有 200K 嘅上下文窗口，但生產環境嘅複雜任務會喺幾分鐘內就耗盡。
佢舉咗個例：「分析銷售數據並產生一份 DOCX 報告」呢個要求，實際要經過：
- 數據載入與探索（5 分鐘）
- 分類別銷售分析（3 分鐘）
- 五張時序圖（10 分鐘）
- 統計驗證（3 分鐘）
- 生成最終報告（5 分鐘）
呢五個步驟喺 15 分鐘內總共耗用超過 150K token。
如果全部塞喺同一個上下文入面處理，會有三個問題：中途窗口爆滿、陳舊上下文拉低效能、一錯就成條 pipeline 要重新行。而隨住上下文越積越多，模型對重要資訊嘅注意力會下降；加上按 token 計費， inefficiency 直接推高成本。
四層框架：隔開、控制、外置、驗證
呢篇（係系列文章嘅第 2 部分）將 Anthropic 嘅工程文章，同 Strands Agents SDK 嘅內建功能，收攏喺四個層：
- 架構層隔離上下文（isolate at the architecture level）
- 提示詞控制（control through prompts）
- 外置到檔案系統（externalize to the filesystem）
- 獨立驗證代理同安全機制（verify with independent agents and safeguards）
喺 Deep Insight 嘅參考實現入面，呢四層合併使用有幾個具體數字：
- 一個「寫入兼執行」嘅單一工具（write-and-execute tool），將每個腳本加入上下文嘅 token 削走約 95%
- 按需要加載技能（skills on demand），將系統提示詞（system prompt）削走約 97%
呢個系列仲有邊啲
- 第 1 部分：生產環境多代理系統嘅五個核心挑戰，同 Deep Insight 點樣解決
- 第 2 部分（即本文）：四層上下文工程，喺可運行代碼嘅實現
- 第 3 部分（即將刊出）：喺 Amazon VPC 私有網絡部署同運營 agent
阿調搞兩下
寫呢篇嘅係 AWS，示範代碼係 Deep Insight——AWS 自家生態入面嘅開源專案。所以上面「削走 95%」「削走 97%」呢兩個數，係廠商喺自家參考實現嘅數據，唔係獨立第三方測試。做數據分析同埋報告生成嘅開發者，值得留意呢套思路；但如果你嘅 stack 唔係建喺 Bedrock 或者 Strands SDK 上面，呢四層框架點樣遷移到其他模型同 SDK，就係你自己要落手做嘅部分。
上下文窗口再大，都係有數嘅。問題唔係個窗口開幾大，係你點排入面嘢。
阿調｜深度調教
