标签AI Agent、LLM、工程实践、知识管理、Claude Code前言去年我开始系统学习 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/ heavy/) ↓ Agent Layer (Hermes / Claude Code) ↓ 项目 (agentone_test / agent_code / ...) ↓ 复盘 (Daily Review Weekly Review) ↓ 持续优化 (Skill 沉淀 规则迭代)每一层的关系是知识库是整个系统的底层土壤。所有技术概念、笔记、阅读记录放在 Obsidian 里用 PARA Zettelkasten 混合管理。Rules是 Agent 的行为规范。拆成 core常驻规则和 heavy按需加载两层避免每次对话塞太多上下文。Agent Layer是执行层。Hermes 管学习、笔记、技能沉淀Claude Code 管编码、重构、测试。两者通过共享规则统一行为。项目是具体的交付成果。每个项目继承通用规则再覆盖项目特有的配置。复盘是反馈闭环。日复盘 周复盘检查学习进度和规则有效性。持续优化是系统的进化机制。有用的经验沉淀为技能过时的规则淘汰整个系统越用越强。这个结构不是一开始就设计好的是在用了两个月的过程中不断调整出来的。后续每篇文章都会深入介绍某一层。用图来说变化是这样的以前工具和数据各自为战flowchart LR Prompt[Prompt 片段] Obsidian[Obsidian 笔记] Claude[Claude Code 工具] Hermes[Hermes 工具] GitHub[GitHub] Notes[各处笔记]现在分层协同flowchart TD Knowledge[知识库] Rules[Rules 行为规范] Agent[Agent 执行层] Project[项目] Review[复盘] Knowledge -- Rules -- Agent -- Project -- Review Review -. Knowledge闭环越用越强flowchart TD Learn[学习新知识] Practice[工程实践] Review3[复盘总结] KB[沉淀到知识库] Learn -- Practice -- Review3 -- KB -- Learn目前已经实现了什么目前已经跑通的部分知识库整理已基本完成。Obsidian 主库 learn02 学习库已经建立了 Index 导航、YAML frontmatter 规范、跨库 wikilink 体系。学过的每个概念都有原子笔记。开发规范已初步建立。AI Engineering OS 分 core/ 和 heavy/ 两层core/ 有 3 条最小规则行为底线heavy/ 有 20 个能力文件按需加载覆盖代码审查、架构设计、测试规范、安全检查Hermes 工作流。配置了 Hermes Agent 作为学习教练管理面试准备和薄弱点识别间隔复习卡片1d/3d/7d/30dObsidian 笔记自动化生成知识关联和 MOC 维护Claude Code 配置。三体分离原则Hermes Agent 管自己的/hermes/目录Claude Code 管自己的.claude/目录AI Engineering OS 管D:\.claude-data\三者互不干扰通过共享规则协同项目模板。常见项目的脚手架和配置文件已经整理新建时直接 copy。还存在哪些不足只写成功是没意义的坦诚说不足生命周期管理仍需完善。知识的过期检查还没做——有些笔记是两个月前写的里面的 API 可能已经变了。谁来定期审查什么频率还没有自动化。自动化程度不够。目前的复盘还是半自动的Hermes 帮忙写但最终还是我触发。理想状态应该是每天自动汇总、推送摘要。很多流程仍依赖人工维护。技能沉淀、规则更新、项目归档这些操作目前还是手动执行自动化程度还有提升空间。还没有形成完整的数据统计。每天学了多长时间、调了几个 Bug、知识库增长了多少——这些数据散落各地没有统一的 Dashboard。三套系统之间的衔接还不够顺。Hermes 写了笔记 → Claude Code 读不到Claude Code 沉淀了经验 → Hermes 不知道。中间还需要一个共享的总线。这些不足既是问题也是后续优化的方向。我最大的感受写到这里我想说一个最真实的感受。我越来越觉得AI Agent 真正难的不是 Prompt而是工程化。Prompt 可以抄、可以调、可以迭代。但工程化不行——它需要你理解自己的开发流程理解工具之间的协作关系理解知识怎么沉淀、规则怎么演进、经验怎么复用。这个系列我会持续写下去每一篇都会围绕一个真实的问题展开为什么 Rules 要分层为什么 Memory 需要生命周期为什么要做 Review不是介绍我有什么而是分享我为什么这样设计。如果这些思考能够帮助更多开发者少走一些弯路那这套系统就不仅仅是我自己的工具而是一份可以持续沉淀的工程实践。如果你也在尝试构建自己的 AI 开发体系欢迎交流。本文是 [AI Agent 工程实践] 系列的第 00 篇用于介绍系列背景和整体思路。
AI Agent 工程实践（00）：为什么我要构建 AI Engineering OS
发布时间：2026/7/8 9:31:05
标签AI Agent、LLM、工程实践、知识管理、Claude Code前言去年我开始系统学习 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/ heavy/) ↓ Agent Layer (Hermes / Claude Code) ↓ 项目 (agentone_test / agent_code / ...) ↓ 复盘 (Daily Review Weekly Review) ↓ 持续优化 (Skill 沉淀 规则迭代)每一层的关系是知识库是整个系统的底层土壤。所有技术概念、笔记、阅读记录放在 Obsidian 里用 PARA Zettelkasten 混合管理。Rules是 Agent 的行为规范。拆成 core常驻规则和 heavy按需加载两层避免每次对话塞太多上下文。Agent Layer是执行层。Hermes 管学习、笔记、技能沉淀Claude Code 管编码、重构、测试。两者通过共享规则统一行为。项目是具体的交付成果。每个项目继承通用规则再覆盖项目特有的配置。复盘是反馈闭环。日复盘 周复盘检查学习进度和规则有效性。持续优化是系统的进化机制。有用的经验沉淀为技能过时的规则淘汰整个系统越用越强。这个结构不是一开始就设计好的是在用了两个月的过程中不断调整出来的。后续每篇文章都会深入介绍某一层。用图来说变化是这样的以前工具和数据各自为战flowchart LR Prompt[Prompt 片段] Obsidian[Obsidian 笔记] Claude[Claude Code 工具] Hermes[Hermes 工具] GitHub[GitHub] Notes[各处笔记]现在分层协同flowchart TD Knowledge[知识库] Rules[Rules 行为规范] Agent[Agent 执行层] Project[项目] Review[复盘] Knowledge -- Rules -- Agent -- Project -- Review Review -. Knowledge闭环越用越强flowchart TD Learn[学习新知识] Practice[工程实践] Review3[复盘总结] KB[沉淀到知识库] Learn -- Practice -- Review3 -- KB -- Learn目前已经实现了什么目前已经跑通的部分知识库整理已基本完成。Obsidian 主库 learn02 学习库已经建立了 Index 导航、YAML frontmatter 规范、跨库 wikilink 体系。学过的每个概念都有原子笔记。开发规范已初步建立。AI Engineering OS 分 core/ 和 heavy/ 两层core/ 有 3 条最小规则行为底线heavy/ 有 20 个能力文件按需加载覆盖代码审查、架构设计、测试规范、安全检查Hermes 工作流。配置了 Hermes Agent 作为学习教练管理面试准备和薄弱点识别间隔复习卡片1d/3d/7d/30dObsidian 笔记自动化生成知识关联和 MOC 维护Claude Code 配置。三体分离原则Hermes Agent 管自己的/hermes/目录Claude Code 管自己的.claude/目录AI Engineering OS 管D:\.claude-data\三者互不干扰通过共享规则协同项目模板。常见项目的脚手架和配置文件已经整理新建时直接 copy。还存在哪些不足只写成功是没意义的坦诚说不足生命周期管理仍需完善。知识的过期检查还没做——有些笔记是两个月前写的里面的 API 可能已经变了。谁来定期审查什么频率还没有自动化。自动化程度不够。目前的复盘还是半自动的Hermes 帮忙写但最终还是我触发。理想状态应该是每天自动汇总、推送摘要。很多流程仍依赖人工维护。技能沉淀、规则更新、项目归档这些操作目前还是手动执行自动化程度还有提升空间。还没有形成完整的数据统计。每天学了多长时间、调了几个 Bug、知识库增长了多少——这些数据散落各地没有统一的 Dashboard。三套系统之间的衔接还不够顺。Hermes 写了笔记 → Claude Code 读不到Claude Code 沉淀了经验 → Hermes 不知道。中间还需要一个共享的总线。这些不足既是问题也是后续优化的方向。我最大的感受写到这里我想说一个最真实的感受。我越来越觉得AI Agent 真正难的不是 Prompt而是工程化。Prompt 可以抄、可以调、可以迭代。但工程化不行——它需要你理解自己的开发流程理解工具之间的协作关系理解知识怎么沉淀、规则怎么演进、经验怎么复用。这个系列我会持续写下去每一篇都会围绕一个真实的问题展开为什么 Rules 要分层为什么 Memory 需要生命周期为什么要做 Review不是介绍我有什么而是分享我为什么这样设计。如果这些思考能够帮助更多开发者少走一些弯路那这套系统就不仅仅是我自己的工具而是一份可以持续沉淀的工程实践。如果你也在尝试构建自己的 AI 开发体系欢迎交流。本文是 [AI Agent 工程实践] 系列的第 00 篇用于介绍系列背景和整体思路。
