第 9 章：Agent 基座战略——不要自己造轮子

我遇到了什么问题

前八章讲完了 Agent 架构的全部演化过程。从自动化三件套（工作流 + 触发器 + 代码运行器），到 LLM 接入，到上下文工程，到 Skill/Rule/Tool/Agent，到 Harness 全景，到四大框架对比，到工作流与 Agent 融合。

但还有一个最宏观的问题没有回答：这些 Agent 能力，应该自己造还是用现成的？

我走过的弯路：

2026 年 2 月，我开始为自己的 Growth AIOS 开发 Agent 引擎。代码分别在 AiAgent 和 AiAgent.Integration 两个项目中——前者是引擎核心，后者是集成层。虽然只做了一个产品的引擎，但这个引擎本身就足够日常复杂。

后来我意识到：Agent 开发最贵的部分不是业务逻辑，是基础设施。

会话管理、记忆系统、上下文压缩、工具调用循环、重试机制、监控追踪——这些东西每个 Agent 都需要，但和具体业务无关。为每个产品重复造这些轮子，是巨大的浪费。

我做了什么决策

决策 1：用 Qoder 做基座

2026 年 6 月，也就是写这本书的时候，我做了一个策略转折：不再自研 Agent 引擎，改用 Qoder 做基座。

Qoder 已经做好了什么？

• 会话管理（Session）
• 记忆系统（Memory + Facts）
• 上下文提供者链（AIContextProvider）
• 装饰器管道（日志、重试、监控、压缩）
• 工具调用循环（FunctionInvokingChatClient）
• Skill 系统（SKILL.md 加载 + 注入）
• Rule 系统（.mdc 规则文件）
• AGENTS.md 全局上下文
• SubAgent 编排（Lead-Sub 分层）
• 多模型适配（OpenAI、Claude、DeepSeek、Ollama）

这些能力，我自己造一遍至少要半年。但 Qoder 已经做好了，而且还在持续迭代。

决策 2：产品暴露 CLI，Skill 封装 CLI

那产品自己的能力怎么接入？

答案是 CLI——命令行接口。

产品 A（Growth AIOS）
  └── CLI 命令
      ├── growth workflow list      → 列出工作流
      ├── growth workflow run <id>  → 运行工作流
      ├── growth plugin list        → 列出插件
      └── growth agent chat "..."   → Agent 对话

产品 B（视频工具）
  └── CLI 命令
      ├── video render <project>    → 渲染视频
      ├── video export <format>     → 导出视频
      └── video subtitle <file>     → 生成字幕

每个产品暴露一组 CLI 命令。然后在 Qoder 里写一个 Skill，封装这些 CLI 命令：

---
name: growth-aios
description: Growth AIOS 产品操作技能
---

# Growth AIOS 操作指南

## 可用命令
- `growth workflow list` — 列出所有工作流
- `growth workflow run <id>` — 运行指定工作流
- `growth plugin list` — 列出所有插件

## 使用场景
当用户提到"工作流"、"插件"、"自动化"等关键词时，
使用上述命令操作用户的 Growth AIOS 实例。

这样 Qoder 就知道怎么操作 Growth AIOS 了——它读 Skill 文档，知道有哪些命令，然后在需要的时候调用 CLI。

决策 3：同一个 Qoder，不同的 Harness

关键洞察：Qoder 是基座，Harness 是"皮肤"。

同一个 Qoder
  ├── 绑上编程 Harness（AGENTS.md + Rule + Skill）→ 编码助手
  ├── 绑上 Growth Harness（AGENTS.md + Rule + Skill）→ 产品控制台
  └── 绑上视频 Harness（AGENTS.md + Rule + Skill）→ 视频工具

不同的 Harness 配置，让同一个 Qoder 变成不同的"产品 Agent"。

编程场景：
  AGENTS.md → 项目架构、命名规范、依赖原则
  Rule     → C# early return、异常处理、前端 API 模式
  Skill    → create-requirement、create-csharp-module、build-desktop

Growth 场景：
  AGENTS.md → 产品模块、API 接口、配置说明
  Rule     → 工作流命名规范、插件开发规范
  Skill    → growth-workflow、growth-plugin、growth-agent

决策 4：CLI 是跨平台的"最小公约数"

为什么选 CLI 而不是 SDK/API？

因为 CLI 是跨平台的最小公约数。

• Qoder 跑在 Windows、Mac、Linux 上
• 产品可能用 .NET、Java、Python 写
• CLI 是它们之间最简单的"协议"——任何语言都能执行命令行

Qoder（任意平台）
  ↓ 执行 CLI 命令
产品 A（.NET）→ `growth workflow list`
产品 B（Java）→ `wukong user export`
产品 C（Python）→ `video render --project xxx`

不需要 SDK，不需要 API 协议，不需要网络通信。Qoder 只需要能执行命令行，就能操作任何产品。

这也是 Integration.CLI 模块的设计初衷——它是跨平台的"最小公约数"。

决策 5：为什么不用 MCP

MCP（Model Context Protocol）是 Anthropic 提出的标准协议——让 AI 模型通过统一接口访问外部工具。

听起来很好，但我没用。原因很简单：MCP 太复杂了。

用 MCP 意味着什么？

• 本地要启动一个 MCP Server 进程
• 远程要部署一个 MCP Server 服务
• 要维护 Server 的生命周期、配置、端口
• 多一个进程就多一个出故障的点

而 CLI 呢？

CLI 的优势：
  ├── 简单：就是一个命令行，不需要任何额外进程
  ├── 可预测：执行完就退出，结果就是 stdout/stderr
  ├── 零运维：不需要启动 Server、不需要管端口、不需要保活
  └── 通用：任何语言都能调用，不需要 SDK

对比一下：

	CLI	MCP
额外进程	无	需要 MCP Server
配置复杂度	零	需要 Server 配置
可预测性	高（执行→输出→退出）	低（长连接、状态管理）
故障点	少	多一个 Server 进程
适合场景	本地产品、单机操作	远程服务、跨网络

我的策略是：CLI 就够了，不需要 MCP。

命令行简单、可预测、不需要额外启动任何服务。对于本地产品的操作场景，CLI 就是最合适的方案——不是"过渡方案"，是"最终方案"。

代码里长成了什么样

整体架构

┌─────────────────────────────────────────────────┐
│                    Qoder 基座                     │
│  会话管理 + 记忆系统 + 上下文链 + 装饰器管道        │
│  工具调用循环 + Skill + Rule + AGENTS.md           │
├─────────────────────────────────────────────────┤
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
│  │ 编程      │  │ Growth   │  │ 视频     │      │
│  │ Harness  │  │ Harness  │  │ Harness  │      │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘      │
│       │              │              │              │
│       ▼              ▼              ▼              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
│  │ VS/IDE   │  │ CLI      │  │ CLI      │      │
│  │ 文件系统  │  │ growth   │  │ video    │      │
│  └──────────┘  └──────────┘  └──────────┘      │
└─────────────────────────────────────────────────┘

Skill 封装 CLI 的模式

.qoder/skills/growth-aios/
├── SKILL.md              ← 操作指南（什么时候用什么命令）
└── reference/
    ├── workflow-api.md   ← 工作流 API 参考
    └── plugin-api.md     ← 插件 API 参考

Skill 文档里写清楚：

1. 有哪些命令
2. 每个命令做什么
3. 什么时候用哪个命令
4. 命令的输出格式是什么

Qoder 读了 Skill 文档，就知道怎么操作产品。

关键认知

这一章的关键认知：

Agent 开发最贵的部分是基础设施（记忆/规则/工具/会话管理），不是业务逻辑。用现成的基座，把精力放在业务上。

我走过的弯路：为 Growth AIOS 自研 Agent 引擎。基础设施的复杂度远超预期。

正确的做法：

1. 选一个成熟的基座（Qoder）——它做好了基础设施
2. 产品暴露 CLI——最简单的跨平台接入方式
3. Skill 封装 CLI——让基座知道怎么操作产品
4. 不同 Harness = 不同产品——同一个基座，不同的"皮肤"

---

全书回顾

到这里，这本书的演化过程讲完了。让我们回顾一下整条链路：

第 1 章：自动化三件套（工作流 + 触发器 + 代码运行器）
  → 能跑确定性流程了

第 2 章：LLM 接入（会话管理 + 流式输出）
  → Agent 能"说话"了

第 3 章：上下文工程（记忆 + 检索 + 规范）
  → Agent 有"知识"了

第 4 章：Skill 与 Rule（操作流程 + 编码约束）
  → Agent 有"规矩"了

第 5 章：Tool 与 Agent（工具系统 + 多 Agent 编排）
  → Agent 能"做事"了

第 6 章：Harness 全景（EvalCheck + Monitor）
  → Agent 可"治理"了

第 7 章：四大框架对比（图/管道/安全/插件）
  → 知道了"取舍"

第 8 章：Agent Flow vs 低代码（双向融合）
  → 两条路线"统一"了

第 9 章：Agent 基座战略（CLI + Skill + Harness）
  → 不用"重复造轮子"了

从一个"本地扣子"的想法，到一个完整的 Agent 架构体系——这就是我这一年走过的路。

希望这本书对你有启发。不是告诉你"应该怎么做"，而是让你理解"为什么这样做"。

Agent 架构没有标准答案，只有问题驱动的演化。你遇到什么问题，就做什么决策，架构就长成什么样。

去吧，去演化你自己的 Agent。