你应该了解的 31 个 AI 编程 Agent 术语，按五大支柱分类

每隔一段时间，我的信息流里就会冒出一个新词。Context engineering、Harness engineering、RLM、Progressive disclosure。我每天都在用 AI 编程 agent，但词汇量的增长速度已经超过了我真正理解它们的速度。

于是我停下来，把积累的 31 个术语全部整理分组。最终浮现出五大支柱，一旦看清这个结构，Claude Code 和 Codex 这类工具的整体架构就豁然开朗了。

这五大支柱遵循一条清晰的逻辑：设计 agent 能看到什么，将工作拆分给多个 agent，控制它们如何执行，帮助它们跨会话记住信息，再将它们连接到外部世界。

设计。拆分。控制。记忆。连接。

设计 Agent 能看到的内容

AI 模型只处理一样东西：它的 context window。每一条 system prompt、用户指令、附加文件、对话历史记录、memory 块和已加载的 skill，都被拼接成一个 token 流。这个流就是模型的整个宇宙。许多团队用来配置 agent 行为的 AGENTS.md 文件，也只是这个流中的一段内容。

Prompt 是你给模型的直接指令。Prompt engineering 是设计这些指令的实践，包括示例和输出格式，目的是获得稳定可靠的结果。这两个术语已经很普及，但它们只覆盖了真正进入模型内容的一小部分。

Context 是模型能够参考的全部内容：system prompt、对话历史、附加文件、memory、skill，以及工具输出的综合。Context engineering 是一门关于决策的学问：什么内容该放进去，什么该排除在外，以什么顺序排列。这个区别很重要。我见过完全相同的 prompt，仅仅因为一个 2000 行的文件放在指令前面还是后面，结果就大相径庭。顺序不是形式问题。

Intent 是用户真正的目标，它可能与字面上写的内容不同。当你写”修复测试”时，真实意图可能是”让 CI 通过”，也可能是”按新 API 重构整个测试套件”。Agent 路由从这里开始，intent 判断错误会影响下游所有环节。

Skill 是一个可复用的专家指令包，调用时会加载进 context。把它理解成 prompt 的函数。你不需要每次都粘贴同一段 200 行的指令，只需调用 /refactor-clean，skill 的内容就会按需进入 context window。

Progressive disclosure 是一种设计模式，不一次性将所有 skill 加载进 context，而是让 agent 在需要时只加载当前用到的 skill。Anthropic 在他们的 skills 博文中发布了这个方法。它之所以重要，是因为 context window 的空间是有限的。提前加载 40 个 skill 会在模型开始工作之前就消耗大量 token。Progressive disclosure 让 context window 保持精简，让模型保持专注。

我早期反复踩到的坑：往 context 里塞太多内容，然后疑惑为什么模型的输出质量下降了。200K 的 context window 是理论上限。实际上，一旦算上 system prompt、MCP server 定义和对话历史，可用空间可能降到 70K 甚至更少。Context engineering 的本质是尊重这个约束。

拆分工作给多个 Agent

让单个 agent 处理所有事情听起来很简单，直到 context window 被填满、输出质量下降。这就是多 agent 架构存在的原因。

Subagent 是主 agent 委托工作的子进程。主 agent 通过将专项任务外包出去来保持自身 context 的整洁。在 Claude Code 中，当你启动一个后台研究任务时，执行这个任务的就是 subagent，它运行在自己的 context window 中，只将结果返回给主 agent。

Swarm 是一种让多个 agent 并行处理同一问题不同部分的模式。如果需要同时分析五个文件，swarm 可以让五个 agent 各自处理一个文件，而不是让一个 agent 逐一处理。

Fleet 是你正在运行的 agent 的运营视角。这是一个管理术语，而非架构术语。当你有三个 subagent 加上两个 background agent 在运行，这个集合就是你的 fleet。

Handoff 是从一个 agent（或一个人）向另一个 agent 传递工作的过程。在顺序工作流中，Agent A 完成自己的阶段后将工作交给 Agent B。关键细节在于传递了什么：只有输出结果，还是完整的 context？大多数 handoff 只传递摘要，这意味着信息丢失是可能发生的，设计时需要考虑到这一点。

Background agent 在无需用户交互的情况下异步运行。GitHub 的 Copilot Workspace 和 Anthropic 的 Claude Code 都支持这种模式。你描述一个任务，合上电脑，agent 独立工作。等你回来时，结果已经在那里了。

我踩过的另一个坑：过早地把工作拆分给太多 agent。一个 context 设计良好的单 agent，在 80% 的任务上表现都优于协调不当的多 agent 方案。只有当你有证据表明单个 agent 正在触及 context 上限或输出质量下降时，才考虑拆分。

控制 Agent 的执行方式

一个能生成正确代码的 agent，如果同时悄悄调用危险工具或修改了不该碰的文件，那它仍然毫无价值。控制是第三根支柱，也是大多数团队投入最不足的那根。

Harness 是包裹 agent 执行、验证和生命周期的运营框架。它涵盖从权限检查到输出校验再到重试逻辑的一切。Harness engineering 是设计这个框架内的约束和反馈循环。OpenAI 在发布 Codex 如何通过结构化 harness 模式生成超过百万行代码的文章时，将这个词带入了主流视野。

Trace 是 agent 每一个步骤和决策的执行日志。我是在发现一个 agent 每次任务调用网页搜索工具 14 次，而实际上只需要获取一次信息之后，才开始认真对待 trace 的。没有 trace，我会以为 agent 工作效率很高。Trace 是最接近 AI agent 调试的工具。

Diff 是代码在 agent 修改前后的对比。与 trace 一起，diff 构成了验证的核心骨架。你无法审查你看不见的东西，而 diff 让 agent 的改动变得可审查，就像 pull request 让人类的改动变得可审查一样。

Guardrails 是防止危险输出的规则和校验检查。它可以简单到”永远不执行包含 rm -rf 的 shell 命令”，也可以复杂到阻止敏感数据出现在输出中的内容分类器。

Sandbox 是权限受限的隔离执行环境。Codex 在 Docker sandbox 中运行，agent 可以在里面写代码和跑测试，但无法访问网络或修改宿主系统。这就是”agent 犯了错误”和”agent 犯了影响生产环境的错误”之间的区别。

CLI（命令行界面）在 agent 时代正在迎来复兴。通过终端运行工具，比通过协议层路由的 token 效率更高。当每个 token 都有成本且占用 context 空间时，CLI 的直接性就显得很重要。

REPL（read-eval-print loop）是可以立即执行代码的交互环境。Agent 用 REPL 来验证假设、检验中间结果，以及在把文件写入磁盘之前先迭代方案。

跨会话记忆

大语言模型有一个硬性边界：context window。当它被填满，较早的内容就会被驱逐。对于跨越数小时或数天的任务，这是一个真实存在的问题。

Memory 是任何将对话历史和任务状态存储在单个 context window 之外的系统。Memory hierarchy 将这些存储组织成多个层级，通常是短期（当前对话）、中期（近期会话）和长期（持久知识）。这个设计与 CPU 缓存层级如出一辙，原因相同：不同的访问模式需要不同的存储策略。

Embeddings 将文本转换为捕捉语义含义的数值向量。它们是 RAG（检索增强生成）的基础，agent 通过搜索向量数据库将相关信息拉入 context window。当你的 agent “记住”了上一个会话的某件事，通常是在执行基于 embedding 的相似度搜索。

Long-running agent 跨越多个 context window 维持状态，处理时间超过单个会话的任务。这需要外部状态管理，因为模型本身没有持久记忆。

Ralph Loop 由 Geoffrey Huntley 创建，是一种用务实方式解决记忆问题的自主编程循环。每次迭代都启动一个全新的 agent 实例，但进度通过 git 提交和进度文件持久化保存。新实例读取 git 历史和进度笔记来了解已完成的工作，然后从那里继续。它通过反复迭代最大化测试时扩展性，每次循环都受益于仓库本身积累的 context。

RLM（Recursive Language Model） 采用了一种本质上不同的方法。它不是将长输入直接送入模型（那样会超出 context window），而是把原始数据存储在 REPL 变量中，让模型通过写代码来探索数据。模型通过递归函数调用对存储的数据发出精确查询。因为原始数据从未进入 context window，信息不会因为截断而丢失。作者声称这种方法可以处理相当于正常 context window 100 倍大小的输入。

两种方法面对的是相同的约束，但解决方式不同。Ralph Loop 通过外部持久化与 context window 的限制共存。RLM 通过将数据保持在 context window 之外来绕过它。两者都不是普遍更优的方案，选择哪个取决于你的瓶颈是任务连续性（Ralph Loop）还是输入规模（RLM）。

将 Agent 连接到外部世界

一个无法访问外部工具、API 或服务的 agent，只能做文本生成。协议解决的是集成问题。

MCP（Model Context Protocol） 标准化了模型连接外部工具的方式。没有 MCP，将 N 个模型与 M 个工具集成需要 N x M 个定制实现。有了 MCP，每个模型和每个工具只需实现一次协议，将集成成本降至 N + M。这和 USB 成功的原理相同：约定一个统一的接口，所有东西都能互联。

ACP（Agent Communication Protocol） 标准化了编辑器与编程 agent 之间的通信。Zed 和 JetBrains 正在主导它的开发。它解决的问题与 MCP 类似，但在不同的层次：不是模型到工具，而是编辑器到 agent。

LSP（Language Server Protocol） 是编辑器与代码分析服务器通信的成熟标准，是协议标准化在开发者工具中行之有效的最初证明。一次引用搜索，用 grep 需要 30 秒，通过 LSP 只需 50 毫秒。token 使用量从 2000 以上降至约 500，因为 LSP 返回的是结构化的精确结果，而不是原始文件内容。LSP 也是 ACP 设计的参考模型，这说得通，两者面对的问题形态几乎一致。

这三个协议运行在不同的层级，但共享同一个架构洞察：自定义的点对点集成无法扩展，标准接口才可以。

地图，而非领土

这里的大多数术语在六个月前还不存在。如果你对它们感到陌生，这很正常。词汇在增长，是因为这个领域在增长，新的概念需要被命名。

这五大支柱的价值，不在于背诵定义，而在于拥有一个心智框架，让你在遇到新术语的那一刻就知道它属于哪里。当有人提到”agent memory”，你知道它属于第四个支柱。当一个新协议发布，你知道它在第五个。这个框架能吸收新词汇，不会因此崩溃。

我现在还是经常查词。区别在于，我已经知道该把它们放在哪个架子上了。