★ FEATURED ARTICLE 系列导航上一篇AI Agent 工程实践48什么时候应该 Multi-Agent-CSDN博客下一篇AI Agent 工程实践50最终项目——一个真正可运行的 Production Agent发布时间2026-09-28标签AI Agent工程实践优化V1 到 V2从第 39 篇那个 100 行的最小版到这一篇Repo Doctor 已经跌跌撞撞走了十篇。中间我修过幻觉、调过工具描述、建过评估集、挡过回归、锁过版本、做过模型实验、把 PR review 退回过 Workflow、给 bug 定位抽过 Reviewer。散落了一路的改动是时候收个账了。这一篇我把它们全部串起来做一次完整的 v1 → v2然后看看到底涨了多少。问题背景这是第五阶段的第十四篇也是整个阶段的高潮篇。前面十三篇每一篇都解决了一个具体问题但也都是散点——这篇修幻觉那篇调工具。这一篇要做的是把散点收拢成一条线把所有改动汇总成一次完整的 v1 → v2 升级用数据回答一个总问题——我们折腾了这么久到底有没有用这也是第五阶段的验收时刻。如果前面的方法论都是对的那么这一刻数字应该会说话。错误尝试改了很多但说不清改了什么我先坦白一个之前的毛病改了很多但说不清每处改动对应哪篇、带来了什么收益。幻觉问题改了、工具描述改了、加了 Reviewer、退了 Workflow……这些改动散落在代码、Prompt、Tool 定义里混在一起。当我被问v1 和 v2 到底差在哪时我只能含糊地说改进了很多地方。改进了很多地方——这是一句废话说得最像结论的样子。问题出在哪我没有在每次改动时记录改了哪一层、为什么、预期影响什么指标。这导致最后想复盘时只剩一团浆糊。关键观察v1 和 v2 之间隔的是决策不是代码量我把 v1 到 v2 的所有改动重新梳理成了一张因果账——每一处改动都对应着一篇、一个根因、一个预期收益改动来自哪篇解决的根因影响的指标加 Task Router38任务串味Success Rate加 Planner终点意识38、40无终点烧 TokenCost改 Tool 描述41Tool Selection ErrorTool Accuracy加验证节点拦截幻觉42Reasoning ErrorAnswer Accuracy建 eval 数据集43无法量化尺子回归门槛44隐蔽回归稳定性锁七维版本45无法复现可复现模型选型换 B46模型不匹配综合PR review 退 Workflow47自主性过度Cost、漏报抽 Reviewer 节点48职责冲突Answer Accuracy核心洞察v1 到 v2 之间隔着的不是代码量是你踩过的每一次失败和每一次验证。代码量其实没增加多少增加的是决策的密度——每一个改动都是一次失败 → 定位 → 归因 → 修复 → 验证的完整闭环。最终方案v1 → v2 完整对照架构对照v1第 39 篇的最小版v2当前多了 Task Router、Planner、Context Builder、Tool Registry、State、Reviewer、Evaluation——但注意这些不是拍脑袋加的组件而是前面每一篇的根因倒逼出来的。收益总表跑同一份 eval 数据集v1 和 v2 的全指标对比指标v1v2变化Success Rate55%85%30%Tool Accuracy60%88%28%Answer Accuracy48%82%34%Cost (avg tokens)42002900-31%Latency (avg s)9.8s6.9s-30%五个指标全面改善。尤其 Success Rate 从 55% 到 85%——这意味着原来有一半的任务是错的现在只有 15% 会错。而这张表最有价值的地方是每一个数字都能回溯到具体改动Success Rate 30%主要来自 Task Router10% Reviewer12% 工具描述优化8%Cost -31%主要来自 Planner 终点意识 PR review 退 Workflow。代码或配置示例v2 的总装是这一篇的收束——把散落的改动收进一个清晰的目录结构repo_doctor/ ├── agent.lock # 第45篇七维版本锁定 ├── nodes/ │ ├── task_router.py # 第38篇任务分流 │ ├── planner.py # 第38篇规划调查 │ ├── context_builder.py # 第42篇控制读什么防上下文爆炸 │ └── reviewer.py # 第48篇独立审查节点 ├── tools/ │ ├── registry.py # 第41篇统一管理工具描述 │ └── schemas.py # 第41篇工具参数约束 ├── eval/ │ ├── normal/ # 第43篇评估数据集 │ └── scorer.py # 第43篇打分器 ├── version/ │ └── check.py # 第45篇版本漂移校验 └── tasks/ └── pr_review.py # 第47篇退回的固定 Workflow每一个目录都能说出它来自哪一篇、解决了什么问题。这就是工程和堆代码的区别。设计权衡候选方案优点缺点为什么不选一次大重构干净无法定位每处改动的收益回归风险极高一口吃不成胖子逐篇小步改复盘每步可验证、可回溯慢每次改动都能说清为什么这十篇走下来最深的一个体会是Agent 的优化从来不是一次性大改能完成的而是失败→修复→验证的小步快跑。大改看似高效实则让你失去对每一处改动的掌控最后连哪里改对了都说不清。总结✅ v1→v2 的所有改动都能回溯到具体的一篇、一个根因、一个预期收益。✅ 架构从 4 节点涨到 10 节点但每个节点都是根因倒逼出来的不是拍脑袋。✅ 收益总表Success Rate 55%→85%、Cost -31%、Latency -30%全面改善。✅ 铁律v1 到 v2 之间隔着的不是代码量是你踩过的每一次失败和每一次验证。✅ 下一篇给 v2 补上最后一层生产外壳收尾整个阶段。参考资料本系列第 39–48 篇 → 为什么引用本文是它们的汇总每处改动都能回溯到原篇。《Accelerate》中的小步快跑 vs 大爆炸 → 为什么引用小步改进优于大重构是这十篇方法论的理论支撑。系列导航上一篇AI Agent 工程实践48什么时候应该 Multi-Agent-CSDN博客下一篇AI Agent 工程实践50最终项目——一个真正可运行的 Production Agent本文是 [AI Agent 工程实践] 系列的第 49 篇。
阅读完成 · 觉得有帮助？
