LLM Call 到底做了什么：一次推理，不是一次任务执行

发表于 分类于 Waline：
一次 LLM Call 会把当前上下文交给模型，完成一次推理并返回生成结果。它不是任务执行，也不会自行调用工具、保存状态或验收交付物。

LLM Call 到底做了什么：一次推理，不是一次任务执行

先给结论：一次 LLM call，只是在本次提供的 Context 上完成一次推理（Inference），并返回生成结果。

它可以回答问题、写代码、给出计划，也可以提出“应该调用哪个工具”。但它本身不会访问网页、修改文件、执行工具、保存进度或确认交付。那些动作要由调用模型的应用或 Agent Runtime 完成。

理解这条边界，是理解 Agent Loop 的起点。

先区分：任务、行动与一次调用

用户说“根据官方文档比较三个 Agent Runtime，并给出选型建议”，交付的是一个任务。要完成它，系统可能需要搜索资料、读取页面、记录来源、补充缺口、写报告并检查结论。

而一次 LLM call 只是这个过程中的一个计算步骤：应用把此刻已知的信息交给模型，模型据此生成下一段结果。

概念 它是什么 是否天然发生在一次 LLM call 中
任务 用户希望最终完成的工作 否
行动 搜索、读文件、写数据库等对环境的操作 否
LLM call 向模型服务发起的一次生成请求 是
Inference 模型基于当前 Context 计算并生成结果的过程 是

所以，模型说“我会先查官方文档”，只是生成了一项建议；只有外部系统真的执行搜索，环境才发生了变化。

一次 LLM call 内部发生了什么

一次调用有明确的起点和终点。应用先组装 Context，模型据此推理，模型服务再把结果返回。

应用组装本次 Context
          ↓
模型根据 Context 生成下一个 Token
          ↓
将该 Token 加入已生成内容，继续生成
          ↓
满足停止条件，返回 Response

这里的“推理”不是人类意义上的长时间思考，而是模型执行前向计算、不断选择下一个 Token 的过程。生成到停止条件（例如输出完成、达到长度上限）后，这次调用就结束了。

模型不会保留一个正在后台持续执行的“我”。下一次调用是否带上这次结果、是否加入新资料、是否继续做事，都由应用决定。

模型依据什么推理

模型只能依据本次 Context 中可见的信息生成。Context 通常来自多个地方：

  • 产品或开发者的指令；
  • 用户的当前问题；
  • 被选入的历史消息；
  • 工具定义、工具结果或文件片段；
  • 输出格式和生成参数。

这些内容被应用装入 Request 后送到模型服务。数据库里存着资料、聊天界面上曾出现过一句话，都不等于它们已经在本次 Context 中。没有被送入，模型就看不到。

同样的用户问题，在不同 Context、模型或生成参数下可能得到不同回答。这也是为什么排查“模型忘了要求”时，应先检查本次 Request，而不是只看聊天界面。

Response 表示什么，又不表示什么

Inference 结束后，模型服务返回 Response。它可以是文本、结构化 JSON，或一个 Tool Call 请求；通常还会带有调用 ID、结束状态和 Token 用量。

Response 表示：这次推理已经有结果。

它不表示：事实已经核验、工具已经执行、文件已经写入，或任务已经完成。

尤其要区分 Tool Call：模型返回 search_official_docs 及其参数时，仍只是一次生成结果。Runtime 必须检查权限、实际执行工具，并把结果作为新的 Context 再发起下一次调用；否则搜索从未发生。

Agent 为什么不等于 LLM

LLM 是生成与判断组件；Agent 是围绕它建立的执行闭环。

任务与当前状态
       ↓
一次 LLM call：判断下一步
       ↓
Runtime 执行工具或处理结果
       ↓
获得新的环境状态，决定是否再次调用
       ↓
达到验收条件后交付

这个闭环需要工具、状态、权限、重试和验收规则。模型影响“下一步判断”的质量；系统决定建议能否可靠地变成行动和交付。

示例：一次调用只能产出一次调研判断

下面是 C01 的最小示例。它刻意关闭工具和网络，只发起一次模型调用：

{
  "model": "gpt-5.6",
  "instructions": "你是技术研究助手。本次没有搜索、文件或记忆工具。不得声称已核验实时资料；信息不足时明确说明。",
  "input": [
    {
      "role": "user",
      "content": "比较三个主流 Agent Runtime，并给出选型建议。"
    }
  ],
  "tools": [],
  "max_output_tokens": 800
}

在这次 call 中，应用实际做的是：提交指令和问题；模型做的是：基于已有知识与这些约束生成比较框架、待确认项或初步建议；模型服务做的是：返回这份 Response。

它没有做的是：查阅官方文档、确认版本、保存证据、补齐缺失信息或发布报告。即便输出写得流畅，也只是一份未经外部验证的推理结果。

这个例子说明了本文的结论：一次 LLM call 可以为任务提供有价值的判断，却不是任务本身，更不是任务的自动完成。

小结

一次 LLM call 的边界很简单：应用提供 Context，模型完成一次 Inference，服务返回 Response。把 Response 变成行动，需要系统执行；把行动串成可交付的任务，需要 Agent Loop。

下一篇将把这条链继续拆开：Input 如何被组装成 Request，哪些信息真正进入 Context，以及 Response 包含哪些可供系统消费的内容。

案例实践

  • 以示例 Request 执行一次不带工具的 C01。
  • 保存 Request、Response、模型标识、参数、调用时间和原始输出。
  • 标出输出中哪些是推理判断，哪些主张仍缺少外部证据。
  • 将“下一步建议”与“已实际执行的动作”分开记录。

参考资料