Skillsync让Agent会话可迁移

Skillsync 想拆掉 Agent 之间的“上下文墙”

Skillsync 于 2026 年 9 月 17 日前后以 YC W26 团队身份亮相，核心卖点是让 AI 对话会话能够在不同 Agent 之间迁移，而不是每换一个工具就重新解释需求、粘贴资料和校正背景。

**会话可迁移性是指把一段 AI 交互中的上下文、任务状态和关键产物，从一个 Agent 带到另一个 Agent，并让后者能够继续工作。**它迁移的不应只是一份聊天记录，更应该包括“用户要做什么、已经做到哪里、采用过哪些假设、哪些方案被否决、接下来需要执行什么”。

这个问题看起来像聊天记录导入，实际触及了 Agent 产品最核心的锁定机制：上下文。过去，用户留在一个 AI 产品里，未必是因为它在所有任务上都最强，而是因为历史对话、项目资料、偏好和纠错过程已经沉淀在里面。迁移成本越高，用户越不愿意切换模型。

Skillsync 的价值主张因此很直接：模型和 Agent 可以换，但工作进度不必清零。

它搬运的不能只是一串消息

**AI Agent 是能够围绕目标规划步骤、调用工具，并在权限范围内推进多阶段任务的 AI 系统。**与普通聊天机器人相比，Agent 的核心不是多说几轮，而是维护任务状态并产生实际操作，例如检索资料、修改文件、运行测试或提交审批。

一段真正有用的 Agent 会话通常至少包含五层信息：

1. 原始消息：用户和模型说过什么，包括附件引用与系统反馈。
2. 任务状态：哪些步骤已经完成，哪些步骤仍在等待处理。
3. 用户约束：技术栈、输出格式、截止时间、权限边界和风格偏好。
4. 中间产物：代码差异、报告草稿、搜索结果、工具调用返回值。
5. 决策轨迹：为什么选择方案 A，为什么放弃方案 B，以及哪些结论仍不确定。

**只迁移消息文本只能做到“重新阅读”，不能做到“接着执行”。**例如，一个编码 Agent 已经读取了 40 个项目文件、修改了 6 个文件并跑过两轮测试，如果迁移后只剩聊天摘要，新 Agent 仍然不知道当前工作区状态、失败测试对应的提交版本，以及哪些改动尚未经过人工确认。

这也是 Skillsync 成败的第一条判断标准：它究竟是在做更方便的复制粘贴，还是在做结构化的任务交接。

会话、记忆和 Skill 不是同一件事

**Agent Skill 是提供给 Agent 的可复用能力模块，通常包含操作说明、规则、工具配置和特定任务流程。**如果把 Agent 比作员工，Skill 更像岗位手册，会话则更像员工正在处理的一张工单，记忆是这个员工长期保留的用户信息。

三者经常被混为一谈，但它们解决的是不同问题：

| 对象 | 核心内容 | 生命周期 | 迁移后的作用 | 典型风险 | |---|---|---:|---|---| | 聊天记录 | 用户与模型消息 | 单次或多次会话 | 让新 Agent 理解讨论内容 | 信息冗余、摘要失真 | | 任务状态 | 步骤、待办、产物、失败记录 | 一次任务 | 让新 Agent 从断点继续 | 状态不一致、重复执行 | | 长期记忆 | 偏好、身份、历史事实 | 跨任务 | 减少重复说明 | 隐私泄露、错误固化 | | Agent Skill | 规则、流程、工具说明 | 长期复用 | 让不同 Agent 采用相同方法 | 权限扩大、指令冲突 | | 工具凭据 | 账户授权与访问范围 | 由权限策略决定 | 允许新 Agent 操作外部系统 | 越权、凭据泄露 |

**Skillsync 当前最明确的公开定位是会话可移植，而不是完整的 Skill 市场或跨平台身份系统。**围绕其发布出现的讨论进一步指向“可复用技能”这一方向，但会话迁移、技能迁移和凭据迁移的安全等级完全不同，不能仅凭产品名称或一句宣传语把它们等同起来。

尤其需要强调的是，工具授权不应随着聊天内容自动搬家。一个 Agent 能读取 Git 仓库，不代表接收会话的另一个 Agent 也应继承相同权限；一个系统能够生成数据库查询，也不代表它可以获得生产数据库的执行权限。

Skillsync 瞄准的是模型路由之后的下一层

**模型路由是根据任务类型、价格、速度或能力，把请求分配给不同模型的机制。**现有路由器大多关注“下一次请求发给谁”，Skillsync 关注的则是“已经进行到一半的任务如何换人”。

这个差异很重要。开发者可能希望先用低成本模型整理需求，再用擅长推理的模型设计架构，最后交给能直接操作仓库的编码 Agent 实施。如果每次切换都要手工整理背景，多 Agent 带来的能力优势会被交接成本吃掉。

| 方案 | 解决的问题 | 是否保留任务进度 | 是否负责工具连接 | 是否要求不同 Agent 互相通信 | |---|---|---:|---:|---:| | 手工复制对话 | 把可见文本带到新工具 | 部分 | 否 | 否 | | 聊天记录导出 | 保存或归档历史消息 | 通常不完整 | 否 | 否 | | 长期记忆功能 | 记住用户偏好和事实 | 部分 | 否 | 否 | | 模型路由 | 为请求选择合适模型 | 取决于宿主平台 | 否 | 否 | | Skillsync 式会话迁移 | 跨 Agent 延续上下文与任务 | 产品目标是支持 | 尚待披露 | 不一定 | | MCP | 统一 Agent 连接工具和数据的方式 | 否 | 是 | 否 | | A2A | 让不同 Agent 发现、通信和协作 | 可交换状态 | 间接 | 是 |

**MCP 是一种连接 AI 应用与工具、数据源和工作流的开放协议。**它更像 Agent 的通用工具接口，重点是让模型知道有哪些工具、工具需要什么参数以及返回什么结果，而不是替用户搬运整个会话。

**A2A 是一种让不同厂商或框架中的 Agent 进行发现、通信和任务协作的开放协议。**Google 在 2025 年 4 月公布 Agent2Agent 协议后，行业开始补齐 Agent 之间的通信层，但“能通信”并不自动等于“能无损接班”。

Skillsync 如果做得足够深入，更接近位于 MCP、A2A 和具体 Agent 产品之上的状态层：MCP 负责接工具，A2A 负责 Agent 之间传话，Skillsync 则试图把用户正在推进的工作打包带走。

真正的技术难点是语义对齐

**跨 Agent 迁移最难的部分不是导出数据，而是让不同系统对同一状态产生一致理解。**不同产品拥有不同的系统提示词、工具名称、上下文窗口、记忆机制和权限模型，同一个“继续执行”指令在两个 Agent 中可能意味着完全不同的动作。

一个可靠的迁移包至少需要处理以下问题：

• 消息角色映射：原平台中的 system、developer、user、assistant 和 tool 消息，在目标平台是否都有对应角色。
• 工具调用映射：原 Agent 调用的工具在目标 Agent 中是否存在，参数结构是否兼容。
• 文件引用解析：对话里提到的文件是否一并迁移，还是只保留一个已经失效的路径。
• 任务断点表示：目标 Agent 如何区分已完成步骤、失败步骤和等待人工批准的步骤。
• 上下文压缩：当原始会话超过目标模型的上下文限制时，哪些内容被摘要，哪些内容必须原样保留。
• 来源与时间戳：每项事实来自用户、模型还是外部工具，以及它在什么时候被验证。

**摘要是会话迁移中最容易被低估的损失来源。**把 10 万字上下文压成 2000 字摘要能够降低成本，却可能删掉一个决定代码行为的边界条件，或者把模型提出的假设误写成用户确认的事实。

更理想的实现不是生成一篇“前情提要”，而是建立结构化状态：目标、约束、证据、产物、待办和权限分别存储，并且保留指向原始消息的引用。这样，新 Agent 可以快速读取摘要，也可以在遇到争议时回溯原文。

安全问题会比兼容问题更早到来

**会话迁移本质上是一次高密度的数据出境或跨边界流动。**一段 Agent 会话可能同时包含源代码、客户名单、合同条款、内部网址、访问令牌和个人偏好，其敏感程度通常高于普通聊天记录。

Skillsync 若要进入企业场景，至少需要明确回答六个问题：数据是在本地处理还是上传服务器、传输与静态存储是否加密、数据保留多久、用户能否彻底删除、企业管理员能否设置迁移范围，以及第三方 Agent 能看到哪些字段。

**提示注入也可能随着会话一同迁移。**如果原 Agent 从网页或文档中读取了恶意指令，并将其写入长期状态，新 Agent 可能把这些内容误当作可信任务继续执行。迁移系统因此不能把所有历史内容放在同一个信任等级里，而应标记信息来源，并隔离外部文本、用户指令和系统策略。

权限继承则应遵循“重新授权”而不是“自动复制”。最稳妥的方式是只迁移任务需要的最小状态，在目标 Agent 重新确认高风险工具权限，并对发送邮件、合并代码、删除文件等不可逆操作再次请求人工批准。

现在还不能把它当成 Agent 的通用标准

**Skillsync 当前更像一个方向明确的早期产品，而不是已经建立事实标准的基础设施。**截至 2026 年 9 月 17 日，现有发布信息尚未充分披露支持的 Agent 清单、迁移格式、端到端加密方案、企业合规能力、定价、迁移成功率或第三方评测结果。

这些缺失信息直接影响产品是否可用。若它只支持少量网页聊天产品，价值更接近效率插件；若它能够迁移编码 Agent 的文件状态、工具结果和人工审批节点，才可能成为团队工作流的一部分；若迁移格式开放且允许其他厂商实现，才有机会接近行业基础设施。

| 观察指标 | 当前公开状态 | 为什么关键 | |---|---|---| | 支持的 Agent 数量与名单 | 尚未明确披露 | 决定实际覆盖范围 | | 迁移数据结构 | 尚未明确披露 | 决定能否避免厂商锁定 | | 定价与免费额度 | 尚未明确披露 | 决定个人和团队采用成本 | | 加密与数据保留策略 | 尚未明确披露 | 决定企业能否使用 | | 迁移准确率或任务续接率 | 暂无公开基准 | 决定产品是否优于手工摘要 | | 开放协议或开发者集成 | 尚未明确披露 | 决定能否形成生态 |

**最值得关注的指标不是迁移速度，而是任务续接率。**如果迁移后的 Agent 有 90% 概率正确理解任务，却只有 50% 概率从正确断点继续执行，这个产品仍然不能用于高风险工作。更有意义的评测应记录约束保留率、工具映射成功率、重复执行率和人工纠正次数。

我们的判断：方向正确，产品护城河尚未建立

**Skillsync 选中了一个真实且会持续扩大的痛点。**模型能力日趋接近、专用 Agent 不断增加之后，用户不会永远只使用一个入口：写代码、查资料、处理文档和操作浏览器，很可能分别交给不同产品。

它的短期价值是减少重复交代背景，中期价值是让团队按照任务阶段选择不同 Agent，长期价值则可能是把会话状态变成独立于模型和应用的用户资产。这个方向一旦成立，Agent 的竞争逻辑会从“谁拥有最多历史上下文”转向“谁能在当前步骤把任务完成得最好”。

**Skillsync 的护城河不会是导入导出按钮，而会是跨 Agent 的状态翻译、安全策略和兼容网络。**纯文本对话很容易被其他产品复制，能够稳定处理文件、工具调用、审批记录与权限边界的迁移层才真正难做。

风险也同样明显。大型 Agent 平台可以通过原生导入功能降低用户迁移门槛，MCP 与 A2A 生态也可能逐步补齐状态交换能力；如果 Skillsync 使用封闭格式，它自己又会成为新的锁定层。这与“让用户摆脱锁定”的产品叙事存在天然冲突。

**Skillsync 值得关注，但现阶段更适合被视为一项基础设施实验。**它提出的问题比已经公布的答案更重要：当 Agent 开始承担数小时乃至数周的任务时，工作状态究竟应该属于模型厂商、Agent 应用，还是属于用户自己。

答案不该再是某个聊天窗口。

参考来源

• 从聊天框到工作流：理解 AI Agent 人机协作的下一次升级：讨论复杂 Agent 对任务状态、审查机制、MCP 与 A2A 协作层的需求。
• Model Context Protocol GitHub 组织：MCP 相关规范、SDK 与开源项目的代码仓库入口。
• Agent2Agent Protocol GitHub 仓库：A2A 协议规范、示例及跨 Agent 协作资料。