OpenAI 发布 Assistants API

Assistant、Thread、Message、Run。2023 年 11 月 6 日，OpenAI 在首届 DevDay 上用四个名词描述一个助手如何存在：它有长期指令，在一条会话里接收消息，并通过一次次运行调用模型和工具。

这些名词之所以有吸引力，是因为开发者早已厌倦重复造轮子。调用模型并不难，难的是把它变成一个持续工作的产品：保存对话，裁剪上下文，接收上传文件，等待代码执行，把函数结果送回模型，再向前推进一步。Assistants API 把其中一部分收进平台状态机。Assistant 保存指令与工具；Thread 承载会话；Message 记录内容；Run 负责让模型在指定线程上工作。

文件检索、Code Interpreter 和函数调用让这套对象模型显得完整。开发者可以更快做出一个能读资料、运行代码、连接业务 API 的助手，但“托管”从来不等于“不需要后端”。业务权限、用户身份、失败补偿和产品界面仍在应用一侧。调试反而多了一层判断：问题出在文件没有召回、解释器超时、模型选错函数，还是 Run 卡在某个状态？

便利与限制来自同一个地方。平台替应用决定 Thread 如何持久化、Run 经过哪些状态、工具结果怎样回到模型，于是团队少写了代码，也少掌握了一些细节。

随着产品增长，日志、告警、权限和计费逻辑会围绕这四个对象生长。对象名看起来只是 API 设计，最后却会进入数据库字段、监控面板和团队语言。

2025 年，Responses API 与 Agents SDK 成为新的开发方向，Assistants API 进入迁移路线。此时真正的成本不只是换一个请求地址。原先交给 Thread 的会话状态放在哪里？Run 的工具循环由谁驱动？文件检索和代码执行继续托管，还是回到应用编排？早期节省的基础设施工作，以重新分配职责的方式回到桌面。

这并不说明 2023 年的选择毫无价值。Assistants API 让大量开发者第一次用同一套词讨论有状态的模型应用，也让能读文件、会用工具的助手更快进入产品。它留下的教训更具体：选择一个高层 API 时，不只要问今天少写多少代码，还要问这些状态如果有一天搬家，团队是否知道每件行李属于谁。

Assistant, Thread, Message, Run. On 6 November 2023, at OpenAI's first DevDay, four nouns described how an assistant could persist: it held durable instructions, received messages inside a conversation, and worked through runs that involved a model and tools.

The nouns were attractive because developers were tired of rebuilding the same machinery. Calling a model was easy compared with turning it into a continuing product: save a conversation, trim context, accept uploaded files, wait for code execution, return function results, then advance the exchange. The Assistants API pulled part of that machinery into a provider state machine. An Assistant stored instructions and tools. A Thread carried the conversation. Messages recorded content. A Run asked the model to work on that thread.

Retrieval, Code Interpreter, and function calling made the object model feel substantial. A developer could reach a file-aware, code-running, business-connected assistant faster, but hosted never meant backend-free. Business authorization, user identity, compensation after failure, and the product interface remained with the application. Debugging gained another layer: had retrieval missed the file, had the interpreter timed out, had the model selected the wrong function, or was the Run waiting in an unexpected state?

Convenience and constraint came from the same source. The platform decided how Threads persisted, which states Runs passed through, and how tool output returned to the model. Teams wrote less code and controlled fewer details.

As a product grew, its logs, alerts, permissions, and billing logic began to organize around those four objects. API nouns that looked cosmetic entered database fields, dashboards, and team vocabulary.

In 2025, the Responses API and Agents SDK became the new development direction and Assistants entered a migration path. The bill was larger than changing an endpoint. Where should conversation state once placed in a Thread live now? Who should drive the tool loop represented by a Run? Should file retrieval and code execution remain hosted or return to application orchestration? Infrastructure work saved at the beginning came back as a reassignment of responsibility.

That does not make the 2023 choice worthless. The Assistants API gave many developers a shared vocabulary for stateful model applications and shortened the path to assistants that could read files and use tools. Its sharper lesson is about choosing high-level APIs: ask not only how much code disappears today, but whether the team knows who owns every piece of state if those objects must move tomorrow.