chat_completion 和 responses 的差异与迁移价值

我们这里探讨一下为什么 codex-cli 这么做。可能从 codex 官方仓库的 issue 入手。

以及分辨一下这两个主要区别，以及迁移价值，会给我们的 XnneHangLab 带来哪些好处？

Anthropic Messages 和 OpenAI 的流式 Tool 回复的差异

以及召回一下以前在碎碎念里留下的疑问：

1
可以探究一下为啥 anthropic 协议支持 tool token 和 chat token 交替，而 openai 只能先 tool 后 chat ，但是似乎用提示词注入又可以让它预告自己要执行的 tool。
2

3
它预告时是否得到了完整的 tool schema? 以及它是在哪一次 LLM call 进行预告?

这里或许不够准确。这个疑问是这样的场景：

我们给桌宠陪伴场景加了 ToolCall 后，不仅 ToolCall 会带来一次额外的 LLM，而且等待 Tool 执行的时间通常还不短，并且还得把 Tool 执行的结果再发给 LLM 进行回复，这个过程中，体感上增加了五六秒的回复延迟。而且这个过程模型显得异常 沉默。

当时我设计给它加入了一个 policy 级别的提示词注入插件: pre_tool_preview

大致就是告诉模型说，嘿，如果你要执行 tool 了，请在执行前口头预告一下你要执行的内容。

之后模型也确实会在做各种事情来一句简短的预告 让我截图看看你在做什么？、让我翻找一下最近的日记内容。

整体效果不错，缓和了原本那段如果死亡一般的寂静沉默。

为什么我的 pre_tool_preview 可以生效？它的限制是什么？

我有点忘了当时的具体实现细节了，需要再次确认。另外，我需要 token 级别的 streaming token 演示，token 是如何交替的，这个预告发生在 tool token 前还是 tool token 后。为什么可以先预告再执行再回答。它中间经过了几次 LLM Tool Call。

以及它可以预告几次？是否支持长 tool call 链条的分段预告？

如果我迁移到 Responses，这个特性会被继承吗？ Responses 会改变 Token 流的返回过程吗？

另外我室友说 Responses 支持长连接是真的吗？是否可以省掉我桌宠对话过程中握手带来的那部分首字延迟？

以及当时为什么我会说 Anthropic 支持边说边做，而 OpenAI 不行？它们在 Streaming Token 流上有什么区别吗？

工程上如何让 Agent 边说边做？

我们了解到 pre_tool_preview 大概只是最初级的做法。

而在工程上，经常会看到某些 Agent 支持长链的 Tool Call，比如 Obsidian-yolo。

这中间大致是高频的 Tool Call 和反馈。它是的提示词是如何编写的。是如何让模型支持长链往返的，这似乎有些违背了我最早对于 chat_completion 的认识。因为这中间看上去似乎没有多次握手？

多次握手大多发生在什么时候？

大致就是这些疑问。接下来我们来请教 Fable 老师，或者 Opus 老师，请老师不要仅仅只依赖自己的学识回答，这里很多涉及到的东西要有依据。最好是 codex 或者 newapi 官方仓库的 issue ， Athropic 和 OpenAI 的文档来背书。

总结和吐槽一下 openai

okay，所以呢，这边很清晰了。

openai 只是自己不想继续在 codex 里面维护两套逻辑 (chat_completion + responses) 于是乎当方面砍掉了 chat 接口。为的是更敏捷的开发和快速迭代。砍掉了那些不为 openai 实际付费的人（第三方模型 provider 支持），被社区骂了很久。

但实际上，它非常左右脑互博，它前脚刚刚把 chat_completion 砍掉，后续又在近期把 ChatGPT 和 Codex 两个客户端合并在了一起，搞成了和 Claude Desktop 一样的架构。

而我们前面聊过 以坏架构为鉴：Claude Desktop 五套定时系统反映出来的 cowork 和 code 分离架构的弊端。这个架构会让维护成本几何倍的上升，分开维护比合起来维护好得多。而且最近 memU 这边的 host 适配的时候， Claude Desktop 和 Codex Desktop 也因为它们的 Cowork 和 Chat 的各种离奇沙箱和低 shell 权限表现出非常糟糕的适配性。

前脚操作像是追求技术整洁，后脚又把架构变成屎山。（虽然两者代码不一定都在 codex 官方仓库莉维护，也许 core 是独立维护的，和 claude code 一样，桌面端独立）。

这大概都是商业化的追求，然而，这追求的我看不懂，决策也看不懂。

而且 openai 永远是这样，喜欢一下子做两件事情而不是一件事情做到最好，更新 gpt 模型的同时，跑去分化 codex 模型，分化 o1、o2 、o3 。然后最后又把 codex 扔掉了只做 gpt。期间命名也是一团糟，简直是想到什么命名什么。而且 5.1、5.2、5.3、5.4 更新频率跟窜了一样。结果这一阵子下来绝大多数人体感最佳模型是 5.2。5.4 这边讲话跟人机一样，而且信息冗余度很高，杂乱无章，ADHD 患者看了一大段一句话都看不进去。

而 claude 这边对于模型追求的始终是数学、编码、逻辑能力。命名迭代严谨且浪漫，希腊神话来着。而且换名字的时候是真的有重磅更新，比如 Fable。

而 GPT 目前就 5.6 sol 、terra 可以用。5.6 以下充斥着混乱无秩序以及不信任感。

我看不懂 openai，为什么一手好牌能打这么烂。也看不懂 codex，估计他们自家员工也是，都建议大家把 5.6 接到 claude code 里最好用 XD。

需要注意什么，当前没有迁移价值，只有迁移风险

我们更在意的，其实是迁移价值。

但是看起来 newapi 当前对于 responses 的原生支持和转换很烂，还有很多技术债。只是简单保证回复能通不出错，真正的特性几乎一个没有继承过来。反而阉割掉了不少东西。

目前绝大多数人还接触不到真正 respones api，也就是说当前我们接着用我们的 chat_completion 就很好了，newapi 在这方面的支持已经沉淀了三年以上了，没必要赌着去换 responses。

再次吐槽

我大概看懂了。

它把之前 choices[0].message.content 那套非常变态的数据结构变得像 pydantic 可校验的白盒子。以及把以前写流式非常多 type unknown error 改成了原生支持。

我以前刚刚接触 openai 那个库的时候就觉得，一个 pypi 包，这么多人用，怎么能写得全是 pyright error，得加那么多 type。它在类型强校验上简直就是一团糟。如果仅仅看一小段代码，可能根本看不出来这段代码返回的是什么内容，因为什么内容都套在 content 的壳里面。

一个那么大的公司，数据结构怎么会设计的那么潦草。

当时我在支持 FastMCP 的时候，最大的难关就是 openai 的 chat_completion 带给我的，它的 Tool Call 看得真是让人心力交瘁。后面我直接把 FastMCP 砍掉了，心情大爽。

但是，responses 就真的设计好了吗？数据结构真的就校验干净了吗？我不信。我对 openai 充满了不信任感，他们以往各种粗糙的、不讲理的、混乱无秩序的做派让我感觉这就是一个草台班子。

边说边做的困惑

我需要你回答我上面的那个问题。

为什么当时 claude 告诉我， anthropic messages 的设计才能真正满足我需要桌宠边说边做的需求，Openai 的协议只能先全部执行 Tool 然后回复。但是我在实际注入那个 pre_tool_preview plugin 后也看到它能够在执行 Tool 前给出预告。

我忘记实现细节，可能需要你确认: XnneHangLab

Opus

当时那句话半对半错。Anthropic 确实原生就边说边做，但 OpenAI 也不是“做不到”——它是“表达不了多段”。你的插件没有突破协议，它只是用上了协议本来就允许、而模型默认不用的那个字段组合。

Anthropic：边说边做是官方例子里的默认行为

官方流式文档的 tool use 例子，逐字是这样的：

1
content_block_start  index:0  {"type":"text"}
2
content_block_delta  index:0  "Okay" "," " let" "'s" " check" " the" " weather" ...
3
content_block_stop   index:0
4
content_block_start  index:1  {"type":"tool_use","name":"get_weather"}
5
content_block_delta  index:1  {"type":"input_json_delta","partial_json":"{\"location\":"}
6
content_block_stop   index:1
7
message_delta                 {"stop_reason":"tool_use"}

模型自己先说了“好，我来查一下旧金山的天气”，再发 tool_use——没有任何提示词注入。 这就是你花力气用插件换来的效果，在 Anthropic 那边是文档首例。

而且它的 content 是有序 block 数组，index 就是最终数组下标。web search 那个例子更夸张：text(0) → server_tool_use(1) → tool_result(2) → text(3) → … 一路到 index:17——一个 message 里文本和工具真正多段交替。

OpenAI：能说一次，但表达不了多段

chat completions 的 assistant message 是 content（一个字符串）+ tool_calls（数组）两个并列字段。所以：

• 一段预告 + 一批 tool call → 完全合法。 你的插件生效不是 hack。
• 说→做→说→做 → 表达不了。 只有一个 content 字符串，没地方放第二段。

还有个更隐蔽的：顺序信息在回存时丢了。 流式过程中你确实先收到 delta.content 再收到 delta.tool_calls（自回归，生成顺序即到达顺序），但组装成 message 之后变成两个平级字段——下一轮模型看到 {content: "让我截图看看", tool_calls: [...]}，结构本身不再告诉它“我是先说后做的”，只能靠语义猜。Anthropic 的 index 是结构性保留的。

你的实现（我读了仓库，确认如下）

疑问	答案
注入在哪	type = "policy"，injection_position = "before_tools"，priority = 10。走 PolicyPlugin.get_prompt_segments() → SystemPromptBuilder.build()，注入进 system prompt，在 tool 定义之前
什么时候注入	AgentFactory.create_core_with_profile()，建 agent 时一次性注入，不是每轮 hook
预告时有没有完整 tool schema	有。 提示词在 system prompt 里，tools 通过 stream_with_tools(tools=tools_schema) 完整传给 API——同一次请求
在第几次 LLM call 预告	就是决定调用 tool 的那一次，不是额外一次。 预告 token 和 tool_call token 来自同一个 completion
预告在 tool token 前还是后	前。 core.py 的循环里 delta.content 先到、累进 text_buf 并直接 yield 给用户；delta.tool_calls 后到、累进 tool_calls_buf
能预告几次	一轮一次（只有一个 content）。但 max_rounds = 6，每轮一次 → 最多 6 段
长链分段预告	支持，粒度是“每轮一段”，不是“一轮内多段”

关键那段组装代码，正是“一个 message 同时带预告和 tool_calls”：

1
assistant_payload = {
2
    "role": "assistant",
3
    "content": text_buf or None,   # ← 预告文本落在这里
4
    "tool_calls": [...],
5
}

所以你早就在用协议允许的合法组合，只是模型默认不这么干，需要你的提示词把它叫出来。

那“OpenAI 不行”错在哪、对在哪

	Anthropic Messages	OpenAI Chat Completions
一轮内说一次再做	✅ 原生默认	✅ 可以，但要提示词诱导
一轮内多段交替	✅（server tool 可到 index 17）	❌ 只有一个 content
顺序结构性保留	✅ index	❌ 两个平级字段
跨轮分段预告	✅	✅（你的 6 轮）

对的部分：Anthropic 是原生行为 + 支持一轮内多段交替，OpenAI 两条都不占。 错的部分：“OpenAI 只能先全部执行 Tool 然后回复”——不对，它一轮内说一次是协议允许的，你自己的插件就是证据。

真正的差距其实在 client tool 场景下并不大（Anthropic 遇到 client tool 也是 stop_reason: "tool_use" 收尾，一轮一段）。多段交替的真正来源是 server tool——工具在服务端执行，控制权不回客户端，所以能在一个 message 里连着 text→tool→result→text。chat completions 没有 server tool，所以永远做不到。这也正好是 Responses 补上的那块。

额外了解

我想了解两点。

a. Anthropic Message 和 OpenAI 都是两者严格交替串行吗？即预告的 message token 发完前不会做任何的 Tool Call token 的发送。 b. 为什么 OpenAI 协议不支持交替？是模型输出的限制吗？大多数模型有这样的限制吗？还是说只是纯粹协议写得垃圾了？

Opus

a：是，两家都严格串行，“交替”这个词从一开始就用错了。b：纯协议问题，不是模型限制——而且证据就在 openai 自己的 SDK 类型里。另外你上面那个例子的锅可能不在协议，在你自己的提示词，见最后一节。

a. 都是严格串行，没有 token 级交替

Anthropic——官方流式文档把流程写死了：

A series of content blocks, each of which has a content_block_start, one or more content_block_delta events, and a content_block_stop event.

即 block 0 收完 content_block_stop 才会有 block 1 的 content_block_start。官方例子里 "Okay, let's check the weather..." 的最后一个 text_delta 到达后，先 content_block_stop index:0，才 content_block_start index:1 开 tool_use。不存在 text_delta(0) 和 input_json_delta(1) 混在一起流的情况。

OpenAI——自回归生成，delta.content 先到、delta.tool_calls 后到，同样串行。

所以准确的说法是：两家都是 [文本 token 段][工具 token 段] 顺序拼接，区别只在能拼几段。

	能拼的形状
Anthropic	[文本][工具][文本][工具]…（server tool 例子里到 index:17）
OpenAI chat	[文本][工具] —— 就这一组

“交替”应该改叫“分段”。 你原来的疑问“tool token 和 chat token 交替”想问的其实是分段能力，不是 token 混流——后者两家都没有，也不该有（客户端没法渲染半句话里插一个工具调用）。

b. 是协议，不是模型——证据在 openai 自己的类型定义里

证据一：同一个模型，换协议就能多段。 gpt-5.x 在 Responses 下 output 是 typed item 数组，message → function_call → message → function_call 完全合法；同一个模型走 chat completions 就做不到。模型没变，协议变了，能力就变了。 这一条直接排除“模型输出限制”。

证据二：openai-python 里的不对称，非常刺眼。

1
# 出参（模型吐给你的）— chat_completion_message.py
2
class ChatCompletionMessage(BaseModel):
3
    content: Optional[str] = None          # ← 一个字符串
4

5
# 入参（你回传的）— chat_completion_assistant_message_param.py
6
ContentArrayOfContentPart: TypeAlias = Union[
7
    ChatCompletionContentPartTextParam,
8
    ChatCompletionContentPartRefusalParam,  # ← 只有 text 和 refusal
9
]
10
content: Union[str, Iterable[ContentArrayOfContentPart], None]

两件事同时成立：

1. 入参侧 assistant content 已经能是数组了，出参侧还是 string。 数组这个形状在协议里是存在的，只是从没扩展到模型输出侧。
2. 就算是那个数组，成员也只有 text 和 refusal，没有 tool_call part。 所以哪怕你手动构造，也放不进一个“文本→工具→文本”的有序序列——tool_calls 永远是另一个平级字段。

这就是问题的根：不是“没做数组”，是“数组里没有工具”。 顺序信息在协议里没有任何一个位置可以承载。

证据三：chat completions 是三家里的异类。 Gemini 的 Content.parts 也是混合数组，官方文档甚至专门警告：

the model may return a mix of functionCall, toolCall, and toolResponse parts in a single turn. Don’t assume the functionCall will always be the last item in the parts array.

——这句话等于明说“文本可以排在 functionCall 后面”。Anthropic 有序 blocks、Gemini 有序 parts、Responses 有序 items，只有 chat completions 是两个平级字段。

那到底是不是“写得垃圾”

不是垃圾，是没重构的历史包袱。 content: str 在 GPT-3.5 时代完全合理——一轮就只可能吐一段文本。2023 年加 function calling 时，加一个平级 tool_calls 字段是向后兼容的，把 content 从 string 改成有序数组不是——那会炸掉当时所有读 choices[0].message.content 的客户端。

于是就锁死了：多模态输入侧后来补了数组（因为那是新字段、新形状），输出侧永远是 string。Responses 之所以要另起一个端点而不是给 chat completions 加参数，根本原因就在这——这个改动没法兼容，只能换协议。 这也回过头解释了前面那节codex 为什么必须硬删而不是软兼容。

最后：你上面那个例子，锅可能在你自己

你说“第一次预告后用户就失去感知”。但跨轮不受多段限制——第二轮的 assistant message 有自己的 content 字段，再预告一次完全合法：

1
round 1: {content: "我来读一下日记。", tool_calls: [read_diary]}
2
round 2: {content: "日记是空的，我查一下记忆。", tool_calls: [read_memory]}   ← 协议完全允许
3
round 3: {content: "我发现…"}

那为什么没发生？看你自己 pre_tool_preview 注入的第五条：

“如果是本轮首次工具调用，且用户能够感知等待，优先输出这条前置说明。”

“本轮首次”这四个字，模型很可能理解成了“一个用户 turn 里只预告一次”。 你观察到的行为和这条提示词高度吻合。

建议先做个对照实验：把那句改成“每次发起工具调用前都输出前置说明；如果与上一条重复则换个说法“，看看第二段预告会不会出现。如果出现了，说明你的长链失声是提示词写的，不是协议限制——这比协议问题好修一万倍。

（顺带修正上一节的表述：那里说“一轮一次、最多 6 段”是对的，max_rounds = 6 给了你 6 段预算；真正卡住你的不是段数上限，是这条提示词把预算用掉了 1 段就停了。）

卧槽！

噢我终于搞懂了，也就是说我一直以来只能看到一段预告是因为我自己的提示词！

并且，openai 协议在 tool loop 里其实每段 tool call 都算独立且都能携带一个预告消息？

这对我非常重要，也就是我后续要追求的工程上消除长 tool 链静默的问题。原本我打算把一条 tool 链 break down 到多步，但现在看起来似乎不用了！

是这样的吗？

也就是说我只要改善提示词，并加上一些护栏就可以了。不用搞很复杂的实现？

Opus

大方向对，但先别急着高兴——有三处必须校准，其中第二处是我的责任。

修正一：是“每轮一个”，不是“每个 tool 一个”

你的 core.py 里这两行说明问题：

1
max_rounds = 6                                    # 503
2
*(_exec_tool(tc, ...) for tc in ordered_tool_calls)   # 606，并行执行

一轮（一次 LLM call）里模型可以一次吐出 N 个 tool_calls，你并发跑掉。 这一轮只有一个 content 字段 → N 个工具共享 1 条预告。

所以准确说法是：预告的粒度是「每次 LLM call 一条」，不是「每个 tool 一条」。

要一对一，得把 parallel_tool_calls: false 传给 API（chat completions 的标准参数，openai-python 里有类型）。但这是拿延迟换感知——本来并行 3 个工具 5 秒，串行就变 15 秒。大多数情况不值，一条预告覆盖“我要同时查日记和记忆”完全够用。

修正二：我那个诊断是假设，不是结论

上一节我说“锅在你的提示词”，那是读代码得出的高置信度推断，我没有跑过你的 agent。别把它当已验证事实——请务必先跑对照实验。

而且即使提示词改了，还有第二个阻力：模型本身在拿到 tool_result 之后就是倾向于直奔下一个 tool call。这个倾向的可塑性因模型而异，你桌宠上跑的那些（deepseek / grok 一类）比 frontier 模型更硬。

所以现实预期是：改提示词 → 大概率有明显改善，但不一定每轮都稳定出现。 做好“部分生效”的心理准备，别一次改完就当解决了。

修正三：预告消不掉 tool 执行本身的静默

这条最容易被忽略。预告覆盖的是 LLM 决定调工具 → 工具开始跑 这个瞬间，不是工具执行那 3-5 秒。

所以真实效果是：

1
改之前： [说一句] ────静默 30 秒──── [回答]
2
改之后： [说一句]─静默5s─[说一句]─静默5s─[说一句]─静默5s─[回答]

是把一段长静默切成若干段短静默，不是消除静默。 体感改善巨大，但如果单个工具本身要跑 10 秒，那 10 秒依然是哑的——那部分只能靠你自己 UI 层的进度反馈（转圈、“正在读取…”），协议给不了。

那还要不要拆多步

如果目的只是消静默——不用拆。 你原本想的 break down 是在用工程手段模拟协议本来就有的能力，属于白干。

但有个硬上限要注意：max_rounds = 6。 长链一旦超过 6 轮就被你自己截断了。如果你要追求“长 tool 链不静默”，先把这个数调上去，否则预告能力再好也只有 6 段预算。

一个具体的提示词形状

别只写“调用前预告”，让每轮那句话同时收尾上一步、预告下一步——这正好就是你想要的形状：

每次发起工具调用前都先说一句话。如果这不是本轮第一次调用工具，这句话要同时做两件事：用半句话说明上一步的结果，再说明接下来要做什么。不要重复上一条的措辞。

对应的输出就是你写的那个理想例子：

1
我来读一下最近的日记。          ← 纯预告
2
[Read Diary] → 空
3
日记是空的，我查一下记忆。      ← 收尾 + 预告，一句话两件事
4
[Read Memory] → ...
5
我发现...                       ← 收尾

这个形状比“每步都预告”更自然，也更省 token——用户拿到的是连贯叙述，不是六条“让我看看…“的复读。