发布时间2026-08-12标签AI Agent工程实践架构设计AI Engineering OS系列AI Agent 工程实践上一篇第 34 篇《企业 AI Agent 架构》下一篇第 36 篇《不要再写 Agent 教程——先定义一个真实问题》三年前我开始做 Agent 的时候最困惑我的不是模型能力不够。而是我明明今天调好了一个 Agent明天换个任务它又不行了这个项目里总结的经验换到下一个项目全要重来。我像是一个每天都在从零搭积木的工程师——每搭完一座下一座又从第一块开始。35 篇之前我讲了很多零件Knowledge、Rules、Runtime、Memory、Review、Provider、Tools。它们单个都能跑但一直没有一根主线把它们串成一个整体。直到我意识到我缺的不是更多零件而是一套操作系统——让这些零件自己运转、自己进化。于是有了今天这篇收官AI Engineering OS 的最终架构。一、开场从 00 到 35我们搭了什么回到第 00 篇的提问为什么我要构建 AI Engineering OS当时说工具在疯狂进化但怎么工程化管理 Agent、让它持续变好没人系统讲。35 篇走完现在我们可以给出答案的全貌——一套把知识、规则、运行时、记忆、复盘、供给、工具串成一个自进化闭环的操作系统式框架。这条路不是线性的它分成了四个清晰的阶段每一阶段都解决上一阶段暴露的问题阶段篇目范围解决什么留下的问题第一阶段理念与架构00–09为什么需要 OS、五层架构长什么样只有骨架没有血肉第二阶段基础组件02–06、10、15Rules/Memory/Knowledge/Review 怎么组织组件齐全但怎么跑起来第三阶段Agent Runtime07–08、11–14、16–19Planner/Context/State/Tool 怎么运行能跑但怎么上生产第四阶段企业级工程化21–35Provider/Memory/Logging/Observability/部署监控零件齐了缺一根主线第五阶段实战项目36–50预告把理论落成完整项目——上篇34画了企业架构这篇把它收进 AI Engineering OS做第四阶段收官。第五阶段起我们将拿一个真实问题仓库诊断 Agent把这套 OS 从头到尾走一遍。二、问题背景散点知识 vs 操作系统式框架学完前三阶段组件和第四阶段工程化你手里有一堆零件Knowledge、Rules、Runtime、Memory、Review、Provider、Tools。但它们之间的关系、谁驱动谁进化需要一根主线串起来——否则只是又会了七个概念。这个困境我相信每一个认真学完组件的人都经历过。它的具体症状有三条症状一知识是死的不会流动。你整理了一堆领域知识放进了 Knowledge 库但它们只是躺在那里。今天 Agent 答错了一个问题这个教训不会自动回流到知识库里——你只能靠人肉去改。症状二规则是静态的不会进化。你精心设计了一套 Rules但它们不会因为运行结果而变好。Agent 在这个项目里踩过的坑下个项目完全不记得。症状三组件之间没有共识。Memory 记它的Review 复盘它的Runtime 跑它的——三者之间没有一条自动的管道把运行经验传回规则和知识。这三个症状指向同一个本质你搭的不是一个系统而是一堆零件的集合。零件再多不会自己动就不是系统。AI Engineering OS 就是来解决这个本质问题的把 Agent 从一次写好的程序升级成会持续自我改进的系统。我见过太多人停在零件集合这一步——因为他们以为把组件用起来就是终点了。但真正的分水岭在于你的 Agent 会不会从自己的运行中变强会才是 OS不会就是框架用法。三、关键观察七支柱 一个反馈闭环整个 OS 由 7 大支柱构成并由一条Review → 改进的闭环驱动进化Knowledge ──┐ Rules ──┼─→ Runtime ─→ Memory ─→ Provider ─→ Tools Review ──┘ ↑ │ └──────────────────┴──── 反馈改进 ──────────┘下面逐个展开讲清每一支柱是什么、为什么需要、在系列哪篇论证过支柱 1Knowledge知识—— Agent 的课本企业/领域知识源RAG 的输入。它是 Agent 回答问题的依据没有它Agent 只能靠模型自己的常识——而常识在垂直领域里几乎必然不够用。设计要点Knowledge 不是一堆文档而是有治理的知识——有分层、有版本、有质量评估呼应第 15 篇RAG 真正的瓶颈不是检索而是知识治理。一段脏知识进库比没有知识更糟因为它会让 Agent 自信地错。支柱 2Rules规则—— Agent 的纪律可执行的约束分层加载。核心价值在第 02 篇论证过规则必须分层core 常驻 / heavy 按需否则上下文会被规则淹没。Rules 是 Agent 的行为底线也是后面Review 反馈闭环的主要落点之一——复盘发现的错误模式最终会沉淀成一条新规则。支柱 3Runtime运行时—— Agent 的中枢编排中枢把 Knowledge、Rules、Memory、Provider、Tools 对齐成一次执行。它对应第 22 篇的项目分层和第 34 篇的企业架构里的编排层。Runtime 是七支柱里最重的一根——它决定了任务怎么被拆、状态怎么流转、工具怎么调度。支柱 4Memory记忆—— Agent 的经验用户与会话的长期记忆。它分两层短期会话内状态和长期跨会话的用户画像、历史结论。设计要点在第 03、10 篇展开过Memory 不属于 Agent应独立成服务——因为记忆要跨会话存活不能被 Agent 的一次运行带走。支柱 5Review复盘—— Agent 的进化引擎每天/每轮回顾把失败与新模式沉淀回 Knowledge/Rules。这是整个 OS 最关键的支柱呼应第 04 篇为什么 AI Agent 必须每天复盘。没有 Review七支柱就只是一个静态架构图有 Review它才变成活系统。支柱 6Provider供给—— Agent 的引擎舱模型抽象层让 LLM 可替换呼应第 23 篇。为什么必须抽象因为换模型在 Agent 时代是常态操作——今天 DeepSeek 便宜、明天新模型更强。如果没有 Provider 层每次换模型都要改业务代码有了它换模型只是改一行配置。支柱 7Tools工具—— Agent 的手脚外部能力注册表统一调度呼应第 24 篇。工具不是散落的函数而是Tool → Registry → Permission → Schema → Executor的统一管理。工具系统决定了 Agent 能碰到世界的哪些部分。闭环是灵魂闭环是灵魂Runtime 跑出的结果和经验经 Review 提炼反哺 Knowledge 和 Rules——系统越用越聪明而不是越用越乱。这正是Engineering OS区别于又一个 Agent 框架的地方。为了说清楚这个闭环的价值我讲一个没有闭环时的真实场景你的客服 Agent 今天答错了一个问题把退款时效说成了7 个工作日实际是 3 个。如果没有 Review 闭环这个错误会永远存在——每次有人问退款时效它都错。但如果有闭环晚上 Review 跑一遍今天的对话发现这个错误把它提炼成一条规则退款时效为 3 个工作日紧急单 1 个工作日写回 Rules。明天Agent 就再也不会答错。这就是越用越聪明。四、最终方案OS 总架构4.1 总架构图Mermaid对比第 01 篇的五层架构Knowledge→Rules→Agent→Project→Review这里用第四阶段的工程化语言重述Agent 层 Runtime Memory Provider ToolsProject 层 一次具体业务编排Review 仍是闭环的发动机。4.2 第二张图一次任务在 OS 里的完整旅程ASCII 图发布提示此图可用 draw.io / ProcessOn 重画成正式架构图与上方 Mermaid 图形成图 1 图 2的发布配图组合。用户提问 │ ▼ ┌─────────────┐ 加载 ┌─────────────┐ │ Runtime │ ──────────→ │ Rules │ 行为约束 │ 编排中枢 │ └─────────────┘ └──────┬──────┘ │ 检索 ▼ ┌─────────────┐ ┌─────────────┐ │ Knowledge │ │ Memory │ │ 知识源 │ │ 长期记忆 │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ 调用 ┌─────────────┐ │ Provider │ ──────────→ │ LLM │ │ 模型抽象 │ └─────────────┘ └──────┬──────┘ │ 需要工具 ▼ ┌─────────────┐ 执行 ┌─────────────┐ │ Tools │ ──────────→ │ 外部系统 │ │ 工具注册表│ └─────────────┘ └──────┬──────┘ │ 运行结果 经验 ▼ ┌─────────────┐ 提炼 ┌─────────────┐ │ Review │ ──────────→ │ Knowledge/ │ │ 每日复盘 │ │ Rules 更新 │ └─────────────┘ └─────────────┘这张图的关键是最后一条回旋箭头——从 Review 回到 Knowledge/Rules。没有这条回旋图就是一个单向数据流有了它才是自进化闭环。五、代码与配置示例5.1 最小可运行骨架目录ai_os/ ├── knowledge/ # 知识源 检索 ├── rules/ # 分层规则 core/heavy ├── runtime/ # 编排中枢 ├── memory/ # 记忆服务 ├── provider/ # 模型抽象层 ├── tools/ # 工具注册表 ├── review/ # 复盘与沉淀 └── config.yaml # 全局配置5.2 配置串起七支柱knowledge: { source: enterprise_wiki, top_k: 5 } rules: { core: always, heavy: on_demand } runtime: { max_steps: 12 } memory: { backend: redis, ttl: 30d } provider: { default: deepseek, fallback: openai } tools: { registry: enabled } review: { cadence: daily }5.3 闭环的核心实现Review 如何反哺 Rules很多人问闭环到底在代码里长什么样这里给一个最小可运行的示例——每天复盘时扫描 Agent 的错误提炼成规则写回规则库# ai_os/review/engine.py —— 闭环的核心失败 → 提炼 → 沉淀 import yaml def run_daily_review(logs: list[dict], rules_path: str) - int: 扫描今日 Agent 日志找出错误模式沉淀为规则 failures [log for log in logs if log[verdict] wrong] new_rules [] for fail in failures: # 1. 定位错误模式简化关键词匹配 pattern extract_error_pattern(fail[query], fail[answer]) if not pattern: continue # 2. 去重已有规则就不重复沉淀 if pattern in load_rules(rules_path): continue # 3. 沉淀为一条 heavy 规则 new_rules.append({rule: pattern, source: review, created: today()}) if new_rules: append_rules(rules_path, new_rules) # 写回规则库 return len(new_rules) # 使用每天定时跑一次 def cron_daily(): logs load_yesterday_logs() # 读昨天的执行日志 added run_daily_review(logs, rules/heavy.yaml) logger.info(f今日复盘沉淀 {added} 条新规则)这段代码就是越用越聪明的最朴素实现错误不删除而是被转化为规则永久留在系统里。你的 Agent 明天遇到同样问题Rules 层会直接约束它不再重蹈覆辙。六、设计权衡为什么是OS而不是又一个框架维度普通 Agent 框架AI Engineering OS关注点怎么调用模型/工具怎么让系统持续变好知识管理散落 promptKnowledge 治理 演化进化机制无/手动Review 闭环自动沉淀差异化套用模板业务规则与记忆是资产判断标准如果你的 Agent 写完就定型、改一次靠人肉那是框架用法如果它每天从运行中学到东西、自动改进规则与知识那才是Engineering OS。但这里有一条必须诚实的边界——不是所有项目都需要 OS场景用框架就够了需要 OS任务规模一次性、线性、固定流程多轮、多任务、长期演进知识量少量静态 prompt大量领域知识、需持续更新演进需求写完不改需要从运行中学习团队规模个人实验团队/企业级资产沉淀判断公式如果你的 Agent 每天产生新的失败、新的知识、新的规则而你又没有一条自动管道把这些沉淀回去那你就已经在需要 OS的区间了。反过来说如果你只是搭一个 demo 跑一次硬套 OS 七支柱就是过度工程——这也正是第 36 篇要讲的先选对问题。七、常见误区FAQQ1AI Engineering OS 是不是就要搭一个很大的系统不是。OS 的核心是闭环这个机制不是组件数量。最小形态可以是一个 Runtime 一个 Review 脚本 一个规则文件。组件可以少闭环不能没有。Q2Review 是必须每天跑吗按你的数据量来。任务量大的每天小项目每周也行。关键是定期不是实时——复盘是批处理不需要介入每一次运行。Q3Rules 会不会越积越多最后又变成上下文灾难会这正是 Rules 必须分层的理由呼应第 02 篇。沉淀的规则进 heavy按需加载只有最核心的进 core常驻。另外Review 里应该有一道规则清理长期没触发、或已被新规则覆盖的旧规则标记淘汰。Q4这个 OS 和 LangGraph / 其他框架冲突吗不冲突。LangGraph 解决运行时编排这一层Runtime 支柱可以用它实现AI Engineering OS 是更高一层的系统架构——它定义组件之间的关系和进化机制不绑定具体实现。八、总结✅ 35 篇走完AI Engineering OS 七支柱Knowledge/Rules/Runtime/Memory/Review/Provider/Tools 一个 Review 驱动的反馈闭环。✅ 闭环是灵魂Runtime 经验经 Review 反哺 Knowledge/Rules系统越用越聪明。✅ 它区别于又一个框架核心是持续自我改进不是怎么调模型。✅ 最小形态一个 Runtime 一个 Review 脚本 一个规则文件机制比数量重要。✅ 呼应全系列Runtime(22/34)、Review(04)、Provider(23)、Tools(24)、Knowledge(06/15)、Rules(02)、Memory(03/10)。系列第四阶段21–35至此完结。从Demo 永远变不成生产到我的 AI Engineering OS 最终架构我们一起把零件拼成了能上线、能监控、能进化的企业 Agent 系统。下一步第五阶段「企业级实战项目」将拿一个真实问题仓库诊断 Agent Repo Doctor把这套 OS 从头到尾走一遍选问题、拆需求、画架构、做 MVP、踩失败、建评估、上生产。参考资料带用途说明本系列01整体架构设计本文七支柱是对01五层架构的工程化重述。本系列04Review——为什么必须每天复盘闭环发动机的来源。本系列02Rules 分层 /03Memory 设计 /06Knowledge 演化三根支柱的原始论证。本系列23Provider /24Tool Registry /22分层Runtime 调用的下游组件。本系列34企业 AI Agent 架构本文 OS 总图是34企业图的操作系统式收口。系列导航上一篇第 34 篇《企业 AI Agent 架构》下一篇第 36 篇《不要再写 Agent 教程——先定义一个真实问题》本文是 [AI Agent 工程实践] 系列的第 35 篇第四阶段第十五篇阶段收官。