# 你应该了解的 31 个 AI 编程 Agent 术语，按五大支柱分类 > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/zh-CN/blog/ai-coding-agent-glossary-31-terms-five-pillars/ > Reading time: 3 minutes > Language: zh-CN > Tags: ai, ai-agents, claude-code, codex, developer-tools, glossary ## Canonical https://tonylee.im/zh-CN/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Rollout Alternates en: https://tonylee.im/en/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ko: https://tonylee.im/ko/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ja: https://tonylee.im/ja/blog/ai-coding-agent-glossary-31-terms-five-pillars/ zh-CN: https://tonylee.im/zh-CN/blog/ai-coding-agent-glossary-31-terms-five-pillars/ zh-TW: https://tonylee.im/zh-TW/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Description 我把每天使用 Claude Code 和 Codex 时反复遇到的术语全部整理分类。五个分组自然浮现，它们完整地描绘了这些工具所运行的整个体系。 ## Summary 你应该了解的 31 个 AI 编程 Agent 术语，按五大支柱分类 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - 设计 Agent 能看到的内容 - 拆分工作给多个 Agent - 控制 Agent 的执行方式 - 跨会话记忆 - 将 Agent 连接到外部世界 - 地图，而非领土 ## Content 每隔一段时间，我的信息流里就会冒出一个新词。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"，你知道它属于第四个支柱。当一个新协议发布，你知道它在第五个。这个框架能吸收新词汇，不会因此崩溃。 我现在还是经常查词。区别在于，我已经知道该把它们放在哪个架子上了。 ## Related URLs - Author: https://tonylee.im/zh-CN/author/ - Publication: https://tonylee.im/zh-CN/blog/about/ - Related article: https://tonylee.im/zh-CN/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/zh-CN/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/zh-CN/blog/claude-code-layers-over-tools-2026/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-CN/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/zh-CN/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.