Coding Agent 常用术语速查表：Prompt / Context / Memory / Tools 一次搞懂（建议收藏）

本文从工程化与实战视角，系统梳理 Coding Agent 的常用术语与核心概念，统一拆解 Prompt、System Prompt、Context、Memory、Tools、Skills、Hooks 等在不同工具中的落地形态。通过对 Claude、Codex、Gemini 的对照讲解，帮助你建立一套通用的 Agent 认知模型，减少概念混淆，更高效地使用 AI 进行代码协作。

杨林伟

1277人浏览 · 2026-01-29 13:03:40

杨林伟 · 2026-01-29 13:03:40 发布

1. 引言

在前面的几篇文章中，博主分别从实战与工程化视角深入讲解了当前主流的三套 Coding Agent 工具体系：Claude Code、Codex 以及 Gemini 3，感兴趣的可以先阅读：

在实际写作和使用过程中，一个非常明显的感受是：

这三套 Coding Agent 看起来“工具不同”，但底层用的却是高度相似的一套概念体系。

例如：

Prompt、System Prompt、Rules 到底边界在哪？
Context、Context files、Context window 有什么区别？
Memory、Skills、Hooks、Checkpointing 是“概念”还是“机制”？
为什么同一个需求，在 Claude / Codex / Gemini 里写法和落点完全不同？

这篇文章的目的，就是把这些分散在不同工具、不同命名下的概念抽象出来，放到同一张认知地图上，方便大家回顾与学习。

2. 概念详解

2.1 Prompt

Prompt （提示词）：是用户提供给 Coding Agent 的指令，用来说明要做什么事情，以及希望它怎么做，它是 Coding Agent 接收任务的主要输入，也是影响最终代码结果最关键的因素之一。

在实际使用中，Prompt 通常会包含任务背景、具体需求、约束条件（例如使用的编程语言或实现方式），以及期望的输出形式。可以把 Prompt 理解为一份“简化版需求说明”：写得越清楚，Coding Agent 对任务的理解就越准确，生成的代码也越接近预期；反之，Prompt 模糊不清，结果就容易跑偏，需要反复修改。

案例：

目标：修复当前仓库的测试失败，确保全量测试通过。
范围：仅修复导致失败的代码与必要测试；不要做无关重构。
约束：遵循现有代码风格；不要引入新依赖（除非必要并说明原因）。
验收：运行 `npm test` 全绿；输出中给出你运行过的命令与结果摘要。
信息不足：如果缺少失败日志或复现步骤，先问我 1-3 个问题。

2.2 System Prompt

System prompt（系统提示词）：工具内置/预置的“默认岗位说明书/规章制度”，影响默认行为，比如是否谨慎、是否先跑测试、输出格式偏好等。

在三套工具里怎么落地（对照）：

工具	描述
Claude Code	可以通过配置/输出风格把“输出契约”固化；并与 CLAUDE.md / Skills / Subagents 组合形成稳定协作方式（Output style）
Gemini	常见做法是用 `GEMINI.md` + skills/extensions 固化规则（System Prompt Override）
Codex	可用自定义 prompts（`~/.codex/prompts/*.md`）把常用指令模板化；更需要“团队共享/隐式触发”时用 skills

从模型的视角来看，System prompt 并不是一种“特殊文件”或“隐藏配置”，而是在请求模型时，与用户 Prompt 一起被提交的一部分上下文，一般：

System prompt：定义模型的长期行为、默认规则和输出契约
User prompt：描述当前一次任务的具体需求

以 OpenAI 风格的 Chat 接口为例，一个同时包含 System prompt 和 Prompt 的请求体通常如下所示：

{
  "model": "gpt-5.2",
  "messages": [
    {
      "role": "system",
      "content": "你是一个谨慎的 Coding Agent，优先保证测试通过，避免无关重构。"
    },
    {
      "role": "user",
      "content": "修复当前仓库中失败的测试，确保 npm test 全绿。"
    }
  ]
}

2.3 Rules

Rules（规则：策略引擎/护栏）: 是一类“策略匹配 → 决策执行”的机制，当某些条件命中时，系统采取 allow / prompt / forbid 等动作（常用于高风险操作治理）。

在三套工具里怎么落地（对照）

工具	描述
Claude Code	permissions/allowed-tools + hooks 的组合，经常承担类似“规则护栏”的作用（更偏工具层与事件层）
Gemini	通过 hooks（模型请求前/工具调用前后）与设置项（如 auto accept）也能实现类似的策略护栏
Codex	文中把 rules 作为“边界与复用”的机制之一（用于高风险命令控制、提示确认等决策）

2.3 Memory

Memory（记忆）：是“跨回合或跨会话能复用的信息”，为了不混淆，建议把它拆成三层来理解：

短期记忆（Short-term）：当前 thread 的对话历史与工具输出（本质还是 context）。
长期偏好（Long-term preferences）：比如你喜欢的输出格式、习惯（需要显式保存/配置）。
项目记忆（Project memory）：项目约定、如何跑测试、目录结构等（通常落在 CLAUDE.md / GEMINI.md / AGENTS.md 或 skills 里）。

它决定了“你要不要每次都从零解释”，memory 做得好，可以显著降低 token 消耗与沟通成本。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	文中有 `/memory` 用于编辑“会话之间可复用的记忆信息”的文件（更像用户级/长期偏好管理）
Gemini	工具体系里有 Memory 相关能力，并支持从 `GEMINI.md` 等上下文文件加载“分层记忆”的拼接内容供检查
Codex	文中强调上下文工程与 skills 的渐进式披露，把“能共享、能审计”的项目知识放进 AGENTS.md/skills 是更稳的团队做法

2.4 Token

Token ：是模型读写的计量单位（输入 token + 输出 token），它不是严格的“字数”，更像“模型内部的编码片段”，token 直接影响：

成本（计费/配额）
延迟（上下文越大越慢）
可用信息量（上下文窗口限制）
代理稳定性（上下文过大时会压缩/丢弃细节）

在三套工具里怎么落地（对照）

模型	描述
Claude Code	`/cost` 命令用于查看成本/时长
Gemini	`/stats` 查看 token/工具调用统计，并提供 token caching、压缩阈值等机制，适合在长会话里控成本
Codex	强调 context window 适配与自动压缩，配置里也能看到与 token 限制相关的参数（例如工具输出 token 上限等）

常见误区：

误区 A：把 token 当“字符数”。
真实情况：代码、符号、英文缩写、路径等都会影响 token 划分。
误区 B：以为 token 大就一定好。
上下文越大越容易“稀释”，关键是把相关信息放进去。

小案例

同样是“修测试”，给出“失败日志 + 相关文件 + 运行命令”通常比“把整个仓库塞进去”更省 token、也更准确。

2.5 Checkpointing

Checkpointing（检查点/回滚点）：指“在关键节点保存一个可回退的状态”，方便：

撤销一次错误改动
回到某个已验证通过的版本继续
在多方案尝试中快速切换

在三套工具里怎么落地（对照）

模型	描述
Claude Code	文中有 `/rewind`（别名 `/checkpoint`）用于把代码或对话恢复到之前时间点（直观就是“撤销到某个检查点”）
Gemini	更常见用“计划确认 + 权限确认 + 明确产物”的方式降低误改；回滚通常落在 Git 工作流里完成
Codex	云端线程强调 diff/审查与 PR 流程，检查点更自然地落在 Git 分支/提交上。

2.6 Threads

Threads（线程）: 一条 thread 可以理解为“一次独立会话 + 其中的提示、模型输出、工具调用历史”。它决定了“上下文历史在哪里、执行环境在哪里、并行怎么做”：

本地线程：能直接操作你的本地工作区，但需要更严格的门禁/沙箱来降低风险。
云端线程：在隔离环境里克隆仓库运行，适合并行委派与跨设备。

2.7 Context

Context（上下文）： Coding Agent 一次能 “看见” 的信息集合，例如文件内容、选中片段、命令输出、对话历史、项目说明文件等。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	有 `/context` 用于可视化当前会话上下文占用与包含的文件/目录；并提供 `/compact`、`/clear` 等用于清理/压缩上下文的命令
Gemini	常见上下文来源包括 `GEMINI.md`、`@文件`/目录包含、工具输出；并提供与 context 扫描/过滤相关的设置（如遵循 ignore 文件）
Codex	IDE 会自动把“打开的文件/选中片段”作为上下文，CLI 场景建议显式引用路径或用 mention 机制附加文件

案例：

你问“为什么这个接口 500？”

好上下文：路由文件 + 控制器 + 相关中间件 + 最近报错堆栈

坏上下文：只给一句“接口 500 帮我修”

2.8 Context window

Context window（上下文窗口）：是模型一次能容纳的上下文 token 上限，不同模型不同，超过就需要：

摘要压缩（保留要点）
丢弃不相关历史
分批处理（分阶段/分模块）

建议：

长任务要“分段验收”：每段完成就总结要点，下一段继续。
如果工具提供 /compress、/compact、/clear 一类命令：把它理解为“整理桌面，把不需要的纸收起来”。

2.9 Context files

Context files（上下文文件/项目说明文件）：给代理看的“项目级说明书”，把长期有效的信息放进仓库，让代理每次都能按同一套约定工作。

三篇文章里的落地名称：

模型	描述
Claude Code	`CLAUDE.md` + 项目 `.claude/`（commands/hooks/agents 等）
Gemini	`GEMINI.md`（以及相关 ignore/设置体系）
Codex	`AGENTS.md`（以及 override/fallback 机制）

怎么写（推荐内容）

如何安装依赖、如何跑测试/构建（给出命令）
代码风格/格式化方式
关键目录与模块职责
常见坑与注意事项（例如必须先生成代码、需要特定环境变量）
交付要求（PR 描述模板、必须给 Test Evidence 等）

常见误区

误区 A：把上下文文件写成“重复 README 的大段介绍”。
更有效：写成“可执行说明书”（命令、路径、约束、验收）。
误区 B：把所有背景都塞进去导致臃肿。
更有效：把“常用但稳定”的内容放这里；把“领域知识/复杂流程”放 skills（按需加载）。

2.10 Compact

Compact（压缩/摘要：把上下文“整理成要点”）：指用 “摘要” 替代长对话历史或大段细节，降低上下文占用，让长任务继续跑下去。长任务必然会遇到上下文窗口上限。压缩能延长任务续航，但也可能丢关键细节。

建议压缩前先明确“不可丢”的内容：

已确认的需求与范围
关键设计决策（为什么这么做）
运行/验证命令（DoD）
风险与回滚策略
压缩后立刻做一次“自检复述”：让代理用清单复述它接下来会做什么，确认没有跑偏。

2.11 Hooks

Hooks（钩子：自动化与门禁）：是“事件驱动自动化”，在特定事件发生时自动执行动作（跑脚本、检查、提醒、阻断等）。

怎么用（最常见三类）

质量自动化：改完文件自动 format/lint/跑测试。
危险拦截：拦截高风险命令、敏感文件写入。
收尾验收：在结束前强制输出检查清单/证据（例如必须给 Test Evidence）。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	支持多种事件类型（会话开始/结束、工具前后、停止前等），并区分命令型 hooks 与提示型 hooks，常配置在项目 `.claude/settings.json`
Gemini	提供 hooks 体系与相关配置项（例如在发起模型请求前运行 hooks、注入上下文或控制部分模型参数）
Codex	更偏 rules/沙箱/工作流；你可以把它理解为“同样目标（门禁与稳定交付），但落点更多在 rules/prompts/skills 上”

2.12 Tools

Tools（工具 / 工具调用）：工具是代理的“手脚”，例如读文件、写文件、搜索、运行命令、访问外部系统等。工具让Coding Agent从“猜”变成“查”：

读文件减少凭空编造
跑测试让它能自证
grep/搜索加速定位影响面

在三套工具里怎么落地（对照）

模型	描述
Claude Code	工具事件可被 hooks 监听（例如 Write/Edit/Bash/Read 等），并可用 permissions 约束可用工具集合
Gemini	提供 `/tools` 查看可用工具列表；并支持文件系统、shell、web fetch/search、memory、todos、MCP servers 等工具体系
Codex	工具调用贯穿整个线程，并强调“在可以验证其工作的情况下输出更高质量”（例如跑 lint/test）

2.13 Skills

Skills（技能 / SOP）：是 “标准作业程序（SOP）打包”，把步骤、清单、输出契约、资源（脚本/参考资料）放进一个可复用单元，并按需加载/触发。

Skills vs Prompts（关键区别）

prompts（自定义提示）更像“可复用话术/模板”，通常需要显式调用，且可能不随仓库共享（具体取决于产品设计）。
skills 更像“可治理的流程资产”，常见支持：
- 目录结构（脚本/资源）
- 渐进式披露（不默认把全文塞进上下文）
- 团队共享与优先级覆盖

在三套工具里怎么落地（对照）

模型	描述
Claude Code	Skills 被用作“可复用 SOP”，并可与 subagents/hook 组合，Subagents 管分工、Hooks 管触发与门禁、Skills 管步骤模板与交付结构
Gemini	有 `/skills`（实验性）与 `gemini skills ...` 管理命令，支持 workspace 级与 user 级技能目录，用于按需加载专家能力
Codex	Skills 遵循 Agent Skills 标准，支持显式调用（`/skills` 或 `$SkillName`）与隐式触发；并有多层级加载与覆盖优先级

2.14 Plugins / Extensions

Plugins / Extensions（插件/扩展：打包与分发）：解决的是“把一套能力打包给别人装上就能用”，例如命令、hooks、skills、MCP 配置、甚至 LSP 等。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	Plugin = 目录 + 清单文件 `.claude-plugin/plugin.json` + 可分发能力（commands/agents/hooks/skills/MCP/LSP）
Gemini	extension 体系可把 Prompts、MCP servers、Agent Skills、自定义命令、Hooks 打包成 `gemini-extension.json` 进行分发安装
Codex	更常见的“可复用与共享”载体是 skills 与仓库内的 AGENTS.md 约束，插件式分发不是Codex主线

2.15 MCP

MCP（Model Context Protocol）：是把外部 “工具/上下文提供者” 接进代理的一种协议/接口标准，例如很多关键上下文不在代码仓库里（内部文档、工单系统、数据库 schema、设计稿、语言服务器等），MCP 让代理能“按需获取”这些信息，而不是靠你手动复制粘贴。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	有 `/mcp` 用于管理 MCP 服务器（外部上下文提供者）
Gemini	`/mcp` 提供 `list/desc/schema/auth/refresh` 等子命令，用于发现与管理 MCP 工具
Codex	支持在 `~/.codex/config.toml` 配置 MCP，并提供 CLI 命令（如 `codex mcp add ...`）来添加与管理服务器

2.16 LSP

LSP（Language Server Protocol）：是编辑器/工具与“语言服务进程”沟通的统一协议，常见能力有跳转定义、找引用、类型诊断、补全、重构提示等。它能把“代码理解”从“文本猜测”提升到“语义级导航”：

哪个符号定义在哪
这个函数被哪里调用
类型/诊断信息是什么
对大仓库尤其有用。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	可随插件分发/配置，指定哪个 language server”
Gemini	当作“可通过 MCP/扩展接入的一类工具能力”
Codex	可通过 MCP 连接到扩展工具，例如语言服务器或外部数据源

2.17 Sandbox

Sandbox（沙箱）：是 “把代理的可执行动作限制在可控范围” 的隔离环境机制，目的是降低意外修改系统/泄露信息/误操作的风险。当代理能跑命令、能写文件时，沙箱和权限一起构成“底层安全网”。

沙箱通常在隔离什么

文件系统范围：只能读/写工作区（或特定目录），防止误伤系统文件。
命令执行能力：限制可执行命令、超时、资源上限，避免“跑飞”或误操作。
网络与外部访问：有的环境会限制联网或只能访问白名单服务。
凭据与环境变量：避免把敏感 token 暴露给不必要的步骤/工具。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	通常配合 permissions/allowed-tools 与 hooks 的门禁来控制“能做什么/什么时候做”
Gemini	执行任务时会出现计划确认与权限确认，并提供工具级配置（例如 shell 是否交互、是否自动接受某些只读工具调用）
Codex	本地线程运行在沙箱环境中以降低意外修改风险，云端线程在隔离环境里克隆仓库执行

2.18 LLM Gateway

LLM gateway（大模型网关）：是企业/团队常用的一层“统一入口”：把多个模型提供方（或多个模型版本）藏在网关后面，对外提供统一鉴权与调用接口。它通常负责这些工程化能力：

路由与选型：根据任务类型选择模型（快/便宜/强推理）。
权限与审计：谁在调用、调用了什么、是否触发敏感策略。
速率限制与配额：防止滥用与成本失控。
日志/追踪/脱敏：便于排障与合规（避免把敏感数据直接打到第三方）。

2.19 Agents

Agents（代理 / 后台任务）：不是单纯的模型，而是 “能执行任务的一整套系统”，在 CLI 产品里，常表现为可运行的任务单元（可能能并行、能查看状态）。

在三套工具里怎么落地（对照）

模型	描述
Claude Code	有 `/agents` 查看运行中的代理/后台任务，并配合 `/todos` 等跟踪复杂对话的任务清单
Gemini	更常见以“工具调用 + 计划确认 + 权限确认”的 agent 行为体现，并支持 sub‑agents 的模型选择差异提示
Codex	更强调“线程（thread）”作为执行与历史的组织单元，尤其区分本地与云端线程

2.20 Subagent

Subagent（子代理 / 专职工种）：可以把主代理当 Tech Lead（负责拆解、编排、汇总），把 Subagent 当“专职工种”（例如测试工程师、安全审计、文档工程师）。

怎么用（安全边界很关键）

给子代理更小的工具权限：
- 安全审计：Read/Grep 就够了
- 测试补齐：再给 Write
- 需要跑命令才给 Bash

2.21 Remote Subagents

Remote subagents（远程子代理）：指“子代理不在当前本地进程/会话里执行”，而是在远程/隔离环境中执行（仍由主代理编排），常用于：

并行处理多个子任务
更强隔离（安全/资源/网络）
把耗时任务放到后台或云端

在三套工具里怎么落地（对照）

模型	描述
Claude Code	见形态是后台代理与子代理分工，“远程”更多通过外部集成/环境来实现
Gemini	启用本地和远程 subagents”的实验性设置语义（可把它理解为 remote subagents 的开关）
Codex	通过“云端线程/云任务”实现远程执行（把仓库克隆到隔离环境里跑）

2.22 AI native team

AI native team（AI 原生团队）：意思不是“用 AI 写代码”，而是把代理纳入 SDLC 的每个环节，让流程天然支持‘代理协作’。

SDLC（软件研发生命周期）：典型环节为需求 → 设计 → 实现 → 测试 → 评审 → 发布 → 监控/回滚 → 复盘。

怎么落地（用你现在学到的术语串成一条流水线）

需求：用 prompt 模板把 DoD 写清楚（范围/验收/风险）。
设计：用 context files 固化约定；必要时用子代理输出设计评审清单。
实现：主代理编排，子代理分工（subagents）；工具（tools）落地改动。
质量门禁：hooks 自动 format/lint/test；rules/permissions 拦截危险操作；沙箱降低误伤。
交付：skills 生成 PR 描述/发布说明（含风险、回滚、测试证据）；必要时通过 MCP 拉取外部信息（工单/文档/语言服务）。
回滚与复盘：checkpointing（Git/rewind）+ 结构化日志，确保可追溯。

3. 术语速查表

3.1 输入与指令层（你对 Agent 说什么）

术语	一句话解释	关键作用
Prompt	用户给代理的任务指令	定义要做什么/怎么验收
System Prompt	工具/团队预置的“默认岗位说明书”	固化默认行为与输出契约
Instructions / Output Contract	对输出结构的强约束（格式、证据、清单）	提升可控性、减少返工
Mention / 引用文件	在 prompt 里显式引用文件/目录/片段	精准供给上下文，降 token

3.2 策略与护栏层（能做什么、要不要确认）

术语	一句话解释	关键作用
Rules	条件命中→执行 allow/prompt/forbid	高风险操作治理
Permissions	工具权限/可用工具集合	控制能力边界
Sandbox	把可执行动作限制在隔离环境	降低误操作与泄露风险
Confirmation / Prompt-to-confirm	执行前强制二次确认	防止“误删/误改/误发布”

3.3 上下文层（模型“看见”的是什么）

术语	一句话解释	关键作用
Context	当前一次请求里模型可见的信息集合	决定回答质量上限
Context Window	单次可容纳的 token 上限	决定能“看多远”
Context Files	给代理看的项目说明书	稳定复用项目约定
Ignore / Exclude	哪些文件不进上下文/不扫描	降噪与降成本
Retrieval / Search	通过搜索按需拉取信息	避免全量塞上下文

5.4 记忆与复用层（跨回合、跨项目怎么复用）

术语	一句话解释	关键作用
Memory	可跨回合/会话复用的信息	降沟通成本、提稳定性
Short-term Memory	当前 thread 的历史与工具输出	让对话连贯
Long-term Preferences	个人偏好（格式/语气/习惯）	减少重复对齐
Project Memory	项目约定（命令/目录/DoD）	团队一致性

5.5 工程化能力层（让 Agent 变“可交付”）

术语	一句话解释	关键作用
Tools	读/写/跑命令/访问外部系统	从“猜”变“查”
Hooks	事件驱动自动化与门禁	自动跑检查/拦截风险
Skills	可复用 SOP 单元（步骤+清单+产物）	提升复用与治理
Plugins / Extensions	打包分发能力（命令/skills/hooks）	团队快速安装复用
Checkpointing	关键节点可回退状态	降试错成本

5.6 执行组织层（怎么跑、怎么并行）

术语	一句话解释	关键作用
Thread	一次会话/任务的历史与执行载体	决定上下文与环境边界
Agent	能执行任务的系统单元	支持长任务与工具编排
Subagent	专职分工的子代理	并行与专业化
Remote Subagents	远程隔离环境运行的子代理	并行 + 隔离 + 资源

5.7 基础计量与成本层（为什么会慢、会贵、会跑偏）

术语	一句话解释	关键作用
Token	模型读写的计量单位	成本/延迟/窗口上限
Token Caching	重复上下文复用缓存	降成本降延迟
Compact / Summarize	把长历史压缩成要点	延长长任务续航

5.8 协议与集成层（把外部系统接进来）

术语	一句话解释	关键作用
MCP	外部上下文/工具提供者接入协议	按需获取外部信息
LSP	语言服务协议（语义级代码理解）	跳转/引用/诊断/补全
LLM Gateway	多模型统一入口（路由/审计/配额）	企业级治理与成本控制

5.9 易混淆对照

容易混淆	区分要点
Prompt vs System Prompt	Prompt 是“这次要做什么”；System prompt 是“长期默认怎么做/怎么输出”。
Context vs Context Files	Context 是“当前看到什么”；Context files 是“每次都该知道的项目约定”。
Context Window vs Token	Token 是单位；Context window 是 token 上限。
Memory vs Context Files	Memory 更偏“偏好/长期复用”；Context files 更偏“项目说明书/团队约定（可审计）”。
Skills vs Prompts	Prompts 是可复用话术模板；Skills 是可治理 SOP（步骤/清单/产物/按需加载）。
Rules vs Hooks	Rules 偏“策略决策（allow/prompt/forbid）”；Hooks 偏“事件触发自动化（跑脚本/拦截/注入上下文）”。
Checkpointing vs Git	Checkpointing 是“回退能力”的抽象；工程实践里往往由 Git 分支/提交、或工具的 rewind 实现。

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

AI产品经理-大模型的智力之源与能力边界

大模型的时代，从来不是 “唯技术论” 的时代，而是技术 + 业务深度融合的时代。想要让大模型真正产生价值，不是盲目追求最新、最强的模型，而是先搞懂它的原理和边界，再结合业务痛点，找到合适的结合点。作为 AI 产品经理，我们的核心竞争力，从来不是单纯的懂 AI 或懂业务，而是把 AI 的能力，精准转化为解决业务问题的方案。搞懂大模型的智力之源与能力边界，只是第一步，而真正的落地，藏在每一次的实操、每