Qoder 作为 Growth 的 Agent 基座

我们走过的弯路

Growth AIOS 是一个完整的营销科技产品矩阵——AI Agent 编排平台、AI 视频剪辑、SCRM 社交客户管理、直播采集推流，每个产品都有自己的技术栈和运行环境。

在做这套产品的过程中，我们很早就意识到：每个产品都需要 AI 能力。用户说"帮我写一个爬虫节点"，如果让用户自己去查文档、写代码、配置环境，体验完全跟不上。

所以我们的第一反应是：自研一个 Agent 产品，为每个子产品赋能。

于是我们开始做自己的 Agent 引擎。先做 AIOS 的，再做 Video 的，再做 BaseData 的……做着做着发现问题了——每个产品的业务逻辑不同、数据模型不同、交互方式不同，Agent 引擎要适配每个产品，复杂度成倍增长。

更麻烦的是，Agent 能力不止是"调大模型"，还涉及规则引擎、记忆系统、工具调用、工作流编排——这些如果全自研，跟重新造一个 Qoder 没有区别。

这条路走不通。

策略转折：用 Qoder 做基座

方向错了就换方向。我们重新审视了整个技术栈之后，做出了一个关键决策：

停止自研 Agent 引擎，把 Qoder 作为一整套 Agent 基座。Growth 产品通过 CLI 接入这个基座。

这个决策基于三条判断：

判断一：Qoder 已经完成了最难的部分

Qoder 的 Agent 系统、Skill/Rule 体系、Memory 治理、MCP 协议——这些底座能力是完整且经过验证的（正如本书第二部分所讲）。我们不需要重复造这些轮子。

判断二：大厂的技术优势比我们自己做强

Qoder 团队在 Agent 工程上的投入和积累远超我们一个产品团队能做的。Rule 系统、Memory 分层、SubAgent 编排——这些我们自己从零开始，至少半年才能做到可用。

利用已有的平台，比从零搭建更聪明。

判断三：CLI 是最通用的连接方式

每个 Growth 产品的技术栈不同——C# WPF、ASP.NET Core、React、C++——但它们都能调用命令行。CLI 是跨平台的"最小公约数"。

---

Integration.CLI：连接 Qoder 与 Growth 产品的桥梁

策略清晰之后，具体怎么落地？答案是一个叫 Integration.CLI 的独立 EXE 程序。

整体交互链路

用户通过 Qoder 提出需求，Qoder 通过 Skill/Agent 调用 CLI，CLI 操控 Growth 产品的运行时环境，返回 JSON 结果：

用户一句话需求
    │
    ▼
Qoder Agent/Skill
  - 理解需求，生成代码节点目录
  - 调用 automator.exe 执行注册/测试
  - 解析 CLI 返回的 JSON 结果
    │  命令行调用（stdin/stdout/stderr）
    ▼
automator.exe（Integration.CLI）
  - 解析命令行参数
  - 调用 Runtimes 模块服务
  - 输出 JSON 到 stdout
    │  调用现有模块接口
    ▼
Runtimes（环境管理 + 代码节点管理）
CodeRunner（代码执行）

调用规范

所有命令统一风格 automator <动词> <对象> [参数...]，输入输出全 JSON：

场景	命令
注册代码节点	automator code-node add ./clue_crawl/
列出所有节点	automator code-node list
测试执行节点	automator code-node run clue_crawl '{"platform":"xhs"}'
更新节点代码	automator code-node update clue_crawl ./v2/
安装运行环境	automator runtime install python --version 3.11
安装依赖	automator dep install clue_crawl

Skill 封装

CLI 本身只是命令行工具，真正的威力在 Qoder 的 Skill 封装。每个 CLI 命令对应一个 Qoder Skill，把"命令行拼字符串"这件事封装成可复用的工作流：

Skill: 注册代码节点
  输入: 目录路径
  执行: automator code-node add {path}
  解析: JSON 返回节点 ID
  输出: "已注册 {name} 节点，ID: {id}"

Skill: 测试代码节点
  输入: 节点 ID + 参数 JSON
  执行: automator code-node run {id} '{params}'
  解析: JSON 返回执行结果
  输出: 执行摘要 + 耗时

多个 Skill 可以组合成一个更强大的 Agent。比如"帮我创建一个小红书爬虫并测试"这个需求，Agent 会依次调用三个 Skill：

1. 生成代码（Qoder 写代码）
2. 注册节点（调用 CLI）
3. 测试运行（调用 CLI）
4. 返回结果

整个过程用户只需要说一句话，剩下的 Agent 自动编排。

---

与 MCP 协议的关系

MCP 协议是另一种 AI 工具连接方式。为什么不直接用 MCP？

维度	MCP 协议	CLI + Skill
集成复杂度	需要实现 MCP Server	已有 CLI 即可，Skill 封装调用
跨语言	协议层统一	CLI 本身就是跨语言
渐进式构建	需一次性实现	今天加一个命令明天加一个
调试难度	需要启动 Server	本地命令行直接测试
可组合性	单次工具调用	Skill 可编排多步流水线

我们的策略是：CLI 作为底层桥梁，MCP 作为可选上层协议。 如果未来需要更标准化的工具调用，可以在 CLI 外面包一层 MCP Server。但现阶段，CLI + Skill 的组合已经足够灵活。

---

跟 Skill 体系的关系

本书第二部分详细讲了 Qoder 的 Skill 体系。Integration.CLI 正是 Skill 体系的最佳实践——把重复性的命令行操作封装成可复用的工作流。

但这里有一个更宏观的视角：Skill 封装 CLI，CLI 连接产品，Qoder 组合一切。

Qoder Agent 基座
  ├── Skill（封装工作流）
  │   ├── 注册节点 Skill → CLI
  │   ├── 测试节点 Skill → CLI
  │   └── 安装依赖 Skill → CLI
  ├── Rule（约束编码规范）
  ├── Memory（记忆用户偏好）
  └── SubAgent（组合多个 Skill）
        │  CLI 连接
        ▼
Growth 产品矩阵
  ├── Growth AIOS
  ├── Growth Video
  ├── Growth BaseData
  └── Growth Chat

Qoder 负责 Agent 能力的全部——理解需求、编排任务、调用工具、约束输出。Growth 产品负责具体执行——运行代码、管理环境、处理文件。两者通过 CLI 对接，互不侵入。

---

给读者的启发

如果你有自己的产品体系，正在考虑"怎么把 AI 集成进去"，我的建议是：

1. 不要自研 Agent 引擎——除非你的核心业务就是卖 Agent 引擎。Agent 系统的复杂度远超表面看到的对话界面
2. 让你的产品暴露 CLI——命令行是最通用的"被集成"接口，比 SDK、API 都轻量
3. 用 Qoder 做基座——把 Qoder 当作你的 Agent 底座，通过 CLI + Skill 连接你的产品
4. 渐进式构建——今天暴露一个命令，明天暴露一个，逐步积累 Skill 库

这跟本书前面讲的四层架构完全一致：Qoder 是 Agent 基座（L1），CLI + Skill 是工具体系（L3），Harness 约束层（L4）用来规范 Coding 的 Agent。Growth 产品体系就是绑在 Qoder 基座上的一个领域。

同一个 Qoder，绑上编程 Harness 就是编码助手，绑上 Growth CLI 就是产品控制台。