分布式 Agent 个人助理：互通协议、委派管理与产品边界

研究截止：2026-10-28。本文是产品方向调研，证据来自公开规范、版本化仓库文档和论文；未运行候选产品、未开展用户访谈，也没有新的性能实验。文中的架构、接入约定、指标和实验安排均为建议。

个人电脑里有一个写代码的 Agent，服务器上有一个定时检查服务的 Agent，另一台机器上有一个处理资料的 Agent。它们都能独立工作，但用户仍然要逐个打开窗口、转述需求、询问进度，再判断不同回复是否说的是同一件事。

这类个人助理的产品价值，是让用户把一件事情交出去后，能够知道谁接了、进行到哪、哪里需要决定，以及结果是否经过确认。连接和聊天是入口，任务归属与可恢复状态才决定它能否长期使用。

建议的方向是“一位长期主助理 + 多个独立执行 Agent + 一套可核查的任务记录”。协议优先复用 A2A、MCP 和 ACP，在上面补一份窄的个人接入与委派约定。前端以对话、待处理事项和任务为中心，不把所有原生工作台重新实现一遍。

一、产品对象：管理独立 Agent，而不只是启动子 Agent

一个应用内部生成的五个子 Agent，和五台机器上已经运行的 Agent，有明显区别。前者通常由同一个调度器创建，知道怎样启动、取消和收集结果；后者有各自的账号、权限、持久化、更新节奏，有的甚至没有远程输入接口。

三个最有价值的使用场景

场景	用户期望	产品必须解决的问题
接入已有 Agent	安装连接器、扫描一次邀请，就能看到远端 Agent	原生 Agent 有没有适配接口；接入后究竟能观察、聊天还是派任务
把任务交给合适的执行者	助理找到有文件、有工具、有权限的 Agent 去做	能力匹配、授权、接受回执、结果归属
离开后继续跟进	关闭手机后事情不丢，下次打开能接着处理	持久化任务、离线状态、人工决定、失败恢复

首批适用对象可以是假设中拥有多台设备、已经使用两个以上 Agent 工具的个人开发者、研究者或技术管理者。这是目标人群假设，不是已经验证的市场规模。更广泛的日历、邮件、生活服务集成，应在这三个场景成立后再扩展。

七个对象需要分开

对象	含义	为什么不能混用
节点 Node	一台受管理机器或独立运行环境	节点在线不代表 Agent 能接受任务
连接器 Connector	把原生接口接入系统的本地进程或插件	它通常有权限连接原生 Agent，必须明确权限范围
Agent	有能力、身份和本地策略的执行者	不应因新建聊天窗口就变成另一个执行者
会话 Session	一段原生对话上下文	对话可以轮转，任务身份不应随之改变
任务 Task	用户希望得到的一个结果	可以跨会话、跨多次执行持续存在
执行尝试 Attempt	某次具体派发与执行	重试不是新任务，也不一定安全
产物 Artifact	文件、报告、补丁等交付物	聊天说“做完了”不等于产物可取得、可核查

第一版不必统一所有 Agent 的内部记忆、提示词和循环实现。它只需要知道：对方能做什么、允许做什么、任务有没有被接受、结果在哪里。这与可移植 Agent 状态是相邻问题：本项目首先解决协作，不要求把整个 Agent 搬到另一个运行时。

二、现有协议：不同层次已经有不同答案

不能把“支持 MCP”“使用 WebSocket”“兼容 A2A”当作同一种能力。网络通道决定能不能连上；协议决定怎样表达请求；具体 Agent 的接口决定请求能否进入正在运行的循环。

协议比较

方案	标准化的关系	本项目可复用的部分	仍需产品解决的部分
A2A	独立 Agent 之间的交互	能力描述、消息、长任务、产物、查询与取消	私有设备入网、原生会话适配、具体委派授权和操作效果核查
MCP	Agent 应用访问工具与资源	把“查任务、委派、取产物”等能力提供给主助理	哪个 Agent 负责哪个任务，以及原生循环怎样接收请求
MCP Tasks 扩展	长操作的异步句柄	断开连接后继续查询任务、取回结果	执行端真正持久化什么、具体操作能否安全重试
ACP：Agent Client Protocol	客户端／编辑器控制编程 Agent	会话输入、更新、工具调用呈现、取消等	跨机器连接、设备配对和长期业务任务
AG-UI	Agent 后端与用户界面的事件交互	流式对话、状态和交互事件	任务数据库、授权、远端执行与故障恢复
ANP	更开放的 Agent 网络	开放网络中的描述、身份与发现设计	个人私有设备场景是否需要这些复杂度

来源：A2A 1.0 规范、MCP 2026-07-28、MCP Tasks、ACP v1、AG-UI、ANP 仓库。表中“仍需解决”指本文场景中的集成责任，不是断言这些项目永远不支持相应能力。

三个会影响选型的细节

A2A 已经允许私有发现。 Agent Card 可以通过私有目录或预先配置取得，个人设备不需要先注册进公共 Agent 市场。因而本项目可以把经过批准的 Agent Card 放在自己的目录中。A2A Agent Discovery

MCP 不能再按旧版本的印象讨论。 本次核查的最新核心规范为 2026-07-28：请求是自包含的，版本和能力按请求声明；长任务由独立 Tasks 扩展提供。旧版 2025-11-25 的初始化流程与实验性 Tasks 不能直接当作当前实现要求。MCP 版本与兼容性、Tasks 扩展版本快照

ACP 接入不等于任意远程会话接管。 v1 文档以 stdio 为基本传输，客户端通常启动 Agent 子进程，Streamable HTTP 仍标为草案。一个已经独立启动且没有控制接口的 Agent，不能仅靠安装管理 App 就被安全接管。本文的 ACP 专指 Agent Client Protocol，不能与名称相近的其他 ACP 混淆。ACP v1 传输

由此形成的建议是：对外委派任务优先采用 A2A；对内接编程 Agent 优先采用 ACP 或其原生接口；把管理能力暴露给助理时使用 MCP；只有需要自建交互界面时，才评估 AG-UI。 第一版不必同时实现四种协议，先把两个真实运行时接通更重要。

三、最小接入约定：小的是责任范围，不是省略失败语义

不建议现在发布一个替代所有 Agent 协议的新标准。更可行的是先定义个人 Agent 接入与委派配置档：沿用现有协议的消息和任务模型，规定个人设备场景需要的少量附加约束，并提供一致性测试。

这里的“配置档”是一份兼容约定，类似规定“在已有标准中必须启用哪些能力、遇到哪些情况必须怎样处理”。它不是新的传输协议，也不意味着只实现几个 A2A 方法就自动符合完整 A2A 规范。服务端仍须遵守选定版本的必选要求。

配对分成三个独立判断

1. 设备配对：用户允许这台机器接入自己的管理域。邀请应短期有效、一次使用，并绑定新设备实际持有的密钥；重复连接沿用同一身份。
2. Agent 登记：连接器声明它能接触哪些 Agent、使用哪个接口、具备哪些经过检查的能力。
3. 委派授权：某个来源能否要求某个目标执行指定类型的操作，以及目标本地是否允许。

同一 Tailnet 中的机器可以被网络策略允许通信，但不因此自动获得对方的文件写入或部署权限。设备密钥证明“持有这把密钥”，也不等于硬件不可复制。

低摩擦流程可以是：主界面生成邀请 → 远端执行一个安装／连接命令 → 复用已有 Tailscale 或按允许策略使用 Tailcat → 本地展示拟接入的 Agent 和权限 → 配对完成。网络未登录、原生 Agent 没有授权或不支持所需接口时，分别说明，不把它们混成“连接失败”。

接入后声明三个能力等级

等级	必须有的证据	界面允许承诺什么
观察	能读取可授权的状态和日志	看状态，不提供发送或取消按钮
交互	原生接口支持把消息送入指定会话	可继续交流；是否能唤醒空闲会话另行标注
受管任务	有接受回执、稳定任务句柄、可查询状态和结果	可以委派并持续跟进，按声明支持取消或恢复

“可接收消息”“可被唤醒”“可恢复任务”“可安全重试”应独立声明，不能用一个绿色在线圆点代替。只有 MCP 工具接口的 Agent，可能能主动询问别人，却没有被外部消息唤醒的能力。

最小契约的六项内容

内容	最少需要表达的语义
身份与版本	稳定 Agent 标识、连接器实例、协议版本、能力描述版本
作用域	允许的目标、工作区、工具类别、有效期和明确的限制
任务关联	产品任务 ID、远端任务句柄、执行尝试、父任务和输入修订号
回执与状态	传输收到、任务接受、等待输入、执行、结束必须可区分
产物与依据	可授权访问的产物引用，以及完成判定所依据的记录
恢复规则	重连后如何查询、如何去重、何时结果未知、何时不得自动重试

这些是产品必须保留的语义，不是要求创建六套新消息格式。现有协议有对应字段时直接映射；附加语义通过明确声明的扩展或连接器本地记录补充，不能悄悄更改标准任务状态。A2A 扩展机制

特别要注意：A2A 1.0 对发送消息的幂等是可选能力，并未保证所有发送都只执行一次。附加一个 ID 也不能阻止一个缺乏去重和效果记录的工具重复付款、发信或部署。A2A 1.0 §3.3.1

四、管理模块：对话是入口，任务与待决定事项是工作面

需要前端，但不建议以“把所有 Agent 的完整界面塞进一个大工作台”为目标。个人助理的入口可以保持稳定：用户一直与同一个助手交流，由助手选择已经授权的执行者；当某件事需要深入操作时，再进入原生 Agent 界面。

三个主要视图

对话承接意图、解释方案、澄清需求。助手在创建任务前，先给出简短的理解：预期结果、执行位置、权限边界、是否需要批准。不是每句闲聊都要变成任务。

任务与待处理事项是日常管理面。用户首先看见需要自己决定的事情：授权、补充信息、失败处置、待核实结果；普通进度安静记录。一个任务应显示负责人、最后可信更新时间、当前阻塞、下一步和交付物，而不是只有滚动日志。

Agent 目录用于接入和排查。显示节点、原生运行时、版本、能力、可用性、权限和适配器健康状况。原生模型、插件和凭据管理仍留给对应节点；管理 App 可以发起经授权的操作，但不复制整个运行时管理系统。

前端后面必须有非模型的管理服务

主助理可以提议分工，但不能靠它“记得自己刚才说过什么”来保存任务。需要一个持久化服务记录任务、执行尝试、授权、产物引用和事件，界面据此生成状态。模型负责理解与解释，代码负责校验和提交状态变化。

每条状态需要标记来源：执行端确认、监测观察、模型推断、等待核实。如果 Agent 只说“应该完成了”，可以展示为待核实，不能自动变成已验收。对于无法观测的第三方执行者，系统应承认验证能力有限。

对话记录、长期记忆、任务账本也要分开。用户可以清理聊天，任务仍可追踪；忘记一个个人偏好，不应抹掉已经批准过某次操作的必要审计记录。数据保留期限、删除和导出应有独立规则。

五、开源产品：借鉴不同工作面，避免叠加多套管理系统

以下比较只依据本次版本化文档，不是安装实测或质量排名。“需要验证”表示资料没有证明适用于本项目，不表示该项目不存在相应功能。

产品	资料确认的主要工作面	可借鉴或复用	用于本项目需要验证
Reason Network	发现跨机器的实时 Agent 会话并互发消息	会话目录、轻量接入、消息注入分级	自主基础设施、稳定会话身份、DSH 唤醒、任务语义
Paseo	桌面和手机控制多个编程 Agent	设备连接、移动端、原生运行时适配	DSH 适配、已有循环接入、长期任务归属
Happy	多模型会话、移动同步；旧 CLI 包装原生编程工具	移动体验、设备配对、加密同步	使用旧包装器还是新 harness、服务依赖和权限边界
Paperclip	目标、任务、审批、预算和 Agent 管理	任务与审批模型、持续跟进、适配器体系	个人使用的复杂度，远端既有循环如何接入
Routa	工作区、Spec、看板、实施与验证角色	任务证据、验收边界、工作区管理	编程工作流能否缩减成通用个人助理
DS Bot	DSH 上的长期 Bot、主 Bot、群聊与能力配置	长期对话、主助理身份、已有 DSH 集成	跨节点协议、组合兼容、严格任务账本

来源为本次保存的仓库快照：Reason Network、Paseo、Happy、Paperclip、Routa、DS Bot。

Reason Network：适合研究通信，但不能直接等同于委派系统

截至本次快照，其默认引导走 Reason 登录，独立引擎仍保留无登录的初始化／加入方式；自建 relay 是单独的网络配置。DSH 在设计中列为主动收信模式，没有提供会话 ID 时还存在基于进程识别的限制。无账号、自建网络、稳定会话和任务可恢复，需要分别验证。Reason Network DESIGN

它目前使用 iroh；在限定 Tailscale／Tailcat 的产品里，不应假定可以直接换掉底层。合理做法是进行一个独立接入验证，检查是否需要额外网络机制或深度分叉，再决定采用。

Paseo、Happy：移动体验已经有直接参照

Paseo 的本次 README 明确支持本地 daemon 与多个客户端；不启用其设备配对 relay 时，可通过 Tailscale 等方式连接。这使它成为移动管理面的直接候选，但并未证明 DSH 能零适配接入。Paseo 快照 README

Happy 需要区分旧 CLI 和新的 Happy Agent／Harness：前者包装已有 Claude Code、Codex，后者覆盖更广的多模型工作方式。选择时要确认是在接入原有循环，还是更换执行运行时。其隐私文档还将可选语音的数据流与加密同步分开说明，因此“消息端到端加密”不能自动扩展为“语音也全程同样加密”。Happy 快照 README、隐私说明

Paperclip、Routa、DS Bot：三种不同的管理重心

Paperclip 的委派文档把目标、计划、审批、任务和心跳跟进连在一起；适合研究任务管理后端，而不是只借鉴一个聊天组件。Routa 则强调工作区内规划、实施、核验的边界，适合参考“怎样算交付”。Paperclip 委派文档、Routa README

DS Bot 更接近已有 DSH 项目的渐进路线。本次包清单版本是 0.2.3，不能继续用先前版本的兼容结论。它的主 Bot 权限很高，复用时应核查如何与目标节点的本地权限相交，而不是默认主 Bot 获得所有机器的完整权限。DS Bot 包清单

建议只选一套主要任务管理后端、一套主要对话界面。 不要把这些产品全部叠起来，让多个数据库同时宣称自己拥有任务状态。已有 DSH 项目可以先验证 DS Bot 的对话面，同时用 Paperclip 的任务模型校准需求；若前者扩展过重，再比较整体采用 Paperclip 或 Paseo 的替代路线。

六、可靠性：让断线、取消与重试具有可理解的含义

一个具体的失败过程

助理向远端发送“生成报告并发布”的任务。远端接受后执行发布，但返回结果时网络断开。管理端没有收到结果，不能推断没有执行；如果立即重发，可能重复发布。这个问题不会因为把自由文本改成 JSON 就消失。

建议的处理过程是：产品任务及执行尝试先记录 → 取得接受回执或保留“是否接受未知” → 执行端记录结果 → 重连后查询原句柄 → 核查副作用 → 再决定是否重试。如果对方不支持去重、查询或效果核验，就把限制告诉用户，而不是承诺恰好执行一次。

故障场景	产品应显示什么	不应做什么
节点休眠	最后确认状态、最后更新时间、等待节点	一直显示实时加载
收不到接受回执	接受情况待核实	自动派给另一台机器重复执行
发布完成但结果丢失	查询原任务或外部发布记录	直接认定失败并重发
请求取消	已请求取消，等待确认	按下按钮就显示已取消
撤销权限	阻止后续请求，标记在途操作待核查	宣称已经撤回不可逆的外部效果
主助理重启	从账本恢复任务列表并与执行端对账	让模型凭聊天记忆重建全部事实
用户修改需求	新修订号、旧任务处置记录	把迟到的旧结果混入新需求
接口升级不兼容	明确降级能力或拒绝执行	伪造正常状态或猜测字段

LangGraph 的 checkpointer 和 store 表明，会话恢复与长期记忆本身可以复用社区持久化机制。但本地运行时有 checkpoint，不代表另一台机器的委派已经具备恢复契约；两者需要显式关联。LangGraph Persistence

响应速度也要分层测量。界面能操作、请求被接受、Agent 开始工作、得到第一个有用结果、产物可下载，是五个不同时间点。不能把“100 毫秒返回了一个空回执”当作任务完成速度，也不能把模型推理时间全部归为通信开销。

七、论文机会：把协议约定变成可证伪的研究问题

“多个 Agent 能聊天”“安装一次就连接”“有一个管理界面”都已有先例。要形成论文贡献，需要说明新增机制解决了什么已知方法不能可靠解决的问题，并在控制条件下比较，而不是用功能数量证明先进。

相关工作会约束新意的表述

工作	与本方向的关系	对研究设计的约束
Internet of Agents，2024	已研究异构 Agent 集成、组队与会话控制	不能把连接异构 Agent 本身作为首次贡献
Agora，2024	研究不同通信形式与效率的选择	“动态选择通信方式”同样已有研究
MAST，2025，v3	把多 Agent 失败分为系统设计、协同失配、任务验证等类别	不能只测消息能否送达；完成判定也要测
MCP／A2A 比较，2026	同一场景下比较两种协议的工程责任	需要公平场景；它早于 MCP 7 月 28 日版本，不能据此断言当前 MCP 没有任务支持
AgentDojo，2024，v3	评估不可信工具内容中的提示注入	同伴消息不能自动升级成用户授权；安全与正常任务效用都要衡量

本次检索还发现 ProtocolBench／ProtocolRouter 相关 OpenReview 条目，但正文访问遇到验证页，未完成版本与结果核查。因此本文不据此做性能或新颖性结论；正式选题前必须继续补查，当前调研不是完整查新。

最值得先验证的研究主线

优先研究：能力差异明确、连接不稳定时的跨运行时委派恢复。

假设是：在现有 A2A 或 MCP Tasks 上增加经过一致性检查的接入配置档，明确接受回执、去重能力、任务归属、取消确认和结果核查，可以减少重复副作用与错误的完成报告，同时保持正常任务完成率和接入成本。

这仍是待验证假设。尤其 A2A、MCP Tasks 已经覆盖部分语义，研究必须与正确实现了现有机制的基线比较，不能故意选择一个不持久化任务的弱实现。

另外两条可保留为后续方向：一是 Agent 能力描述与真实行为不一致时的协商和降级；二是面向人的注意力管理，让助手只在必要时打断用户，并让汇总忠实于可核查状态。前者需要多运行时互操作测试，后者需要用户研究和来源一致性评价。

建议的验证设计与发表门槛

以下是未来实验计划，本次没有执行。

项目	建议设计
基线	普通消息协调；正确持久化的原生 A2A；当前 MCP Tasks；增加接入配置档的方案
首轮样本	至少两种独立运行时、十类故障轨迹；先验证测量链路，不做显著性结论
扩展样本	再加入第三种独立运行时、不同网络条件和未参与开发的适配器；样本量由效应估计与功效分析决定
固定变量	模型、提示、工具、任务、权限、预算和重试策略；协议自身带来的差异单独记录
注入故障	接受回执丢失、执行后断线、事件重复、重启、取消竞态、撤权、旧结果迟到、版本不兼容等
主指标	副作用完成且正确验收的任务数／全部任务数；重复副作用次数／副作用尝试数；错误完成报告数／全部完成报告数
恢复指标	网络恢复到管理端重新取得可信任务状态的时间，报告分布和失败样本，不只报均值
成本指标	去掉模型推理后的通信延迟、字节量；人工操作次数、接入耗时和版本升级所需修改
消融	分别去掉接受日志、去重、能力检查、来源标注、取消确认，定位收益来自哪个机制
威胁范围	区分可信执行者的崩溃、错误适配器与恶意 Agent；不能用前两者实验声称抵抗第三者

对副作用是否发生，用可复查的操作日志或受控环境中的最终状态判定；不要只用 LLM 阅读聊天后评分。拒绝所有任务可以让重复率很低，因此安全指标必须与正常完成率一起报告。

进入论文写作的门槛，应是多运行时真实互操作、可公开的故障轨迹、可复现基线、消融与明确威胁模型。发出草案、提供 SDK 或通过几次演示，并不证明学术新意。

八、产品实施边界与阶段门槛

对于已有 DSH／Hub 的项目，建议保留各节点完整 DSH，把长期主助理部署为独立产品节点。Hub 继续只负责配对、连接、授权和转送；任务正文、用户记忆和业务记录归助理服务，执行记录与文件归实际执行节点，模型凭据留在使用它们的节点。

Tailscale／Tailcat 可以作为明确允许的网络依赖。若采用 Reason Network，仍需单独验证其自建身份与发现／中继路径，以及它与既定网络边界的关系。不能把“消息加密”替换成“不依赖公共基础设施”的证明。所有升级应经过兼容验证并保留回退版本，避免多个运行时自动升级后同时破坏接入。

阶段	做什么	通过什么证据才进入下一阶段
接入验证	DSH 加一个真正不同的 Agent 运行时；邀请、连接、能力分级	用户无需转述即可定向交互；不支持的能力被明确拒绝
个人助理闭环	一位主助理、任务与待处理事项、委派和产物	网页关闭后不丢任务；重连、取消和失败均可解释
最小协议草案	固化两个适配器共有的契约与一致性测试	第三个适配器接入时不要求修改协议核心
研究验证	独立基线、故障注入、消融、用户研究	证明收益、成本和失败边界，再决定论文主张

第一版建议暂缓全量会话聚合、跨运行时记忆迁移、公共 Agent 市场、自动生成通信协议，以及让 Agent 自主修改权限。这些都可能有价值，但不会替代接单、跟进和验收的基本闭环。

产品验证要问什么

找符合目标人群的用户，让他们实际完成“接入第二台机器、交出一个任务、处理中断、找回产物”这条链路。观察配对耗时、必须离开管理 App 的次数、为取得状态主动追问的次数、错误理解状态的次数，以及任务质量是否达标。不要仅询问他们是否喜欢一个概念。

现阶段最有用的产品指标是：已接受任务的正确验收率，以及每个完成任务需要多少次人工追问与救援。 可以少接入几个 Agent，先让这些指标可信；节点数量、会话数量和自动互聊条数不应成为成功的替代指标。

九、资料版本与证据范围

本文规范核查基线为 A2A 1.0.0、MCP 2026-07-28、MCP Tasks 扩展的同日期稳定 schema，以及 ACP v1。AG-UI 按 2026-10-28 的官方介绍核查。动态文档链接可能继续变化，因此产品代码仍应固定 SDK、协议版本和适配器版本。

仓库	文档快照提交	本次审阅材料
Reason Network	29a96dc22dc0	README、DESIGN、Cargo 清单
Paperclip	cff331f6ca0a	README、委派指南
Paseo	986687b8fd46	README
Happy	85aa1baf5a78	README、隐私说明
Routa	9dc7b7be8fa9	README
DS Bot	4a7b55069ad3	README、包清单
MCP Tasks	b3d28aceaa6d	扩展 README 与官方文档
ANP	0837cfdfaf4d	README

这些资料能证明项目公开描述的定位、接口和版本，不能证明生产稳定性。本文没有给开源项目打性能分，没有把目录中的能力声明当作执行保证，也没有把建议架构写成已经部署的产品。

三幅图均为本文原创、由确定性 SVG 生成的设计示意；不使用第三方产品截图。可下载研究快照与内容校验记录，并从公开源码仓库取得文章、图源与生成脚本。相关背景可继续阅读DSH 架构评估和可移植 Agent 状态；它们各自的证据日期与本次调研不同。