简报要求的 28 个核心概念全部覆盖，索引如下；完整定义（英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆）按模块分节在后。原文分散于 glossary/glossary-*.md，本表为合并总览。
| 概念 | 模块 |
|---|---|
| Agent / Agent Loop / Agentic Architecture | 08 |
| Attention | 01 |
| Context / Context Window / Context Engineering | 01 · 07 |
| Embedding | 01 · 07 |
| Evaluation | 12 |
| Grounding / Groundedness | 07 · 12 |
| Hallucination | 01 · 12 |
| Human-in-the-loop | 04 · 11 |
| Inference | 01 |
| MCP / MCP Host / MCP Client / MCP Server | 06 |
| Model Routing | 10 |
| Orchestration | 08 |
| Prompt Engineering | 05 |
| Prompt Injection | 11 |
| RAG / Retrieval-Augmented Generation | 07 |
| Resource | 06 |
| Reranking | 07 |
| Structured Output | 05 |
| Subagent | 08 · 09 |
| Tool / Tool Use | 04 · 06 |
| Workflow | 08 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Token | 词元 | 模型处理文本的最小单位，也是计费与限速的计量单位 | 成本估算、上下文预算、ITPM/OTPM 全部按 token | 与「字符/字节」混淆；中英文密度差异巨大 |
| Tokenization | 分词 | 把文本切成 subword 单元的过程 | 解释为什么不能按字符数做预算 | 与「编码 (encoding)」混淆 |
| Context Window | 上下文窗口 | 单次请求可引用的全部文本的「工作记忆」 | 上下文预算与多轮对话管理的地基 | 与「数据库/永久记忆」混淆——请求结束即消失 |
| Context Rot | 上下文衰减 | 上下文越长，准确率与召回越降 | 「把所有文档塞进 1M 窗口」不成立的官方依据 | 与「超窗报错」混淆——rot 在窗口内就发生 |
| Attention | 注意力 | 生成每个 token 时对上下文动态加权聚焦 | 解释长上下文成本、位置敏感性、开头结尾记得牢 | 与「存储」混淆——注意力不写入权重 |
| Next-token Prediction | 下一词预测 | 给定全部已有文本预测下一个 token 的核心机制 | 输出长度不可预知、streaming 基础、输出多样性 | 与「检索/查询」混淆 |
| Temperature | 温度 | 采样随机性参数（0 近似确定 → 1 多样） | 4.7+ 模型非默认值返回 400；行为控制转向 prompting | 与「结构化输出保证」混淆——温度不保格式 |
| Hallucination | 幻觉 | 生成看似合理但不真实的内容 | 概率系统固有属性；需接地/工具/评估分层缓解 | 当成可修的 bug |
| Adaptive Thinking | 自适应思考 | 模型自行决定思考量，effort 调节（Opus 5/Sonnet 5/Fable 5） | 成本/质量/延迟的主动权在 effort 参数 | 与手动 extended thinking 混淆（Haiku 4.5 仍是手动） |
| Training vs Inference | 训练 vs 推理 | 权重更新（Anthropic 侧，预发布）vs 权重冻结的请求期计算 | 推理期只能控制 prompt/上下文/工具/参数 | 与「微调定制」混淆 |
| Knowledge Cutoff | 知识截止 | 模型知识最可靠的截止日期 | cutoff 后的事实必须靠工具/检索 | reliable cutoff 与 training data cutoff 两个日期不同 |
| Grounding | 接地 | 把回答约束在可验证来源上 | RAG 与引用机制的目标；幻觉的架构级缓解 | 与「prompt 里要求准确」混淆 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Model Family | 模型家族 | Fable/Opus/Sonnet/Haiku 四条产品线 | 选型的第一层输入（价格/延迟/窗口三轴） | 把「更强」当默认答案；限流桶常比单价先卡住 |
| Pinned Snapshot | 固定快照 | 每个 model ID 指向固定权重版本 | 同 ID 同行为是回归测试与灰度升级的基础 | 与「自动升级到最新」混淆——换 ID 是主动决策 |
| System Prompt | 系统提示词 | 顶层 system 参数，无 "system" role | 角色与行为边界的规范位置；参与缓存前缀 | 与「塞进 user 消息」混淆——浪费缓存与稳定性 |
| Content Block | 内容块 | text/image/document/tool_use/tool_result 等结构 | 多模态与工具回路的原子单位 | 字符串 content 只是单 text block 的简写 |
| Visual Token | 视觉 token | 28×28 像素 patch，图片计量单位 | 多模态成本核算；两档分辨率上限不同 | 与「文件大小」混淆 |
| Stop Reason | 停止原因 | 本轮响应的 7 种完成方式 | 应用层分支的权威信号（截断/工具/拒答…） | 与「HTTP 错误」混淆；rate_limit_error 不是 stop_reason |
| SSE (Server-Sent Events) | 服务端推送事件 | streaming 的传输层 | 逐事件消费降低 TTFT；流内 error 事件要处理 | 与 WebSocket 混淆 |
| TTFT | 首 token 时间 | 发送请求到第一个 token 的时间 | 感知延迟的核心 SLO 指标 | 与总生成时长混淆——streaming 只改前者 |
| RPM / ITPM / OTPM | 每分钟请求/输入/输出 token | 三维速率限制 | 容量规划；cache-aware ITPM 是吞吐倍增器 | 忘了 OTPM 常是瓶颈（输出 5x 价） |
| Token Bucket | 令牌桶 | 容量连续回补的限流算法 | 短突发也会 429；客户端限速要平滑而非整分重发 | 与「整点重置」混淆 |
| Spend Limit | 花费上限 | 月度成本天花板（Start $500/Build $1K/Scale $200K） | 触顶后 429 无 retry-after，重试无效 | 与 rate limit 混淆——前者按月按钱 |
| Deprecation / Retirement | 弃用/退役 | 模型与参数的生命周期终点管理 | 变更管理流程输入；≥60 天通知；参数也会退役（temperature 400） | 只盯模型不盯参数弃用 |
| Model Snapshot / Pinned ID | 模型快照 | ID 生命周期内指向固定权重 | 生产可复现性的前提 | 与「云端自动最新」的期望冲突 |
| Alias | 别名 | 早期模型的便捷指针，解析到最新快照 | 别名会漂移，生产环境用固定快照 ID | 与快照 ID 混淆 |
| Model Routing | 模型路由 | 按任务类型/成本分层选模型 | 成本最大杠杆（不同档位 5–10x） | 以为单模型更「简单」就更好 |
| Cascade | 级联 | 便宜模型先过滤，边缘样本升强模型 | 兼顾成本与漏检；升级率是核心指标 | 与 ensemble 混淆 |
| Prefill | 预填充 | 末尾 assistant 消息约束输出开头 | 4.6+/Mythos Preview 已弃用（400）；改结构化输出 | 以为等于 schema 校验 |
| Pause Turn | 暂停回合 | 服务端工具循环达迭代上限而暂停 | 原样回传 assistant 内容即可继续 | 当作错误 |
| Refusal | 拒答 | Claude 拒绝响应（读 stop_details） | 记录 + fallback 模型，勿盲目重试 | 与普通空响应混淆 |
| Cache-aware ITPM | 缓存感知限速 | 多数模型 cache 读取不计入 ITPM | 高缓存命中率 = 有效吞吐放大器 | 以为缓存 token 也占限速 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Workload Identity Federation | 工作负载身份联合 | 用短期 token 替代长期 API key | 无状态工作负载的密钥治理方案 | 与云平台 IAM 混淆（另一套体系） |
| Typed Exception | 类型化异常 | SDK 按 HTTP 错误抛对应类 | 按具体类分派处理策略，勿字符串匹配 | 与 catch-all 混淆 |
| Exponential Backoff | 指数退避 | base×2^n(±jitter) 的重试间隔 | 官方 SDK 默认行为；自建重试的基线公式 | 与固定间隔重试混淆 |
| Retry Budget | 重试预算 | 最大次数/时限约束 | 防重试风暴；重试也烧钱（计费不幂等） | 与无限重试混淆 |
| Retry-After | 重试等待 | 429 响应头，服务端指定等待秒数 | 优先于自身退避；spend-cap 429 无此头 | 假设所有 429 都有此头 |
| Cache Breakpoint | 缓存断点 | cache_control 标记的位置，最多 4 个 | 缓存粒度的控制点；自动/显式可混用 | 以为断点越多越好（上限 4） |
| Cache Invalidation | 缓存失效 | 前缀变化导致 miss | 稳定性设计：易变内容靠后；tool_choice 变化作废 messages | 与 TTL 过期混淆 |
| Message Batches | 消息批处理 | 异步批量 API，5 折 | 离线任务的默认架构；24h 过期/29 天取结果 | 与客户端并发混淆 |
| custom_id | 自定义批项 ID | 批内请求的业务标识（^[a-zA-Z0-9_-]{1,64}$） | 结果对账与重入的钥匙 | 与 request-id 混淆 |
| Request ID | 请求 ID | 每响应必带的追踪标识 | 报障/审计必带；错误体与响应头都有 | 与 custom_id/model ID 混淆 |
| Token Bucket (client) | 客户端令牌桶 | 按三维限流做平滑发送 | 防突发 429 与加速限制 | 与服务端令牌桶重复建设 |
| Billing Non-idempotency | 计费不幂等 | 重试无副作用但重复计费 | 重试预算也是预算控制；Batch 摧低重试成本 | 以为重试免费 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Function Calling | 函数调用 | Tool use 的别名 | 跨厂商语境下的同一概念 | 与「代码生成」混淆 |
| Client Tool / Server Tool | 客户端/服务端工具 | 执行位置在应用 vs Anthropic 基础设施 | 决定谁写执行器、谁管重试与权限 | 以为 server tool 也要自己执行 |
| tool_use / tool_result | 工具调用/结果块 | 回路的两个原子 block | 消息历史的结构约束全围绕它们 | 与 user text 混在同一消息里乱序 |
| tool_choice | 工具选择控制 | auto/any/tool/none 四级 | 判断权在模型与代码间的分配旋钮 | 与 strict 混淆（选不调 vs 调得对不对） |
| Parallel Tool Use | 并行工具调用 | 一轮多个 tool_use | 吞吐提升；执行侧要能对账与并发 | 忘了每个 tool_use 都要配对结果 |
| is_error | 错误标记 | tool_result 的失败信号 | 错误回传让 Claude 自我修正/改道 | 与 HTTP 错误混淆（这是对话内恢复机制） |
| Strict Tool Use | 严格工具使用 | strict:true 保证入参过 schema | 根除坏参数中断（模块 05 展开） | 与 tool_choice=any 混淆 |
| Human-in-the-loop | 人在环 | 不可逆动作执行前的人工确认 | 权限门的最高档；门在应用不在 prompt | 以为 prompt 里要求确认就是人审 |
| Indirect Prompt Injection | 间接提示注入 | 经 tool_result 内容注入恶意指令 | 工具结果是不可信输入面（模块 11） | 只防用户直接注入 |
| Permission Gate | 权限门 | 执行前的授权检查点 | LLM 指令 ≠ 授权机制的落地形态 | 与 schema 校验混淆（合法性≠权限） |
| High-signal Response | 高信号返回 | 工具只回下一步需要的字段 | 控制 token 预算与选择准确率 | 与「返回越多越好」直觉相反 |
| Agent Loop | 智能体回路 | tool_use↔tool_result 循环 | 停止条件必须代码兑底（模块 08） | 与单次工具调用混淆 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Prompt Engineering | 提示工程 | 通过设计与迭代 prompt 控制模型行为 | 一切 Claude 应用的第一道设计面；先有评估再调 prompt | 与「调参」混淆——temperature 不是提示工程 |
| Structured Output | 结构化输出 | 用 JSON schema 约束模型输出为合法结构化数据 | 下游系统对接的硬保证；替代 prefill 的现代方案 | 与「prompt 里要求输出 JSON」混淆（软 vs 硬） |
| Constrained Decoding | 约束解码 | 解码期用文法禁止非法 token，而不是事后报错 | 解释了为什么零重试；理解能力边界（只保格式不保语义） | 与后置校验混淆 |
| JSON Schema | JSON 模式 | 描述 JSON 结构与约束的标准 | API 契约的通用语言；结构化输出/strict tool use 共用 | 与「JSON 格式」混淆 |
| Strict Tool Use | 严格工具使用 | strict: true 保证工具名与入参过 schema | agent 工作流中消灭坏参数导致的中断 | 与 tool_choice 混淆（后者控制是否调用） |
| Few-shot / Multishot Prompting | 少样本/多样本提示 | 在 prompt 里给 3–5 个示例引导输出 | 控制风格、判断口径、格式「神」的软手段 | 与 fine-tuning 混淆（不改权重） |
| Zero-shot | 零样本 | 不给示例直接下指令 | 基线；新模型指令跟随强，很多任务已够用 | 与「一个示例 (one-shot)」混淆 |
| Prefill | 预填充 | 旧技巧：预填 assistant 半句话引导输出 | 4.6+/Mythos Preview 起 400；旧教程遗毒识别 | 与 system prompt 混淆 |
| Extended Thinking | 扩展思考 | 手动 budget_tokens 思考预算 | 4.6 弃用、4.7+ 拒绝；存量系统仍需懂规则 | 与 adaptive thinking 混淆 |
| Adaptive Thinking | 自适应思考 | thinking: {type: "adaptive"}，按 effort 与复杂度自动调节 | 2026 年的现行方案；官方称稳定优于手动模式 | 与「temperature 自适应」无关 |
| Interleaved Thinking | 交错思考 | 工具调用之间穿插思考块 | agent loop 的观察消化机制 | 与多 agent 交替混淆 |
| Effort | （思考）投入度 | output_config.effort 控制思考深度的档位 | adaptive 时代的预算控制旋钮 | 与 max_tokens 混淆（那是输出硬顶） |
| Grounding / Groundedness | 有据性 | 回答是否贴着给定证据（如先引原文再作答） | 幻觉治理与 RAG 评估的核心概念 | 与 accuracy 混淆（可有据但不全对） |
| Repair Retry | 修复式重试 | 把校验错误信息拼进 prompt 让模型自我修正 | 无结构化输出环境的标准回路 | 与盲目重试混淆 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Model Context Protocol (MCP) | 模型上下文协议 | 把 AI 应用连到外部系统的开放协议（「AI 的 USB-C」） | 解决 M×N 集成问题的标准化层；选型判断的核心对象 | 与「某个厂商的 API」混淆——它是跨厂商开放标准 |
| Host | 宿主 | AI 应用本体：管理 client、权限、用户同意、上下文聚合 | 完整对话历史与编排权留在 host——安全边界的根 | 与 MCP Client 混淆（client 只是 host 里的连接器） |
| Client (MCP) | 客户端 | host 内与恰好一个 server 通信的连接器 | 1:1 关系是 server 隔离边界的实现机制 | 与 OAuth client 混淆（授权场景里含义不同） |
| Server (MCP) | 服务器 | 通过 tools/resources/prompts 暴露能力的服务（本地进程或远程） | 能力封装单元；看不到完整对话与其他 server | 与 Web server 混淆（语义完全不同） |
| Tools | 工具 | model-controlled：模型自主发现并调用的函数 | 模型的行动面；必须有人类在回路；定义会进上下文 | 与 API 的 endpoint 混淆——控制方是模型 |
| Resources | 资源 | application-driven：URI 标识、由 host 决定取用的上下文数据 | 数据面：文件、schema 等只读上下文的规范出口 | 与 tool 混淆（把只读数据做成 tool 会扩大行动面） |
| Prompts (MCP) | 提示模板 | user-controlled：server 定义、用户显式选用的消息模板（斜杠命令） | 「user-controlled 指谁触发，不是谁编写」是高频陷阱 | 与 prompt engineering 的 prompt 混淆 |
| Resource Template | 资源模板 | RFC 6570 URI 模板参数化的资源（catalog://{section}） | 参数化只读数据的标准形态 | 与 tool 入参混淆 |
| Transport | 传输层 | 消息封装与投递的绑定层；协议语义与传输无关 | 选型：stdio（本地）vs Streamable HTTP（远程共享） | 与「协议本身」混淆——换传输不换语义 |
| stdio | 标准流传输 | host 拉起子进程，stdin/stdout 上换行分隔 JSON-RPC | 本地开发工具默认形态；凭证来自环境、不走 OAuth | 与「Linux 标准流一般概念」混淆 |
| Streamable HTTP | 可流式 HTTP 传输 | 单 MCP 端点 POST；响应为 JSON 或请求级 SSE；无协议级会话（2026-07-28） | 远程/企业部署形态；必须校验 Origin 防 DNS rebinding | 与已淘汰的 HTTP+SSE（2024-11-05）混淆 |
| Capability Negotiation | 能力协商 | 双方声明能力并按声明行事（Modern：每请求 _meta 携带） | 理解 server/discover 与扩展协商的基础 | 与 OAuth scope 混淆 |
| Elicitation | 征询 | server 向用户追加索取信息（Modern 经 InputRequiredResult/MRTR） | server 缺输入时的标准回路，替代旧 sampling 式反向请求 | 与 sampling（Legacy 时代 server 反调 LLM）混淆 |
| Progressive Discovery | 渐进式发现 | 只注入 search_tools 元工具，按需加载完整定义（catalog→inspect→execute） | 上百工具时上下文治理的官方方案；阈值窗口 1%–5% | 与一次性 tools/list 混淆（list 照常、注入延后） |
| Tool Search Tool | 工具搜索工具 | Anthropic 原生按需检索：全部定义+defer_loading:true，服务端搜索加载 | 治理工具膨胀的首选捷径（regex/BM25 两变体） | 与自建 progressive discovery 混淆 |
| MCP Connector | MCP 连接器 | Messages API 内置 server-side MCP client（beta） | 免自建 client 编排；但仅远程 HTTP server、仅工具调用 | 与完整 MCP client 混淆（不支持 stdio/resources/prompts） |
| Token Passthrough | 令牌透传 | server 把上游 token 原样转发下游——被规范禁止的反模式 | 安全评审的必查项：绕过 audience 控制与审计链 | 与合法的代理转发混淆 |
| Confused Deputy | 混淆代理人 | proxy 静态 client ID+动态注册+consent cookie 跳过用户同意 | MCP proxy 架构的标志性攻击；缓解靠 per-client consent | 与普通 CSRF 混淆 |
| Human in the Loop | 人在回路 | 工具调用前有人类确认、可拒绝 | MCP 工具安全三大原则之一；LLM 指令≠应用层强制（模块 11） | 与「模型自我约束」混淆 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 | ||||
|---|---|---|---|---|---|---|---|---|
| Retrieval-Augmented Generation (RAG) | 检索增强生成 | 先从知识库检索相关片段拼进 prompt，再让模型生成回答 | 「库大塞不下」时的知识接入默认方案；成本随块数而非库大小线性 | 与 agentic search 混淆（后者模型自己决定查什么、何时查） | ||||
| Embeddings | 嵌入向量 | 把文本映射成高维向量，意思相近的文本向量距离近 | 语义检索的上限由嵌入模型决定；官方推荐 Voyage AI（Gemini 嵌入测试中亦佳） | 与「词向量/词嵌入」混淆（那是词级的旧技术） | ||||
| Vector Search / Semantic Search | 向量检索/语义检索 | 按余弦相似度等度量在向量库找查询的近邻 | 换说法查询的命中靠它；但精确 token（错误码/SKU）是它的系统性盲区 | 与「语义理解」混淆——它只比距离，不理解 | ||||
| BM25 (Best Matching 25) | 词法排名函数 | TF-IDF 家族的排名函数：词频饱和 + 稀有词加权 + 文档长度归一 | 精确 token 查询（TS-999、法条编号、函数名）必须靠它；毫秒级倒排索引 | 与「关键词包含匹配」混淆（它有排名不是布尔过滤） | ||||
| Lexical / Sparse Retrieval | 词法/稀疏检索 | 基于词表命中（BM25/TF-IDF）的检索范式 | Hybrid 的词法路；工业标准、可解释、零训练成本 | 与「过时技术」划等号——官方明确它补 embedding 盲区 | ||||
| Hybrid Retrieval | 混合检索 | 语义 + 词法双路召回后融合去重 | 官方默认姿势：Embeddings+BM25 好于单独 embeddings | 与「多个向量模型 ensemble」混淆 | ||||
| Rank Fusion / RRF (Reciprocal Rank Fusion) | 排名融合 | score = Σ 1/(k+rank)，k 常取 60，合并多路排名 | 双路分数量纲不可比，排名天然可比——融合的标准解 | 与「分数加权平均」混淆（需归一化且对分 calibrated 敏感） | ||||
| Chunking | 分块 | 把文档切成检索与拼装的最小单元 | RAG 里性价比最高的调参点；块大小由「答案需要多少上下文自解释」决定 | 与「分页/分段展示」混淆（那是 UI 概念） | ||||
| Chunk Overlap | 块重叠 | 相邻块共享 10–20% 文本，缓解边界信息丢失 | 代价是索引存储与重复内容膨胀；是缓解手段不是免费午餐 | 与「冗余=浪费」或「overlap 越大越好」两个极端混淆 | ||||
| Semantic Chunking | 语义分块 | 在相邻句话题相似度骤降处切分 | 保句子完整、话题聚块；实现复杂、块长不均、有成本 | 与「用 embedding 模型做检索」混淆（这里是找切点不是找邻居） | ||||
| Structural Chunking | 结构化分块 | 按标题/章节/函数/表格行切并保留层级元数据 | Markdown/代码/合同的正确切法；标题链天然缓解主语丢失 | 与「语义分块」混淆（按文档结构 vs 按话题相似度） | ||||
| Context Loss | 上下文丢失 | 块被切出文档后失去归属（谁的？哪季？） | 传统 RAG 的系统性缺陷；"revenue grew 3%" 没有公司名就是废数据 | 与「块重叠能解决」混淆——重叠救边界，救不了主语 | ||||
| Contextual Retrieval | 上下文检索 | 索引前用廉价 LLM 为每块生成 50–100 token 情境前缀再做嵌入与 BM25 | 官方数据：+上下文 BM25 降检索失败率 49%，+reranking 累计 67%；prompt caching 摊薄后 $1.02/M doc tokens | 与「结构化分块带标题」混淆（近似但机制不同：LLM 定制前缀 vs 复制标题） | ||||
| Metadata Filtering | 元数据过滤 | 块入库时打结构化标签（tenant/acl/updated_at），查询时先过滤再检索 | 同时解决安全（租户隔离）、新鲜度（作废政策）、精度（候选更小）；pre-filter 优于 post-filter | 与「生成后检查」混淆——过滤必须发生在候选集形成前 | ||||
| Pre-filter vs Post-filter | 检索前过滤 vs 检索后过滤 | 先缩小候选空间再检索 vs 检索完再筛结果 | pre-filter 更准更安全；post-filter 可能把 Top-K 滤空或被迫回填噪音 | 与「两者等价」混淆 | ||||
| Top-K | 前K结果 | 最终拼进 prompt 的块数 | 上下文预算分配问题；官方实测 20>10>5 但收益递减；K×块长+提示+历史+输出 ≤ 窗口 | 与「召回 Top-N」混淆（N 是宽进的候选数，如 150） | ||||
| Reranking | 重排序 | 用 cross-encoder 对 query-chunk 对精排，Top-N 收敛到 Top-K | 官方：更好回答+更低成本延迟（无关信息更少）；代价是运行期多一跳 | 与「重跑一遍向量检索」混淆 | ||||
| Cross-encoder | 交叉编码器 | query 与 chunk 拼接后联合过模型打相关分 | 准但慢→只对 Top-N 做；精排阶段的模型形态 | 与 bi-encoder 混淆 | ||||
| Bi-encoder | 双塔编码器 | query 与 chunk 分别独立编码再比距离 | 快而粗、可预计算——全库召回阶段的模型形态 | 与 cross-encoder 混淆（快粗 vs 慢准的分工） | ||||
| Groundedness | 有据性/接地性 | 回答主张被检索证据支撑的比例 | 生成层防幻觉的核心指标；prompt 层 <quotes> 技巧、API 层 Citations、评估层独立评分 | 与 accuracy 混淆（可有据但不正确——原文过时；反之亦然） | ||||
| Hallucination | 幻觉 | 输出无依据的虚构内容 | RAG 不自动消灭幻觉——检索到噪音块或无 groundedness 约束时照样编 | 与「检索错误」混淆（那是检索层问题，因果链上游） | ||||
| Citations | 引用 | document 块上 citations.enabled=true，回答返回支撑每条主张的 cited_text 与出处 | 主张可审计；cited_text 不计输出 token；全开或全不开、仅文本 | 与「让模型自己写来源」混淆（自报来源可伪造，API 引用指向你给的文档） | ||||
| Recall@k | 召回率 | 该找到的相关块找到了多少（\ | R∩Top-k\ | /\ | R\ | ） | RAG 优先指标——块没检索到生成再强也没用 | 单独看会被「加大 K」作弊（全库塞入=100%） |
| Precision@k | 精确率 | 找回的 Top-k 里有多少真的相关（\ | R∩Top-k\ | /k） | 上下文预算紧时的关键指标——噪音块挤占预算助长 context rot | 与 recall 的优先级之争：RAG 先 recall 后 precision | ||
| MRR (Mean Reciprocal Rank) | 平均倒数排名 | 首个相关结果排名倒数的平均 | 单正确答案问答场景的排序指标 | 与 nDCG 混淆（后者支持分级相关度） | ||||
| nDCG | 折损累计增益 | 位置对数折损加权的相关度增益 | 分级相关度、列表排序质量；「好结果是否按重要度排好」 | 与 MRR 混淆 | ||||
| Pass@k / Hit Rate | 命中率 | 金标块是否出现在前 k 个结果里 | 单金标块评测、实现最简；官方上下文检索 cookbook 的口径（248 条评测查询） | 与 Recall@k 混淆（多金标时两者才分化） | ||||
| Golden Dataset | 金标数据集 | 人工标注的问题-答案/块对 | 无金标=盲调；换嵌入模型/调 chunk/加 reranker 都要有数字背书 | 与「线上日志」混淆（那是观测不是标注） | ||||
| Context Rot | 上下文腐烂 | token 越多，准确率与召回率越退化（官方术语） | 「窗口够小就塞」的物理边界；策展上下文与窗口大小同样重要 | 与「超出窗口报错」混淆（那是硬限制，rot 是软退化） | ||||
| Attention Budget | 注意力预算 | 模型处理长上下文的有限注意力，每个 token 都在消耗它 | 解释为什么 K 不能无限加、为什么 rerank 省上下文反而更好 | 与 max_tokens 混淆（那是输出上限） | ||||
| Prompt Caching | 提示缓存 | 前缀缓存复用，降本提速 | 「塞库方案」与 Contextual Retrieval 索引期的经济学支柱（延迟 >2x、成本最高降 90%） | 与「客户端缓存」混淆（这是服务端前缀缓存） | ||||
| Ingestion / Indexing | 摄取/索引 | 离线建库阶段：解析→分块→前缀→嵌入/倒排→入库 | 增量更新与失效机制在这里；「索引一建永不更新」是常见事故源 | 与「查询期」混淆（问题域完全不同） | ||||
| Just-in-time Retrieval | 即时检索 | agent 运行期按需拉取，而非预先索引 | 规避陈旧索引、渐进式披露；代价是慢与不可预测（Claude Code 样板：预取+按需混合） | 与 RAG 对立起来——两者常组合 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Agentic Systems | 智能体系统 | 官方对 workflow + agent 的统称：一切以 LLM 为引擎、超出单次调用的系统 | 术语总纲：先判断自己在哪个自主性档位 | 与「agent」混用——workflow 也属于 agentic systems |
| Workflow | 工作流 | LLM 和工具走预定义代码路径：if/else/循环都是开发者写死的 | 可预测、可测试、可预算；well-defined 任务的首选 | 与「自动化脚本」混淆——workflow 里每次调用仍是 LLM |
| Agent | 智能体 | LLM 动态指挥自己的流程与工具使用；极简口径「LLMs autonomously using tools in a loop」 | 开放式问题的答案；控制权从代码转移到模型 | 与「带工具的聊天机器人」混淆——关键在循环控制权归属 |
| Agent Loop | 智能体循环 | Goal→Reasoning→Planning→Action(tool_use)→Observation(tool_result) 的循环 | 一切 agent 的引擎；= 模块 04 工具回路 + 控制权转移 | 与单圈 tool loop 混淆——loop 的圈数方向由模型定 |
| Stopping Conditions | 停止条件 | 让开放式循环可控的刹车：任务完成/max iterations/预算/人审检查点/阻塞升级 | 官方点名的 max iterations 是 agent 上生产的准入门槛 | 与 stop_reason 混淆（那是单次 API 响应的字段） |
| Ground Truth (from the environment) | 环境真实反馈 | 每步用工具结果/代码执行结果评估进展，而非模型自我感觉 | agent 可靠性的根基；测试驱动修复的前提 | 与「模型置信度」混淆 |
| Augmented LLM | 增强型 LLM | LLM + 检索/工具/记忆的基础积木 | 一切编排模式的原子单元；接口要按用例裁剪 | 与 RAG 混淆——RAG 只是增强之一 |
| Routing | 路由 | 输入分类后导向专用下游（prompt/工具/模型） | 分离关注点；高低难度分流省成本 | 与 Routing（网络）无关 |
| Prompt Chaining | 提示链 | 固定顺序的多次 LLM 调用，前一步喂后一步，可加程序化 gate | 用延迟换准确率的经典交易 | 与 agent 的多轮混淆——链的顺序是代码写死的 |
| Parallelization | 并行化 | 多个 LLM 调用同时跑再程序化聚合；分 sectioning 与 voting 两变体 | 耗时≈最慢子任务；guardrails/多视角评审的载体 | 与 orchestrator-workers 混淆——子任务是否预定义 |
| Evaluator-Optimizer | 评估器-优化器 | 一个 LLM 生成、另一个按标准评估反馈、循环精修 | 有清晰评估标准 + 人类反馈有效时最划算 | 与 self-refine 混淆——官方是两个角色（可以是同一模型） |
| Orchestrator-Workers | 编排器-工人 | 中央 LLM 动态分解任务、委托 workers、综合结果 | 子任务集合随输入变化时的标准答案；多智能体的拓扑基础 | 与 parallelization、与 planner-executor 混淆 |
| Planner-Executor | 规划器-执行器 | 先产出计划、照单执行；计划通常不随观察改写 | BEA 未单列；区分判据是「计划是否静态契约」 | 与 orchestrator-workers 混淆（后者动态再分解） |
| Multi-Agent System | 多智能体系统 | 多个 agent（各自 tools-in-a-loop）协同，常为 lead + subagents | 开放式+可并行+超窗口+高价值四前提；≈15× token | 与「多工具」混淆——每个 agent 有独立上下文与循环 |
| Subagent | 子代理 | 被主 agent 拉起的下级 agent，独立上下文窗口 | context isolation / 并行 / 专用指令 / 工具限制四大收益 | 与 MCP server 混淆（那是工具提供方，不是 agent） |
| Context Isolation | 上下文隔离 | subagent 中间过程留在自己窗口，只回传最终摘要 | 多智能体对搜索「压缩」价值的实现机制 | 与数据隔离混淆——是上下文管理概念不是安全边界 |
| Compaction | 压缩 | 窗口快满时摘要历史、以摘要重启新窗口 | 长时程任务第一杠杆；最轻量是旧工具结果清理 | 与 truncation 混淆（压缩是蒸馏不是截断） |
| Agentic Memory / Structured Note-Taking | 结构化笔记 | agent 定期把笔记写到窗口外持久存储，之后取回 | 长时程一致性；产品化为 memory tool | 与 vector DB 混淆（那是检索侧，这是 agent 主动写） |
| Memory Tool | 记忆工具 | 平台工具 memory_20250818：Claude 在 /memories 下读写文件、跨会话积累 | client-side 执行；必须做路径穿越防护 | 与「模型自己记住」混淆——记忆在你控制的存储里 |
| Harness | （智能体）挽具 | 调用 Claude 并把工具调用路由到基础设施的循环本体 | Managed Agents 三接口之一；「模型之外的循环代码」统称 | 与 agent 混淆——harness 是确定性外壳 |
| ACI (Agent-Computer Interface) | 智能体-计算机接口 | 工具定义与文档面向模型易用性设计，对标 HCI 投入 | 官方经验：优化工具的时间超过优化 prompt | 与 API 设计混淆——读者是模型不是人类开发者 |
| Compounding Errors | 错误复合 | agent 多轮中小错滚雪球放大 | sandbox 试跑 + guardrails + 人审检查点的理由 | 与单次幻觉混淆——复合是多轮特有的风险 |
| Pets vs Cattle | 宠物 vs 牛群 | 不可替换需人工照料 vs 可替换可重建的组件 | Managed Agents 把容器/harness 做成 cattle 的设计观 | 与「有状态 vs 无状态」混淆——讲的是运维姿态 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Agentic Coding Tool | 智能体式编码工具 | 官方对 Claude Code 的定位：不止补全，而是读库、改文件、跑命令的完整 agent | 理解产品边界：它是一个跑在你机器上的 agent，不是聊天窗口 | 与「IDE 补全插件」混淆——后者无 agent loop |
| Agentic Loop | 智能体循环 | gather context → take action → verify results 的三阶段循环，工具结果不断回喂 | 一切 agent 系统的骨架；停止条件与打断机制是设计重点 | 与「单轮问答」混淆；三阶段相互交织而非严格串行 |
| Agentic Harness | 智能体脚手架 | 让模型能作为 agent 行动的执行系统：输入处理、工具编排、结果返回 | 官方称 Claude Code 为 a flexible agent harness——自建 agent 系统时的参照实现 | 与「模型本身」混淆——harness 是模型外的工程系统 |
| CLAUDE.md | 项目指令文件 | 你写给 Claude 的持久指令，每次会话自动加载；层级：Managed policy → User → Project → Local | 跨会话一致性的第一道设计面；官方建议每文件 ≤200 行 | 与「强制配置」混淆——它只是 context，强制要靠 hook/deny |
| Auto Memory | 自动记忆 | Claude 自己在 MEMORY.md 里记的偏好与纠错笔记 | 零成本积累项目知识的官方机制；加载限前 200 行/25 KB | 与 CLAUDE.md 混淆——作者不同（Claude vs 你） |
| Rules (.claude/rules/) | 路径规则 | 带 paths: 前置元数据的规则文件，只在读到匹配路径的文件时加载 | 把大 CLAUDE.md 按目录拆小的官方机制——局部约定按需付费 | 与 skills 混淆——rules 是约定不是流程 |
| Tiered Permissions | 分层权限 | 按工具类型（只读/Bash/文件修改/Web）决定是否需要批准的体系 | human oversight 的产品化：审批粒度即安全粒度 | 与 permission modes 混淆——前者是规则体系，后者是会话级模式 |
| Permission Modes | 权限模式 | default(Manual)/acceptEdits/plan/auto/dontAsk/bypassPermissions 六种免询问范围 | 效率 vs 审查的旋钮；auto 用 classifier 治提示疲劳 | 把 plan 当独立功能页——它已是一种 permission mode |
| Deny Rules | 拒绝规则 | permissions.deny 列表：命中的动作一律拒绝 | 唯一在所有模式（含 bypassPermissions）下生效的规则层 | 以为 allow 能压过 deny——顺序恰好相反 |
| Managed Settings / Policy | 组织托管配置 | 组织级 settings/CLAUDE.md，优先级最高、可锁定 | 企业统一红线与审计基座的落点 | 与项目 settings 混淆——托管层个人改不掉 |
| Protected Paths | 受保护路径 | 任何模式都不会被自动批准的敏感路径（bypass 除外） | 内置防误删防线；rm/rmdir 对关键路径永不自动批准 | 与 deny 规则混淆——这是平台内置行为，不是你配置的 |
| PreToolUse Hook | 工具调用前钩子 | 每次工具调用前必经的处理器，可返回 block 阻断 | 「无论模型怎么决定都执行」的强制点——LLM 指令 ≠ 应用层强制 | 与 CLAUDE.md 指令混淆——前者强制、后者建议 |
| Hooks | 钩子 | 生命周期事件触发的自动化：shell/HTTP/MCP 工具/LLM prompt/subagent | 把审批、审计、lint 接进 agent loop 的标准插槽 | 与 plugins 混淆——hook 是事件机制，plugin 是分发打包 |
| Exit Code 2 | （hook）阻断退出码 | hook 脚本以 2 退出即阻断该工具调用 | 最小可用的 deny 通道（pretooluse_guard.py 示例的核心） | 与普通脚本错误码混淆——2 是语义化 block 信号 |
| Skills | 技能 | 一个 SKILL.md 装知识/流程；/name 手动调用或相关时自动加载，正文用时才载入 | 长参考资料的「几乎零成本」容器；遵循 Agent Skills 开放标准 | 与旧 custom commands 混淆——已合并，二者等价 |
| Bundled Skills | 内置技能 | 官方自带的提示词驱动技能：/doctor、/code-review、/batch、/debug、/loop 等 | 区分「提示词驱动技能」与「固定逻辑命令」（/help、/compact） | 与 built-in commands 混淆——前者模型编排，后者固定逻辑 |
| Subagents | 子代理 | 独立上下文窗口的专职代理：自定义 system prompt、受限工具、独立权限，完成后只回摘要 | context 隔离 + 最小权限 + 成本路由三合一；description 合计 >15,000 tokens 告警 | 与「多开几个会话」混淆——subagent 由主会话自动委派 |
| Explore / Plan Subagents | 探索/规划子代理 | 内置只读代理：Explore 做大探索、Plan 在 plan 模式做研究，均禁 Write/Edit | 官方对「大规模探索污染主上下文」的标准答案 | 以为 Explore 固定跑 Haiku——模型继承主会话 |
| Plan Mode | 规划模式 | 一种 permission mode（plan）：只读探索 + 产出计划供人审 | 把 human approval 插进 agent loop 的标准位置（高危变更先审后动） | 老教程的独立 plan-mode 页面说法已过时 |
| Tool Search / Deferred Tools | 工具搜索/延迟加载 | MCP 工具默认只在上下文放名字列表，schema 按需载入（ENABLE_TOOL_SEARCH 可调） | MCP 规模化的上下文成本治理 | 与 transport 选择混淆——一个管 schema 加载，一个管连接 |
| .mcp.json | 项目 MCP 配置 | 随仓库分发的 MCP server 清单，团队/CI 环境一致 | 「配置入库 + token 走环境变量」是团队协作基线 | 把 token 写进 .mcp.json——绝不入库 |
| Plugins / Marketplaces | 插件/插件市场 | 把 skills+hooks+subagents+MCP 打包（.claude-plugin/plugin.json）经 marketplace 分发 | 跨仓库复用与组织内推广的分发层；先 standalone 后打包 | 与 skills 混淆——plugin 是打包格式，不是新能力类型 |
| Context Window Management | 上下文窗口管理 | /context 诊断、/compact 压缩、/clear 重开；启动时分层自动加载 | context 是 agent 最稀缺资源；隔离（subagent）优先于压缩（compact） | 以为 /compact 无损——它是有损摘要 |
| Prompt Caching (Claude Code) | 提示缓存 | Claude Code 自动管理的前缀缓存 | 成本/延迟优化：模型切换触发无缓存慢轮次；CLAUDE.md 中途改动不生效 | 与 API 侧手动 cache_control 混淆——Code 里是自动的 |
| Checkpointing | 检查点 | /rewind 把代码与对话回滚到检查点 | agent 事故的可恢复性设计（对照模块 10 故障处理） | 与 git 混淆——它连对话状态一起回滚 |
| Headless / Print Mode (-p) | 无头/打印模式 | claude -p "..." 非交互运行，用于 CI/脚本 | 自动化管道的接入点；配合 dontAsk + 最小 allow + hook 兜底 | 与「绕过所有权限」混淆——无人值守更要收紧 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Observability | 可观测性 | 从系统外部输出（logs/metrics/traces）推断内部状态的能力——「不打开机器就能知道哪坏了」 | 生产 Claude 应用的三支柱具体化为 request-id 透传、usage 记账、OTel span 链路；没有它，故障只能靠猜 | 与「监控 (monitoring)」混淆——监控是预设问题的看板，可观测性支持未预设的探索式排查 |
| Auditability | 可审计性 | 能回答「过去某时某刻系统做了什么、依据什么配置与版本」 | 决策留痕 + 配置版本 + Usage Export 对账；合规行业（金融/医疗）的硬要求 | 与 Observability 混淆——一个管「现在怎么样」，一个管「当时凭什么」；保留策略与访问控制也不同 |
| Redaction | 脱敏 | 日志入库前把 PII/密钥替换为占位符 | 日志管道入口的集中式过滤器；「记了不该记的」是最常见合规事故 | 与「加密」混淆——脱敏是不可逆移除信息，加密可逆且密钥管理是新风险 |
| PII (Personally Identifiable Information) | 个人身份信息 | 能定位到具体自然人的信息（姓名/邮箱/证件号/病历） | 生产日志/缓存/训练回流的红线判断依据；prompt 里的 PII 决定日志与留存策略 | 与「敏感业务数据」混淆——商业机密不属 PII 但同样不能裸记 |
| Retry with Exponential Backoff | 指数退避重试 | 失败后等 base×2^n + 抖动再试，越等越久 | 官方 SDK 默认对瞬时错误重试 2 次；生产要在超时预算内显式化同一策略 | 与「无限重试」混淆——退避重试有次数与预算上限 |
| Jitter | 抖动 | 退避等待上加随机量 | 防止同批请求同步重试形成 thundering herd | 与「随机延迟」混淆——抖动是退避的修正项，不是独立延迟 |
| Thundering Herd | 惊群 | 大量客户端同时重试，压垮正在恢复的上游 | 529 过载期设计重试策略的核心反面教材；熔断器存在的理由 | 与「限流」混淆——惊群是故障模式，限流是治理手段 |
| Fallback | 降级 | 主路径失败时切换到更便宜/更慢但可用的替代路径（次级模型/无检索/模板） | 需要三件套：显式声明 degraded、指标单独计数、可恢复切回 | 与「重试」混淆——重试打同一目标，降级换目标 |
| Escalation | 人工升级 | 把决策权交还人类（低置信/不可逆操作/降级链打穿/合规复核） | 生产架构一等公民：队列 + 结构化上下文协议 + 处置回写 + 审计；升级率是核心监控指标 | 与「报错给用户」混淆——升级携带上下文交接给人工，不是甩锅 |
| Circuit Breaker | 熔断器 | closed→open→half-open 三态开关：连续失败即快速失败走降级，冷却后探测恢复 | 529/区域故障时保护上游与用户耐心；调参=阈值/冷却/探测流量 | 与「重试上限」混淆——重试上限管单请求次数，熔断管系统对系统级的熔断 |
| Timeout Budget | 超时预算 | 请求级总时限向下分配给每次尝试与等待 | 防「多层各 30s 叠成 90s」的放大事故；预算耗尽即降级 | 与「单层超时」混淆——预算是跨层传递的共享资源 |
| Rate Limit | 限流 | 单位时间请求数/token 数上限（RPM/ITPM/OTPM），token bucket 算法持续补充 | 429+retry-after 的等待依据；限流是「组织级」而非「用户级」 | 与 Spend Limit 混淆——限流管速率，spend cap 管月度总额；两者 429 形态不同 |
| Spend Limit | 支出上限 | 月度成本上限；tier 触顶 429 无 retry-after，自设限额触顶 400 | 必须区分两类错误形态：重试只对前者有效 | 与 Rate Limit 混淆（见上）——细节是 error_code 与 retry-after 的有无 |
| Token Bucket | 令牌桶 | 以恒速补充令牌、请求消耗令牌的限流算法；容量可攒 | 解释「限流可能在更短窗口被强制执行」与突发行为 | 与「固定窗口计数」混淆——令牌桶允许受控突发 |
| Prompt Caching | 提示缓存 | 相同前缀复用缓存：写 ×1.25(5m)/×2(1h)、读 ×0.1、命中免费续期 | 稳定前缀应用的省钱+提速+提吞吐三合一；缓存读取不计 ITPM | 与「响应缓存」混淆——提示缓存按前缀哈希复用 KV，语义完全不同 |
| Cache Breakpoint | 缓存断点 | cache_control 标记的位置；条目=从头到断点的哈希；回看窗口 20 块 | 断点放错（每轮变化的块）=永远全款写入永不命中；放「跨请求不变的末块」 | 与「缓存自动找稳定内容」的想象混淆——回看找的是先前写过的断点条目 |
| Message Batches API | 批处理 API | 异步提交大批 Messages 请求，全量半价，多数 1 小时内完成 | 离线批量（评估/审核/生成）的成本杠杆；不支持 stream/fast mode/Threads/max_tokens:0 | 与「并发调用」混淆——batch 是异步提交整体调度，不是并发限流技巧 |
| Model Tiering / Routing | 模型分层路由 | 按任务难度把请求分给 Haiku/Sonnet/Opus/Fable 不同档位 | 决策依据=evals 通过率×单价×延迟，而非「越大越好」；路由器成本计入总账 | 与「模型升级」混淆——分层是同一时刻的空间切分，升级是时间上的版本迁移 |
| Version Pinning | 版本锁定 | 生产固定用带日期快照模型 ID（如 claude-haiku-4-5-20251001）而非漂移别名 | 保证「今天的行为=上周评估过的行为」；模型 ID 是配置不是代码 | 与「API 版本头」混淆——anthropic-version 锁协议，快照 ID 锁模型行为 |
| Canary Release / Gradual Rollout | 灰度发布 | 新版本按 1%→5%→25%→100% 承接流量，异常即回滚 | 模型升级的标准发布形态；稳定哈希避免同用户体验抖动；新旧分标签对比 | 与「A/B 测试」混淆——灰度是发布安全机制（目标=可回滚），A/B 是效果实验（目标=选优） |
| Regression Evaluation | 回归评估 | 用 golden dataset 对比新旧模型/配置的任务通过率，防行为退化 | 模型升级/退役迁移的前置门槛；模块 12 展开为完整 evals 体系 | 与「测试」混淆——evals 评概率性行为的质量分布，不是确定性断言 |
| Workload Identity Federation | 工作负载身份联合 | 云平台身份换短时效 token，无静态密钥 | 官方对生产负载/CI/CD/K8s 的推荐认证方式——消除静态 secret 的轮换与泄露面 | 与「API key 轮换」混淆——轮换是缓解，Federation 是根治（token 分钟级过期） |
| request-id | 请求标识 | 每个响应自带的唯一 ID（req_ 前缀），报障与对账钥匙 | 结构化日志必挂字段；AWS 上另有 x-amzn-requestid 主 ID | 与 trace-id 混淆——request-id 对 Anthropic 侧，trace_id 对你内部链路 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Prompt Injection | 提示注入 | 以文本为载体改写模型行为:把「数据」伪装成「指令」喂给模型 | 一切 LLM 应用的第一攻击面;防御分层设计的出发点 | 与传统代码注入混淆——这里没有解析器漏洞,是语义层被劫持 |
| Direct Prompt Injection / Jailbreak | 直接注入/越狱 | 应用用户自己构造恶意输入绕过护栏 | 威胁模型决定防御选型:输入筛查、harmlessness screen、处置惯犯 | 与间接注入混淆——前者用户即攻击者,后者用户是受害者 |
| Indirect Prompt Injection | 间接注入 | 载荷藏在模型代为处理的第三方内容里(邮件正文/网页/OCR/工具结果) | RAG 与 agent 场景最危险的形态;数据管道即攻击面 | 与「用户输入校验」混淆——入口根本不在用户侧 |
| LLM Instruction vs Application Enforcement | 模型指令 ≠ 应用层强制 | prompt 里写禁令只是影响模型「倾向」,授权必须由应用代码确定性执行 | 本模块第一原则:安全评审时先问「这条期望由哪段代码强制?」 | 与「提示工程做好了就安全」混淆——概率层永远有漏判 |
| Least Privilege | 最小权限 | 给 agent 的工具/数据/网络面砍到「任务刚好够用」 | 决定注入成功后的 blast radius;只读 agent 可部署面更广 | 与「权限越多越能干」的效率思维混淆——能力面=战果面 |
| Blast Radius | 战果上限/爆炸半径 | 一次失守(注入成功)能造成的最大伤害 | 隔离选型的核心指标:先定可接受上限,再倒推工具面 | 与「攻击概率」混淆——降概率(分类器)与封顶(沙箱)是两件事 |
| Defense in Depth | 纵深防御 | 概率层(筛查/模型抗性)+ 确定性层(网关/沙箱/egress)叠加 | 任何单层都有已知失效模式;缺一层就把该层失效变成系统失效 | 与「多重弹窗」混淆——层间要互补而非重复 |
| Human-in-the-Loop / Approval Gate | 人工审批门 | 高危动作先经人批准再执行 | 对低频高危有效;前提是用户能评估风险且审批不密集 | 与「有人看就安全」混淆——93% 批准率下人审近似摆设 |
| Approval Fatigue | 审批疲劳 | 弹窗越多,人对每个弹窗越不细看,批准率飙高 | 决定审批门的适用边界;官方因此做沙箱/auto mode 减少弹窗 | 与「用户素质问题」混淆——是系统性注意稀释,换人也一样 |
| Sandbox | 沙箱 | 对 agent 可触达的文件/网络/进程画硬边界(容器/OS 级/VM) | 确定性边界的主力;隔离强度要匹配用户监管能力 | 与「虚拟环境」混淆——目标是安全边界不是运行隔离 |
| Egress Control | 出站流量控制 | 限制 agent 能向哪里发数据(域名白名单、代理、默认断网) | 唯一能挡住「钓鱼+顺从模型」组合的防线;数据外传的最后一闸 | 与「入站防火墙」混淆——LLM 安全的主战场在出站 |
| Allowlist as Capability Grant | 白名单即能力授予 | 放行一个域名=授予它背后全部 API 功能面(上传/分享/发消息) | 白名单设计要按 API 能力粒度评估,不能停在域名层 | 与「目的地过滤器」混淆——Cowork 经 api.anthropic.com 外泄即反例 |
| tool_result Channel | 工具结果通道 | API 中承载工具输出的消息块;官方指定为不可信内容的唯一入口 | 结构化隔离:数据与指令分层,配合 JSON 编码防「越狱定界符」 | 与 user text 混淆——把网页正文贴进 user 消息是最常见错误 |
| Harmlessness / Injection Screen | 无伤害筛查/注入筛查 | 用轻量模型(如 Haiku)+ structured output 在前后端做布尔分类 | 廉价可扩展的概率层;判定结果供应用代码分支(拒绝/剥离/放行) | 与「内容过滤中间件」混淆——它输出给应用分支,不是自行拦截 |
| Zero Data Retention (ZDR) | 零数据留存 | 推理完成后不把 prompt/响应持久化到长期存储的企业选项 | 合规架构的基线选项;covered models 有 30 天留存例外(截至 2026-08-30) | 与「不训练」混淆——不训练是默认条款,ZDR 是留存维度的更强承诺 |
| PII Redaction / Data Residency | 个人信息脱敏/数据驻留 | 出边界前替换敏感字段;数据物理/合规地留在指定云或区域 | 面向安全评审的必答题;影响模型接入路径选择(直连 API vs Bedrock/Vertex/Foundry) | 与「加密传输」混淆——TLS 保完整性与机密性,不解决「送了什么」 |
| Confused Deputy | 混淆代理 | 被信任的中间组件被诱导,替攻击者行使它自己的权限 | MCP proxy 的典型漏洞形态;per-client consent 是官方对策 | 与普通钓鱼混淆——受害者是「有权限的代理」而非人 |
| Token Passthrough | 令牌直通 | MCP server 不校验令牌归属就直接透传给下游 API 的反模式 | MCP 规范明令禁止;审计断链+信任边界混乱 | 与「代理转发」混淆——合法代理用自己的凭证且可审计 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Evaluation (Eval) | 评估 | 给 AI 系统的测试：喂输入，用评分逻辑量输出 | 把「感觉变好」变成可回归、可门禁的数字；CI 的第一道防线 | 与「线上监控」混淆——eval 有 ground truth 且可复现，监控没有 |
| Golden Dataset / Golden Answer | 金标数据集 / 金标答案 | 人工确认的正确答案库；eval 的比对基准 | 题目分布 ≈ 生产分布才有意义；held-out 子集用于汇报 | 与「训练集」混淆——金标只用来打分，不参与训练/调参汇报 |
| Task / Trial | 任务 / 试验 | Task=一道题（输入+成功标准）；Trial=这道题的一次尝试 | 模型非确定 → 每 task 多 trial，用 pass@k / pass^k 汇总 | 与「一次 API 调用」混淆——一个 task 可能几十次调用 |
| Grader / Assertion | 评分器 / 断言 | 给表现某方面打分的逻辑；一个 grader 可含多条断言 | 分层评分的载体：state/tool/rubric 各配各的 | 与「指标」混淆——grader 是判分动作，指标是聚合结果 |
| Transcript (Trace / Trajectory) | 转录 / 轨迹 | 一次 trial 的完整记录：输出、工具调用、推理、中间结果 | 排障与「读 transcript」校准的原始材料；API 场景=完整 messages 数组 | 与 Outcome 混淆——说得好不等于做成了 |
| Outcome | 结果（环境终态） | trial 结束时环境的最终状态（数据库/文件/工单） | Task Success 的唯一可靠判据（state_check） | 与 Transcript 混淆——高频考点 |
| Evaluation Harness | 评估脚手架 | 端到端跑评估的基础设施：下发、并发、记录、评分、汇总 | CI 门禁的载体；要求环境隔离、与生产同构、可回放 | 与 Agent Harness 混淆——前者测后者 |
| Agent Harness (Scaffold) | 智能体脚手架 | 让模型作为 agent 行动的执行系统 | 评估对象 = harness + 模型的组合体 | 与「评估 harness」混淆 |
| Code-based Grading | 代码评分 | exact/string match、单元测试、state_check、tool_calls 校验 | 官方第一优先：最快最可靠最可扩展；对合法变体脆 | 与「低级/简陋」划等号——它是首选而非妥协 |
| Model-based Grading (LLM-as-Judge) | 模型评审 | 用 LLM 按 rubric 给输出打分（可先推理后结论） | 开放式任务的主力；必须 rubric 化 + Unknown 出口 + 人工校准 | 与「自动正确」混淆——judge 自己会幻觉，未校准不可信 |
| Human Grading / Spot-check | 人工评分 / 抽检 | SME 或众包人工判分；抽样审读 | 金标准；主要用于校准 judge 与建金标，不适合全量 | 与「必须全量人审」混淆——官方建议少量点睛 |
| Rubric | 评分细则 | 给 judge 的可执行判分标准（「第一句必须提到 X 否则 incorrect」） | rubric 质量直接决定 judge 质量；改 rubric 要重校准 | 与「prompt 随便写写」混淆——rubric 是合同不是寒暄 |
| Reference Solution | 参考解 | 一份已知能通过所有 grader 的输出 | 证明题目可解、grader 配置正确；0% 通过率先查它 | 与 Golden Answer 混淆——参考解是给「任务」验身的，金标答案是给「输出」判分的 |
| Capability Evals | 能力评估 | 测「能做好什么」，故意选做不好的题，低通过率 | 爬坡目标；给团队一座要爬的山 | 与 Regression Evals 混淆——期望通过率相反 |
| Regression Evals / Regression Testing | 回归评估 / 回归测试 | 测「过去会的现在还会吗」，期望 ≈100% | CI 门禁；分数下降即「有东西坏了」 | 与「重跑一次看看」混淆——它是带锁定题集与阈值的门禁 |
| Eval Saturation | 评估饱和 | 套件全通过后分数不再提供改进信号 | 高分≠无事可做：旧题毕业进回归套件、补新难题 | 与「模型到顶了」混淆——常是套件到顶了 |
| pass@k / pass^k | k 次至少一成 / k 次全成 | pass@k=k 次里至少一次成功（随 k 升）；pass^k=全部成功（随 k 降） | 产品决策看 pass^k（75%³≈42%）；研发爬坡看 pass@k | 两者混用——k 大时讲相反的故事 |
| Task Success Rate | 任务成功率 | 以 outcome 状态校验的任务完成比例 | 用户视角的终极质量指标；transcript 收尾不算数 | 与「回答完整率」混淆 |
| Tool Correctness | 工具正确性 | 该调的调了、参数合规、不该调的没调、规则顺序正确 | agent 安全与合规的代码级审计面（amount ≤100 类断言） | 与「逐步路径校验」混淆——官方：评产出不评路径 |
| Groundedness | 接地性 | 回答的每个主张被检索证据支撑的比例 | RAG 质量核心；Citations 让逐主张溯源程序化 | 与 accuracy 混淆——有据≠正确，正确≠有据 |
| Hallucination Rate / Abstain Rate | 幻觉率 / 弃答率 | 无支撑未弃答主张占比 / 「我不知道」占比 | 必须成对上报，否则全拒答可刷出幻觉率 0 | 只报幻觉率不报弃答率——新的作弊方向 |
| Recall@k / Precision@k | 查全率 / 查准率@k | 前 k 结果覆盖金标比例 / 前 k 中相关比例 | RAG 默认 recall 优先；precision 管上下文预算 | recall 单看——加大 k 就能作弊 |
| MRR (Mean Reciprocal Rank) | 平均倒数排名 | 第一个相关结果排名倒数的平均 | 单正确答案问答的排序指标 | 与 nDCG 混淆——MRR 只看第一个命中 |
| nDCG (normalized Discounted Cumulative Gain) | 归一化折损累计增益 | 分级相关度 + 排名位置对数折损，再按理想排序归一 | 完美块该排在沾边块前面的排序质量度量 | 与 recall 混淆——nDCG 关心「排在第几」，不只「进没进」 |
| TTFT (Time to First Token) | 首 token 延迟 | 发送 prompt 到吐出第一个 token 的时间 | streaming 场景用户感知响应速度的决定项 | 与总时长混淆——TTFT 好总时长也可能差 |
| Baseline Latency | 基线延迟 | 模型处理 prompt 并生成响应的时间（不含量纲视角） | 延迟监控的基础口径，与 TTFT 分开报 | 与 TTFT 混淆 |
| Cost per Task | 每任务成本 | 完成一个任务的全部调用成本（多轮×token×重试放大） | 预算与门禁的正确粒度；配 token 预算 grader | 与每请求成本混淆 |
| Distribution Drift | 分布漂移 | 输入分布/模型行为/语料随时间偏离基线 | 生产监控的核心告警对象；回归套件是离线探针 | 与「随机波动」混淆——漂移是持续偏移 |
| Escalation Rate（业界通称） | 人工接管/升级率 | 会话转人工或用户放弃 agent 的比例 | 逃逸指标族（改写率/接管率/放弃率）：用户视角的任务失败代理 | 与「质量分」混淆——它不说哪层坏，只说变差了 |
| Inter-annotator Agreement | 标注者间一致性 | 多个人工标注者互相一致的程度 | 人审与金标自身的质量度量；judge 校准的分母 | 与「标注越多越好」混淆——不一致的标注是噪声 |
| 英文术语 | 中文翻译 | 通俗解释 | 架构师相关性 | 常见混淆 |
|---|---|---|---|---|
| Reference Architecture | 参考架构 | 一套经过论证的组件拓扑与职责划分模板（网关→编排→模型/检索/工具/状态→人审），项目照着裁剪 | 架构评审的「共同语言」；Capstone 交付物本体 | 与「技术选型清单」混淆——参考架构回答职责与路径，不是购物车 |
| Data Plane vs Control Plane | 数据面 vs 控制面 | 数据面是请求实时走过的路径；控制面是管理配置/策略/评估/发布的路径 | 「这笔退款为什么被批准」要能在控制面回放（配置版本+策略依据）；两面分离是可审计性的前提 | 与「前端/后端」混淆——那是部署分层，这是职责分层 |
| Deflection Rate | 自动解决率 | 无需人工坐席就解决的会话占比 | 客服类系统的第一业务指标；与升级率此消彼长，必须一起看 | 与「自动化率」混淆——模型回了话不等于解决了问题 |
| Escalation Rate | 升级率 | 转人工的会话占比 | 人审容量规划（C7）与质量信号的双面指标：过低可能是该升不升，过高是坐席崩溃 | 「越低越好」是误区——审批红线（>200 退款）撑高它是设计使然 |
| Approval Gate | 审批门 | 高危/不可逆动作的强制人工检查点：模型只能创建冻结态申请，人批准后代码执行 | 「LLM 指令 ≠ 应用层强制」的物理落点；与审计事件（谁/依据/结果）配套 | 与 Permission Gate 混淆——权限门管「能不能调」，审批门管「调了之后要不要人点头」 |
| Structured Handoff | 结构化交接 | 升级人工时传给坐席的结构化上下文（摘要+已执行动作+证据+建议处置） | 人审效率的杠杆：坐席不读 30 轮聊天记录也能接手；处置结果回写评估集 | 与「转发聊天记录」混淆——那是原始数据不是交接协议 |
| Blast Radius | 爆炸半径 | 单点失效/被攻陷后能波及的范围 | 能力面设计的度量：最小工具面+数据范围过滤都在收缩它；admin token 直接放大它 | 与「影响人数」混淆——还包括可执行动作的种类与深度 |
| Graceful Degradation | 优雅降级 | 依赖故障时系统降低能力继续服务而非直接失败 | R8 类需求（「降级可用」）的实现概念；白屏是它的反例 | 与 Fallback Chain 混淆——降级是行为，链是实现它的结构 |
| Fallback Chain | 降级链/后备链 | 预定义的逐级退路：强模型→弱模型→模板+表单→人工 | 每级触发条件必须是代码；链末端必须有人工兜底 | 与「重试」混淆——重试是同级的再来一次，降级是换更弱但更稳的方案 |
| Circuit Breaker | 熔断器 | 连续失败后自动「开路」快速失败，冷却后半开试探恢复 | 防重试风暴烧穿预算与下游；开路期间新请求直接走降级 | 与「限流」混淆——限流按速率挡，熔断按健康度挡 |
| Error Budget | 错误预算 | 可用性目标换算出的「允许出错量」（如 99.5% → 每月约 3.6 小时不可用） | 把「可靠性多贵」变成可消费的额度：预算烧完就冻结发布换稳定 | 与「重试预算」混淆——那是单请求内的重试额度，这是系统级的月度额度 |
| SLO / SLA / SLI | 服务目标/协议/指标 | SLI 是测出来的指标，SLO 是内部目标，SLA 是对客户的合同承诺 | 需求量化语言：R6（首字 p50≤5s）是 SLO；三件套对齐才能验收 | 三者混用——面试/评审常见扣分点 |
| Cost per Resolution | 单次解决成本 | 每自动解决一个会话的 API 成本（含缓存/分摊） | 把「省钱」变成可监控可告警的架构指标（R7 的 $0.10） | 与「每 token 价格」混淆——前者含路由/缓存/路径分布的结构效应 |
| Publish Gate | 发布门 | 变更（模型/prompt/检索/策略）必须通过的评估阈值才能发布 | 「无评估不上线」的机制化：阈值（groundedness≥95% 等）写在门上不写在人脑里 | 与「CI 通过」混淆——单测绿不等于业务质量达标 |
| Canary Release | 灰度发布 | 新版本按 1%→5%→25%→100% 逐步接流量，指标分标签对比，异常自动回滚 | 控制爆炸半径的标准手段；稳定哈希分流避免体验抖动 | 与「蓝绿部署」混淆——蓝绿是全量切换两环境，灰度是比例渐变观测 |
| Data Flywheel | 数据飞轮 | 坐席改写/否决、低置信会话等线上信号回流进评估集的闭环 | 评估集从一次性测试变成活资产； Capstone 评估体系的长期造血机制 | 与「日志留存」混淆——留存是存下来，飞轮是标注后进回归 |
| Architecture Decision Record (ADR) | 架构决策记录 | 一条决策的「上下文+选项+选择+后果+放弃项」短文档 | 决策工作簿的工程化形态；「为什么当时不用 X」半年后还能答上来 | 与「设计文档」混淆——ADR 一事一记且不可变（废止就标 superseded） |
| Least-Privilege Tool Surface | 最小权限工具面 | 模型可见的工具集合被压到完成任务所需的最小集 | 「不能做 X」的正确实现是「不给做 X 的工具」；能力面=攻击面 | 与「工具越少越好」混淆——是按任务必要裁剪，不是无脑删 |