Day 10 - Weekly Review 2: Context Design Document

今日目标

能输出《测试报告 Agent 上下文设计 v0.1》，理清信息来自用户、系统、工具、记忆还是检索。

学习安排

核心概念

阅读重点

• 对应章节：复盘第 2 章，重点重读上下文窗口构成、上下文压缩与 Agent Skills 三节。
• 关注点：
• 从「单个 Prompt」上升到「整个上下文的设计」：系统、工具、记忆、检索如何协作。
• 历史摘要策略：什么时候压缩、压缩成几层、由谁触发。
• 错误处理策略：哪些错误由模型处理、哪些由 harness 处理、哪些需要人工。
• 如何验证设计有效：把 Day 6 的 system prompt 与 Day 9 的 Skill 组合起来跑样例。
• 补充材料：
• Anthropic 的 context engineering 文档，对照检查你的设计遗漏了哪个维度。
• OpenAI 的 prompt engineering 指南中关于迭代评估的部分。

理解检查

• 你 Day 6-9 的四份产物，分别对应上下文设计的哪一部分？
• 一个 Agent 的上下文里，哪些信息来自用户、哪些来自系统、哪些来自工具、哪些来自记忆、哪些来自检索？各举一例。
• 当前上下文设计最大的风险是什么？
• 哪些信息会频繁变化？这些信息由谁负责更新？

实践任务

背景：今天是阶段复盘日。前四天你分别写出了 system prompt、结构化 Prompt、三层摘要和一个 Skill，今天把它们串成一份完整的上下文设计文档。

步骤：

• 汇总 Day 6 的 system prompt 与 Day 7 的结构化 Prompt，作为系统层与用户层的核心内容。
• 设计 tool descriptions：列出 2-3 个工具，各写用途、参数、返回。
• 定义输入数据格式：日期、数据源、指标字段的约定。
• 写历史摘要策略：多久压缩一次、分几层、由谁触发。
• 写错误处理策略：数据缺失、工具超时、输出解析失败分别怎么办。
• 定输出格式：报告章节与表格列。
• 按「用户、系统、工具、记忆、检索」五类信息源核对每一部分，填入输出模板的信息源清单。
• 保存为 context-design-test-report-agent-v0.1.md。

产出：一份完整的《测试报告 Agent 上下文设计 v0.1》，成为 Day 20、Day 30 交付物的基础。信息源归属用一句话自查：这段信息是用户给的、我写死的、工具查来的、记住的，还是检索出来的。

输出模板

《[Agent 名] 上下文设计 v0.1》

目标与范围：
- [这个 Agent 做什么]。
- 不做：[不做什么]。

system prompt：
- 角色：[角色]。
- 规则：[行为底线]。
- 输出约定：[格式]。

tool descriptions：
- [工具名]：用途 [xxx]，参数 [xxx]，返回 [xxx]。

输入数据格式：
- [字段]：[类型/示例/必填]。

历史摘要策略：
- 触发时机与层级：[轮次或 token 阈值]，[层数与每层长度]。

错误处理策略：
- [错误类型]：[处理方式]。

输出格式：[章节与字段]。

信息源清单：
- 用户：[哪些信息]。
- 系统：[哪些信息]。
- 工具：[哪些信息]。
- 记忆：[哪些信息]。
- 检索：[哪些信息]。

已知风险与待验证项：[列表]。

示范输出

《测试报告 Agent 上下文设计 v0.1》

目标与范围：
- 每天根据用例执行数据、缺陷数据与性能数据生成 Markdown 测试报告。
- 不做：不执行测试、不修改数据、不发送报告。

system prompt：
- 角色：测试报告分析助手。
- 规则：只基于输入数据输出；不确定结论标注「待验证」；不编造缺失数据。
- 输出约定：Markdown，结构为概述、用例执行、缺陷摘要、性能指标、待验证事项。

tool descriptions：
- read_test_data：读取指定日期的测试执行数据，参数为日期，返回用例统计。
- query_metrics：查询接口性能指标，参数为指标名与时间窗，返回 TPS、P95、错误率。
- generate_markdown：把结构化内容渲染为 Markdown 报告。

输入数据格式：
- date：日期，如 2026-08-13，必填。
- 数据源：默认从 read_test_data 与 query_metrics 获取，可选切换环境。

历史摘要策略：
- 触发时机与层级：对话超过 10 轮或摘要超过 2000 token 时触发；一层完整摘要，保留关键数字与待验证项，结论行用于下一轮。

错误处理策略：
- 数据缺失：标注「无数据」，不推测，列入待验证事项。
- 工具超时：重试一次，仍失败则说明并跳过该数据源。
- 输出解析失败：由 harness 重试一次，再失败交给人工。

输出格式：
- 概述（今日结论与风险）、用例执行表（用例数/通过/失败）、缺陷摘要表（编号/标题/严重程度/状态）、性能指标表（指标/值/环比/是否达标）、待验证事项（假设/原因/验证方法），全部为 Markdown 表格。

信息源清单：
- 用户：日期、环境选择、临时要求。
- 系统：system prompt、tool descriptions、输出格式约定。
- 工具：指标与日志数据。
- 记忆：历史报告结论摘要。
- 检索：指标口径与报告规范。

已知风险与待验证项：
- 风险：性能数据口径可能跨版本变化，摘要可能丢失数字；待验证：用 5 天真实数据跑通后检查关键指标覆盖率。

追问练习

• 哪些信息应该长期记忆？如果记忆和检索结果冲突，你的设计听谁的？
• 如何验证上下文设计是否有效？你会看哪些指标？
• 如果只能给 v0.1 保留一个设计部分，你会保留哪个？为什么？
• 把这份设计拿给同事看，你预期他会指出哪三个问题？

常见误区

• 只设计 system prompt，不设计信息源与更新机制：文档停留在「写一段话」。
• 把会变化的业务规则写死在 system prompt：规则一改就要动 prompt。
• 没有错误处理设计：工具一失败，整个流程就停。
• 不写验证方式：设计有没有效，凭感觉而不是凭数据。

进阶扩展

• 用 eval 集验证上下文设计：把 v0.1 的上下文方案跑在 10 条样例上，记录编造率与关键指标覆盖率。
• 上下文设计的持续迭代：每个版本记录改动与效果，像产品一样做迭代。
• 与 Day 20、Day 30 交付物的衔接：这份上下文设计是工具型 Agent 与最终项目的基础。

今日作业

• 完成《测试报告 Agent 上下文设计 v0.1》，保存为可复用文件。
• 整理 Day 6-9 的四份产物，标注各自状态与缺口。
• 写下阶段复盘三句话：本周我学会了什么、还差什么、下周的重点是什么。

自检清单

• 我能说清上下文中每部分信息来自哪个信息源。
• 我能输出完整的上下文设计文档。
• 我能为历史摘要与错误处理写出具体策略。
• 我能指出 v0.1 最大的风险与验证方法。
• 我能把 Day 6-9 的产出串成一份设计文档。