这两年 AI 发展的速度，说实话有点吓人。几乎每个月都有新概念冒出来：Chat Completions、Tool Use、RAG、MCP、Agent……如果你是刚准备入门的开发者，打开 OpenAI 或 Anthropic 的官方文档大概会直接被术语淹没。
这篇文章从 OpenAI 和 Anthropic 的官方文档中梳理了最重要的 20 个核心概念，分成了六个板块。从最基础的 API 调用，到工程优化，再到当下最火的 Agent 架构，一条线走下来，希望能帮你快速建立起一个完整的技术地图。
一、基础架构与交互
1. Messages / Chat Completions（消息 / 聊天补全）
大模型不是你想象的那种”输入一句话，补全后半句”的玩法。现代模型的核心交互模式是消息列表——你给它一段结构化的对话历史，它接着往下说。
每次请求里通常有三个角色：
- System——给模型的全局指令，设定它的身份和行为边界
- User——你的输入
- Assistant——模型的回复
这三个角色共同构成了所谓”上下文”，模型基于这个上下文来理解该回答什么。
2. System Prompts / System Instructions（系统提示词）
这是你在对话开始前塞给模型的一纸”最高指示”。
打个比方：System Prompt 就像是给一个新入职员工发的公司规章制度手册，规定了什么能做、什么不能做、语气应该怎样、遇到敏感问题如何处理。OpenAI 和 Anthropic 两家都非常强调它对模型行为的决定性控制作用。写好 System Prompt，往往比调后面的用户消息更关键。
3. Tokens & Context Window（Token 与上下文窗口）
Token 是模型理解文本的最小单位。什么概念呢？大概 1 个 Token 约等于 0.75 个英文单词，中文的话一个汉字通常占 1-2 个 Token。
上下文窗口则是模型单次能处理的 Token 总量——包括你的输入和它的输出。超出这个窗口，模型会直接”失忆”，前面的内容就接不上了。而且 Token 的数量直接决定你每次 API 调用的账单金额，算钱的时候得心里有数。
4. Stop Reasons / Finish Reason（终止原因）
模型为什么停下来了？是话说完了？还是字数到了？或者它想调用工具了？
API 返回的 finish_reason 字段就是告诉你原因的：stop 表示正常结束，length 表示输出超长被截断，tool_calls（Anthropic 是 tool_use）表示模型请求调用外部工具。根据不同的终止原因，你的程序需要做出不同的下一步处理。
二、工具与结构化输出
5. Tool Use / Function Calling（工具调用 / 函数调用）
说白了就是给模型一双手，让它能碰外面的世界。
你给它定义一些工具——比如查天气的 API、算数学的引擎、或者查数据库的接口——模型会根据用户的问题自主决定要不要调用、传什么参数、什么时候调。它输出的是一段结构化的 JSON 调用请求，真正执行这段代码的还是你的后端。
6. Structured Outputs（结构化输出）
AI 的输出天然是自然语言，而传统软件要的是 JSON、是格式化的数据。怎么办？
OpenAI 提供了 Structured Outputs 模式，能保证模型返回的数据 100% 符合你预设的 JSON Schema。Anthropic 则通过工具定义的参数 Schema 做严格约束，达到类似效果。如果你想把 AI 的输出直接喂给下游系统——比如写入数据库、触发某个工作流——这个是必不可少的。
7. MCP（Model Context Protocol，模型上下文协议）
这是 Anthropic 发起并开源的一个开放标准。它的目标是解决一个老问题：每个 AI 应用都要重复对接各种工具，能不能有一套统一的方式？
MCP 的思路很简单：把 AI 应用拆成两个部分——MCP 客户端和 MCP 服务器。你开发好一个 MCP 服务器（比如对接 Slack、GitHub、本地文件系统），任何兼容 MCP 的 AI 工具都可以直接复用，不需要给每个模型单独写一遍适配代码。
三、性能与成本优化
8. Prompt Caching（提示词缓存）
如果你每次请求都带着同样一大段文档——比如几千行的代码库、几百页的产品手册——每次都重新处理这些内容，既慢又贵。
Prompt Caching 的解决方案是：云端自动把重复的部分缓存起来，下次再发同样的内容就直接命中缓存。注意，要被缓存的内容必须放在 prompt 的开头，中间插一段不一样的就会让缓存失效。OpenAI 和 Anthropic 两家都支持，而且计费上区分”缓存命中”和”未命中”。实测下来，成本可以降低 50% 到 90%，延迟也大幅下降。
9. Extended Thinking / Reasoning Effort（扩展思考 / 推理努力度）
还记得 ChatGPT 碰到数学题就瞎编的日子吗？现在有了”推理模型”。
当面对复杂的逻辑推理、数学证明或者代码难题时，模型在最终给出答案之前，会先打开一个内部的”思考通道”，在里面生成一条长长的思维链（Chain of Thought）。OpenAI 的 o 系列模型可以配置 reasoning_effort，Anthropic 也有对应的 Extended Thinking 功能。代价是更长的响应时间，但复杂任务的成功率提升非常明显。
10. Embeddings（嵌入向量）
把一段文字（甚至图片）转换成一串固定长度的数字，这些数字的几何距离就代表了语义的相似度——这就是 Embedding。
这玩意儿是很多 AI 应用的底层基础：语义搜索、文本分类、推荐系统，以及 RAG（检索增强生成，让模型拿着外部知识答复），都需要靠 Embedding 来判断”哪段文字跟用户的问题最相关”。
四、智能体架构
11. AI Agents / Agent Architecture Patterns（智能体与架构模式）
你可能已经发现了，传统的”一问一答”模式在很多场景下远远不够用——比如”帮我订一张下周去北京的机票”，这中间涉及查航班、比价格、看日期、下单支付等多个步骤。
Agent 的思路是：给 AI 设定一个目标，让它自己规划步骤、调用工具、反复迭代，直到完成。目前主流的设计模式有单智能体循环、多智能体协同，以及 OpenAI 深度集成的 Codex 编码智能体。
12. Orchestration / Multi-Agent Systems（编排与多智能体系统）
一个 Agent 搞不定的事，那就上多个。
核心思路是：把复杂任务拆碎，由一个”协调者”分发给多个”专家”智能体，各干各的活，最后再汇总。Anthropic 强调的是”小而专注的微技能组合”——每个 Agent 只做一件事，但做到极致。OpenAI 则推出了 Agents SDK，用代码来控制 Agent 之间的状态移交和协同。
13. State Management & Memory（状态管理与记忆）
Agent 不是一次性对话——它可能跑几小时甚至好几天。在这期间，用户的偏好、当前的进度、已经完成的任务，都不能丢。
这就意味着你必须为 Agent 设计明确的记忆存储和状态机。不然模型会在长时间的交互中迷失目标——它自己都忘了刚才干到哪一步了。
14. Grade-and-Revise Loop / Outcomes（自我验证与修正闭环）
这是一个很有意思的设计模式：Agent A 负责生成内容，Agent B 根据一套严格的标准来打分和审查，不合格就打回去重做，直到达标。
你可以理解成写论文——先写一版初稿，然后找审稿人挑毛病，修改完再审，直到通过。这套机制在需要高质量输出的场景下非常有用。
五、模型定制与评估
15. Fine-Tuning（微调）
基座模型很聪明但它不是为你定制的。如果你想让模型的语气更像你的客服风格，或者让它在你的代码库里用特定的命名规范——那就需要微调。
微调的本质是：用你特定场景的数据集对模型做二次训练。注意，它改变的是模型的行为习惯和长期记忆，而不是给它灌输新的外部知识。
16. Distillation（模型蒸馏）
大模型（比如 GPT-5 级别）聪明但贵、慢。小模型便宜又快但不够聪明。蒸馏就是：用大模型产出的高质量答案和推理路径，去训练一个小模型，让它尽量接近大模型的表现。
结果就是你得到了一个”缩小版”的模型——成本低、速度快，在特定场景下表现接近大模型，非常实用。
17. Evals（评估系统）
AI 的输出是有随机性的——同样的提示词，每次的回答可能都不完全一样。这就意味着传统的单元测试很难覆盖。
Evals 是一套系统化的评估框架，用于测量和监控模型（或 Agent）在各个维度上的表现。OpenAI 和 Anthropic 都强调必须建立自动化的 Evals 基准，不然你调整了提示词或做了微调之后到底变好还是变差了，根本说不清楚。
六、工程实践与安全
18. Realtime API & Low-Latency Streaming（实时 API 与流式低延迟）
传统的 API 调用是你发请求等响应，哪怕用 SSE 流式返回也只是”逐字输出”。Realtime API 不一样——它基于 WebSocket 或 WebRTC，支持双向音频、实时语音交互、中途打断。
你在语音助手里说话说到一半发现不对立刻改口，它能接上——这就是 Realtime API 做的事。
19. Safety Classifiers & Fallbacks（安全分类器与降级熔断）
大模型有时候会因为安全规则、合规政策（比如欧盟 AI 法案）或内容审查而被拦截。这在生产环境里是不能接受的——你不能让用户看到”抱歉，我无法回答这个问题”就直接断掉。
正确的做法是：捕获特定的错误码，在服务端设置自动降级策略。比如主模型被拦截了，自动切换到备用模型继续服务，保证可用性。
20. X-Request-ID & Tracing（请求追踪与可观测性）
大模型的黑盒特性让线上 Debug 变得异常困难——它出错了但你不知道是提示词写崩了，还是上下文太长被截断了，还是模型本身抽风了。
官方推荐的做法是：在全链路日志中记录每次请求的 x-request-id、openai-processing-ms 等元数据。在复杂的 Agent 异步执行场景下，这些追踪标识是你定位问题的最重要线索。
写在最后
20 个概念，从最基础的 Chat Completions 一路聊到生产级的追踪和降级。如果你能把这 20 个点都理清楚，基本上 AI 应用开发的全景图就在你脑子里了。
技术的变迁确实很快，但底层的思维方式是通的——理解”消息”怎么流动、“工具”怎么挂接、“状态”怎么维持，不管模型怎么换代，这些基础都能复用。