第九章习题 参考答案

[pikeduo]

第九章习题参考答案：上下文工程

1. 上下文工程与提示工程的区别

1.1 什么是上下文腐蚀？为什么长上下文仍需谨慎管理？

**上下文腐蚀（context rot）**指的是：随着输入上下文中的 token 数量不断增加，模型从上下文中准确定位、回忆和利用关键信息的能力反而下降。第九章中提到，LLM 与人类一样有有限的“注意力预算”，每新增一个 token 都会消耗一部分注意力资源；而 Transformer 的注意力机制会让 token 之间形成大量两两关系，随着上下文长度增长，模型对关键信息的关注会被稀释。

所以，即使模型支持 100K、200K 甚至更长上下文，也不意味着应该把所有信息都塞进去。长上下文有几个问题：第一，噪声变多，模型更容易被无关信息干扰；第二，重要信息可能被埋在中间，出现“大海捞针”失败；第三，成本和延迟上升；第四，输出质量不一定随上下文长度线性提升。因此，上下文工程的目标不是“塞得越多越好”，而是在有限窗口中放入最相关、最高信号密度、最能支撑当前任务的信息。

1.2 代码审查助手：一次性加载所有文件 vs JIT 上下文

假设要审查一个包含 50 个文件的代码库。

策略一：一次性加载所有文件内容。

优点是：模型能一次看到全局信息，适合代码库较小、文件之间强耦合、任务需要整体一致性判断的情况。例如审查一个只有几千行代码的小项目，或者需要统一检查命名规范、架构分层、接口一致性时，全量上下文可能更直接。

缺点是：50 个文件很容易超出 token 预算，即使没超，也会造成上下文腐蚀；大量无关文件会稀释注意力，模型可能忽略真正关键的业务逻辑。并且代码一旦变动，之前加载的内容就可能过时。第九章也指出，完整代码库可能包含数万行，无法一次性放入上下文窗口，因此代码库维护案例使用 TerminalTool 按需探索具体文件。

策略二：JIT（Just-in-time）上下文，通过工具按需检索文件。

优点是：只在需要时查看目录、函数、日志或特定文件，token 开销低，信息更实时，适合大型代码库、长期重构、复杂调试。第九章提到，JIT 上下文不预先加载所有数据，而是保留文件路径、URL、查询语句等轻量引用，在运行时通过工具动态加载所需数据。

缺点是：探索过程更慢，需要设计好工具和检索策略；如果模型探索方向错误，可能遗漏关键文件。因此实际系统可以采用混合策略：先加载 README、目录结构、关键架构说明，再用 TerminalTool 的 find、grep、head、tail 等命令逐步探索。

1.3 系统提示的两个误区

误区一：过度硬编码。

例子：

如果用户问 A，就回答 X；
如果用户问 B，就回答 Y；
如果用户问 C，就调用工具 1；
如果用户说“继续”，就执行步骤 3；
如果用户说“重新来”，就删除所有历史……

这种提示把大量业务逻辑写成脆弱的 if-else，维护成本很高。一旦场景稍微变化，模型就可能不知道该遵循哪条规则。

误区二：过于空泛。

例子：

你是一个优秀的代码审查助手，请认真审查代码并给出建议。

这个提示太泛，没有说明审查重点、输出格式、安全边界、是否要引用文件路径、是否要区分严重程度，因此模型输出会不稳定。第九章也提到，系统提示的常见问题包括“过度硬编码”和“过于空泛”，建议用清晰分区组织背景、工具指引、输出要求等信息。

平衡点是：提示要定义角色、目标、边界、工具使用原则和输出格式，但不要把所有业务情况都写死。一个合适提示可以包括：

你是代码审查助手。
重点关注：安全风险、复杂度、重复代码、测试缺失、异常处理。
当需要查看代码时，优先使用 grep/find/head 等只读命令。
输出格式：
1. 总体结论
2. 高风险问题
3. 中低风险问题
4. 修改建议
5. 需要进一步确认的信息

---

2. GSSC 流水线：Gather-Select-Structure-Compress

2.1 某个阶段失效会产生什么影响？

GSSC 是 ContextBuilder 的核心流程，分为 Gather、Select、Structure、Compress 四个阶段。第九章说明，Gather 汇集多源候选信息，Select 根据相关性和新近性选择信息，Structure 组织成固定上下文模板，Compress 在 token 超限时压缩上下文。

如果 Gather 失效，会导致关键信息没有进入候选池。例如记忆系统、RAG、工具输出没有被收集，后面的 Select 再好也无从选择。表现为模型回答空泛，缺少依据。

如果 Select 失效，会导致上下文中混入大量无关信息，或者遗漏真正相关信息。这是最危险的阶段之一，因为模型看似有很多上下文，但真正有用的信息不在里面。

如果 Structure 失效，会导致信息堆叠混乱。模型无法区分哪些是系统规则、哪些是证据、哪些是历史对话，可能把用户历史当成当前任务，把工具输出当成指令。

如果 Compress 失效，可能有两种情况：压缩不足会超出 token 限制；过度压缩会丢失关键细节。例如把“依赖冲突来自 pandas 2.0 与旧版 numpy ABI 不兼容”压缩成“存在依赖问题”，就会失去诊断价值。

2.2 为 ContextBuilder 添加“上下文质量评估”功能

可以在每次 build() 之后，对上下文做三个维度评估：

1. 信息密度：有效信息 token / 总 token。
2. 相关性：上下文内容与用户问题的语义相似度。
3. 完整性：是否包含任务、约束、证据、历史状态、输出要求。

示例设计：

def evaluate_context_quality(context: str, user_query: str) -> dict:
    sections = {
        "role": "[Role & Policies]" in context,
        "task": "[Task]" in context,
        "evidence": "[Evidence]" in context,
        "context": "[Context]" in context,
        "output": "[Output]" in context,
    }

    total_tokens = estimate_tokens(context)
    useful_lines = [
        line for line in context.splitlines()
        if line.strip()
        and not line.strip().startswith("[")
        and len(line.strip()) > 10
    ]

    information_density = min(1.0, len(useful_lines) / max(1, len(context.splitlines())))

    relevance = simple_similarity(context, user_query)

    completeness = sum(sections.values()) / len(sections)

    score = (
        information_density * 0.35
        + relevance * 0.45
        + completeness * 0.20
    )

    suggestions = []

    if information_density < 0.4:
        suggestions.append("上下文中空泛或格式性内容较多，建议减少模板废话。")

    if relevance < 0.5:
        suggestions.append("上下文与用户问题相关性不足，建议优化检索或提高 min_relevance。")

    if not sections["evidence"]:
        suggestions.append("缺少证据区，回答可能缺乏依据。")

    if total_tokens > 0.9 * MAX_TOKENS:
        suggestions.append("上下文接近 token 上限，建议压缩历史对话或减少候选信息。")

    return {
        "score": round(score, 3),
        "information_density": round(information_density, 3),
        "relevance": round(relevance, 3),
        "completeness": round(completeness, 3),
        "suggestions": suggestions
    }

这个功能可以接在 ContextBuilder 的最后：

context = builder.build(...)
quality = evaluate_context_quality(context, user_query)

if quality["score"] < 0.6:
    print("[WARNING] 上下文质量偏低:", quality["suggestions"])

2.3 什么时候简单截断或滑动窗口比 LLM 摘要更合适？

LLM 摘要适合复杂长文本，但不总是最优。以下情况更适合简单截断或滑动窗口：

1. 日志分析：最新日志最重要，用 tail -n 200 比摘要更可靠。
2. 代码片段：函数实现、错误堆栈不能随意摘要，否则会丢失变量名、行号、异常类型。
3. 实时交互：需要低延迟时，调用 LLM 摘要成本太高。
4. 格式敏感内容：JSON、配置文件、SQL、代码 diff，摘要可能破坏结构。
5. 局部相关任务：只需要最近几轮对话，滑动窗口足够。

可以设计一个混合压缩策略：

def hybrid_compress(context_items, max_tokens):
    preserved = []
    compress_candidates = []

    for item in context_items:
        item_type = item.metadata.get("type")

        if item_type in ["system_instruction", "current_task", "error_stack", "code_diff"]:
            preserved.append(item)  # 原样保留
        elif item_type in ["recent_conversation", "recent_log"]:
            preserved.append(sliding_window(item, max_recent_tokens=800))
        else:
            compress_candidates.append(item)

    remaining_budget = max_tokens - count_tokens(preserved)

    if remaining_budget > 1000:
        summaries = llm_summarize(compress_candidates, budget=remaining_budget)
    else:
        summaries = truncate_by_relevance(compress_candidates, budget=remaining_budget)

    return structure_context(preserved + summaries)

原则是：系统指令、当前任务、错误栈、代码 diff 原样保留；历史对话用滑动窗口；背景资料和旧笔记用 LLM 摘要；低相关内容直接丢弃。

---

3. NoteTool 与 TerminalTool 扩展实践

3.1 设计“笔记自动整理”机制

NoteTool 使用 Markdown + YAML 的混合格式，既方便机器解析，也方便人类阅读；它适合记录任务状态、结论、阻塞、行动项和参考资料。 第九章也建议合理分类笔记，例如 task_state、conclusion、blocker、action、reference，并定期清理和归档。

可以设计三层笔记：

• 临时笔记：随手记录、工具观察、一次性想法。
• 任务笔记：某个阶段的目标、进度、阻塞、下一步。
• 项目笔记：长期有效的架构决策、规范、关键结论。

自动整理流程：

临时笔记数量达到阈值
        ↓
按标签、时间、相似度聚类
        ↓
抽取高频主题、关键结论、阻塞项
        ↓
判断提升类型
        ↓
生成或更新任务笔记 / 项目笔记
        ↓
标记原临时笔记为 archived 或 merged
        ↓
保留可追溯链接

提升规则：

if note.contains_blocker or note.importance >= 0.8:
    promote_to("task_note")

elif repeated_topic_count >= 3:
    merge_to("project_note")

elif note.type == "action" and deadline_is_near:
    promote_to("task_note")

elif note.is_outdated:
    archive(note)

整理后的项目笔记可以长这样：

---
title: 数据管道重构阶段总结
type: project_state
tags: [refactoring, data_pipeline]
source_notes: [tmp_001, tmp_004, tmp_008]
updated_at: 2026-06-12
---

## 已完成
- 数据模型层重构完成
- 测试覆盖率达到 85%

## 当前阻塞
- 业务逻辑层存在依赖版本冲突

## 下一步
- 梳理依赖树
- 锁定兼容版本
- 增加集成测试

3.2 TerminalTool 安全机制是否足够？如何设计审批流程？

TerminalTool 的安全机制包括命令白名单、工作目录沙箱、超时控制和输出大小限制；它只允许常见只读命令，并禁止访问工作目录外路径。 这些机制对普通探索任务足够，例如查看目录、搜索代码、分析日志，但如果涉及敏感文件或危险操作，仅靠白名单和路径限制还不够。

需要增加“人机协作审批”流程：

智能体提出操作意图
        ↓
风险分类
        ↓
低风险：自动执行
中风险：用户确认后执行
高风险：需要二次确认或禁止
        ↓
执行前生成操作摘要
        ↓
用户批准
        ↓
执行
        ↓
记录审计日志

风险分级示例：

风险级别	操作	策略
低风险	ls、grep、head、tail	自动执行
中风险	查看 .env.example、读取大日志、扫描大量文件	用户确认
高风险	读取 .env、私钥、生产配置	默认拒绝或脱敏后审批
禁止	rm、`curl	sh`、修改系统文件

审批提示可以这样设计：

智能体请求执行以下操作：

命令：cat .env
风险级别：高
原因：可能包含 API Key、数据库密码等敏感信息
建议：改为查看 .env.example，或只提取变量名不显示值

是否允许？
[拒绝] [脱敏执行] [允许一次]

3.3 智能代码重构助手工作流程图

可以设计为：

用户提出重构目标
        ↓
创建项目笔记：目标、范围、约束
        ↓
TerminalTool 探索代码库结构
        ↓
记录项目结构到 NoteTool / MemoryTool
        ↓
识别候选模块：复杂度高、重复代码、TODO、多依赖
        ↓
为每个模块创建任务笔记
        ↓
生成重构计划
        ↓
用户审批计划
        ↓
逐步执行重构
        ↓
每一步后运行测试 / 检查日志
        ↓
成功：更新 task_state / conclusion
失败：创建 blocker 笔记
        ↓
ContextBuilder 汇总当前任务、相关笔记、最近工具输出
        ↓
进入下一轮重构
        ↓
全部完成后生成项目总结

工具分工：

• TerminalTool：查看目录、搜索函数、定位 TODO、分析日志、运行只读检查。
• NoteTool：记录阶段计划、阻塞问题、已完成事项、架构决策。
• ContextBuilder：每轮对话前选择最相关的笔记、历史和工具输出。
• MemoryTool：保存用户偏好、长期项目事实和跨会话记忆。

第九章也展示了 TerminalTool 与 MemoryTool、NoteTool、ContextBuilder 的协同：工具发现的信息可以进入记忆系统，重要发现可记录为结构化笔记，TerminalTool 输出也可转换为 ContextPacket 进入上下文。

---

4. 长时程任务管理案例分析

4.1 三层上下文管理如何协调？

第九章代码库维护助手使用了三层架构：TerminalTool 即时访问、MemoryTool 会话记忆、NoteTool 持久笔记，并用 ContextBuilder 进行筛选和组织。文中也指出，长程代码库任务会遇到代码量超出上下文窗口、跨会话状态管理、上下文相关性不足等问题。

三层应该这样分工：

层级	存放内容	生命周期	示例
TerminalTool 即时访问	当前需要查看的文件、日志、目录、函数	临时	grep TODO、head src/app.py
MemoryTool 会话记忆	用户偏好、近期对话、项目事实	中短期到长期	“用户偏好先写测试再重构”
NoteTool 持久笔记	项目状态、计划、阻塞、决策	长期	“业务逻辑层重构计划”

避免冗余和不一致的方法：

1. TerminalTool 输出不要全部保存，只保存结论。
2. NoteTool 是项目状态的“事实源”，重要状态以笔记为准。
3. MemoryTool 保存偏好和历史摘要，不保存大量原始文件内容。
4. 每条笔记保留 source、updated_at、status。
5. 当 blocker 解决后，应更新为 conclusion 或 archived，而不是新建一条相互矛盾的笔记。

4.2 设计“断点续传”机制

断点续传的核心是：每完成一个重要阶段，都把足够恢复任务的信息写入结构化笔记。

笔记中至少要记录：

---
title: 业务逻辑层重构状态
type: task_state
status: in_progress
current_step: resolve_dependency_conflict
completed_steps:
  - analyze_model_layer
  - refactor_model_layer
  - run_unit_tests
blockers:
  - numpy 与 pandas 版本冲突
last_verified_commit: abc123
last_test_result: unit tests passed, coverage 85%
updated_at: 2026-06-12T10:00:00
---

恢复流程：

系统重启
    ↓
读取项目级 notes_index
    ↓
查找 status = in_progress 的任务
    ↓
读取最近 task_state、blocker、action
    ↓
用 TerminalTool 验证当前代码状态
    ↓
比较笔记记录与实际文件 / git 状态 / 测试结果
    ↓
一致：继续执行
不一致：进入人工确认或重新规划

验证机制：

def resume_task(project):
    state = note_tool.search(type="task_state", status="in_progress")
    last_commit = state["last_verified_commit"]

    current_commit = terminal.run({"command": "git rev-parse HEAD"})
    test_result = terminal.run({"command": "pytest --collect-only"})

    if current_commit.strip() != last_commit:
        return "代码状态已变化，需要重新评估任务计划"

    return "状态验证通过，可以继续执行"

4.3 任务依赖管理系统如何设计？

可以把任务建模为 DAG（有向无环图）：

---
title: 数据管道重构任务图
type: task_graph
tasks:
  A:
    name: 重构数据模型层
    status: done
    depends_on: []
  B:
    name: 解决依赖版本冲突
    status: in_progress
    depends_on: [A]
  C:
    name: 重构业务逻辑层
    status: pending
    depends_on: [B]
  D:
    name: 增加集成测试
    status: pending
    depends_on: [C]
---

调度规则：

def get_ready_tasks(tasks):
    ready = []

    for task_id, task in tasks.items():
        if task["status"] != "pending":
            continue

        deps = task.get("depends_on", [])
        if all(tasks[d]["status"] == "done" for d in deps):
            ready.append(task_id)

    return ready

与 NoteTool 集成方式：

1. 每个任务是一条 task_state 笔记。
2. 项目级任务图是一条 task_graph 笔记。
3. 任务状态变化时，同步更新任务图。
4. blocker 笔记可以挂到对应任务。
5. ContextBuilder 每次只拉取当前 ready task、相关 blocker 和最近 conclusion。

这样智能体就不会跳过前置任务，例如不会在依赖冲突未解决前直接重构业务逻辑层。

---

5. 渐进式披露

5.1 应用场景：复杂问题调试

以“线上服务响应变慢”为例，渐进式披露流程如下：

用户：线上接口最近变慢了
        ↓
智能体先查看最近错误日志摘要
        ↓
发现慢查询关键词
        ↓
进一步 grep slow query
        ↓
定位到 UserService.get_user_orders
        ↓
查看该函数实现
        ↓
发现 N+1 查询
        ↓
查看 ORM 模型关系
        ↓
提出优化方案：预加载关联、加索引、增加缓存
        ↓
记录 blocker 和 action 笔记

这个过程不是一开始就加载所有日志、所有代码、所有数据库配置，而是每一步基于新发现决定下一步探索方向。第九章把渐进式披露描述为：每一步交互都会产生新的上下文，并反过来指导下一步决策；它让智能体按层构建理解，只在工作记忆中保留当前必要子集。

5.2 设计“探索引导”机制

渐进式披露的风险是探索效率低：智能体可能一直看无关文件，或者陷入细节。可以设计元认知策略：

每次探索前，智能体必须回答：
1. 当前目标是什么？
2. 已知事实是什么？
3. 最大不确定性是什么？
4. 下一步探索能减少哪个不确定性？
5. 如果结果无关，何时停止？

可以加入启发式规则：

def choose_next_exploration(state):
    if state.has_error_stack:
        return "优先查看堆栈指向的文件和函数"

    if state.has_keyword:
        return "用 grep 搜索关键词出现位置"

    if state.no_project_structure:
        return "先查看目录结构和 README"

    if state.has_blocker:
        return "优先检索 blocker 相关笔记"

    if state.explored_steps > 5 and no_new_information:
        return "停止探索，生成阶段性总结并询问用户"

还可以设置探索预算：

exploration_budget:
  max_tool_calls: 8
  max_files_to_open: 5
  max_log_lines: 200
  stop_if_no_new_signal: true

这样既保留渐进式探索能力，又避免无限搜索。

5.3 渐进式披露 vs 一次性加载所有上下文

渐进式披露明显更适合：

1. 大型代码库维护
   文件多、依赖复杂，不可能一次加载全部代码。应先看目录，再定位模块，再查看函数。
2. 线上故障排查
   日志巨大且实时变化，应先看最新错误，再逐步缩小范围。
3. 学术研究综述
   文献数量大，先看标题摘要，再筛选重点论文，再深入方法和实验。

一次性加载更适合：

1. 短文本改写
   例如改一封邮件、润色一段简历，全文一次加载即可。
2. 小型配置审查
   例如审查一个 100 行 YAML 配置，整体上下文很小。
3. 单文件代码审查
   如果只有一个 200 行 Python 文件，一次性加载能保证模型看到完整结构。

总体来说，渐进式披露适合“大、动态、不确定、需要探索”的任务；一次性加载适合“小、静态、边界明确”的任务。第九章总结中也强调了分层设计、智能筛选、安全机制和人机协作，这些都是渐进式上下文工程在长时程任务中发挥作用的关键。