Agent 术语速查

系列入口：如何使用 Agent。还不确定 Agent 是什么，先看 Agent 和聊天机器人的差别。

一、为什么先理术语

Agent 生态这两年长得太快，各家工具造了一堆词，而且很多词含义重叠——这个工具叫 Rules，那个叫 Memory，第三个叫 Skill，新手很容易被绕得失去耐心。其实这些概念并不复杂，把它们按「谁在干活、它知道什么、它能连什么、什么在约束它」分成四类，一下就清楚了。

二、主体类：Agent 与 Subagent

• Agent（智能体）：跑主循环的那个角色，直接接收你的目标，负责规划和总控。平时说「让 Agent 改一下」指的就是它。
  • 例子：你说「把登录模块加上失败次数锁定」，这个从理解需求到改代码、跑测试全程跟你对接的角色就是 Agent。
  • 别搞混：Agent 不是模型本身。同一个模型可以只做问答（不是 Agent），也可以驱动 Agent。Agent = 模型 + 循环 + 工具 + 权限边界，模型是它的「大脑」，Agent 是整套干活的角色。
• Subagent（子代理）：主 Agent 在执行中派生出来的分身，专门去做一个独立子任务，比如「去把整个 codebase 里调用某函数的地方都找出来」。子代理有自己的上下文窗口，干完把结论汇报给主 Agent。好处是主对话不会被大量中间信息塞满，相当于项目经理派了个调研员。
  • 例子：主 Agent 要改一个被多处调用的函数，先派生一个子代理去全库盘点调用点，子代理返回「共 14 处，分属 3 个模块」，自己读过的几十个文件内容不会污染主对话。
  • 别搞混：子代理和「新开一个对话」不一样。子代理由主 Agent 自动派生、结果自动回流，是编排的一部分；手动新开对话则要你自己搬运结论。两者的分工后面在多 Agent 编排里细讲。

三、知识类：Context、Skill、Rules、Memory

这组词最容易混，核心区别在「这次任务临时看到的」还是「长期沉淀下来的」。

• Context（上下文）：Agent 在当前这一次任务里能看到的全部信息——你发的消息、它读过的文件、之前的对话、工具返回的结果。上下文有长度上限（token 预算），超了就要裁剪或压缩。怎么管理它是后面「上下文工程」模块的主题。
  • 例子：你让它改一个函数，它读过的函数本体、调用方、相关测试，此刻都在上下文里；而隔壁没读过的服务，它并不知道，除非去读。
  • 别搞混：上下文是「这次记得」，关掉对话就没了；它不是记忆。很多「AI 失忆」其实是上下文窗口被塞满或被重置，而不是它学会了又忘。
• Skill（技能）：一份打包好的、可复用的做事方法，通常包含触发条件 + 步骤说明 + 可能附带的脚本。比如「写周报的 skill」「发布前检查的 skill」。需要时 Agent 按条件调用，不必每次都把方法讲一遍。
  • 例子：一个「提交前检查」skill 里写好了触发条件（用户要提交时）、步骤（跑 lint、跑测试、检查提交信息格式）和一个执行脚本，Agent 命中条件就照做。
  • 别搞混：Skill 是「怎么做一件事的方法」，Rules 是「做事必须守的规矩」。「发布前要跑冒烟测试」是流程方法，可放进 Skill；「禁止直接 force push 到 master」是硬约束，属于 Rules。
• Rules（规则）：项目或团队定的硬性约定，比如「不许用 var」「提交信息用中文」。不同工具叫法不同（规则文件、CLAUDE.md、项目约定），本质都是长期生效的约束。写法看 CLAUDE.md 编写指南。
  • 例子：规则文件里写「本项目包管理器固定用 pnpm，依赖版本锁定，不要升级大版本」，Agent 每次动手都会看到。
  • 别搞混：Rules 写「必须怎样 / 不要怎样」的约束，不写操作流程；而且只写 AI 容易搞错、又不是常识的事，别把「函数要用括号」这种废话塞进去。
• Memory（记忆）：Agent 跨任务保留下来的信息，比如「这个项目用 pnpm 不用 npm」「用户偏好简短回答」。让它不用你每次重复背景。Rules 和 Memory 的边界在不同产品里有差异，理解成「规则偏必须遵守，记忆偏参考背景」即可。
  • 例子：你纠正过一次「这个仓库的部署脚本在 scripts/deploy 而不是根目录」，它记下来，下次直接找对地方。
  • 别搞混：记忆不是越多越好。记错或过期的背景（比如去年用过、今年已废弃的命令）会持续误导它，记忆也需要定期清理和纠正。

词	作用范围	一句话
Context	仅当前任务	它此刻能看到的信息
Skill	可复用	打包好的做事方法
Rules	长期、强制	必须遵守的约定
Memory	跨任务	记住的背景与偏好

四、连接与约束类：MCP 与 Hooks

• MCP（Model Context Protocol，模型上下文协议）：一套标准化的「插插座」规范，让 Agent 用统一方式接入外部工具和数据源——数据库、Git、文件系统、第三方 API。没有它，每接一个工具都要单独写一遍适配；有了它，支持 MCP 的工具和服务可以即插即用。细节看 MCP 协议。
  • 例子：你配置一个连数据库的 MCP server，Agent 就能用统一的查询动作读数据，换一个支持 MCP 的 Agent 也能复用同一套配置，不用重写。
  • 别搞混：MCP 是「连接的协议/插座」，不是某个具体工具；它本身不干活，定义的是 Agent 和外部服务之间怎么对话、怎么暴露能力。
• Hooks（钩子）：在 Agent 工作流的特定事件点自动触发的动作。比如「每次要执行删除命令前先拦下来确认」「每改完文件自动跑一遍格式化」。它把你不想手动重复的检查固化成自动机制，是从「人盯着」走向「流程自动管」的关键。
  • 例子：配一个 PreToolUse 钩子，凡是命令里匹配到 rm -rf 就拦截并要求二次确认；再配一个 PostToolUse 钩子，文件改完自动跑 prettier。
  • 别搞混：Hooks 是「事件触发的自动机制」，Rules 是「写在那儿让模型读的约束」。规则可能被模型忽略（它毕竟是在「读」），钩子则是程序级强制执行，拦得住就是拦得住。

4.1 顺带把这几个高频词也收了

• Tool（工具）：Agent 能调用的单个动作（读文件、跑命令、发搜索）。MCP 是连接工具的协议，Tool 是最终被调用的那个动作本身。
• Approval / Permission（审批 / 权限）：危险或不可逆操作前，Agent 停下来等你确认的环节。「允许一次」「本会话都允许」「拒绝」通常是三个基本选项。
• Token（词元）：模型计量文本的单位，约等于「半个到一个词」。上下文窗口和费用都按 token 算，中文一个字常占 1~2 个 token。
• Context Window（上下文窗口）：一次任务能装下的 token 上限，比如 128k、200k。它决定了 Agent「一次能看多少」，但不等于越大越好——塞太满会变贵、注意力也会被稀释。
• Orchestration（编排）：把一个大目标拆成多个子任务、分派给多个 Agent、再汇总结果的组织方式。
• Plan Mode（计划模式）：只让 Agent 分析和出方案、禁止改动的模式，用来在动手前对齐。
• Compaction / Summarization（压缩 / 摘要）：上下文快满时，把前面的对话浓缩成摘要、腾出空间的动作。

五、一张表收口

分类	术语	类比
主体	Agent / Subagent	项目经理 / 她派出的调研员
知识	Context / Skill / Rules / Memory	手头资料 / 操作手册 / 公司规章 / 记事本
连接	MCP	统一规格的插座
约束	Hooks	自动触发的安检门

如果连四类都嫌多，可以用一句更糙的话记住：Agent 是干活的人，Context 是他眼前的桌子，Skill/Rules/Memory 是他的手册、规章和笔记本，MCP 是他伸手够得到外面世界的门，Hooks 是门口和工位上自动生效的安检闸。 人、桌子、资料、门、闸——五个意象对应五组概念，够用了。

另外提醒一个心态：术语多是这个阶段的行业常态，不是你理解力的问题。你完全不需要一次记全，先把「主体 + 上下文」这两个最核心的用熟，其余概念在真实任务里碰到一个、理解一个，反而最扎实。后面每一篇专题都会把对应术语放回具体场景里，你会越来越熟。

六、几组最容易混的，单独掰一掰

Context vs Memory：上下文是「这次任务眼前摊着的资料」，随对话结束而清空；记忆是「跨任务留在本子上的背景」。你可以把上下文想成桌面，记忆想成抽屉——桌面大小有限要常收拾，抽屉里的东西会留到下次，但也可能放了过期的玩意儿。

Skill vs Rules：Skill 回答「这件事怎么做」，是可调用的流程与方法；Rules 回答「做任何事都不能违反什么」，是横在所有动作上的红线。一个可被按需触发，一个始终生效。

Rules vs Hooks：Rules 靠模型「读后自觉遵守」，本质仍是提示，存在被无视的可能；Hooks 在事件点由程序强制执行，拦不拦得住不取决于模型配不配合。要硬保证的事用钩子，偏好与约定用规则。

MCP vs Tool：Tool 是 Agent 能调用的具体动作；MCP 是让一批 Tool 被标准化发现和接入的协议。前者是电器，后者是插座标准。

Subagent vs 另开对话：子代理由主 Agent 自动派生、结果自动回流，属于编排；手动另开对话要你自己传目标、搬结论，是两次独立使用。

七、用一个上午的工作，把全部术语串起来

孤立地记名词容易忘，跟着一个真实工作流走一遍，这些词就各就各位了。

早上九点，你接到需求：给支付服务加一个「退款超时自动关闭」的能力。你打开 Agent（主体），没有直接让它开写，而是先切到 Plan Mode（约束类的一种工作模式），让它读代码、出方案。它在 Context（这次任务的上下文）里读了退款相关的三个服务，给出了改动计划，你确认无误后切回执行模式。

执行中，它发现要改动的状态机函数被很多地方调用，于是派生一个 Subagent（子代理）去全库盘点调用点，主对话保持干净。动手时它遵守项目 Rules（规则）里「时间处理统一用 UTC、禁止裸 sleep 轮询」的约定；写测试时它调用了团队沉淀的「测试数据构造」Skill（技能），不必你再教它怎么造订单。

它需要查一笔真实订单的状态，于是通过 MCP（连接器）连上了（只读的）订单数据库，用统一的 Tool（工具动作）查到数据。它有一次想跑一个带删除临时目录的命令，被一个 Hooks（钩子）拦下来要求确认——你看了一眼，是安全的，点了允许。整个过程中，它还记得这个服务的部署目录在 services/payment/deploy，这是上周存进 Memory（记忆）的背景。

你看，七个术语不是考试要点，而是同一件事里各司其职的零件：Agent 和 Subagent 是干活的角色，Context、Skill、Rules、Memory 构成它能动用的知识，MCP 是它向外的连接，Plan Mode 和 Hooks 是管着它节奏与安全的约束。

八、其他你迟早会遇到的词

简单收几个进阶词，现在看不懂没关系，遇到时回来查：

• System Prompt（系统提示词）：产品在对话背后预置的指令，定义 Agent 的基本行为、可用工具和输出格式，通常不需要你改，但解释了「为什么它默认会先规划」。
• Streaming（流式输出）：文字一个一个蹦出来而不是等整段生成完，纯展示机制。
• Temperature（温度）：控制输出随机性的参数，越高越发散、越低越稳定；做确定性强的编码任务通常调低。
• Grounding（接地）：让回答基于真实检索到的资料而非模型记忆，降低「一本正经胡说」的概率；接文件、接数据库本质都是在做接地。
• Idempotency（幂等性）：同一操作执行一次和多次效果相同。让 Agent 跑命令、做自动化时，优先选幂等操作，重试才安全。
• Diff：改动前后的差异对比，是你审查 Agent 写操作的主要对象。
• Sandbox（沙箱）：隔离的执行环境，Agent 在里面折腾也不影响主机，是放权执行类工具时的安全垫。

九、常见问题

Q：这些词不同工具里叫法都不一样，需要一一对应去背吗？ 不必。各家产品命名不同但概念基本能落进这四类。记住「主体 / 知识 / 连接 / 约束」的功能位，看到新词先判断它在回答哪个问题（谁干活、知道啥、连什么、谁在管），就能归位。

Q：Agent、模型、助手（Assistant）是一回事吗？ 模型是底层的语言引擎；Agent 是模型加上循环、工具和权限后能干活的角色；Assistant 多是产品界面对对话角色的称呼，具体是否算 Agent 要看它有没有自主循环和工具。判断始终回到功能，不看叫法。

Q：术语里哪些是我真正要动手配置的？ 新手阶段重点接触三个：Rules（写项目约定）、Skill（沉淀做事方法）、Hooks（固化强制检查）；MCP 在需要连数据库或特定外部服务时再配；Subagent 和编排是任务变复杂后自然会用到的组织手段。

Q：要不要专门去学这些名词的「官方标准定义」？ 这个领域还在快速变化，并没有跨厂商完全统一的严格定义，过度纠结「某词的标准含义」反而容易钻牛角尖。更实用的做法是抓住每个词解决的问题、能区分功能边界即可；真要深入某一块，点进对应主题的专题文章看用法，比背定义有效得多。

总结

不用死记名词，记住四个问题就够了：谁在干活（Agent/Subagent）、它知道什么（Context/Skill/Rules/Memory）、它能连什么（MCP）、什么在自动管着它（Hooks）。