前言
过去一年，在系统学习AI Agent开发的过程中，从LangChain、Prompt Engineering到MCP及各类Agent框架，几乎每个环节都接触过。
但学得越深入，越发现一个核心瓶颈：真正限制开发效率的，并非模型能力，而是工程管理能力。
最初，Prompt、代码、文档和笔记分散存放在不同位置。随着项目复杂度不断上升，逐渐暴露出几个问题：
- 同样的问题反复思考，每次遇到新坑都得重新搜索一遍；
- 项目规则越来越混乱，不同的Agent工具各自拥有独立配置，相互冲突；
- 学到的知识无法复用，读完的论文、调试过的Bug转瞬即忘；
- 每次启动新项目都要重新搭建开发环境，如同重新搭积木。
这个发现让我意识到：问题不在于工具不够强大，而在于缺乏统一的工程化管理体系。
于是，我尝试将学习、知识管理和开发流程沉淀为一套系统，期望把日常开发中的知识、规则、工作流和项目统一管理起来。
这篇文章是整个系列的第00篇，主要阐述为什么会有这个想法、希望解决什么痛点，而非介绍具体工具的使用方法。
为什么需要一套AI Engineering OS？
先谈最原始的问题：开发环境变得越来越难管理了。
三个独立的AI工具在同时工作，各自负责不同事务：一个管理学习和知识管理，一个负责代码生成，一个把控工程规范。三个工具各有各的配置、规则和记忆文件。
刚开始还算顺畅，后来问题逐渐显现：
Prompt散落各处。有些写在学习工具的skill里，有些写在代码工具的rules里，还有些散落在笔记中。想要查找一个曾经调试好的prompt，需要翻遍好几个地方。
文档难以定位。之前编写过一个项目架构文档，但放在哪个目录、什么格式，完全没有印象。检索成本比重新编写还高。
Agent缺乏统一规则。不同工具对“代码风格”、“输出格式”、“安全约束”的理解截然不同。同一个项目，两个工具的答案风格可能相差两倍。
每个项目都需要重复配置。新建项目→配置规则文件→编写行为规范→安装依赖→调整prompt。这一套流程下来半天就没了。下次做类似项目，还得重复一遍。
经验无法积累。调试好一个复杂pipeline，解决了三个隐患，跟同事分享完就结束了。下次遇到类似场景，又得从头排查。没有形成可复用的知识资产。
这些问题的本质是：工具在进化，但工程化管理没有同步跟上。
由此引出一个思考：有没有办法把这些零散的流程串联起来？
我的目标
核心矛盾在于：开发效率受限于工具之间的信息孤岛。
我对这套系统的期望包括：
知识统一管理。所有学到的概念、踩过的坑、调通的流程，都有一个地方可以快速检索。不需要全部记在脑子里，但要求两分钟内能够找到。
Agent统一行为规范。无论是用Hermes做知识管理、Claude Code写代码，还是未来接入其他Agent，都应遵循同一套规则体系：代码风格一致，输出格式统一，安全边界清晰。
工程经验持续累积。每次解决一个问题，系统自动或半自动地将经验沉淀下来。下次遇到同类问题，不需要从头思考。
项目可以快速复用。新建项目时，规则、模板、常用配置、依赖环境都能一键拉起。从“搭积木”变成“用模板”。
每天都有可复盘的数据。今天学了什么、调了什么、踩了什么坑、解决了什么——这些数据能被记录和复盘，形成正向反馈循环。
系统的大致结构
AI Engineering OS 当前的分层设计如下：
知识库 (Obsidian) ↓Rules (core/ + hea vy/) ↓Agent Layer (Hermes / Claude Code) ↓项目 (agentone_test / agent_code / ...) ↓复盘 (Daily Review + Weekly Review) ↓持续优化 (Skill 沉淀 + 规则迭代)
每一层的关系是：
- 知识库是整个系统的底层基础。所有技术概念、笔记、阅读记录存放在Obsidian中，采用PARA + Zettelkasten混合管理。
- Rules是Agent的行为规范。拆分为core（常驻规则）和hea vy（按需加载）两层，避免每次对话携带过多上下文。
- Agent Layer是执行层。Hermes负责学习、笔记、技能沉淀；Claude Code负责编码、重构、测试。两者通过共享规则统一行为。
- 项目是具体的交付成果。每个项目继承通用规则，再覆盖项目特有的配置。
- 复盘是反馈闭环。日复盘+周复盘，检查学习进度和规则有效性。
- 持续优化是系统的进化机制。有用的经验沉淀为技能，过时的规则淘汰，整个系统越用越强。
这个结构并非一开始就设计好的，而是在两个月的使用过程中不断调整出来的。后续每篇文章都会深入介绍某一层。
用图来表示，变化如下：
以前：工具和数据各自为战
flowchart LRPrompt[Prompt 片段]Obsidian[Obsidian 笔记]Claude[Claude Code 工具]Hermes[Hermes 工具]GitHub[GitHub]Notes[各处笔记]
现在：分层协同
flowchart TDKnowledge[知识库]Rules[Rules 行为规范]Agent[Agent 执行层]Project[项目]Review[复盘]Knowledge --> Rules --> Agent --> Project --> ReviewReview -.-> Knowledge
闭环：越用越强
flowchart TDLearn[学习新知识]Practice[工程实践]Review3[复盘总结]KB[沉淀到知识库]Learn --> Practice --> Review3 --> KB --> Learn
目前已经实现了什么？
目前已经实现的部分包括：
知识库整理已基本完成。Obsidian主库 + learn02学习库，已经建立Index导航、YAML frontmatter规范、跨库wikilink体系。学过的每个概念都有原子笔记。
开发规范已初步建立。AI Engineering OS分为core/和hea vy/两层：
- core/有3条最小规则（行为底线）
- hea vy/有20+个能力文件（按需加载）
- 覆盖代码审查、架构设计、测试规范、安全检查
Hermes工作流。配置了Hermes Agent作为学习教练，管理：
- 面试准备和薄弱点识别
- 间隔复习卡片（1d/3d/7d/30d）
- Obsidian笔记自动化生成
- 知识关联和MOC维护
Claude Code配置。遵循三体分离原则：
- Hermes Agent管理自己的
/hermes/目录 - Claude Code管理自己的
.claude/目录 - AI Engineering OS管理
D:.claude-data - 三者互不干扰，通过共享规则协同
项目模板。常见项目的脚手架和配置文件已经整理，新建时直接复制即可。
还存在哪些不足？
只写成功是没意义的，坦诚说明不足：
生命周期管理仍需完善。知识的“过期检查”尚未实现——有些笔记是两个月前写的，里面的API可能已经更新。谁来定期审查？什么频率？还没有自动化机制。
自动化程度不够。目前的复盘仍是半自动状态：Hermes协助编写，但最终需要手动触发。理想状态应该是每天自动汇总、推送摘要。
很多流程仍依赖人工维护。技能沉淀、规则更新、项目归档等操作，目前还是手动执行，自动化程度还有提升空间。
还没有形成完整的数据统计。每天学习时长、调试Bug数量、知识库增长率——这些数据散落各地，没有统一的Dashboard。
三套系统之间的衔接还不够顺畅。Hermes写了笔记→Claude Code读不到；Claude Code沉淀了经验→Hermes不知道。中间还需要一个共享的“总线”。
这些不足既是当前的问题，也是后续优化的方向。
我最大的感受
写到这里，最真实的感受是：
越来越觉得，AI Agent真正难的不是Prompt，而是工程化。
Prompt可以模仿、调整、迭代。但工程化不行——它需要理解自己的开发流程，理解工具之间的协作关系，理解知识如何沉淀、规则如何演进、经验如何复用。
这个系列会持续写下去，每一篇都会围绕一个真实的问题展开：为什么Rules要分层？为什么Memory需要生命周期？为什么要做Review？
并不是介绍“有什么”，而是分享“为什么这样设计”。
如果这些思考能够帮助更多开发者少走一些弯路，那这套系统就不仅仅是一个人的工具，而是一份可以持续沉淀的工程实践。
如果你也在尝试构建自己的AI开发体系，期待与同行交流。
本文是 [AI Agent 工程实践] 系列的第 00 篇，用于介绍系列背景和整体思路。
