用"五组件架构"构建你的 AI Agent 系统

当你的 AI Agent 从一个 prompt 文件膨胀到几十个文件时，你需要的不是更多 prompt，而是一套架构。

写在前面

2024 年以来，"AI Agent" 成了技术圈最热的关键词之一。大量团队开始尝试用 LLM 驱动的 Agent 来自动化各种工作流——写代码、做分析、跑测试、管项目。

但一个尴尬的现实是：大多数 Agent 项目都停留在"一个超长 prompt + 几个工具调用"的阶段。一旦需求变复杂、涉及多人协作或多场景复用，整个系统就会陷入 prompt 意面代码——到处是复制粘贴、边界不清、改一处崩三处。

我花了几个月时间构建一个相对完整的 AI Agent 系统，踩了不少坑之后，沉淀出一套"五组件架构"。本文分享这个架构的设计思路和背后的取舍。

一、先定义问题：AI Agent 系统到底在管理什么？

如果类比传统软件：

• 传统软件管理的是代码和数据
• AI Agent 系统管理的是指令和上下文

你的 Agent 系统本质上是一个"指令编排层"——它告诉 LLM 在什么场景下、扮演什么角色、用什么方法、按什么流程、遵守什么约束来完成任务。

二、五组件模型

经过多次迭代，我把 Agent 系统的构成拆分成五个正交的组件类型：

┌──────────────────────────────────────────────────┐
│                 AI Agent 系统                      │
├──────────┬──────────┬──────────┬────────┬────────┤
│  Agent   │  Skill   │ Command  │  Rule  │  MCP   │
│  (角色)  │  (能力)  │  (流程)  │ (约束) │ (集成) │
├──────────┼──────────┼──────────┼────────┼────────┤
│ 决定由   │ 决定用   │ 决定按   │ 定义   │ 连接   │
│ 谁来做   │ 什么方法 │ 什么步骤 │ 什么边界│ 哪些系统│
└──────────┴──────────┴──────────┴────────┴────────┘

2.1 Agent（角色）—— "谁来做"

Agent 是一个测试视角单元，拥有明确的角色目标和决策策略。

关键区分——Agent 不是：

• 不是一个子进程
• 不是一堆 Skill 的集合
• 不是一个 Command 的别名
• 不是一个 prompt 模板

如果它没有独立的目标函数和决策策略，那它只是另一个 Agent 的一种模式，不是独立的 Agent。

每个 Agent 需要定义：

• 身份：我是谁，我的专业领域是什么
• 目标：我的成功标准是什么
• 决策策略：遇到模糊情况时我怎么做
• 交接协议：我把什么格式的产物交给谁

2.2 Skill（能力）—— "用什么方法"

Skill 是可复用的、业务无关的能力单元。它描述的是"怎么做某件事"的方法论。

Skill 是这个架构中最持久的资产。Agent 会换，Command 会演化，外部工具会被替换，但好的 Skill 可以长期复用。

Skill 的黄金法则：如果换一个项目就不能用了，那它不是 Skill，而是 Playbook。

2.3 Command（流程）—— "按什么步骤"

Command 是面向用户的工作流编排。它把多个 Skill 串联成一个端到端的流程。

核心原则：Command 编排 Skill，但不实现能力逻辑。如果你发现 Command 里在做具体的分析、生成、判断，那它应该被抽取成 Skill。

2.4 Rule（约束）—— "什么边界"

Rule 是跨 Agent、跨 Command 的约束条件。它们不实现能力，而是约束能力的行为。

一个特别有效的模式是双层规则架构：

• 通用规则：所有场景都必须遵守，比如"输出格式"、"质量底线"
• 领域规则：只在特定领域激活，通过一个配置文件控制

2.5 MCP（集成）—— "连接哪些系统"

MCP（Model Context Protocol）负责连接外部系统——项目管理工具、代码仓库、文档系统、监控平台等。

它的角色很清晰：提供数据进来，推送结果出去。不承载业务逻辑。

三、为什么是五个，不是三个或七个？

五个组件对应五个正交的关注点：

四、这套架构的实际代价

引入的成本：

• 初始学习曲线——新人需要理解五种组件各自的边界
• 文件数量增多——一个完整的系统可能有几十个 Markdown 文件
• 需要约定规范——没有严格的命名和结构约定，很快就会混乱

获得的收益：

• 可维护性：改一个 Skill 不影响其他组件
• 可复用性：同一个 Skill 被多个 Command 共用
• 可协作性：不同人负责不同层
• 可测试性：每个组件可以独立验证
• 可审计性：版本化的文件天然支持 diff、review、回滚

五、一个反直觉的发现

构建这个系统过程中最反直觉的发现是：整个代码仓库里没有一行可执行代码。

全部是 Markdown 定义、JSON Schema、YAML 配置。这些文件不是"文档"——它们就是系统本身。LLM 直接消费这些文件作为运行时指令。

这意味着：

• 你可以用 git diff 审查 Agent 行为的变更
• 你可以用 PR 流程管理 Skill 的升级
• 你可以用 Semantic Versioning 管理能力的演进
• 你可以给 prompt 写 CHANGELOG

六、从这里开始

如果你正在构建 AI Agent 系统，我建议的起步路径：

1. 先定义 2-3 个 Skill，而不是先写 Agent。Skill 是最稳定的资产
2. 从一个 Command 开始，串联这些 Skill 成一个端到端流程
3. 当你发现 prompt 里有"当XX情况时"这样的条件判断，把它抽取成 Rule
4. 当你需要第二个"视角"来处理同一个任务时，才引入新的 Agent
5. 当手动复制粘贴外部系统数据感到痛苦时，才接入 MCP

不要一上来就搭全套架构。让复杂度跟着需求自然生长。

这是"AI Agent 工程化实践"系列的第一篇。后续文章将深入 Skill 设计哲学、多 Agent 协作模式、以及 AI 与人类的分工模型。