在构建现代的AI应用或智能体（Agent）时，你是否曾被各种层出不穷的术语搞得晕头转向？Rules、Commands、Subagent、MCP、Skills、Modes、Hooks... 这些词在不同框架和文档中反复出现，但它们的边界却常常模糊不清，容易混淆。
本文将从工程实践的角度出发，为你系统梳理这七个核心概念的本质、职责边界以及它们在实际AI编程中的应用场景，助你构建更清晰、更健壮的智能体系统架构。
概念层次结构
从架构设计的视角来看，这七个概念可以划分为三个清晰的层次：
┌─────────────────────────────────────────┐
│ 应用层 / 编排层 │
│ (Subagent， Modes， Hooks) │
├─────────────────────────────────────────┤
│ 能力层 / 扩展层 │
│ (Skills， MCP， Commands) │
├─────────────────────────────────────────┤
│ 约束层 / 规范层 │
│ (Rules) │
└─────────────────────────────────────────┘
- 约束层：定义智能体的行为边界和规范，划清“能做什么，不能做什么”。
- 能力层：扩展智能体的功能范围，提供具体的执行手段。
- 应用层：控制复杂任务的执行流程、策略以及整体的行为模式。
1. Rules（规则）
定义
Rules 是对AI智能体行为和输出的约束规范，用于控制其在特定场景下的行为模式。它回答了“应该或不应该做什么”的问题。
核心特征
- 声明式：描述目标状态或限制条件，而非具体的执行步骤。
- 可组合：多个规则可以叠加使用，共同形成一套复杂的行为策略。
- 作用域明确：通常绑定到特定的任务、场景或能力模块。
典型应用场景
# 示例：代码审查规则
- 禁止使用已废弃的API
- 安全漏洞必须高亮标注
- 性能问题需提供优化建议
- 代码风格需符合团队规范
技术实现
- 硬规则：基于规则引擎或逻辑判断，强制执行（例如格式检查、安全扫描）。
- 软规则：作为提示词（Prompt）的一部分，用于指导AI的优先级和决策倾向（例如语气、写作风格）。
与其他概念的区别
| 概念 |
区别 |
| Rules |
描述 “约束和边界” ，是限制性的。 |
| Commands |
描述 “操作指令” ，是执行性的。 |
| Skills |
描述 “能力单元” ，是功能性的。 |
2. Commands（命令）
定义
Commands 是可被智能体直接调用的、封装了具体动作或任务的操作指令。它代表了一个明确的“做什么”。
核心特征
- 命令式：明确的动作触发，直接导致状态改变或结果产生。
- 参数化：接收输入参数，并返回执行结果。
- 原子性：通常设计为完成一个明确、独立的动作。
典型应用场景
// 文件操作命令
interface FileCommands {
readFile(path: string): Promise<string>
writeFile(path: string， content: string): Promise<void>
deleteFile(path: string): Promise<void>
}
// LLM交互命令
interface LLMCommands {
complete(prompt: string): Promise<string>
chat(messages: Message[]): Promise<Message>
}
技术实现
- 同步命令：调用后立即返回结果（例如计算、内存查询）。
- 异步命令：返回
Promise 或 Stream（例如网络请求、耗时任务）。
与其他概念的区别
| 概念 |
区别 |
| Commands |
单次操作，通常无状态，注重执行结果。 |
| Skills |
知识的封装，可复用，注重能力表达。 |
| MCP |
远程能力的接口协议，注重服务调用。 |
3. Subagent（子代理）
定义
Subagent 是一个具有特定领域专长的、相对独立的智能体实例。它就像团队中的专家，被委托处理主智能体不擅长或需要深度分析的特定类型任务。
核心特征
- 领域专精：在特定领域内具备更深度的知识和推理模式。
- 独立性：拥有独立的上下文、工具集和决策逻辑。
- 可委托：主智能体可以将复杂任务分解后，委托给相应的子代理处理。
典型应用场景
// 领域专家Subagent
const subagents = {
frontend: new FrontendExpertSubagent()， // 前端工程专家
backend: new BackendExpertSubagent()， // 后端工程专家
security: new SecurityAuditorSubagent()， // 安全审计专家
documentation: new DocWriterSubagent() // 技术写作专家
}
// 主Agent委托任务
const result = await subagents.frontend.analyzeComponent(component)
技术实现
- 模型选择：不同的子代理可能使用为其领域优化过的不同模型。
- 工具集差异：每个子代理配备其领域专属的工具集。
- 上下文隔离：避免不同子代理之间的信息相互污染，保证决策独立性。
与其他概念的区别
| 概念 |
区别 |
| Subagent |
完整的AI实体，具备独立的推理和决策能力。 |
| Skills |
知识和能力的“描述书”，需要被调用才能执行。 |
| Commands |
单次操作接口，不具备自主性。 |
4. MCP (Model Context Protocol)
定义
MCP 是一种标准化的协议，用于在大型语言模型（LLM）与外部服务、工具或数据源之间建立上下文感知的连接。它解决了工具集成“各自为政”的问题。
核心特征
- 协议标准化：定义统一的接口规范、消息格式和通信方式。
- 服务发现：支持动态发现、加载和调用外部能力。
- 安全边界：提供清晰的权限控制和访问边界管理。
典型应用场景
// MCP Server接口示例
interface MCPServer {
// 工具定义
listTools(): Tool[]
callTool(name: string， args: any): Promise<ToolResult>
// 资源访问
listResources(): Resource[]
readResource(uri: string): Promise<ResourceContent>
// 提示词模板
listPrompts(): Prompt[]
getPrompt(name: string): Promise<PromptContent>
}
技术实现
- 传输层：支持 stdio、SSE (Server-Sent Events)、HTTP 等多种传输方式。
- 消息格式：通常基于 JSON-RPC 或自定义的轻量级消息协议。
- 生命周期管理：包含连接建立、心跳检测、断线重连等机制。
与其他概念的区别
| 概念 |
区别 |
| MCP |
协议层，定义通信规范和接口标准。 |
| Skills |
知识层，定义领域能力和最佳实践。 |
| Commands |
接口层，定义具体操作和调用方式。 |
5. Skills（技能）
定义
Skills 是封装了特定领域知识、工具使用方法和行业最佳实践的可复用能力单元。你可以把它理解为智能体的“技能包”或“专业知识库”。
核心特征
- 知识密集：不仅包含操作，还内嵌了该领域的推理模式和知识。
- 工具绑定：明确声明完成该技能所需的具体工具集。
- 可组合：多个基础技能可以组合成更复杂的复合技能。
典型应用场景
# SKILL.md - 前端工程技能
---
name: frontend-engineering
version: 1.0.0
description: 前端工程的代码生成、审查和重构
tools: [playwright， eslint， prettier]
---
# 使用场景
- 生成React组件代码
- 审查前端代码质量
- 重构CSS样式
- 性能优化建议
# 约束规则
- 遵循React最佳实践
- 使用TypeScript强类型
- 符合WCAG无障碍标准
技术实现
- 元数据驱动：通常使用 YAML frontmatter 来定义技能的属性。
- Prompt模板：包含系统提示词、少样本示例（Few-shot）和任务指令。
- 工具声明：声明执行该技能所必需的工具和相应的权限。
与其他概念的区别
| 概念 |
区别 |
| Skills |
知识封装，包含领域专业性和最佳实践。 |
| Commands |
操作接口，仅定义如何调用某个功能。 |
| Subagent |
完整实体，具备自主推理和决策能力。 |
6. Modes（模式）
定义
Modes 是智能体在不同场景或任务类型下的整体行为策略和运行配置的集合。通过切换模式，可以改变智能体的“性格”或“工作状态”。
核心特征
- 状态切换：在不同模式间切换，全局性地改变智能体的行为倾向。
- 配置差异化：每个模式有其专属的规则集、工具集和策略参数。
- 上下文隔离：切换模式时，可能会清空或重置部分上下文，以确保状态纯净。
典型应用场景
// Agent模式定义
const agentModes = {
development: {
tools: [file， git， terminal]，
rules: [verbose-logging， allow-experiments]，
maxTokens: 16000
}，
production: {
tools: [read-only]，
rules: [safety-first， no-experiments]，
maxTokens: 4000
}，
debug: {
tools: [diagnostics， profiler]，
rules: [detailed-logs， step-by-step]，
maxTokens: 32000
}
}
技术实现
- 状态机：使用状态机来管理模式切换的逻辑和条件。
- 配置热加载：支持在运行时动态切换模式配置。
- 权限降级：例如在生产模式下，禁用所有具有写入或高风险的操作。
与其他概念的区别
| 概念 |
区别 |
| Modes |
行为配置，定义整体策略和执行环境。 |
| Rules |
行为约束，定义具体规则和边界条件。 |
| Skills |
能力单元，定义可用能力和领域知识。 |
7. Hooks（钩子）
定义
Hooks 是在特定事件或生命周期节点自动触发的扩展点。它允许开发者在核心执行流程中插入自定义逻辑，是实现横切关注点（如日志、监控、权限）的利器。
核心特征
- 事件驱动：绑定到特定事件（例如任务开始、工具调用前、错误发生后）。
- 可插拔：可以动态地注册和注销，不影响核心逻辑。
- 副作用：主要用于执行监控、日志记录、权限检查、数据转换等具有副作用的操作。
典型应用场景
// 生命周期Hooks
const hooks = {
beforeCommand: async (command， args) => {
logger.log(`Executing: ${command.name}`， args)
await security.checkPermission(command.name)
}，
afterCommand: async (command， result) => {
metrics.record(command.name， result.duration)
if (result.error) {
alerting.notify(command.name， result.error)
}
}，
onError: async (error， context) => {
telemetry.trackError(error， context)
await fallback.recover(error， context)
}
}
技术实现
- 中间件模式：在处理链中插入拦截器，在执行前后进行干预。
- 事件总线：采用发布-订阅模型，实现Hook注册与触发的解耦。
- 异步执行：支持异步Hook，避免阻塞主流程的执行。
与其他概念的区别
| 概念 |
区别 |
| Hooks |
事件处理，用于拦截和扩展特定流程。 |
| Commands |
直接调用，用于执行具体任务。 |
| Rules |
行为约束，用于控制Agent行为。 |
概念关系图
理解了单个概念后，我们通过一张关系图来看看它们是如何协同工作的：
┌─────────────┐
│ Agent │
└──────┬──────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Modes │◄─┤ Hooks │◄─┤ Rules │
└────┬────┘ └─────────┘ └─────────┘
│
┌────────┴────────┐
▼ ▼
┌─────────┐ ┌─────────┐
│Subagent │ │ Skills │
└────┬────┘ └────┬────┘
│ │
└───────┬────────┘
▼
┌──────────┐
│Commands │
└─────┬────┘
▼
┌─────────┐
│ MCP │
└─────────┘
解读：Agent 是核心。Rules 约束其行为，Hooks 监听其事件，Modes 定义其状态。Agent 的能力由 Skills（知识）和 Subagent（专家）提供，而这些能力最终通过 Commands（操作）来执行，Commands 又可以借助 MCP 协议调用外部服务。
实战应用：组合使用这些概念
场景：构建一个代码审查Agent
理论说再多，不如看一个具体的例子。假设我们要构建一个智能代码审查Agent，看看上述概念如何各司其职：
// 定义代码审查Agent
class CodeReviewAgent {
// 模式配置
modes = {
quick: { rules: [basic-syntax]， tools: [linter] }，
deep: { rules: [security， performance]， tools: [linter， scanner] }
}
// 注册Hooks
hooks = {
beforeReview: [logStart， checkPermissions]，
afterReview: [generateReport， notifyTeam]
}
// 可用Skills
skills = {
frontend: loadSkill(frontend-engineering)，
backend: loadSkill(backend-security)，
documentation: loadSkill(tech-writing)
}
// 子专家Subagents
subagents = {
security: new SecurityExpertSubagent()，
performance: new PerformanceOptimizerSubagent()
}
// MCP连接的外部工具
mcpClients = {
github: connectMCP(github://api)，
sonarqube: connectMCP(sonarqube://server)
}
async review(code: string， mode: quick | deep) {
// 1. 切换模式（如“深度审查”模式）
await this.switchMode(mode)
// 2. 触发beforeReview Hooks（记录日志，检查权限）
await this.hooks.beforeReview.forEach(h => h())
// 3. 根据代码类型选择Skill（如使用前端工程技能包）
const skill = this.detectSkill(code)
await skill.execute(code)
// 4. 委托给Subagent进行深度分析（如安全专家分析漏洞）
const securityIssues = await this.subagents.security.analyze(code)
// 5. 调用MCP工具获取外部数据（如从GitHub拉取PR元数据）
const metadata = await this.mcpClients.github.getPRMetadata()
// 6. 触发afterReview Hooks（生成报告，通知团队）
await this.hooks.afterReview.forEach(h => h())
}
}
在这个例子中，Modes 决定了审查的深度，Hooks 管理了审查过程的监控和报告，Skills 提供了针对不同技术栈的审查知识，复杂的专项分析（安全、性能）被委托给 Subagent，而 MCP 则打通了与外部系统（GitHub， SonarQube）的通道。所有这些，都建立在基础的 Commands（如文件读取、API调用）之上，并受到 Rules（编码规范、安全红线）的约束。
最佳实践
1. 合理选择概念边界
- 单一职责：确保每个概念只解决一类核心问题，避免功能混杂。
- 层次分明：明确概念间的层次关系，避免“既当裁判又当运动员”的混乱设计。
- 可组合性：在设计之初就考虑如何让这些概念像乐高积木一样灵活组合。
2. 避免过度设计
- 从最简单的
Commands + Rules 开始，随着复杂度上升再按需引入 Skills、Hooks。
- 并不是每个项目都需要
Subagent 或 MCP。评估其带来的价值是否大于增加的复杂度。
- 优先使用框架或社区提供的内置能力，而不是一切从头造轮子。
3. 文档化设计决策
在代码注释或架构文档中，记录为什么选择某个概念而非其他。例如：
## 为什么使用Subagent而不是Skill？
-**决策理由**：安全审计需要完全独立的推理过程、专用工具集和上下文隔离，以避免被主任务干扰。
-**替代方案**：曾考虑用`Security Skill` + 严格`Rules`，但无法保证思维过程的隔离性。
-**权衡**：引入了`Subagent`增加了资源开销和编排复杂度，但换来了更高的安全性和模块化。
4. 测试策略
针对不同概念，采用不同的测试重点：
- Rules测试：验证约束条件是否在各类边界情况下都被正确触发和执行。
- Commands测试：对每个命令进行单元测试，覆盖正常、异常和边界输入。
- Skills测试：进行集成测试或端到端测试，验证技能在真实或模拟场景中的整体表现。
- MCP测试：重点测试协议兼容性、网络异常处理和服务降级能力。
常见误区
误区1：混淆Commands和Skills
错误：把需要领域知识判断的复杂操作（如“优化这段SQL查询”）简单封装成一个 Command。
正确做法：简单、原子性的操作用 Command（如“执行SQL查询”）。涉及推理、选择和最佳实践应用的复杂能力，应封装成 Skill（如“数据库查询优化技能”）。
误区2：过度使用Subagent
错误：为每一个简单的分类或过滤任务都创建一个 Subagent。
正确做法：Subagent 应用于需要独立、深度推理的场景。对于简单的规则判断或查询，使用 Skill 或 Command 组合即可。
误区3：忽略Hooks的作用
错误：将日志、监控、权限校验等代码直接硬编码在核心业务逻辑中。
正确做法：使用 Hooks 将这些“横切关注点”解耦出来。这使核心逻辑更清晰，且功能更易复用和维护。
误区4：Mode配置冗余
错误：为每一个细微的参数调整（如“输出详细日志”）都创建一个新的 Mode。
正确做法：Mode 应用于定义整体的、策略性的行为差异（如“开发模式” vs “生产模式”）。细粒度的调整应通过 Rules 或命令参数来实现。
总结
在智能体（Agent）与AI应用开发中，理清这七大核心概念是构建健壮系统架构的关键：
- Rules：划定行为的“交通规则”和“安全红线”。
- Commands：提供可直接执行的“具体动作”。
- Subagent：引入专注的“领域专家”。
- MCP：建立连接外部世界的“标准化桥梁”。
- Skills：封装可复用的“专业知识包”。
- Modes：切换整体的“行为状态”和“策略环境”。
- Hooks：插入流程中的“监控探头”和“扩展插件”。
理解它们之间的本质区别与联系，能帮助开发者在正确的抽象层次上解决问题，避免架构混乱。最终目标不是使用所有概念，而是根据实际需求，灵活、恰当地选择和组合它们，从而设计出既强大又优雅的AI系统。如果你对这类系统设计话题感兴趣，欢迎在云栈社区与更多开发者交流探讨。
发表于 昨天 18:44
|
查看: 2|
回复: 0
