Day 02 - The Role of the LLM Inside an Agent

今日目标

能区分模型能力与系统工程能力，说清 LLM 在 Agent 中的决策、推理与生成职责。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读第 1 章模型能力与工具调用决策部分，只抓问题、思路、结论。
25-45 分钟	实践任务	完成「工作流程分工表」，把 LLM 步骤与工具/代码步骤分开。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
LLM	大语言模型：Agent 的决策与语言推理核心，负责理解、推理、规划、生成。	判断下一步该查日志还是该总结
reasoning	推理：基于上下文做逻辑推导、得出结论的能力。	从 P95 升高推断可能的上游瓶颈
planning	规划：把目标拆成有序步骤，决定先做什么、后做什么。	先查时间窗口，再查日志，最后下结论
generation	生成：把推理结果转成自然语言或结构化输出。	把指标变化写成 Markdown 日报段落
tool-use decision	工具调用决策：模型判断是否需要工具、调用哪个、参数是什么。	数据不足时决定调用 query_metrics
tool execution	工具执行：由工程层真正运行工具代码并拿回结果。	执行 SQL 查询并返回结果集
native agent capability	模型原生能力：模型不借助工具就具备的推理、对话、格式化能力。	归纳缺陷描述、改写报告语气
model capability vs engineering	模型能力与工程能力的边界：有的靠模型、有的必须靠代码。	算平均数靠代码，解读趋势靠模型
orchestration	编排：工程层把多轮「模型调用 + 工具调用」串成完整流程。	循环调用工具直到拿到全部数据
cost-latency trade-off	成本与延迟权衡：更强模型更贵更慢，按任务复杂度选型。	简单格式化用轻量模型，复杂分析用强模型
function calling	函数调用：模型以结构化参数请求调用外部函数的机制，是工具调用决策的载体。	模型发出「调用 query_metrics(start=10:00, end=11:00)」请求
hallucination	幻觉：模型生成与事实不符内容的倾向，是决策与生成环节的主要风险。	模型编造不存在的错误率数值

阅读重点

对应章节：第 1 章中关于模型能力、原生 Agent 能力、工具调用决策的部分。
关注点：
LLM 在 Agent 中承担的三类能力：决策、推理、生成，各自的输入输出。
工具调用决策（模型负责）与工具执行（工程层负责）的分工边界。
为什么搜索、数据库查询、代码执行不能只靠模型本身完成。
模型更强不等于 Agent 更强：上下文质量、工具质量、编排同样决定上限。
补充材料：
Anthropic 官方文档 Tool Use 章节，看工具调用决策与执行的完整流程。
OpenAI Agents SDK 文档中关于 tool calling 与 agent loop 的说明。

理解检查

LLM 在 Agent 中主要承担哪三类能力？各举一个测试场景的例子。
为什么搜索、数据库查询、代码执行不能只靠模型本身完成？
「工具调用决策」和「工具执行」有什么区别？分别由谁负责？
一个模型更强，是否一定代表 Agent 更强？为什么？

实践任务

背景：你每周都要生成性能测试报告：导数据、算指标、对比基线、写结论。手工流程耗时且容易漏指标。现在选一个你熟悉的工作流程（可用性能测试报告生成），把每一步标记为「适合 LLM」或「必须靠工具/代码」。

步骤：

写下工作流程名称与目标。
把流程拆成 5-8 个步骤，每步只做一件事。
给每步打标签：LLM / 工具代码 / 混合，并写一句理由。
单独标记成对的「决策 + 执行」，例如「决定查哪个指标（LLM）→ 执行查询（代码）」。
总结边界原则：什么类型的事交给 LLM，什么必须交给代码。
产出：一张分工表，保存下来，Day 03 拆解任务时继续用。

输出模板

工作流程：[xxx]
流程目标：[一句话]

| 步骤 | 具体动作 | 由谁完成 | 为什么 |
|---|---|---|---|
| 1 | [动作] | LLM / 工具代码 / 混合 | [理由] |
| 2 | [动作] | LLM / 工具代码 / 混合 | [理由] |
| 3 | [动作] | LLM / 工具代码 / 混合 | [理由] |

总结：
- LLM 擅长：[列举 2-3 项]
- 必须靠工具/代码：[列举 2-3 项]
- 成对的决策与执行：[举例]
- 边界原则：[一句话]

示范输出

工作流程：性能测试报告生成
流程目标：压测结束后自动产出可归档的性能报告

| 步骤 | 具体动作 | 由谁完成 | 为什么 |
|---|---|---|---|
| 1 | 从压测平台导出原始指标 CSV | 工具代码 | 需要精确读取文件，模型无法直接访问 |
| 2 | 计算平均响应时间、P95、错误率 | 工具代码 | 数值计算要精确，模型算术不可靠 |
| 3 | 对比本次与上次基线，找出明显变化 | 混合 | 变化阈值用代码判定，变化原因解读交给模型 |
| 4 | 把指标变化总结成结论 | LLM | 需要自然语言归纳与领域理解 |
| 5 | 生成 Markdown 报告并归档 | 工具代码 | 格式模板由代码保证，避免输出不规范 |
| 6 | 发送报告给干系人 | 混合 | 发送动作由代码执行，内容措辞由模型生成 |

总结：
- LLM 擅长：归纳结论、解释原因、调整语气、回答追问
- 必须靠工具/代码：读文件、算指标、查库、写文件、归档
- 成对的决策与执行：步骤 3 中变化阈值由代码判定，变化原因解读由模型完成
- 边界原则：先拿准数据，再让模型说话

追问练习

什么时候需要更强模型，什么时候需要更好的工程编排？各举一个场景。
如果工具返回了错误数据，模型能否发现？这说明了模型能力的什么局限？
工具调用决策错了（例如参数填错），应该由谁兜底：模型重新决策，还是工程层校验？
你的流程里哪一步最容易把「模型能力」错当成「系统能力」？

常见误区

把 Agent 的成败全归因于模型：上下文、工具、编排的缺陷同样会导致失败。
让模型做精确计算：算术、统计、时间计算应该交给代码或计算工具。
混淆「工具调用决策」与「工具执行」：模型只负责决定，执行、容错是工程层的职责。
一上来就用最强模型：成本与延迟可能翻几倍，而简单任务收益不明显，要按任务选型。

进阶扩展

生产系统靠执行轨迹分析模型在哪一步判断失误：是决策错、参数错，还是上下文信息不足。
模型选型是 cost-latency trade-off 工程：轻量模型做格式化与抽取，重型模型做复杂推理。
原生能力也有边界：即便模型支持 JSON 输出或 function calling，工程层仍要做校验兜底。

今日作业

保存分工表，明天拆解任务时把它当输入。
用一句话写出「模型能力与工程能力」的边界原则，明天开始前复述。
记录 1 个「模型擅长」和 1 个「模型不擅长」的真实工作案例。
想清楚你工作中哪一步曾被模型「一本正经地算错」，明天讨论。

自检清单

我能说出 LLM 在 Agent 中承担的三类能力。
我能解释工具调用决策与工具执行的区别。
我能区分模型能力与系统工程能力。
我能说明为什么精确计算必须交给代码。
我知道明天要复习哪一点。