Day 05 - Weekly Review 1: Minimal Agent Design

今日目标

能独立完成一页《日报生成 Agent v0.1》设计说明，整合 Day 1-4。

学习安排

时间	模块	做什么
0-10 分钟	复盘回顾	整理 Day 1-4 的产物：组件图、分工表、任务拆解表、状态表。
10-25 分钟	查漏补缺	对照第 1 章回看 Day 1-4 的阅读重点，标出还说不清的概念。
25-45 分钟	交付物输出	完成《日报生成 Agent v0.1》一页设计说明，这是本周核心交付物。
45-55 分钟	设计评审	用自检问题评审自己的设计，找出 2 处可改进点。
55-60 分钟	阶段小结	总结本周「我能解释什么、我能做出什么」，定下 Day 06 复习点。

核心概念

术语	中文解释	应用场景
design doc	设计文档：描述 Agent 目标、架构、输入输出与风险的一页说明。	《日报生成 Agent v0.1》设计说明
target user	目标用户：Agent 要服务的人及其核心痛点，决定一切设计取舍。	每天花 30 分钟手工整理日报的测试工程师
MVP	最小可行产品：只包含核心价值、砍掉非必要功能的第一版。	v0.1 只做「生成草稿」，不做自动发布
input/output	输入输出：明确 Agent 吃什么数据、产出什么格式，是验收的前提。	输入缺陷与指标数据，输出 Markdown 日报
tool list	工具列表：Agent 需要的外部能力清单，含用途与权限。	query_db、read_file、generate_markdown
permission	权限：哪些动作必须人工确认或直接禁止执行。	发送邮件必须人工确认，删除数据禁止执行
risk	风险：数据泄露、编造、误操作等潜在问题及缓解措施。	模型可能编造缺失指标，用「待验证」标注缓解
scope cut	范围裁剪：明确 v0.1 不做的事，防止范围膨胀。	不做自动发布、不做多项目对比分析
success criteria	成功标准：判断 v0.1 是否可用的可量化条件，是验收的依据。	报告数据忠实、10 分钟内出稿
architecture diagram	架构图：用组件图表达 Agent 各部分的连接关系，Day 01 产物升级而来。	把「每日测试报告整理 Agent」组件图挂到设计文档开头
audit trail	审计轨迹：设计里写清记录什么，v0.1 至少记录工具调用参数与返回摘要。	出问题后能回溯是哪一步产生的错误数据

阅读重点

对应章节：第 1 章整章回顾（Agent 基础、执行循环、LLM 角色、任务规划、状态与反馈）。
关注点：
用 Agent 基本公式核对设计：LLM、上下文、工具、编排是否都有明确答案。
用「观察 → 思考 → 行动 → 反馈」检查执行步骤是否闭环。
用能力边界检查：哪些步骤依赖模型，哪些依赖工具，分工是否清晰。
用状态与反馈检查：设计中是否包含失败处理和人工介入点。
补充材料：
重看 Day 1-4 的学习笔记与全部产物，找出前后矛盾的地方。
Anthropic 文档 Building Effective Agents 中「以简单方案开始」的建议，对照自己的 scope cut。

理解检查

我能不用笔记说清 Agent 与 Chatbot 的区别吗？说不清就回看 Day 01。
我的设计里，哪一步是「工具调用决策」、哪一步是「工具执行」？
我的设计里，信息不足时 Agent 会做什么？会不会硬下结论？
我的设计里，哪一步失败会导致整个任务中断？有没有兜底？

实践任务

背景：本周第 5 天，你要把 Day 1-4 的四个产物整合成一份 1 页设计说明《日报生成 Agent v0.1》，它同时是 Day 10 交付物的基础。目标用户就是你所在的 QA 团队。写之前先想清楚一句话：这个 Agent 为谁省了什么时间。

步骤：

收集 Day 1-4 的产物：组件图、LLM/工具分工表、任务拆解表、状态表。
按下方设计文档骨架逐节填写，每节限 2-3 句，整体控制在一页。
用 scope cut 砍掉至少 3 个非必要功能，写进「v0.1 不做」。
用设计评审问题检查一遍：核心价值、权限、失败处理是否都写到了。
对照 Day 01 组件图，确认设计文档没有漏掉任何组件。
产出：一页《日报生成 Agent v0.1》设计说明，保存为本周交付物。

输出模板

# 日报生成 Agent v0.1 设计说明

- 目标用户：[xxx]
- 核心价值：[一句话]
- 输入数据：[数据清单]
- 模型：[模型及选型理由]
- 上下文组成：[system prompt / 当日数据 / 昨日报告摘要]
- 工具列表：[工具名 + 用途 + 权限]
- 执行步骤：[5 步以内]
- 状态与失败处理：[状态迁移 + 重试规则]
- 风险与限制：[3 条以内]
- Scope Cut（v0.1 不做）：[至少 3 条]
- 成功标准：[如何判断 v0.1 可用]

示范输出

# 日报生成 Agent v0.1 设计说明

- 目标用户：每天需要手工整理测试日报的 QA 工程师
- 核心价值：把 30 分钟的日报整理压缩到 5 分钟
- 输入数据：缺陷库昨日数据、CI 测试结果、性能指标
- 模型：中等能力模型，推理与生成够用，成本和延迟可控
- 上下文组成：system prompt（规则 + 输出格式）+ 当日数据 + 昨日报告摘要
- 工具列表：
  - query_db：查缺陷，只读
  - read_file：读昨日报告，只读
  - query_metrics：查性能指标，只读
  - generate_markdown：生成报告草稿，写入临时目录
- 执行步骤：收集需求 -> 查缺陷 -> 查指标 -> 生成草稿 -> 输出待确认
- 状态与失败处理：查询失败重试 2 次；分析数据不足时回退到查询
- 状态与失败处理：报告发布动作必须人工确认
- 风险与限制：可能编造缺失数据，用「待验证」标注
- 风险与限制：数据源权限不足时降级为手工输入
- Scope Cut（v0.1 不做）：不做自动发布；不做多项目对比；不做长期记忆
- 成功标准：报告数据忠实、10 分钟内出稿、发布前人工确认

追问练习

哪些动作必须加权限确认？你判断「必须」的标准是什么？
v0.1 不做哪些能力？砍掉这些功能会带来什么影响？
如果只能保留 1 个工具，你会保留哪个？为什么？
你的设计最可能在哪一步失败？你打算怎么验证这个判断？

常见误区

一上来就做「全自动」：没有人工确认的 Agent 只能留在演示环境，生产环境风险极高。
范围膨胀：把记忆、多 Agent、自动发布都塞进 v0.1，结果什么都做不好。
只写功能不写风险：设计文档没有失败处理，等于没有设计。
工具列表贪多：v0.1 应该以 2-4 个只读工具起步，先只读，后写入。

进阶扩展

生产视角：设计文档还要包含成功标准与评估方式，这是 Day 21-23 的主题。
一页设计文档是团队评审的最小单元：评审重点放在权限边界与 scope cut。
从 v0.1 到 v0.2 的演进路径：先补评估集，再加新工具，最后才考虑自动发布。

今日作业

保存《日报生成 Agent v0.1》设计说明，这是 Day 10 交付物的基础。
明天开始前，用 3 句话向同事复述你的设计：用户、价值、不做的事。
记录 2 个仍说不清的概念，Day 06 带着问题进入第 2 章。
把 Day 1-4 的全部产物归档到学习笔记，标注每份产物在 v0.1 里的去向。

自检清单

我能独立完成一页 Agent 设计说明。
我能说清设计的核心价值与目标用户。
我能列出工具清单并说明各自的权限。
我能明确列出 v0.1 不做的事。
我知道 Day 06 要从第 2 章哪个小节开始。