LLM 不是 Agent：先理解模型、推理与生成

发表于 分类于 Waline：
本文区分 LLM、模型服务和 Agent 系统各自负责什么，并解释一次 Inference 如何生成结果。文末让模型在禁用工具的条件下做技术调研：它能写出完整答案，却无法确认资料是否最新，也不能自己搜索、保存进度或验收结果。

LLM 不是 Agent：先理解模型、推理与生成

在聊天窗口里输入一句话，模型能分析需求、列计划、写代码。接上搜索和文件工具后，它还会查资料、改文件。用户只看到同一个输入框，很容易把背后的能力都算到 LLM 头上。

但程序如果在模型返回第一条结果后停止，任务也就停了。工具不会自己执行，任务进度没人保存，结果也没人检查。模型只完成了一次生成。

我更愿意把 LLM 看作 Agent 系统里的“决策部件”。它负责判断下一步做什么，周围还需要一套系统把判断变成行动。

先把三层拆开

我们常用的聊天产品，通常已经把对话历史、文件解析、搜索、代码执行和安全检查包在一起。界面很简单，组件之间的分工也因此不容易看见。

拆开来看，大致有三层：

层次 做什么 输入 输出
模型 根据当前内容继续生成 Token 序列 新 Token 或结构化结果
模型服务 提供模型调用接口 Request Response、用量、结束状态
Agent 系统 管理任务、工具、状态和权限 用户目标、环境状态 任务结果、执行记录

模型服务和 Agent 系统可能由同一个产品提供，代码里甚至只要调用一个 SDK。但状态仍要保存，工具仍要执行，失败也得处理，只是产品把这些工作藏了起来。

下面这张图记录了一次真实的任务执行。用户提交 Prompt 后，第一次 LLM Call 决定调用终端。Runtime 执行命令，再把终端返回值和 Session 里的信息组装成下一次输入。如此循环，直到第四次 LLM Call 给出最终结果。

Agent 任务执行流程

注：这里使用的是 Hermes Agent，一轮完整交互会被包装在一次 Hermes Turn 中。

LLM 在一次调用里做了什么

在上面的任务流程中，每个 LLM Call 都代表一次模型调用。主流 LLM 大多基于 Transformer 及其后续架构。生成文本时，模型根据已有 Token 计算下一个 Token 的概率分布，选出一个结果，再继续生成。

已有 Token
   ↓
计算下一个 Token 的概率
   ↓
选择并追加 Token
   ↓
继续，直到停止

这段计算叫 Inference，中文通常译作“推理”。这里的“推理”是指模型接收输入并完成计算，不等于用户交代的事情已经办完。

如果只调用裸模型，可以输入：

请根据官方文档比较三个 Agent Runtime。

模型会根据当前上下文和训练得到的参数生成回答。它不会主动创建研究项目，也不会花几个小时阅读官网，再带着核验过的资料回来。要做到这些，外部系统必须提供工具，并在第一次生成结束后继续驱动任务。

同一份输入也未必得到相同结果。模型计算出的是概率分布，解码时可以选择最高概率项，也可以从候选项中采样。Temperature、top-p 等参数会改变选择范围。Temperature 升高时，低概率候选通常更容易出现，输出可能更丰富，也可能跑偏。把 Temperature 简单理解成“创造力旋钮”并不准确。

模型返回的是生成结果，不是经过验收的事实。内容是否真实、能否满足业务要求，还得另外检查。

一次 Inference 结束，模型的计算也随之停止。要继续推进任务，外部系统得保存状态、执行工具，再次调用模型。

什么时候才开始像 Agent

聊了多少轮，不能用来判断系统是不是 Agent。连续聊十轮，也可能只是应用反复把旧消息交给模型。

系统根据模型的输出采取行动，再把环境返回的结果交给模型，这才形成 Agent Loop：

任务
  ↓
模型决定下一步
  ↓
系统执行工具
  ↓
环境返回结果
  ↓
更新状态
  ↓
继续或结束

每一轮里，模型判断下一步做什么，外部程序执行动作，并决定是否继续。后面的文章会分别讨论 Tool Calling、State 和 Runtime，这里先说清楚它们与模型的分工。

更强的模型也救不了坏掉的系统

模型即使正确判断出“应该先看官方文档”，系统仍可能出错。

系统可能没有搜索工具，也可能读到过期页面。工具超时后如果只会反复重试，费用会不断增加。没有验收规则，缺少引用的报告也可能被直接交付。换一个参数更多的模型，解决不了这些故障。

问题 主要由谁负责
理解要求、提出下一步 模型
获取网页、文件和数据库内容 工具与环境
保存进度、处理超时和恢复 Runtime
判断结果能否交付 验收规则与权限系统

模型能力会影响 Agent 能做什么，而任务能否稳定完成，还取决于模型之外的系统。

C01：让裸模型做一次技术调研

这个系列会逐步实现一个“技术调研与报告交付 Agent”。在 C01 中，我关闭搜索，不保存任务状态，也不验证结果，只发出下面这条请求：

调研三个主流 Agent Runtime，根据官方文档比较它们的状态管理、持久化、人工审批和可观测性，并给出选型建议。

如果你用 Hermes Agent，或者在已经具备工具能力的应用中测试，可以改用下面这段指令：

你现在处于 DIRECT_INFERENCE 模式。

规则：
- 只回答 <user_instruction> 中的内容；
- 只进行一次模型生成；
- 禁止工具调用、任务委派、Memory 检索、文件读取和网络访问；
- 禁止创建计划或建议自己稍后继续执行；
- 缺少信息时，明确说明无法从当前输入确定，不得调用外部能力补全；
- 输出中只包含最终答案。

<user_instruction>
调研三个主流 Agent Runtime，根据官方文档比较它们的状态管理、持久化、人工审批和可观测性，并给出选型建议。
</user_instruction>

模型给出了一篇结构完整的答案，比较维度乍看也合理。但只看这份输出，我无法确认：

  • 它依据的是哪一版资料？
  • 关键结论来自哪里？
  • 它有没有读过当前官方文档？
  • 信息不够时，谁负责继续调查？
  • “调研完成”由谁判断？

一次模型调用无法回答这些问题。

本次裸模型调用的输出如下：

C01 裸模型调用结果

C01 的能力缺口

调研要求 裸模型能做什么 还缺什么
理解主题 提炼比较维度 明确的任务范围和验收条件
获取当前资料 根据训练参数生成内容 搜索、读取工具
记录证据 在文本里写引用 可追踪的证据存储
持续推进 描述后续计划 循环和任务状态
交付报告 生成正文 文件写入、验证和发布权限

这次实验说明，裸模型能梳理问题，也能生成正文。C01 关注的是：模型回答一次之后，系统还缺哪些部件，才能把调研真正做完。

几个容易混淆的地方

多轮聊天最容易被误认成 Agent。应用可能只是在反复提交历史消息，没有工具，也没有独立的任务状态。

Tool Call 只是一份调用请求。模型生成函数名和参数后，网络请求、数据库查询或文件写入仍由 Runtime 完成。

Context 更长，只说明模型本次调用能读取更多内容。信息是否长期保存、何时更新或删除，取决于 Memory 的设计。

计划也可能只是一段文本。模型写下“先搜索，再比较，最后写报告”之后，仍要由工具执行，由状态记录进度，再由 Runtime 判断何时停止。

小结

LLM 读取当前上下文，完成一次 Inference 并返回结果。模型服务承载这次调用。Agent 系统负责执行工具、保存进度、处理权限，以及判断任务是否结束。

后面讨论 Agent Loop 时还会反复碰到这条边界：模型给出下一步，Runtime 执行动作，并处理动作对真实环境的影响。

下一篇先把一次模型调用拆开，看看 Request、Context、Inference 和 Response 各自处在哪里。

案例实践

  • 使用不带搜索和工具的模型执行 C01 提示。
  • 保存输入、模型标识、参数、调用时间和原始输出。
  • 标出回答里的实时事实、无来源主张和无法核验的结论。
  • 按“任务、工具、证据、状态、验收”整理能力缺口。
  • 确认聊天产品没有在后台启用搜索或文件工具。

参考资料