多 Agent 与项目
Day 28 - Final Project Design
今日目标
能定义「技术问题分析 Agent」的 MVP 范围与成功标准。
学习安排
| 时间 | 模块 | 做什么 |
|---|---|---|
| 0-10 分钟 | 核心概念 | 通读当天术语表，圈出 3 个你最想在工作里用上的概念。 |
| 10-25 分钟 | 阅读输入 | 精读当天章节重点，只抓问题、思路、结论。 |
| 25-45 分钟 | 实践任务 | 动手完成输出模板，必须产出一份可复用产物。 |
| 45-55 分钟 | 追问与反思 | 回答追问练习，标记卡住的概念。 |
| 55-60 分钟 | 复盘与作业 | 整理自检清单，定下明天要复习的一点。 |
核心概念
| 术语 | 中文解释 | 应用场景 |
|---|---|---|
| MVP | 最小可行产品，只做验证核心价值所必需的最小功能集 | 项目第一版只做一条完整分析链路 |
| scope | 范围，明确这个项目做什么、不做什么 | 列出必须做、可暂缓、明确不做三档 |
| success criteria | 成功标准，可验证的完成条件，而不是感觉上的好坏 | 一个输入对应一个预期输出和一个通过条件 |
| capability cut | 能力裁剪，主动砍掉非核心能力以控制范围 | 不做多 Agent、不做长期记忆 |
| risk list | 风险清单，列出可能失败的点与缓解办法 | 知识库资料不足、工具返回空数据 |
| eval plan | 评估计划，用什么用例、什么指标判断系统好坏 | 10 条用例覆盖简单分析、缺失信息、工具失败 |
| deliverable | 交付物，项目结束时必须产出的东西 | 可运行 Demo、运行日志、评估结果 |
| mock tool | 模拟工具，用预置数据代替真实系统的工具 | 用固定日志文件模拟 query_logs |
| acceptance example | 验收示例，一组输入对应一组预期输出，用于核对实现 | 输入 WAF 问题，预期输出含假设与验证步骤 |
| demo | 可演示版本，能现场跑通的完整闭环 | 30 天结束时演示从问题到报告的全过程 |
阅读重点
- 对应章节：Day 28-30 为全计划回顾。回看第 1 章执行循环、第 2 章上下文、第 3 章记忆与 RAG、第 4 章工具、第 6 章评估、第 10 章多 Agent。
- 关注点：
- 从「用户问题」到「Markdown 报告」的完整链路需要用到哪些模块。
- 30 天学过的上下文、检索、工具、评估如何组合进同一个系统。
- MVP 范围怎么定：哪些能力必须做，哪些可以砍。
- 成功标准怎么写才可验证：一个输入、一个预期输出、一个通过条件。
- 补充材料：
- OpenAI Evals 与 LangSmith 的评估文档，参考用例的组织方式。
- MCP 官方文档中模拟工具与真实工具切换的方式。
理解检查
- 最终项目的 MVP 是什么？一句话说清核心闭环。
- 哪些能力必须做，哪些可以不做？你的裁剪依据是什么？
- 需要哪些工具？哪些必须真实调用，哪些用 mock 就可以？
- 需要哪些知识库资料？资料不足时怎么处理？
实践任务
背景：30 天的最终项目是「技术问题分析 Agent」。输入示例：开启 WAF 后 Nginx CPU 升高，请帮我分析可能原因，并给出验证步骤。Agent 需要理解问题、拆解分析路径、检索知识库、调用模拟日志与指标工具、输出 Markdown 报告、标注证据与假设与下一步，并用评估集测试。
- 第 1 步：用下面的项目定义骨架，写清楚 MVP 范围、核心链路、成功标准。
- 第 2 步：为「WAF 开启后 Nginx CPU 升高」写一条验收示例：输入、预期输出、通过条件。
- 第 3 步：写 10 条评估用例草案，至少覆盖 4 种场景：简单分析、缺失信息、工具失败、数据冲突。
- 第 4 步：列风险清单（至少 5 条）与对应缓解办法，再列知识库资料清单。
输出模板
项目名称：[技术问题分析 Agent]
一句话目标：[输入一个技术问题，输出一份带证据标注的 Markdown 分析报告]
MVP 范围
- 必须做：[最小闭环的每一步，如解析问题、检索、调工具、写报告]
- 可暂缓：[非核心能力，如多 Agent、长期记忆]
- 明确不做：[本次不做，如写回操作、自动修复]
核心链路
- 输入 -> 理解问题 -> 拆解分析路径 -> 检索知识库 -> 调用模拟工具 -> 输出报告 -> 评估
成功标准
- 输入示例：[...]
- 预期输出：[...]
- 通过条件：[...]
评估计划
- 用例数量：[n] 条
- 覆盖场景：[简单分析 / 缺失信息 / 工具失败 / 数据冲突]
- 指标：[报告准确率、证据标注完整率、编造率]
风险清单
- [风险] -> [缓解办法]
知识库资料清单
- [资料] -> [用途]
交付物
- [代码或伪实现、运行日志、评估结果、复盘说明]示范输出
项目名称：技术问题分析 Agent
一句话目标：输入一个技术问题，输出一份带证据标注的 Markdown 分析报告
MVP 范围
- 必须做：解析问题、拆解分析路径、检索知识库、调用 mock 日志与指标工具、输出报告、跑评估
- 可暂缓：多 Agent 协作、长期记忆、自动修复建议
- 明确不做：任何写回操作、真实生产数据访问
核心链路
- 输入 -> task_parser 理解问题 -> 拆解分析路径 -> retriever 检索知识库 -> tool_router 调 mock 工具 -> report_writer 输出报告 -> evaluator 评估
成功标准
- 输入示例：开启 WAF 后 Nginx CPU 升高，请帮我分析可能原因，并给出验证步骤
- 预期输出：Markdown 报告，含 3 条以上假设、每条假设的证据引用、验证步骤、待验证标注
- 通过条件：假设都有证据或待验证标注；验证步骤可执行；无编造数据
评估计划
- 用例数量：10 条
- 覆盖场景：简单分析、缺失信息、工具失败、数据冲突
- 指标：报告准确率、证据标注完整率、编造率
风险清单
- mock 数据与真实环境差异大 -> 用真实日志片段构造数据
- 知识库资料过少 -> 先收录 Nginx 与 WAF 的 10 篇内部文档
- 工具返回空数据 -> 报告中明确标注数据缺口
- LLM 编造指标 -> 强制只引用工具返回值
- 评估用例太少 -> 每天补 2 条真实案例
知识库资料清单
- Nginx 运维手册 -> 常见 CPU 升高原因
- WAF 配置文档 -> 规则与性能开销
- 历史故障复盘 -> 真实案例素材
交付物
- 6 个模块的伪实现、运行日志、10 条用例评估结果、复盘说明追问练习
- 需要哪些工具？mock 工具与真实工具如何切换才不会污染线上数据？
- 需要哪些知识库资料？资料不足时，Agent 应该继续还是停下来问人？
- 成功标准是什么？如何判断「分析得对」而不是「分析得顺」？
- 如果只剩 3 天时间，你会砍掉项目的哪一部分？
常见误区
- 一上来就想做「大而全」的全自动 Agent，范围失控。
- 成功标准写成「感觉好用」，没有可验证的输入、输出与通过条件。
- 评估用例只准备成功场景，没有缺失信息、工具失败、数据冲突用例。
- 没有 eval plan 就动手实现，改完代码也不知道是好是坏。
进阶扩展
- 上线监控：真实环境的失败率、延迟、成本都要有指标，MVP 阶段就要留好埋点。
- 离线评估流水线：每次改动先跑 eval 再上线，防止边改边退化。
- 影子模式：先在只读与 mock 数据上运行，验证稳定后再逐步开放真实工具。
今日作业
- 完成项目定义骨架：MVP 范围、核心链路、成功标准都要写全。
- 写 10 条评估用例草案，覆盖至少 4 种场景，每条写明输入与预期行为。
- 列风险清单（至少 5 条）与对应缓解办法。
- 列出你需要的知识库资料清单，并标注每份资料的用途。