第 10 章 · 上下文工程：组装、压缩与记忆

本篇目标：为一轮请求画出预算表，为一次长任务设计压缩策略，为跨会话设计记忆。 上下文工程是 Harness 的一个子集，不是与它并列的学科。

10.1 一次请求是怎么拼出来的

官方 DSH core/system-prompt 负责「prompt-section 与 tool-schema 的组装」。docs/architecture.md 的 turn flow 给出精确顺序：

claim 输入 → 快照 model selection → 组装 prompt sections + step-admitted tool schemas
→ agent/pre-step（可改写/拒绝）→ step/start
→ agent/request → prepareCall（绑定适配器，取消则什么都不提交）
→ 刷新运行时事实 → 协调提示词 → 准入 users → 冻结请求 → 流式调用

要点：组装发生在每 step，不是每 session。这意味着运行时事实（git status、时间、权限变化）可以随 step 更新，也意味着「同一 turn 内前后不一致」往往源于刷新而非模型抽风（第 06 章）。

官方 三条硬约束：

1. Model-visible means logged —— 新增模型可见输入必须新增会话事件。
2. 新增上下文的正规入口是 agent.inject()，落在下一次被准入的请求。
3. 插件若要改动已有消息内容，须注册 pure message projections，不能就地改历史。

判据 14：任何绕过正规入口、直接往 messages 数组里塞东西的插件，都在制造「日志里查不到的模型输入」。这类 bug 极难定位。

10.2 上下文预算表

把一轮输入拆成可管理的格子。下表是模板，数字需你自己测（第 09 章「你好」体检）：

预算纪律：给 E 设硬阈值，给 A–D 设上限并定期复审，F/G 默认不常驻。

10.3 压缩策略

社区 生产实践里较通行的阈值与做法（来自 Heym 公开运行时）：

原文 DSH 侧的对应能力：/compact 手动触发，极简模式直接砍掉上下文压缩（为了让跑分环境尽量少变量）。subsystems/compaction 是官方文档中的独立子系统页。

官方 提供了 hook 层的配套：PreCompact 可在压缩前归档完整 transcript，PostCompact 记录生成的摘要。

压缩最危险的地方：把「必须 100% 生效」的约束压没了。所以第 08 章才要求把这类约束迁到 hook / sandbox——它们不依赖留在上下文里。

10.4 记忆：跨会话靠什么

社区 Anthropic 在 Effective harnesses for long-running agents（2025-11-26）给出经典模式：initializer agent 先写好 progress file 与 feature list，之后每个新 session 第一件事是读它们。理由很直白：「each new session begins with no memory of what came before.」

官方 DSH 文档站有 /guide/mcp-memory（记忆 MCP）与 /reference/subsystems/persistence、spill、session-telemetry 等页面；架构层则由 append-only 日志 + projection seam 统一承载。

判据 15：记忆写「结论」不写「过程」。过程在日志里，随时可 replay；把过程塞进记忆，等于用高成本常驻上下文复刻一份已经存在的日志。

10.5 信息对等再访：注入的边界

第 03、06 章讲过 information parity。这里补一个反向风险：注入也会污染。

原文 极简模式连时钟上下文都砍掉了——这不是疏漏，是跑分环境的必要净化：任何随墙上时间变化的信息都会破坏可复现性。

10.6 本章产出与验收

核心产出：本项目一份真实上下文预算表（A–G 各格实测 token）+ 一条压缩策略（触发阈值、保留项、记录方式）+ 一份 MEMORY.md 模板。

验收点：

• 能说出「组装发生在每 step」带来的一个好处与一个风险
• 能解释为什么必须走 agent.inject() 而不能直接改 messages
• 能把一条常驻规则迁到 hook，并说明这对压缩鲁棒性的意义
• 能设计一个不污染可复现性的记忆方案
• 能对着 Trajectory 指出上一次压缩丢掉了什么

延伸阅读