Personal Agent 架构设计思考（一）

2026-02-09 · Junyi Yan

数字分身 App 以下代称为 Charon

Charon = 一个面向用户的 Lead（数字分身）+ 一组内置系统 Agent（协调/记忆/质量/安全/交易/呈现）+ 一个可扩展的外部执行网（A2A Mesh）+ 可解释可回放的 UI（A2-UI）

Personal Agent 一次任务的时序（含“Claude Code 作为执行单元”）

把系统拆成两层：对外互操作用开放协议（A2A/UCP），对内协作与效率用你自己的“团队协作/编排层”。

借鉴 Claude Code 的 Agent Teams ，把“协作效率”做成产品级原语：共享任务列表（含依赖/自领任务）、队友邮箱式通信、显式生命周期管理、以及把 Lead 限制为纯协调的 delegate mode 等。这些都不是 A2A 重点覆盖的部分。

长期可扩展的架构蓝图

包括哪些用 A2A/UCP 标准，哪些是“域内”的“Team Coordination Plane”，以及怎么把 Claude Code Team 当作其中一个执行单元接进来。

从 Claude Code Agent Teams 借鉴什么（相对 A2A 的“优势点”） A2A Protocol 解决的是“异构 agent 怎么互通”：AgentCard 描述能力、Task/Message/Artifact 的结构化交换、长任务/流式状态等。它强在开放互操作，但它不会替你决定“团队怎么协作最有效”。 Claude Code Agent Teams 强在“协作与管理原语”（可以把这些抽象进 Charon，而不是照搬 Claude 实现）：

  1. 共享任务列表 + 依赖关系 + 自领任务/避免抢活（可以做成任务 DAG + claim/lock 机制）
  2. agent 间直接消息（mailbox/inbox，而不是只能回报给 lead）
  3. 显式生命周期控制（启动/停止/收敛，避免“失控的并行”）
  4. delegate mode 的思想：Lead 不干活，只做拆解/验收/汇总（强制团队结构不坍塌）
  5. 把“上下文工程”当作一等公民：信息不断增长时，必须做精炼、分层、回写与再注入，对应 Charon 的 Memory 体系 1~4 是 Charon 的“Team Coordination Plane”，5 是“Memory & Context Plane”，用 A2A 把外部异构 agent 织成“Execution Mesh”。

总体架构（Lead App + Coordination Plane + Execution Mesh）

核心目标：Lead 负责“理解意图 + 任务拆解 + 调度 + 质量门禁 + 记忆沉淀 + UI 交互”；执行由各种异构 agent/工具完成；商业闭环用 UCP（面向商家/支付/售后）标准化；所有动作可观测、可回放、可评估。

系统分成 6 个层面（plane），每个层面都有明确扩展点：

1. A2-UI 平面（Agent-to-User Interface）

  • 形态：对话主入口 + 任务看板（DAG）+ 运行轨迹（trace）+ 记忆视图（可解释的“我为什么这么做”）+ 产物库（Artifacts）。
  • 关键：UI 不只是聊天框，而是把“Team/Task/Run/Memory”可视化，降低用户“操作太多”的学习成本（很多操作由 Lead 自动完成，UI只呈现必要看板）。

2. Lead Plane（Charon/主 Agent）

  • Intent Router：把用户意图分类到（研究/写作/编码/浏览器操作/商务交易/系统维护…）
  • Team Builder：动态组队（选哪些 agent 来做这票活）
  • Quality Gates：计划审批、结果验收、风控策略（包括你后面要接的支付风控）
  • Memory Steward：把过程沉淀成 episodic/semantic/procedural 等，并决定下次注入什么

Lead 只做四类事，其他一律下放：

  • 意图澄清与目标定稿：把用户自然语言转成“任务目标 + 约束 + 成功标准”
  • 决策与取舍：当出现多方案、成本/风险冲突、需要你确认时，做选择或发起一次最小追问
  • 关键审批：支付/生产变更/数据外发等高风险节点的“同意/拒绝/改条件”
  • 最终合成与叙事：把 artifacts、证据、风险、下一步用最少交互的方式呈现给用户

3. Coordination Plane 借鉴 Claude Code Teams的层,把下面这些做成平台原语（数据库对象 + API）：

  • Team：一次目标驱动的协作单元（带成员、权限、预算、截止时间）
  • Task（DAG）：可分解、可依赖、可 claim/lock、可重试、可回滚
  • Mailbox：team 内消息/广播/@，支持 thread 与引用 artifact
  • Lifecycle：创建/扩容/收敛/归档（避免并行发散） 这层不依赖具体模型，所以天然适配异构 agent。

Coordination Plane 实质上是一组内置系统 agents，负责把 Lead 的意图变成可控的协作执行，并对外部 Mesh 做统一调度。它包含（但不等同于）你之前说的“平台原语”，只是这些原语背后是 agent 在跑。它拥有内置 Skills/Tools、懂得如何拆解与调度，并把一切变成可观测、可回放、可治理的过程。但它不替代 Lead 的人格与决策主权。

最小内核由 6 个系统 agent 组成（后续再扩展）：

  • Planner Agent：把目标编译成 Task DAG（节点、依赖、验收标准、预算、所需能力标签）
  • Dispatcher Agent：组队与派单（内置 skills vs 外置 A2A agents），并发控制、claim/lock、超时重试
  • Context Engineer Agent：构建 Context Pack（从 Memory/Artifacts 抽取最小充分上下文），并在任务结束后做蒸馏回写
  • QA/Verifier Agent：质量门禁（计划门禁、结构化验收、引用/证据一致性校验、对比评测）
  • Policy Guard Agent：权限与风控（能力令牌、数据出域策略、支付/删改/生产变更审批策略）
  • Artifact Librarian Agent：产物版本化、索引、同步（让“手机可读、原件在家里电脑/网盘”成为默认能力）

4. Execution Mesh（异构执行网） 这一层 A2A 互操作，把 OpenClaw、CUA 浏览器代理、Claude Code Team Unit、以及未来任何第三方 agent 统一成可发现可调度的能力节点。Coordination Plane 是 Mesh 的“唯一入口”，Lead 不直接碰 Mesh。

  • A2A-native Agents：直接按 A2A spec 接入（AgentCard + Task API
  • Wrapped Agents：不支持 A2A 的（单独包一层 A2A adaptor）
  • 类似 Claude Code Team 作为一个执行单元：对外表现为一个 A2A agent（或一组 agent），内部再用 Claude Teams 去并行干活（不需要把“外部 agent”变成 Claude teammate，反过来把 Claude team 封装成 A2A 能力节点即可）

5. Memory & Context Plane（Charon 的差异化护城河） 把 Memory 明确分成“存储层”和“注入层”两件事：

  • 存储层：Identity / Semantic / Episodic / Procedural / Working（短期）等分区，外加 Artifact 索引与向量检索
  • 注入层（Context Engineering）：针对不同任务类型，自动组装“最小充分上下文包”（避免把所有记忆都塞进 prompt），并周期性精炼（summarize / compress / distill） 另外：所有外部 agent 的产物都要“结构化回写”，否则记忆会被垃圾淹没（这也是 Claude Teams 强调的“合成结果”思路）。

6. Commerce Plane（UCP + 支付/履约）

  • 当任务进入“买/付/退/售后”域，Lead 把它切换到 UCP 交易编排：发现商家能力、协商、下单、支付、查询订单、售后等，用标准化 primitives 跑完整链路
  • 把“支付与风控”当作强门禁：必须走审批策略、必须可追溯、必须可撤销/回滚（至少逻辑回滚）。

Lead Agent 和 Coordination 都属于 App 的内置 Agent 系统，两者的边界是：

  • Lead 是“面向人的主叙事与决策主体”
  • Coordination Plane 是“面向任务与资源的操作系统（Agent OS）” Lead 不直接调外部 agent、不直接管并发与锁、不直接写 Memory；它只通过 Coordination Plane 提交目标、审批关键决策、接收进度与结果，再把结果讲给用户听。

分层后的“工作流”也会更干净

  1. 用户只跟 Lead 说话
  2. Lead 把“目标/约束/成功标准”提交给 Planner
  3. Planner 生成 DAG，必要时请 Lead 做一次“最小确认”（而不是反复问问题）
  4. Dispatcher 根据 DAG 调度：内置 skills 先跑，外置 A2A agents 并行跑
  5. QA/Policy 在关键节点卡口（计划、出域、支付、最终交付）
  6. Artifact 回到 App，Lead 只负责最终“讲清楚 + 让你一键拿走产物”

为什么这个拆分很重要（对可扩展目标直接有收益）

  • 可以更换 Lead 的“人格/语气/模型”，而不影响底层 OS 的稳定性；甚至以后支持多个 Lead（工作 Lead / 生活 Lead）共用同一套 Coordination OS。
  • 可以把 Coordination Plane 做成“可测试的系统”：同一个目标输入，DAG、调度、门禁、产物结构都可回归测试；Lead 只是前台交互与决策层。
  • 能自然实现“更少交互”：很多复杂性都由 Coordination OS 自动消化，Lead 只在真正需要你的地方出现。

关键数据模型

平台内部统一 6 类一等对象，让系统可扩展的“通用对象”（降低后续扩展成本）：

  • Agent：以 A2A AgentCard 为基座，外加自己的标签（成本/可靠性/权限域/工具集/擅长任务）
  • Team：目标、成员（Agent IDs）、权限策略、预算（token/费用/时间）、工作区（artifact namespace）
  • Task：DAG 节点（input spec、expected output schema、owner、状态机、依赖、重试/回滚策略）
  • Message：线程化对话（人-Lead、Lead-agent、agent-agent），必须可引用 Task/Artifact
  • Artifact：版本化产物（文件/结构化 JSON/引用链接/截图/报告），可被记忆索引
  • Run/Trace：一次执行的全链路可观测数据（用于回放、评估、归因、训练数据沉淀） 这套对象能实现 Claude Teams 的“任务看板 + mailbox + 合成汇总”，同时又能让 A2A agent 通过标准 Task/Artifact 接入。

执行流程（从用户一句话到异构团队完成任务）

典型链路：

  1. 用户在 A2-UI 对话：给目标与约束
  2. Lead 做 intent 识别 → 生成 Task DAG（含依赖与验收标准）
  3. Team Builder 选 agent（本地工具 agent、浏览器 agent、Claude Code 执行单元、研究 agent…）
  4. 调度器按能力/成本/时延分配任务并下发（对外用 A2A）
  5. 执行中产出 artifacts → 回写 → 触发质量门禁（plan gate / review gate / policy gate）
  6. 通过后合成最终答复给用户，同时把可复用的程序性经验写入 Procedural Memory
#人工智能#Personal Agent
https://junyiyan.xyz/posts/feed.xml