发布时间：2026-07-11
标签：AI Agent｜LLM｜系统演化｜阶段总结｜工程实践

---

系列导航

上一篇：AI Agent 工程实践（08）：Workflow——什么时候应该拆成 Multi-Agent？
下一篇：AI Agent 工程实践（10）：Memory 不只是聊天记录——长期记忆架构设计

本文是 [AI Agent 工程实践] 系列的第 09 篇（第一季收官）。

---

写第 00 篇时，我只有一团模糊的想法：Agent 的能力不该靠"每次手教"。

写到现在第 09 篇，回头看，那团想法已经长出六块能独立运转的部件——Knowledge、Rules、Memory、Review、Workflow、Router，还自己闭合了一个反馈环。

最让我意外的是：这个结果不是我在第 00 篇"规划"出来的。每一块都是踩了坑、被现实逼出来后补上的。系统是演化出来的，不是设计出来的。

这一篇，把第一季收个尾：系统现在长什么样、九篇怎么咬合、下一步往哪走。

---

本文你将学到

✓ 第一季九篇之间的逻辑脉络与关系图
✓ 当前系统已有的六大组件各自解决什么
✓ v2 的未来路线图：Benchmark / Governance / State / Lifecycle / Metrics / Automation
✓ 为什么"演化"比"一步到位设计"更适合个人工程体系

适合阅读

✓ 追完了前 8 篇、想看全局地图的人
✓ 想给自己也搭一套 AI 工程体系的人
✓ 关心"个人系统怎么长期长起来"的人

---

问题背景

写第一季时，我是"边写边想清楚"的——第 01 篇讲分层，第 03 篇才意识到 Memory 是个独立问题，第 06 篇才发现 Knowledge 到 Rules 的演化缺口。每篇都是在填上一篇暴露的洞。

这带来一个副作用：读者一路追下来，可能只看到了"九篇文章"，没看到"一个系统"。各篇之间的呼应——比如 Review（04）驱动 Knowledge→Rules（06）的 Pattern 识别、Router（05）让 01 的分层真正运转——容易散落在不同文章里。

第一季写完，是时候做三件事：画一张关系图把九篇串起来、盘点当前系统、展望 v2 路线图。

---

关键观察：九篇关系图

先把你给的脉络画出来——这是整个系列的地基与骨架：

怎么读这张图：00-02 是基石（动机 + 分层 + 架构），03-09 是构建详解——每块子系统深挖、概念梳理、最后收官。分界线叫"第一阶段"，意味着后面还有。

七篇（03-09）之间如何咬合

03-09 这七篇不是平行罗列，是互相咬合的：

篇	解决什么	它和谁咬合
03 Memory	数据怎么记	给 08 的 Agent 提供状态底座
04 Review	怎么改进	驱动 06 的 Pattern 识别，验证 08 效果
05 Rule Router	规则怎么动态加载	让 01 的分层真正运转
06 Knowledge→Rules	知识怎么变规则	打通 02 的 Knowledge↔Rules 箭头
07 Skills vs Prompt	概念边界	定义 05/08 里的 Skill 术语
08 Workflow/Multi-Agent	怎么组装	把 Skill/Rule/Memory 组装成执行
09 本篇	收束 + 展望	以上全部

一句话串起来：06 把知识喂进规则（02 的缺口），05 让规则按需加载（01 的落地），07 澄清里面 Skill 是什么（05/08 的零件），08 决定怎么组装执行，03 兜底状态，04 全程驱动改进。Review 是黏合剂——它既验证 08 的效果，又通过 Pattern 触发 06 的演化。

---

最终方案：当前系统盘点 + v2 路线图

当前已有的六大组件

第一季把系统从"一团想法"搭成六个能独立运转的部件：

# AI Engineering OS v1 — 当前能力清单
components:
  knowledge: "02/06 · 知识库 + 演化成规则的链路"
  rules:     "01/05 · core/heavy 分层 + Router 动态调度"
  memory:    "03 · 四层记忆 + 生命周期"
  review:    "04 · 日/周复盘反馈闭环"
  workflow:  "07/08 · Skill 编排 + 单 Agent 优先"
  router:    "05 · 任务→规则 的自动路由"

六块之间的关系，已经闭合成环：

注意看虚线：Review 从 Project 回流到 Rules 和 Knowledge——这正是 02 篇说的"反馈闭环"。第一季的核心成就，就是让这个环真正转起来。

v2 未来路线图

第一季是"手工 + 半自动"：Review 靠人（04 篇坦诚过），Router 规则写死（05 篇），演化靠周复盘手动抽（06 篇）。v2 要解决的是把半自动变成自动、把隐性变显性：

未来方向	它解决什么	对应现在哪块的升级
Benchmark	量化 Agent 输出质量，不再"凭感觉好不好"	给 Review（04）装上客观尺子
Governance	规则/技能的准入、版本、权限管理	给 Rules（01）+ Skills（07）加治理
State	跨会话、跨任务的标准化状态机	强化 Memory（03）的结构化
Lifecycle	组件从生到死的统一管理	强化 Review（04）+ 06 的双向演化
Metrics	系统健康度可观测（延迟/成本/质量）	给整个 OS 装仪表盘
Automation	把半自动 Review/演化变成自动	升级 04/05/06 的人工环节

六个方向不是新造轮子，是把第一季"手工做得对的事"变成"系统自动做"。比如 Benchmark 不是新概念，是给 04 的 Review 装上客观标准；Automation 不是颠覆，是让 04/06 的人工环节自己跑。

实际收益

维度	第一季（v1）	v2 目标
Review	半自动（靠人）	自动复盘 + Benchmark 量化
规则演化	周复盘手动抽	自动识别 Pattern 并提议
可观测性	基本没有	Metrics 仪表盘
治理	个人随意	Governance 准入/版本

第一季的价值是"把对的架构立起来"，v2 的价值是"让它自己跑起来"。

---

架构图 / 流程图

v1 → v2 的扩展

读图：v2 不是推翻 v1，是在 v1 的每个薄弱点上"贴"一层自动化/治理能力。v1 是骨架，v2 是让它有血有肉、能自运转。

---

代码或配置示例

v2 系统清单（声明式）

用一份配置表达"现在有什么、将来要什么"，让演化可见、可追踪：

# ai-engineering-os.yaml
version: 2
current:                      # 第一季已建成
  - knowledge
  - rules
  - memory
  - review
  - workflow
  - router
roadmap:                      # 第二季规划
  benchmark:   { upgrades: review,      status: planned }
  governance:  { upgrades: rules,       status: planned }
  state:       { upgrades: memory,      status: planned }
  lifecycle:   { upgrades: review,      status: planned }
  metrics:     { upgrades: [all],       status: planned }
  automation:  { upgrades: [review,06], status: planned }

roadmap 每一项都 upgrades 某个已有组件——再次印证：v2 是升级，不是重写。

---

设计权衡

候选方案	优点	缺点	为什么不选（现在）
现在就做 v2 全套	一步到位	第一季架构还没验证，容易过度设计	自己打脸第 08 篇"先跑通再升级"
只做第一季不演化	简单	系统长不大	背离"演化"本身
先夯实 v1，按 roadmap 渐进	验证充分、成本可控	当前靠手工	选择理由：和全文"演化"哲学一致——先让对的跑起来，再让对的自动跑

别在第二季翻车。 第一季的核心教训（08 篇讲的"反过度工程"）对 v2 同样适用：Benchmark/Automation 这些听起来高级，但只有 v1 真的跑顺了，它们才是解药；v1 还没验证就去搞 v2，就是把第一季的坑放大成第二季的坑。

---

总结

✅ 系统不是设计出来的，是演化出来的——00 的想法靠 03-09 逐篇补齐才长成。
✅ 九篇关系：00-02 基石，03-09 构建详解；Review（04）是黏合剂，驱动 06 演化、验证 08 效果。
✅ 当前系统六大组件已闭合反馈环：Knowledge→Rules→Router→Agent→Project→Review→回流。
✅ v2 不是重写，是给 v1 每个薄弱点"贴"上自动化/治理（Benchmark/Governance/State/Lifecycle/Metrics/Automation）。
✅ 演化哲学贯穿始终：先让对的跑起来（v1），再让对的自动跑（v2）。

---

参考资料（第一季回链）

• 第 00 篇：为什么我要构建 AI Engineering OS → 动机起点，一切的开头
• 第 01 篇：AI Engineering OS 整体架构设计 → 五层架构与反馈闭环的定义
• 第 02 篇：为什么 Rules 要分层 → core/heavy 分层，Rules 的底座
• 第 03 篇：Memory 设计→ 四层记忆与生命周期
• 第 04 篇：Review——为什么必须每天复盘→ 反馈闭环的黏合剂
• 第 05 篇：Rule Router → 规则的动态调度，让分层运转
• 第 06 篇：Knowledge 如何演化成 Rules → 知识到规则的演化链路
• 第 07 篇：Skills vs Prompt → 概念辨析，定义 Skill 等术语
• 第 08 篇：Workflow / Multi-Agent → 组装方式，反过度工程

---

系列导航

上一篇：AI Agent 工程实践（08）：Workflow——什么时候应该拆成 Multi-Agent？
下一篇：AI Agent 工程实践（10）：Memory 不只是聊天记录——长期记忆架构设计

本文是 [AI Agent 工程实践] 系列的第 09 篇（第一季收官）。