LangChain、MCP与Agent架构：AI大模型核心评测

Ja va / Android 类比：

数据准备错误 ≈ 数据源脏数据 / 接口返回错数据检索召回错误 ≈ 查询条件不准 / SQL 查错表重排序错误 ≈ 排序逻辑错误 / 优先级计算不对生成幻觉 ≈ UI 展示层把错误数据加工成了看似合理的结果引用溯源 ≈ 日志 Trace / 数据链路追踪RAGAS 评估 ≈ 自动化测试 + 线上监控

一句话总结：

RAG 幻觉的本质，是模型没有拿到、没有看准、没有用对可靠证据；解决方案就是沿着“数据准备—检索召回—重排序压缩—生成约束—评估回流”这条链路逐层治理。

九、100+ 个工具 API，如何避免全部塞进 Prompt？

当系统中有 100 多个工具 API 时，不能把所有工具描述都塞进 Prompt。因为每个工具都要有工具名、描述、参数说明、参数类型、调用示例和权限说明。100 个工具放进去，会占用大量 Token，挤压用户问题、历史对话、RAG 检索结果、业务上下文和工具返回结果。

更严重的是，工具越多，模型越容易选错。比如用户问：

帮我查一下现在的金价，并计算买 10 克要多少钱。

真正需要的工具可能只有：

get_gold_pricecalculator

但如果 Prompt 里同时放了 weather、stock、crypto、order_query、refund_order、send_email、create_ticket 等大量无关工具，模型判断成本就会更高，误选概率也会上升。

所以核心方案不是 All-in-Prompt，而是 Tool RAG，也可以叫 Retrieval-based Tool Selection。

它的流程是：

Step 0：离线预处理↓Step 1：用户提问↓Step 2：语义检索 Top-K 工具↓Step 3：动态构建 Prompt↓Step 4：LLM 推理并生成 Function Call↓Step 5：执行工具并返回结果

离线阶段，把每个工具结构化描述：

{"name": "get_gold_price","description": "查询当前黄金实时价格，适用于金价、黄金价格、买入黄金金额计算等问题","parameters": {"type": "object","properties": {"unit": {"type": "string","enum": ["gram", "ounce"]}},"required": ["unit"]}}

然后把工具描述文本化，做 Embedding，存入向量数据库：

100+ 工具定义↓工具描述文本化↓Embedding 向量化↓存入 Vector DB

在线阶段，用户提问后，先把 Query 向量化，再和工具库向量做相似度计算，召回 Top-K 工具。例如可能召回：

Top 1：get_gold_priceTop 2：calculatorTop 3：currency_converterTop 4：stock_priceTop 5：commodity_price

然后只把 Top-K 工具定义注入 Prompt：

System Prompt+用户问题+Top 5 工具定义

而不是把 100 个工具全部塞进去。

这套方案解决三个痛点：上下文窗口限制、Token 成本浪费、模型注意力分散。它就像不是每次都把整个 SDK 文档发给模型，而是只把当前要用的 API 文档发给模型。

还可以继续增强：

第一，加工具分类路由。先判断用户问题属于金融、天气、订单、邮件、数据库等哪个类别，再只在对应类别中检索工具。

第二，加工具 Rerank。向量检索可能召回语义相似但不准确的工具，可以先召回 Top-20，再用 Reranker 排序，保留 Top-5。

第三，加权限过滤。不是所有工具都应该对所有用户可见。普通用户不能调用退款工具，客服不能调用财务转账工具，游客不能调用内部数据库工具。工具检索前后都要结合用户身份做权限过滤。

第四，加工具调用校验。即使模型选了正确工具，也要做参数 Schema 校验、必填字段检查、枚举值检查、权限检查、高风险操作人工确认、调用频率限制和失败重试。

它和普通 RAG 的关系很直接：

普通 RAG：用户问题 → 检索相关文档 → 把文档给模型Tool RAG：用户问题 → 检索相关工具 → 把工具定义给模型

所以可以记一句：文档太多时，我们用 RAG 检索文档；工具太多时，也可以用 RAG 检索工具。

当系统中有 100 多个工具 API 时，我不会把所有工具定义都直接塞进 Prompt。这样会导致上下文窗口被占满、Token 成本过高，而且大量无关工具会分散模型注意力，增加误调用概率。更合理的方案是 Tool RAG，也就是基于语义检索的动态工具加载。离线阶段先把每个工具的名称、描述、参数 Schema、适用场景和调用示例整理成文档，然后做 Embedding 存入向量数据库。在线阶段，当用户提问后，对 Query 做向量化，在工具库中检索最相关的 Top-K 工具，只把这些候选工具注入 Prompt，让模型在一个更小、更干净的工具集合中做 Function Calling。工程上还要配合权限过滤、工具分类路由、Rerank、参数 Schema 校验和高风险操作人工确认。

Ja va / Android 类比：

100+ 工具库 ≈ 一个很大的 SDKTool Embedding ≈ 为 API 建索引Vector DB ≈ API 检索目录Top-K 工具 ≈ 当前场景需要 import 的类动态 Prompt ≈ 当前调用上下文Function Calling ≈ 真实方法调用

一句话总结：

当工具 API 很多时，不要把所有工具 All-in-Prompt，而要把工具定义向量化成 Tool Index，运行时根据用户 Query 检索 Top-K 工具，再动态注入 Prompt，让模型在受控、低噪声、低成本的候选工具集中完成 Function Calling。

十、线性注意力为什么没有直接替代标准 Attention？

这个问题容易被问深。线性注意力理论上可以把复杂度从 O(N²) 降到 O(N)，那为什么工业界没有直接全面采用？

关键在于：理论复杂度更低，不等于真实工程里更快、更稳、更强。工业界看的是端到端效果，包括速度、显存、硬件利用率、训练稳定性、长上下文质量和模型表达能力。

标准 Attention 的核心是：

Q 和 K 做两两相似度计算再用 Softmax 得到注意力权重最后加权求和 V

公式是：

Attention(Q, K, V) = Softmax(QKᵀ / √d) V

如果序列长度是 N，每个 Token 都要看其他 N 个 Token，所以复杂度是 O(N²)。

线性 Attention 想避免显式计算完整的 N × N 注意力矩阵。它尝试利用矩阵乘法结合律，把：(QKᵀ)V 变成类似 Q(KᵀV)，这样不用保存完整 N × N 矩阵，而是维护一个压缩状态。理论上序列越长，优势越明显。

但问题在于，数学上能降复杂度，不代表工程上一定好用。

第一个原因是 Causal Mask 会破坏并行性。自回归模型从左到右生成，第 t 个 Token 只能看 1 到 t-1 的历史 Token，不能看未来 Token。标准 Attention 虽然是 O(N²)，但它可以一次性用大矩阵计算完成，GPU 非常擅长这种并行矩阵乘法。很多线性注意力加入 Causal Mask 后，会变成类似 state_1 → state_2 → state_3 → ... → state_N 的前缀状态递推，更像 RNN，理论复杂度降了，但 GPU 并行度也下降了。所以 O(N) 不一定比 O(N²) 快，因为 O(N²) 可能更适合 GPU 并行。

第二个原因是工程瓶颈不只是计算量，还有显存带宽。很多人以为 Attention 慢是因为算得多，但真实工程里，显存读写也非常重要。标准 Attention 经过 FlashAttention 优化后，可以减少中间矩阵落显存，做分块计算，提高 GPU 利用率，降低 HBM 访问压力。于是会出现一个反直觉现象：工程优化后的 O(N²)，在常见上下文长度下，可能比没有充分优化的 O(N) 更快。Big-O 只描述增长趋势，不包含常数项、并行度、缓存命中、显存带宽和硬件 kernel 优化。

第三个原因是线性注意力会损失表达能力。标准 Attention 的最大优势是每个 Token 都能精确关注任意历史 Token。比如长文档中第 2000 个 Token 提到“合同金额是 352 万”，后面第 8000 个 Token 需要引用这个信息，标准 Attention 可以直接把注意力打到那个位置。但线性 Attention 通常把历史信息压缩到固定大小状态里，压缩就会有损失，细粒度信息、低频关键信息容易被淹没，导致长上下文精确检索能力下降、事实回忆变差、复杂推理不稳定。

所以工业界并不是简单放弃线性注意力，而是演进出了多种折中方案。

第一类是继续优化标准 Attention，比如 FlashAttention、PagedAttention、KV Cache 优化、分块计算、稀疏 Attention、滑动窗口 Attention、Grouped Query Attention、Multi-Query Attention。这类方法尽量不牺牲表达能力，而是从底层 kernel、显存管理和缓存机制上优化。

第二类是分块计算。块内使用标准 Attention，保证局部精确建模和 GPU 并行；块间使用线性状态或压缩表示，降低长距离传播成本。也就是块内 O(N²)，块间 O(N)。

第三类是数据依赖门控。不是所有历史信息都一样重要，模型应该学会该记的记、该忘的忘。比如无意义寒暄可以遗忘，关键实体、数字、结论要强化保留。这类思路在 Mamba / Selective State Space Model 中比较典型。

第四类是混合架构。底层或大部分层使用线性注意力或状态空间模型，高效处理长序列；中间层使用局部 Attention；关键层保留标准 Attention，保证精确检索和回溯能力；外部再结合 RAG、KV Cache、Memory 等机制。

线性注意力理论上能把复杂度从 O(N²) 降到 O(N)，但工业界没有直接全面采用，核心原因是 Big-O 不等于真实性能。第一，标准 Attention 虽然是 O(N²)，但它是大矩阵乘法，非常适合 GPU 并行；很多线性注意力在加入 Causal Mask 后会变成前缀状态递推，反而降低并行度。第二，Attention 的工程瓶颈不只是计算复杂度，还有显存带宽和中间矩阵读写。FlashAttention 这类优化显著降低显存访问，使标准 Attention 在常见上下文长度下仍然非常有竞争力。第三，线性注意力通常需要把历史上下文压缩成固定大小状态，会损失精确检索和长程依赖能力。标准 Attention 可以精确访问任意历史 Token，而线性注意力在长文本事实检索、低频信息保留和复杂推理上容易退化。所以现在更主流的是混合路线，比如块内标准 Attention，块间线性状态传递，或者引入门控状态空间模型，再结合 FlashAttention、KV Cache、PagedAttention 等工程优化。

Ja va / Android 类比：

算法 A：理论 O(N)，但大量随机访问、缓存不友好、无法并行算法 B：理论 O(N²)，但可以批量矩阵计算、SIMD/GPU 友好、缓存命中高

真实系统里，B 不一定比 A 慢。

Android 中也类似：

一个看似复杂度更低的方案，如果导致频繁 Binder 调用、随机 I