AI Agent 工程实践（04）：Review——为什么 AI Agent 必须每天复盘？

发布时间2026-07-10标签AI AgentLLM反馈系统工程实践复盘机制系列导航上一篇AI Agent 工程实践03Memory 设计——Agent 到底应该记住什么下一篇AI Agent 工程实践05Rule Router——如何让 Agent 自动加载正确的规则本文是 [AI Agent 工程实践] 系列的第 04 篇。我的 Agent 用了半年代码越写越顺可有个怪现象同一个坑它会在不同项目里反复踩。A 项目里我纠正过别把配置硬编码进代码两周后 B 项目它又硬编码了一遍。我一度以为是它记性差——直到我发现问题根本不在记忆。它确实记得我说过的话只是那句话从来没变成过规则。纠正发生在对话里然后随对话一起消失了。没有任何机制把这次踩的坑沉淀回系统。于是我给整套系统加了最后一层也是我认为最关键的一层Review。本文你将学到✓ 为什么复盘不能是顺手做的事必须独立成层✓ Review 和日志的本质区别——一个是死的记录一个是活的反馈✓ 反馈闭环怎么跑通Project → Review → Knowledge → Rules → Agent✓ 为什么说 Review 是这套系统有资格叫 OS的原因适合阅读✓ 想让 Agent 越用越聪明、而不是原地打转的开发者✓ 用 Claude Code / Cursor / LangGraph 搭个人工程体系的人✓ 对系统如何自我改进这个话题感兴趣的人问题背景在 系列第 03 篇 里我讲了 Memory 怎么分层——那解决的是记忆该记什么、记多久。但 Memory 解决不了一个更根本的问题记住了不等于改进了。记忆是被动的存储。它能让 Agent想起你说过的话却不能让这句话变成下次自动遵守的约束。中间缺了一个环节把经验转化为规则的机制。这就是我遇到的怪现象的根源同一个坑反复踩。A 项目纠正过的问题B 项目重新出现。因为纠正只停留在对话层没有回流到规则层。改进不可积累。每次对话都是从头教一遍Agent 的能力曲线是平的——用了半年和用第一天差不多。问题找不到根因。出了错是知识错了规则错了还是 Agent 执行错了没有定期回看永远在救火从不防火。一句话概括没有 ReviewAgent 就是一个能力封顶的工具而不是一个会成长的系统。前三层Knowledge / Rules / Agent负责把事做出来但没有任何一层负责把事做得越来越好。错误尝试第一次尝试把复盘当成顺手做的事最初我没打算专门做复盘。想法很自然每次出问题我都会记一下攒着以后优化。结果一次都没优化过。因为顺手记意味着没有固定时间、没有固定格式、没有强制动作。忙起来就跳过跳过几次后就彻底忘了这回事。凡是有空再做的事最终都不会做。第二次尝试记详细日志指望日后回看那就正式一点——每天让 Agent 输出一份工作日志记录做了什么、遇到什么问题。文件攒了一大堆。结果日志确实全但它是只写不读的。我几乎从不回头翻翻了也不知道该干嘛——日志只告诉我发生了什么没告诉我该改什么。它是一份死的记录不是一个活的动作。两次尝试指向同一个教训复盘的价值不在记录而在记录之后触发的改进动作。没有闭环的记录等于没记。关键观察我对比了有日志和有复盘两种状态下一个问题的完整生命周期环节只有日志有 Review 闭环问题发生记进日志记进日志事后回看几乎不看定期强制回看归因无定位到 Knowledge/Rules/Agent 某层转化无写成新规则 / 更新知识下次表现大概率重犯已被规则拦住pie title 日志 vs Review 的本质差异 记录写下来就结束 : 30 回看 归因 转化真正产生改进 : 70日志是发生了什么Review 是该改什么。前者是数据的终点后者是改进的起点。一字之差一个是死的一个是活的。定位真正原因问题不在没记录而在记录之后没有任何机制强制触发改进。日志是只写不读的单向流而 Review 是读—归因—回写的闭环流。真正让系统进化的是那条从 Project 回流到 Rules 的反向箭头——而这条箭头前三层里没有任何一层负责。所以它必须独立成层。理由很简单凡是顺便做的事都不会被做凡是没有专属位置的动作都会被省略。把 Review 独立出来就是用架构强制它发生——它不是可选的装饰是系统的一部分。最终方案Review 作为独立的反馈层前四层Knowledge → Rules → Agent → Project的数据是自上而下流动的知识产出规则、规则约束 Agent、Agent 交付项目。Review 干的是反过来的事——它从最末端的 Project 出发把经验逆流回灌到最上游Project交付物里暴露的问题 ↓ Review 定期扫描、归因 Knowledge把新事实/坑记成笔记 ↓ Rules把笔记转化为新约束 ↓ Agent下次自动遵守不再重犯这条反向箭头才是 Review 的本质它让系统从一堆工具的堆叠变成能自我改进的有机体。Review 不是日志是反馈系统这是全篇最想说清的一点用一张表对齐维度日志LogReview反馈系统方向单向只写闭环写 → 读 → 回写目的记录发生了什么决定该改什么触发被动累积主动定期扫描产出一堆文件新规则 / 知识更新对系统的影响无不读就等于没有让系统下一轮变强一句话日志是 Review 的输入不是 Review 本身。只做到日志就停在了半路。两级节奏Daily 抓具体Weekly 抓模式Daily Review日复盘抓具体问题。今天哪次输出被我手动改了改了什么记下来。Weekly Review周复盘抓重复模式。这周的日复盘里有没有同一类问题出现≥2 次有 → 说明该沉淀成规则了。日复盘负责采集信号周复盘负责从信号里发现该改的规则。单靠日复盘会陷在细节里单靠周复盘会漏掉现场。实际收益指标只有日志有 Review 闭环同类问题重犯率高换项目又踩显著下降已成规则拦截规则新增来源拍脑袋来自真实踩坑有据可依Agent 能力曲线平用半年用一天向上每周都在补漏洞问题归因靠回忆定位到具体层数据为主观经验估算非严格 A/B Test但反映了加入闭环前后的量级差异。架构图 / 流程图反馈闭环数据向下经验向上实线是正向数据流自上而下虚线是 Review 的反馈流自下而上。正是这条虚线让系统闭环。一个问题的闭环之旅stateDiagram-v2 [*] -- 发生: Agent 在 Project 里犯错 发生 -- 采集: Daily Review 记下现场 采集 -- 识别: Weekly Review 发现同类≥2次 识别 -- 归因: 定位到 Knowledge/Rules 某层 归因 -- 回写: 写成新规则 / 更新知识 回写 -- 拦截: 下次 Agent 自动遵守 拦截 -- [*]: 同类问题不再发生图片多样性这里用 Mermaid 的 pie / flowchart / stateDiagram 三种发文时可再补一张 ProcessOn/draw.io 版的闭环示意图提升 CSDN 图片多样性得分。代码或配置示例复盘的目录结构project/.agent/memory/ ├── 2026-07-09.md # Daily Review当天的具体问题现场 ├── 2026-07-10.md ├── weekly/ │ └── 2026-W28.md # Weekly Review本周模式识别 待沉淀规则 └── MEMORY.md # 沉淀后的长期结论回写 Rules 前的中转Daily Review 模板结构化不是流水账日复盘的关键是结构化——每条都要能指向该改什么而不是记今天干了啥# 2026-07-10 Daily Review 被手动修正的输出 现象Agent 把数据库密码硬编码进了 config.py 我的修正改用环境变量读取 疑似归因Rules 层缺敏感信息禁止硬编码约束 值得记住的新事实 FastAPI 的 BackgroundTasks 不适合长任务 → 应进 Knowledge 待观察暂不成规则 生成的注释偏啰嗦先记一笔看是否重复出现复盘 → 规则的转化逻辑伪代码Review 的核心不是记是这段从日志到规则的转化def weekly_review(daily_logs: list[DailyLog]) - list[Rule]: 周复盘从日复盘里提炼出该沉淀的规则 # 1. 聚合本周所有被修正的问题 issues [i for log in daily_logs for i in log.corrections] # 2. 找出重复出现的模式同类 gt; 2 次才值得成规则 patterns group_by_root_cause(issues) recurring [p for p in patterns if p.count gt; 2] new_rules [] for p in recurring: # 3. 归因到具体层 if p.layer knowledge: knowledge.append(p.to_note()) # 缺事实 → 补知识 elif p.layer rules: new_rules.append(p.to_rule()) # 缺约束 → 写规则 return new_rules # 回写 Rules 层下轮 Agent 自动加载代码不多但点出了 Review 区别于日志的唯一动作group_by_root_cause 回写。没有这一步攒再多日志也只是死数据。设计权衡候选方案优点缺点为什么不选不做复盘零成本同一个坑无限重犯能力封顶Agent 永远长不大只记日志记录全只写不读不产生改进停在半路日志死数据复盘塞进 Agent 层顺便做不用新增结构顺便不会做且归因不清没有专属位置的动作会被省略Review 独立成反馈层强制闭环、归因清晰、经验回流需要纪律 定期投入选择理由唯一能让系统自我改进的方案Review 不是银弹它要付出纪律成本。如果你的 Agent 只是跑一次性任务、不需要长期积累那确实不用复盘。但凡是想越用越强的系统这一层就省不掉。坦诚一点我的 Review 目前还是半自动的——采集靠 Agent归因和回写很大程度靠人。但我认为架构里留好这个位置比自动化程度更重要。自动化可以慢慢迭代架构缺了一层推倒重来的成本极高。总结✅ Memory 让 Agent记得住Review 让 Agent改得动——记住 ≠ 改进。✅ 日志是发生了什么Review 是该改什么前者只写后者是写→读→回写的闭环。✅ Review 必须独立成层因为顺便做的事都不会被做——用架构强制它发生。✅ 闭环的关键是那条反向箭头Project → Review → Knowledge → Rules → Agent。✅ 这条反馈流是整套系统有资格叫 OS的原因没有它只是一堆工具的堆叠。参考资料PDCA 循环戴明环→ Plan-Do-Check-ActReview 层检查→改进闭环的方法论原型Site Reliability Engineering — Postmortem 文化Google→ 无指责复盘 转化为改进项直接启发了本文的归因→回写设计Generative Agents (Park et al., 2023)→ Agent 的反思reflection机制把观察提炼为高层洞察是自动化 Review 的参照The Fifth Discipline (Peter Senge)→ 学习型组织与反馈回路思想Review 让系统具备自我改进能力的理论来源系列导航上一篇AI Agent 工程实践03Memory 设计——Agent 到底应该记住什么下一篇AI Agent 工程实践05Rule Router——如何让 Agent 自动加载正确的规则本文是 [AI Agent 工程实践] 系列的第 04 篇。