系列导航上一篇AI Agent 工程实践00为什么我要构建 AI Engineering OS本文是AI Agent 工程实践系列的第 01 篇。1发布时间2026-07-08标签AI AgentLLM架构设计工程实践知识管理为什么很多 AI Agent 项目越做越乱我用了一年、踩了半年坑最终把整个系统拆成五层Knowledge → Rules → Agent → Project → Review这篇讲清楚为什么一定这样分、而不是别的方式。读完后你会明白你遇到的问题90% 都能用它解决。本文你将学到✓ 为什么 AI Agent 需要分层架构✓ 五层分别负责什么、边界在哪✓ 为什么一定要有 Review很多系统缺这一层✓ 如何形成学到→做到→复盘→改进的闭环适合阅读✓ AI Agent 初学者了解完整架构✓ Claude Code / LangGraph 重度用户✓ 想搭建个人知识开发体系的人✓ 对工程化而非 demo 感兴趣的人目录[TOC]不先讲架构先讲为什么不是别的这篇文章最后长成五层不是一开始设计出来的。它是一步步演化出来的。从 v0 到 v5 的演进graph LR v0[v0: 只有 Prompt]:::v -- v1[v1: Knowledgebr/知识能存了] v1 -- v2[v2: Rulesbr/行为统一了] v2 -- v3[v3: Agentbr/执行解耦了] v3 -- v4[v4: Projectbr/交付可追溯了] v4 -- v5[v5: Review br/闭环形成了] classDef v fill:#e6f1fb,stroke:#185fa5版本加了什么解决了什么还缺什么v0Prompt 文件能跑起来知识无法沉淀v1Obsidian 知识库知识有地方存Agent 行为不统一v2core/heavy 规则分层行为统一了规则和 Agent 耦合v3Hermes Claude CodeAgent 独立执行项目和工具混一起v4项目目录标准化交付物可追溯经验无法回流v5每日/每周复盘闭环形成Review 半自动当前每个版本都在补上一个版本的漏洞而不是为了多一层而多一层。为什么不选其他方案候选方案问题在哪单体一个文件全包规则20条后维护成本指数上升多 Agent 互相覆盖扁平层无方向双向依赖改了 A 不知影响 B复盘找不到根因四层缺 Review经验不回流踩过的坑下个新项目再踩一遍五层 反馈闭环架构留对了位置自动化可以迭代——推荐选五层的核心理由Review 把系统从一堆工具变成了能自我改进的有机体。第一层Knowledge — 土壤Knowledge Obsidian 知识库原子笔记 MOC PARA 管理体系存一切技术概念、论文笔记、踩坑记录、设计决策。为什么是底层因为规则不能拍脑袋。如果 Knowledge 里没有LLM 上下文窗口有限这个事实Rules 层就产不出关键提示放开头和结尾这条规则。设计三原则写入人类/Hermes 写笔记→ 读取Rules/Agent 检索→不做决策只存事实不含应该怎么做。第二层Rules — 从知识到约束Rules core/3 条常驻底线 heavy/20 按需能力文件把知道是什么变成应该怎么做。Knowledge 中的事实转化为 RuleLLM 上下文窗口有限加载 heavy/ 前估算 token超限时剪裁模型会 lost in the middle关键提示放开头和结尾修改文件前要读内容Read 优先于 Edit为什么独立一句话规则可以被多个 Agent 共享Hermes 和 Claude Code 读同一套 core/可以独立测试可以按需加载详见 01 篇。塞在 Knowledge 或 Agent 里都拿不到这些好处。第三层Agent — 规则的执行者Agent Hermes Agent学习教练 Claude Code编码工程师只管执行。接收任务 → 加载 Rules → 输出结果。不制造规则、不管理知识。为什么不和 Rules 合并Rules 定义应该遵守什么Agent 负责在特定任务中遵守它。合并的话每新增一个 Agent 都要重新配一遍规则。分开后 Agent 只管加载规则层独立演进。当前分工Hermes 管知识管理/面试准备Claude Code 管代码生成/架构/测试。两者共享 core/。第四层Project — 交付物Project agentone_test / agent_code / ...Agent 产出的代码、文档、配置。分开的理由很务实换工具时Claude Code → Cursor项目不受影响出问题时能分清是Agent 的问题还是规则的问题还是项目本身的问题一句话责任可追溯。第五层Review — 自愈Review Daily Review日复盘 Weekly Review周复盘定期检查前四层 → 发现问题 → 更新 Knowledge → 迭代 Rules → 优化 Agent。为什么独立成层经验证明如果 Review 是顺便做的事它就不会被做。独立成层是强制闭环——它不是可选装饰是架构的一部分。一个概念的五层之旅用真实例子说明五层如何联动Knowledge我记了一条原子笔记——LLM 对 Prompt 中间位置的指令遵循率低于两端来源Lost in the Middle 论文。RulesClaude Code 常忽略写在中段的约束。我把笔记转化为 heavy/ 规则关键提示放在对话开头或结尾。AgentClaude Code 加载规则后自动把安全边界、风格约束放 prompt 头尾中段只放参考内容。Projectagentone 项目的代码风格一致性提升手动修正减少 40%。Review周复盘记录了改善。Hermes 的 cron 发现连续两周出现遵循率波动备注建议补充规则——对话超过 10 轮后重新注入关键约束。闭环跑通的前提五层职责清晰、数据流向明确。架构图五层堆叠自底向上阅读方向自底向上。KNOWLEDGE 是土壤 → RULES 提取约束 → AGENT 加载执行 → PROJECT 产出 → REVIEW 反馈改进。再抽象一步和操作系统的类比OS 概念AI Engineering OS文件系统Knowledge持久化存储系统配置Rules行为约束进程调度Agent任务执行工作目录Project交付物监控日志Review可观测 反馈代码或配置示例完整目录结构一、AI核心规则配置根目录Rules Review 层 统一存放模型约束规则、复盘记录、通用技能库为智能体执行提供标准化规范与迭代素材 /.claude-data/ ├── core/ │ └── 00-must.md # 全局核心底线规则3条常驻强制规范所有场景通用 ├── heavy/ # 场景化按需增强规则库20细分能力配置 │ ├── 10-review.md # 内容复盘、输出校验规则 │ ├── 20-test.md # 代码测试、用例编写规则 │ ├── 30-architecture.md # 系统架构、方案设计规则 │ └── 40-security.md # 代码安全、合规校验规则 ├── memory/ # 常态化复盘归档目录体系自愈迭代核心 │ ├── YYYY-MM-DD.md # 每日复盘迭代记录按日期归档 │ └── MEMORY.md # 全局汇总复盘台账 └── skills/ # 可复用通用技能库 └── code-review.md # 代码评审标准化技能规范 二、通用知识知识库目录Knowledge 层 全局私有知识沉淀载体采用标准化笔记架构为规则、智能体提供底层知识土壤 /knowledge-base/ ├── 概念/ # 基础理论、技术概念沉淀 │ └── llm-context-window.md ├── MOC/ # 主题知识地图全局知识索引体系 └── 公开内容/ # 博客、文档、公开输出素材库 三、项目交付工程目录Agent Project 层 业务/技术项目落地载体支持项目级独立配置、可追溯、可复用 /workspace/project-demo/ ├── src/ # 项目核心源码、业务逻辑目录 ├── .claude/ # 项目专属个性化配置覆盖全局规则 └── README.md # 项目说明、交付文档、迭代记录 核心架构对应关系 知识层/knowledge-base/ 全域知识库提供所有上下文素材 规则层/.claude-data/core heavy 双层规则统一模型输出约束 执行层依托规则知识驱动智能体完成代码、文档、复盘等任务 交付层/workspace/ 各项目落地产出形成标准化交付物 复盘迭代层/.claude-data/memory/ 日周复盘反向更新知识与规则完成闭环迭代层间交互配置示例这是core/00-must.md常驻规则——任何任务都加载# core/00-must.md — 行为底线 core: - 始终使用中文回复 - 修改文件前先 Read 原始内容 - 提出架构方案时必须说明 trade-off这是heavy/10-review.md按需加载——仅代码审查任务# heavy/10-review.md — 代码审查规范 trigger: 用户要求代码审查或提交变更 max_lines: 300 priority: - 设计问题 - 正确性 - 可读性 - 性能 rules: - 每个问题必须有「描述 反例 改进建议」 - 不指出缺少文档/注释等非功能性建议加载逻辑伪代码def build_context(task_type: str) - list[str]: context load_file(core/00-must.md) # 常驻 task_heavy { review: [heavy/10-review.md], test: [heavy/20-test.md], arch: [heavy/30-architecture.md], security: [heavy/40-security.md], } for f in task_heavy.get(task_type, []): context load_file(f) # 按需 return context总结✅ 五层是从 v0 一步步演化出来的不是为了分层而分层。✅ 每一层不可替代Knowledge存→ Rules约→ Agent行→ Project交→ Review馈。✅ 依赖方向单向上→下反馈方向反向下→上避免循环依赖。✅ Review 层是这套系统有资格叫 OS的原因。没有闭环它只是一堆工具的堆叠。✅ 坦诚Review 目前半自动但架构里留好位置比自动化程度更重要——自动化可以迭代架构推倒重来成本极高。参考资料Lost in the Middle 论文→ 为什么关键指令不能放中间直接影响了 Rules 层的设计原则Claude Code 官方文档→ Rules 与 Project 配置分层加载的工程基础[待补链接]PARA Method (Tiago Forte)→ 知识库管理方法论Knowledge 层的组织依据Obsidian Linking MOC→ 笔记互连和索引导航让 Knowledge 层可检索Hermes Agent Skills 系统→ Review 半自动化的技术基础[待补链接]
