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

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

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

老Z没直接回答：“先别急着比参数。你先说说，模型在你的 Agent 里是干什么的？”

“生成回答啊，还能干什么？”

“要是它什么都干得了，Agent 工程就不需要存在了。”老Z说，“这一章不看任何具体产品，我们把 LLM 放回 Agent 的坐标系里，摸清它的脾气。坐标系搭好了，选型的事自然清楚。”

本章回答什么

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

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

先这样理解 Agent：本章说的 Agent，可以先粗略理解为“模型提出下一步、由程序去执行并决定是否继续”的系统；执行动作的那个程序叫宿主。完整定义在第7章 一台自动接力的机器——Agent。

先把名字对齐

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

1.1 模型是组件，不是神谕

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

老Z把他的想法拆开了：“本章讨论的文本生成模型只负责一件事：根据输入生成后续文本。你系统里有哪些工具、哪些权限、哪些历史记录，它一概不知道，全靠系统装配好再交给它。”

小A拿自己的业务去套：“用户问‘我的工单卡在哪个环节’，模型负责把这句话变成一句像样的回答；至于‘工单现在在哪’，得系统去查业务库才能告诉它？”

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

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

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

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

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

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

小A还是不太服气：“假如模型强到能写对工具调用，我把判断全交给它，行不行？”

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

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

“那‘可替换’具体指什么？”

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

“契约会被破坏吗？”

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

小A把见过的几类破坏记了下来，老Z把它们整理成一张更具体的表：

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

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

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

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

要点

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

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

小A翻到一份模型介绍，上面写着“支持任意格式转换、编写任意语言代码”。他有点心动，拿去问老Z这类说法怎么判断。

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

“‘过时’长什么样？”

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

“类比续写出来的东西，听起来也很像‘会用’啊。”

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

“那同一个模型里，记忆区和类比区大概怎么分布？有没有个比例？”

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

老Z画了一条能力区带：

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

“这条带子还会动。”老Z说，“模型升级，带子挪一挪；你的系统接了检索工具，证据被带进上下文，类比区里拿得到资料的部分就暂时变成‘可查区’。判断某个能力落在哪一区，别看模型名气，拿你的真实任务去探。”

“探的办法我猜是：让它在真实环境里跑，看引用的东西在不在。”

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

“那引用能对上，能反过来证明它‘懂’吗？”

“证明不了，但工程上够用了。”老Z说，“执行通过只说明这次输出落到了真实环境里，不代表它理解原理。对系统来说，结果跑得通就是可接受的。”

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

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

“所以‘任意语言代码’这种说法，问题出在哪个字上？”

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

小A点头：“真正要问的是：我关心的那几门，分别落在记忆区还是类比区。”

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

1.3 选型看四件事

小A把所有候选模型填进一张对比表：参数、价格、延迟、上下文长度。填完他去问老Z：“这么多列，我该优先看哪个？”

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

选型的四个约束

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

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

四个约束分别在什么时候顶到最前面、顶不住时代价是什么，老Z也列了出来：

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

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

“怎么判断一个约束到底硬不硬？”

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

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

“先看最坏情况。最便宜的模型在你的核心任务上频繁失败，重试加人工补救，成本早超过差价了。任务匹配先测出来，成本再谈。”

“差价值不值得省，有没有算法？”

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

“那我反过来，选最强的，至少不会败在模型不够强上。”

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

“同样的四个约束，交互和批量排出来会不一样？”

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

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

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

“那整条流水线只能用一个模型吗？”

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

“四个约束打架，有没有通用的优先级？”

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

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

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

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

1.4 用评测代替感觉

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

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

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

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

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

“标注会不会很费劲？”

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

“分数高就能用？”

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

三类样本各自的考点，老Z列了出来：

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

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

“那公开榜单呢？总得有点参考价值吧。”

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

“我自己跑的评测，会不会也有偏？”

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

“指标偏能说细点吗？”

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

“样本要多少条？”

“够分出趋势就行。几条样本告诉你它会不会做这件事，几十条才能告诉你它多久失败一次，区分这两件事比堆数量重要。”

“评测集建好就一劳永逸了？”

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

1.5 成本是可以设计出来的

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

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

“这些手段按什么顺序上？”

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

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

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

“那上下文越省越好？”

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

“延迟这笔账怎么算？它又不直接扣费。”

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

“做预算时怎么把账算准？”

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

“延迟的来源主要在哪几处？”

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

“模型服务区分流式和非流式，怎么选？”

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

“流式会不会把内容切得七零八落？”

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

1.6 把模型放回系统的位置

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

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

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

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

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

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

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

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

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

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

小结

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

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

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

动手核验

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