截至 2026 年 8 月 28 日的公开资料与产品观察

agent-continuity-map.svg

图中左边是今天常见的产品内记忆，右边是一种把可迁移上下文交还给用户或企业的设计方向

最近再看 AI 产品，很容易生出一种疲惫感。打开产品页，几乎人人都在讲多 Agent、深度研究、文件处理、浏览器、本地电脑、定时任务和长程执行。Codex 和 ChatGPT Work 放在一起，Claude Code 之外又有 Cowork，Qoder、千问办公、TRAE IDE 和 TRAE Work、CodeBuddy 和 WorkBuddy、ZCode、Kimi Code 和 Kimi Work，再加上 DeepSeek Harness。

名字越多，用户的问题越朴素。它们到底差在哪。今天在 A 里调出来的工作习惯，明天换到 B 里，为什么还要从头解释。做了几个月的项目，Agent 为什么像刚入职一样问我代码在哪里、文档怎样写、哪些动作需要先批准。

我把能找到的产品资料和协议说明对了一遍，感觉这件事有两层。产品之间确实存在重叠。另一层更要紧，眼下的市场把几种不同东西都塞进了“Agent”这个词里，用户看到的自然是一团。

一长串名字里混着四种产品

先把产品按工作对象拆开，很多看似冲突的地方就清楚了。

层次

服务的工作对象

公开产品例子

用户选它时该问什么

对话入口

问答、检索、临时创作

ChatGPT、Kimi、千问

它能否快速给出可靠的即时帮助

工作 Agent

文档、表格、研究、演示、网页和日常办公

ChatGPT Work、Claude Cowork、千问办公、TRAE Work、WorkBuddy、Kimi Work

它能否拿到工作资料并交付可用成品

编码 Agent

仓库、终端、测试、评审和发布流程

Codex、Claude Code、Qoder、TRAE IDE、CodeBuddy、ZCode、Kimi Code

它能否理解工程边界并在权限内持续完成任务

Harness

模型、工具、会话、沙箱、调度和存储

DeepSeek Harness 与各类 Agent SDK

它能否让团队组装和治理自己的 Agent

同一家产品线会跨几层。OpenAI 目前在 ChatGPT 桌面应用中区分 Chat、Work 和 Codex。Work 面向研究、分析与文档、表格、演示等成品，Codex 面向仓库、代码、测试和开发工具。它们共享一个应用入口，历史仍然分开保存。OpenAI 的当前说明 写得很直白。

Anthropic 的 Claude Code 和 Cowork 也很接近这个结构。前者围绕开发环境，后者从桌面办公任务进入，最初以研究预览形式推出。Anthropic 的产品说明 还把技能、连接器和桌面 Agent 放在同一条演进线上。

国内产品的分层更容易被名字遮住。TRAE IDE 或 TRAE Work 的 Code Mode都是Coding Agent。TRAE Work 已把研究、写作、数据、设计和代码纳入一个工作台。它的产品页 很明确地写了 Work 与 Code 两种模式。千问办公则由阿里巴巴公告为一个办公 Agent 平台，整合了 Qoderwork、Mulerun 和悟空的能力，并把桌面、云端和企业协作放在同一个产品里。官方公告 给出了这条产品线的由来。

腾讯的 CodeBuddy 更贴近开发，WorkBuddy 更贴近日常办公。智谱的 ZCode 以任务、上下文、权限、文件和 Review 串起长程开发流。ZCode 文档 里可以看到这套思路。Kimi 也把 Kimi Code 和 Kimi Work 分成面向开发者和知识工作者的两条线。Kimi 的产品总览 写得很清楚。DeepSeek Harness 则是另一类东西，它面向构建 Agent 的开发者，强调模型、工具、技能、会话、沙箱、存储和调度都可以按插件方式替换，目前还处在 Developer Preview。DeepSeek 的说明 对此有明确限定。

这张表没有替任何产品排座次。它只想说明，今天的市场同时在卖办公入口、开发环境和运行时。把它们都当成“聊天软件升级版”，功能当然会显得复制粘贴。

功能为什么越做越像

表层功能像，是因为底下的动作已经趋同。一个能做事的 Agent 接到目标后，要找上下文，列计划，选工具，运行几步，检查结果，再把产物交给人审。它写 PPT 时如此，改代码时也如此。模型已经能读图片、文件、网页和代码，产品边界就会顺着工作对象移动。

于是，浏览器和本地文件从办公工具跑进了编码 Agent。代码生成和网页搭建也进入了工作 Agent。多 Agent、后台任务、远程接续和任务看板很快成了两边都会有的能力。OpenAI 把 Codex 应用描述成管理并行长任务的指挥台，发布说明 也提到技能与自动化。TRAE Work 把多类型文件放在一个工作区里。ZCode 则把权限和 Review 纳入任务流。它们使用的工作语言越来越相似。

产品仍然会分开，因为人手里的资料和风险没有合并。改一份营销演示与改一套生产系统，所需上下文、可接受错误、审批路径和审计责任差得很远。办公 Agent 可以先追求交付物的可读性。编码 Agent 必须面对仓库、测试、分支、部署和回滚。Harness 还要给企业提供扩展、隔离和可观测性。

未来一两年，产品表面会继续收拢，底层的身份、权限、工作区、数据治理和审计会拉开距离。我更在意后半部分。模型每隔几个月就会更会做事，用户不会每隔几个月重建一次工作关系。

用户失去的不是聊天记录

大家把这个问题叫作 Agent 失忆，其实里面混了至少五类东西。

第一类是项目规则。仓库怎样启动，测试跑什么，哪些路径不能改，提交前要看什么。这些内容适合放在代码库和文档里。AGENTS.md 已经提供了一种朴素的、可版本管理的项目规则文件形式。AGENTS.md 的开放格式说明 把它比作写给 Agent 的 README。

第二类是技能和流程。比如把需求整理成评审材料的步骤，处理周报的模板，某个系统的排障手册。Agent Skills 使用带有 SKILL.md 的目录承载说明、脚本、参考资料和资产，格式本身具有跨工具复用的潜力。Agent Skills 规范 已经把这个目录结构写清楚了。

第三类是事实记忆。用户习惯中文沟通，团队使用某种分支规范，某个客户只能在授权范围内访问，某项项目约束的来源是什么。这类内容需要来源、作用范围、有效期和删除入口。没有这些字段，记忆很快会从帮助变成陈旧的猜测。

第四类是连接器和权限。日历、邮箱、知识库、代码托管、数据库和本地电脑都要接进来。这里最危险的一点很容易被忽略，连接配置可以迁移，密钥和高风险授权不该打包迁移。MCP 的授权规范要求令牌面向具体资源，服务端也不能把收到的客户端令牌直接传给上游 API。MCP 授权规范 已经把这条边界写进协议。

第五类才是任务证据。一个任务由谁发起，依赖了什么文件，做了哪些决策，最终产生了什么，哪些动作经过人批准。用户换工具以后，最值得带走的常常是这条线，而不是模型在某个回合生成的内部压缩摘要。

这些东西都被产品放进“记忆”两个字里，体验上很方便，数据上却是五种完全不同的资产。能带走的程度也完全不同。

已有协议解决了一部分，缺口其实还在中间

现在已经有不少开放协议。它们很重要，也很容易被说过头。

MCP 解决 Agent 到工具和数据源的连接。A2A 解决一个 Agent 如何发现另一个 Agent，交换消息、文件、结构化产物和任务状态。A2A 的规范同时说得很清楚，它的目标是让独立且不透明的 Agent 协作，不要求把对方的内部状态、记忆或私有工具交出来。A2A 规范 因而更像任务协作语言，不能充当用户记忆的迁移格式。

AGENTS.md 适合保存项目规则。Agent Skills 适合保存可复用流程。OpenTelemetry 的 GenAI 语义约定有助于让模型调用、工具调用和 Agent 运行事件更容易被观测系统理解。OpenTelemetry 的 Agent span 文档 也提醒我们，观测字段、数据留存和隐私脱敏仍需部署方自行决定。

它们像一套正在长出来的基础设施。MCP 管工具，A2A 管协作，Skills 管做法，AGENTS.md 管项目规则，OpenTelemetry 管运行记录。中间还缺一层，用户或企业可控的上下文和授权迁移。

这个缺口不是小功能。它要求新产品知道一条记忆从哪来，能用到哪里，多久失效，谁能看，换到新系统后还要不要继续授权。现有的导出能力也能说明问题。OpenAI 允许导出聊天数据，但其账户迁移说明明确，导入只会作为新聊天中的参考，并不会复原旧侧栏、设置、记忆、文件和工作区权限。OpenAI 的迁移说明 已把边界列出来。Claude 提供用户数据与对话导出，其帮助文档 没有承诺跨产品恢复为一个可继续执行的 Agent。

所以，今天还没有一个可用的通用标准，能把一个人的画像、长期记忆、技能、完整任务历史、连接器授权和审计记录一次性搬到任意 Agent 里。这个判断来自协议和公开导出说明的范围比较，不涉及任何厂商未公开的路线图。

解决方向要从可迁移上下文开始

我更希望行业做出一种 Agent 连续性包。它不是现成标准，下面只是一个可讨论的产品设计。

包的最外层由用户或企业保存。每一条内容都有来源、作用范围、敏感级别、有效期和删除方式。导入一个新 Agent 时，系统先显示差异和权限请求，用户再决定迁入哪些部分。

内容

应该怎样保存

换 Agent 时怎样处理

个人偏好

人可读的偏好卡与可机器读取的字段

用户逐项确认，允许跳过

项目规则

代码库、文档和 AGENTS.md

直接随项目版本流动

工作技能

SKILL.md、脚本、模板和资产

安装前显示工具权限和兼容性

事实记忆

带来源、时间和有效期的结构化记录

迁移后由目标产品重新索引

任务证据

目标、计划、输入、产物、审批和摘要

支持按项目或时间范围导出

连接器

服务地址、所需权限和非敏感配置

在新产品内重新登录和授权

审计摘要

谁做过什么以及对应保留策略

默认脱敏，按权限提供给企业系统

这里有两条底线。

一条底线是，原始聊天记录不等于长期记忆。它里面可能有过期结论、隐私内容、错误假设和只有当时才有意义的上下文。系统需要先提炼出可追溯的事实和决策，再允许用户带走。

另一条底线是，迁移不能变成凭证搬家。账号令牌、会话 cookie、数据库密码和本地电脑的完全控制权都应该留在原地。新 Agent 想访问同一套工具，要重新拿到用户或企业的明确授权。这样会多一步操作，却能避免“换个客户端就继承全部权限”的事故。

模型私有的向量索引、压缩摘要和上下文缓存，也不必执着于逐字还原。更可靠的路线是把原始事实、规则、产物和来源带走，由目标产品重新索引。迁移的是可以检查的依据，模型自己的临时理解让它重新建立。

谁该先做这件事

个人用户可以先把稳定的偏好、常用模板、项目规则和重要产物放进自己的目录。把它们写成普通 Markdown、结构化数据和版本化文件。换产品时带走这些长期资产，不要把整段对话一股脑塞给新 Agent。私密合同、身份信息和密钥默认排除在外。

企业需要更早一步。代码、文档、数据定义和流程规则应该进入可审计的系统记录，聊天窗口只承担一次任务的入口。连接器经过统一身份网关和最小权限控制。项目级 AGENTS.md 与版本化技能适合保存稳定规则。运行日志可以采用 OpenTelemetry 的字段约定，哪些内容记录、谁能访问、保留多久，仍然要由企业自己决定。

厂商如果愿意把用户体验做得更长久，最实在的动作是提供按项目和时间范围导出的接口，显示每条记忆的来源和作用域，支持预览导入、字段映射、重新授权和一键撤销。竞争仍然可以留在模型、交互、执行速度和服务质量上。用户更换产品时，项目规则和长期积累的工作常识也该跟着走。

最后的判断

这一轮 Agent 产品会继续合并入口，也会继续拆分专业工作台。用户眼里看见的重复，一部分来自厂商还在试不同界面，一部分来自同一个 Agent 循环已经能处理越来越多的工作。

真正决定长期体验的，会是 Agent 能否接住一个人已经形成的工作方法，并且允许他在需要时带走。今天的开放协议已经铺好几段路，工具、技能、项目规则、任务协作和观测各有位置。下一段路要处理用户上下文、再授权和可审计迁移。

到了那一天，换 Agent 会更像换编辑器或浏览器。工具可以变，项目规则、工作成果和你对风险的判断还在。

本文主要资料