第1章 模型是组件——LLM 的角色与选型

小a接了个新任务：给团队的 Agent 选一个模型底座。他打开模型目录，二十多个名字，参数从几亿到几千亿，价格差着上百倍。网上有人说大模型什么都干得了，有人说只适合特定任务，他越看越晕。

他把问题抛给老z：“到底该怎么选？”

“先别急着比参数。”老z说，“**选模型之前，先想清楚模型在你的系统里到底扮演什么角色。**这一章我们不看任何具体产品，而是把 LLM 放回 Agent 的坐标系里，摸清它的脾气。”

本章回答什么

• LLM 在 Agent 里负责什么、不负责什么
• 能力边界从哪里来，为什么不能当“全能引擎”
• 选型要看哪几个约束，评测怎么代替感觉
• 模型为什么应该被当成可替换的组件

不覆盖范围：token、自回归、上下文窗口、采样、幻觉等生成机制，留给第2章 接龙机器的真相——LLM展开；厂商 API 的差异与抽象，在第4章 翻译局如何接通模型——Provider。

先把名字对齐

中文术语	英文全称或缩写	本书工作定义	不等于什么
模型服务	model service／LLM API	通过接口提供模型推理能力的产品；一次调用返回文本或事件流	一次调用会改变模型参数
推理调用	inference call	应用向模型服务发起的一次请求；计费、延迟和失败都按调用计	模型训练或微调
能力边界	capability boundary	模型在训练数据与推理资源约束下可稳定完成的任务范围	厂商宣传的全部可能性
选型	model selection	按任务、成本、延迟与可用性约束挑选模型的过程	按参数数量或榜单排名选
评测	evaluation	用可复现任务样本量化模型行为的手段；评测只对样本负责	一次印象式试用
模型替换性	model substitutability	同一契约下更换底层模型而不改应用逻辑的性质	换模型后输出仍可预期一致

1.1 模型是组件，不是神谕

小a一开始以为，把模型接进系统，就等于请来一位“什么都会的同事”。他问老z：

“是不是只要模型够强，Agent 的问题就都解决了？”

“反过来想。”老z说，“如果模型什么都能做，Agent 工程就不需要存在了。**模型只负责一件事：根据输入生成后续文本。**它不知道你的系统有哪些工具、哪些权限、哪些历史记录——这些都要由系统装配好，再交给它。”

小a想了想，举了个例子：“用户问‘我的工单卡在哪个环节’——模型负责把这句话变成一句像样的回答，而‘工单现在在哪’，得系统去查业务库才能告诉它？”

“正是。”老z说，“模型不知道你的数据库在哪、状态字段从哪个表读、读出来能不能直接展示给这个用户。它只负责把已经到手的材料组织成文本；材料从哪来、能不能给，是系统的事。分工画清楚，后面选模型、评模型、换模型才有坐标系。”

“那模型强不强，到底重不重要？”

“重要，但不是全部。”老z说，“一次真实任务能不能完成，取决于模型能力、工具可用性和系统约束三者的配合。模型是系统里可以被替换的组件，就像数据库或消息队列——它应该服从系统的契约，而不是反过来。”

老z画了三条腿的示意图：

任务能否完成
   │
   ├── 模型能力：能不能写出正确的动作
   ├── 工具可用性：动作背后有没有真实能力撑
   └── 系统约束：权限、校验、流程允不允许执行

“三条腿里任何一条短，任务就倒。”老z说，“模型再强，工具没实现或权限没放开，动作也只是停在纸面上；反过来，模型平庸，但工具和校验把每一步都兜住了，任务照样能成。选型只是给系统挑一条腿，另外两条腿同样决定成败。”

小a追了一句：“如果模型强到能写对工具调用，我能不能就把判断全交给它？”

“不能，因为‘写对一次’和‘每次都写对’是两件事。”老z说，“模型会偶发地给出越界参数或幻觉路径。系统能不能扛住这种偶发错误，取决于你有没有在它和真实动作之间放校验。把判断全交给模型，等于把整条链路的可靠性押在一次生成上。”

老z给他画了个场景：“假设模型在工具调用里多传了一个参数，或者少填了一个必填项。如果你把调用原样转发，工具可能执行一个和你预期不同的动作；如果中间隔着一层 schema 校验，调用会被拦下来，系统可以重试或交给用户确认。同一个模型错误，前一种架构把它放大了，后一种把它消化了。”

“那‘可替换’具体指什么？”小a问。

“指模型换了，系统的其余部分不重写。”老z说，“你和模型之间约定的是接口契约——给定输入返回文本，外加可能的工具调用结构。只要新模型遵守这套契约，你换掉底层，工具、循环、权限都不动。反过来，如果你的工具描述、提示词、参数格式全都只为某一个模型的脾气调到极致，换模型就要重调一遍——那不是组件，是耦合。”

“契约会被破坏吗？”小a问。

“会，主要是两类。”老z说，“一类是模型升级后输出风格变了：同样的输入，措辞更啰嗦或更简短，下游解析就得跟着改。另一类是模型悄悄不再遵守某个隐含约定，比如以前总按固定顺序排字段，现在随机了。契约里没写明的东西，都不算契约——把对模型行为的假设显式写进校验和解析，破坏发生时你才会第一时间看见。”

小a把踩过的几类破坏记下来，让老z列成了一张更具体的表：

常见契约假设	破坏信号	显式化的做法
返回字段顺序稳定	升级后顺序变化，位置解析错位	按字段名解析，不按位置
工具调用参数完整合规	偶发缺参、多参或类型不符	schema 校验，失败重试
措辞风格稳定	升级后明显变啰嗦或精简	提示词锁定模板，必要时输出摘要
隐含的排序或去重约定	排序随机化、结果重复	把规则写进提示词，并在校验层复验

“这些条目没有一条是厂商写进文档的。”老z说，“它们是你和模型之间的不成文默契。把默契变成条文，破坏发生时它才是可报告的故障，而不是一个难以复现的诡异现象。”

小a试着推演了一遍替换场景：“比如我换了模型，之前约定好的‘字段按固定顺序排’没了——这时我该找谁？”

“先看哪一层先发现。”老z说，“如果你的解析是按位置写的，模型一换，解析立刻错——这是校验层先发现；如果你解析按字段名写、但没验内容，换模型后字段还是齐的，只是某条结论变了——这是评测集先发现。校验层抓结构，评测集抓内容，两层缺一层，替换时就会有一个盲区。”

要点

• 模型的职责是生成，系统的职责是执行与约束
• 能力、工具、约束三者共同决定任务能否完成
• 模型是可替换组件，不是系统的主宰；可靠性靠系统校验，不靠单次生成

1.2 能力边界来自训练，不来自宣传

小a翻到一份模型介绍，写着“支持任意格式转换、编写任意语言代码”。他有点心动。

“这类说法，要怎么判断？”他问。

“把它当成营销话术，而不是技术规格。”老z说，“模型的能力边界来自它的训练数据、训练目标和推理资源：数据没覆盖到的领域，它只能靠类比续写；数据覆盖过的领域，信息也可能已经过时。”

小a追问：“‘过时’会是什么样子？”

“训练数据有一个截止点，但你的仓库、文档和 API 是活的。”老z说，“如果模型学到的用法早于你的接口新版本，它给出的调用可能语法合理、但照着跑不通——因为它不知道后来发生了什么。边界不只在‘会不会’，还在‘有没有跟上版本’。”

小a追问：“类比续写，听起来也像是‘会用’啊。怎么区分真会用和硬凑？”

“看输出能不能落地。”老z说，“数据覆盖的领域，它给的 API 名、参数名、文件结构通常对得上真实环境；硬凑的时候，它给的调用常常语法成立、但引用的对象不存在——比如调一个根本不存在的函数，或者拼一段看起来对、其实查无此库的代码。前者是记忆，后者是接龙惯性，两者在短句里很难分，放进真实执行里一下就露馅。”

小a问：“那同一个模型里，这两种区域大概怎么分布？”

“没有固定比例，但有一个可用的规律。”老z说，“主流语言、常见框架、公开库的用法，它见过的量够大，往往落在记忆区；私有协议、内部命名、上周刚发布的版本，它没见过或见得少，几乎都在类比区。你的任务越贴近公开语料，它那句‘会’越可能是真的。”

老z画了一条能力区带：

记忆区──────────模糊区──────────类比区
常见框架    │  冷门但存在   │  私有协议
主流库      │  少见的写法   │  内部命名
公开文档    │  半公开资料   │  新发布的版本
   │              │              │
验证靠执行   验证靠检索+执行   默认当接龙，不信

“这条带子不是静止的。”老z说，“模型升级、你的系统接入了检索工具，带子都会移动——检索把证据带进上下文，类比区里能拿到资料的部分就暂时变成了‘可查区’。判断某个能力落在哪一区，不是看模型名气，是拿你的真实任务去探。”

“所以一个判断办法是：让它在真实环境里跑，看引用的东西在不在。”小a说。

“对。”老z说，“**‘看起来对’和‘跑得通’之间隔着的就是数据边界。**越靠近边界，越要靠执行结果说话。”

“那如果引用的东西能对上，能反过来证明它‘懂’吗？”小a问。

“不能完全证明，但已经够工程用了。”老z说，“执行通过只能说明这次输出落到了真实环境里，不代表它理解了背后的原理；不过对系统来说，结果跑得通就是可接受的。我们要的不是证明它‘懂’，是让输出落到真实环境里能站住。”

“那能力边界到底怎么知道？”

“只能靠测。”老z说，“**模型的能力边界，不是读出来的，是测出来的。**文档能告诉你它支持什么协议、什么参数；但‘它能稳定完成什么任务’，必须用你的真实任务去验证。”

“所以‘任意语言代码’这种说法，问题在哪？”小a问。

“问题在‘任意’。”老z说，“训练数据里出现过某种语言，不代表它能稳定产出该语言的可用代码；冷门语言、刚发布的库版本、私有 API，几乎一定在它的类比区而不是记忆区。‘任意’是宣传用词，工程上要替换成‘某批样本上的可复现成功率’。”

小a点头：“所以‘任意语言’真正要问的是：我关心的那几门，分别落在它的记忆区还是类比区。”

“对，而且还要再拆细。”老z说，“同样是‘会写代码’，‘给现有函数补一段’和‘从零设计一个模块’是两个不同的能力形态；‘读注释改参数’和‘按你的内部 API 文档接一个服务’也不是一回事。宣传词是一片‘能’，工程上要拆成一块块‘在什么输入上、能产出什么’。”

1.3 选型看四件事

小a列了一张对比表，把所有候选模型都填进去，然后问老z：“参数、价格、延迟……我该优先看哪个？”

“没有固定顺序，但有固定维度。”老z在表上圈了四个词：

选型的四个约束

1. 任务匹配：你的任务是不是它被训练覆盖的形态
2. 成本：单次调用价格、上下文长度与并发放大后的总账
3. 延迟与吞吐：一次调用要多快、单位时间能处理多少
4. 可用性：地区、配额、数据驻留和长期稳定性

“这四个约束常常互相打架。”老z说，“快而贵、便宜但慢、强但配额紧——选型的本质是在四个约束里做取舍，不是找一个‘最好’的模型。”

老z把四个约束分别会在什么情况下顶到最前面，列成了一张表：

约束	什么时候它会顶到最前面	它失败时的代价
任务匹配	核心任务上频繁出错	重试与人工补救，隐性成本远超差价
可用性	地区、数据驻留或配额受限	根本没法上线，其余三项无从谈起
延迟与吞吐	交互有硬指标，或批量有截止时间	用户等不起，或任务在期限内跑不完
成本	预算有明确上限	上线即超支，被迫中途换模型

“没有一张表能替你排顺序。”老z说，“关键是先找出哪一项是‘不满足就死’的硬约束，剩下的按代价从大到小排。硬约束可以不止一个——比如既要求数据不能出境、又要求单轮应答在一秒内，那可用性和延迟就同时卡在最前面。”

“那怎么判断一个约束到底硬不硬？”小a问。

“把假设说破。”老z说，“问一句：如果这个条件不满足，任务还做不做？比如‘数据必须留在国内’，如果答案是‘那就用不了，宁可换方案’，它是硬的；如果答案是‘可以接受折中，比如加审批’，它是软的。把‘我想要’和‘必须要’分开列出来，选型时才不会拿软约束去卡掉一个其实合适的模型。”

“那我是不是该选最便宜的？”

“要看最坏情况。”老z说，“如果最便宜的模型在你核心任务上频繁失败，重试和人工补救的成本会超过差价。先把任务匹配测出来，再谈成本。”

小a追问：“那怎么判断差价值不值得省？”

“没有通用公式，但可以按场景估算。”老z说，“把失败概率的差距乘上核心调用的次数——多出来的重试、超时重试和人工复核，都是纯成本。省的是单价，花的是失败，账要合起来算。”

小a又问：“那反过来，选最强的呢？至少不会因为模型不够强而失败。”

“会换一种方式失败。”老z说，“最强的模型往往最贵、配额最紧、延迟最高。在交互式场景里，单次慢一截，用户体验就崩；在批量场景里，配额一顶住，任务根本跑不完。‘不够强’和‘太贵太慢’都会让任务失败，只是失败发生在不同环节。”

小a问：“那同样的四个约束，交互和批量两种场景，排出来会不一样吗？”

“会很不一样。”老z画了两行对比：

交互场景（用户在线等）：  延迟与吞吐 → 可用性 → 任务匹配 → 成本
批量场景（离线跑完）：    成本 → 配额与吞吐 → 任务匹配 → 延迟

“交互场景里，慢比贵更致命——用户不会等你重试三遍；批量场景里，贵和跑不完比慢更致命——晚一小时出结果通常没事，单价翻倍就难受了。同一个模型，在两个场景里可能给出两个完全不同的选择。”

小a接着问：“那整条流水线，是不是只能用一个模型？”

“不必。同一套系统里可以同时用多个模型，按任务分派。”老z说，“路由和分类这类简单判断用便宜的小模型，核心生成或复杂推理用强模型；甚至可以给同一个任务配主模型和兜底模型——主模型超时或失败时切到另一个。**选型不是‘选一个’，而是‘给每个环节选一个合适的’。**但要注意：环节越多，测试组合越多，评测集的成本也跟着上来。”

“四个约束打架时，有没有通用的优先级？”小a问。

“有一个粗略顺序，但不绝对。”老z在表边画了张决策顺序：

示意：选型取舍的常见顺序

任务匹配（能不能稳定做对）
       ↓ 通过
可用性（这里能不能用、能不能长期用）
       ↓ 通过
延迟与吞吐（够不够快、够不够多）
       ↓ 通过
成本（总账能不能接受）

任务匹配排第一，是因为它在后面三项上做得再好也救不回来——一个做不对任务的模型，再便宜也不省。但只要数据驻留、配额或延迟里有一项是硬约束，它就会顶到任务匹配前面去。

“所以顺序不是固定的。”老z说，“哪个约束是硬性的，它就排第一；其余的按代价大小往下排。”

1.4 用评测代替感觉

“怎么测任务匹配？”小a问。

“用评测。”老z说，“评测不是跑一遍基准测试看分数，而是用你的真实任务样本，量化模型在‘你关心的行为’上的表现。”

示意： 如果你的任务是“按项目文件列表提取测试命令”，评测样本可以包括 10 个不同项目的配置文件。每次跑完统计：正确识别命令的比例、读错文件路径的比例、以及需要多轮追问才纠正的比例。分数只对这批样本负责。

老z在纸上画了评测集从无到有的过程：

从真实请求里抽任务样本
   │
   ├─ 人工先标好“期望行为”：正确 / 证据不足 / 应拒绝
   │
   ├─ 按行为分类：正常路径、边界输入、失败场景
   │
   └─ 跑模型 → 记录输出 → 对照标注统计
          └─ 结果存下来，作为换模型时的回归集

“标注会不会很费劲？”小a问。

“费劲，但值得。”老z说，“每条样本的‘期望行为’要人先定好——同样一个问题，什么算答对、什么算可以接受、什么算必须拒绝，标的人不统一，分数就没有意义。所以第一条规则是先写标注说明：模型的输出是供人参考，还是会直接触发操作，对‘什么算合格’的定义完全不同。评测集是测出来的，也是标出来的；标得糊，测什么都白测。”

“分数高就说明能用？”

“分数只是起点。”老z说，“评测要覆盖三种行为：正常路径、边界输入和失败场景——比如没有配置文件时，它会不会编造命令。一个在常规样本上表现好、在边界样本上编造答案的模型，和成绩一般但老实承认不知道的模型，在 Agent 里的表现可能截然不同。”

老z把三类样本各自的考点列了出来：

样本类型	具体长什么样	考的是
正常路径	配置齐全、问题典型	常规完成度与格式稳定性
边界输入	空配置、极长输入、缺字段	会不会硬凑、会不会崩
失败场景	检索无结果、权限不足、信息过期	会不会编造、有没有退路

“三类样本缺哪类，评测就漏哪类风险。”老z说，“正常路径高分只能说明它‘做熟活’稳，Agent 最容易出事的恰恰是那些它不熟的边角。”

“那公开榜单呢？”

“榜单是参考，不是验收。”老z说，“公开榜单测的是公开任务，你的任务不在里面。拿自己的样本跑一遍，比引用任何榜单都有说服力。”

“那榜单一点用都没有吗？”小a追问。

“有用，但只能当初筛。”老z说，“它告诉你一个模型在同类型任务上的大致水准，帮你把二十几个候选先砍掉一大半；但榜单分数和你的任务之间的差距，可能来自数据分布、任务形态、评测方式任何一个环节。榜单的作用是‘别从零开始’，不是‘就此定案’。”

小a追了一句：“我自己跑的评测，会不会也有偏？”

“会，主要在两处。”老z说，“一是样本偏：你只挑了顺手的项目当样本，模型在这批上分数好看，换个仓库就垮。二是指标偏：只统计‘答对了没’，没统计‘答错时是老实说不知道、还是一本正经编一个’，这两种错误在 Agent 里后果完全不同。评测的偏，靠的不是消除，是知道它偏在哪、再用另一批样本交叉验证。”

“指标偏的例子，能再说细一点吗？”小a追问。

“拿‘答错了’这一个标签说。”老z说，“如果它答错时老实说‘这个我不确定’，系统可以把问题转给人工，损失可控；如果它答错时一本正经给出一个不存在的路径，用户照着操作，损失就大了。两种错都叫‘错’，风险完全不同——把‘编造’和‘不确定’并成一个桶，评测就分不出这两种后果。”

“那评测样本要多少？”小a问。

“够分出趋势就行，不必求多。”老z说，“**几条样本能告诉你它会不会做这件事；几十条才能告诉你它多久失败一次。**区分这两件事的样本量，比单纯堆数量更重要。”

“那评测集建好之后，就一直不动了吗？”小a问。

“要跟着任务走。”老z说，“任务本身会变——流程改了、工具改名了、你的验收标准更新了——评测集不更新，分数测的就是一个已经不存在的老任务。换模型时用它当回归集，任务变化时也要同步更新它；它是一套需要维护的资产，不是一次性的打分表。”

1.5 成本是可以设计出来的

小a算出总账之后吓了一跳：“光上下文里塞项目文件，一个月就不少钱。”

“成本不是被动接受的，是可以设计的。”老z说，“你每往上下文里放一段内容，都在花两笔钱：一笔是当次调用的输入费用，一笔是延迟——上下文越长，处理越慢。反过来，裁剪历史、缓存稳定前缀、把长文档改成按需检索，都是在降低这两笔开销。”

“那这几类手段，一般按什么顺序上？”小a问。

“按内容特征分，而不是按名字分。”老z列了一张表：

上下文内容	特征	合适的成本手段
系统提示、工具清单	每轮都一样的稳定前缀	提示词缓存，省重复处理
聊天历史	逐轮增长、重复度高	裁剪、摘要压缩、窗口内滚动
长文档、大仓库	体积大、多数用不到	按需检索，只带命中片段
跨会话的长期事实	需要持续存在	存到外部存储，用工具读

“顺序是先固定能固定的，再砍掉会变的。”老z说，“稳定前缀走缓存，变化部分走裁剪或检索——反了的话，缓存永远命不中，检索也省不下钱。”

“那是不是上下文越省越好？”

“不是。”老z说，“过度裁剪会让模型丢掉完成任务需要的证据。**成本设计的目标是‘刚好够完成任务’，不是‘越少越好’。**这个问题在第10章 记住什么，忘掉什么——Memory会展开。”

“裁剪和缓存，哪个更优先？”小a问。

“看那段内容会不会变。”老z说，“系统提示、工具清单这种每轮都一样的，先走缓存前缀，每轮省的是它被重复处理的费用；聊天历史、检索结果这种每轮都在变的，只能裁剪或压缩。先固定能固定的，再砍掉会变的——顺序反了，缓存就省不到钱。”

小a又问：“延迟这笔钱，怎么算？它又不直接扣费。”

“它扣的是体验和吞吐。”老z说，“交互场景里，单轮慢一秒，用户就觉得卡；批量场景里，单轮多花半秒，乘上并发数和总轮数，就是实打实的机器时间。延迟这笔账记在哪，取决于你的场景对‘慢’有多敏感，而不是它出不出现在账单上。”

“那做预算的时候，怎么把账算准？”小a问。

“先按 token 数，别按字数。”老z说，“不同语言、不同内容类型切出来的 token 数量差别很大——一段中文的 token 数可能是同长度英文的好几倍。**要估算就先对着目标 API 的计数接口跑几段真实内容，用数出来的 token 数乘单价，而不是拿字数拍脑袋。**估算完还要留余量，因为失败重试本身也是一笔成本。”

“那延迟的来源，主要在哪几处？”小a问。

“至少三处。”老z说，“一是输入长度——同样的模型，上下文越长，单次处理越慢；二是输出长度——生成是逐步的，要的长文本天生比短回复慢；三是服务端排队——高峰期请求排队，再快的模型也快不起来。前两处你可以通过裁剪和约束输出设计，第三处只能靠错峰、降并发或换配额。”

“模型服务一般会区分流式和非流式，我该怎么选？”小a问。

“看你的场景要不要‘先看到一部分’。”老z说，“交互场景通常选流式，边生成边展示，用户的第一反应快很多；但要先全部收齐再做结构化解析的，非流式更省事。这不是质量差别，是到达方式差别——你等的内容是一样的，只是要不要分批看到。”

“流式的话，会不会把内容切得七零八落？”小a追问。

“要看你的下游怎么消费。”老z说，“展示给用户看，逐个片段流过去没问题；但如果你要解析结构、提取字段，流式输出可能一段字段名和它的值隔着好几帧，解析逻辑要等完整的结构出现才下手。判断标准是：你的消费方是‘人看着舒服’还是‘程序要收齐’——前者流式友好，后者通常在服务端收齐再统一处理。”

1.6 把模型放回系统的位置

小a消化了一会儿，把模型从“神谕”的位置上请了下来。

“所以一句话总结：模型是系统里负责生成的那个组件，它强不强要测，贵不贵要算，能不能换要留好接口。”他说。

“对。”老z说，“这三件事串起来，就是这一章的全部：测，是为了知道边界在哪；算，是为了知道代价在哪；留接口，是为了不让它绑架整个系统。”

老z把三件事收进一张表：

设计动作	回答的问题	落地形态
测	这个模型在我的任务上能稳定做什么	任务样本评测集，覆盖三种行为
算	用它的总账是多少	上下文成本、缓存、失败率一起估算
留接口	换掉它要不要重写系统	统一的调用抽象、schema 校验、提示词模板

“这张表补上最后一列，就是模型替换的操作清单。”老z说，“评测集做回归——新模型先跑一遍，看哪些样本变了；调用抽象保证换模型时应用代码不动；模板和校验保证输出结构还是原来的。三者齐了，换模型是 A/B 测试；缺一个，换模型是重构。”

小a想了想：“那 Agent 工程做的事，就是在模型和真实任务之间，搭这一层测、算、留接口的脚手架？”

“正是。”老z说，“这一章我们先不打开模型内部，只把它当作一个‘会生成文本的组件’来打交道。真正理解它为什么这么难缠，要从它怎么生成文本讲起——那是后面的事。现在，你只需要记住三件事：测、算、留接口。”

老z把三件事画成了一张检查清单，示意小a贴起来：

接新任务、换模型前，逐条过：
  [ ] 任务匹配：拿我的样本跑过吗？三类行为都测了吗？
  [ ] 硬约束：数据驻留 / 配额 / 延迟，哪项不满足就死？
  [ ] 成本：按 token 估过总账吗？重试和补救算进去了吗？
  [ ] 契约：解析按字段名吗？对模型的假设写进校验了吗？
  [ ] 回归集：这次变更后，评测集需要更新吗？

小结

本章把 LLM 从“神谕”的位置上请下来，放回 Agent 系统的组件层。它只负责根据输入生成后续文本，不知道你的工具、权限和历史——这些都要由系统装配。能力边界来自训练数据与推理资源，营销话术不是技术规格，只能靠真实任务评测去测。同一个“会”，落在记忆区还是类比区，靠的是拿真实环境里的执行结果去验证，而不是读宣传页。

选型没有“最好”，只有取舍：任务匹配、成本、延迟与可用性四个约束互相打架，先把任务匹配测出来，再谈成本。成本是可以设计的，裁剪、缓存、按需检索都是降低开销的手段，但目标是“刚好够完成任务”，不是“越少越好”。评测的价值不止是算分——正常路径、边界输入、失败场景三类样本要分开看，模型在边界上是老实承认不知道还是一本正经编造，决定的是完全不同的风险等级。模型被当作可替换组件来对待时，换底层就不需要重写其余部分——它服从系统契约，而不是反过来。

把这一章做成一张可以随身带的三件事清单，就不会在选型时被榜单和宣传带走：测，知道它的边界在哪；算，知道它的代价在哪；留接口，知道换它时系统要动多少。三者里面，测是入口——评测集一旦建好，就变成了换模型时的回归工具，这也是它最容易被低估的长期价值。模型是组件，组件的意思是：它有脾性、有代价、有边界，可以被更换，但前提是你先把它测清楚、算明白、接得松。

动手核验

挑两个模型，用 5 个真实任务样本各跑一轮，只统计三个指标：正确完成的比例、编造不可验证信息的比例、以及需要多轮交互才完成的次数。再把上下文长度减半重跑，记录完成质量与单次延迟或费用的变化。不要把结果解释成“某个模型全面优于另一个”。