当前主流大语言模型的交互方式,本质上是一封电子邮件:你写完发送,对方读完回复,中间有一段沉默的等待。Thinking Machines Lab——由 OpenAI 前首席技术官 Mira Murati 创立的新团队——最近发布的研究预览"交互模型"(Interaction Models),试图把这段等待砍掉,让人与 AI 的协作更像两个人面对面聊天:可以打断、可以补充、可以同时开口。
这个方向看似只是体验优化,实际上触及了 LLM 交互架构的底层假设。值得认真看看它到底在改什么,以及作为开发者可以怎么提前布局。
轮次制交互的隐性代价
几乎所有主流 LLM API 都遵循同一套协议:
用户输入 → 模型推理 → 返回完整文本 → 等待下一轮输入
这套协议的好处是简单——状态清晰、易于缓存、方便计费。但它在三个场景下会卡住:
- 长任务协作:让模型写一段 2000 字的分析,你只能等它写完才能说"第三段方向不对"。人之间不会这样——你看到同事写到第三段时就会插一句"这里换个角度"。
- 实时决策辅助:驾驶、手术、交易等场景需要模型在用户还在说话时就给出反馈,而不是等用户说完再开始推理。
- 多模态同步:语音+手势+屏幕共享的自然对话中,信息是持续流入的,不是打包发送的。
轮次制不是技术限制,而是架构选择。早期的 GPT 系列继承了这个选择,后续几乎所有模型都沿用了,不是因为最优,而是因为惯性。
交互模型的核心改动:从离散轮次到连续流
Thinking Machines Lab 提出的交互模型,核心改动是把交互从离散的"轮次"变成连续的"流"。具体来说有三层变化:
输入端:持续接收而非批量等待。 模型不再等用户把话说完才开始推理,而是在用户输入的过程中就持续处理——类似流式输入的反向应用。用户可以随时追加信息、修正意图,模型实时更新内部状态。
输出端:渐进呈现而非一次性返回。 这一点现有的流式输出(streaming)已经部分实现,但交互模型更进一步:模型可以在输出中途根据用户的新输入调整方向。比如模型正在生成一段代码,用户中途说"改用 Rust",模型可以即时转向,而不是等当前输出完成再重新生成。
状态端:共享上下文而非独立轮次。 每一轮对话不再是独立事件,而是共享一个持续更新的上下文窗口。模型的"注意力"不是每轮重新分配,而是在整个交互过程中持续维护。
用一个类比:轮次制像发邮件,交互模型像共享文档里的实时协作编辑——双方都能随时看到对方的修改并做出响应。
用现有工具模拟交互模型的流式协作
交互模型的完整 API 専尚未公开,但它的核心思路——持续输入、渐进输出、中途可干预——可以用现有的流式 API 加 WebSocket 来模拟。下面是一个可运行的 Python 示例,展示"用户中途打断并修正方向"的交互模式:
"""
实时流式协作示例:模拟交互模型的"中途干预"能力
依赖:pip install openai fastapi uvicorn websockets
运行:python interaction_sim.py
然后打开浏览器访问 ws://localhost:8000/ws 进行交互
"""
import asyncio
import json
from fastapi import FastAPI, WebSocket
from openai import AsyncOpenAI
app = FastAPI()
client = AsyncOpenAI() # 需设置 OPENAI_API_KEY 环境变量
# 共享的持续上下文——交互模型的核心特征
conversation_context: list[dict] = []
@app.websocket("/ws")
async def interaction_ws(ws: WebSocket):
await ws.accept()
await ws.send_json({"type": "system", "content": "连接建立,你可以随时输入。输入 /redirect <新方向> 可中途改变生成方向。"})
# 用户输入队列:支持持续流入
user_queue: asyncio.Queue = asyncio.Queue()
redirect_flag: asyncio.Event = asyncio.Event()
redirect_msg: str = ""
async def receive_user_input():
"""持续接收用户输入,区分正常消息和干预指令"""
try:
while True:
data = await ws.receive_text()
msg = json.loads(data)
text = msg.get("content", "")
if text.startswith("/redirect"):
# 中途干预:设置重定向标志
redirect_msg = text.replace("/redirect", "").strip()
redirect_flag.set()
else:
await user_queue.put(text)
except Exception:
pass
async def stream_with_intervention():
"""流式生成,支持中途被用户干预打断并转向"""
while True:
# 等待用户的新输入
user_text = await user_queue.get()
if user_text is None:
break
conversation_context.append({"role": "user", "content": user_text})
# 开始流式生成
stream = await client.chat.completions.create(
model="gpt-4o-mini",
messages=conversation_context,
stream=True,
)
accumulated = ""
redirect_flag.clear()
async for chunk in stream:
# 检查用户是否发出中途干预
if redirect_flag.is_set():
# 把干预信息注入上下文,重新生成
await ws.send_json({
"type": "interrupted",
"content": f"收到方向修正:{redirect_msg},正在转向..."
})
conversation_context.append({
"role": "assistant", "content": accumulated + f"\n[用户中途修正:{redirect_msg}]"
})
conversation_context.append({
"role": "user", "content": redirect_msg
})
# 用修正后的上下文重新开始生成
new_stream = await client.chat.completions.create(
model="gpt-4o-mini",
messages=conversation_context,
stream=True,
)
accumulated = ""
async for new_chunk in new_stream:
delta = new_chunk.choices[0].delta.content or ""
accumulated += delta
await ws.send_json({"type": "token", "content": delta})
break
delta = chunk.choices[0].delta.content or ""
accumulated += delta
await ws.send_json({"type": "token", "content": delta})
# 保存完整输出到持续上下文
conversation_context.append({"role": "assistant", "content": accumulated})
await ws.send_json({"type": "done", "content": accumulated})
# 并行运行:输入接收与生成输出同时进行
recv_task = asyncio.create_task(receive_user_input())
gen_task = asyncio.create_task(stream_with_intervention())
try:
await asyncio.gather(recv_task, gen_task)
except Exception:
recv_task.cancel()
gen_task.cancel()
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=8000)
运行前需要做的准备:
pip install openai fastapi uvicorn websockets- 设置
OPENAI_API_KEY环境变量 - 运行
python interaction_sim.py - 用任意 WebSocket 客户端(浏览器 JS、Postman、wscat)连接
ws://localhost:8000/ws
关键设计点:
conversation_context是跨轮次持续维护的,不是每轮重建——模拟交互模型的共享状态receive_user_input和stream_with_intervention并行运行——输入和输出不再互斥等待/redirect指令模拟"中途干预"——用户不需要等当前生成完成就能改变方向
这个示例用现有 API 模拟了交互模型最核心的三个特征。真正的交互模型 API 发布后,底层推理机制会进一步优化(比如增量注意力计算而非全量重算),但上层交互模式大概率就是这个形状。
从轮次到流式:架构层面的取舍
交互模型不是免费午餐。从轮次制切换到流式协作,有几个必须正视的工程代价:
推理成本上升。 轮次制下,模型只在完整输入后做一次推理。流式协作中,模型需要持续推理、增量更新状态,计算量可能增加 2-5 倍。Thinking Machines Lab 的论文中提到需要新的推理调度策略来控制成本,具体方案尚未公开。
状态一致性难题。 共享持续上下文意味着模型内部状态在交互过程中不断变化。如果用户中途干预,模型需要决定:是丢弃之前的部分输出,还是在现有基础上修正?这涉及注意力权重的动态重分配,目前没有标准方案。
错误传播风险。 轮次制下,一轮出错只影响那一轮。流式协作中,一个早期错误会持续影响后续所有交互,因为上下文是连续累积的。需要更精细的上下文管理机制——什么时候截断、什么时候回滚。
协议兼容性。 现有的 OpenAI/Anthropic API 都是轮次制。交互模型需要新的传输协议(WebSocket 或类似的双向流),新的请求格式,新的计费模型。这是生态层面的变化,不是换个参数就能适配的。
开发者现在可以做什么
交互模型的完整产品还在研究预览阶段,但方向已经明确。作为开发者,有三件事现在就可以动手:
1. 把所有 LLM 调用改为流式输出。 即使还在用轮次制 API,流式输出(stream=True)是交互模型的前置条件。如果你的应用还在用同步请求一次性返回完整结果,现在就改过来。上面的示例代码已经展示了基本模式。
2. 设计双向通信的接口层。 在你的应用架构中加一层 WebSocket 或 Server-Sent Events 的双向通道,让前端可以在模型生成过程中发送补充信息。不需要等交互模型 API,用现有 LLM + 中途干预逻辑就能跑通基本流程。
3. 实验持续上下文管理策略。 不再每轮清空上下文,而是维护一个持续更新的对话状态。关键问题是:什么时候截断旧内容、什么时候保留?可以先在现有 API 上用滑动窗口 + 摘要压缩的方式实验,为交互模型的正式 API 做准备。
一个最小化的检查清单:
- ✅ 所有 LLM 调用是否已改为流式?
- ✅ 前端是否支持在生成过程中发送补充指令?
- ✅ 上下文是否跨轮次持续维护,而非每轮重建?
- ✅ 是否有中途干预的 UI 机制(停止按钮、方向修正输入框)?
- ✅ 是否考虑了增量推理的成本预算?
交互模型要解决的问题很真实:人不会等对方说完再回应,AI 也不应该。从轮次制到流式协作的切换,不只是体验升级,而是交互架构的范式变化。现在开始把你的应用往流式、双向、持续上下文的方向调整,等正式 API 发布时,迁移成本会低很多。