OpenAI把编程工具变成了dots：常驻个人助理

OpenAI的编程工具正在经历一次角色转变——从开发者手中的代码生成器，变成随时在线的个人助理dots。负责dots的高管Alexander Embiricos在接受采访时说了一句耐人寻味的话：他永远不想和别人的AI agent开会。这句话背后，是OpenAI对AI助理形态的一次重新思考。

从编程工具到常驻助理

OpenAI的编程工具原本服务于开发者，核心能力是理解代码、生成代码、调试代码。dots的出现改变了这个定位：它把编程工具积累的推理与执行能力，延伸到日常任务中，变成一个始终在线的个人助理。

这种转变不是简单的功能叠加。编程场景对AI的要求是精确、可验证、多步执行，这些特性恰好是个人助理需要的底层能力。OpenAI把编程工具打磨出的能力迁移到助理产品上，走的是一条能力复用的路径。

Embiricos的“不想开会”意味着什么

Embiricos的表态值得拆解。他不想和别人的AI agent开会，指向的是一种产品判断：如果每个用户都有自己信任的AI助理，那么人与人之间的协作界面会发生变化，AI助理之间的交互可能取代一部分人类之间的直接沟通。

dots的定位正是“always-on”——常驻在线、持续可用。与需要用户主动调用的工具不同，常驻助理意味着它长期处于用户的上下文之中，理解用户的任务、偏好和节奏。这种形态对产品的信任度和上下文管理能力提出了更高要求。

AI agent（AI 代理） 指能够自主感知环境、制定计划并调用工具执行多步任务的智能体，区别于仅对单轮提问作出回应的聊天机器人。其关键特征包括目标持续性、工具使用能力和一定程度的自主决策。业界通常用“代理性”（agentic）描述这类系统在无人逐步指令下推进任务的程度。Embiricos 所说的“别人的 AI agent”，指的是代表其他用户行事的代理实例；若这类代理普遍存在，人机协作就会演变为代理与代理之间的协商，涉及身份认证、意图传达与责任归属等新问题。

编程能力为什么是助理的基础

编程任务是检验AI能力的试金石：代码能被执行、结果能被验证、错误能被定位。一个能在编程场景中稳定工作的模型，通常具备较强的多步推理和工具调用能力。

把这些能力用于个人助理，意味着dots不只是回答问题，还要能执行任务、操作工具、在多个步骤之间保持目标一致。OpenAI把编程工具作为支点撬动助理市场，逻辑上说得通，但产品体验能否迁移成功，还需要看实际表现。

工具调用（tool use / function calling） 是让大模型在生成文本之外调用外部函数或 API 的机制：模型输出结构化的调用请求，由运行时执行后把结果回传给模型，继续下一轮推理。它是多步任务自动化的技术基础，也是“可验证性”的来源之一——工具返回的结果可以被检查，而不像纯文本生成那样难以核实。编程场景天然要求模型频繁、准确地使用工具并处理返回错误，因此常被视为检验工具调用能力的压力测试场。

常驻助理的竞争格局

“always-on personal assistant”是多家AI公司共同瞄准的方向。dots的差异化在于它的编程基因：更强调任务执行的可靠性，而非单纯的对话流畅度。

Embiricos关于AI agent开会的那句话，也暗示了dots的长期愿景——它不只是一个被动响应的助手，而可能成为代表用户参与协作的代理。这个方向目前仍处于早期，产品形态、交互方式和信任机制都还没有定论。

上下文窗口与上下文管理 指模型单次可处理的信息量上限，以及系统在其中筛选、保留和丢弃信息的策略。常驻助理长期处于用户上下文之中，会持续积累任务历史、偏好与环境信息，因而必须解决“记什么、忘什么、何时检索”的问题。常见做法包括摘要压缩、分层记忆（短期对话记忆与长期向量检索）以及按需加载。上下文边界管理直接关系到隐私控制与响应质量，是 always-on 形态能否落地的工程难点。

值得关注的问题

从编程工具到个人助理，OpenAI的这次转向提出了几个实际问题：常驻助理如何管理隐私和上下文边界；编程场景的可靠性标准能否平移到日常任务；以及当AI agent开始代表用户与他人交互时，协作规则该如何建立。dots目前披露的信息有限，这些问题还没有明确答案，但它们决定了这类产品能走多远。