ZXT / Runtime

Notes · · 10 分钟阅读

从「回答问题」到「完成任务」：大模型 API 正在进入 Agent 时代

大模型 API 经历了四个阶段——从文本续写、推理行动、聊天接口到任务执行。DeepSeek 支持 Responses API 是一个明确信号：模型厂商的竞争正在从「谁回答得更好」变成「谁能提供完整的 Agent 基础设施」。

AI Agent MCP 产品思考

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

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

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

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

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

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

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

大模型 API 的四个阶段

阶段一文本续写机2020阶段二推理+行动2022阶段三聊天接口2023阶段四任务执行2025

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

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

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

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

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

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

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

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

理解状态调用工具观察结果observe -. 更新判断

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 个条目的数组，完整记录了模型执行这次任务的每一步：

① 推理：先搜天气② 搜索：web_search_call ✅③ 推理：搜索结果时效性不一，需要打开可靠网站④ 搜索：多次调用，部分失败 ❌⑤ 推理：确认今天日期，获取实时数据⑥ 搜索：找到正确来源 ✅⑦ 推理：已获取数据，再核实官方信息源⑧ 输出：格式化天气报告

这 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 技术栈理解为分层结构：

Responses API描述一次任务如何运行ReAct决定推理与行动的循环MCP连接外部工具和数据模型理解、规划、判断、生成Agent 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 客户端兼容。

三条路径

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

OpenAI定义「任务如何执行」Responses + Agents SDK + CodexAnthropic定义「工具如何连接」Messages + Claude Code + MCP国内厂商兼容生态，成为可替换后端协议兼容 = 分发渠道

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 执行任务」的基础设施搭好了。 我们只是在合适的时间，站在了这个趋势上。