Agent 协作破局：从「传话筒」到「共享工作台」，AWCP 如何终结上下文鸿沟？

导语：OpenClaw爆火后，多Agent协作仍停留在消息传递，上下文鸿沟导致效率低下。AWCP协议首次将协作下沉到工作区层，实现原生文件系统共享，本文带你读懂这一突破。

当每个 Agent 都成为专家，协作却还停留在传纸条

2025 年，AI Agent 学会了独立工作——写代码、做研究、管项目，单个智能体的能力突飞猛进。2026 年，OpenClaw 引爆了一切：两周狂揽 15 万 GitHub Star，创始人直接被 OpenAI 招至麾下。这个现象级项目让 AI Agent 从极客玩具变成人人可用的生产力工具。当每个人都拥有自己的智能体，当数以百万计专精 Agent——代码审计、视觉识别、合规盖章、数据分析——在各个平台涌现，一个必然的问题摆到了面前：你的 Agent 需要找专家 Agent 帮忙时，它们怎么协作？

Google 推出 A2A 协议让 Agent 之间交换任务，Anthropic 的 MCP 成为工具调用事实标准，ANP 试图构建智能体互联网的通信基础设施——多智能体协作的基础设施竞赛全面打响。但一个致命短板始终悬而未决：智能体之间只能“传话”，却无法“共事”。

想象一下：你的 OpenClaw Agent 接到一个复杂任务——需要一个视觉 Agent 帮忙整理数据集，需要一个安全审计 Agent 帮忙审查代码。现有协议能做什么？让它们互相发消息、传 JSON、来回倒腾文件。视觉 Agent 拿到的是压缩打包后的扁平文件集合，审计 Agent 收到的是脱离了构建系统和版本历史的代码片段——跑不了项目级静态分析，追不了跨文件依赖。这就像让三个建筑师隔着玻璃墙交流设计图纸——低效、易错、令人崩溃。

近日，上海创智学院的研究团队提出了 AWCP（Agent Workspace Collaboration Protocol）——首个在协议层面形式化工作区委派的智能体互操作标准，并同步开放了完整的参考实现。简单来说：你的 OpenClaw Agent 可以把工作区直接委派给视觉专家、安全审计师、合规盖章 Agent，它们在同一个文件系统里协作，就像坐在同一张办公桌前。协作的媒介，从消息升级到了工作区。

填补协议栈空白：工作区层一直没人管

先盘点一下 2025-2026 年主流 Agent 协议各自在解决什么问题：

MCP（Model Context Protocol）：工具调用层标准，让 Agent 能使用外部工具。
A2A（Agent-to-Agent）：任务层协议，负责 Agent 之间的任务分发和消息交换。
ANP（Agent Network Protocol）：网络层基础设施，解决 Agent 发现和连接问题。

发现问题了吗？工具层有了，任务层有了，网络层有了——但工作区层是空白的。没有任何一个协议解决“智能体如何在同一个文件系统里协作”这个问题。MCP 能让 Agent 逐个调用 lint 工具，但它没法让 Agent 在完整项目上下文里跑全局静态分析。A2A 能让 Agent 交换任务消息和文件附件，但收到的是剥离了构建系统、版本历史和测试基础设施的平面快照。

2025 年 5 月 arXiv 综述论文《A Survey of Agent Interoperability Protocols》分析了 MCP、A2A、ANP 等协议后明确指出，现有协议均在消息层运作，尚未覆盖环境级的互操作需求。AWCP 论文进一步将这个缺口概括为上下文鸿沟（Context Gap）——它的代价体现在四个维度：

环境重建成本高昂：每次协作都需要重新描述目录结构、文件内容、项目配置
状态同步容易出错：JSON 消息无法准确表达文件系统的完整状态
工具链不兼容：Agent A 的工具无法直接操作 Agent B 描述的“虚拟”文件
迭代效率低下：每一轮修改都需要“打包→传输→解压→执行→再打包”的完整流程

AWCP 给出的回答是：把协作从消息层下沉到工作区层。

核心理念：直接把工作区委派出去

你让 Claude 帮你重构一个 React 项目。Claude 分析后认为需要：修改 5 个组件文件、更新 package.json 依赖、调整 tsconfig.json 配置、跑 npm install 和 npm test 验证。在传统消息传递模式下，Claude 只能告诉你该怎么改，或者把修改后的代码贴给你。但它无法直接执行这些操作——因为它根本接触不到你的文件系统。AWCP 的答案很直接：让它接触到。

AWCP 借鉴了 Unix 经典的“万物皆文件”哲学，提出了文件即接口（Files-as-Interface）的协作范式。这不是一个随意的设计选择——观察现实中 Agent 的工作方式：编码 Agent 读文件、写补丁、跑测试；视觉 Agent 遍历图片目录；合规 Agent 审阅和盖章 PDF 文档。文件系统不只是协作的一种可能接口，它就是 Agent 与计算环境交互的原生媒介。

基于这个认知，AWCP 定义了一套标准化的工作区委派协议：Delegator 将自己的文件系统投影给远程 Executor，Executor 用自己的工具链直接操作这些文件，修改实时或按需同步回来。这与现有协议的本质区别在于：从交换打包好的结果，升级为共享原始工作环境。

技术架构：如何安全地“借出”工作区

解决了理念问题后，接下来是工程挑战：如何把工作区安全、可靠地投影给远程 Agent？AWCP 采用了控制面-数据面分离架构。控制面（HTTP + SSE）负责协议握手和状态同步，数据面通过可插拔传输适配器搬运文件。两者分离的好处是：控制逻辑不变，只换传输适配器就能适应不同部署场景，从本地开发到云端生产无缝切换。

四阶段握手：发邀请、谈条件、交钥匙、干活交付

整个协作生命周期分为四个阶段：

① 发邀请（Negotiation）：Delegator 告诉 Executor：“我有个任务，这是任务说明、这是你能用的文件目录、你有 1 小时的操作时间。干不干？”
② 谈条件（Accept）：Executor 可以直接接受，也可以还价——把 TTL 从 1 小时砍到 30 分钟，把读写降级为只读。这种协商式接受避免了“要么全接受、要么全拒绝”的刚性模式。
③ 交钥匙（Provisioning）：条件谈妥，Delegator 正式下发传输凭证（SSH 证书、ZIP 数据、预签名 URL 或 Git 仓库信息），激活数据面。
④ 干活交付（Execution & Completion）：Executor 配置好工作空间后执行任务，通过 SSE 实时推送进度。完成后双方两阶段清理：先优雅断开连接，再回收临时资源。

双状态机：各管各的，才更健壮

协议设计中一个值得注意的选择是：Delegator 和 Executor 两侧各运行一个独立状态机。Delegator 侧有 9 个状态，覆盖从创建到完成的全生命周期；Executor 侧只有 4 个状态（pending → active → completed / error）。两个状态机通过 ACCEPT、START、DONE 三条消息同步，但不共享状态存储——在分布式系统中，这比维护一个全局一致的状态要健壮得多。

数据面支持四种传输适配器，覆盖从本地开发到云端生产的全部场景：SSHFS（内核级挂载，即时同步）、Archive（ZIP 打包，适合离线传输）、Storage（对象存储预签名 URL，云原生部署）、Git（利用版本控制，天然可追溯）。传输层完全可插拔——未来扩展 WebDAV、rsync、P2P 都不需要改动核心协议，只需实现对应的适配器对。

对于非实时传输，Executor 通过 SSE 定期发回工作空间快照，Delegator 按策略处理：立即应用（auto）、排队等人工审批（staged）、或忽略（discard）。

实战验证：两个场景直击痛点

论文给出了两个演示场景，分别验证 AWCP 在能力非对称和信任非对称两个维度的有效性。

场景一：跨模态数据集整理

用户有一个混乱的图片文件夹（超过 100 张图片），需要按内容分类整理。但 Delegator 是纯文本智能体（Cline + DeepSeek V3.2）——它看不懂图片。传统方案需要压缩文件夹、上传到多模态 Agent、等逐张识别返回 JSON、根据 JSON 决定分类、执行或再次传输。如果分类规则要调整，整个流程从头再来。

在 AWCP 方案中，Delegator 发起委派，Gemini 3 Pro 通过 SSHFS 将图片目录直接挂载到本地。Executor 遍历图片，用视觉能力识别内容，直接在挂载目录里创建子文件夹（bear/、penguin/、panda/…）并移动文件。变更即时同步回 Delegator，全程零手动传输。纯文本 Agent 通过一次工作区委派就获得了视觉能力——这就是能力非对称协作。

场景二：企业级多轮合规盖章

用户在飞书平台通过 OpenClaw 提交合同文件，需要合规审核+身份验证+电子盖章。OpenClaw 拥有强大的任务编排能力和丰富的技能生态——但它本身没有盖章权限。这恰好体现了 AWCP 的互补价值：OpenClaw 负责用户交互和任务编排，AWCP 负责把工作区安全地委派给拥有特定权限的远程 Agent 执行。

第一轮委派中，Executor 检查材料后发现缺少身份证件，返回明确提示：“请补充签署人身份证正面照片”。用户补充材料后，OpenClaw 发起全新的第二轮委派。每轮是独立的 AWCP 生命周期，协议天然支持这种迭代工作流。盖章操作在授权 Executor 上完成，数字印章始终不出 Executor 环境——这就是信任非对称协作。

开源与集成：即插即用的参考实现

AWCP 协议规范完全公开，参考实现以 Apache 2.0 协议开放源码，可免费用于商业项目。该 TypeScript 参考实现目前约 9,200 行源码，2,500+ 行测试代码（161 个测试用例），拆分为 7 个 npm 包，模块化设计，开发者可按需引入。

在 Agent 接入层面，AWCP 提供了两种官方接入方式，覆盖 IDE 类和对话类两大 Agent 阵营：

MCP Server（@awcp/mcp）：面向 IDE 类 Agent。任何支持 MCP 工具调用的 Agent——Claude Code、Cursor、Cline、Trae、GitHub Copilot、OpenCode——都能通过标准 MCP 配置直接接入 AWCP，无需额外开发。
Skill 模块（awcp-skill）：面向对话式 Agent 平台。OpenClaw 等基于聊天交互的智能体可以通过 Skill 模块获得同样的工作区委派能力。前面 Demo2 中 OpenClaw 发起合规盖章，用的就是这个 Skill。

对于需要深度集成的开发者，@awcp/sdk 提供了完整的 Delegator 和 Executor 服务实现，支持自定义传输适配器和准入控制策略，一个最小化的 Delegator 集成只需十几行 TypeScript 代码。

展望：工作区层将成为 Agentic Web 的必要拼图

研究团队对当前版本的局限并不回避。AWCP 目前聚焦于可用的最小闭环：一对一委派、四种传输、完整生命周期管理，但离生产级的多智能体协作还有不少距离。安全性是其中最关键的一环，论文明确将细粒度权限控制和沙箱执行列为未来工作，这在当前 Agent 安全事件频发的大环境下，是 AWCP 走向生产部署前必须补齐的短板。

回顾互联网历史，HTTP 让孤立的计算机连成了万维网。今天的 AI 智能体正处在类似的转折点——它们各自强大，却无法真正协作。工具连接有了（MCP），任务通信有了（A2A），智能体互联有了（ANP），现在工作区协作也有了（AWCP）。

值得注意的是，AWCP 并不与任何编排框架竞争。无论 Agent 跑在 OpenClaw、Cline 还是自研平台上，AWCP 提供的是一个标准化的工作区委派原语——带有显式的生命周期管理和传输无关的文件同步，任何编排系统都可以采用。当 Agent 越来越专业化，一个标准化的工作区层将成为 Agentic Web 的必要基础设施。AWCP 能否成为这个层的事实标准，取决于社区的采纳和生态的发展——但至少，这个位置第一次被正式定义出来了。

项目地址：https://github.com/SII-Holos/awcp
论文地址：https://arxiv.org/abs/2602.20493
演示视频：https://youtu.be/IAMZa4zgGdI