第九章《上下文工程》习题答案｜逐章学习笔记

[jarvanstack]

本帖是我对《从零开始构建智能体》的逐章学习答案。基于教材仓库 main 分支提交 92e6891（2026-08-09 读取）。开放题为个人理解，欢迎指正。

原章链接：第九章 上下文工程

1. 有限上下文与 JIT

上下文腐蚀指输入变长后，有关信息被无关、重复或冲突内容稀释，模型对中间位置和跨段关系的利用下降，指令优先级也更易混乱。100K/200K 是容量上限，不是每个 token 都能被同等可靠地使用；长输入还增加延迟、费用、缓存失效和攻击面。上下文目标应是“足够且相关”，不是“越多越好”。

把 50 个文件一次性加载，优点是全局可见、无需多次工具往返，适合小而紧密耦合的代码快照；缺点是昂贵、易截断、旧生成文件/依赖污染注意力。JIT 先读取目录、diff、符号和依赖图，再按假设打开相关文件，成本低、证据聚焦且可获得最新状态；缺点是检索可能漏掉隐式依赖，工具往返增加延迟。代码审查宜采用 JIT + 最小全局骨架 + 依赖邻居扩展，关键变更再做全库静态分析。

过度硬编码示例：“必须依次调用 A/B/C，任何错误重试三次”，即使 B 不需要也浪费调用；过于空泛示例：“你是优秀代码助手，请审查代码”，没有证据、格式、权限和完成标准。平衡做法是固定不可变约束、输出契约和安全边界，把探索路径留给模型，并用测试集验证而不是凭提示长度判断。

2. GSSC 与质量评估

Gather 漏源会导致先天证据不足；Select 错选会造成“有资料但没送到模型”；Structure 失败会混淆来源、优先级与时间；Compress 过度会丢失限定条件、数值和否定。最终错误常表现相似，因此每阶段都应记录候选、分数和压缩映射，支持定位。

质量评估可输出：相关性（选中片段与目标相似度/重排分）；完整性（任务所需证据槽位覆盖率）；信息密度（非重复有效 token/总 token）；冲突率；来源与时效覆盖；预算占用。示意接口：

class ContextQuality(BaseModel):
    relevance: float
    completeness: float
    density: float
    conflicts: list[str]
    missing_slots: list[str]
    suggestions: list[str]

def assess(bundle, task_spec):
    return ContextQuality(
        relevance=reranker.mean_score(bundle.items),
        completeness=coverage(task_spec.required_evidence, bundle.items),
        density=unique_fact_tokens(bundle) / max(1, bundle.token_count),
        conflicts=find_conflicts(bundle.items),
        missing_slots=find_missing(task_spec, bundle.items),
        suggestions=suggest_repairs(bundle, task_spec),
    )

指标本身需在人工标注任务上校准，不能让同一个 LLM 同时压缩并无条件给自己高分。

简单截断适合日志尾部、固定格式且“最新最重要”的数据；滑动窗口适合连续对话/时序信号；LLM 摘要适合冗余自然语言，但有成本和失真风险。混合策略先保留系统约束、当前目标、错误原文、数值和最近 N 轮不压缩；对旧对话做抽取式摘要；低价值内容截断；需要细节时通过摘要中的 source ID JIT 回原文。

3. 笔记整理、审批与重构助手

临时笔记达到数量/token/时间阈值后，整理器先聚类去重，抽取“决定、约束、发现、未决项、证据”，再按稳定性与范围提升：跨任务稳定信息进项目笔记，当前任务决定进任务笔记，未经验证的猜想继续留临时区。合并前生成 diff；冲突不覆盖而是标记；所有提升项保留来源 ID。低价值临时笔记延迟删除，先进入可恢复回收区。

路径验证、命令白名单和权限检查仍不足以防符号链接逃逸、参数注入、TOCTOU、资源耗尽、供应链脚本和合法命令的危险组合。审批流程应把动作分级：只读自动；工作区可逆写入可预览 diff 后执行；敏感文件、网络外发、安装依赖、删除和生产操作强制人审。审批卡展示准确命令/参数、目标、数据范围、风险、回滚和有效期；批准令牌绑定动作哈希，不能复用于后续变体。

flowchart TD
  A["读取项目笔记与任务"] --> B["Terminal: 目录/符号/测试基线"]
  B --> C["生成重构计划并写任务笔记"]
  C --> D{"人类批准计划?"}
  D -- 否 --> C
  D -- 是 --> E["创建检查点/分支"]
  E --> F["执行一个最小改动"]
  F --> G["格式化/静态检查/测试"]
  G --> H{"通过?"}
  H -- 是 --> I["记录结果与证据"]
  H -- 否 --> J["记录故障并回滚/修复"]
  I --> K{"还有步骤?"}
  J --> K
  K -- 是 --> F
  K -- 否 --> L["总结、最终 diff、人工复核"]

Loading

4. 分层状态、恢复与依赖

即时层保存当前文件/命令输出，不保证跨会话；会话记忆保存近期交互、尝试和短期偏好；持久笔记保存已确认目标、架构约束、决定、任务状态和证据指针。笔记是权威计划，文件/测试是事实来源，Memory 不是事实数据库。写入时去重并带版本；冲突时以可验证的当前环境为准，再更新笔记。

断点记录至少包括 run_id、目标、输入版本/commit、计划版本、已完成步骤、当前步骤、产物哈希、工具副作用、测试结果、剩余预算和下一安全动作。恢复时重新读取 Git/文件状态，校验哈希和外部操作状态；不一致则进入 reconciliation，不能直接重放。副作用工具使用幂等键，checkpoint 原子写入。

任务依赖用 DAG 表示，每个任务含 id/status/dependencies/inputs/outputs/owner/retry_policy/checkpoint。调度器只运行所有依赖成功的节点；失败按策略阻塞下游或走补偿。NoteTool 可把 YAML front matter 作为机器状态、Markdown 作为人类解释；更新用乐观锁，图循环和缺失依赖在写入时拒绝。

5. 渐进式披露

调试“支付偶发重复扣款”时，先读告警和调用链 → 定位幂等服务 → 查相关日志 → 打开对应代码 → 复现并验证数据库约束。每一步产生的错误码、trace ID 和调用关系决定下一步，避免一开始加载整个系统。

探索引导可维护“假设—证据—信息增益—成本”表：优先执行能区分多个假设、风险低、可逆且成本小的动作；为每个分支设时间盒；两次无进展就回到目标重排；始终保留一份关键证据缺口清单。选择分数可设为 (预期信息增益 × 影响 × 成功率) / (成本 + 风险)。

渐进披露明显适合大型代码库故障诊断、开放式研究、动态旅行/库存规划；一次性加载适合短合同的全局一致性检查、小型配置文件迁移、对固定表格做整体统计。也可混合：小型核心规范全载入，大型证据库 JIT 检索。