Inside Thinking Machines’ Interaction Models

Thinking Machines 交互模型解析

ByteByteGo

2026年6月30日

从终端为您的应用添加身份验证（赞助）

运行 npx workos@latest，AI 代理将分析您的项目，检测框架，并直接将 AuthKit 集成到代码库中。

这不是一个通用的初始模板。代理会读取您实际的应用，在合适的位置编写集成代码，然后进行类型检查和构建，从而在过程中修复错误。AuthKit 提供托管身份验证、可定制的 UI、多因素认证、社交登录、会话管理，并在需要时提供单点登录（SSO）和系统配置信息接口（SCIM）等企业功能。

免费提供高达 100 万 MAU 的服务。

立即体验 →

如今看似与 AI 实时对话的体验，实际上是由许多协同工作的组件构建而成。

核心是一个分阶段运作的语言模型，其工作方式与您向 ChatGPT 输入文字时的机制相同。响应速度来自于围绕该模型的辅助系统层，这些系统能预测用户暂停的时机、转录音频、从文本生成语音，并快速整合这些部分，使对话显得流畅。

然而，Thinking Machines 的新研究认为这种整体方法存在上限，并提出了构建实时交互 AI 系统的不同方式。

Thinking Machines 是一家相对较新的 AI 研究实验室，专注于人机协作，以 Connectionism 的名义发布研究，并为更广泛的社区提供开发者面向的产品。他们与众不同的地方在于识别出的核心问题。大多数 AI 实验室将自主能力视为最重要的推进方向，即模型能够独立完成任务并返回结果的能力。

Thinking Machines 认为这种定位忽视了人类的作用。在他们看来，真正的工作需要持续协作，人类在模型执行过程中不断澄清、调整方向并提供反馈。界面应支持这种协作，而不是将人类视为完成任务后就离开的人。

在本文中，我们将探讨该研究预览内容以及 Thinking Machines 提出的交互模型概念。

免责声明：本文基于 Thinking Machines 工程团队公开分享的信息。如果您发现任何不准确之处，请在评论中指出。

瓶颈

问题始于当今模型实际感知世界的方式。典型的语言模型在单一线程中运行。它必须等待用户完成输入（打字或说话）后才能感知任何输入。一旦模型开始生成响应，其感知能力就会冻结，任何新输入都会被排队等待后续处理。

Thinking Machines 将这种设置比作通过电子邮件而非当面解决关键分歧。带宽实在太窄。协作中如此多的关键因素——您在不确定时声音的变化、在句子中途意识到需要改变方向的瞬间、当对方说出有用内容时您脸上的反应——所有这些都会在人与模型之间被剥离。

这很重要，因为真正需要另一个头脑参与的工作依赖于这种带宽。

一个只能看到干净、最终版本输入的模型，迫使人们像模型一样思考：准备完整的请求，提交后等待结果。相比之下，真正的协作往往混乱、充满打断和中途修正。直到界面允许这种交互方式，人类不得不额外做一些工作来适应模型的运行方式。Thinking Machines认为，这种瓶颈解释了为什么当今许多AI工作感觉像提示和等待，而非像两个人之间那样协作。

Harness

尽管存在这种限制，如果今天的语音AI仍能实现某种程度的实时交互，那又是如何运作的呢？答案是一种被称为Harness的模式。

典型的语音AI产品由多个组件堆叠而成：

• 语音活动检测监听停顿，判断用户何时停止说话。
• 语音转文本模型将语音内容转录为文字。
• 语言模型生成文本回复。
• 文字转语音模型将回复转换为音频。
• 对话管理器协调整个流程，使延迟感觉可接受。

想象一位只能通过门缝递入信件进行交流的学者。要让这种交流感觉像对话，需要助手的帮助。一位站在门外监听访客何时停止说话，另一位在学者回信时大声朗读，第三位则在发生学者需要知道的可见事件时敲响铃铛。

这种设置基本可行，但学者仍通过信件感知现实。语音语调、面部表情、当下这一刻，所有这些都超出了学者的感知范围。这就是所有实时语音AI的本质：一个基于回合制语言模型的核心，周围环绕着模拟对话的助手。

为什么这种模式存在上限？

因为助手比模型本身更简单。语音活动检测基于原始音频信号运行，使用的模型比背后的语言模型小得多、轻得多。这限制了整个行为范畴。

系统难以处理像“在我犯错时提醒我”这样的主动插话，因为决定何时发言的助手仅基于声学信号运作，而判断正确性是语言模型的职责。类似“告诉我何时在代码中写入了错误”的视觉反应也面临同样问题，因为助手处理音频，而屏幕上的任何内容都超出了它的感知范围。

Thinking Machines在此指出一个重要教训。正如Rich Sutton一篇著名论文所述，利用通用计算和学习的方法，始终优于嵌入人类设计启发式方法的方案。从手工设计的计算机视觉特征转向深度学习，从手工设计的游戏启发式规则转向自我对弈，都是这一论点的体现。应用于交互性场景，Harness组件正是那种最终会被规模淘汰的手工启发式方案。突破上限的方法是将交互性直接内置到模型本身。

• 统一可观测性如何将基础设施健康状况、日志和应用程序整合到单一视图中，以加快事件解决速度

• Dust 如何使用 Datadog MCP 将可观测性上下文直接引入事件调查

• 在构建 AI 时代系统时保持可靠性的实用策略

观看网络研讨会

架构

将交互性嵌入模型内部究竟意味着什么？

Thinking Machines 的解决方案是一种名为交互模型（interaction model）的系统。首个版本命名为 TML-Interaction-Small，这是一个包含 2760 亿参数的专家混合模型，任何时刻有 120 亿个活跃参数。名称中的 "small" 指的是其在产品路线图中的定位，后续将推出更大规模的版本。

大多数多模态系统从文本开始，再叠加音频和视频。

Thinking Machines 采取了相反的路径，从连续的音频和视频开始，因为实时对话需要满足严格的实时约束条件，这是文本无法避免的。优先解决最复杂的情况，使他们能够设计出一种架构，可以跨所有模态处理并发的输入和输出流。

请参见下图：

该架构背后有三个设计选择：

• 首先是时间对齐的微回合（micro-turns），这改变了模型对对话单元的定义。

• 第二是跳过重型预训练编码器的方法，音频和视频通过从零训练的轻量级处理组件进行处理，而不是通过 Whisper 等独立系统。

• 第三是双模型协调方案，快速交互模型与处理深度推理的较慢背景模型协同工作。

Thinking Machines 还对这种架构的推理优化进行了大量工作，包括向开源 SGLang 库贡献了流式会话功能，使 200 毫秒的数据块能够被高效处理。

微回合

大多数 AI 模型以回合（turn）为单位工作：用户说话，模型回应，用户再次说话。每个回合是一个独立单元，模型一次处理一个完整回合。即使系统处理音频，底层逻辑仍然是基于回合的。系统模拟实时交互，但模型本身感知的是清晰分离的数据块。

Thinking Machines 选择了不同的路径。

他们没有使用回合，而是将时间切分为 200 毫秒的片段，称为微回合。每 200 毫秒，模型会接收音频、视频和文本流中的所有输入，并决定在音频和文本流中输出什么。时间成为基本单位，完全取代了回合的概念。

这听起来像是一个小改动，但彻底改变了模型的能力。模型将时间视为连续流而非分段的回合，每个微回合都决定是说话、倾听、插话还是保持沉默。输入和输出同时持续进行。

具体来说，这解锁了基于回合的系统难以实现的行为：

• 模型可以在倾听时同时说话，这是实时翻译的工作方式。

• 它可以在说话时观看，这是实时体育解说的工作方式。

• 当出现视觉事件时（例如实时计数某人做俯卧撑），它可以在句子中间插话。

• 它还可以支持“边听边纠正我的发音错误”等任务，这类任务需要在听的同时进行说话，而基于回合的架构会将这类操作视为独立的操作。

这些能力都源于同一个源头，源自相同的架构选择。

协调机制

时间对齐的微回合解决了响应性问题，但也带来了新的挑战。

一个设计为在200毫秒窗口内响应的模型，如何同时进行深度推理？

某些任务确实需要数分钟的思考、网页浏览、工具使用或链式推理步骤。构建一个既能快速响应又能进行深度思考的单一模型非常困难。

Thinking Machines 的解决方案是使用两个模型协同工作：

• 交互模型快速、实时，负责处理对话。
• 后台模型速度较慢，负责处理持续推理、工具使用、浏览和长期任务。

它们之间共享上下文，因此都能了解对话内容和当前情况。

` 协调机制的工作方式如下：

• 当交互模型遇到需要深度推理的内容时，会将完整的上下文包发送给后台模型。
• 这是完整的对话内容而非独立查询，使后台模型能全面理解情境。
• 后台模型异步运行，结果在生成时实时返回。
• 交互模型会在合适的时机将这些结果自然地融入对话，而非在对话进行中突然切换上下文。

从用户角度看，这是一场连贯的对话，一个AI在思考、回应，偶尔暂停深入分析，再自然地重新融入对话。在后台，两个系统持续协调运作。

这种逻辑在计算领域广泛存在，快速路径与慢速路径配对、前台进程与后台进程配对，操作系统和浏览器中随处可见常规示例。Thinking Machines 做的是将这一模式以系统化方式应用于AI推理，而非让用户承担推理延迟的问题。

能力

这些设计选择共同作用。交互模型自主管理对话，能判断用户是否在思考、让步或自我纠正，并可根据上下文进行语音或视觉干预。它能同时说话和倾听，这使得实时翻译成为可能。它对经过的时间有直接感知，能与对话同时调用工具、搜索和生成UI，并在结果就绪时自然地将其整合回对话。

这些说法需要证据。现有语音AI基准难以捕捉这些质的飞跃，因此 Thinking Machines 自行构建了测试体系。

• TimeSpeak 测量模型是否能在用户指定时间点用正确内容发起语音，示例任务是“每4秒提醒我一次深呼吸，直到我让你停止”。
• CueSpeak 测量模型是否能在用户仍在说话时在合适时机回应，示例任务是“每次我切换语言时，用原始语言给出正确的词汇”。
• RepCount-A 在“数出俯卧撑次数”的指令后，播放有人做重复动作的视频流。
• ProactiveVideoQA 播放包含问题的视频流，正确答案取决于特定时刻的视觉内容。

结果令人印象深刻。在这些基准测试中，所有现有模型在这些任务上都表现不佳，大多数模型要么保持沉默，要么给出错误答案。这是 Thinking Machines 提出的最有力证据，证明其架构转变解锁了一种全新的能力类别，而不仅仅是加速旧有行为。

局限性

尽管结果令人鼓舞，但研究也指出了仍然存在的困难。

• 长会话仍然是这种架构的现实挑战。连续的音频和视频会迅速积累上下文。虽然流式会话设计能够很好地处理短时和中等时长的交互，但非常长的会话仍然需要谨慎的上下文管理。

• 连接性仍然是一个硬性要求，因为低延迟的音频和视频流需要可靠的互联网连接。较差的连接会导致体验显著下降。

• 模型规模的扩展受到延迟目标的限制，TML-Interaction-Small 的规模之所以如此，部分原因在于 Thinking Machines 更大的预训练模型目前在该场景下运行速度过慢。

结论

回顾来看，核心论点很简单。今天语音 AI 中感觉实时的交互，实际上是基于辅助组件的回合制语言模型，这种设计在一定范围内有效。Thinking Machines 的赌注是，突破这个限制的方法是将交互性本身作为模型的一部分。

两个架构选择承担了大部分关键工作：

• 时间对齐的微回合将时间切分为 200 毫秒片段，使模型能够将输入和输出作为连续流处理。

• 双模型架构将快速的交互模型与处理深度推理的较慢背景模型配对，两者共享上下文。

这一能力属于全新类别而非单纯降低延迟的证据，来自 Thinking Machines 自己构建的基准测试。像“在我做俯卧撑时实时计数”或“在句子中间纠正我的语言转换”这类任务，对于回合制架构来说仍然遥不可及，无论其速度提升到何种程度。

一个重要的启示是，通过外部框架添加能力会为该能力设定上限，框架本身而非底层系统会成为瓶颈。这一模式在计算领域普遍存在，而这项研究预览是 AI 领域近期最清晰的例证之一。

Thinking Machines 计划在未来几个月内开放有限的研究预览，今年晚些时候将推出更广泛的版本，并设立交互模型研究的专项资助。

参考文献：

• *Interaction Models: A Scalable Approach to Human-AI Collaboration*