news 2026/7/8 9:30:51

AI Agent 工程实践(00):为什么我要构建 AI Engineering OS

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
AI Agent 工程实践(00):为什么我要构建 AI Engineering OS

标签: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/30d)
  • Obsidian 笔记自动化生成
  • 知识关联和 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 篇,用于介绍系列背景和整体思路。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/8 9:30:52

GEO时代,如何从0到1建立品牌监控体系?

当我们还在讨论SEO优化时,用户的搜索行为已经悄然改变。根据最新数据显示,越来越多的用户开始直接向AI助手提问,而不是打开搜索引擎输入关键词。这种趋势带来了一个新的问题:你的品牌内容是否被AI平台引用?在AI的回答中…

作者头像 李华
网站建设 2026/7/8 9:29:02

AI智能体其实是一次创富机会,只是99%的人都错过了

AI智能体其实是一次创富机会,只是99%的人都错过了。阿里和豆包,为什么突然把智能体关了?说白了,就是有些人,把AI玩得越来越不像AI了。很多人对AI智能体的机会还没看懂,这个行业就消失了。你别以为大家都拿A…

作者头像 李华
网站建设 2026/7/8 9:28:47

MCP3428与MK24FN1M0VDC12在工业数据采集中的优化应用

1. 为什么选择MCP3428MK24FN1M0VDC12组合 在工业现场的数据采集场景中,我们常常面临几个典型痛点:传感器信号微弱易受干扰、多通道同步采集需求强烈、现场布线复杂导致信号衰减。传统方案采用分立式ADC芯片配合通用MCU,不仅电路设计复杂&…

作者头像 李华
网站建设 2026/7/8 9:27:31

高压隔离技术:ISOM8710与PIC18F86J11的工业应用

1. 高压安全隔离技术概述 在工业自动化、电力电子和汽车电子等领域,高压安全隔离是一个至关重要的设计考量。当系统需要处理数百甚至数千伏的电压时,可靠的隔离技术能够保护低压侧的控制电路和操作人员免受高压危害。ISOM8710与PIC18F86J11的组合&#x…

作者头像 李华
网站建设 2026/7/8 9:24:53

家庭游戏串流革命:如何用Sunshine打造全屋游戏共享中心

家庭游戏串流革命:如何用Sunshine打造全屋游戏共享中心 【免费下载链接】Sunshine Self-hosted game stream host for Moonlight. 项目地址: https://gitcode.com/GitHub_Trending/su/Sunshine 想象一下这样的场景:爸爸在客厅用大屏电视玩AAA大作…

作者头像 李华
网站建设 2026/7/8 9:21:46

Pearson vs Spearman vs Kendall:3大相关系数适用场景与Python/R代码对比

Pearson vs Spearman vs Kendall:3大相关系数适用场景与Python/R代码实战 当我们需要探究两个连续变量之间的关系时,相关系数是最常用的统计工具之一。但在实际应用中,面对不同的数据特征和分析需求,如何选择合适的相关系数往往让…

作者头像 李华