2026 年 AI Agent 上下文管理：rules、skills、MCP、subagent 与 hooks

一句话总结：大多数新出现的 Agent 术语，其实只是在用不同方式回答两个问题——助手应该预先记住什么，又应该在任务真正需要时才加载或调用什么。

Agent 生态在很短的时间里堆积了大量名词：rules、命令、MCP 服务器、工具、模式、hooks、subagent、skills。每一个都解决了真实的问题。但放在一起，它们会让一个简单的问题显得异常棘手："我该如何给助手提供恰当的上下文，又不至于让每次运行都变成一堆繁琐的配置？"

要用好 Agent，你并不需要把整套体系都背下来。真正有用的心智模型要小得多：

1. 静态上下文是助手在开始之前就该知道的内容。
2. 动态上下文是助手可以在任务真正需要时去发现、加载或调用的内容。
3. 确定性护栏是你希望每次都以完全相同方式执行的检查。

对大多数 Agent 运营者来说，到这里就够了。构建者则需要其余的术语，才能把整套体验干净利落地打包起来。

2026 年的快速答案

AI Agent 上下文管理，就是决定助手在任务开始前应该知道什么、又该只在需要时才去发现什么的实践。在 2026 年，最清晰的划分是：

• 用 rules 承载稳定、始终相关的指令；
• 用 skills 承载可复用、可按需加载的任务工作流；
• 用 MCP 服务器 承载实时工具、数据、OAuth 和外部系统；
• 用 hooks 承载围绕工具调用或编辑的确定性检查；
• 只在工作流需要隔离、并行，或需要一个明显不同的运行状态时，才使用subagent和模式。

对大多数团队来说，务实的配置方式不是"把每一个 Agent 抽象都学一遍"，而是"把 rules 保持精简、安装合适的 skills、连接一个 MCP 服务器，剩下的让助手动态加载"。

简单模型

陷阱在于把这些当作八个互不相干的产品。它们实际上是同一个上下文管理故事里的不同层级。

rules、skills 与 MCP 的取舍

最有意图的搜索问题通常不是"Agent 有哪些功能？"，而是"这段上下文该放在哪里？"下面给出简短答案。

这种划分之所以重要，是因为上下文如今已经是一个产品层面。臃肿的提示词会让助手更慢、更不可靠。而一个打包良好的工作流，能让助手从精简起步，再在任务需要时加载相关的 skill、工具 schema 或证据来源。

真正的搜索意图

搜索"rules vs skills vs MCP"或"Claude Code skills subagents hooks"的人，通常并不是在问协议层面的冷知识。他们是在为手头已有的东西寻找归宿：

• 一份很长的 AGENTS.md、CLAUDE.md 或 Cursor 规则文件；
• 一段反复复用的提示词；
• 一个想让助手运行的 shell 脚本或检查器；
• 一个工具太多的 MCP 服务器；
• 一套希望所有 Agent 客户端都能共享的团队工作流；
• 一条非工程师也能跟着走、不用翻五页文档的安装路径。

这意味着文章必须回答两个层面。先定义术语，再展示路由决策：rules 用于持久上下文，skills 用于工作流，MCP 用于实时能力，hooks 用于确定性事件，subagent 用于隔离的工作。

2026 年的术语对照表

不同客户端用的标签略有差异，但底层职责正在趋同。

这正是术语显得嘈杂的原因：每个平台都暴露出同一套控制平面的略微不同的切片。真正有用的问题不是"哪个术语是通用的？"，而是"这段上下文的职责是什么？"

为什么 rules 最先出现

早期的编码 Agent 工作流需要一个地方来存放模型不该忘记的东西。仓库约定、业务规则、测试命令、包管理器偏好、命名约束、"不要手动编辑生成的文件"——这些都该放进助手经常会看到的文件里。

这就是 rules 的职责。在很多工具里，它表现为 AGENTS.md、项目规则、记忆文件或工作区指令。rules 的优势在于可靠：在助手开始猜测之前，它们就已经在那儿了。它的劣势在于成本：如果文件膨胀成一本手册，那么每次对话都从一本手册开始,哪怕任务只需要其中一段。

好的 rules 应该简短、持久、信号密度高。它们应当描述跨越众多任务都成立的约束：

• 不能破坏什么；
• 真相来源在哪里；
• 哪些命令可以验证常见的改动；
• 助手必须保留的产品语言；
• 团队已经踩过的反复出现的错误。

糟糕的 rules 则试图变成一本涵盖所有可能任务的手册。这会造成静态上下文膨胀：更多 token、更多相互冲突的指令，也给模型留下更多锚定在无关细节上的空间。

为什么会出现命令

当团队开始用 Agent 做真正的工作后，下一个需求就显而易见了："我每周都要跑同一段提示词,能不能把它打包？"

这就是命令。命令通常是你显式调用的一段提示词,常通过斜杠命令或菜单项触发。对于用户清楚知道该何时运行的工作流,它非常合适：

• 起草一份 PR 描述；
• 准备一份变更日志；
• 跑一遍发布清单；
• 总结当前的 diff；
• 制定一个迁移计划；
• 把一条支持工单变成一个 issue。

命令在"始终生效"的意义上并不算真正的"上下文"。它们是可复用的工作指令。如果说 rules 是贴在助手桌上的便签，那么命令就是你按下的一个按钮。

命令与 skills 的取舍

命令和 skills 之所以有重叠，是因为两者都可以从 Markdown 指令起步。区别通常在于触发方式和配套材料的多少。

如果一个工作流只是一个按钮，就让它保持命令的形态。如果它教会助手如何完成某项任务,并且可能需要示例、模板、脚本或参考文档,那就把它做成 skill。

为什么 MCP 服务器改变了格局

rules 和命令都是文本。Agent 还需要能力。

MCP，即 Model Context Protocol，为助手提供了一种连接外部工具与数据的标准方式。它不再要求每个客户端去硬编码一个集成,而是由 MCP 服务器暴露一个工具面,让兼容的助手去调用。

这一点之所以重要,有三个原因：

1. 实时数据： 助手可以读取当前记录,而不必依赖记忆。
2. OAuth 与授权： 用户可以登录到连接器背后的服务。
3. 共享的集成形态： 同一个服务器可以支持多个兼容 MCP 的客户端。

但 MCP 也带来了一个上下文问题。如果每个已连接的服务器都暴露几十个带长描述的工具,助手可能会仅仅为了搞清楚有哪些工具,就耗费过多上下文。Cursor 的动态上下文工作正是描述了这种压力：预先加载得更少,再让 Agent 在需要时去查找相关的工具或 skill。

这才是重要的转变：MCP 不是"更多提示词"。MCP 是一种给助手赋予能力的方式,而无需把所有工具细节都塞进第一条消息里。

MCP 的工具、资源与提示词

MCP 常被描述为"给 Agent 的工具",但这套协议远不止"模型可以按的一个按钮"。一个 MCP 服务器可以暴露多种上下文：

对大多数产品文案来说,"MCP 服务器"就够用了。但对构建者而言,这种区分很重要：并非每一段上下文都该是一个可调用的工具。静态参考资料可能更适合放进资源或 skill 参考文件里。而一个实时、经用户授权的操作,才该放进工具里。

为什么 skills 正在成为中心

skills 介于指令和代码之间。

一个 skill 可以是一份紧凑的操作手册："当用户要求估算 KOL 报价时,收集这些公开信号,套用这些置信度规则,然后返回这张表。"它也可以包含脚本、参考文件、资源、模板和示例。重点不在于每个 skill 都很花哨,而在于 skill 可以在相关时被发现并加载,而不是永远占据每一个提示词。

这让 skills 成为流程化知识最干净的答案：

• rules 说明什么必须始终成立。
• skills 说明如何完成一项可复用的工作。
• MCP 在工作需要证据时提供实时工具和数据。

对 UnifAPI 来说,这种区分就是产品架构本身。营销人员不该一开始就纠结该调用哪个端点,而应从一个任务出发：SEO 审计、AI 可见度检查、创作者短名单、竞品简报、内容机会调研,或本地排名扫描。UnifAPI 的 Skill 给助手提供工作流,UnifAPI 的 MCP 服务器给它提供公开数据操作,用户最终拿到一份有证据支撑的简报。

UnifAPI 的相关指南对产品各层有更深入的讲解：

• Agent First 架构 解释 Agents、Skills、MCP 和 API 如何协同。
• 面向营销 Agent 的 SKILL.md 操作手册 解释为什么任务工作流该放进可加载的操作手册里。
• 用 Skills 和 MCP 分发 Agents 解释插件式安装如何把工作流和连接路径捆绑在一起。

subagent 的位置

当一次对话需要多条专注的工作线时,subagent 就派上用场了。

例如,一个 worker 可以检查当前的 API 契约,另一个读文档,再一个核对某条 UI 路径,而主助手负责协调结果。这种隔离之所以有价值,是因为每个 worker 都获得了更小、更专注的上下文窗口。

代价是开销。subagent 需要启动、收集上下文、运行工具并汇报。它们可能比直接让主助手干活花费更多 token 和时间。它们最适合复杂或可并行的工作,而非每一个小任务。

实际操作中,大多数运营者并不需要手动创建 subagent。一个好的 Agent 客户端能自行判断何时该委派或并行某项任务。如果你在打包一款产品体验,subagent 是实现工具,而不是用户需要最先学会的东西。

模式的位置

模式让 Agent 的行为变得可见。

一个规划模式可能会限制写入、倾向于提问和讨论架构,并显示规划相关的控件。一个构建模式可能允许编辑和运行测试。一个审查模式可能优先呈现发现项和行号引用。模式不只是一段提示词;它往往是指令、工具权限、UI 元素和提醒的集合。

当用户意图会改变允许的行为时,模式很有用。但当它变成用户在干活之前还得先理解的另一套分类法时,它的用处就打了折扣。

hooks 的位置

hooks 是确定性的。这是关键区别。

助手或许会记得运行测试,而 hook 可以在每次文件编辑后总是运行一项检查。助手或许会记得不去调用危险命令,而 hook 可以在命令执行前拦截它。助手或许会总结一次会话,而 hook 可以在会话结束时持久化元数据。

把 hooks 用于那些无论模型"心情"如何都该以相同方式发生的事情：

• 在敏感的工具调用前阻止或询问；
• 在编辑后格式化文件；
• 捕获对话记录或指标；
• 在 shell 或 MCP 执行前强制执行策略；
• 在 subagent 完成时触发一次后续检查。

不要把 hooks 当作任务知识的替代品。hook 可以强制执行、记录或转换。而解释如何做工作,应该交给 skill。

运营者视角：停在两个想法上

如果你只是用 Agent 来完成工作,那么这套术语可以被压缩：

其余的通常都在幕后。

这正是为什么最新的 UnifAPI MCP 配置页 是围绕"选择你的 Agent"而非"学习协议"来设计的。它先展示受支持的客户端路径：

• Claude 和 ChatGPT 的自定义 MCP 应用使用带 OAuth 的连接器式配置。
• Claude Code、OpenClaw 和 Hermes 可以安装一个插件,把 Skills 和公开数据 MCP 一并带来。
• Cursor、VS Code 及其他客户端可以使用各自支持的 MCP 配置或深链路径。

用户不该被迫去判断某个工作流到底是"rules 加命令加 MCP 也许再加一个 subagent"。他们应该选择自己已经在用的助手,连接一次,然后运行自己需要的营销 Agent 或 skill。

一个迁移示例

假设你的团队有一份巨大的项目指令文件：

AGENTS.md / CLAUDE.md
- package manager rules
- product positioning
- "how to run SEO audits"
- "how to price KOLs"
- MCP setup notes
- API endpoint descriptions
- release checklist
- "always run lint after editing"
- browser troubleshooting notes

这份文件试图同时扮演五种不同的角色。一个更清晰的 2026 年划分应该是这样：

收益不只是整洁。助手从更少的无关文本起步,工作流更易于更新,用户也能在不理解每一层的情况下安装或运行恰当的单元。

构建者视角：把复杂性打包

如果你在构建一款 Agent 产品或内部 Agent 栈,这套术语就很重要,因为每一层都有自己的职责：

产品问题不是"支持每一种抽象",而是让恰当的抽象在恰当的时机消失于无形。

对 UnifAPI 来说,这意味着：

1. Agents 是面向用户的角色。 SEO Agent、AI Visibility Agent、Content Strategy Agent 和 Competitive Intelligence Agent 描述的是要做的工作。
2. Skills 是工作流包。 每一个都是一份 SKILL.md 操作手册,载明任务、边界、输出形态和证据规则。
3. MCP 是连接路径。 助手拿到的是 list_operations、get_operation 和 call_api,而不是一大堆扁平的、端点专属的工具。
4. API 是证据层。 SEO、GEO、Browser、社交、新闻和公司记录始终保持结构化、可引用。
5. MCP 配置页 隐藏了配置摩擦。 选客户端、跟着步骤走、用 OAuth 登录,然后跑出第一条提示词的结果。

这正是 Agent 上下文管理的意义所在：不是更多的仪式,而是更少的重复解释。

常见错误

对一款公开产品而言,最后一个错误代价最高。搜索 MCP、skills 或 Agent 上下文的用户本来就已经一头雾水。页面应当讲清楚足以建立信任的内容,然后把他们引向最快能跑通的配置。

一份务实的决策清单

当你在决定一段 Agent 上下文该放在哪里时,可以用这份清单。

拿不准时,问两个问题：

1. 助手在每个任务上都需要它吗？
2. 助手能否只在用户提出那类工作时,才去发现或加载它？

如果第一个问题答案为是,就把它留作 rule。如果第二个问题答案为是,就让它动态化：一个 skill、一次工具查找,或一个 MCP 操作。

为什么这对 SEO、GEO 和营销 Agent 很重要

营销工作流会很快暴露这个问题。一个有用的 SEO 或 AI 可见度 Agent,同时需要任务知识和实时证据：

• 它需要知道如何组织一次审计。
• 它需要当前的搜索、AI 回答、外链、本地、社交和页面证据。
• 它需要引用来源,并把观测到的记录与建议区分开。
• 它应该跑在运营者已经在用的助手里。

把这一切都塞进一个巨大的提示词会很脆弱。让营销人员手动接线十个工具则更糟。更好的形态是：

1. 选择一个 Agent 或 Skill;
2. 通过 MCP 配置页 把 UnifAPI 连接一次;
3. 让助手按需加载工作流并调用公开数据操作;
4. 为返回的记录付费,而不是为又一个 LLM 订阅或一个仪表盘席位付费。

这就是为什么这些概念很重要,但配置本身应该让人感觉简单。

如何让页面对引用友好

对于 AI 搜索和回答引擎,结构很重要,因为模型可能在没有上下文页面的情况下引用某一段。本文有意采用了几种模式：

• 在靠前位置放置直接的定义块；
• 为"rules vs skills vs MCP"类查询准备对照表；
• 用与常见搜索短语匹配的 H2 标题；
• 提供可以独立成立的简短 FAQ 回答；
• 优先引用官方文档,而非只引用评论文章；
• 内链到更深入的 UnifAPI 指南和 MCP 配置页。

这也是产品层面的启示。如果你的 Agent 工作流连人都难以快速浏览,那么助手也会难以检索和应用它。好的 Agent 上下文是模块化的、命名清晰的、易于引用的。

FAQ

什么是 Agent 上下文管理？

Agent 上下文管理,就是你如何决定一个 AI 助手在某项任务中应该收到哪些信息、指令、工具和记忆。好的上下文管理会把持久指引放进 rules、把可复用流程放进 skills、把实时数据放在 MCP 之后、把确定性检查放进 hooks。

skills 在取代 rules 吗？

不是。skills 更适合那些只在某些情况下相关的流程化工作流。而对于助手应当始终纳入考量的简短、持久指令,rules 仍然是正确的归宿。

MCP 和 skill 是一回事吗？

不是。skill 告诉助手如何执行一项任务。MCP 则在助手执行任务时,给它可以调用的实时工具或数据。许多有用的工作流两者都需要：skill 提供方法,MCP 提供当前证据。

我需要 subagent 吗？

通常一开始并不需要。subagent 适合隔离或并行的工作,但大多数运营者工作流应该从一个清晰的 skill 加一个已连接的 MCP 服务器起步。

AGENTS.md 或 CLAUDE.md 里该留下什么？

把持久的项目指引留在那里：仓库布局、真相来源文件、生成文件策略、验证命令、产品语言,以及反复出现的错误。把冗长的任务流程搬进 skills。

MCP 该取代直接 API 吗？

不该。MCP 是面向 Agent 的连接路径。对于需要明确请求控制的应用、后端、仪表盘和系统,直接的 HTTP API 仍然是正确的生产接口。许多产品应当两者都暴露。

Agent rules 该写多长？

在仍能避免重复犯错的前提下,越短越好。如果某一节只对一项任务、一个平台或一条排障流程有意义,那它多半应该放进 skill、参考文件或文档页,而不是始终生效的 rules。

对非开发者来说,最好的初次配置是什么？

选他们已经在用的助手,安装插件或连接器,用 OAuth 登录,然后运行一个具体的 skill。用户应该先看到一个有用的结果,再去学习完整的术语体系。

结论

对日常使用来说,Agent 世界其实并没有八个概念那么深。它是一个上下文问题,带着若干实现层级。

rules 用于稳定的记忆。skills 用于可复用的工作。MCP 用于实时能力。hooks 用于确定性控制。subagent 和模式则在任务或 UI 确实需要时才有用。

对其他所有人来说,合适的产品应该把术语压缩。选择你的助手。连接一次。运行工作流。

这正是 UnifAPI 借 MCP 配置页 所走的方向：Skills 加实时公开数据,合为一条路径,让运营者无需关心底层栈究竟用了 rules、命令、工具、hooks 还是 subagent,来让答案变得可靠。

主要参考资料

• Cursor，动态上下文发现。
• Cursor 文档，Agent Skills。
• Cursor 文档，subagent。
• Cursor 文档，Hooks。
• Cursor 文档，Model Context Protocol。
• Claude Code 文档，扩展 Claude Code。
• Claude Code 文档，Hooks 参考。
• Model Context Protocol，简介。
• Model Context Protocol，工具规范。
• Agent Skills，开放标准。
• UnifAPI，用 MCP 连接你的 Agent。