AI 工程与 GEO 术语表

面向生成式 AI 引擎（如 ChatGPT、Perplexity、Claude）的网站优化方法，目标是被 AI 正确抓取、理解并引用。与 SEO 的区别在于：SEO 面向搜索引擎蜘蛛，GEO 面向 AI 引擎。

大语言模型，指基于 Transformer 架构、经过海量文本训练的深度学习模型，能够理解和生成自然语言。代表模型包括 GPT 系列、Claude 系列、通义千问、DeepSeek 等。

一种基于 JSON 的结构化数据格式，用于在网页中嵌入机器可读的语义信息。搜索引擎和 AI 引擎通过 JSON-LD 理解网页的实体类型（如组织、文章、FAQ、产品）。

由 Google、Microsoft、Yahoo 和 Yandex 联合发起的结构化数据词汇表，定义了数百种实体类型和属性。JSON-LD 是最推荐的 Schema.org 实现方式。

结论前置的内容结构——先给出核心结论，再展开论证。AI 引擎在抓取内容时优先读取页面开头部分，BLUF 结构能提高被 AI 正确引用的概率，是 GEO 优化的关键内容策略。

一种网站根目录下的文本文件，为 AI 代理（如 ChatGPT、Claude 的爬虫）提供网站导览，列出核心页面和爬虫规则。是 GEO 基建中与 robots.txt 互补的关键文件。

AI 引擎用于抓取网页内容的自动化程序。与搜索引擎爬虫（Googlebot、Bingbot）不同，AI 爬虫（如 GPTBot、ClaudeBot、PerplexityBot）的主要目的是为 LLM 收集训练和推理数据。

检索增强生成，一种将信息检索与文本生成相结合的 AI 架构。LLM 在生成回答前先从外部知识库检索相关文档，将检索结果作为上下文注入提示词，从而减少幻觉、提高回答的时效性和准确性。

大语言模型处理文本的基本单位。一个 Token 可以是一个词、一个子词或一个字符。中文语境下，一个字通常对应 1-2 个 Token。Token 也是 API 调用的计价单位——输入和输出都按 Token 数计费。

提示词工程，通过设计输入文本（提示词）来引导 LLM 产生期望输出的技术。包括 Few-shot（给示例）、Chain-of-Thought（引导推理步骤）、System Prompt（设定角色和行为边界）等方法。

结构化数据，以标准化格式（如 JSON-LD、Microdata）嵌入网页的机器可读数据，帮助搜索引擎和 AI 引擎理解网页内容。核心类型包括 Organization、WebPage、Article、FAQPage、BreadcrumbList、DefinedTermSet 等。

静态站生成，在构建时预渲染所有页面为 HTML 文件，部署时无需服务器端运行时。Astro、Next.js（静态导出）、Hugo、11ty 等框架支持 SSG。纯静态站对 AI 爬虫最友好——无需 JavaScript 即可读取完整内容。

HTML 中的语言标记属性，告诉搜索引擎和 AI 引擎同一内容的不同语言版本之间的对应关系。正确的 hreflang 配置能防止多语言网站被判定为重复内容，并让 AI 引擎在回答时引用正确语言版本。

规范 URL，在 HTML 头部用 `<link rel="canonical">` 声明当前页面的权威版本 URL。当同一内容可通过多个 URL 访问时，canonical 告诉搜索引擎和 AI 引擎哪个是原始出处，避免权重分散。

站点地图（sitemap.xml），列出网站所有重要页面的 URL、最后修改时间和更新频率。搜索引擎和 AI 爬虫通过 sitemap 发现和索引网站内容，是 GEO 基建的标配。

Schema.org 定义的 FAQ 页面结构化数据类型。每对问答（Question + Answer）独立标记，AI 引擎在回答相关问题时可直接引用 FAQ 中的答案。是 GEO 优化中效果最直接的结构化数据之一。

知识图谱，以实体和关系为核心的结构化知识库。搜索引擎和 AI 引擎通过知识图谱理解实体之间的关联（如"ChatGPT 是 OpenAI 的产品"）。网站可以通过 JSON-LD 输出实体关系，帮助 AI 引擎构建更准确的知识关联。

嵌入向量，将文本、图像等非结构化数据映射到高维向量空间的技术。语义相似的文本在向量空间中距离更近，Embedding 是 RAG、语义搜索、推荐系统的基础技术。

微调，在预训练 LLM 的基础上用特定领域的数据进一步训练，使模型在特定任务上表现更好。与 RAG 的区别：微调改变模型参数，RAG 不改变参数只改变输入上下文。

模型上下文协议，由 Anthropic 提出的开放协议，定义了 AI 模型与外部工具和数据源之间的标准化交互方式。MCP 使 LLM 可以安全地调用 API、查询数据库、读写文件，是 AI 代理（AI Agent）的基础设施。

MCP 协议中的服务端进程，向模型/应用暴露三种能力原语：Tools（可执行动作，如查订单）、Resources（只读数据，如知识库文档）、Prompts（预置提示词模板）。Server 写一次即可被所有支持 MCP 的客户端复用，是"工具写一次、到处用"的关键。生产部署要点：鉴权（OAuth/API Key）、超时重试、幂等、错误信息写给模型看、调用可观测性。

MCP 协议中的客户端，运行在 AI 应用（Host）内部，负责与一个或多个 MCP Server 通信。Host 与 Server 是一对多关系：一个应用可挂多个 Server，一个 Server 也可服务多个 Host。传输方式两种：stdio（本地子进程，零网络暴露）与 HTTP+SSE（远程部署，需鉴权与 TLS）。

上下文工程，系统性地设计和编排送入 LLM 的上下文内容（系统提示词、检索结果、工具调用结果、历史对话），以控制模型行为的工程实践。与 Prompt Engineering 的区别：Prompt 是写好一条提示词，Context Engineering 是管理整个上下文生命周期——放什么、放多少、顺序如何、成本多少（Token 成本常被工具返回结果重新入上下文的开销吞噬）。

模型路由，按请求特征把任务分发给最合适的模型规格的机制。三种实现：规则路由（按接口/字段/用户分层分流）、语义路由（用 Embedding 匹配任务意图再分流）、级联路由（先小模型后大模型，质量不达标再升级）。价值：把全量流量从旗舰模型按 8:2 分流到小模型，综合成本降 50%-80% 而复杂任务质量不变。前提是先建"每类任务 × 每个模型"的能力-成本评测基线。

提示词缓存，模型供应商侧的 KV 缓存机制：相同前缀（系统提示词、长文档）的多次请求从第二次起按缓存命中价（通常 10%-25%）计费。工程要点：提示词"前静后动"——固定内容放前缀、变化内容放后面，最大化命中。对长上下文场景（几百页文档问答、超长系统提示、多轮对话）输入 Token 成本可降 75%-90%。

语义缓存，应用侧的缓存机制：通过 Embedding 相似度判定请求意图是否相同，命中后直接返回历史答案，完全跳过模型调用。与 Prompt Caching 的区别：前者省整个调用，后者只省重复重算输入 Token 的钱。核心是失效策略——知识更新、价格变动时用缓存键版本号、热点 TTL 缩短、敏感类目跳过缓存。

级联路由，先让便宜小模型作答，质量存疑时逐级升级到中档、旗舰模型重算的降本策略。质量判定三种方式：结构化自评（模型输出置信度）、规则校验（JSON Schema/字段存在性）、判别器模型（小分类模型判断答案是否达标）。收益：平均成本接近小模型，最差质量兜在旗舰水平。

持续集成与持续部署，一种自动化软件交付实践。CI 指频繁将代码变更合并到主干并自动运行测试；CD 指通过自动化流水线将验证通过的代码部署到生产环境。GitHub Actions、GitLab CI 是主流 CI/CD 工具。

一种容器化平台，将应用及其依赖打包到轻量级、可移植的容器中，确保在不同环境中一致运行。Docker Compose 用于编排多容器应用（如 Web 服务 + 数据库 + 缓存），是中小项目部署的主流选择。

一种用于描述 RESTful API 的接口规范标准（原 Swagger 规范）。通过 OpenAPI 规范文件，可以自动生成 API 文档、客户端 SDK 和 Mock 服务，是 API 契约式开发的核心工具。

微服务架构，将应用拆分为多个独立部署的小型服务，每个服务对应一个业务子域，通过轻量级通信协议（REST/gRPC/消息队列）协作。与单体架构相比，微服务允许独立部署、独立扩容、独立团队，但引入了分布式事务、服务治理等额外复杂度。

API 网关，位于客户端与后端服务之间的中间层，负责请求路由、认证授权、限流熔断、协议转换等横切关注点。在多供应商 Token 聚合场景中，API 网关还承担路由决策（按价格/延迟分发请求）和容错（熔断降级）职责。

Google 开发的开源自动化工具，用于审计网页的质量，涵盖性能（Performance）、可访问性（Accessibility）、SEO、最佳实践（Best Practices）和 PWA 五个维度。Lighthouse 分数是衡量前端性能优化效果的重要参考指标。

Google 定义的一组核心网页性能指标，包括 LCP（最大内容绘制，衡量加载性能）、CLS（累积布局偏移，衡量视觉稳定性）、TBT（总阻塞时间，衡量交互响应）。这些指标直接影响搜索排名和用户体验评分。

Google 开发的新一代图像格式，支持有损和无损压缩，以及透明通道和动画。相比 PNG，WebP 的无损压缩体积平均减少 26%；相比 JPEG，有损压缩体积平均减少 25-34%。本站所有图片已从 PNG 转为 WebP，总体积缩减 89%。

服务端渲染，在服务器端将页面渲染为完整 HTML 后发送给客户端。与 SSG（静态生成）的区别在于：SSR 在每次请求时动态生成 HTML，适合需要实时数据的页面；SSG 在构建时预生成 HTML，适合内容相对固定的页面。Next.js 同时支持 SSR 和 SSG 两种模式。

高性能 Web 服务器与反向代理服务器，也常用于负载均衡、HTTP 缓存、SSL 终端和静态资源服务。本站使用 Nginx 作为前端服务器，负责 HTTPS 终止、静态资源服务、安全头注入和反向代理配置。

一种基于 JSON 的开放标准（RFC 7519），用于在各方之间以安全的方式传输信息。JWT 由 Header、Payload、Signature 三部分组成，常用于 API 认证和授权。特点是无状态（服务端不需要存储 Session），但无法主动撤销，适合短期过期的 Token 场景。

一种开放授权标准，允许用户将特定资源的访问权限授予第三方应用，而不需要共享密码。OAuth 2.0 是当前主流版本，定义了四种授权流程：Authorization Code（最常用，用于第三方应用访问用户数据）、Client Credentials（服务间通信）、Password（第一方应用，不推荐）、Implicit（已废弃，由 PKCE 替代）。

跨域资源共享，一种基于 HTTP 头的机制，允许服务器声明哪些来源（域名、协议、端口）可以访问其资源。浏览器默认阻止跨域请求，CORS 通过在响应头中设置 Access-Control-Allow-Origin 来安全地解除限制。生产环境应将 CORS 配置为白名单模式，只允许可信任的域名。

一种在单个 TCP 连接上实现全双工通信的协议。与 HTTP 的请求-响应模式不同，WebSocket 建立连接后，客户端和服务端可以随时向对方推送数据，适合聊天、实时协作、游戏等需要低延迟双向通信的场景。实现复杂度较高，需要处理连接管理、心跳检测和水平扩展。

服务端推送事件，一种基于 HTTP 的轻量级实时通信协议，允许服务端通过长连接主动向客户端推送数据。客户端使用 EventSource API 接收推送。相比 WebSocket，SSE 实现更简单、浏览器原生支持自动重连，但只支持单向通信（服务端→客户端）。适合消息通知、数据推送、日志流等场景。

一种事件驱动的回调机制，服务端在特定事件发生时通过 HTTP POST 请求向预先注册的 URL 推送数据。与长连接方案不同，Webhook 是短连接回调，不需要保持持久连接，天然支持水平扩展。常用于支付回调、CI/CD 通知、第三方事件订阅等场景。需要实现重试机制和签名验证来保证可靠性。

JavaScript 的超集，由 Microsoft 开发的开源编程语言，在 JavaScript 基础上增加了静态类型系统。TypeScript 在编译时进行类型检查，能提前发现类型错误，提升代码可维护性和重构安全性。本站前端使用 TypeScript 编写，配合 Astro 框架和 Tailwind CSS。

开源的内存数据结构存储系统，支持字符串、哈希、列表、集合、有序集合等多种数据类型。常用于缓存、会话管理、消息队列、实时排行榜等场景。其特点是极低的读写延迟（亚毫秒级）和丰富的数据结构，是 Web 应用中最流行的缓存层解决方案。

功能强大的开源关系型数据库管理系统，以 ACID 事务支持、扩展性和 SQL 标准兼容性著称。支持 JSON 数据类型、全文搜索、地理空间数据（PostGIS）、窗口函数等高级特性。是本站后端服务的主要数据库选择。

一种由 Facebook 开发的 API 查询语言和运行时，允许客户端精确指定需要的数据结构，避免过度获取（Over-fetching）和获取不足（Under-fetching）。与 REST 不同，GraphQL 通过单一端点提供服务，客户端在请求中声明所需字段。适合多端聚合和快速迭代的前台场景。

由 Google 开发的高性能远程过程调用（RPC）框架，基于 HTTP/2 协议和 Protocol Buffers 序列化协议。与 REST 的 JSON 文本传输不同，gRPC 使用二进制序列化，性能更高，适合内部服务间的高频调用。支持双向流式通信，是微服务架构中的主流通信协议之一。

HTTP 的安全版本，在 HTTP 之下增加了 TLS/SSL 加密层，确保数据传输的机密性、完整性和服务器身份验证。HTTPS 可以防止中间人攻击、数据篡改和窃听。所有生产环境的网站和 API 都应强制使用 HTTPS，本站使用 Let's Encrypt 证书自动续期。

架构决策记录，一种轻量级的文档方法，用于记录每次架构决策的上下文、备选方案、最终选择及其后果。ADR 与代码一起版本管理，存放在 docs/adr/ 目录下，按编号命名。核心价值在于让半年后的团队成员能理解"为什么当初这么选"。

测试驱动开发，一种软件开发流程，核心循环是"红-绿-重构"：先写一个失败的测试（红），再写恰好能让测试通过的代码（绿），然后重构优化代码。TDD 的价值不在于"先写测试"，而在于"写代码之前先想清楚预期行为"。

内容分发网络，由分布在全球各地的边缘节点组成的网络，将内容缓存到离用户最近的节点，加速内容传输。CDN 可以显著降低用户访问延迟、减轻源站压力、抵御 DDoS 攻击。常见的 CDN 服务商包括 Cloudflare、阿里云 CDN、AWS CloudFront 等。

可访问性，指产品、设备、服务或环境对尽可能多的人可用的设计理念，特别关注残障人士的使用体验。前端 a11y 的核心实践包括：语义 HTML、ARIA 标签、键盘导航、颜色对比度（WCAG 2.1 AA 标准要求文本 ≥ 4.5:1）、屏幕阅读器支持。

一套开源的日志管理解决方案。Elasticsearch 负责日志的存储和全文搜索，Logstash 负责日志的采集和转换，Kibana 负责日志的可视化和查询。ELK 对日志内容建立全文索引，查询灵活但存储成本较高。适合需要全文搜索和复杂聚合分析的日志场景。

消息队列，一种异步通信机制，用于在服务之间传递消息。消息队列的核心模型包括：生产者（Producer）发送消息到队列（Queue），消费者（Consumer）从队列接收消息。主流消息队列包括 RabbitMQ（队列模型，适合任务分发）、Kafka（日志模型，适合事件流）、Redis Streams（轻量级，适合简单场景）。

AI 代理，一种能够自主感知环境、制定计划并执行行动的 AI 系统。AI Agent 通常基于 LLM 作为核心推理引擎，结合工具调用（Function Calling）和记忆系统，可以完成多步骤的复杂任务，如自动编写代码、操作数据库、调用 API 等。

思维链，一种提示词工程技术，引导 LLM 在给出最终答案之前先展示推理过程。通过在提示词中加入"让我们一步一步思考"或提供推理示例，可以显著提高 LLM 在数学、逻辑推理等复杂任务上的准确率。

温度参数，控制 LLM 输出随机性的超参数。温度值越低（如 0.1），输出越确定和可重复；温度值越高（如 0.9），输出越多样和创造性。温度 0 适合需要精确答案的场景（如代码生成），温度 0.7-0.9 适合创意写作。

幻觉，指 LLM 生成看似合理但实际上不正确或虚构的内容的现象。幻觉是 LLM 的固有问题，源于模型本质上是基于概率生成文本而非理解事实。缓解方法包括 RAG（检索增强生成）、Prompt 约束、输出验证等。

上下文窗口，指 LLM 一次能处理的最大 Token 数量。上下文窗口越大，模型能处理的文本越长。当前主流模型的上下文窗口从 8K 到 200K Token 不等。上下文窗口是 LLM 选型的重要指标之一，直接影响模型处理长文档、多轮对话的能力。

量化，一种模型压缩技术，通过降低模型参数的数值精度（如从 FP32 降到 INT8）来减少模型大小和推理耗时。量化后的模型体积可减少 75%，推理速度提升 2-4 倍，但精度会略有下降。常见的量化方法包括 GPTQ、GGUF、AWQ 等。

代理，在 AI 语境中指能够自主执行任务的智能体。AI Agent 通常具备感知（Perception）、推理（Reasoning）、行动（Action）三个核心能力，可以调用外部工具、访问知识库、执行代码来完成任务。

少样本学习，一种提示词工程技术，通过在提示词中提供少量示例（通常 2-5 个）来引导 LLM 理解任务要求和输出格式。与 Zero-shot（零样本，不给示例）相比，Few-shot 通常能获得更准确和符合预期的输出。

零样本学习，指不给 LLM 提供任何示例，直接要求其完成任务。Zero-shot 的效果取决于模型的能力和任务的清晰度，简单的任务（如翻译、分类）Zero-shot 效果不错，复杂的任务（如格式化的数据提取）Few-shot 更可靠。

向量数据库，专门存储和检索高维向量（Embedding）的数据库。支持近似最近邻（ANN）检索，如 HNSW、IVF 索引。主流选择包括 Qdrant（上手最快、运维最简）、Milvus（分布式、亿级扩展）、pgvector（复用现有 PostgreSQL）、Elasticsearch（全文+向量一体）。向量数据库是 RAG 知识库的核心存储组件。

切分，将长文档按语义边界拆分为检索单元（chunk）的过程。生产级做法：按标题层级和段落边界切分、相邻块重叠 50-100 字、单块 200-1000 字。切分质量直接决定检索召回效果——固定字数硬切会切断语义完整段，是最常见的 RAG 落地错误。

混合检索，同时使用向量检索（语义相似）与关键词检索（BM25 精确匹配）的检索策略。向量检索擅长"换个说法"的语义召回，关键词检索擅长合同条款号、产品型号等专有名词的精确匹配。混合结果合并后通常再接重排器精排，是生产级 RAG 的标准配置。

重排器，对初检结果进行二次排序的模型。常见做法是用 cross-encoder 模型（如 bge-reranker）对查询与每个候选文档逐对打分，把真正相关的提到前面。显存开销小（几 GB）但检索质量提升明显，是 RAG 链路中性价比最高的一笔投入。

经典的关键词检索排序算法，基于词频（TF）和逆文档频率（IDF）对文档打分。与向量检索互补：向量检索处理语义相似，BM25 处理精确匹配（编号、专有名词、缩写）。Lucene/Elasticsearch 的默认相关性算法基于 BM25 改进而来。

2023 年论文发现的位置偏倚现象：长文档中，模型对开头和结尾信息的召回率显著高于中间位置，源于 transformer 注意力分布的固有特性。2026 年的长上下文模型有改善但未消失，只收窄了降幅。三个工程缓解手段：① 三明治结构——系统提示放最前、用户最新问题放最后；② RAG 注入时把最相关 chunk 放上下文首尾位置；③ 关键事实（金额、日期、条款号）预提取成结构化字段，不依赖模型从长文中现场翻找。

输入长度增长时模型对上下文信息的有效利用率下降的现象——「塞得下」不等于「塞进去能用好」。三个成因：① 位置偏倚（中间部分召回率下降）；② 干扰项（语义相近的干扰内容拉低对正确答案的注意力）；③ 长度泛化不足（部分模型实际可用窗口小于标称值）。它是长上下文模型在真实文档问答上比 NIAH 测试低 10-30 个精度点的直接原因，也是「整篇塞入」方案的隐性风险项。

长上下文能力的理想化基准测试：在长文档（干草堆）中埋一句含随机编码的答案（针），让模型找出它。特点是唯一答案、纯噪声背景、问题精确——通过率可达 90-100%。但真实业务文档答案跨多段、带噪声、需推理，真实精度通常低 10-30 个点。结论：NIAH 分数只能用来排除最差的模型，不能保证生产精度——选型必须用自己的真实业务文档建金标集（50-100 条）做回归，换模型或改提示词后精度掉 3 个点以上不上线。

把「查询 + 候选文档」拼接在一起编码并打相关分的关系评分模型，与 bi-encoder（查询和文档分别编码，向量可预计算但打分粒度粗）相对。cross-encoder（bge-reranker、cohere rerank 等）逐个候选打分，慢（50-100ms/个）但准，标准用法在重排阶段：混合检索召回 top-20 → cross-encoder 精排 → 取 top-8~12 注入上下文。显存开销小（几 GB），是 RAG 调优性价比最高的一步。

LLM 推理的第一阶段：把整个输入上下文一次性前向处理、生成 KV Cache。TTFT 由 prefill 耗时主导，其算力消耗随输入长度近似平方增长——10 万 token 输入的 prefill 是秒级到十秒级（取决于硬件），是长上下文场景首字延迟恶化的直接原因。prefill 算力还直接挤压并发：同一张推理卡，8K 输入的 QPS 可以是 100K 输入的 5-10 倍，私有化部署选型时必须把「输入长度 × 并发目标」一起算。

向量检索（语义相似）与 BM25（关键词精确匹配）双路并行、合并去重、再经重排器精排的检索策略。法律/财务/技术文档中精确词（条款号「4.2.1」、金额「860 万」、合同名）是向量检索盲区——语义相近但向量距离远，必须 BM25 兜住。生产参数：双路各召回 top-10 → 合并 → rerank 取 top-8~12，相似度低于阈值（cosine ≥ 0.75）宁可不注入。相对纯向量 top-5 召回率提升 15-30%，比换更好的 embedding 模型便宜得多。

长文档问答场景中把文档全文直接塞进上下文窗口让模型通读的 RAG 替代方案。优点是信息天然完整、零管线建设；三个硬约束：① 注意力衰减（lost in the middle，中间信息召回率下降）；② token 计费——输入也计费且随文档长度线性增长，高频场景账单与 RAG 差 5-10 倍；③ prefill 延迟——长输入 TTFT 秒级起步，在线场景（要求 TTFT < 3s）直接出局。决策口诀：文档占窗口 ≤ 30% 或低频离线选整篇塞入，高频在线选 RAG，中间地带按月调用量算成本账。

回答必须引用来源 chunk 且引用受程序校验的工程要求：模型引用的来源编号必须落在本次注入的 chunk 范围内，超范围判定为幻觉引用并拒答。配套做法：每个 chunk 注入时带「文档名 + 章节 + 页码/行号」标注，生成要求引用编号，程序侧校验编号有效性。它是可审计长文档问答的标配——用户质疑答案时可指出原文出处，同时压制模型「自信地胡说」，也是向客户交付时的信任基础设施。

查询改写，在检索前对用户原始问题做改写，解决口语化指代、模糊表达导致的检索失败。例如把「上次说的那个政策还能用吗」改写为「政策 有效期 2026」再检索。可用小模型或规则实现，命中率提升明显，是生产级 RAG 的常用前置步骤。

平均倒数排名，信息检索的评估指标，衡量第一个正确答案在检索结果中的排名位置。MRR = 1/排名，第一个正确答案排第 1 得 1 分、排第 5 得 0.2 分。配合召回率（Recall）用于评估 RAG 检索层质量：低于 80% 召回率时先优化检索，再调生成。

多智能体系统，由多个各司其职的 AI Agent 协作完成复杂任务的架构。需要多 Agent 的三个信号：① 子任务可并行执行；② 不同步骤需要不同工具集和权限隔离；③ 需要"生成→审查"的对抗循环。多 Agent 灵活但 Token 成本与调试难度显著上升，固定流程优先单 Agent。

工具调用（也称 Function Calling），LLM 根据用户需求选择并调用外部函数/API 的机制。模型输出结构化调用指令（函数名+参数），由应用程序执行并返回结果。设计要点：工具职责单一、参数 description 写清楚（模型靠它决定何时调用）、返回值结构化、异常显式返回给模型而非吞掉。

推理-行动循环，AI Agent 的标准执行循环：思考（Reason）→ 调用工具（Act）→ 观察结果 → 再思考，直到完成任务。ReAct 让模型逐步推理并用工具结果修正判断，是降低幻觉的基础机制——回答必须基于工具调用证据，没有证据的答案应被拒绝。

编排，把多个 Agent/步骤按依赖关系组织成工作流的架构方式。三种主流模式：线性流水线（顺序固定，最可预测）、DAG 图编排（支持并行分支汇合，生产默认）、Planner-Executor（动态拆任务，最灵活但最不可预测）。选型顺序：能流水线就不上图，能上图就不上自主协调。

由 LangChain 团队推出的 Agent 编排框架，用图结构描述工作流，支持状态持久化、检查点（checkpoint）恢复、并行与条件分支。适合有工程能力的团队做生产级多 Agent，是 Dify 验证后的生产化路径。

开源的 LLM 应用开发平台，可视化拖拽编排 Agent 工作流、RAG 管道与对话应用，支持模型接入、工具集成、监控与发布。适合快速验证业务流程，深度定制（复杂状态、自定义调度）会碰壁，生产级多 Agent 常迁移到 LangGraph。

任务分解，将复杂目标拆解为可执行的子任务序列。拆解粒度直接影响成功率与成本：太粗模型难以执行，太细 Token 开销暴增。多 Agent 系统中由 Planner 负责分解与派发，是 Agent 工程化质量的第一道关口。

反思，Agent 生成结果后自我审查或由独立审查 Agent 校验的机制：检查引用是否真实、结论与数据是否矛盾、是否遗漏关键约束，发现错误即回退重做。反思不能消除幻觉，但与证据链、人工兜底共同构成幻觉控制的三层结构。

面向对象设计的五大原则：单一职责（Single Responsibility）、开闭原则（Open-Closed）、里氏替换（Liskov Substitution）、接口隔离（Interface Segregation）、依赖反转（Dependency Inversion）。遵循 SOLID 原则可以提高代码的可维护性、可扩展性和可测试性。

不要重复自己，一种软件开发原则，强调避免代码重复。重复的代码增加了维护成本——修改一个逻辑需要更新多处。DRY 的常见实现方式包括函数抽取、抽象类、设计模式等。但过度追求 DRY 可能导致过度抽象，需要在 DRY 和可读性之间平衡。

设计模式，软件工程中针对常见问题的可复用解决方案。设计模式不是代码片段，而是解决特定问题的通用模板。经典的设计模式分为创建型（如 Singleton、Factory）、结构型（如 Adapter、Proxy）和行为型（如 Observer、Strategy）三类。

命令查询职责分离，一种架构模式，将系统的读操作（查询）和写操作（命令）分离到不同的模型中。CQRS 允许读模型和写模型独立优化，读模型可以使用缓存和物化视图，写模型可以专注于业务逻辑和一致性。

事件溯源，一种数据持久化模式，将系统的状态变化记录为一系列事件，而不是存储当前状态。要获取当前状态，需要重放所有历史事件。事件溯源的优势包括完整的审计日志、时间旅行（恢复到任意历史状态）、以及事件驱动的架构支持。

模型-视图-控制器，一种经典的软件架构模式，将应用程序分为三个核心组件：Model（数据与业务逻辑）、View（用户界面）、Controller（处理用户输入并协调 Model 和 View）。MVC 实现了关注点分离，提高了代码的可维护性。

耦合度，衡量模块之间依赖程度的指标。高耦合意味着一个模块的修改会影响其他模块，降低系统的可维护性和可测试性。低耦合是良好设计的标志，常见解耦手段包括接口抽象、依赖注入、消息队列等。

内聚度，衡量模块内部元素之间关联程度的指标。高内聚意味着模块内部的元素在功能上紧密相关，职责清晰。高内聚低耦合是模块化设计的核心目标。

观察者模式，一种行为型设计模式，定义了一对多的依赖关系。当一个对象（主题）的状态发生变化时，所有依赖它的对象（观察者）都会自动收到通知。在 JavaScript 中，EventEmitter 是观察者模式的经典实现。

单例模式，一种创建型设计模式，确保一个类只有一个实例，并提供一个全局访问点。在 TypeScript/JavaScript 中，模块级别的变量天然就是单例。单例模式常用于日志记录器、配置管理器、数据库连接池等场景。

开源的容器编排平台，用于自动化容器的部署、扩展和管理。Kubernetes 将多个服务器组成一个集群，统一管理容器的调度、网络、存储和健康检查。适合大规模微服务部署，但运维复杂度较高，小项目建议用 Docker Compose 替代。

开源的基础设施即代码（IaC）工具，使用声明式配置文件（HCL 语言）来定义和管理云基础设施。Terraform 支持 AWS、Azure、阿里云等主流云平台，可以自动化创建、修改和版本化管理云资源。

开源的系统监控和告警工具包，最初由 SoundCloud 开发，现在是 CNCF 的毕业项目。Prometheus 通过拉取（Pull）模式采集指标数据，支持多维数据模型和强大的 PromQL 查询语言。常与 Grafana 搭配使用，构成监控解决方案。

开源的数据可视化和监控仪表盘工具，支持 Prometheus、Elasticsearch、InfluxDB、MySQL 等多种数据源。Grafana 提供丰富的图表类型和告警功能，是运维监控和业务数据分析的标准工具之一。

服务网格，一种基础设施层，用于处理服务间通信的专用基础设施层。Service Mesh 通过 Sidecar 代理（如 Envoy）拦截服务间的所有网络流量，提供服务发现、负载均衡、熔断、重试、可观测性等功能，对应用代码透明。

CAP 定理，分布式系统设计的基本定理，指出一个分布式系统最多只能同时满足三个特性中的两个：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）。实际工程中，分区容错性是必须的，所以在一致性和可用性之间做权衡。

无服务器计算，一种云计算执行模型，云提供商动态管理服务器的分配和资源。开发者只需编写和上传代码，不需要关心服务器配置、扩展和维护。常见的 Serverless 产品包括 AWS Lambda、阿里云函数计算、Cloudflare Workers。

负载均衡器，一种将网络流量分发到多个后端服务器的设备或软件。负载均衡可以提高系统的可用性和扩展性，常见的负载均衡算法包括轮询（Round Robin）、最少连接（Least Connections）、IP Hash 等。

反向代理，一种位于客户端和后端服务器之间的中间服务器，代表后端服务器接收客户端请求。反向代理常用于负载均衡、SSL 终止、缓存、安全防护等场景。Nginx 是最流行的反向代理服务器之一。

数据库事务的四个特性：原子性（事务要么全部执行要么全部回滚）、一致性（事务前后数据保持一致）、隔离性（并发事务互不干扰）、持久性（提交后数据永久保存）。ACID 是关系型数据库（如 PostgreSQL、MySQL）的核心特性。

分布式系统的设计理念，与 ACID 相对。BASE 强调基本可用（Basically Available）、软状态（Soft state）、最终一致性（Eventual consistency）。NoSQL 数据库（如 MongoDB、Cassandra）通常采用 BASE 模型。

分片，一种数据库水平扩展技术，将数据按某个键（如用户 ID）分散到多个数据库实例中。每个分片持有部分数据，所有分片合起来构成完整数据集。分片可以突破单机存储和性能限制，但引入跨分片查询和分布式事务的复杂度。

复制，将数据从一个数据库实例同步到另一个实例的过程。复制可以提高数据可用性和读取性能。主从复制（Master-Slave）是最常见的模式：主库处理写操作，从库处理读操作。

对象关系映射，一种将数据库表映射到编程语言对象的技术。ORM 框架（如 TypeORM、Prisma、SQLAlchemy）让开发者可以用面向对象的方式操作数据库，不需要写 SQL 语句。ORM 提高了开发效率，但复杂查询可能需要原生 SQL。

索引，一种数据库优化技术，通过对指定列创建有序数据结构来加速数据查询。索引可以大幅提高 SELECT 查询的速度，但会降低 INSERT/UPDATE 的性能并占用额外存储空间。常见的索引类型包括 B-Tree、Hash、GiST、GIN 等。

范式化，数据库设计的一种方法，通过消除数据冗余和依赖关系来组织数据。常见的范式包括第一范式（1NF，消除重复列）、第二范式（2NF，消除部分依赖）、第三范式（3NF，消除传递依赖）。范式化减少了数据冗余但可能增加查询复杂度。

反范式化，故意引入数据冗余来优化查询性能的策略。反范式化通过将关联数据存储在同一张表中来减少 JOIN 操作，适合读多写少的场景。反范式化与范式化之间需要根据实际场景权衡。

非关系型数据库的统称，与关系型数据库（SQL）不同，NoSQL 数据库不使用固定表结构。常见的 NoSQL 类型包括文档型（MongoDB）、键值型（Redis）、列族型（Cassandra）、图数据库（Neo4j）。NoSQL 适合灵活的数据模型和水平扩展场景。

连接池，一种数据库连接管理技术，预先创建一组数据库连接并重复使用，避免每次请求都创建新连接的开销。连接池可以显著提高数据库访问性能，常见的连接池实现包括 PgBouncer（PostgreSQL）、HikariCP（Java）等。

跨站脚本攻击，一种常见的安全漏洞，攻击者将恶意脚本注入到网页中，当其他用户访问该页面时脚本被执行。XSS 可以窃取用户 Cookie、重定向到恶意网站、篡改页面内容。防御方法包括输入验证、输出转义、Content-Security-Policy 头。

跨站请求伪造，一种攻击方式，诱导用户在已登录的状态下点击恶意链接，利用用户的登录态执行非预期操作。防御方法包括 SameSite Cookie 属性、CSRF Token、验证 Referer 头。

分布式拒绝服务攻击，攻击者通过控制大量僵尸网络向目标服务器发送海量请求，耗尽服务器的网络带宽或计算资源，导致正常用户无法访问。防御方法包括 CDN 防护、流量清洗、限流、WAF。

Web 应用防火墙，一种安全设备或软件，监控和过滤 HTTP/HTTPS 流量，保护 Web 应用免受常见攻击（如 SQL 注入、XSS、文件包含）。WAF 可以部署在应用前端（如 Cloudflare WAF、阿里云 WAF）或服务器端。

内容安全策略，一种 HTTP 安全头，通过白名单机制控制浏览器可以加载哪些资源（脚本、样式、图片等）。CSP 可以有效防止 XSS 攻击和数据注入攻击。配置示例：Content-Security-Policy: default-src 'self'。

零信任安全模型，一种安全架构理念，核心原则是"永不信任，始终验证"。零信任假设网络内外都不可信，对每个访问请求都进行身份验证和授权检查。零信任架构包括微隔离、最小权限、持续验证等关键组件。

传输层安全协议，HTTPS 的底层加密协议，确保数据在传输过程中的机密性、完整性和身份验证。TLS 是 SSL 的继任者，当前主流版本是 TLS 1.3。TLS 握手过程包括密钥交换、证书验证和加密参数协商。

单点登录，一种身份验证机制，允许用户使用一组凭据登录多个独立的系统。SSO 通常基于 OAuth 2.0 或 SAML 协议实现，用户只需登录一次即可访问所有关联系统，提高了用户体验和安全性。

多因素认证，一种安全认证机制，要求用户提供两种或以上的验证方式才能登录。常见的因素包括：知识因素（密码）、持有因素（手机验证码、硬件密钥）、固有因素（指纹、面部识别）。MFA 显著提高了账户安全性。

漏洞，系统、软件或网络中的安全缺陷，可能被攻击者利用来获取未授权访问、破坏数据或导致服务不可用。常见漏洞类型包括缓冲区溢出、SQL 注入、权限提升、远程代码执行。漏洞管理包括发现、评估、修复、披露等环节。

一种高级编程语言，以简洁易读的语法著称。Python 在数据科学、机器学习、Web 开发（Django、FastAPI）、自动化脚本等领域广泛应用。其丰富的第三方库生态（如 NumPy、Pandas、PyTorch）使其成为 AI 领域的首选语言。

一种系统编程语言，以内存安全、零成本抽象和并发安全著称。Rust 的所有权系统和借用检查器在编译时防止内存错误，不需要垃圾回收器。Rust 适合性能敏感的场景（如 WebAssembly、系统工具、游戏引擎）。

一种由 Google 开发的编译型编程语言，以简洁的语法、内置并发支持和快速编译著称。Go 的 goroutine 和 channel 使得并发编程变得简单。Go 在云原生工具（Docker、Kubernetes、Terraform）和微服务领域广泛使用。

一种高级解释型编程语言，是 Web 浏览器的原生脚本语言。JavaScript 支持面向对象、函数式和事件驱动编程范式。Node.js 将 JavaScript 带到服务器端，使其成为全栈开发的首选语言。

一个基于 Chrome V8 引擎的 JavaScript 运行时环境，允许在服务器端运行 JavaScript。Node.js 采用事件驱动、非阻塞 I/O 模型，适合构建高并发、I/O 密集型的应用（如 Web 服务器、API 网关、实时应用）。

一个由 Meta（Facebook）开发的 JavaScript 前端库，用于构建用户界面。React 采用组件化架构和虚拟 DOM 技术，提高了 UI 开发效率和性能。React 生态包括 React Router、Next.js 框架、状态管理库（Redux、Zustand）等。

一个渐进式 JavaScript 前端框架，以轻量、灵活和易上手著称。Vue.js 的核心库专注于视图层，可以逐步集成到项目中。Vue 生态包括 Vue Router、Pinia 状态管理、Nuxt.js 框架等。

一个基于 Node.js 的轻量级 Web 应用框架，提供简洁的 API 用于构建 Web 服务器和 API。Express.js 通过中间件机制处理请求和响应，是 Node.js 生态中最流行的 Web 框架之一。

一个基于 React 的全栈 Web 框架，支持服务端渲染（SSR）、静态生成（SSG）、增量静态再生（ISR）等多种渲染模式。Next.js 提供了文件系统路由、API 路由、中间件等开箱即用的功能，是企业级 React 应用的首选框架。

一个现代的静态站点生成框架，以"零 JavaScript 默认"为核心理念。Astro 在构建时将页面预渲染为静态 HTML，只在需要交互时加载 JavaScript（岛屿架构）。Astro 支持多种 UI 框架（React、Vue、Svelte）混用，本站即使用 Astro 构建。

代码重构，在不改变软件外部行为的前提下改善内部结构的过程。重构的核心原则是小步前进——每次只做一种重构操作（如重命名、提取函数、移动方法），每一步后都运行测试确保行为不变。重构不是重写，而是逐步改善代码质量。

API 版本管理，标识和管理 API 不同版本的策略。常见的版本策略包括 URL 路径版本（/v1/users）、Header 版本（Accept Header）、参数版本（?version=1）。推荐使用 URL 路径版本，透明且易于调试。版本号只在不兼容变更时升级。

数据可视化，通过图表和图形将数据转化为视觉形式的技术。好的数据可视化能让读者一眼看懂数据背后的趋势和模式。核心原则包括：选对图表类型、保持高数据-墨水比、色盲友好的配色方案、以及合理的交互设计。

一个由百度开源的功能强大的 JavaScript 图表库，提供 60+ 种图表类型，包括折线图、柱状图、饼图、散点图、地图、热力图等。ECharts 使用 Canvas 渲染，适合大数据量场景，配置简单，中文文档完善，是国内数据可视化的首选库。

一个基于数据操作文档的 JavaScript 库，通过将数据绑定到 DOM 来实现数据可视化。D3.js 提供了最大的灵活性和自定义能力，但学习曲线陡峭。适合需要高度定制化的图表场景，如桑基图、弦图、力导向图等。

向后兼容，新版本的 API 或软件能够与旧版本的客户端正常工作。在 API 设计中，向后兼容的变更包括加字段、加可选参数、扩展枚举值；不兼容的变更包括删字段、改字段类型、改必填参数。好的 API 设计应尽可能保持向后兼容。

数据库迁移，将数据库 Schema 或数据从一种结构迁移到另一种结构的过程。零停机迁移的核心策略是"并轨运行"——新旧结构在一段时间内并存，应用层兼容两者，等旧数据全部迁完再切换。常用的零停机工具包括 gh-ost（MySQL）、pgroll（PostgreSQL）。

在线 Schema 变更，在不停止数据库服务的情况下修改表结构的技术。原理是通过创建影子表、将增量变更同步到影子表（通过触发器或 binlog），最后原子交换表名。gh-ost 使用 binlog 流式同步，不依赖触发器，对主库压力更小。

服务等级目标，衡量系统服务质量的核心指标，从用户视角定义。常见的 SLO 包括 API 可用率（≥ 99.9%）、响应时间 P99（≤ 500ms）、数据新鲜度（≤ 5 分钟）。SLO 是监控告警体系的基础——只对违反 SLO 的情况告警，不做基础设施层面的噪声告警。

告警疲劳，指运维人员因收到过多无关紧要的告警而变得麻木，最终错过真正重要的告警。缓解方法包括：SLO 驱动告警（只对用户可感知的异常告警）、依赖抑制（下层故障自动屏蔽上层告警）、分组聚合（同类告警合并为一条通知）。

爬虫预算，搜索引擎爬虫每天对每个网站分配的固定抓取配额。如果网站有大量低价值页面（重复内容、参数化 URL），爬虫会把配额浪费在这些页面上。管理方法：用 robots.txt 和 noindex 屏蔽低价值页面，让爬虫集中抓取核心内容。

经验-专业-权威-信任，Google 质量评估指南的核心框架。虽然不是直接的排名算法因素，但内容质量信号会影响排名。提升方法：文章署名真实作者、引用权威来源、展示团队资质、保持内容更新日期可见、完善的联系信息和关于我们页。

树摇（摇树优化），打包工具自动移除未使用代码的优化技术。依赖 ES Module 的静态分析特性，在打包时识别并剔除那些被导入但从未被调用的代码。2026 年所有主流构建工具（Vite、Webpack、Turbopack）都默认支持 Tree Shaking。

代码分割，将应用的代码拆分成多个独立 Chunk，按需加载的技术。最常见的粒度是路由级分割——用户访问哪个路由才加载对应的代码，其余代码延迟加载。Vite 和 Webpack 都自动将动态导入（import()）的模块拆分为独立文件。

事件驱动架构，一种以事件（Event）作为核心通信机制的软件架构模式。组件之间不直接调用，而是通过发布和订阅事件进行异步通信。EDA 的核心优势是松耦合——发送方不需要知道谁在消费事件、消费是否成功。典型实现包括消息队列（RabbitMQ）和事件流（Kafka）。

事件流，一种将事件持久存储在日志中的消息模型。与消息队列不同，事件流中的事件不会在消费后被删除，而是保留到过期时间，消费者可以在任意时间点回溯重放。Apache Kafka 是事件流的代表实现，以高吞吐和持久化著称。

Saga 模式，一种在微服务架构中管理分布式事务的模式。Saga 将一个大事务拆分为多个本地事务，每个本地事务完成后发布事件触发下一个步骤。如果某个步骤失败，Saga 执行补偿事务（Compensating Transaction）来回滚已完成的步骤。编排方式分为编排式（Choreography，通过事件驱动）和协调式（Orchestration，通过中心协调器）两种。

熔断器模式，一种保护分布式系统防止级联故障的设计模式。熔断器监控对下游服务的调用失败率，当失败率超过阈值时"断开"线路，后续请求直接返回错误而不真正调用下游，给下游服务恢复时间。熔断器有三种状态：关闭（正常调用）、打开（快速失败）、半开（试探恢复）。Resilience4j 和 Hystrix 是流行的熔断器实现。

舱壁模式，一种隔离故障的设计模式，源自船舶的隔舱设计——一个舱漏水不会沉掉整条船。在系统中，Bulkhead 通过为不同组件分配独立的线程池或连接池来隔离故障。当某个组件的资源耗尽时，只影响该组件自身，不会耗尽整个系统的线程池导致所有请求失败。常与熔断器模式配合使用。

幂等性，指同一操作执行多次和执行一次产生相同结果的性质。在分布式系统中，网络抖动、重试机制可能导致消息重复投递，消费者必须实现幂等性。幂等的常见实现方式包括：天然幂等操作（SET key = value）、去重表（事件 ID 唯一约束）、乐观锁（版本号检测）、状态机（只允许特定状态转移）。

背压，一种流控制机制，当消费者处理速度跟不上生产者时，消费者主动向生产者反馈压力信号，让生产者减慢或暂停发送。背压是 Reactive Systems 的核心机制之一，可以防止消费者被数据洪流压垮。在 Kafka 中，消费者通过 max.poll.records 和 fetch.max.bytes 参数实现背压控制。

分布式追踪，一种在微服务架构中追踪请求完整链路的技术。每个请求在入口处分配一个唯一的 Trace ID，在跨越不同服务时通过 Propagate Header 传递。通过 Trace ID 可以将一个请求经过的所有服务调用串联起来，快速定位性能瓶颈和故障点。Jaeger 和 Zipkin 是主流的分布式追踪系统。

蓝绿部署，一种零停机发布策略，维护两套完全相同的生产环境（蓝环境和绿环境）。任何时候只有一套环境承载生产流量。新版本先部署到空闲环境，验证通过后流量网关瞬时切换（路由/负载均衡器更新），旧环境保留作为回滚容量。切换是瞬时的，没有灰度窗口。

金丝雀部署，一种渐进式发布策略，先将新版本发布到一小部分实例（如 5%），监控运行状态和错误率一段时间，如果没有异常再逐步扩大流量比例到 100%。如果发现异常，可以立即将流量切回旧版本。相比蓝绿部署，金丝雀部署更精细但发布周期更长。

功能开关，一种在运行时控制功能可见性的技术，不需要重新部署代码即可开启或关闭某个功能。常用场景包括：灰度发布（对指定用户或地区开启新功能）、A/B 测试（随机分组测试不同版本）、运维开关（紧急关闭问题功能）。LaunchDarkly 和 Unleash 是专用的功能开关管理平台。

优雅降级，一种系统设计策略，当部分组件或依赖不可用时，系统不直接崩溃，而是以降低的功能水平继续服务。例如：推荐服务不可用时降级为热门榜单、图片加载失败时显示占位图、支付服务不可用时暂缓开通功能。降级策略应在架构设计阶段预先定义，而不是在线上故障时临时拍脑门。

限流，一种系统保护机制，限制在指定时间窗口内允许通过的请求数量。常见的限流算法包括：令牌桶（Token Bucket，允许突发流量）、漏桶（Leaky Bucket，均匀处理请求）、滑动窗口（Sliding Window，精确计数）。限流的维度可以是 IP、用户 ID、API Key，网关层（如 Kong、APISIX）通常内置限流插件。

健康检查，一种检测服务实例是否正常运行的机制。分为两种：存活检查（Liveness Probe，服务进程是否还在运行）和就绪检查（Readiness Probe，服务是否能正常处理请求）。Kubernetes 通过 Pod 的健康检查决定是否重启容器或摘除流量。对外暴露的健康检查端点通常返回 200 OK 或 JSON 格式的状态详情。

Sidecar 模式，一种将辅助功能（日志、监控、代理、配置）从主应用中剥离到独立的伴生容器的架构模式。Sidecar 与主应用共享相同的网络和存储卷，但独立部署和更新。Service Mesh（如 Istio）的 Envoy 代理就是经典的 Sidecar 实现——应用代码不需要感知服务网格的存在。

领导者选举，一种分布式系统算法，在多个副本中选出一个 Leader 负责处理写操作或协调任务，其他副本作为 Follower 保持同步。Leader 崩溃时自动重新选举。ZooKeeper、etcd、Redis Sentinel 都提供了 Leader Election 的能力。选举算法包括 Paxos、Raft、Bully 等。

共识算法，一种在分布式系统中让多个节点就某个值达成一致的算法。共识算法是分布式可靠性的基石，在 Leader Election、分布式锁、原子广播等场景中发挥核心作用。最著名的共识算法是 Paxos（理论严谨，实现在 Chubby/ZooKeeper）和 Raft（更易理解，实现在 etcd/Consul）。

数据管道，一种将数据从源端经过抽取、转换、加载等步骤流转到目标端的过程。数据管道通常涉及数据源提取→清洗→转换→加载到数仓的过程，可以按批次调度或实时流处理。Apache Kafka、Apache Flink、Apache Airflow 是数据管道的常用工具组合。

最终一致性，一种分布式系统一致性模型，允许多副本之间在一段时间内存在数据不一致，但只要没有新的更新，经过足够长的时间后所有副本最终会达到一致。最终一致性与强一致性相对，是 BASE 理论的核心。在事件驱动架构中，读模型通常落后于写模型数秒到数分钟。

响应式系统，一种面向弹性和响应的架构风格，遵循四个核心原则：即时响应（Responsive，在合理时间内响应）、弹性（Resilient，故障时系统仍可用）、弹性扩展（Elastic，根据负载自动伸缩）、消息驱动（Message Driven，异步消息传递实现松耦合和背压）。Reactive Manifesto 定义了响应式系统的核心理念。

补偿事务，在 Saga 模式中，当某个步骤失败时，用于撤销之前已完成步骤的操作。补偿事务不是"还原到原始状态"——因为中间可能发生了其他操作——而是"抵消"之前操作的影响。例如：扣款失败后执行退款（而非"反扣款"）、订单取消后执行恢复库存而非"改订单状态"。补偿事务必须是幂等的。

每秒查询数，衡量系统处理能力的核心指标。容量规划中通常区分平均 QPS 和峰值 QPS。平均 QPS = 日总请求数 / 86400，峰值 QPS = 平均 QPS × 峰值系数（5-8 取决于业务类型）。压测目标通常设置为峰值 QPS 的 3-5 倍，预留余量。

第 99 百分位延迟，指 99% 的请求在低于此值的时间内完成。P99 比平均值更能反映系统的真实用户体验——平均值可能被大多数请求拉低，掩盖少量慢请求的问题。P99 超过 1000ms 且占比超过 5% 应视为预警信号。相关指标还包括 P50（中位数）和 P95（第 95 百分位）。

首 Token 延迟，AI 推理场景的关键性能指标，指从提交请求到收到第一个输出 Token 的时间。TTFT 直接影响用户感知的响应速度。在流式输出中，TTFT 应控制在 500ms 以内。影响 TTFT 的因素包括模型大小、硬件配置、批处理策略和 KV Cache 命中率。

每 Token 输出延迟，AI 推理场景的关键性能指标，指生成每个输出 Token 所需的平均时间。TPOT 决定生成速度——500 Token 的输出在 TPOT 为 10ms 时需要 5 秒。TPOT 受 GPU 算力、显存带宽、量化方式和批处理大小影响。

负载测试，通过模拟真实用户请求来验证系统在预期负载下的性能表现。压测金字塔：组件级（单接口/单查询）→ 模块级（单服务）→ 全链路（端到端）。常用工具包括 wrk（轻量 HTTP）、k6（场景编排）、pgbench（数据库）、vLLM benchmark_serving.py（AI 推理）。必须覆盖基线压测、极限压测、持续压测和突发压测四种场景。

连接池耗尽，一种常见的数据库性能瓶颈，指所有数据库连接都被占用，新请求等待释放连接而超时。350 QPS 下数据库连接池建议 50-80 个连接。连接池耗尽的原因通常是慢查询占用连接时间过长、连接泄漏（未正确归还连接）、或突发流量超过池容量。监控连接池使用率和等待时间是早期发现瓶颈的关键。

Google 搜索结果页顶部的 AI 生成摘要，由 Google 的生成式 AI 基于排名靠前的网页内容自动总结而成，直接回答用户查询。AI Overviews 会引用来源网页——被引用的网站因此获得高曝光但通常不产生点击（零点击搜索）。GEO 优化让网站内容更容易被 AI Overviews 选中引用。

答案引擎，一类直接给出答案而非列出链接的 AI 信息检索产品，代表是 Perplexity。与传统搜索引擎不同，答案引擎先检索相关网页，再由 LLM 综合生成带引用的回答。GEO（生成式引擎优化）的目标就是让网站内容被答案引擎抓取、理解并引用。

答案引擎优化，面向答案引擎（如 Perplexity）的优化方法，目标是让网站在 AI 回答中被引用。与 GEO 高度重叠：都要求结构化数据、结论前置（BLUF）、可抓取的内容和清晰的实体关系。AEO 是 GEO 在"答案引擎"这一具体渠道上的实践。

Perplexity 搜索引擎使用的 AI 爬虫，用于抓取网页内容作为其 AI 回答的引用来源。与 GPTBot（OpenAI）和 ClaudeBot（Anthropic）类似，属于专门为 AI 引擎服务的爬虫。robots.txt 应显式放行 PerplexityBot，否则网站在 Perplexity 的回答中会完全隐形。

富摘要，搜索结果中展示的增强片段，通过结构化数据（JSON-LD）驱动，可显示评分、价格、FAQ 问答、面包屑等丰富信息。富摘要能显著提高点击率，同时 FAQPage 等类型的富摘要内容也更容易被 AI 引擎直接引用，是 SEO 与 GEO 的共赢基建。

语义 HTML，使用具有明确语义的标签（article、section、nav、header、h1-h6、time 等）构建页面结构，而非全部使用 div/span。语义 HTML 帮助搜索引擎和 AI 引擎理解内容的层次与含义，是 GEO 基建的一部分——AI 爬虫比浏览器更依赖语义标签来判断内容重要性。

知识面板，搜索引擎结果页（如 Google、百度）中展示实体（品牌、人物、机构）摘要信息的信息框，数据来自知识图谱。知识面板提升品牌权威感，通常与维基百科、官网结构化数据（Organization Schema）、权威媒体引用相关，是 E-E-A-T 信号的一部分。

零点击搜索，用户在搜索结果页或 AI 回答中获得完整答案，不再点击进入任何网站。AI Overviews 与答案引擎放大了这一趋势——大量信息查询不再产生流量。对网站而言，应对策略是让品牌名、核心卖点在 AI 回答中被引用，把"零点击"变成品牌曝光。

OpenAI 用于抓取网页内容的 AI 爬虫，数据用于训练和推理。GPTBot 的 User-Agent 含 "GPTBot"，可通过 robots.txt 单独控制放行或屏蔽。ChatGPT 联网搜索时还使用 OAI-SearchBot 抓取实时内容。观察 GPTBot 抓取量是衡量 OpenAI 侧 GEO 效果的第一层信号。

OpenAI 搜索引擎（ChatGPT Search）使用的爬虫，用于抓取实时网页内容作为回答的引用来源。与训练用 GPTBot 不同，OAI-SearchBot 服务于推理阶段的联网检索，对网站的 GEO 价值更直接——被它抓取意味着有机会出现在 ChatGPT 的回答引用中。

Anthropic 的 Claude 系列 AI 助手使用的爬虫，用于抓取网页内容供训练与推理。Claude 的搜索类产品（Claude-SearchBot、Claude-User）也会抓取实时内容。User-Agent 含 "ClaudeBot"，与 GPTBot、PerplexityBot 同属应显式放行的 AI 爬虫白名单。

Google 用于训练 Gemini 等生成式 AI 模型的专用爬虫标识，独立于常规 Googlebot。站长可在 robots.txt 中单独控制 Google-Extended 的抓取权限。在 Search Console 中观察 Google-Extended 的抓取数据，可侧面衡量内容被 Google AI 侧读取的规模。

网站根目录下的爬虫协议文件，声明哪些 User-Agent 可以抓取哪些路径。GEO 实践中常见的坑是沿用旧的屏蔽规则误伤 AI 爬虫（如屏蔽了 GPTBot/PerplexityBot 所在 UA 段）。GEO 基建要求显式放行所有主流 AI 爬虫并保留 sitemap 指向。

Google 搜索控制台（GSC），Google 官方的网站索引与搜索表现监控工具。GEO 场景下的用法：在性能报告中筛选 Googlebot 与 Google-Extended，观察哪些 URL 被抓取、返回状态码，侧面推断内容被 AI 侧读取的规模与质量问题。

统一跟踪参数，附加在 URL 上的查询参数（如 ?utm_source=perplexity&utm_medium=organic），用于在统计工具中标记流量来源。GEO 归因的标准做法：在 AI 回答中出现的落地页链接上加 UTM 参数，即可统计 ChatGPT、Perplexity 等 AI 渠道带来的访问量与转化。

AI 可见度，衡量网站在 AI 引擎回答中被抓取、理解并引用的综合程度。与 SEO 的"关键词排名"对应，AI 可见度通过四层链路衡量：爬虫抓取量（服务器日志）→ 索引覆盖（Search Console）→ 引用（品牌测试与业务词测试）→ 归因（AI 来源流量与询盘）。

评测集/黄金数据集，一组带标准答案的测试用例，用于评估 AI 系统的质量。正确的建法：人工标注 50-100 条覆盖主要场景的种子集（分层抽样、双人标注）→ 上线后每周从真实日志回流 10-20 条失败用例 → 形成防回归闭环。评测集是 AI 项目"离线技术质量层"的基石，改版前先跑回归、防回归用例不过不许上线。

精确率/召回率/F1 分数，分类与抽取任务的核心评估指标。Precision=预测为正的样本中真正为正的比例；Recall=真正为正的样本中被预测为正的比例；F1 是两者的调和平均。类别不平衡时只看 Accuracy（准确率）毫无意义，必须看 Precision/Recall 的组合。

RAG 项目的开源评估框架，提供四个指标：Context Precision（检索结果中相关内容占比）、Context Recall（该召回的有没有召回）、Faithfulness（回答是否忠于检索上下文，防幻觉）、Answer Relevancy（回答是否切题）。四个指标组合才能定位问题在检索层还是生成层——只给一个总准确率等于没给。

幻觉率，AI 回答中出现无依据或错误内容的比例，RAG/Agent 类项目的关键质量指标。测量方法：在评测集上由标注者（或独立评估模型）逐条判定回答是否有事实性错误，统计占比。幻觉率只能靠"证据链 + 审查 + 人工兜底"压缩，无法靠提示词消除。

用大模型当裁判，按评分标准（Rubric）对回答质量打分，用于无法用规则自动判定的生成类任务评估。实践要点：① 评分标准要写得可操作；② 裁判模型与被评模型异构，避免同源偏好；③ 定期抽样人工复核裁判的稳定性。

A/B 测试，将用户随机分组、同时运行新旧两个版本并对比关键指标的实验方法，是 AI 系统上线验证的黄金标准。AI 场景的坑：冷启动期（检索索引、用户习惯在变）导致效果波动，测试至少跑 2-4 周再下结论；且要同时看质量与成本两侧，避免"成本降了质量也降了"。

冠军-挑战者机制：线上运行的版本是 Champion（冠军），新模型/新提示词作为 Challenger（挑战者）并行灰度运行，A/B 对比指标，挑战者明确胜出才切换。防止"改了还不如不改"——AI 系统的每次改动都应该先做挑战者，而不是直接替换。

模型漂移，输入数据分布或检索内容随时间变化导致模型效果悄悄变差的现象。AI 系统上线后效果是动态的：用户提问方式变了、知识库内容更新了、业务规则变了都会引发漂移。对策：建立基线指标周报、监控输入分布变化、定期重跑评测集。

人在回路/人工介入，AI 流程中高风险步骤（下单、删数据、大额决策）由人工确认后再执行的机制。介入率是 AI 系统的关键运营指标：太高说明 AI 没省到人，太低说明风险没控制住。设计与业务指标（ROI）直接挂钩——人工兜底成本必须计入 AI 项目总成本。

单位经济，按"单次处理"为单位核算成本与收益的方法，判断 AI 是否值得做的硬标准：单次 AI 处理总成本（Token + 兜底人工 + 开发摊销）必须低于单次人工处理成本。很多项目"省了人但没省钱"，根源就是介入率过高导致兜底人工成本吃掉全部收益。

分层可导航小世界图索引，向量检索中最常用的近似最近邻（ANN）索引算法。核心思路：构建多层图结构，顶层粗粒度导航、底层精确检索。查询时从上到下逐层进入，搜索复杂度 O(log N)。HNSW 的 ef_construction 和 M 两个参数控制索引精度与速度的平衡：M 越大召回率越高但索引越大，推荐 M=16 起步。HNSW 构建慢但查询极快，适合"写少读多"的在线检索场景。

倒排文件索引，向量检索的经典索引算法。核心思路：用 K-Means 聚类将向量空间划分成 nlist 个分区，查询时只搜索最近的 nprobe 个分区。IVF 构建快（比 HNSW 快数倍），但查询需遍历候选集、速度慢于 HNSW。适合批量写入、离线检索或资源受限场景。nlist 参数控制分区数：分区越多构建越慢但查询越准。

余弦相似度，衡量两个向量方向相似程度的指标，取值范围 [-1, 1]。值越接近 1 表示方向越一致。在向量检索中 Cosine Similarity 与内积（IP）在向量归一化后等价，是最常用的向量相似度度量方式。vivo 中文 Embedding 模型（bge-m3、text-embedding-3 等）默认使用 Cosine Similarity 作为距离度量。

近似最近邻检索，向量检索的基本范式——不保证返回绝对最近邻，而是在可接受的召回率下换取数量级的检索速度提升。与暴力搜索（Brute Force，即精确搜索）相比，ANN 在百万级数据上速度可快 100-1000 倍，召回率通常保持在 90-99%。HNSW、IVF、DiskANN 都是 ANN 索引的具体实现。

乘积量化，一种向量压缩技术。将高维向量切分成若干子向量，对每个子向量空间独立聚类，用聚类中心 ID 代替原始向量存储。压缩比可达 4-32 倍，大幅降低内存占用和查询距离计算开销。代价是检索精度轻微下降（通常 1-3% 的召回率损失），适合资源受限的大规模部署场景。

基于磁盘的近似最近邻检索算法，由微软提出。核心思路：将向量索引存储在 SSD 而非内存中，仅图结构（约原始数据的 1/10）驻留内存，大幅降低单机部署成本。支持亿级向量检索，召回率接近内存索引。适合海量数据但内存预算有限的场景。

稠密检索，用 Embedding 模型将文本映射为稠密向量（Dense Vector），在向量空间中进行语义相似度检索。与稀疏检索（Sparse Retrieval）互补：稠密检索擅长"换个说法"的语义召回，但遇到专有名词、编号、缩写时稳定性不如稀疏检索。生产级 RAG 通常将两者结合为混合检索。

稀疏检索，基于词频统计的检索方法，以 BM25 为代表。与稠密检索（Dense Retrieval）的"语义匹配"不同，稀疏检索做的是"词项精确匹配"——合同条款号、产品型号、人名缩写等专有名词，稠密向量容易模糊，稀疏检索能精确命中。生产级 RAG 的标准做法是稠密 + 稀疏混合检索，互补增益。

Top-K 召回率，向量检索和 RAG 检索层最核心的评估指标：给定查询，正确答案在检索结果 Top-K 中出现的比例。K 通常取 5/10/20，配合 MRR（平均倒数排名）一起使用。健康线：检索层 Recall@10 ≥ 80%，低于此值先解决检索问题再调生成。注意评测集不能是模型训练数据，否则指标虚高。

元数据过滤，向量检索时按元数据（来源、日期、权限、类型等）缩小检索范围的技术。两种实现模式：预过滤（Pre-filtering）——在索引层先过滤再向量检索，Qdrant 的 payload 索引为代表，过滤严格时召回率稳定；后过滤（Post-filtering）——先向量检索 Top-K 再过滤结果集，pgvector 和大多数向量库的默认行为，过滤条件严格时可能返回空结果。预过滤是更可靠的生产方案。

意图识别，对话系统的第一层能力：判断用户消息想干什么（查订单、退款、投诉）。实现方式从规则/关键词、小模型分类，到大模型零样本（Zero-shot）分类。AI 客服落地中，意图识别的结果用于分级路由——高频标准化问题自动化、高风险问题转人工，是"AI 敢放手干"的前提。

意图分级路由，按意图级别把消息分发给不同处理通道：高频标准化问题（查单、改地址、开票）走全自动通道；中频半标准问题（退款、换货）AI 处理+人工确认关键动作；高风险/投诉问题直接转人工。分级路由的价值：把 70% 高频问题安全交给自动化，把 10% 高风险问题握在人工手里，是 AI 客服四层架构的第一层。

人工接管/转人工，AI 无法处理或高风险场景下把对话转移给人工坐席的机制。三个要点：转人工必须携带完整上下文（对话摘要+已尝试方案+用户信息），用户不能重复描述；兜底人力成本必须计入 AI 项目总账（否则"省了人但没省钱"）；兜底率是双刃剑——太高说明 AI 没省到人，太低说明风险没控制住。

人工介入率，AI 客服的关键运营指标：需要人工接管或确认的对话占总对话的比例。行业参考：简单问答型目标 10-20%，复杂业务型（售后、投诉、多轮办理）30-40% 属正常。与任务成功率、单次处理成本构成 AI 客服上线后必盯的三个数，也是渐进式落地中判断"要不要进下一阶段"的依据。

自然语言理解，让计算机理解人类语言含义的技术领域，包括意图识别、槽位填充（Slot Filling）、实体抽取、情感分析等任务。传统对话系统以 NLU 为核心，大模型时代 NLU 能力被 LLM 大幅吸收，但"意图识别+分级路由"仍是生产级 AI 客服的关键设计。

槽位填充，多轮对话中逐步收集完成一个任务所需的关键信息（槽位）的过程。例如改地址任务需要"订单号+新地址"两个槽位，AI 通过追问逐步填满。设计要点：槽位缺失时主动追问而非猜测；敏感操作（改收款账户）填满槽位后仍需人工确认。

情感分析/情绪识别，判断文本情绪倾向（正面/中性/负面）的技术。AI 客服中用于风险管控：识别出客户情绪激动或投诉倾向时，立即切换策略——停止标准话术、优先转人工，避免 AI 在舆情场景中说错话。情绪识别是"高风险场景拦截"的关键信号源。

任务成功率，AI 客服的核心质量指标：用户发起的任务（查单、退款、预约）中，最终被成功完成的占比。与人工介入率不同——介入率低不代表任务成功率高，也可能是 AI 答非所问客户放弃。统计口径建议按任务粒度（而非消息粒度）计算，并区分"AI 独立完成"与"AI+人工协作完成"两类。

模型迁移，企业将生产负载从闭源 API 切换到开源模型或新增多供应商的工程过程。2026 年趋势：OpenRouter 数据显示美国企业调用中国开源模型的 Token 占比从 2025 上半年 4.5% 涨到 30%+（峰值 46%）。正确流程：建评测基线（真实样本新旧模型对比打分）→ 上多供应商网关（统一协议+路由+熔断回退）→ 分层灰度迁移（按接口分批）→ 成本归因。前提是"随时可以切回去"——网关让切换成本趋近于零。

开放权重模型，公开下载模型权重（weights）、可自行私有化部署的模型（如 DeepSeek、Qwen、GLM、Kimi）。与闭源 API 的本质区别：数据不出企业内网、不受接口厂商限流/涨价/版本迭代约束，但需要自备推理基础设施与运维。2026 年企业迁移潮的三大驱动之一：成本便宜 60%-90%、性能够用（91% 工程师不需要极限性能）、部署自由。

多供应商网关，统一接入多家模型供应商的中间层，业务侧全部走 OpenAI 兼容协议，由网关层做路由（按接口/任务/用户分发）、限流、熔断与自动回退。价值：单一供应商故障或涨价时不中断业务；模型迁移的"可回退"前提；多模型分层选型的落地点。与 API Gateway 的区别：前者专为模型供应商设计，包含模型路由与成本归因能力。

数据驻留/数据驻留地，数据存储与处理必须位于特定地理或法律管辖范围内的合规要求。企业 AI 落地中的关键约束：数据不能出域（内网/国境）时不能调用公共 API，必须选择私有化部署开源模型。决定"API 还是私有化"的第一因素，金融、医疗、政务场景优先于一切成本考量。

生产级开源 LLM 推理服务框架，OpenAI 兼容 API 开箱即用。两大核心机制：PagedAttention（KV Cache 分页管理，显存利用率高、支持更多并发）与 Continuous Batching（连续批处理，新请求随时插入在飞批次，短请求先走）。官方支持 Qwen/DeepSeek/Llama 等主流开源模型，是私有化推理生产部署的默认选择。关键启动参数：--gpu-memory-utilization（默认 0.9）、--max-num-seqs（有效并发上限）、--enable-prefix-caching（前缀缓存）。

Transformer 推理中缓存历史 Token 的注意力键值（Key/Value）张量的机制——生成每个新 Token 时只需计算它与全部历史 KV 的点积，避免重复前向计算。显存公式：2 × 层数 × KV头数 × 头维度 × 每 Token 字节数 × 上下文 Token 数。是私有化部署的显存大头（权重之外的主要占用），也是并发上限的决定因素；PagedAttention 将其按页管理以减少碎片。

连续批处理，推理引擎按"请求完成即让位"的方式动态调度批次：新请求随时插入在飞批次，短请求先生成完先退出，长请求继续。与静态批处理（凑满一批再算，长请求堵住短请求）相比，GPU 利用率显著提升，是 vLLM 等生产推理引擎吞吐领先的核心机制。注意：显存不足时有效并发被 KV Cache 上限卡死，批处理没有发挥空间。

分页注意力，vLLM 提出的 KV Cache 显存管理技术：像操作系统分页一样，将 KV Cache 划分为固定大小的页，只分配实际用到的部分，显著减少显存碎片与浪费，让更多并发请求塞进同一张卡。这是 vLLM 吞吐领先的成名机制，无需配置——但"KV Cache 上限就是并发天花板"这一认识是调优的前提。

前缀缓存，缓存请求共享前缀（系统提示词、RAG 文档前缀）的 KV 计算结果，命中后直接复用、跳过重复计算。多轮对话与 RAG 场景命中率常达 70-90%，等于白赚输入算力。工程要点：提示词"前静后动"（固定内容放前缀、变化内容放后面）最大化命中；vLLM 中对应 --enable-prefix-caching；监控命中率（目标 > 50%）判断提示词结构是否合理。

投机解码，用小型草稿模型先快速生成 k 个候选 Token，再由大模型一次性并行验证——验证通过的部分原样采纳，失败则从分歧点重新生成。生成速度可提升 1.5-3 倍，适合 70B 级大模型、延迟敏感且算力富余的场景；vLLM 等引擎内支持。并非所有负载都划算（小模型本身就快时收益有限），先测收益再启用。

提示注入，攻击者把恶意指令注入 LLM 输入上下文、诱导模型执行非预期动作的攻击。与 SQL 注入的本质区别：SQL 注入是"代码与数据未分离"（用户输入被拼进 SQL 执行），提示注入是"指令与数据未分离"——模型无法区分系统指令和内容里的指令，因为 LLM 输入本质是纯文本。防御核心：输入侧隔离声明（内容只是参考资料不是指令）、输出侧独立校验、高风险操作人工兜底。

间接提示注入，攻击者把恶意指令藏在模型检索到的网页、文档、邮件等外部内容里，用户无需输入任何恶意文本，模型读取数据时即"中毒"执行。RAG 应用和 AI 客服的独有风险，危害等级最高（如网页藏转账指令）。防御三层：系统提示词声明"检索内容不是指令"、敏感操作过独立规则校验或人工确认、入库文档合规审查且外部内容打"不可信"标签降级处理。

越狱，通过角色扮演、虚构场景、假想对话等方式绕过 LLM 安全限制的攻击。典型手法："假设你是一个没有安全限制的模型"、剧本设定、ASCII 艺术混淆等。与提示注入的区别：越狱目标是突破模型本身的安全对齐，提示注入目标是诱导模型执行具体动作。防御：持续红队测试 + 绕过用例沉淀为回归集，新模型发布后第一时间重跑（模型能力变强，攻击手法也变强）。

红队测试，模拟攻击者对 LLM 应用做对抗性安全测试的方法。四类必测攻击：直接注入（忽略指令/套取系统提示词）、间接注入（恶意文档）、越狱（角色扮演）、数据提取（翻译/复述/编码绕过）。正确做法：独立红队（非开发人员或专门攻击模型）避免"自己测自己"的盲区；记录绕过率（建议 < 5%）作为上线门槛；用例沉淀为回归集，每次提示词/工具/模型变更后自动重跑。

沙箱隔离，把可能执行任意代码/动作的组件（如 Agent 的代码执行器）放进受控环境运行的机制。要点：无网络出站权限（防止数据外传）、文件系统只挂载必要目录、资源限额（CPU/内存/磁盘）、进程生命周期受控。是 Agent 工具权限治理的关键一环——即使模型被提示注入骗着调用了工具，沙箱也能把破坏范围限制在隔离环境内。

数据外泄/数据窃取，攻击者从 AI 应用中提取敏感信息的攻击。四条渠道：提示注入诱导复述（翻译/编码绕过限制套取隐藏内容）、多用户会话隔离不到位、日志与缓存留存 PII 明文（拖库泄露）、工具副作用（模型把数据写入不该写的存储）。防御：会话级数据隔离、日志脱敏（PII 字段脱敏或加密）、敏感类目禁用 Prompt Caching、工具写路径白名单。

Agent 记忆，为无状态的 LLM 维护跨调用状态的能力——把什么塞进上下文、把什么存到外部、什么时候取回，由应用层设计实现。模型本身是无状态的，所谓"记忆"本质是替模型维护状态。分类：短期记忆（会话消息）、工作记忆（任务状态）、长期记忆（跨会话用户画像与结论）。设计好坏决定 Agent 能否从"单轮问答"进化成"连续干活的工作流"。

短期记忆，当前会话内的原始消息序列，存在于 LLM 上下文中，会话结束即失效。工程实现：每次模型调用前自动追加，配合上下文窗口裁剪（只保留最近 N 轮）或滚动摘要控制 Token 占用。丢失后果：会话内"断片"、答非所问。与工作记忆（任务状态）和长期记忆（跨会话画像）共同构成 Agent 记忆三层。

工作记忆，当前任务进行中的状态——已执行步骤、中间结果、待办清单。生命周期与任务绑定：任务开始写入目标、每个步骤完成写入结果、任务失败写入原因；任务完成或超时（如 24h）后归档。工程实现：Redis Hash 或数据库表按 task_id 存取，需支持崩溃恢复。丢失后果：任务中断后无法续跑，只能重新开始。

长期记忆，跨会话保留的用户画像、偏好、历史结论。只存"结论性信息"（用户明确偏好、任务结束摘要、跨会话复用的事实），过程性信息不入库以防噪声。存储：语义型用向量库（Qdrant/Milvus/pgvector）存摘要向量按需检索，结构化事实用 PostgreSQL 按 user_id 存取。丢失后果：每次都"重新认识用户"，体验差。

记忆摘要/对话压缩，对话滚动到阈值后把旧内容压缩成摘要放进上下文、保留"结论"而非"过程"的技术。要点：主动触发而非每轮执行（如累计 20 轮或上下文用掉 70% 才滚动），避免无谓模型调用；摘要本身有信息损耗，细节会被"滚"掉。与裁剪（丢最老）和检索（按需召回）组合，是长对话控制 Token 成本的默认解。

记忆检索，回答时按相关性从存储层召回记忆片段注入上下文的技术。触发时机：会话开始时拉用户画像、任务开始时拉历史结论、上下文缺失信息时触发向量检索。要点：检索到的冲突记忆按"时间新者优先 + 主动向用户确认"处理，不让模型自己猜；召回相关性 ≠ 重要性，可能需要混合检索或重排。

记忆衰减/遗忘策略，记忆系统主动"会忘"的机制：短期会话结束即清空（TTL）；工作记忆任务完成或超时后归档；长期记忆超过 N 天未被检索则降权或过期；用户修正偏好时旧记忆标记失效而非共存（否则模型每次看到矛盾信息）。合规刚需：用户主动要求删除的记忆必须可删（delete 接口 + 用户可见的"清除记忆"入口）。

记忆隔离，多租户场景下记忆按 user_id 维度的行级隔离——A 用户的记忆绝不能检索到 B 用户，是安全事故底线。配套治理：写入时脱敏（PII 检测，身份证/手机号/银行卡命中即脱敏或加密，明文不进存储层）、长期记忆只存摘要不存原始消息（降低泄露面）、提供 delete 接口满足合规。

经过人工标注、带有"期望答案"的高质量评测样例集，是 LLM 评测可信度的基础。建设三原则：从真实流量采样而非自己编例子（自编样例容易"设计得刚好能过"）；多人标注先对齐标准（双人标注+分歧仲裁，否则标注分歧变成评测噪音）；持续扩充（每次线上问题、每条客户反馈都转成样例）。评测集质量决定评测可信度上限——评测集偏了，后面所有指标都是自欺。

由历史修过的问题复现样例组成的评测子集，用于防止回退——"上周修好的 bug 这周又出现"。建设方法：每次修完线上问题，把复现样例沉淀进回归集；每次提示词/模型/工具变更后自动重跑，发现回退立即拦截。回归测试必须自动化，靠人肉回忆"上次哪改坏了"毫无生产力。与能力集（基准能力）、对抗集（边界/恶意输入）构成三层评测集。

由边界/恶意输入组成的评测子集（超长、错别字、诱导、越狱等），检验 LLM 应用在极端情况下的鲁棒性。来源：红队测试沉淀 + 线上异常输入收集。与能力集（正常场景基准）、回归集（历史问题防回退）共同构成完整评测集。对抗集是安全评测（红队）与质量评测的交汇点——LLM 安全实战中的四类攻击测试可直接沉淀为对抗集样例。

评测样例出现在模型训练数据中导致指标虚高的现象——模型"见过答案"，评测结果不可信。缓解：① 评测集用最新真实数据持续更新，避免复用公开数据集中被反复使用的样例；② 用发布时间晚于模型训练截止的线上数据评测；③ 敏感/独特场景自建评测集；④ 定期换说法重问同一问题，检查是否被"背下来"。污染评测集比没有评测更危险——它给出虚假的安全感。

LLM-as-a-Judge 的常见偏差之一：裁判倾向于给固定位置（如第一个）的答案更高分，与内容质量无关。解法：轮换答案顺序做两次对比取平均，或采用单条评分而非对比评分。校准 Judge 时需同时检查位置偏差、自我偏好偏差（更喜欢"说话风格像自己"的输出，解法是给评分标准 rubric 而非开放式"谁更好"）、冗长偏差（答案越长分越高，解法是分维度打分或长度归一）。人工一致率 ≥ 85% 才算校准通过。

LLM-as-a-Judge 的常见偏差之一：裁判模型更喜欢与自身风格一致的输出——风格相似但内容更差的答案得分反而更高。解法：给评分标准（rubric）按维度打分，避免"哪个更好"这种开放式对比；必要时用不同模型做裁判交叉验证。与位置偏差、冗长偏差并称 Judge 三大盲区，校准方式统一为拿 30-50 条人工标注样本测一致率，达不到 ≥ 85% 就换更强的裁判或保留人工抽检兜底。

LLM-as-a-Judge 的常见偏差之一：答案越长得分虚高，即使内容冗余、答非所问。产生原因是裁判模型对"信息量"的感知与长度强相关。解法：分维度打分（相关性/完整性/简洁性），或对长度做归一化处理；也可在评分标准中明确"简洁加分、冗余扣分"。实际工程中常与位置偏差、自我偏好偏差一起校准——三者是 Judge 可信度检查的标配清单。

给 LLM-as-a-Judge 的明确评分维度与规则（如相关性 0-5 分、完整性 0-5 分、简洁性 0-3 分），替代"哪个更好"这类开放式对比。作用：① 降低裁判模型的自我偏好偏差和冗长偏差——有维度有锚点，打分才可复现；② 让评分结果可解释——客户/团队能看到"为什么这版比上版好"；③ 便于校准——把 rubric 输出与人工标注对比，量化 Judge 一致率。评分标准是 Judge 从"感觉打分"变成"工程指标"的关键。

监督微调，用"指令-期望回答"配对数据继续训练模型的阶段，是微调的主战场。数据量级参考：500-5000 条高质量配对即有清晰效果，质量远大于数量（1000 条精心清洗的数据胜过 5 万条爬来噪音）。数据来源优先级：线上真实流量整理 > 合成数据+人工清洗 > 通用公开数据。训练后必须做前后对比评测，否则微调是玄学不是工程。

低秩适配，参数高效微调的主流方法：冻结原模型权重，只训练注入的少量低秩适配矩阵（参数占比通常 <1%）。单张 24G 消费级显卡即可微调 7B-32B 模型，效果接近全参微调，且改动幅度小、灾难性遗忘风险天然更低。是 2026 年微调事实上的默认选项；全参数微调效果上限更高但成本与风险高，无充分理由不建议。

量化低秩适配，将模型 4-bit 量化后再做 LoRA 微调，单张 12-16G 显卡也能微调 7B-14B 级模型，是小团队和资源受限场景的默认起点。代价是训练质量略低于 LoRA 全精度微调。选型顺序：显存紧张用 QLoRA 起步，效果不够再升级 LoRA 或全参。

用"指令-回答"格式的数据微调模型，让模型学会按指令执行任务、对齐输出格式，是 SFT 的主流形式。核心在数据：指令要贴近真实用户提问（别用"设计得刚好能过"的自编例子）、回答要有规范格式样例。与领域知识微调的区别：指令微调教"怎么干活"，领域微调教"懂什么专业"——生产实践常两者混合。

人类反馈强化学习，用人类偏好数据对模型进行对齐训练的技术栈，让模型输出更符合人类期望（有用、无害、诚实）。分为三步：SFT 基线 → 训练奖励模型（人类排序打分）→ PPO 强化学习。成本高、工程复杂，企业微调一般到 SFT 就够；RLHF 层通常由模型厂商完成，企业自训 RLHF 需要充分理由（如强价值观约束场景）。

模型在新数据上变强、却在原有通用能力上退化（算术、常识、其他领域问答变差）的微调副作用。三个标准缓解手段：① 数据混合——微调数据掺入 10-20% 通用数据，"边学新知识边复习旧知识"；② 参数高效微调——LoRA/QLoRA 改动幅度小，遗忘风险天然更低；③ 训练后必测——同一评测集前后对比，通用分掉太多先调数据配比再上线。

由大模型生成的训练数据，用于解决无标注数据起步问题。标准做法：让大模型按业务场景批量生成"问题-答案"对，人工抽检清洗后入库；也可用真实样例改写（paraphrase）扩充覆盖。注意合成数据的自我循环风险——合成数据喂给模型再生成新数据，错误会逐代放大，必须人工质检兜底，绝不能直接拿来训。

知识蒸馏，用大模型（教师模型）的输出数据训练小模型（学生模型），让小模型学会大模型能力的压缩技术——容易记反，方向是小模型学大模型。常见用途：把旗舰模型的能力蒸馏进 7B 级模型，做低成本路由、离线分类、私有化部署。注意：蒸馏模型会继承教师模型的偏差与幻觉模式，评测不能省；教师与学生能力差距过大时蒸馏收益有限。

数据出域，指企业数据离开自身控制范围，被外部服务商（云厂商、AI 模型提供商）访问或处理。判断标准：数据在传输、存储、处理任一环节经过第三方服务器，即构成出域。常见场景：调用公有云 AI API、使用 SaaS 型 AI 工具、外包 AI 训练/微调。不出域方案：私有化部署、本地化推理、联邦学习。

以电子或其他方式记录的与已识别或可识别的自然人有关的各种信息，包括姓名、身份证号、手机号、生物特征、位置信息等。《个人信息保护法》要求：个人信息出境需满足标准合同、认证或安全评估之一；处理个人信息应遵循最小必要原则；敏感个人信息（金融账户、生物特征、医疗健康）需单独同意。AI 场景常见风险：训练数据、对话日志、用户反馈中混入个人信息，出境或使用前须脱敏。

一旦遭到篡改、破坏、泄露或非法获取、非法利用，可能危害国家安全、经济运行、社会稳定、公共健康和安全的数据。典型范围：未公开的财务数据、客户名单、技术文档、商业策略、基础设施运行数据、人口健康数据。重要数据出境需通过网信办安全评估，未评估不得出境。与核心数据的区别：核心数据原则上不得出境，重要数据可经评估后出境。

对数据中的个人信息或敏感信息进行变形、替换、屏蔽或伪匿名化处理，降低泄露风险的技术措施。常用手段：替换（手机号 138****1234）、截断（身份证前 6 位）、哈希（不可逆映射）、泛化（年龄段代替具体年龄）、扰动（数值加噪）。注意：脱敏不等于匿名化——脱敏数据仍可能通过关联分析还原个人信息，出境场景需做残留风险评估。与匿名化的区别：匿名化不可逆、无法还原；脱敏可逆或可关联还原。

一种分布式机器学习范式：多个参与方在本地训练模型，只交换模型参数（梯度），原始数据始终不出本地。核心优势：数据不出域，满足合规要求；多源数据协同训练，提升模型泛化能力。三类架构：横向联邦（样本不同特征相同）、纵向联邦（特征不同样本重叠）、联邦迁移学习（样本和特征都不同）。局限：通信开销大、协调成本高、模型参数仍可能携带训练数据信息（梯度泄露攻击），需配合安全聚合和差分隐私。

面向公众提供算法推荐服务或生成式 AI 服务的企业，依法向网信办提交备案材料的制度。算法备案依据《互联网信息服务算法推荐管理规定》，生成式 AI 服务备案依据《生成式人工智能服务管理暂行办法》。备案材料包括：算法安全评估报告、数据来源说明、内容过滤机制、用户权益保障方案。审核周期 2-3 个月，未备案不得上线面向公众的服务。企业内部使用 AI 目前不强制备案，但生成内容面向公众时需做内容标识。

专门针对生成式 AI（大语言模型、图像生成、视频生成等）面向公众提供服务时的备案制度，依据《生成式人工智能服务管理暂行办法》。与算法备案并列，但侧重生成式 AI 的特殊风险：生成内容标识、虚假信息防范、训练数据来源合规。已通过备案的模型名单可在网信办官网查询。使用已备案模型可简化备案流程，自研/微调模型需单独申请。

在 AI 生成内容（文本、图片、视频、音频）中嵌入可识别的"AI 生成"标记，满足合规要求的技术措施。三类方案：① 显式标识（水印/角标）——直观但影响视觉；② 隐式标识（隐写/元数据）——隐蔽但需专用工具检测；③ 结构化标识（API 响应字段）——适合程序化消费。2026 年合规要求：面向公众的生成内容必须可识别，推荐显式+隐式双保险。与水印的关系：水印是显式标识的一种实现，隐写是隐式标识的一种实现。

基于角色的访问控制：权限授予角色（如 dept:hr、role:executive），用户通过所属角色间接获得权限，而不是逐用户授权。RAG 知识库的主力权限模型——文档元数据存"可见角色列表"（acl），检索时用户的角色与 acl 做交集匹配。适合部门/职级清晰的组织；粒度比 ABAC 粗，但实现和审计成本最低。

基于属性的访问控制：用属性策略表达式（用户属性 × 资源属性 × 环境属性）动态判定权限，如"文档密级 ≤ 用户密级 且 同部门"。比 RBAC 灵活（可表达条件逻辑），但策略编写、调试、审计成本高。RAG 场景建议：先用 RBAC + 密级元数据两级，出现真实条件逻辑需求再演进 ABAC，避免过度设计。

访问控制列表：直接挂在资源（文档）上的"可见主体列表"。RAG 中通常以向量库元数据字段实现（如 acl: ["dept:hr", "role:executive"]）。设计要点：① 存 ID 不存名称（部门改名不触发重建）；② 继承权限在索引时展平；③ 临时授权放独立 grant 表 + TTL，不污染 acl。

最小权限原则：每个主体只授予完成工作所必需的最小权限集合。RAG 三层体现：① 数据层——文档按最小可见范围建 acl；② 应用层——检索权限参数只来自服务端会话，不信任用户输入；③ 模型层——系统提示不罗列文档清单、不给模型超出上下文的"记忆"。配合审计日志（每次检索的权限判定结果）形成闭环。

行级安全，数据库层面的权限机制：同一张表的不同行对不同用户可见性不同（如 PostgreSQL 的 RLS 策略）。RAG 中向量库的 metadata filter 是"向量版的行级安全"——同一 collection 内按元数据谓词隔离不同用户的可见 chunk。ES 的 document-level security、pgvector + RLS 是两种典型实现。

向量库中按租户/用户组/密级将数据切分到独立 collection（或 namespace）的物理隔离手段。共享文档在多个 partition 各存一份：写入成本升高、权限变更要同步 N 份副本，但隔离强度最高——跨 partition 的数据串扰在架构上不可能发生。多租户 SaaS 知识库、高合规行业的标准做法；Milvus 的 partition、ES 的 index 都适用。

源文档系统（Confluence/SharePoint/飞书）的权限变更同步到向量库元数据的机制。推荐事件驱动（webhook/MQ → 增量更新 acl 元数据）+ 每日全量对账兜底。工程铁律：① 增量更新不重建索引；② 同步失败时默认收紧（visibility 降级），宁可漏召回不可越权；③ 高危文档追加实时二次鉴权（检索命中后调源系统授权 API 确认）。只索引不更新权限 = 定时炸弹。

面向 AI 负载的财务运营实践：把云成本优化（资源层）延伸到 Token 计费层，核心是"成本可度量、可设限、可告警"。三件套：① 计量——网关层记录每次调用的 model/key/scenario/task_id/tokens，不信任客户端自报；② 单位经济学——用 Cost per Task 替代 $/request 做业务成本核算；③ 控制——Token Budget 硬上限 + Cost SLO + 异常检测。与 FinOps 传统三大支柱对应：Inform（成本可视化）→ Optimize（四层降本杠杆）→ Operate（预算与告警当 SLA 管）。

按 场景 × 租户/项目 维度设置的月度 Token 硬上限，网关侧实时计量累计，到 80% 告警、100% 执行 on_exceed 策略（降级小模型 / 拒绝 / 审批放行）。铁律：① 双闸门——场景级（细粒度降级）+ 项目级（总闸熔断），缺一层时单场景 bug 会烧穿整个项目；② 计量在网关，不信任客户端自报 token 数；③ 预算值必须留 3 倍流量余量，上线第一周的账单波动远超预估。

AI 项目的核心单位经济学指标：Cost per Task = Σ(任务链路上所有模型调用成本) / 业务完成的任务数。分母是"业务完成"（一条工单闭环、一篇摘要产出）而不是 API 请求数；人工兜底的任务也算完成，成本里含人工。只有它能回答"上 AI 前（人工成本）vs 上 AI 后（模型+运维+兜底）谁更便宜"，并能暴露"便宜模型因成功率低反而更贵"的经典陷阱。配套指标：Token Efficiency（每百万 Token 完成的任务数）与 Quality-Adjusted Cost（成本/质量分，防止降本=降质自欺）。

供应商提供的离线批处理推理 API：提交批量请求文件，24h 内返回结果，单价通常为实时 API 的 50%。适用一切非实时场景（摘要/数据标注/批量生成/评测跑分）。工程要点：① 业务侧要有"完成回调 + 超时补跑"（SLA 是 24h 不是承诺）；② 文件按场景拆分，别把高优和低优混在一个文件（整文件一起返回）；③ 成本记账时 batch 单价单独标记，否则 Cost per Task 算错。

主模型失败或降级时的自动切换机制，三层含义：① 错误回退——主模型超时/限流/5xx 时切备用供应商或备用模型，保障可用性；② 预算回退——触发 Token Budget on_exceed 时从旗舰模型降级到小模型，业务不中断；③ 质量回退——级联路由中小模型置信度不足时升级大模型（方向相反的"升级回退"）。铁律：回退链每层都要有独立超时（避免级联等待放大延迟），且回退事件必须进监控大盘——频繁回退是主模型定价/配额/质量的先行指标。

多团队/多项目共用 AI 能力时的成本归属与结算机制。三档方案：① <5 团队——统一预算 + 场景级成本报表（不分摊）；② 5-20 团队——项目级 API Key + 网关按 Key 计量 + 独立预算 + 超额审批；③ 20+ 团队（AI 中台）——内部定价结算（结算价 = 供应商成本 × 1.1-1.3，含运维摊销）。铁律：分摊粒度到"场景"不到"团队"（一个 Key 混多个功能永远算不清），场景标签在网关强制要求。

o1/R1 类推理模型在生成答案前的内部思考 Token：按输出单价计费但内容不可见、数量不可直接控制（模型自行决定思考深度）。成本风险：同一问题思考 200 vs 8000 token，差价 40 倍，且账单里只看到 output_tokens 总数。管理要点：① 限定使用场景——只有确实需要深度推理的任务走推理模型；② 监控 reasoning token 占比（推理模型 API 返回的 usage 里单独可查）；③ 简单任务误路由到推理模型是账单异常的头号原因，异常检测规则里单列一条。

把成本当作 SLA 一部分的管理机制：不是"成本越低越好"，而是设定"每任务成本 ≤ X"的目标值，纳入监控大盘，超了和延迟超标一样触发 on-call。与延迟/成功率 SLO 并列（如：Cost per Task ≤ 0.8 元，7 天均值 > 1.0 元告警）。超标排查四因：路由变化（大模型占比升）、提示词变长、流量结构变化（简单问题占比降）、供应商调价——前两个团队能控制，后两个要写进合同和变更流程。

LLM 输出 100% 符合指定 JSON Schema 的约束机制：字段名、类型、枚举值全部强制（OpenAI structured_outputs、Anthropic tool use、Qwen/DeepSeek 的 json_schema 变体均属此类）。关键认知：约束的是"形状"不是"事实"——schema 挡得住格式错误，挡不住语义幻觉（格式完美但不存在的 order_id），必须叠加执行层的参数校验。云端 API 默认选择；纯提示词 + "请输出 JSON" 已淘汰。

LLM 按声明的工具 schema 输出结构化调用请求（工具名 + 参数）、由程序执行的机制。工程要点：① 工具描述比 schema 重要——写清"什么情况下调 / 参数从哪来 / 缺了怎么办"，误调率降一个数量级；② 工具粒度收敛，单工具参数 ≤4 个，参数越多模型越爱编；③ 执行前在数据层验证参数存在性（白名单校验），无效参数不抛异常，而是回喂"不存在 + 原因 + 候选值"让模型重试。

API 参数 response_format: json_object 提供的轻量约束，保证输出"是合法 JSON"，但不保证符合指定 schema（字段名拼错、多字段、漏字段仍可能出现）。定位：老模型/小模型的兜底手段，必须配解析重试链使用。2026 年基线能力是 Structured Outputs（schema 级约束），JSON Mode 介于纯提示词与结构化输出之间——"合法但不一定对"。

描述 JSON 结构的标言语汇（type/enum/required/maxLength/additionalProperties 等），LLM 结构化输出的约束载体。Schema 设计六条铁律：① 嵌套 ≤2 层、每层 ≤8 字段（深层嵌套是小模型翻车重灾区）；② 枚举优于开放字段（有限取值必须 enum）；③ 字段名自解释 + description 带可执行判定标准；④ 提示词给 1-2 个完整 few-shot 示例；⑤ required 最小化，其余 optional + 默认值；⑥ 禁止二维数组（嵌套数组是可靠性悬崖），扁平数组 + 外键。

JSON Schema 关键字，设为 false 时输出禁止携带 schema 之外的字段。纯提示词/JSON Mode 下模型常"自由发挥"加字段，仅在 Structured Outputs 下才真正生效（解码器直接屏蔽非法字段）。铁律：所有业务 schema 一律设 false，否则下游校验器永远在追模型的即兴发挥。

在推理引擎层做语法约束的技术：生成时逐 token 屏蔽不合法 token，保证输出 100% 符合约束（outlines/guidance/lm-format-enforcer 等库）。私有化部署的标准解：vLLM/Ollama 兼容 OpenAI API 但没有 structured outputs 开关，约束必须下沉到解码层（vLLM 原生支持 guided_json/guided_choice）。代价是逐 token 约束的轻微减速，多数场景可忽略；仅对可编译为语法的 schema（JSON Schema/正则）有效，自由叙述不适用。

结构化输出的失败兜底机制：解析/校验失败时不裸重试原提示词（成功率仅 ~60%），而是把"校验错误 + 原输入"回喂模型重新生成（如"你上次输出缺少 required 字段 urgency"），成功率升至 95%+。铁律：① 重试上限 2 次，第 3 次基本必败，转降级路径；② 截断导致的失败不可修复（缺的 token 补不回），只能整次重试，所以 max_tokens 按 schema 最大长度 ×1.5 设定；③ 重试成功率要埋点，突增 = 模型版本静默升级或提示词变更的信号。

长文档结构化生成的模式：第 1 次调用只输出结构化骨架（章节数组 + 每章要点），第 2..N 次调用逐章填充（可并行），最后程序按 id 锚点组装。相比整篇塞一个 output 字段：① 避免 max_tokens 截断（截断的 JSON 不可恢复）；② 单章失败只重跑该章；③ 骨架可先审，填充前就能改章节结构。适用于报告、长文等"结构化骨架 + 长文本"任务，章节并行后总耗时往往更短。

端到端延迟，从用户发送请求到收到完整响应的总时间。Agent 场景下 = LLM 推理延迟 + 工具调用延迟 + 网络延迟 + 队列等待延迟。优化目标：简单任务 < 5 秒，复杂任务 < 30 秒。端到端延迟是用户体验的综合指标，比单独看 TTFT 更能反映真实感受——用户不关心哪个环节慢，只关心"多久能拿到结果"。

LLM 逐 Token 返回输出的技术，用户无需等待完整响应生成即可看到内容。实现：使用 SSE（Server-Sent Events）或 WebSocket 推送。效果：感知延迟降低 50-80%（3 秒完整等待 → 0.5 秒开始看到输出）。限制：工具调用结果必须等待完整返回，不能流式；错误处理需在流式结束后统一处理。Agent 场景下流式输出是延迟优化的第一优先级。

多个独立工具调用同时执行的技术，总延迟 = 最慢单个工具延迟，而非所有工具延迟之和。实现：Promise.all（JavaScript）或 asyncio.gather（Python）。判断标准：工具调用之间无依赖关系（如同时获取用户信息、订单信息、推荐信息）才可并行。实测：3 个各 1 秒的工具调用，并行后总延迟 1 秒（原 3 秒）。Agent 性能优化中收益最大的单一优化点。

Agent 调用外部工具（API、数据库、搜索引擎）的响应时间。常见瓶颈：外部 API 调用（1-5 秒）、数据库查询（0.1-1 秒）、文件读写（0.5-2 秒）。优化策略：① 并行化（独立工具并行执行）；② 缓存（相同参数结果缓存 5-30 分钟）；③ 超时控制（设置 5-10 秒超时，超时后降级）；④ 批量调用（多个查询合并为一个请求）。实测中工具调用延迟常占端到端延迟的 60-80%，是最容易被忽视的优化点。

缓存请求中命中已有缓存的比例，衡量缓存效果的核心指标。计算：命中次数 / 总请求次数 × 100%。Agent 场景下三类缓存：① LLM 响应缓存（相同输入+参数，TTL 1 小时）；② 工具调用结果缓存（相同参数，TTL 5-30 分钟）；③ 高频问题缓存（常见问答，TTL 24 小时）。目标：整体命中率 > 60%，工具调用缓存命中率 > 40%。命中率过低需检查缓存键设计（是否过于精细）或 TTL 设置（是否过短）。

在延迟、吞吐量、成本三个维度上优化 AI Agent 生产环境表现的工程实践。三个核心维度：① 延迟（TTFT、端到端延迟）——用户体验生命线；② 吞吐量（并发处理能力）——系统容量天花板；③ 成本（Token 消耗、工具调用开销）——运营效率底线。优化顺序：先保延迟（用户体验），再提吞吐量（系统容量），最后压成本（运营效率）。配套：生产监控（TTFT、端到端延迟、工具调用成功率、Token 消耗、并发用户数）+ 分级告警（P0/P1/P2）。

每百万 Token 完成的业务任务数，衡量 Token 利用效率的核心指标。计算：完成的任务数 / 消耗的 Token 总数（百万）。Token 效率低的三个原因：① 提示词冗余（系统提示 > 500 Token）；② 上下文管理差（保留过多历史对话）；③ 工具调用结果重复入上下文。优化收益：某客服 Agent 项目通过上下文压缩，Token 效率从 50 任务/百万 Token 提升到 120 任务/百万 Token，成本降低 58%。与 Cost per Task 配合使用。

自然语言转 SQL，让用户直接用自然语言查数据库，系统生成 SQL、执行并连同口径一起返回结果。生产级实现的瓶颈不在“生成 SQL”而在“理解业务”：约 80% 工作量在语义层（业务词 → 字段/口径映射），15% 在工程架构（Schema Linking、生成约束、权限注入、执行限制），5% 在提示词。上线门槛：核心 20 个高频问题语义正确率 ≥ 95%，且每个回答带“可展开 SQL + 口径说明”。

NL2SQL 的同义表达，强调“自然语言文本 → SQL”的翻译过程。学术基准（Spider/BIRD 等）中是标准评测任务；工程语境中通常指完整生产链路：语义层 → Schema Linking → 约束生成 → 权限注入执行 → 结果解释。三大典型翻车点：① 整个库表结构全量塞进提示词（超上下文 + 同名字段混淆）；② 靠提示词约束权限（模型会“配合”越权请求）；③ 只在精挑的标准问题上评测，真实用户流量下准确率骤降。

NL2SQL 中的召回步骤：对每个用户问题，只从数据库中召回相关的 3-8 张表、10-20 个字段进上下文，而非全量塞入。三级漏斗（向量粗召回 → 权限白名单过滤 → LLM 精排）是常见生产实现。关键细节：① 向量用表/字段的业务注释生成，不用表名（表名是技术标识符，匹配不准）；② 无权表在召回阶段剔除——模型必须“看不到”；③ 指标字典点名的字段排候选列表最前并加强调标记，LLM 对靠前、带强调的上下文权重更高。

数据域中位于物理表之上的业务-数据统一映射层：业务词典（同义词/黑话 → 字段）、指标字典（指标名 → 公式 → 标准过滤条件）、表/字段级业务注释。语义层是指标口径的唯一事实源——BI 报表与 NL2SQL 都从它取口径，避免“同一指标两套算法”。NL2SQL 项目中它是护城河也是最大工作量项（约 80%）；标准动作是拉业务方（不是数据组）开 2-3 天工作坊，逐条过 Top 30 高频问题，把确认的口径沉淀进字典。

语义层中业务指标的资产化结构：每条 = 指标名 + 计算公式 + 标准过滤条件 + 口径确认时间与确认人。是 NL2SQL 最高频错误“口径错位”（模型自创“复购率”定义）的解药。三个工程要点：① 字典由业务方逐条确认，数据组不得闭门编写；② 同一业务词可挂多个口径命名空间（运营/财务），按用户角色在生成时注入对应口径；③ few-shot 示例从字典自动拼装（业务问题 + 标准 SQL），口径与示例永远同步。

业务用自然语言提问、直接拿到结果图表与口径说明的分析交互范式，免去 BI 排期链条。正确定位是“补位”而非“替代” BI：高频固定问题走 BI 报表（快、准、便宜），长尾探索问题走对话式 BI（灵活、即时、带解释），两者共用同一套语义层。实测规律：对话式 BI 上线后 BI 报表使用率通常不降反升——业务先问 AI，AI 把固定问题导流回现成报表。

联机分析处理，面向大数据量多维聚合分析的技术与建模方法（与面向在线事务处理的 OLTP 相对）。特征：复杂聚合查询、读多写少、建模倾向维度建模（星型/雪花）。NL2SQL / 对话式 BI 场景中 OLAP 是典型目标库——查询模式聚合型，全表扫描与笛卡尔积代价高，权限谓词注入与行数限制是必配项。

数仓经典维度建模模式：中心事实表（订单等）+ 围绕它的多张维度表（时间、区域、商品等），形如星形。相比三范式模型，聚合查询 join 数少、允许列冗余（存储便宜、计算贵）。NL2SQL 项目中星型模型是模型最友好的库表结构——事实表/维度表选择直观、同名字段歧义少。底层是三范式结构时，先在语义层预注册“业务问题 → 事实表 + join 路径”映射。

RAG 知识库中知识的新鲜程度，指索引内容与事实源文档的一致性随时间的保持能力。失效分四类：内容过期（源已更新索引未更新）、僵尸 chunk（文档已废止向量未删）、覆盖缺口（新文档未入索引）、事实源漂移（文档与业务系统数据打架）。新鲜度是过程指标不是状态——上线即开始衰减，必须用 Freshness SLA、矛盾检测、时效探针三件套持续度量，而不是上线时验收一次。

一个事实的唯一权威来源（政策走审批流、价格走业务系统、流程走文档系统）。RAG 时效管理的第一性原理：知识库与事实源之间必须存在自动同步链路，不能只有“某次”人工搬运。常见错误是以“文档最后编辑时间”为生效点——编辑了半个月还在审批的文档不算生效，生效点应是审批通过/发布事件。同一事实在文档、系统、口口相传里各有一个版本时，先收敛事实源再谈建库。

RAG 更新管线的标准模式：文档变更只重切自己的 chunk、按 source_id 删旧 chunk、upsert 新 chunk，成本从“小时级全库”降到“分钟级单文档”。前提是每份文档有稳定 source_id、每个 chunk 有 content_hash。更新管线的成本决定知识库的新鲜度——全量重建太贵，更新就会退化成季度工程，两次重建之间的知识全是盲区。全量重建只留给向量模型升级与切分策略大改两种场景，且应双索引切换避免半新半旧窗口。

丢弃现有索引、对全部文档重新切分与向量化。成本为小时到数十小时，期间知识库不可用或半新半旧，是 RAG 更新管线的反模式：成本太高导致更新频率上不去，知识库必然过期。只在两种场景使用：embedding 模型升级（维度/版本变化必须全量重算）、切分策略重大调整。执行时采用双索引切换——新库完整构建完成后再切流量，消除半新半旧窗口；放在低峰窗口执行。

同一文档重复 ingest 结果不变，是 RAG 索引管线的底线要求。实现方式：chunk 级 content_hash（内容哈希）去重，upsert 而非 insert。不幂等的管线一次重试就制造一批重复 chunk——同一内容多个向量互相稀释相似度分数，召回质量不可预测，重复 chunk 是检索质量的第一杀手。排查手段：定期对同 source_id 下的高相似 chunk 对做去重扫描。

源文档已废止/替换，但向量仍残留在索引库中、可被检索命中的 chunk。危害比“内容过期”更隐蔽：新旧版本并存且互相矛盾时，检索命中哪版全凭运气，表现为“答案时灵时不灵”、投诉随机发生。检测方法：对同主题高相似 chunk 做两两矛盾检测，检出的矛盾对即删除清单。根治方法：文档带 status 字段 + 显式废止工作流（标记 → 删向量 → 探针验证删干净 → 审计留痕）。RAG 运维的动词是增、改、删，只做了“增”的团队最易积累僵尸 chunk。

由 50-100 个高频真实问题（来自工单/搜索日志）+ 固定期望答案要点（2-3 个必须命中的事实点）组成的回归集，每周或源变更后自动跑，判定“答案要点是否命中 + 引用文档版本是否最新”，失败进修复队列。本质是评测回归集，回归对象是知识新鲜度而非模型效果。两个维护要点：源文档变更时期望答案同步更新（否则探针先于知识库过期）；结果画周趋势线——新鲜度是渐进劣化的，单点正常不代表没在腐。

对同一主题下 embedding 相似度超过阈值的 chunk 对做 LLM 两两矛盾判定，产出“高相似但内容冲突”的清单。专抓僵尸 chunk：新旧政策并存时，矛盾对就是现成的删除清单。节奏：每周全量 + 变更后增量；检出的矛盾对应在 48h 内清零（删除、标记或确认保留其一）。与 Freshness SLA（看管线）、时效探针（验结果）分工互补：矛盾检测查的是存量。只挂一个检测手段必漏，三者需同时在线。

RAG 入库层第一段：从 PDF/Word/扫描件提取文字与结构（标题层级/表格/列表）。工具按文档类型分工而非“选最准的”——数字文档（有文本层）用 Unstructured/Docling，扫描件需 OCR+版面分析（MinerU/Docling），表格密集文档优先表格结构保留能力强的工具。选型标准是拿自己的文档抽 20 份实测三个数（解析完整率/结构保留率/解析失败率），不信通用 benchmark；不要自研解析器，自研的正确位置是建在工具输出之上的规则补丁层（编号识别/页眉页脚清除）。

扫描件解析的质量闸：OCR 输出带逐块置信度分数，低于阈值（通常 0.85）的块标记“需人工复核”而不硬入库。低质量 OCR 块进库后的症状是“AI 偶尔把参数答错一位/答出乱码”，且用户无法判断是模型错还是入库错，投诉全归模型。扫描件占比 >30% 的知识库，置信度门槛+人工复核队列是标配而非锦上添花——一个 7% 的低质量块占比会在用户端放大成“这个 AI 不靠谱”的整体印象。

解析器在提取文字之前先识别页面的视觉结构（正文区/标题/表格/图注/页眉页脚），再按结构组织输出。是扫描件与表格密集文档解析的核心能力：没有版面分析，表格被拆成“一个单元格一块”、页码混入正文、跨栏文字顺序错乱。工具层面 MinerU/Docling 的表格重建质量代表当前水平；纯文字识别层（如 PaddleOCR）不做版面分析，需下游自己处理结构。

解析阶段保持表格的行列关系（表头与数据行的对应、合并单元格、表标题），输出 Markdown 表格或等价结构化表示，而不是拆成一堆散文本。企业知识库里表格占检索故障的 40-60%：无列名的单元格被单独检索回来，模型无法推断“这一列是单价”。配套切分规则：小表（<15 行）整表一块带表头上下文，大表按行切但每行 chunk 必须携带表头，表格 chunk 元数据带表名+章节+页码。

清洗层第一道：移除页眉页脚（页码/文档编号/密级标记）、重复模板声明、书签目录等“原文档里是结构、入库后是纯噪声”的内容。规则要求：对高频出现（>10% 页）且不含业务信息的短行做正则清除；清除规则写进代码并留样本，不能靠“感觉删干净了”（不可复现=不可验收）；只删不改——内容级改写不属于清洗层。

肉眼不可见但存在于文本中的 Unicode 字符（零宽空格 U+200B 等），在 OCR 输出里极常见。危害：让“同一段文字”因不可见字符不同而分裂成多个近似重复 chunk，向量化后成为检索质量的隐形杀手——表现为“同一内容反复被检索到两次”、召回质量不稳定。清洗层必须统一清除；排查手段是对高相似 chunk 对做字符级 diff，不可见字符差异是最常见来源之一。

判断一个 chunk 是否合格的根本标准：单独拿出来能读懂，且能直接作为答案片段引用，不依赖上一块的上下文。切分单元由此确定——按文档类型的“最小自足语义单元”（制度=标题层级/合同=条款号/手册=任务/FAQ=一问一答），而非固定字数。自足性失败的直接症状是“答案缺半句”（条款 4.2.1 被切成两块，检索命中前半句“甲方应在”）。自足性在生成层测不出来——模型拿到半截会尽力补全，回答通顺但引用是错的，只有查 chunk 本身（编号完整性抽检）才能发现。

合同/制度库的双通道检索：用户问“违约金条款”走向量语义召回，问“4.2.1 条”走编号精确匹配，两者在检索层合并。前提是入库时给每个条款 chunk 挂 `number` 元数据字段——没有该字段，编号类问题只能靠 embedding 猜，而 embedding 对编号/型号等标识符的区分度极差。number 字段还有第二个用途：矛盾检测的版本比对键（新旧合同同一条款号，diff 即出修改点）。验收时编号完整性抽检（随机 20 个条款查单块自足）专测这一链路的输入质量。