Agent中的5个关键术语

现在市面上的 Agent 层出不穷，但它们几乎都有一些共同的特性，这些共同的特性就像中间件的协议标准或某些面向对象语言的“多态”特性一样，只要熟悉相应的术语，切换 Agent 时会容易很多。

需要提醒的一点是：虽然 Agent 的切换不算困难，但 harness 这种需要经过配置和长期完善的内容可能仍然需要重新培养。

Memory

Memory 直译是记忆，这里指 Agent 的记忆系统。

在大模型的早期，只能进行一问一答的对话，因为它是没有记忆的，就像服务的“无状态”那样，每次的响应都只能基于本次提问中的信息来回复。现在的模型可以进行多轮次对话，像是有了记忆，本质是每次新的提问都会把之前的对话历史也一起放入本次提问的信息中（历史对话并非完全完整的放入，可能会进行压缩）。

但 Agent 上下文窗口终归是会满的，如果新开一轮对话，如何让这个纯净的 Agent 知道当前项目的情况呢？这就是 Memory 解决的问题之一。

Memory 的外在表现形式是 AGENTS.md 或 CLAUDE.md（Claude Code 独立标准），也就是一份记忆文档，每次在当前项目启动 Agent 时，它就会读取当前目录下 AGENTS.md 文件，以了解当前项目的情况。它就像是公司的员工手册，新员工会读取员工手册理解公司规范。

Memory 是有层级之分的，例如用户级：～/.claude/CLAUDE.md、项目级：./CLAUDE.md，如果内容有冲突后加载的会覆盖先前的，就像项目的代码规范优先级要高于个人的代码规范。在微服务项目中，建议整体有一个 CLAUDE.md 简要介绍各个微服务的信息等，每个服务再有独立的 CLAUDE.md。

CLAUDE.md 文件的目标行数最好不超过 200 行，过长的文件会占用更多上下文信息，Agent 在上下文窗口占用过多时会混乱，做出一些预期外的行为。可以使用 rule 规则拆分 CLAUDE.md，例如把代码编写规范、提交规范放置在两个其它的 md 中，在 CLAUDE.md 中引用即可，这样会在用到的时候才去加载。

当然 Memory 不仅能解决让新 Agent 理解项目情况的问题，还可以在 Agent 重复犯相同错误纠正完后让它把这个问题写到记忆文件中，这样就不用进行多次澄清了。

想要更深入的理解 Memory，可以看 Claude Code 的官方文档：How Claude remembers your project。

Skill

Skill 直译为技能，是针对某个特定场景的处理方案。

举个例子：我希望 Agent 在执行完 A 流程后生成总结报告发送到我的邮箱，也希望它在执行完 B 流程后生成总结报告发送到我的邮箱。

如果每次都在提示词里表述，Agent 需要考虑邮箱服务器、发件人账号、授权码等，但如果把发送邮件作为一个 Skill，那么最后的表述就变为：使用 send-email Skill 发送总结报告到 *** 邮箱。

Skill 的结构非常简单，通常如下：

~/.claude/skills/send-email
├── assets
├── references
├── scripts
│   ├── send.py
└── SKILL.md

最重要的就是 SKILL.md 描述文件，非常重要的两个字段 name 和 description：

• name 是 SKILL 的名字，如果我希望指定 SKILL 处理，可以使用 /{skill-name}；
• description 是对 SKILL 的描述，内容包括触发条件，Agent 会对问题进行理解，如果觉得匹配就会选择相应的 SKILL 处理。

Agent 拥有哪些 SKILL 是需要放到上下文里的，为了避免 Skill 占用过多的上下文，Agent 采用渐进式加载的机制（一开始只存 SKILL 的 name 和 description，需要用到时再加载 SKILL.md）。

MCP

MCP（Model Context Protocol），直译为模型上下文协议，是 Agent 与外界工具进行通信的标准。

Agent 依赖的模型是通过历史数据训练出来的，那么面对未来的信息，例如明天的天气怎么样它该如何处理呢？我们在面对这样的问题，会通过浏览器搜索，使用工具，Agent 也是这样。

使用工具并不难，RPC 就可以实现，但在这个场景里，如果天气A是 HTTP 调用，天气B是 gRPC 调用，那么切换天气服务时就很麻烦。

MCP 定义了 Agent 与 MCP 服务交互的规范，减少二者的耦合度，方便单独更换。

A2A

A2A 即 Agent To Agent，用于统一 Agent 间的通信。

像微服务拆分服务一样，工程中也会有专用的 Agent，如 Code Agent、Review Agent。Code Agent 在写完代码后，需要交给 Review Agent 审查，并根据 Review Agent 的反馈进行更新或用新的 Fix Agent 修改。

如果 Agent 之间通过自定义协议同步消息，会严重影响未来的可拓展性，包括但不限于更换 Agent、添加或删除 Agent。

有了 A2A，Agent 在启动时会发布 Agent Card 表达自己可提供的功能、认证方式、输入/输出等，其它 Agent 会在需要时通过 Agent Card 中描述的方式与其它 Agent 交互，示例如下（图就在上一个链接的文档里）：

Multi Agent

Multi Agent 直译就是多 Agent 架构，是一种使用时多的架构方式，还没有正式的标准文件。

在 A2A 小结中提到的 Code Agent 和 Review Agent 合作就是一种 Multi Agent 的体现，还有爬虫服务可能会爬取多个网站的数据，每个网站分配一个 Agent 来执行也是 Multi Agent。

Multi Agent 不仅仅是例如通过并行提高 Agent 的运行效率、为不同 Agent 选择合适的模型，它最重要的一点是上下文隔离。

思考一个这样的任务：检索每日的运行日志，找到出现错误的位置，分析错误原因并整理。在大型服务中，每日运行日志是非常大的，可能运行日志就会把上下文窗口占满，而且这些内容中，只有很少的错误部分才对后续流程有用，这就很适合 Multi Agent，后续 Agent 的执行拥有独立的上下文，运行的效率和正确性都会提高。

Multi Agent 架构的实现有多种：

• SubAgent：主 Agent 作为老板，每个子 Agent 爬取一个网站的数据汇总给主 Agent；
• Handoffs：交接模式，如例子中的 Review Agent 把 Review 意见交给 Fix Agent 处理，推进流程的执行；
• Router：Route Agent 对输入进行语义分析和职责分流，将任务分发给专业领域的 Agent，最终汇总输出响应给用户。

对于简单任务，Multi Agent 会有点大材小用并消耗更多的 token，Anthropic 在他们 多 Agent 研究系统的完整设计 也提到了性能和成本的权衡，Multi Agent 会有数倍甚至十数倍 token 的消耗。

小结

Memory 让 Agent 理解项目的内容和规范等信息，SKILL 是特定场景的可复用处理方案，MCP 是 Agent 与外部工具沟通的标准，A2A 规范了 Agent 间的通信，Multi Agent 提高工程的运行效率或隔离上下文，处理复杂任务。

这5个术语也许不同的 Agent 表现形式会有区别，但几乎都会出现。