前言：我这一年经历的三个阶段
起点：从豆包开始粘贴代码
2025 年初，我想做一个本地的"扣子"——把字节的 Coze 搬到本地跑，数据不出本机。
为什么是基于 Coze？因为之前做影刀产品，我对自动化工作流已经非常了解了。Coze 刚好在这个时间开源了，并且用的是 MIT 协议——最宽松的开源协议，商业最友好。虽然 n8n 也开源了，但它带 Commons Clause 附加条款，不支持二次开发，对商业不友好。
最核心的判断是：前端节点编辑器是整个产品里最复杂、最耗时的部分。Coze 的画布已经做得很好，没必要重写。在其基础上做一个本地版 Coze，既能跑影刀的自动化流程，又能跑大模型的智能能力——这才是真正的价值所在。
那时候我的编程方式是这样的：打开豆包，问它"帮我写一个 C# 的插件加载器"，拿到代码，复制粘贴到 Visual Studio 里，跑一下，报错了，再把错误信息贴回去问。DeepSeek 也用过，效果差不多。
这个阶段，AI 对我的价值就是代码生成器。我提问，它回答。我复制，它粘贴。
这个时期做的产品是蜜蜂采集客户端（Mifeng-windows-client），一个 WPF 桌面应用，用来做直播数据采集。代码主要是我写的，AI 帮我生成一些结构性的东西——实体类、转换器、配置文件。它不理解你的业务，但它知道一个 Entity 类长什么样。
后来 IDE 开始有 AI 编程插件了——写一行它补三行。效率提升了，但本质没变：我写代码，AI 帮我补全。
第一阶段：我写代码，AI 辅助
这个阶段的核心状态是——人为主，AI 为辅。
我负责所有的业务逻辑、架构设计、核心代码。AI 负责那些"确定性高、重复性强"的部分：
- 帮我生成 Entity 类（给个表结构，它能出一堆实体）
- 帮我写配置文件（JSON、XML、YAML 这些格式化的东西）
- 帮我做批量操作（20 个页面要改同样的逻辑，它几秒钟搞定）
工具链：豆包 / DeepSeek + IDE 编程插件
人的价值：写代码。没有 AI 我也能写完，只是慢一些。
这个阶段 AI 干的事情，本质上是"批量生产结构化的代码"。
第二阶段：我做设计，AI 写代码
2024 年底，悟空项目启动。这是一个 Java 后端的直播社交平台——注：这个项目和我的产品没有直接关系，是我以解决方案架构师的身份，协助中小企业做企业架构转型的项目。
工具链升级了：从"豆包 + 复制粘贴"变成了"IDEA + AI 编程插件"。
体验完全不同了。以前是"我问它答"，现在是"我写一行，它补三行"。写个 Controller 方法签名，它帮你把参数校验、Service 调用、异常处理全补上了。写个 Entity 类，它帮你把 Repository、Service、Controller 一层全生成出来。
效率翻了好几倍。但核心变了——我不再一行一行写代码了，我在做设计。
悟空项目里有个账务模块，我设计了一套完整的领域驱动架构——账户隔离、交易流水驱动、事务管理。架构是我画的，核心类是我定义的，但具体的实现代码，大部分是 AI 生成的。现在去看那个账务模块的设计文档（wukong-server/wukong-component/src/main/java/com/mifeng/wukong/common/trans/账务系统设计.md），里面从模型层到业务处理层的完整设计，都是我先想清楚，再让 AI 按设计填充的。
这个阶段人的价值变了：不再是写代码，而是架构设计和质量把关。
AI 能写代码，但它不知道代码应该长什么样。你得告诉它。
这个阶段的关键变化：人的价值从"写代码"变成了"做设计"。你不需要一行一行敲代码了，但你需要知道代码应该长什么样。
第三阶段：AI 全流程执行
2025 年初，我开始用 Qoder。
Qoder 和 IDE 插件的区别是——IDE 插件只能在你写代码的时候补全，Qoder 能理解你的整个项目。它知道目录结构、知道代码规范、知道模块之间的关系。
这时候我开始想一个问题：能不能让 AI 不只是写代码，而是参与整个开发流程？
需求分析 → 架构设计 → 架构 Review → 编码 → 测试 → 发布。
这一整条链路，能不能全让 AI 跑？
答案是：可以，但要分几步走。
子阶段 1：让 AI 写文档，我来审阅
我做的第一件事，是让 AI 帮我写需求文档。
比如要改一个功能，我先让 AI 扫描现有代码，生成一份需求分析文档。我审阅一遍，改改措辞，确认方案没问题，然后让 AI 按文档写代码。
Documents/修改记录 目录下有 160 多份这样的文档，每一份都对应一次真实的代码变更：
0410-143000-LLM节点简化改造.md
0412-203000-Skill管理后端功能开发.md
0414-模型配置三层架构.md
0416-160000-CLI安装中心.md
0528-Coze三层架构迁移-端点响应格式对比.md但很快我发现了问题——没有工程化思想。
每个功能的文档散落在各个文件夹里，命名不统一，规范不统一。AI 默认生成的位置就是当前编辑目录，结果文档到处都是。代码也是，同一个功能，AI 两次生成的风格可能不一样，因为它不记得上次是怎么写的。
AI 能写文档，能写代码，但它没有"规矩"。你不告诉它规范，它每次按自己的理解来。
子阶段 2：驾驭 AI
发现问题之后，我开始琢磨怎么"管住"AI。
先做 Skill。 我发现自己反复给 AI 说同样的话——"需求文档要放在 Documents/修改记录 目录下"、"后端要按五层架构写"、"前端模块要用 Rush Monorepo"。说了十遍之后我烦了，就把这些写成了 Skill 文件。
一个 Skill 就是一份标准化的操作手册——输入是什么、输出是什么、放在哪里、遵循什么规范。现在 .qoder/skills/ 目录下有 30 多个 Skill：
create-csharp-module/ — 创建 C# 模块，自动生成标准目录结构
create-web-module/ — 创建前端模块，含 Formily 表单标准
design-wpf-ui/ — 设计 WPF 界面，遵循 Semi Design 规范
create-requirement/ — 生成需求文档，自动放到修改记录目录
build-desktop/ — 构建桌面端，自动打包发布再做 Rule。 Skill 解决了"怎么做"的问题，但 AI 写的代码风格还是不统一。比如 C# 的异常处理，AI 默认喜欢到处 try-catch 然后吞掉异常；前端组件的导出方式，每次都不一样。
于是我写了 Rule 文件——比 Skill 更短、更聚焦，只定义一条约束：
csharp-early-return.md — 禁止深层嵌套，强制 early return
csharp-exception-handling.md — 禁止吞异常，不捕获直接抛出
web-api-pattern.md — API 层统一返回格式
web-hooks-pattern.md — React Hooks 标准写法
web-tailwind-standard.md — Tailwind CSS 使用规范.qoder/rules/ 目录下现在有 14 条规则。这些规则不是"建议"，是强制约束。
有了 Skill + Rule，AI 的输出质量稳定多了。但还有一个问题——AI 不了解项目全貌。
子阶段 3：Harness 架构
到了 2025 年中，事情开始变得不一样了。
我不再是一个一个地写 Skill 和 Rule，而是开始思考一个更大的问题：怎么让 AI 像一个团队成员一样工作？
一个团队成员需要什么？
- 知道项目的整体架构（
AGENTS.md） - 知道自己能做什么、不能做什么（边界约束）
- 知道遇到问题找谁（SubAgent 分工）
- 知道做事要遵循什么规范（Rule）
- 知道有哪些现成的能力可以用（Skill + Tool）
这就是 Harness 架构的由来。
现在打开 Automator Client 项目的 AGENTS.md，你会看到一份完整的项目上下文定义——后端五层架构、前端模块结构、命名规范、依赖原则、测试命令、需求文档规范、基础类库索引，全部写在一个文件里。
AI 接到任务时，先读 AGENTS.md 了解项目全貌，再根据任务类型加载对应的 Rule 和 Skill，然后开始工作。如果任务复杂，它会拆分给 SubAgent——每个 SubAgent 有自己的上下文和工具集。
AGENTS.md — 全局上下文（项目架构、规范、索引）
rules/ — 14 条编码约束
skills/ — 30+ 个标准化操作
agents/ — 子 Agent 定义（部署、发布等）
Documents/修改记录/ — AI 生成的需求文档（人审阅）从"我教 AI 做事"变成了"我给 AI 定义工作环境"。 我不再需要每次告诉它"怎么做"，而是定义好"在这个项目里，所有事情都这么做"。
三个阶段，一张图
第一阶段
人写代码 → AI 辅助补全
工具：豆包/DeepSeek + IDE 编程插件
人的价值：写代码
代表作：蜜蜂采集客户端
第二阶段
人做架构设计 → AI 生成代码 → 人测试把关
工具：IDEA + AI 编程插件
人的价值：架构设计 + 质量把关
代表作：悟空平台（账务模块）
第三阶段
人定义 Harness → AI 全流程执行
需求分析 → 架构设计 → 编码 → 测试 → 发布
工具：Qoder + AGENTS.md + Rule + Skill + SubAgent
人的价值：定义规则 + 审阅决策
代表作：Growth AIOS Components这本书讲什么
这本书讲的就是我从第一阶段走到第三阶段的整个过程。
不是"Agent 是什么"的科普，不是"怎么用 LangGraph 写一个 Agent"的教程。是一个正在做 Agent 产品的人，把自己踩过的坑、做过的决策、长出来的架构，原原本本写下来。
每一章都是一个问题：我遇到了什么麻烦，我做了什么选择，代码最终长成了什么样。然后我会告诉你，业界其他人在怎么解决同样的问题——LangGraph 怎么做的、微软的框架怎么做的、Hermes 怎么做的、AgentScope 怎么做的。
读完这本书，你不一定学会用某个框架，但你会理解：Agent 架构为什么长这样，每个组件为什么必须存在，以及你自己的项目应该怎么演化。
全书结构
- 第一部分 + 第二部分：Harness 工程方法论——怎么驾驭 AI，让它稳定、可控、按规范产出。从 Skill、Rule 到 AGENTS.md，从单点辅助到全流程执行。
- 第三部分：Agent 架构设计——深入 Agent 的每个核心组件，从记忆、工具、规划到多 Agent 协作，结合业界主流框架对比分析。
为什么先花两大部分讲 Harness，不直接讲 Agent？
因为这是我自己踩出来的顺序。没有 Harness 的基础，你设计出来的 Agent 架构是空中楼阁——AI 的输出不稳定、不可控、每次结果都不一样，你拿什么去编排？先让 AI 能稳定干活，再谈怎么让它协同工作。这不是理论推导，是我真实走过的路径。
市面上讲 Agent 的书和课程不少，但大多数直接切入架构设计——记忆怎么做、规划怎么做、多 Agent 怎么协作。这些都没错，但跳过了一个前置问题：你怎么让 AI 的输出是稳定的、可控的、符合规范的？
这个问题不解决，Agent 架构设计得再漂亮，落地也是散的。因为 Agent 的每一步执行都依赖 AI 的输出质量——如果 LLM 的返回格式不稳定，你的工具调用就会报错；如果代码生成风格不统一，你的多 Agent 协作就会互相冲突。
所以这本书的结构是：
- 先解决“驾驭 AI”（第一部分 + 第二部分）：Skill、Rule、AGENTS.md、Harness 架构——让 AI 的输出稳定、可控、按规范产出。
- 再解决“设计 Agent”（第三部分）：记忆、工具、规划、多 Agent 协作——在稳定的基础上构建复杂的智能体系统。
为什么没有 RAG 和向量数据库的章节
我的个人经历都是做自动化工作流的，目前市面上主流的聊天、辅助销售、企业知识库产品，核心是 RAG（检索增强生成）和向量数据库。但在我目前的场景里确实用不到，所以这本书不会介绍这部分内容。
等后续有具体落地的项目，我会继续分享。那部分主要是向量数据库的使用，纯粹是知识性的内容——说实话，AI 本身就能提供足够好的讲解，没必要专门写一章。
我们开始吧。