---
title: 从「回答问题」到「完成任务」：大模型 API 正在进入 Agent 时代
slug: llm-api-entering-agent-era
description: 大模型 API 经历了四个阶段——从文本续写、推理行动、聊天接口到任务执行。DeepSeek 支持 Responses API 是一个明确信号：模型厂商的竞争正在从「谁回答得更好」变成「谁能提供完整的 Agent 基础设施」。
date: 2026-08-06
published_at: 2026-08-06 11:00
category: Notes
tags:
  - AI
  - Agent
  - MCP
  - 产品思考
draft: false
featured: true
hidden: false
archived: false
---

最近重新用 ChatGPT 网页版时，会明显感觉到：它已经不太像过去那个「输入问题、返回文字」的聊天机器人了。

它可以搜索互联网、读取文件、分析数据、运行代码、调用外部工具、生成文档，甚至持续执行一个包含多个步骤的任务。

用户提出的也不再只是「帮我回答一个问题」，而更像是「帮我查资料、比较方案、得出结论，然后生成一份可以直接用的交付物」。

表面看是 ChatGPT 功能越来越多，但从底层看，真正发生的变化是：

> **大模型正在从一个文本生成模型，逐渐变成一个可以理解目标、调用工具、读取环境并完成任务的 Agent。**

最近 DeepSeek-V4-Flash 开始支持 OpenAI Responses API，并且可以直接接入 Codex，同时在 Responses API 中支持服务端 `web_search`——就是这个趋势中非常有代表性的信号。DeepSeek 官方明确表示，增加 Responses API 支持的直接原因之一，就是满足开发者接入 Codex 的需求。

这件事的意义不只是「DeepSeek 又兼容了一种接口」。它说明国内模型厂商的竞争范围，已经开始从「谁的模型回答得更好」，扩展为「谁能更好地支持 Agent 执行任务」。

## 大模型 API 的四个阶段

```d2
direction: right

s1: {
  label: "阶段一\n文本续写机\n2020"
  style.fill: "#1e1e2e"
  style.stroke: "#6C7086"
  style.border-radius: 8
}

s2: {
  label: "阶段二\n推理+行动\n2022"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

s3: {
  label: "阶段三\n聊天接口\n2023"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

s4: {
  label: "阶段四\n任务执行\n2025"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
  style.stroke-width: 3
}

s1 -> s2 -> s3 -> s4
```

### 第一阶段：模型是一台「文本续写机」

2020 年 6 月，OpenAI 发布最初的 API。核心抽象非常简单：

```text
输入一段文字 → 模型继续向后生成
```

这个阶段的模型不会主动搜索，不会调用工具，不会判断是否需要外部信息，也不会管理任务的生命周期。它只是根据前面的文字预测后面的文字。

### 第二阶段：模型开始学会「推理」和「行动」

2022 年出现了两个重要概念。

**FIM（Fill-In-the-Middle）**——让模型不仅能从左向右续写，也能根据前缀和后缀补全中间缺失的部分。这对代码编辑器很重要，因为用户通常不是从头生成整个文件，而是在光标位置插入或修改内容。但 FIM 仍然属于「内容生成能力」，不是 Agent 协议。

**ReAct（Reasoning + Acting）**——让模型在推理和行动之间循环：

```d2
direction: right

think: {
  label: "理解状态"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

act: {
  label: "调用工具"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

observe: {
  label: "观察结果"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
}

think -> act -> observe
observe -.-> think: {
  label: "更新判断"
  style.stroke: "#6C7086"
}
```

ReAct 论文强调，将推理与行动交错进行，可以让模型通过外部知识库或环境获得新信息，减少单纯依赖内部知识产生的错误。

需要区分的是：**ReAct 是一种 Agent 运行模式，不是一种 HTTP API 协议。** 很多 Agent 框架内部的运行方式，本质上都是 ReAct 的变体：Think → Act → Observe → Think → Act。

### 第三阶段：聊天成为主流接口

2023 年，行业从 Completion 转向 Chat。OpenAI 推出 ChatGPT API，开发者传入的是由 `system` / `user` / `assistant` / `tool` 组成的 `messages` 数组。Anthropic 也形成了自己的 Messages API。

Chat Completions 最终成为兼容厂商最多的事实标准——DeepSeek、MiniMax、Kimi、GLM、Gemini、Mistral 等大量厂商都提供了兼容接口。

但这个阶段仍然是：**模型负责返回一条消息，开发者负责管理整个 Agent。** 搜索怎么做、工具怎么运行、历史怎么保存、失败怎么重试、任务怎么追踪，基本都要开发者自己实现。

### 第四阶段：API 开始描述一次「任务执行」

随着 Agent 发展，单纯用 `messages` 表达所有内容变得越来越困难。一次 Agent 任务可能包含：用户指令、模型推理、搜索请求、搜索结果、函数调用、代码执行、文件读取、再次推理、最终答案——如果都塞进 `assistant message`，接口会越来越混乱。

2025 年 3 月，OpenAI 发布 Responses API，把它定义为面向 Agent 的新 API primitive。

核心变化是把 API 的抽象从「生成一条回复」变成「执行一次任务」。一次 Response 中可以包含不同类型的 Item：

```text
reasoning          — 推理过程
message            — 文字消息
function_call      — 函数调用
web_search_call    — 搜索请求
file_search_call   — 文件检索
computer_call      — 电脑操作
custom_tool_call   — 自定义工具
```

流式输出也不再只是文字 Token，而是语义化事件——前端和 Agent Runtime 能明确知道：模型现在是在搜索、在调用工具、在输出答案、还是已经执行失败。

## 实测：一次 Response 到底长什么样

光说协议有点抽象。我用 DeepSeek-V4-Flash 的 Responses API 做了一个最简单的测试——让它查「北京今天的天气」，并开启了服务端 `web_search`。

请求的核心结构很简单：

```python
payload = {
    "model": "deepseek-v4-flash",
    "instructions": "你是一个能够联网搜索的助手。优先检索最新资料，并在回答中说明信息来源。",
    "input": "北京今天的天气",
    "tools": [{"type": "web_search"}],
    "tool_choice": "auto",
    "stream": False
}
response = requests.post("https://api.deepseek.com/responses", ...)
```

如果这是传统的 Chat Completions，返回的就是一段文字。但 Responses API 返回的 `output` 是一个包含 **27 个条目**的数组，完整记录了模型执行这次任务的每一步：

```d2
direction: down

s1: {
  label: "① 推理：先搜天气"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 6
}

s2: {
  label: "② 搜索：web_search_call ✅"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 6
}

s3: {
  label: "③ 推理：搜索结果时效性不一，需要打开可靠网站"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 6
}

s4: {
  label: "④ 搜索：多次调用，部分失败 ❌"
  style.fill: "#1e1e2e"
  style.stroke: "#F38BA8"
  style.border-radius: 6
}

s5: {
  label: "⑤ 推理：确认今天日期，获取实时数据"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 6
}

s6: {
  label: "⑥ 搜索：找到正确来源 ✅"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 6
}

s7: {
  label: "⑦ 推理：已获取数据，再核实官方信息源"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 6
}

s8: {
  label: "⑧ 输出：格式化天气报告"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 6
  style.stroke-width: 3
}

s1 -> s2 -> s3 -> s4 -> s5 -> s6 -> s7 -> s8
```

这 27 个条目分三种类型，交替出现：

| 类型 | 作用 | 本次数量 |
| ---- | ---- | -------- |
| `reasoning` | 模型的思考过程 | 7 |
| `web_search_call` | 服务端搜索请求 | 10（6 成功 / 4 失败） |
| `message` | 中间结论或最终回答 | 6 |

整个过程清晰地展现了 ReAct 循环——**但这次不是开发者写的循环代码，而是模型在服务端自主完成的。**

几个值得注意的细节：

1. **日期搞错了再纠正**：模型一开始不确定今天日期，经过几轮搜索后才确认是 2026 年 8 月 6 日，然后在最终回答里正确标注了。
2. **搜索会失败，模型会换路**：10 次搜索有 4 次返回 `failed`，模型没有卡住，而是推理「让我尝试其他来源」然后换关键词重试。
3. **会主动校验**：拿到数据后，模型推理「让我再核实一下官方信息源」，又发起了搜索。
4. **Token 消耗以推理为主**：本次共消耗约 4.9 万 Token，其中输出 2544 个里有 1358 个是 reasoning token——超过一半的输出花在了「思考」上。

这就是「第四阶段」和「第三阶段」最直观的区别：

> **Chat Completions 返回的是一段文字；Responses API 返回的是一次任务执行的完整过程。**

前端拿到这 27 个条目，可以渲染出「正在搜索」「搜索失败，换个方式」「已找到数据，正在核实」这样的实时状态——用户看到的就不是一个「正在思考」的转圈，而是一个正在干活的过程。

## MCP 补上了另一块拼图

Responses API 解决的是「如何描述和管理模型的一次任务执行」。

MCP 解决的是「Agent 如何连接外部工具、系统和数据」。

2024 年 11 月，Anthropic 开源 Model Context Protocol——用一种统一协议替代每个数据源都单独开发连接器的方式。

把目前的 Agent 技术栈理解为分层结构：

```d2
direction: down

responses: {
  label: "Responses API\n描述一次任务如何运行"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
}

react: {
  label: "ReAct\n决定推理与行动的循环"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

mcp: {
  label: "MCP\n连接外部工具和数据"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

model: {
  label: "模型\n理解、规划、判断、生成"
  style.fill: "#1e1e2e"
  style.stroke: "#CBA6F7"
  style.border-radius: 8
}

runtime: {
  label: "Agent Runtime\n状态、权限、重试、沙箱、记忆、调度"
  style.fill: "#1e1e2e"
  style.stroke: "#F38BA8"
  style.border-radius: 8
}

responses -> react -> mcp -> model -> runtime
```

它们不是互相替代的关系，而是处于不同层级。这和我前面几篇文章里聊的实践是呼应的——我之所以执着于把能力封装成 Skill、用 MCP 连接工具、让 Agent 自我迭代，正是因为整个行业都在往这个方向走。

## 国内厂商当前支持情况

以下状态基于截至 2026 年 8 月 6 日各厂商的官方公开文档。这里比较的是官方托管 API，不是模型在本地推理框架中的接口。

| 厂商 | Chat Completions | Anthropic Messages | Responses API | Codex 接入 |
| ---- | --------------- | ------------------ | ------------- | ---------- |
| DeepSeek | 支持 | 支持 | 支持（仅 V4-Flash） | 可直接接入，含服务端 Web Search |
| MiniMax | 支持 | 支持 | 支持（M3 可直连 Codex） | M3 可通过 Responses 直连 |
| Kimi | 支持 | 支持 | 暂未提供 | Claude Code 可直连；Codex 需协议转换 |
| GLM | 支持 | 支持 | 暂未见公开接口 | 通过 Chat 或 Anthropic 协议接入 |

### DeepSeek：协议最完整

DeepSeek 当前支持四种协议：Chat Completions、Anthropic Messages、Responses、FIM Beta。Responses API 目前只支持 `deepseek-v4-flash`，已支持 Function Calling、服务端 Web Search、Codex 所需的 `apply_patch`、Reasoning Item 和语义化 SSE 事件。

但仍是**部分兼容**——不支持 `previous_response_id`、`conversation`、`store`、File Search、Code Interpreter、Computer Use、Remote MCP。更准确的描述是：已经支持 Responses 的任务执行协议和 Codex 关键链路，但还没完整复制 OpenAI 的 Agent 平台。

### MiniMax：已支持 Codex 直连

MiniMax-M3 的 Codex 官方配置使用 `wire_api = "responses"`，可以直接用 Responses 协议接入 Codex，不需要额外的转换层。但通用 Responses API 的完整兼容范围，公开文档还没有 DeepSeek 那样详细。

### Kimi：模型有能力，API 还没跟上

Kimi 的主接口是 Chat Completions，已提供 Anthropic 兼容端点可直接接入 Claude Code。但 Codex 使用 Responses API，而 Kimi 目前提供的是 Chat Completions API，接入 Codex 需要本地协议转换。

这非常能说明一个问题：**模型具备 Agent 能力，与厂商提供 Agent 原生 API，是两件不同的事。**

### GLM：模型能力强，API 仍以 Chat 为主

GLM 当前官方支持 Chat Completions 和 Anthropic Messages 两种协议。模型本身已经强化了 Function Calling、长程 Agent 任务、工具协同、MCP、Coding Agent 等能力，但对外 API 还没有独立的 Responses 接口。

## 为什么 DeepSeek 支持 Responses 值得关注

如果只把 Responses 看成另一种 JSON 格式，这件事的重要性会被低估。它至少带来三个变化。

**第一，更容易进入 OpenAI 的 Agent 生态。** Codex 不是普通聊天客户端——它需要理解推理、Shell 命令、文件修改、`apply_patch`、工具返回、执行状态、任务完成。原生支持 Responses 后，DeepSeek 可以直接成为 Codex 的模型后端，减少中间转换和字段丢失。

**第二，搜索开始成为模型厂商的基础设施。** 过去 Web Search 是开发者自己完成的：模型生成关键词 → 开发者调搜索 API → 整理结果 → 传回模型。DeepSeek Responses API 支持服务端 `web_search`，搜索不再只是外部插件，而开始成为模型服务本身的一部分。

**第三，模型厂商开始承担更多 Agent Runtime 工作。** 传统模式下厂商只提供「输入 Token → 输出 Token」。现在开始向外扩张：模型推理、搜索、工具协议、任务事件、代码修改、状态管理、缓存、可观测性、Agent 客户端兼容。

## 三条路径

目前可以大致看到三条路径。

```d2
direction: right

openai: {
  label: "OpenAI\n定义「任务如何执行」\nResponses + Agents SDK + Codex"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
}

anthropic: {
  label: "Anthropic\n定义「工具如何连接」\nMessages + Claude Code + MCP"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

cn: {
  label: "国内厂商\n兼容生态，成为可替换后端\n协议兼容 = 分发渠道"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}
```

**OpenAI** 通过 Responses API、Agents SDK 和 Codex，试图定义 Agent 的一次运行应该如何表达——输入是什么、输出有哪些类型、工具怎么调用、事件怎么流式返回、任务什么时候完成。

**Anthropic** 通过 Messages、Claude Code 和 MCP，重点解决模型如何连接真实世界中的工具和上下文。MCP 正在逐渐成为 Agent 连接数据源和工具的重要开放标准。

**国内厂商**（DeepSeek、MiniMax、Kimi、GLM）都在积极兼容 OpenAI 或 Anthropic 协议。背后的商业逻辑很直接：支持 Chat Completions 就能进入大量现有应用；支持 Anthropic Messages 就能进入 Claude Code 生态；支持 Responses 就能直接进入 Codex 和新一代 Agent 生态；支持 MCP 就能连接标准化工具。

**协议兼容能力正在成为模型的分发渠道。** 模型即使能力很强，如果无法进入开发者正在使用的 Agent、IDE 和工作流，也很难获得真实调用量。

## 这对我的启发

前面几篇文章聊了我怎么用 Skill 改造工作流、怎么让 AI 读代码。这篇提供了一个更底层的视角：**为什么这些东西现在能成立？**

因为整个行业的基础设施已经到了「Agent 可以真正执行任务」的阶段。

这给我几个判断：

**1. 复杂任务应该按「一次 Agent Run」来组织，而不是「多轮对话」。**

普通的文案生成、摘要总结，继续用 Chat Completions 就够了。但像数据查询、方案评估、报告生成这种多步骤任务，更适合按照一次 Agent Run 来组织：理解需求 → 拆解任务 → 搜索 → 查询内部数据 → 调用多个 Skill → 核验 → 生成交付物。

**2. 前端不应该只展示「正在思考」。**

更有价值的是展示可被用户理解和验证的行动：「正在理解需求」「正在搜索目标信息」「正在查询内部数据」「正在核验结果」「正在生成报告」。这样用户感知到的就不是一个回答得比较好的聊天机器人，而是一个正在替我推进任务的数字同事。

**3. 不要把自己绑死在一个模型厂商上。**

各家厂商的 API 能力差异很大，而且都在快速变化。用模型适配层把 Responses、Chat Completions、Anthropic Messages 统一封装起来，才能在不同厂商之间灵活切换。

## 最终判断

DeepSeek-V4-Flash 支持 Responses API，不只是增加了一项接口能力。它代表模型行业正在进入一个新的竞争阶段：

```text
第一阶段：比模型能不能生成
第二阶段：比模型回答得好不好
第三阶段：比模型能不能推理和调用工具
第四阶段：比谁能提供完整的 Agent 基础设施
```

未来模型厂商的竞争，不会只看模型榜单。还会看：

- 是否支持主流 Agent 协议
- 是否可以直接进入 Codex、Claude Code 等生态
- 是否提供搜索、文件、代码执行和 MCP
- 是否支持长程任务
- 是否能管理完整的任务运行过程
- 是否让开发者更容易构建可靠产品

大模型的最终形态，可能不再是一个只负责回答问题的 API。它会逐渐变成：**一个可以推理、搜索、调用工具、读取环境、执行行动并交付结果的任务执行引擎。**

---

> 上一篇说「当业务知识被结构化沉淀进 Skill，产品经理和代码之间的那堵墙就真的被打通了」。
>
> 这篇想补一个更底层的判断：**这堵墙能被打通，前提是行业已经把「Agent 执行任务」的基础设施搭好了。** 我们只是在合适的时间，站在了这个趋势上。