Day 25 - Continuous Improvement and Feedback Loops

今日目标

能设计轨迹日志与反馈沉淀流程，让 Agent 从运行轨迹中持续进化。

学习安排

核心概念

阅读重点

围绕三个问题读第 8 章：进化发生在哪些层面、轨迹怎么用、反馈怎么防污染。

• 对应章节：第 8 章「Agent 的持续进化」，重点读从运行轨迹获得学习信号，更新知识、指令、程序与参数。
• 关注点 1：进化发生在四个层面——知识、指令、程序、参数，按成本从低到高排序。
• 关注点 2：轨迹是进化的原材料——没有轨迹就没有改进依据，最终答案只是轨迹的一小部分。
• 关注点 3：用户反馈如何变成结构化改进项——收集、分类、去重、验证、落地，每一步都要有人负责。
• 关注点 4：反馈不等于事实——用户可能误判，反馈必须经过验证才能进入知识库，防止反馈污染。
• 补充材料：Agent 记忆与持续改进的官方文档与实践。
• 补充材料：eval 驱动迭代的工程实践博文，介绍改进后的回归流程。

理解检查

先不看笔记回答下面 4 个问题，卡住的写下来。

• Agent 的「进化」可以发生在哪些层面？按成本从低到高排序。
• 为什么运行轨迹很重要？没有轨迹时改进靠什么？
• 用户反馈如何转化为改进项？一条差评到一次改动的完整路径是什么？
• 如何避免错误反馈污染系统？哪些反馈必须验证才能吸收？

实践任务

背景：你的测试报告 Agent 已经上线运行，今天为它设计「运行日志 + 反馈闭环」，让它越用越好。

步骤：

• 步骤 1：列出日志必须回答的问题——这个任务是什么、做了什么、哪里出错、用户怎么评价。
• 步骤 2：按字段设计 yaml 结构——task_id、user_goal、steps、tool_calls、intermediate_errors、final_answer、user_feedback、human_correction、lessons_learned。
• 步骤 3：补充 2 个字段——eval_score（自动评分）与 updated_at（时间戳），方便筛选和追溯。
• 步骤 4：设计闭环流程——谁收集反馈、谁分类、谁验证、改哪里（知识库 / 指令 / 代码 / 参数）。
• 步骤 5：写一条「人工纠正 -> 沉淀为规则」的示例路径，走通一遍再定流程。

产出：日志结构 yaml 与一条反馈闭环流程图（文字版）。

闭环流程示例（文字版）：

运行 -> 记录轨迹日志 -> 人工打分与用户反馈 -> 分类问题 -> 验证反馈真伪
  -> 沉淀 lessons_learned -> 更新知识库或指令 -> 跑 eval 回归 -> 再运行

验收提示：闭环里每一环都要有人或程序负责，写不出负责人的一环就是会断掉的一环。

输出模板

先按模板填空，再替换成你的真实任务。字段顺序固定，可自行增加字段。

task_id: [T-YYYYMMDD-序号]
user_goal: [用户原始目标]
steps: [执行步骤摘要]
tool_calls:
  - tool: [工具名]
    args: [参数摘要]
    result: [结果摘要]
    error: [错误信息，可为空]
intermediate_errors: [中间错误记录]
final_answer: [最终输出摘要]
user_feedback: [满意 / 不满意 / 原因]
human_correction: [人工纠正内容，可为空]
lessons_learned: [本次沉淀的经验，可为空]
eval_score: [自动评分，可为空]
updated_at: [时间戳]

示范输出

以下是一条已填好的日志，场景是接口 P95 分析任务，可以看到「纠正 -> 经验」的沉淀过程。

task_id: T-20260814-008
user_goal: 分析接口 /api/order/list 的 P95 从 200ms 升到 800ms 的原因
steps:
  - 解析任务，确认时间窗口
  - 调用 query_metrics 查询 P95 指标
  - 调用 query_logs 查询异常时段日志
  - 调用 query_deploy_history 检查发布记录
  - 生成结论并标注已验证与待验证
tool_calls:
  - tool: query_metrics
    args: metric=P95, start=14:00, end=15:00
    result: P95 在 14:30 后从 200ms 升至 800ms
    error: null
  - tool: query_deploy_history
    args: start=14:00, end=15:00
    result: 14:31 有一次配置变更
    error: null
intermediate_errors:
  - query_logs 首次调用超时，重试后成功
final_answer: 结论：P95 升高与 14:31 配置变更时间重合，待验证项：回滚后观察
user_feedback: 满意，但希望结论附上日志证据片段
human_correction: 把「高度相关」改为「与配置变更时间重合，需回滚验证」
lessons_learned: 涉及发布变更的结论，必须先查部署历史再下结论
eval_score: 4.5
updated_at: 2026-08-14T16:00:00+08:00

追问练习

下面的问题比理解检查深一层，建议边想边写。

• 哪些改进应该进入 Prompt，哪些进入代码，哪些进入知识库？判断依据是什么？
• 一条人工纠正过的轨迹，什么信号说明该把它沉淀成规则而不是只改一次？
• 反馈闭环里最容易断掉的一环是什么？如何保证它不断？
• 日志里哪些字段涉及隐私或安全，生产环境里应该怎么处理？

常见误区

• 只记最终答案不记轨迹：出了问题无从定位，改进没有原材料。
• 所有反馈照单全收：用户误操作、错误判断也被当成规律吸收，造成反馈污染。
• 改了知识或指令不做回归：旧场景悄悄退化，等用户发现已经晚了。
• 反馈收集了没人处理：闭环断在「分析」这一环，日志变成了死数据。

进阶扩展

• 生产级日志还要考虑隐私与审计：哪些字段不能记录，谁可以查看轨迹。
• 改进项要排优先级：频率 x 影响 x 成本，而不是谁反馈得多先改谁。
• 高质量轨迹是未来微调与 RL 的原料，日志设计从一开始就要为复用留好结构。

今日作业

• 完成日志结构 yaml，并填 2 条真实的示例日志。
• 用文字画出反馈闭环流程：谁收集、谁分类、谁验证、改哪里。
• 定下例行动作：每天检查哪些日志字段、多久沉淀一次 lessons_learned。
• 写一条防反馈污染的规则，例如「用户反馈必须经过复核才能进入知识库」。

自检清单

• 我能设计一份包含完整字段的轨迹日志结构。
• 我能说清进化可以发生在知识、指令、程序、参数四个层面。
• 我能把用户反馈转化为可执行的改进项。
• 我能识别并防止反馈污染。
• 我能说清为什么每次改进后都要跑 eval 回归。