AI智能体 Dots

原创

ITPAPA
ITPAPA

ITPAPA

2026年9月30日 16:22
江苏

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

AI智能体 Dots 将长期目标、工作记忆、任务调度、应用工具和执行环境组织在同一个持续工作代理中。官方介绍明确其由 GPT-6 Astra 驱动，并拥有云端电脑和浏览器；用户离开对话后，已安排的工作仍可继续。

官方公开了持续任务、跨渠道联系、保存笔记、插件访问和任务委派等行为。内部模型路由、数据库种类、队列服务、记忆检索算法和资源调度策略仍未公开。

1 总体逻辑架构

Dots 的核心关系是云端协调与多环境执行。协调决定下一步工作；具体操作可以由应用工具、云端电脑、本地电脑或委派任务完成。下图按职责建模，不对应后台微服务的数量。

图1 Dots 的逻辑架构  箭头表示任务分发路径  执行结果回传协调层

控制信息与业务信息分别流转

从工程视角看，目标、计划、授权范围、触发条件和进度属于控制信息；工单、文件、工具参数、执行结果和产物属于业务信息。控制信息决定可以做什么，业务信息提供判断和执行所需的事实。该划分用于理解系统职责。

推理与执行形成反馈关系

模型可以提出查询和动作候选；宿主负责连接工具和执行环境；外部系统依据身份与参数完成操作。结果返回后，协调层判断是否满足目标。API 返回成功、文件生成成功和业务目标完成，是三个需要分别核验的状态。

架构设计应保留从目标到动作再到结果的关联。对于自研集成，可使用任务 ID、工具调用 ID 和业务对象 ID 建立追踪关系，避免只能看到一段自然语言总结而无法核对实际变更。

2 任务生命周期与运行逻辑

持续工作依赖可延续的状态和唤醒机制。官方确认 Dot 能在暂停后继续，也支持保存的定时任务以及受支持的应用事件。“Always-on”描述持续可用和工作延续，并未证明模型全天不间断推理。

图2 任务运行状态的工程抽象  并非官方内部状态名称

状态转换需要明确原因

可将任务抽象为待执行、规划、执行、核验、等待、完成或失败。等待原因应区分授权不足、用户未决、电脑离线、外部系统不可用和定时条件未到。相同的“等待”状态可能需要完全不同的恢复动作。

长期责任与单次运行分别管理

“持续跟踪项目风险”是一项长期责任；今天生成风险清单是一次运行。工程集成应分别保存责任范围、每次运行的起止时间和交付结果。取消长期责任、停止某次运行、停止子任务，应有明确对象和效果。

在执行结果不足时，协调层需要补充查询或调整计划。建议设定单次运行的时间、调用次数和成本上限，并在达到上限时保存进度和阻塞原因。上述预算控制是实施建议，不是对 Dots 默认限制的描述。

3 上下文与记忆管理

Dot 使用当前对话中的相关信息、相关 ChatGPT 记忆和自己的保存笔记。Dot 笔记与 ChatGPT 保存的记忆分开；切换联系渠道不会重置笔记，但可见消息不会自动复制到其他渠道。新委派任务获得为该任务提供的上下文。

避免将工作记忆当作事实数据库

偏好可以长期沿用，项目期限和工单状态却会变化。对于自研集成，建议把事实的来源、读取时间和版本一起返回；执行修改前重新查询关键字段。保存摘要能降低重复阅读，但摘要可能遗漏条件，不能代替业务系统中的最新记录。

上下文选择影响质量与成本

工程上可优先提供目标、授权范围、当前状态、相关证据和下一步约束，再按需要读取详情。向每个子任务复制全部历史会增加成本，也可能扩大信息暴露。只传摘要则可能丢失关键证据，因此还应传来源引用和可调用的查询工具。

记忆存储与模型训练是不同问题

保存工作笔记不意味着修改模型参数。官方控制文档说明，不会直接使用主动研究或其私人笔记训练模型；相关信息进入适用的对话或任务后，仍按对应数据设置处理。

4 数据流转与结果核验

一次业务任务从指令开始，经过读取、判断、动作审查、工具执行和结果核验，再更新进度。下图是推荐的数据流模型，适用于分析 Dots 与企业系统之间的连接。

图3 业务数据与工具结果的流转  设计示意

三个边界决定数据正确性

第一是来源边界：查询结果应能对应到原始对象和时间。第二是执行边界：写入必须由后端校验身份、字段和当前版本。第三是交付边界：结果应明确说明已查询、已生成、已保存或已发送，避免将动作意图写成已完成事实。

对接系统应保留的数据

以上字段是自研服务的数据契约示例。敏感参数可只保存摘要或哈希；审计记录应限制读取权限。涉及本地资源时，工具结果和任务上下文仍可能进入云端协调，不能按“仅本地处理”评估。

5 插件与 MCP 工具对接

插件是可安装的能力包，可以提供 Skills、MCP 服务和可选 UI。Skill 描述流程和成功标准；MCP 服务提供工具、输入输出结构、认证和业务操作；UI 用于检查或确认结构化信息。具体能力仍取决于工作表面和权限。

图4 自研业务系统的插件对接  业务 API 与数据库属于企业侧

工具设计应围绕明确动作

官方建议按用户目标定义工具，并提供清晰的名称、描述、输入 Schema、结构化输出和准确的安全注解。服务端处理器负责授权和执行。工具不宜暴露可任意拼接的 SQL 或无限制的 URL 参数。

工具名称属于设计示例，不是 Dots 内置 API。对稳定、结构化的业务操作，建议优先采用可审计的 API；缺少接口的页面可考虑浏览器操作，但需增加结果回读和人工接管。

6 认证授权与写入契约

需要访问用户数据或执行写动作的 MCP 服务，应实施身份认证。官方认证机制采用 OAuth 2.1 授权码流程与 PKCE，宿主获得访问令牌后，在后续请求中携带 Bearer Token；服务端逐次核验令牌的发行者、受众、有效期和权限范围。

三类许可同时影响动作

模型正确识别用户意图不能代替后端对象权限校验。后端应从已认证身份确定租户，避免相信模型提供的 tenant\_id；对高影响操作，还应核对对象、目标状态与授权范围。

写入接口的建议参数

更新工单的业务参数可包含 case\_id、允许修改的字段、expected\_version 和 idempotency\_key。expected\_version 用于发现期间发生的修改；idempotency\_key 用于识别同一业务动作的重试。这两个字段由自研后端实现，不是 Dots 官方通用参数。

执行结果应能区分失败与未知

推荐返回 operation\_id、applied、current\_version、business\_status 和 error\_code。超时但提交状态未知时，应查询操作结果，再决定是否重试。权限错误应明确返回权限不足，不能被模型推测为暂时性网络故障。

凭据处理

业务访问令牌和 webhook 签名密钥应由服务端管理，不应进入普通提示词、工具说明或可供模型读取的结果。网站登录会话与 MCP 令牌分别管理，撤销其中一种不会自动撤销另一种。

7 事件订阅与唤醒机制

MCP Events 允许 ChatGPT 订阅连接服务的更新。当前官方机制使用 HTTPS webhook，提供事件发现、订阅、取消订阅和回调验证；该集成要求 MCP 2.0 协议版本 2026-07-28。是否可用于具体 Dot 任务，需验证连接服务和账户支持。

图5 应用事件进入 ChatGPT 的交互顺序  事件集成机制不等同于所有应用均支持

事件只携带足够启动工作的信息

官方事件结构包含 eventId、name、timestamp 和 data，发送方使用订阅密钥签名。建议仅发送对象 ID、变化摘要与来源链接，再由读取工具查询完整记录。用户文本按数据处理，不能作为新的执行指令。

订阅成功与持续有效分别验证

工程上线时应验证订阅范围、到期续订、重复投递、权限撤销和事件丢失后的恢复。重复事件的消费端去重属于建议；业务写入仍需独立保证幂等。不能仅凭收到一次事件，就推断未来持续监控可靠。

定时检查可以补偿未提供事件能力的系统。定时检查与事件订阅是不同路径：前者主动查询，后者由来源推送。具体监控任务必须确认已建立，而不能只在对话中写下监控意图。

8 执行环境与任务委派

Dot 的云端电脑具备独立文件、软件和浏览器会话；连接本地电脑后，可使用获准的本地资源。消息渠道、应用插件和电脑连接分别授权。电脑离线会阻塞依赖本地资源的工作，但不等于撤销授权。

委派需要交付契约

建议为每个子任务明确目标、输入、允许动作、交付物、成功条件和依赖。调查代码缺陷的子任务可以交付证据和修改建议；准备修复的子任务交付差异、测试结果和待审产物。主任务依据结果决定后续动作。

并行适用于可独立推进的工作

相互独立的查询和分析可并行；对同一个对象的写入应串行或采用版本校验。若多个子任务需要共享结论，需明确以哪个产物为准，否则容易重复操作、覆盖更新或引用旧结论。

环境切换不等于任务迁移

已有任务仍关联其原始电脑或云端环境。设计恢复流程时，应记录仓库版本、文件位置、已完成操作和待续步骤，再决定原地恢复还是重建任务。不要假定更换 Dot 的电脑选择会迁移执行状态。

9 安全边界与企业治理

官方动作审查会综合任务指令、权限、自定义规则和内置要求，决定执行、请求批准或人工接管。主动研究工具本身不能发送消息、修改连接应用或控制电脑；随后执行的动作仍需符合对应权限。

提示注入需要在数据边界处理

以下属于工程防护建议。邮件、网页、文档和事件正文可能包含诱导工具调用的内容。集成服务应把这些内容标记为外部数据，避免混入受信任的流程指令；在执行写入或分享时，再核对对象、受众和授权范围。删除或过滤文本本身不能保证消除所有风险。

云端协调需要独立评估数据治理

官方企业说明指出，Dots 在 Enterprise beta 阶段不支持数据驻留或推理驻留，也不提供严格的零数据保留。本地文件与网络限制不会自动覆盖云端电脑。企业应按实际执行路径和数据种类评估，不能沿用其他 API 或产品的承诺。

审计应核对业务结果

建议同时保留智能体任务记录和业务系统操作日志，关联发起身份、授权对象、操作 ID 和最终状态。不要把审批回调或自然语言总结当作完整审计链；合规事件覆盖应以实际可取得的记录验证。

10 故障处理与可靠性设计

本章给出自研对接的工程建议。长期任务的可靠性取决于外部系统可用性、身份有效性、数据版本、执行状态和恢复规则。只提高模型回答质量，无法解决重复写入或事件丢失。

完成状态需要可验证条件

建议为每项业务目标定义完成条件。例如“更新风险清单”要求目标文档存在、包含最新业务对象、引用时间明确且内容已保存；“提交修复”要求改动存在、适用测试完成并产生可审查的代码产物。运行结束只说明执行退出。

补偿与回滚分别设计

业务操作可能已产生外部影响。删除已创建记录、恢复文档版本和撤销发送通常具有不同能力与限制。应在工具设计阶段说明可否撤销，不能把再次调用模型视为自动回滚。遇到不可撤销动作，恢复策略应以阻断后续错误和明确通知为主。

成本应与成功结果关联

建议统计每个成功交付的查询量、模型调用量、运行时间和人工复核时间。通过限制查询范围、按需读取详情、独立任务并行和合并通知降低浪费；高频事件应在企业侧先筛选，避免每次变化都启动完整调查。

11 工单跟踪的完整对接案例

以下为技术设计案例，不代表已经部署的产品功能。目标是在获准范围内跟踪重要工单，生成风险摘要，更新内部清单；对客户发送信息需取得相应授权。

确定对象与触发条件

用户指定项目、严重级别、监控期限、通知渠道和可执行动作。插件提供查询、读取、更新清单和创建跟进事项等工具。若支持事件，可订阅目标队列的状态变化；否则建立定时查询。实际订阅或计划需验证已保存。

事件进入后的处理过程

1  企业侧发送工单 ID、事件 ID、变化摘要和时间。接收流程校验来源和格式后，启动对应工作。

2  通过 get\_case 回查最新状态，并查询相关缺陷、负责人和截止时间。证据需保留来源，避免凭单条事件直接判断。

3  形成风险结论和理由。可将相互独立的日志分析或代码调查交给子任务，但不得默认子任务有访问全部客户资料的权限。

4  对允许更新的内部清单形成结构化参数，通过动作审查和业务后端权限检查。使用工单当前版本避免覆盖他人的更新。

5  回读清单确认落地，保存操作结果；按指定渠道报告重要变化，记录下次检查条件。若需要客户沟通，先准备具体内容再按授权范围处理。

示例结果契约

该案例的关键是把“发现变化”与“执行动作”分开：先获取最新事实，再判断和审查，最后通过业务结果证明完成。这样才能在任务持续运行时定位错误和恢复工作。

12 技术评估与实施路线

建议先选择一个可核验、可恢复且边界清楚的业务目标，验证完整链路，再逐步扩大自动执行范围。以下路线适用于自研插件和企业流程试点，不预设 Dots 对某个账号已经可用。

分阶段验证

评价指标应围绕业务目标

成功率应以达到预先定义的交付条件计算，而非工具调用返回成功。其他指标可包括结果准确率、来源覆盖率、端到端延迟、重复副作用数量、人工复核时间和每次成功交付成本。指标定义应包含样本范围和统计窗口。

至少验证这些异常场景

重复事件、乱序事件、撤销权限、过期令牌、目标版本变化、电脑离线、写入后超时和子任务失败。对具有外部副作用的工具，应验证恢复时不会重复执行。测试必须使用允许操作的数据和环境。

需要进一步验证的产品边界

官方明确 Dots 由 GPT-6 Astra 驱动，但没有据此公开每个子任务的模型路由、推理预算或队列实现。独立 Dots 开发者控制接口、记忆检索算法、后台存储和服务级承诺，需要另行取得可验证资料。应用连接和事件能力也要按账号、插件与工作环境实际验收。

架构评估的落点是完整业务链路：有明确目标和授权，有可核验的来源，有受控的执行，有实际结果和可恢复状态。