---
url: 'https://aisee.wiki/learn/agent-orchestration/index.md'
---
# Agent 的核心组成：Memory、Skill、MCP、Tool、Hook 如何配合

Memory、Skill、MCP、Tool、Hook 不是同一层能力。Memory 负责上下文，Skill 负责复用流程，MCP 负责连接外部能力，Tool 负责执行动作，Hook 负责生命周期检查和约束。

## 核心结论

真正重要的不是记住这五个名词，而是理解它们在一次任务里怎么接棒：

* `Memory`
  负责让 Agent 带着上下文进入任务。
* `Skill`
  负责把稳定流程套到合适任务上。
* `Tool`
  负责真正执行动作并产生结果。
* `MCP`
  负责把外部系统能力接进来，成为可用入口。
* `Hook`
  负责在关键节点做检查、注入和拦截。

如果把这五个概念都看成“差不多的能力”，后面就很容易把 Tool 当 Skill、把 MCP 当 Agent、把 Hook 当业务逻辑。

## 职责边界

| 概念 | 负责什么 | 不负责什么 |
|---|---|---|
| Memory | 保留和调取上下文、偏好、项目长期决策 | 不替代事实核查 |
| Skill | 复用稳定流程、模板、脚本和经验 | 不替代项目规则和验证 |
| MCP | 连接外部系统，把能力暴露给 Agent | 不等于无限授权 |
| Tool | 执行具体动作并返回结果 | 不判断业务最终正确性 |
| Hook | 在生命周期节点自动检查、注入、拦截 | 不替代人工判断 |

这张表最值得反复看的地方不是“负责什么”，而是“它不负责什么”。很多协作失控，恰恰是因为把某一层能力误当成了另一层。

## 以 Codex 智能体为例

一次 Codex 任务通常这样流动，但关键不在步骤数量，而在每一步是谁接手：

1. 用户给出当前目标和约束。
2. Codex 读取当前会话、项目规则、项目文件和相关 memory。
3. 如果任务匹配某个 Skill，就按 Skill 的稳定流程组织下一步。
4. 模型规划动作，并通过 Tool 读文件、改文件、跑命令或查资料。
5. 如需连接外部系统，Tool 的来源可能是 MCP server。
6. Hook 在工具调用、修改后、提交前等关键节点做检查。
7. 最后输出结果、diff、验证和后续建议。

这里可以把它们的接棒关系理解成一条主线：

* `Memory` 先让 Agent 读到对的背景
* `Skill` 再告诉它这类任务通常怎么推进
* `Tool` 真正把计划变成动作
* `MCP` 让这些动作能够延伸到外部系统
* `Hook` 则在关键时刻提醒、检查和拦截

## 完整任务流转

把这张图按一次真实任务去读，会更容易理解：

1. `用户目标进入当前任务`
   这里决定的是方向，不是实现细节。
2. `上下文被装载`
   当前会话、项目规则、项目文件、项目记忆一起形成判断材料。
3. `流程被收敛`
   如果这类任务已经有稳定做法，就由 Skill 把步骤拉回到熟悉轨道。
4. `动作开始发生`
   Tool 负责读、写、跑、查；只要涉及外部系统，MCP 可能在这一步提供能力入口。
5. `结果回到下一轮`
   stdout、diff、截图、报错等结果重新进入模型判断。
6. `关键节点被检查`
   Hook 保证高风险动作、验证和收尾不会被轻易跳过。

所以这五个概念不是并列展示品，而是在任务链里前后接棒。

## 常见误解

| 误解 | 更准确的理解 |
|---|---|
| MCP 就是 Agent | MCP 是连接层，Agent 还需要模型、上下文、工具和控制循环 |
| Tool 等于 Skill | Tool 执行动作，Skill 封装流程 |
| Hook 能解决所有安全问题 | Hook 只能覆盖明确规则，仍需要权限设计和人工审查 |
| Memory 永远可靠 | Memory 会过期，必须被当前文件和官方文档校验 |
| Skill 只是更长 prompt | Skill 可以包含脚本、模板、资产和操作步骤 |

这些误解的共同问题是：把不同层的职责揉成了一层。一旦揉在一起，就会不知道该把问题交给哪一层解决。

## 工程落地顺序

从单次 AI Coding 走向团队流程时，建议按这个顺序建设：先写项目规则，再沉淀 memory；先让 Tool 调用可审查，再接入 MCP；先手动验证关键流程，再用 Hook 自动化；最后把稳定流程做成 Skill。

这个顺序背后的逻辑是：

* 先把边界写清楚，再谈自动化
* 先让动作可审查，再接外部能力
* 先让流程稳定，再沉淀成 Skill

如果顺序反过来，比如先接很多外部系统、先做一堆自动化、最后才补规则和验证，工程复杂度通常会先失控。