AI 前沿趋势与新范式

AI 技术 ⭐⭐⭐ 高级 🔥🔥🔥 高频

💡 核心要点

AI 工程已从"单模型调用"全面转向"多组件协作系统"。Compound AI Systems（复合 AI 系统） 已成为标准架构模式，Model Routing 在主流平台已普遍可用，RAG 持续演进（GraphRAG / Long Context / Agentic RAG），Reasoning Models（推理模型） 开创了"慢思考"新范式，Agentic AI 从概念走向生产工具，A2A 协议 推动 Agent 间通信标准化，开源/开放权重模型 大幅缩小与闭源的差距。理解这些趋势是 2025-2026 年 AI 面试的核心竞争力。

---

全局视角：从单模型到复合系统

2022-2023: 单模型调用时代
  用户 → Prompt → LLM → 回答

2023-2024: RAG + Tool Use 时代
  用户 → 检索 → Prompt 组装 → LLM → 回答

2025-2026: Compound AI Systems 时代（已成为主流）
  用户 → AI Gateway（路由/缓存/限流）
    → 意图分类器（小模型/SLM）
    → 路由到合适的处理管线
      ├── 简单问题 → 小模型直接回答（Phi-4, Gemma 2）
      ├── 知识问题 → RAG/GraphRAG → 大模型
      ├── 复杂推理 → Reasoning Model（o3, Claude 深度思考）
      ├── 复杂任务 → Agent（多步规划 + 工具调用 + A2A 协作）
      └── 安全检查 → Guardrails → 输出
    → 评估管线（质量监控 + 回归检测）

核心转变：AI 产品的竞争力不再取决于"用了哪个模型"，而取决于系统设计——如何组合多个组件、路由、缓存和评估来构建可靠的产品。

---

Compound AI Systems（复合 AI 系统）

核心理念

来自 BAIR（Berkeley AI Research）2024 年的核心论断，现已被业界广泛验证：多组件系统在可靠性、成本和质量上一致性地优于单一模型调用。到 2025 年，复合系统已成为 AI 工程的标准架构模式。

单一模型调用:
  Input → LLM → Output
  问题: 可靠性不够、成本高、无法验证

复合 AI 系统:
  Input → Retriever → LLM → Verifier → Output
         ↑                    ↓
       Knowledge DB      如果验证失败 → 重试/降级
  优势: 每个组件可独立优化和替换

复合系统的典型组件

组件	职责	示例
Router	按意图/复杂度分发请求	简单问题用小模型，复杂问题用大模型
Retriever	从知识库获取相关上下文	向量检索 + BM25 混合
Generator	基于上下文生成回答	LLM 调用
Verifier	验证输出的正确性	LLM-as-Judge / 规则检查
Guardrails	安全过滤	输入/输出安全分类器
Cache	缓存相似请求的结果	语义缓存（Embedding 相似度）
Fallback	降级策略	大模型失败时回退到小模型或模板

DSPy：自动优化复合管线

DSPy 是斯坦福提出的框架，用编程方式定义 LLM 管线，然后自动优化 Prompt 和参数：

import dspy

# 定义 Signature（输入-输出规范）
class AnswerQuestion(dspy.Signature):
    """Answer a question based on retrieved context."""
    context = dspy.InputField(desc="relevant passages")
    question = dspy.InputField()
    answer = dspy.OutputField(desc="concise answer")

# 定义 Module（管线组件）
class RAGModule(dspy.Module):
    def __init__(self, num_passages=3):
        super().__init__()
        self.retrieve = dspy.Retrieve(k=num_passages)
        self.generate = dspy.ChainOfThought(AnswerQuestion)

    def forward(self, question):
        context = self.retrieve(question).passages
        answer = self.generate(context=context,
                               question=question)
        return answer

# 编译优化（自动调 Prompt + Few-shot）
from dspy.teleprompt import BootstrapFewShot

optimizer = BootstrapFewShot(metric=answer_accuracy)
optimized_rag = optimizer.compile(
    RAGModule(),
    trainset=train_examples
)

DSPy 的核心价值：不再手写 Prompt，而是定义输入输出规范，让框架根据评估指标自动优化。

---

Model Routing（模型路由）

为什么需要路由

请求类型	最佳模型	原因
"你好"	小模型 (Haiku)	简单寒暄，大模型浪费
"解释量子纠缠"	中等模型 (Sonnet)	知识问答，中等复杂度
"设计一个分布式锁"	大模型 (Opus)	复杂推理，需要深度思考

不路由的代价：全部用大模型 → 成本高 10~50 倍，延迟高 3~5 倍。全部用小模型 → 复杂问题质量差。

路由策略

用户请求
  ↓
┌─────────────────────────────────┐
│       Model Router               │
│                                  │
│  策略一: 基于规则                  │
│    Token 数 < 50 → 小模型         │
│    包含"代码"/"设计" → 大模型      │
│                                  │
│  策略二: 基于分类器                │
│    小模型先判断复杂度（1-5 分）     │
│    1-2 → 小模型                  │
│    3-4 → 中等模型                 │
│    5 → 大模型                    │
│                                  │
│  策略三: 级联（Cascade）          │
│    先用小模型回答                  │
│    自动评估置信度                  │
│    置信度低 → 大模型重新回答        │
└─────────────────────────────────┘

级联路由实现

class CascadeRouter:
    """级联路由：先小后大，按质量需要升级。"""

    def __init__(self, models: list[dict]):
        # models 按成本从低到高排序
        self.models = models  # [haiku, sonnet, opus]

    def route(self, query: str,
              quality_threshold: float = 0.8) -> str:
        for model in self.models:
            response = model["client"].generate(query)
            confidence = self.assess_confidence(
                query, response
            )

            if confidence >= quality_threshold:
                return response

            # 如果是最后一个模型，无论如何都返回
            if model == self.models[-1]:
                return response

        return response

    def assess_confidence(self, query: str,
                          response: str) -> float:
        """用轻量级检查评估回答质量。"""
        checks = [
            self.check_length(response),      # 太短可能不完整
            self.check_hedging(response),      # "我不确定"等表达
            self.check_relevance(query, response),  # 是否切题
        ]
        return sum(checks) / len(checks)

AI Gateway

AI Gateway 是模型路由的工程化实现，类似 API Gateway 但专为 LLM 设计：

功能	说明	产品
路由	按规则/成本/质量分发到不同模型	OpenRouter, Martian, Unify
负载均衡	多个模型实例间分发请求	AWS Bedrock, Azure AI
缓存	语义缓存减少重复调用	GPTCache, Prompt Caching（Anthropic/OpenAI 已原生支持）
限流	Token/请求级别的限流	自研
可观测性	请求日志、延迟、成本追踪	LangSmith, Helicone
Fallback	主模型不可用时自动切换	LiteLLM

---

RAG 的演进：不是过时了，而是在进化

RAG vs Long Context vs Fine-tuning：何时用什么

这是 2025 年面试最高频的选型题之一：

维度	RAG	Long Context	Fine-tuning
知识更新	实时（更新知识库即可）	实时（放进上下文即可）	需要重新训练
知识量	无限（向量数据库）	受限于上下文窗口（1M tokens）	固化在权重中
准确性	高（可追溯来源）	中（"大海捞针"效应）	取决于训练数据质量
成本	中（检索 + 生成）	高（长上下文 Token 费用）	高（训练成本）+ 低（推理）
延迟	中（检索耗时）	高（长上下文推理慢）	低（无检索开销）
幻觉控制	好（有来源引用）	一般（可能忽略关键信息）	差（无法引用来源）
适用场景	知识库问答、客服、搜索	长文档分析、会议纪要	改变模型行为/风格

面试答法：RAG 不是过时了，而是从"万能方案"变成了"知识密集型场景的最佳选择"。长上下文窗口（100K~1M tokens）让"把所有内容塞进 Prompt"成为可能，但存在"大海捞针"问题——模型可能忽略中间的关键信息。最佳实践是混合使用：RAG 检索最相关的内容，放入合理长度的上下文中。

GraphRAG

GraphRAG 是 Microsoft 提出的 RAG 演进方案，核心思想是用知识图谱增强检索：

传统 RAG:
  Query → Embedding → 向量检索（相似度匹配） → Top-K 文档 → LLM

GraphRAG:
  索引阶段:
    文档 → LLM 提取实体和关系 → 构建知识图谱
    知识图谱 → 社区检测算法 → 生成社区摘要

  检索阶段:
    Query → 两种检索模式:
      Local Search: 从相关实体出发，沿图谱边遍历，获取局部子图
      Global Search: 搜索社区摘要，获取全局概览

GraphRAG vs 传统 RAG 对比：

维度	传统 RAG	GraphRAG
检索方式	向量相似度	图谱遍历 + 社区摘要
多跳推理	弱（只能检索直接相关文档）	强（沿关系链推理）
全局问题	弱（"总结所有..."类问题）	强（社区摘要提供全局视角）
索引成本	低	高（需要 LLM 提取实体关系）
适用场景	事实性问答	分析性问答、多跳推理

Agentic RAG

Agentic RAG 是将 RAG 嵌入 Agent 循环中，让检索成为 Agent 的一个工具而非固定流程：

传统 RAG（固定流程）:
  Query → 检索 → 生成 → 结束

Agentic RAG（动态决策）:
  Query → Agent 思考: "我需要什么信息？"
    → 行动 1: 检索知识库 A
    → 思考: "信息不够，还需要查 B"
    → 行动 2: 检索知识库 B
    → 思考: "需要验证数据 C"
    → 行动 3: 调用 API 获取实时数据
    → 思考: "现在信息充分了"
    → 生成最终回答

优势：Agent 可以动态决定搜索什么、搜索几次、是否需要其他工具补充信息，而不是机械地"检索 → 生成"。

---

AI 可观测性（Observability）

为什么 LLM 应用需要专门的可观测性

传统应用监控关注延迟、错误率、吞吐量。LLM 应用还需要关注：

维度	传统应用	LLM 应用
正确性	有明确的对错	输出质量是概率性的
成本	资源消耗可预测	Token 消耗波动大
调试	看日志和堆栈	需要看完整的 Prompt 和 Response
回归	代码变更触发	Prompt 变更、模型更新都可能回归

AI 可观测性的核心能力

┌─────────────────────────────────────────┐
│          AI 可观测性平台                  │
├─────────────────────────────────────────┤
│  Tracing（追踪）                         │
│  ├── 请求级: 用户输入 → 最终输出          │
│  ├── Span 级: 检索耗时、LLM 耗时、后处理  │
│  └── Token 级: 输入/输出 Token 数、成本    │
├─────────────────────────────────────────┤
│  Evaluation（评估）                      │
│  ├── 在线评估: 实时 LLM-as-Judge 评分    │
│  ├── 离线评估: 批量回归测试              │
│  └── 用户反馈: 点赞/点踩/投诉            │
├─────────────────────────────────────────┤
│  Analytics（分析）                       │
│  ├── 成本分析: 按模型/功能/用户的花费     │
│  ├── 质量分析: 按类别的成功率趋势         │
│  └── 使用分析: 热门问题类型、高频失败模式  │
├─────────────────────────────────────────┤
│  Alerting（告警）                        │
│  ├── 质量下降告警（评估分数低于阈值）      │
│  ├── 成本异常告警（Token 消耗突增）        │
│  └── 安全告警（Guardrails 拦截率异常）     │
└─────────────────────────────────────────┘

工具生态

工具	核心能力	适用场景
LangSmith	LangChain 原生追踪、评估、数据集管理	LangChain 生态项目
Arize Phoenix	开源，Trace 可视化、Embedding 漂移检测	需要开源方案
Helicone	轻量级 API 代理，成本追踪、缓存	快速接入、成本优先
Weights & Biases Weave	实验追踪 + LLM 评估	ML 团队，已用 W&B
Braintrust	评估 + Prompt 管理 + 数据集	评估驱动开发

---

2025-2026 新兴趋势

Reasoning Models（推理模型）——"慢思考"范式

2024 年底至 2025 年，推理模型成为最重要的新范式。与传统 LLM 的"快速回答"不同，推理模型通过**扩展推理时间（test-time compute）**来提升复杂任务的准确率：

模型	厂商	特点
o1 / o3 / o4-mini	OpenAI	开创推理模型品类，o3 在数学/编程上接近人类专家
Claude（Extended Thinking）	Anthropic	Claude 支持扩展思考模式，推理与创作兼顾
Gemini 2.5（Thinking）	Google	内置思考模式，原生多模态推理
DeepSeek-R1	DeepSeek	开源推理模型，性能接近 o1，推动开源社区跟进

面试要点：推理模型不是简单的"更大模型"，而是用更多推理时间换取更高准确率。在 Model Routing 中，推理模型适合数学证明、复杂代码生成、多步逻辑推理等场景，但延迟和成本较高，简单任务不需要使用。

DeepSeek-V3 / R1 深度解析

DeepSeek 在 2024-2025 年成为最常被面试官追问的模型——不只是因为性能强，更因为它把"中等团队也能训前沿模型"变成了现实。能讲出它的关键创新点，是面试加分项。

V3 的工程创新

技术	解决的问题	价值
MoE 671B / 37B 激活	推理时算力像 37B 模型，能力像数百 B 模型	推理成本大幅低于同档稠密模型
无辅助损失负载均衡	传统 MoE 用辅助损失会损害模型能力	用偏置项动态调整专家选择，性能不让步
FP8 原生混合精度训练	FP16/BF16 训练成本太高	训练显存减半，速度翻倍
MLA（Multi-head Latent Attention）	KV Cache 显存随序列线性增长	把 KV 压缩到低维隐变量，KV Cache 减少 93%
MTP（Multi-Token Prediction）	自回归一次只出一个 token	训练时同时预测 N 个未来 token，推理可配合推测解码加速
DualPipe + 计算-通信重叠	大集群训练 GPU 经常等通信	流水线并行打满 GPU

R1 的训练突破

R1 不是简单的"V3 + RLHF"，而是首次公开证明"纯 RL 也能逼出推理能力"：

R1-Zero（探索版）:
  V3 Base 模型 → 直接用 GRPO 强化学习（无 SFT）
  → 模型自发涌现长思维链、自我反思、回溯能力
  → 缺点: 语言混合、可读性差

R1（正式版）:
  Stage 1: 冷启动 SFT（少量高质量推理数据）
  Stage 2: 推理任务 RL（GRPO + 规则奖励）
  Stage 3: 拒绝采样 + 通用 SFT
  Stage 4: 全场景 RL（推理 + 偏好对齐）
  → 接近 o1 性能，开源可商用

GRPO 算法关键点

GRPO（Group Relative Policy Optimization）是 R1 的核心 RL 算法，相比 PPO 的简化：

维度	PPO（传统 RLHF）	GRPO（R1）
是否需要 Critic 模型	需要（与 Policy 同等大小）	不需要（节省一半显存）
优势函数估计	GAE，需 Critic 输出价值	同 prompt 采样多个回答，用组内归一化作为优势
适合什么奖励	任意奖励	特别适合规则可验证的奖励（数学正确性、代码通过测试）
训练稳定性	中	高（移除 Critic 这个不稳定因素）

行业冲击与启示

维度	在 DeepSeek 之前	在 DeepSeek 之后
前沿模型门槛	必须百亿美元算力	数百-千万级美元也能做出来
开源 vs 闭源差距	至少落后 1 年	几乎追平
推理模型范式	"需要 o1 那样的秘密配方"	"纯 RL + 可验证奖励 = 推理能力"
MoE 工程化	学术意义大、落地难	生产首选架构之一

面试黄金回答模板

当面试官问 "你怎么看 DeepSeek？" 时：

"DeepSeek 的价值不是参数量大，而是把三件事一起做对：架构上用 MoE + MLA 把单 token 推理成本压到极致；训练上用 FP8 + DualPipe 把训练成本压到行业 1/10；后训练上用 GRPO 证明纯 RL 就能涌现推理能力。这三点合在一起，让开源社区第一次有了对标 o1 级闭源模型的能力。

对工程师的启示是：未来生产架构选型时，MoE 推理优化（FP8 量化 + 专家并行）、KV Cache 压缩（MLA 风格）、和基于规则奖励的轻量 RL 微调，这三件事会成为必备技能。"

---

Agentic AI 的成熟

AI Agent 从 2024 年的概念验证阶段，到 2025 年已进入生产工具阶段：

产品/框架	类型	状态（2025-2026）
Claude Code	编程 Agent	已成为开发者日常工具
OpenAI Agents SDK	Agent 开发框架	2025 年发布，统一 Agent 构建范式
GitHub Copilot Workspace	编程 Agent	从需求到 PR 的端到端 Agent
LangGraph	Agent 编排框架	已成熟，支持复杂状态管理和多 Agent 编排
CrewAI	多 Agent 框架	生态完善，企业级多 Agent 协作

关键变化：Agent 不再是"Demo 好看，生产不行"。通过更好的工具调用、结构化输出和错误恢复机制，编程 Agent 已成为实际提升开发效率的生产工具。

A2A 协议（Agent-to-Agent）

Google 于 2025 年 4 月发布 A2A 协议，定义了 Agent 间通信的开放标准：

MCP（Model Context Protocol）: 模型 ↔ 工具/数据源
  解决: Agent 如何调用外部工具

A2A（Agent-to-Agent Protocol）: Agent ↔ Agent
  解决: 不同 Agent 之间如何发现、通信、协作

两者互补，共同构成 Agentic AI 的基础设施层。

面试要点：MCP 解决的是"Agent 怎么用工具"，A2A 解决的是"Agent 怎么找到并协作其他 Agent"。类比微服务架构：MCP 是数据库驱动，A2A 是服务间 RPC。

小型高效模型（SLM）与端侧 AI

2025 年，"更小但更强"成为重要趋势，推动 AI 从云端走向端侧：

模型	参数量	亮点
Phi-3 / Phi-4	3.8B~14B	微软，小参数量下性能惊人
Gemma 2	2B~27B	Google，开源，适合端侧部署
Llama 3.2	1B~3B	Meta，支持移动端推理

面试要点：SLM 在 Model Routing 中扮演关键角色——作为意图分类器、简单请求处理器，大幅降低系统整体成本。端侧部署还解决了隐私和延迟问题。

开放权重模型缩小差距

2025 年，开源/开放权重模型与闭源模型的差距大幅缩小：

• Llama 3（405B）/ Llama 4：Meta 持续推动开放权重，Llama 4 Scout/Maverick 引入 MoE 架构
• DeepSeek V3 / R1：中国团队以极低训练成本达到顶级性能，引发行业震动
• Qwen 2.5 / QwQ：阿里巴巴，在中文场景表现突出，推理能力持续提升

影响：企业 AI 选型不再是"闭源 vs 开源 = 质量 vs 自由"的简单取舍。在许多场景下，开放权重模型已能提供与闭源模型相当的质量，同时拥有更好的数据控制和部署灵活性。

多模态成为默认能力

2025 年，主流模型已将多模态作为默认能力而非附加功能：

• 文本 + 图像 + 视频 + 音频：GPT-4o、Gemini 2.5、Claude 均原生支持多种模态
• 实时语音对话：GPT-4o 的实时语音、Gemini Live 已落地到消费级产品
• 视觉理解 + 代码生成：截图生成代码、UI 理解等从 Demo 进入实用阶段

面试要点：多模态不再是"未来方向"，而是选型时的基本考量维度。

AI 基础设施层的崛起

2025 年最重要但容易被忽视的趋势：AI 基础设施已经形成独立的产业层。理解这一层的分工，是回答"AI 工程师在做什么、AI 公司怎么赚钱"的关键。

┌──────────────────────────────────────────────────┐
│  应用层    Cursor / Devin / Perplexity / 客服    │
├──────────────────────────────────────────────────┤
│  Agent/编排 LangGraph / LlamaIndex / CrewAI      │
├──────────────────────────────────────────────────┤
│  推理服务  Together / Fireworks / Groq / DeepInfra│
│            （第三方推理云，比官方 API 便宜 3-10×）│
├──────────────────────────────────────────────────┤
│  模型权重  OpenAI / Anthropic / Google / Meta /  │
│            DeepSeek / Mistral / Qwen             │
├──────────────────────────────────────────────────┤
│  推理引擎  vLLM / SGLang / TensorRT-LLM / TGI    │
├──────────────────────────────────────────────────┤
│  算力      NVIDIA H100/H200/B200 / AMD MI300X /  │
│            Google TPU / AWS Trainium / Groq LPU   │
├──────────────────────────────────────────────────┤
│  数据中心  Hyperscaler（AWS/Azure/GCP）+ 新进者  │
│            CoreWeave、Lambda、Crusoe              │
└──────────────────────────────────────────────────┘

GPU 算力分层

层级	代表硬件	单卡显存	主要用途	2025-2026 价位（参考）
训练 / 大型推理	H100 / H200 / B200	80-192 GB HBM	训练 + MoE 推理	数万美元/月（云租）
生产推理主力	H100 / A100	80 GB	70B 级推理服务	中等成本
中小推理	L40S / L4 / A10	24-48 GB	7-13B 模型、边缘推理	低成本
专用加速	Groq LPU / Cerebras / SambaNova	—	极致低延迟推理（数百-数千 tok/s）	按请求计费
苹果端侧	M4 / M5（统一内存）	16-192 GB	本地 7-70B 推理	一次性购买

推理云 vs 官方 API

2024-2025 年崛起的第三方推理云（Together、Fireworks、DeepInfra、Replicate、Groq）成为开源模型的主要分发渠道：

维度	官方 API（OpenAI/Anthropic）	第三方推理云	自建部署
可用模型	仅自家闭源模型	主流开源 + 少数闭源	任意
单价	高	同模型比官方便宜 3-10×	高 QPS 时最低
延迟	稳定	视厂商，Groq 极低	自己控制
数据合规	受厂商政策约束	同上	完全可控
冷启动	无	无	慢（需预热）
最适合	闭源最强模型	开源模型主流选择	高 QPS + 隐私

面试加分点：能说出"为什么 Cursor 用 Claude 但 Devin 自托管"——同一道问题的答案，本质就是 Latency、单 token 成本、合规、可控性这四个维度的不同取舍。

训练算力 vs 推理算力

2025 年的关键转折：全球 AI 算力支出中，推理已经超过训练。

维度	训练算力	推理算力
集中度	极高（少数前沿实验室）	分散（每个 AI 应用都需要）
硬件偏好	大集群、HBM 大、NVLink 互联	单机或小集群、TCO 优先
2024 年占比	~70%	~30%
2025-2026 预期	~40%	~60%（持续上升）
核心瓶颈	集群互联带宽	显存带宽、能耗

含义：对工程师而言，推理基础设施工程师（vLLM/SGLang 优化、K8s GPU 调度、成本治理）的需求正在快速超过训练工程师。

---

面试常问 & 怎么答

Q1: RAG 还有必要用吗？什么时候用 Long Context 替代 RAG？

RAG 没有过时，但适用范围更精确了。Long Context 适合：文档量可以放进上下文窗口、需要全文理解而非片段检索的场景（如长文档分析、会议纪要）。RAG 仍然更好：知识库大且持续更新、需要来源引用、需要精确事实回答的场景（如企业知识库、客服系统）。实际中最佳实践是RAG + 适度长上下文：先用 RAG 检索最相关的内容，放进合理长度的上下文中生成回答。

Q2: 什么是 Compound AI Systems？为什么比单一模型调用好？

Compound AI Systems 是将多个 AI 组件（检索器、多个 LLM、验证器、安全过滤器等）组合成一个完整系统的设计理念，自 2024 年由 BAIR 提出后，已成为 2025 年 AI 工程的标准架构。核心优势：①每个组件可以独立优化和替换；②可以用小模型处理简单请求，大模型处理复杂请求（Model Routing），大幅降低成本；③增加验证环节提高可靠性；④支持降级和 Fallback。目前 OpenRouter、AWS Bedrock、Azure AI 等主流平台均已内置路由和级联能力。

Q3: Model Routing 怎么实现？有哪些策略？

三种主要策略：①基于规则：按 Token 数、关键词等简单规则路由（实现简单但不够智能）；②基于分类器：用小模型先判断请求复杂度，再分发到不同大小的模型（准确但增加延迟）；③级联（Cascade）：先用小模型回答，自动评估质量，质量不够再用大模型重新回答（成本最优但总延迟可能更高）。生产中通常混合使用，用 AI Gateway 统一管理路由、缓存、限流和可观测性。

Q4: Evals-Driven Development 是什么？为什么重要？

Evals-Driven Development 是将评估（Evals）作为 AI 产品开发的核心驱动力的工程实践。核心理念：AI 产品失败几乎都因为缺少系统化评估。具体做法：①定义评估标准和 Golden Dataset；②构建自动化评估管线（集成到 CI）；③每次 Prompt 或模型变更都触发评估；④分析失败案例，迭代改进。评估数据还可以形成飞轮效应：失败案例经人工修正后成为微调数据，进一步提升模型质量。

Q5: AI 可观测性和传统应用监控有什么区别？

传统监控关注延迟、错误率、吞吐量，这些指标有明确的对错判断。LLM 应用额外需要：①输出质量监控——LLM 输出质量是概率性的，需要 LLM-as-Judge 或用户反馈来衡量；②Token 成本追踪——按模型、功能、用户维度分析花费；③Prompt 级追踪——调试时需要看完整的输入和输出，而非只看状态码；④回归检测——Prompt 修改或模型更新可能导致质量下降，需要自动化评估管线持续检测。主流工具包括 LangSmith、Arize Phoenix、Helicone 等。

Q6: 什么是 Reasoning Models？和普通 LLM 有什么区别？

Reasoning Models（如 OpenAI o3/o4-mini、Claude Extended Thinking、Gemini 2.5 Thinking）通过扩展推理时间来提升复杂任务的准确率，本质是"用更多计算换更好结果"。与普通 LLM 的区别：①普通 LLM 是"快思考"——一次前向传播生成答案；推理模型是"慢思考"——在回答前进行多步内部推理。②推理模型在数学、编程、逻辑推理等任务上显著优于同级别普通模型。③代价是延迟更高、成本更大。在 Compound AI Systems 中的定位：推理模型应该通过 Model Routing 用于真正需要深度推理的请求，简单请求仍用普通小模型处理。

Q7: A2A 和 MCP 有什么区别和联系？

MCP（Model Context Protocol）解决的是模型与工具/数据源之间的连接——让 Agent 能调用外部 API、读取数据库等。A2A（Agent-to-Agent Protocol）解决的是Agent 之间的发现和通信——让不同 Agent 能互相找到、了解能力、发起协作。两者互补：MCP 是"Agent 怎么用工具"，A2A 是"Agent 怎么和其他 Agent 协作"。类比微服务架构：MCP 相当于数据库连接层，A2A 相当于服务间的 gRPC/REST 通信协议。

---

看到什么就先想到这类

关键词/场景	联想到
"RAG 过时了吗"	RAG vs Long Context vs Fine-tuning 选型分析
"成本太高"	Model Routing + 语义缓存 + 级联策略 + SLM
"系统不稳定/质量波动"	Compound AI Systems + Verifier + Evals Pipeline
"多跳推理/全局问题"	GraphRAG（知识图谱 + 社区摘要）
"复杂推理/数学/代码"	Reasoning Models（o3, Claude Extended Thinking）
"多 Agent 协作"	A2A 协议 + LangGraph / CrewAI
"编程效率"	Agentic AI（Claude Code, Copilot Workspace）
"怎么评估 AI 产品"	Evals-Driven Development + LLM-as-Judge
"怎么监控 LLM 应用"	AI 可观测性（Tracing + 质量评估 + 成本分析）
"模型选型"	不是选一个模型，而是用 Router 按需分发
"端侧/隐私/离线"	SLM（Phi-4, Gemma 2, Llama 3.2）
"开源 vs 闭源"	开放权重模型已缩小差距，按场景选型
"自动优化 Prompt"	DSPy（声明式定义 + 自动编译优化）

---

延伸阅读

• Compound AI Systems (BAIR Blog)
• GraphRAG: Unlocking LLM discovery on narrative private data (Microsoft)
• DSPy: Compiling Declarative Language Model Calls
• FrugalGPT: How to Use Large Language Models While Reducing Cost
• Your AI Product Needs Evals (Hamel Husain)
• LLM Patterns (Eugene Yan)
• A2A Protocol (Google)
• OpenAI Reasoning Models
• Claude Extended Thinking (Anthropic)
• Model Context Protocol (MCP)