跨模态、全自动：创智学院开源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，它们在同一个文件系统里协作，就像坐在同一张办公桌前。
协作的媒介，从消息升级到了工作区。
论文：AWCP: A Workspace Delegation Protocol for Deep-Engagement Collaboration across Remote Agents
GitHub：github.com/SII-Holos/awcp
Demo视频：https://www.bilibili.com/video/BV1iNfhB4EG2/?buvid=Y040AC07205334FD4753B82D9608978B6780
图1：两种协作范式的对比。左侧是传统消息传递——Agent之间交换序列化的任务描述和结果，接收方脱离原始执行环境处理孤立的工件，导致上下文丢失、信息不完整、环境不匹配。右侧是AWCP的深度参与模型——Delegator将工作区投影给Executor，后者使用本地工具链直接操作原始文件，完整保留上下文，实现原位执行。
01
填补协议栈空白：工作区层在哪里？
先盘点一下2025-2026年主流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给出的回答是：把协作从消息层下沉到工作区层。
02
核心理念：直接把工作区委派出去
举个具体的例子。
你让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用自己的工具链直接操作这些文件，修改实时或按需同步回来。
与现有协议的本质区别：
图2：AWCP在Agentic协议生态中的位置。Delegator通过MCP工具服务器或Skill模块接入AWCP。控制面使用标准HTTP和SSE进行信令交互。Executor通过可扩展适配层接入，支持A2A、ANP或直接HTTP。传输面提供可插拔的文件系统级访问，与消息级协调形成互补。
03
技术架构：怎么把工作区安全地”借”出去？
解决了”要不要共享工作区”的理念问题后，接下来是工程问题：怎么把工作区安全、可靠地投影给远程Agent？
从技术实现来看，AWCP采用了控制面-数据面分离架构。控制面（HTTP + SSE）负责协议握手和状态同步，数据面通过可插拔传输适配器搬运文件。两者分离的好处是：控制逻辑不变，只换传输适配器就能适应不同部署场景。
图3：AWCP架构。控制层处理Delegator和Executor之间的信令与状态同步，传输层通过可插拔适配器（SSHFS、Archive、Storage、Git）实现数据交换。两端各运行专用AWCP服务，Agent使用各自原生工具链操作。
四阶段握手：发邀请、谈条件、交钥匙、干活交付
整个协作生命周期分为四个阶段：
① 发邀请（Negotiation）：Delegator告诉Executor：“我有个任务，这是任务说明、这是你能用的文件目录、你有1小时的操作时间。干不干？”
② 谈条件（Accept）：Executor可以直接接受，也可以还价——把TTL从1小时砍到30分钟，把读写降级为只读。这种协商式接受避免了”要么全接受、要么全拒绝”的刚性模式。
③ 交钥匙（Provisioning）：条件谈妥，Delegator正式下发传输凭证（SSH证书、ZIP数据、预签名URL或Git仓库信息），激活数据面。
④ 干活交付（Execution & Completion）：Executor配置好工作空间后执行任务，通过SSE实时推送进度。完成后双方两阶段清理：先优雅断开连接，再回收临时资源。
图4：Delegator与Executor之间的四阶段消息序列。实线箭头为同步HTTP请求，虚线箭头为HTTP响应，蓝色箭头为异步SSE事件。
双状态机：各管各的，才更健壮
协议设计中一个值得注意的选择是：Delegator和Executor两侧各运行一个独立状态机。Delegator侧有9个状态，覆盖从创建到完成的全生命周期；Executor侧只有4个状态（pending → active → completed / error）。两个状态机通过ACCEPT、START、DONE三条消息同步，但不共享状态存储——在分布式系统中，这比维护一个全局一致的状态要健壮得多。
图5：AWCP双状态机设计。左侧DelegationStateMachine追踪Delegator侧的9个状态，右侧AssignmentStateMachine追踪Executor侧的4个状态。实线箭头为正常路径，红色虚线表示任意非终态可转入终态，蓝色虚线标记跨状态机的协议消息同步点。
四种可插拔传输
数据面支持四种传输适配器，覆盖从本地开发到云端生产的全部场景：
传输层完全可插拔——未来扩展WebDAV、rsync、P2P都不需要改动核心协议，只需实现对应的适配器对。
对于非实时传输，Executor通过SSE定期发回工作空间快照，Delegator按策略处理：立即应用（auto）、排队等人工审批（staged）、或忽略（discard）。
04
实战验证：两个典型场景
论文给出了两个演示场景，分别验证AWCP在能力非对称和信任非对称两个维度的有效性。这两个场景恰好对应了当前Agent协作中最常见的两类需求缺口。
完整的AWCP协作流程演示，展示智能体如何通过工作区委派实现深度协作
点击观看Demo视频：https://www.youtube.com/watchv=IAMZa4zgGdI
场景一：跨模态数据集整理
图6：跨模态数据集整理。纯文本Delegator（Cline + DeepSeek V3.2）将混乱的图片目录委派给多模态Executor（Gemini 3 Pro）。Executor分类、过滤、重组文件，变更通过FUSE挂载双向实时同步。
问题：用户有一个混乱的图片文件夹（超过100张图片），需要按内容分类整理。但Delegator是纯文本智能体（Cline + DeepSeek V3.2）——它看不懂图片。
传统方案：压缩文件夹 → 上传到多模态Agent → 等逐张识别返回JSON → 根据JSON决定分类 → 执行或再次传输。如果分类规则要调整，整个流程从头再来。
AWCP方案：Delegator发起委派，Gemini 3 Pro通过SSHFS将图片目录直接挂载到本地。Executor遍历图片，用视觉能力识别内容，直接在挂载目录里创建子文件夹（bear/、penguin/、panda/…）并移动文件。变更即时同步回Delegator，全程零手动传输。
纯文本Agent通过一次工作区委派就获得了视觉能力——这就是能力非对称协作。
场景二：企业级多轮合规盖章
图7：多轮合规盖章。Delegator（OpenClaw on Feishu）将合同委派给Compliance Auditor进行盖章。第一轮因缺少身份验证被拒，第二轮补充材料后成功。每轮是独立的AWCP生命周期。
问题：用户在飞书平台通过OpenClaw提交合同文件，需要合规审核+身份验证+电子盖章。OpenClaw作为当下最火的AI Agent平台，拥有强大的任务编排能力和丰富的技能生态——但它本身没有盖章权限。这恰好体现了AWCP的互补价值：OpenClaw负责用户交互和任务编排，AWCP负责把工作区安全地委派给拥有特定权限的远程Agent执行。
第一轮委派中，Executor检查材料后发现缺少身份证件，返回明确提示：“请补充签署人身份证正面照片”。用户补充材料后，OpenClaw发起全新的第二轮委派。每轮是独立的AWCP生命周期，协议天然支持这种迭代工作流。
盖章操作在授权Executor上完成，数字印章始终不出Executor环境——这就是信任非对称协作。
05
协议规范与参考实现
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代码。
06
未来方向
研究团队对当前版本的局限并不回避。AWCP目前聚焦于可用的最小闭环：一对一委派、四种传输、完整生命周期管理，但离生产级的多智能体协作还有不少距离。
安全性是其中最关键的一环。论文明确将细粒度权限控制和沙箱执行列为未来工作，这在当前Agent安全事件频发的大环境下，是AWCP走向生产部署前必须补齐的短板。
07
结语
回顾互联网历史，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
项目团队：AWCP主要由上海创智学院的多智能体团队设计实现，包括导师张伟楠、高级工程师周元剑、博士生聂晓航、郭子晗。
引用
@article{nie2026awcp,
title={AWCP: A Workspace Delegation Protocol for Deep-Engagement Collaboration across Remote Agents},
author={Nie, Xiaohang and Guo, Zihan and Chen, Youliang and Zhou, Yuanjian and Zhang, Weinan},
journal={arXiv preprint arXiv:2602.20493},
year={2026} }
未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！
公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。