中文译本。原文见同目录 README.md

第 2 课：Agent 如何思考 - LLM 作为推理引擎

引言

在第 1 课中，我们说过 Agent 由三部分组成：模型（大脑）、工具（双手）和编排层（控制循环）。本课聚焦大脑。

语言模型是 Agent 最重要的组件。它负责读取用户目标、推理该做什么、决定调用哪些工具、解释结果并生成最终答案。Agent 系统中的其他一切，都是为了支持或扩展模型能做的事。

理解 LLM 如何工作——哪怕只是高层理解——会让你成为好得多的 Agent 构建者。你会知道为什么有些提示有效、有些无效；理解 Agent 为何有时会跑偏；并能就模型选择、提示设计与系统架构做出知情决策。

LLM 作为 Agent 的大脑

大语言模型是在海量文本数据上训练的神经网络。其核心只做一件事：预测下一个 token（大致是下一个词或词的一部分），给定此前所有内容。

听起来简单，但由此涌现的能力非常惊人：

理解：理解复杂问题与指令
推理：处理多步逻辑问题
规划：把目标拆成子任务
代码生成：编写与调试软件
工具选择：决定调用哪个函数以及用什么参数
摘要：把长文档提炼成要点
翻译：在语言、格式与表示之间转换

LLM 擅长什么

能力	Agent 场景中的例子
自然语言理解	解析用户请求：「取消我最近的订单」
推理与规划	决定：「先找订单，再检查是否可取消，然后取消」
工具选择	选择调用 `lookup_order(user_id, sort="recent")`
输出格式化	返回干净的 JSON 响应或友好消息
错误解释	阅读 API 错误并决定用不同参数重试
上下文综合	把多次工具调用的结果合成连贯答案

LLM 做不到的事（没有帮助时）

局限	为何重要
无实时数据访问	模型知识有训练截止日期
无计算保证	LLM 可能算错数学——它们预测 token，不计算
无持久记忆	每次对话从零开始，除非你自行构建记忆
无法行动	没有工具，模型只能生成文本
幻觉风险	模型可能生成看似合理但不正确的信息
上下文窗口限制	模型一次能处理的文本量有上限

这就是 Agent 存在的原因。工具弥补模型无法行动与访问实时数据的缺陷。编排弥补其缺乏持久记忆以及容易跑偏的倾向。

语言模型如何处理信息

你不需要深入理解 transformer 架构也能构建 Agent，但理解三个关键概念会帮你写出更好的提示、设计更好的系统。

Token：语言的单位

LLM 不读字符或词。它们读 token——模型在训练中学会识别的文本块。一个 token 可能是整个词、词的一部分，或标点。

例子：

文本	大约 Token 数
"Hello"	1 token
"Hello, world!"	3 tokens
"ChatGPT is amazing"	4 tokens
典型代码函数（20 行）	100-300 tokens
一整页英文文本	~500-700 tokens

对 Agent 为何重要：

计费：多数 API 按 token 收费（输入 + 输出）。Agent 工作流比单次提示用更多 token，因为循环每次迭代都会发送完整上下文。
速度：更多 token = 更长生成时间。保持工具描述简洁。
上下文限制：单次调用模型能处理的 token 有上限。若 Agent 累积的上下文超出，你会丢失信息。

上下文窗口：模型的工作记忆

上下文窗口是模型一次能考虑的 token 总数。可以把它想成模型的桌面——需要参考的一切都必须放在这张桌上。

模型	上下文窗口
Gemini 3.1 Pro	1,000,000 tokens
Gemini 3.5 Flash	1,000,000 tokens
GPT-5.6	1,050,000 tokens
Claude Sonnet 5	1,000,000 tokens

一次 Agent 调用中，什么会进入上下文窗口：

+------------------------------------------+
| System instructions ("You are a...")     |  ~200-500 tokens
+------------------------------------------+
| Tool definitions (names, descriptions,   |  ~500-2000 tokens
| parameter schemas)                       |
+------------------------------------------+
| Conversation history                     |  Variable
+------------------------------------------+
| Previous tool calls and results          |  Variable (can grow fast)
+------------------------------------------+
| Current user message                     |  Variable
+------------------------------------------+
| = Total must fit within context window   |
+------------------------------------------+

对 Agent 为何重要：

随着 Agent 执行多步，上下文随每次工具调用与结果增长。5 步 Agent 工作流可能累积数千 token 的工具结果。若不小心，可能在任务中途耗尽上下文窗口。

管理策略：

摘要中间结果，而不是保留原始数据
截断长工具输出，只留相关部分
对复杂多步任务使用大上下文窗口模型
实现滑动窗口，丢弃较旧、不太相关的上下文

上下文窗口探索器

调节滑块，查看不同组件如何占满上下文窗口。

选择模型

上下文窗口占用

Token 分配

Attention：模型如何聚焦

**注意力机制（attention）**让模型弄清上下文中哪些部分与当前决策相关。在决定下一个生成哪个 token 时，模型给输入的不同部分分配不同权重。

可以想成读长文档并高亮重要部分。模型会「高亮」与此刻目标最相关的 token。

对 Agent 为何重要：

把重要信息放在模型找得到的地方。 模型往往更关注上下文开头与结尾。关键指令应放在系统提示（开头）或靠近用户查询（结尾）。
具体且清晰。 模糊指令迫使模型猜测什么重要。具体指令让注意力机制更容易抓住正确信息。
结构有帮助。 清晰的标题、编号列表与一致格式，有助于模型解析并关注正确内容。

推理策略

Agent 如何「思考」一个问题，很大程度上取决于你如何提示模型。不同推理策略会产生非常不同的结果，尤其在复杂任务上。

Chain-of-Thought（CoT，思维链）

是什么： 提示模型在给出最终答案前逐步思考问题。

如何工作： 模型不是直接跳到答案，而是生成中间推理步骤。这会显著提高需要逻辑、数学或多步分析的任务准确率。

无 CoT 的例子：

Prompt: "If a server handles 100 requests/second and we have 3 servers,
         with 40% of traffic going to server 1, how many requests/second
         does server 1 handle?"

Model response: "120 requests per second"  (wrong)

有 CoT 的例子：

Prompt: "Think step by step. If a server handles 100 requests/second and
         we have 3 servers, with 40% of traffic going to server 1, how
         many requests/second does server 1 handle?"

Model response:
"Step 1: Total capacity is 3 servers x 100 req/s = 300 req/s
 Step 2: Server 1 receives 40% of total traffic
 Step 3: 40% of 300 = 120 req/s
 Step 4: Server 1 can handle 100 req/s but receives 120 req/s
 Answer: Server 1 receives 120 req/s but can only handle 100 req/s,
         so it is overloaded by 20 req/s"

逐步方法抓住了直接回答遗漏的过载情况。

何时在 Agent 中用 CoT：

复杂工具选择决策（「给定这 5 个工具，哪个在这里有用？」）
多步规划（「什么行动序列能达成这个目标？」）
错误诊断（「工具返回了错误——哪里出了问题，下一步该试什么？」）

Tree-of-Thoughts（ToT，思维树）

是什么： Chain-of-Thought 的扩展，模型探索多条推理路径，评估它们，并选出最好的一条。

如何工作： 不是一条推理链，模型生成几种可能做法，对每条打分或批评，并沿最有希望的路径继续。

Goal: "Optimize this slow database query"

Path A: "Add an index on the WHERE clause column"
  -> Evaluation: "Likely effective, low risk, easy to implement"

Path B: "Rewrite as a materialized view"
  -> Evaluation: "Might help, but adds complexity and maintenance"

Path C: "Denormalize the table structure"
  -> Evaluation: "Could work but high risk, affects other queries"

Decision: Proceed with Path A first, try Path B if A is insufficient

何时在 Agent 中用 ToT：

有多种有效做法，且希望模型考虑权衡时
根因不确定的复杂调试
需要评估备选方案的架构决策

权衡： ToT 用更多 token、花更多时间。留给选错代价高的决策。

逐步分解（Step-by-Step Decomposition）

是什么： 在执行任何步骤之前，先把复杂目标拆成更简单的子任务序列。

如何工作： Agent 先制定计划，再执行计划的每一步，并沿途检查进度。

User goal: "Set up monitoring for our new API endpoint"

Plan:
1. Check what monitoring tools are currently configured
2. Determine what metrics matter for this endpoint (latency, error rate, throughput)
3. Create the monitoring dashboard
4. Set up alerting thresholds
5. Test that alerts fire correctly
6. Document the monitoring setup

Execution: [proceeds step by step, with each step potentially using tools]

何时在 Agent 中用分解：

顺序很重要的多步任务
希望 Agent 对其做法透明的任务
受益于检查点的复杂工作流

模型选择：为任务挑选合适的模型

并非所有任务都需要最强模型。选对模型是工程决策，需在能力、成本、速度与可靠性之间平衡。

模型光谱

Lighter / Faster / Cheaper                  Heavier / Smarter / More Expensive
|----------------------------------------------------------|
Gemini Flash-Lite     Gemini Flash        Gemini Pro
(simple tasks)        (balanced)          (complex reasoning)

何时用什么

任务类型	推荐档位	原因
分类（「这是垃圾邮件吗？」）	轻量（Flash）	简单决策，无需复杂推理
数据抽取（「从这封邮件拉出日期」）	轻量（Flash）	模式匹配，输出明确
摘要	轻到中等	取决于源材料长度与复杂度
多步推理	中到重（Pro）	需要持续逻辑链
复杂代码生成	重（Pro）	需要深刻理解模式与边界情况
Agentic 工具使用	中到重	工具选择与结果解释需要强推理
创意写作	中等	不必用最重模型也能有好结果

模型路由：不同步骤用不同模型

成熟的 Agent 系统不会每一步都用同一模型。这叫 model routing（模型路由）——按复杂度把工作流不同部分导向不同模型。

架构例子：

User query arrives
    |
    v
[Light model: Classify intent]  --> "order_status"
    |
    v
[Light model: Extract parameters]  --> order_id: 12345
    |
    v
[Tool call: Look up order]  --> status data
    |
    v
[Light model: Format response]  --> "Your order #12345 shipped on March 15"

在这个流中，每一步都用快速、便宜的模型，因为单个步骤都不需要重推理。总成本与延迟远低于整段交互都用前沿模型。

对比更难的任务：

User: "Review this pull request and suggest improvements"
    |
    v
[Heavy model: Analyze code changes, reason about patterns,
 identify bugs, suggest improvements]
    |
    v
[Return detailed review]

此任务需要深度推理，因此值得用更强的模型。

Google Cloud 模型选项

Google Cloud 通过 Vertex AI 提供 Gemini 模型访问：

Gemini 3.5 Flash - Google 当前默认主力。对多数 Agent 任务快速高效，具备强 agentic 与编程表现，以及大上下文窗口（1M tokens）。
Gemini 3.1 Pro - 复杂任务的顶级推理。任务需要深度分析、复杂多步逻辑或细腻理解时使用。
Gemini 3.1 Flash-Lite - 分类与抽取等简单任务的最快、最便宜选项。

注意： 模型名称变化很快。Gemini 2.5 系列（2.5 Flash、2.5 Pro、2.5 Flash-Lite）仍可用，但计划于 2026 年 10 月 16 日退役；Gemini 2.0 模型已于 2026 年 6 月 1 日关停。请始终查阅文档获取当前模型 ID。

了解更多： Vertex AI Model Documentation

了解更多： Gemini API Documentation

系统指令的角色

系统指令是 Agent 的「职位描述」。它们告诉模型它是谁、能做什么、应如何行为，以及不应做什么。

系统指令里写什么

写得好的 Agent 系统指令通常包括：

角色定义：Agent 是什么、为谁服务
能力：有哪些工具、何时使用
约束：Agent 不应做什么
输出格式：如何组织回复
错误处理：出错时怎么办
个性/语气：如何沟通（如相关）

例子：客服 Agent

You are a customer support agent for Acme Corp, an online electronics retailer.

Your role:
- Help customers with order inquiries, returns, and product questions
- Be friendly, professional, and concise

Available tools:
- lookup_order(order_id): Returns order status, items, and shipping info
- initiate_return(order_id, reason): Starts a return process
- search_products(query): Searches the product catalog
- escalate_to_human(reason): Transfers to a human agent

Guidelines:
- Always verify the customer's identity before accessing order information
- If you cannot resolve an issue in 3 attempts, escalate to a human agent
- Never make up order information - always use the lookup tool
- Do not offer discounts or refunds beyond standard policy
- Keep responses under 3 paragraphs

When you encounter an error from a tool:
- If it is a temporary error (timeout, 500), retry once
- If it is a permanent error (not found, unauthorized), explain the issue to the customer
- If you are unsure, escalate to a human agent

写有效系统指令的技巧

要做	不要做
对工具用法具体说明	让工具选择含糊不清
定义清晰边界	假设模型知道你的业务规则
包含错误处理指导	指望模型自己搞定错误
指定输出格式	让模型每次自己选格式
使用具体例子	写抽象、模糊的指令
保持指令简洁	写十页长文（浪费上下文）

顺序很重要

模型对系统提示开头与结尾的指令更敏感。这样组织系统指令：

1. Most critical rules (identity, safety constraints)     <-- Start
2. Tool usage guidelines
3. Output format
4. Examples
5. Edge case handling
6. Reminder of most critical rules                        <-- End

这利用了注意力中的「首因与近因」效应。

Temperature、采样与 Agent 行为

语言模型生成文本时，并不只选单个最可能的下一个 token。它从所有可能 token 的概率分布中采样。控制采样的参数对 Agent 行为影响很大。

Temperature

Temperature 控制模型输出的随机程度。

Temperature 0（或极低）：模型几乎总是选最可能的 token。输出确定、聚焦。
Temperature 1：模型按 token 概率比例采样。输出更多样、更有创意。
Temperature > 1：模型越来越随机。输出变得不可预测。

直观类比：

Temperature 0:    "The capital of France is Paris."
                  (Always the same answer)

Temperature 0.7:  "The capital of France is Paris, a city known for..."
                  (Slight variation in elaboration)

Temperature 1.5:  "The capital of France is historically rooted in..."
                  (More creative, potentially off-track)

Agent 该用什么 temperature

Agent 任务	推荐 Temperature	原因
工具选择	0 - 0.2	希望确定性、正确的工具调用
数据抽取	0	精确答案，不需要创意
代码生成	0 - 0.3	正确性比多样性更重要
规划	0.2 - 0.5	一些灵活性有助于探索选项
创意写作	0.7 - 1.0	重视多样性与原创
头脑风暴	0.8 - 1.0	希望多样想法

对多数 Agent 用例，保持低 temperature（0 到 0.3）。 Agent 需要在工具使用、参数抽取与推理上做出可靠决策。高 temperature 会在你需要一致性的地方引入随机性。

Top-K 与 Top-P 采样

这些是控制模型如何选择 token 的额外参数。

Top-K： 只考虑最可能的 K 个 token。若 K=50，模型忽略 top 50 之外的所有 token。

Top-P（nucleus sampling）： 只考虑累积概率达到 P 的 token。若 P=0.9，模型考虑合计概率为 90% 的最小 token 集合。

Token probabilities: [0.4, 0.25, 0.15, 0.08, 0.05, 0.03, 0.02, ...]

Top-K=3:  Consider only [0.4, 0.25, 0.15]
Top-P=0.8: Consider only [0.4, 0.25, 0.15] (cumulative = 0.8)
Top-P=0.9: Consider only [0.4, 0.25, 0.15, 0.08] (cumulative = 0.88... round up)

对 Agent： 使用保守设置。Top-P 约 0.9、中等 Top-K 是合理默认。模型默认设置对 Agent 工作通常够用——temperature 是你最可能想调整的参数。

采样如何影响 Agent 循环

考虑需要决定调用哪个工具的 Agent。低 temperature 下，它会在给定情境中一致地选同一个（通常正确的）工具。高 temperature 下，不同运行可能选不同工具，导致行为不一致。

User: "What is the weather in Tokyo?"

Low temperature (0):
  -> Agent thinks: "I need the weather tool"
  -> Calls: get_weather(city="Tokyo")
  -> Consistent, predictable

High temperature (1.2):
  -> Run 1: Calls get_weather(city="Tokyo")
  -> Run 2: Calls web_search("Tokyo weather forecast")
  -> Run 3: Tries to answer from training data (no tool call)
  -> Inconsistent, hard to debug

对生产 Agent，确定性行为几乎总是你想要的。

ELI5：LLM 大脑如何工作

把 LLM 想成厨师

想象你在经营餐厅厨房，LLM 是主厨。

厨师的训练（模型训练）： 厨师花了数年研读成千上万本菜谱、看烹饪节目、练习菜式。他们没有逐字背下每道菜，但形成了关于什么味道搭配、什么技法适合什么食材、缺东西时如何即兴的深刻直觉。

Token 像食材： 厨师不会一下子想完整道菜。他们按单个食材与步骤思考。「先洋葱，再蒜，再番茄……」每个食材选择影响下一个。这就是 token 预测——每个 token 基于此前所有 token 被选出。

上下文窗口像台面空间： 厨师只能用厨房台面上放得下的东西。若台面巨大（100 万 token），可以同时看到很多食材、菜谱与准备工作。若台面小，就得收起东西腾地方，可能忘记刚才在做什么。

Temperature 像厨师的心情：

低 temperature：厨师专注、有条理。严格按菜谱。你每次点同一道菜，味道一样。
高 temperature：厨师感觉有创意。即兴、换料、试新东西。有时结果惊艳，有时很怪。

系统指令像餐厅定位： 「你是一家法式小酒馆。你用传统技法。你不卖寿司。」这塑造厨师的每个决策，而不必为每道菜重复。

工具像厨房设备： 厨师的知识 alone 不会把饭做熟。他们需要烤箱、炉灶、刀与量具。同样，LLM 的推理 alone 不会查数据或调 API。它需要工具。

Agent 循环像烹饪挑战节目： 厨师接到挑战（「为无麸质人士做三道菜」）。他们规划做法、开始烹饪、边做边尝、调味、装盘、评估结果。酱汁破了就排查并调整。那个「计划—行动—观察—调整」循环，正是 Agent 所做的。

综合起来：模型选择如何影响 Agent 质量

下面是一个这些概念在真实 Agent 场景中如何组合的实践例子。

场景：bug 分诊 Agent

团队希望有一个 Agent 阅读新 bug 报告、按严重度分类、分派给正确团队，并起草初步调查计划。

模型选择决策：

步骤	模型选择	理由
分类严重度（P0-P3）	Flash（轻）	标准清晰的简单分类
分派团队	Flash（轻）	基于组件的查找式决策
起草调查计划	Pro（重）	需要理解 bug、相关系统并建议诊断步骤

Temperature 决策：

步骤	Temperature	理由
分类严重度	0	必须确定——同一 bug 应总是同一严重度
分派团队	0	必须一致——同一组件应总是路由到同一团队
起草调查计划	0.3	轻微灵活性有助于生成更有用、更多样的调查想法

系统指令摘录：

You are a bug triage agent for the Platform Engineering team.

Severity classification:
- P0: Service is down or data loss is occurring
- P1: Major feature is broken, no workaround
- P2: Feature is impaired but a workaround exists
- P3: Minor issue, cosmetic, or improvement request

Team routing:
- Auth/login issues -> Identity team
- API errors -> Platform team
- UI issues -> Frontend team
- Database/performance -> Infrastructure team

When drafting an investigation plan:
- Start with the most likely root cause
- List 3-5 diagnostic steps in order of priority
- Include relevant log queries or dashboard links
- Note any recent deployments that might be related

此例说明：理解模型能力、设置合适参数、写清指令，都会贡献于可靠的 Agent。

在 Agent 中使用 LLM 的常见错误

1. 信任模型做数学

LLM 预测 token，不计算方程。对任何重要计算，使用代码执行工具。

Bad:  "Calculate the total cost of 47 items at $23.99 each"
      -> Model might say $1,127.53 (the correct answer is $1,127.53,
         but it got lucky - it often gets these wrong)

Good: Have the agent call a calculator tool or code execution tool
      -> calculate("47 * 23.99") -> $1,127.53 (guaranteed correct)

2. 假设完美记忆

模型只「记得」当前上下文窗口里的内容。若第 1 步的信息在第 10 步被截断，模型就不会记得。

3. 过度依赖单一模型

每一步都用前沿模型浪费金钱并增加延迟。用模型路由把模型能力与任务复杂度匹配。

4. 忽视系统提示

精心打磨的系统提示，可能是 Agent 50% 时间有效与 95% 时间有效的差别。投入时间撰写并迭代系统指令。

5. 不考虑幻觉

LLM 会自信地生成看似合理但不正确的信息。对任何重要事实，把 Agent 的回复锚定在工具结果上，而不是模型训练数据。

关键要点

LLM 是你 Agent 的推理引擎。 理解其能力与局限，是构建好 Agent 的基础。
Token、上下文窗口与注意力是三个关键概念。Token 决定成本与速度。上下文窗口决定模型能处理多少信息。注意力决定模型聚焦什么。
推理策略很重要。 Chain-of-Thought、Tree-of-Thoughts 与逐步分解，可大幅提升复杂任务上的 Agent 表现。
为每一步选对模型。 简单任务用更轻模型，复杂推理用更重模型。模型路由降低成本与延迟。
系统指令是控制 Agent 行为的主要杠杆。 仔细撰写、具体说明，并根据测试迭代。
对 Agent 保持低 temperature。 对生产 Agent 系统，确定性行为几乎总是更好。

接下来？

大脑很重要，但只能思考的 Agent 只是聊天机器人。下一课我们给 Agent 双手——让它与世界交互、调 API、搜网页、执行代码的工具。

下一课：第 3 课 - 工具：给 Agent 双手 -->

第 2 课：Agent 如何思考 - LLM 作为推理引擎

引言

LLM 作为 Agent 的大脑

LLM 擅长什么

LLM 做不到的事（没有帮助时）

语言模型如何处理信息

Token：语言的单位

上下文窗口：模型的工作记忆

上下文窗口探索器

Attention：模型如何聚焦

推理策略

Chain-of-Thought（CoT，思维链）

Tree-of-Thoughts（ToT，思维树）

逐步分解（Step-by-Step Decomposition）

模型选择：为任务挑选合适的模型

模型光谱

何时用什么

模型路由：不同步骤用不同模型

Google Cloud 模型选项

系统指令的角色

系统指令里写什么

例子：客服 Agent

写有效系统指令的技巧

顺序很重要

Temperature、采样与 Agent 行为

Temperature

Agent 该用什么 temperature

Top-K 与 Top-P 采样

采样如何影响 Agent 循环

ELI5：LLM 大脑如何工作

把 LLM 想成厨师

综合起来：模型选择如何影响 Agent 质量

场景：bug 分诊 Agent

在 Agent 中使用 LLM 的常见错误

1. 信任模型做数学

2. 假设完美记忆

3. 过度依赖单一模型

4. 忽视系统提示

5. 不考虑幻觉

关键要点

接下来？

评论