前言：

开始本文前先用最省的篇幅交代三件底层事实

Transformer 是什么? 一句话——它是当代 LLM 的底层架构,靠"注意力机制"判断一段文字里哪些词彼此相关,从而能并行处理长序列、理解长距离依赖。你现在只需记住:模型能"读懂上下文",靠的就是它。

模型的能力从哪来? 两步:预训练用海量文本让模型学会知识和语言(但只会"续写");后训练(监督微调 + 对齐)才教会它"听指令、好好对话"。这解释了本篇的核心——为什么 Agent 如此依赖"指令跟随"能力,因为那是后训练专门塑造出来的。

本文不会深入模型内部原理。 做 Agent 开发,把 LLM 当成一个"能读懂上下文、按指令输出"的黑盒 API 就够了,就像用数据库不必先懂 B+ 树。想搞清楚 Transformer、注意力、预训练/对齐的机制,可读本系列的第 附录 篇《Transformer 与预训练》(可选前置)。本文我们只站在 Agent 开发者的视角看模型。

一、Agent 为什么如此依赖"指令跟随"能力

先回顾上一篇的回路:每一轮,我们把上下文喂给 LLM,由它决定"调哪个工具"或"直接回答"。请注意,这个决策没有任何硬编码的规则——完全是模型读完你的系统提示和工具描述后,"自己想"出来的。

这就引出一个关键事实:Agent 的可靠性,首先是模型指令跟随(Instruction Following)能力的函数。

传统软件里,if/else 分支是确定的,写对了就永远对。Agent 不是。同样一段提示,能力强的模型能稳定地在该调工具时调工具、该停时停;能力弱的模型可能:

• 该调工具时,自己"脑补"了一个工具返回值(幻觉);
• 参数格式给错,把 {"city":"北京"} 写成 {"城市":"北京"};
• 陷入啰嗦,反复解释"我打算调用工具"却始终不真正发起调用;
• 无视你在系统提示里写的约束("只用中文回答"照样飙英文)。

所以在 Agent 场景里,选模型的第一标准不是"知识多渊博",而是"指令跟随和工具调用有多稳"。一个知识稍弱但极其"听话"、工具调用格式永远正确的模型,做 Agent 往往比一个博学但"自由发挥"的模型更好用。这一点和做纯问答 Chatbot 的选型直觉是相反的。

实践建议:评估一个模型能不能做 Agent,别只看榜单分数,要专门看它的工具调用成功率和多步任务完成率。很多模型的对话体验很好,但一让它稳定输出结构化工具调用就露馅。

二、推理模型:会"先想后答"的大脑

近两年最重要的变化,是推理模型(Reasoning Models)的成熟——它们在给出答案前,会先生成一段内部的"思考过程"。你可以把它类比成:普通模型是脱口而出,推理模型是先在草稿纸上演算再下笔。

这对 Agent 意味着什么?非常关键的几点:

1. 更强的规划能力。 面对"先查天气、再根据天气决定要不要查路况"这种需要多步推演的任务,推理模型能在"思考"阶段就把步骤想清楚,而不是走一步看一步。回顾上一篇的四能力维度,推理模型直接强化了"规划"这一维。

2. 更少的工具误用。 因为它会先推演"我到底需不需要这个工具、参数该填什么",工具调用的准确率通常更高。

3. 但更慢、更贵。 那段"思考"本身要消耗大量 token 和时间。一个简单的"查个天气"任务,用推理模型可能要多花几秒和数倍 token。

这就带出一个核心的架构决策——不是所有环节都该用推理模型:

       任务复杂度低                        任务复杂度高
   (查询、格式化、路由)              (多步规划、复杂决策、纠错)
           │                                                         │
          ▼                                                       ▼
    ┌─────────────┐                    ┌─────────────┐
    │  快模型                    │                      │  推理模型     │
    │ (便宜、快)              │                      │ (贵、慢、强)  │
    └─────────────┘                    └─────────────┘
          │                                                                               │
          └──────────► 模型路由 / 级联 ◄────────┘
              (由一个轻量判断决定用哪个,后续文章会详细讲)

一个成熟的 Agent 系统常常是混合模型的:用快而便宜的模型做意图路由、参数抽取、结果格式化,只在真正需要深度规划的节点才动用推理模型。后续文章会展开讲"模型路由与级联"。现在你只需建立这个意识:大脑不必只有一个,按脑力需求分配

三、系统提示的结构化设计（系统提示词）:

如果说模型是大脑,系统提示(System Prompt)就是给这个大脑的岗位说明书。Agent 的系统提示和 Chatbot 的有本质区别:它不只是设定人设,而是要精确约束行为、定义工具契约、规定输出格式。

一个结构良好的 Agent 系统提示,通常包含四个部分:

1. 角色与目标(Role) —— 你是谁、要达成什么。 2. 约束与规则(Constraints) —— 能做什么、不能做什么、边界在哪。 3. 工具契约(Tools) —— 有哪些工具、何时用、参数怎么填(上一篇的坑 2 讲过,这是可靠性第一关)。 4. 输出契约(Output) —— 最终答案要什么格式、什么语言、什么结构。

下面是一个可直接套用的系统提示词模板：

static final String SYSTEM_PROMPT = """
    # 角色
    你是一个差旅助手,帮用户查询并规划行程。

    # 约束
    - 只处理差旅相关请求,无关问题礼貌拒绝。
    - 不确定的信息必须调用工具查证,严禁编造车次、价格。
    - 每次最多调用 3 个工具,避免过度调用。

    # 工具使用
    - 需要实时数据(车次、天气、酒店)时,必须调用对应工具。
    - 信息已足够时,不要再调用工具,直接给出结论。

    # 输出格式
    - 用中文回答。
    - 最终方案用「出发时间 | 车次 | 价格」的表格呈现。
    """;

几个写系统提示的实战要点:

用"必须/严禁"这类强指令词,比"尽量""建议"更能被模型稳定执行。Agent 提示要的是确定性,不是委婉。

把最重要的约束放在开头和结尾。 模型对长提示的中间段落注意力较弱(这和第五节的上下文经济学相关),关键规则别埋在中间。

工具的"何时用/何时不用"要成对写。 只说"需要时调用工具"不够,一定要补一句"信息够了就别调"——否则模型容易陷入上一篇坑 1 的过度调用死循环。

输出契约要具体到可验证。 "用表格呈现"比"清晰地呈现"好,因为前者你能用代码校验它到底有没有照做。

提示工程正在演化为更大的"上下文工程"。系统提示只是喂给大脑的上下文的一部分,还有检索结果、记忆、工具返回值。但系统提示是你唯一能完全掌控的部分,值得反复打磨。

四、上下文窗口经济学:token、成本、延迟的三角

大脑的"工作记忆"是有限的——这就是上下文窗口(Context Window)。所有喂给模型的东西(系统提示 + 历史对话 + 工具返回 + 当前问题)都要挤进这个窗口,并且每个 token 都要花钱、花时间。

这里有三个此消彼长的量,构成一个三角:

                 token 用量
             /                           \
            /                              \
         成本 ◄──────────► 延迟
       (钱越多)                     (等越久)

   塞进窗口的 token 越多:
   → 成本越高(按 token 计费)
   → 延迟越大(模型处理更慢)
   → 但信息越全(可能决策更准)
   三者需要按场景平衡,不存在免费的"全塞进去"

对 Agent 来说,这个三角尤其致命,因为 Agent 是多轮循环:每一轮都带着不断变长的历史重新调用模型。会出现上下文无限增长——一个跑了 30 轮的 Agent,如果不做任何处理,最后一轮可能要把前 29 轮的所有工具返回值一起再发一遍,成本和延迟都会失控。

几个必须知道的应对手段后面文章会详细讲解

提示缓存。 系统提示这种每轮都不变的部分,很多厂商支持缓存,重复部分大幅降价、提速。把稳定的内容(系统提示、工具定义)放在上下文最前面,能最大化缓存命中。

历史压缩与摘要。 跑了很多轮后,把早期的对话和工具结果压缩成一段摘要,只保留关键结论,而不是原样携带。

选择性携带。 不是每一轮都需要全部历史。有些框架只把最近 N 轮 + 相关记忆带进去。

警惕"上下文腐化"。 一个反直觉的事实:上下文不是越长越好。窗口塞得太满时,模型对中间内容的注意力会下降,反而可能表现更差。所以"精准地喂"比"喂得多"更重要。

记住这条经验法则:上下文窗口是 Agent 最稀缺的资源,要像管理预算一样管理它。 每往里放一段内容前,问一句"这轮决策真的需要它吗?"

五、温度与采样:该让大脑多"随性"

最后一个常被忽略但影响很大的旋钮:温度(Temperature)。它控制模型输出的随机性——温度高,输出更多样、更有创意;温度低,输出更确定、更可复现。

对 Agent 来说,直觉很明确:大多数情况下要低温度。

原因是 Agent 的核心动作是"做正确的决策、生成格式正确的工具调用",这些场景要的是稳定和可预测,不是创意。你不希望同样的输入,这次 Agent 调了搜索工具、下次却心血来潮调了别的。高温度会放大上一篇提到的各种不稳定行为。

一个实用的配置原则:

温度接近 0     ──►  工具调用、参数抽取、路由决策、结构化输出
                    (要确定性,要可复现)

温度中等       ──►  最终面向用户的自然语言回复
(0.3 ~ 0.7)         (要一点自然和温度,但仍需可控)

温度较高       ──►  纯创意场景(头脑风暴、文案多样性)
(0.7+)              (Agent 里很少用到)

需要提醒的是:即使温度设为 0,输出也未必 100% 确定。 由于浮点运算、并行计算等底层原因,大多数模型在温度 0 时仍可能有微小的不确定性。所以别把"温度 0"当成"绝对可复现"的保证——这也是为什么 Agent 需要专门的评估和测试体系(第 17 篇),而不能像传统单元测试那样假设"输入固定则输出固定"。

六、总结

这一篇我们钻进了 Agent 的大脑:

• Agent 的可靠性首先是模型指令跟随与工具调用能力的函数,选型标准和 Chatbot 不同;
• 推理模型强化了规划能力但更慢更贵,成熟系统按脑力需求混合使用多个模型;
• Agent 的系统提示要包含角色、约束、工具契约、输出契约四部分,用强指令词、成对写工具使用条件;
• 上下文窗口是最稀缺资源,要在 token、成本、延迟三角里精打细算,警惕上下文腐化;
• 决策环节用低温度追求确定性,但别指望温度 0 带来绝对可复现。