Personal Agent 架构设计思考（二）

2026-02-26 · Junyi Yan、GPT 5.2 Thinking

关键词：多端控制台（A2-UI）、对外协作协议底座（A2A Profile Hybrid）、任务图与交付包、门禁与审批、审计回放与撤销、记忆养育、交易对象域（UCP ）

真正把 Personal Agent 用进工作流，会给它三类“活”：改东西、找人干活、记住东西。改文件、发消息、下单，都会改变外部世界的状态；委派外部执行器，会引入新的不确定性；写入长期记忆，会让今天的选择影响明天的行为。它们的共同点是：都有后果，而且后果常常不完全可逆。

所以一个可托付的 Personal Agent，需要像系统一样被设计：它要能在关键点停下来让点头，也要能在事后把链路回放清楚，并尽可能提供“撤回影响”的手段。否则能力越强，风险越像“隐形成本”，只会越来越不敢让它自动跑。

本文试图用三个视角把问题说清楚，并把它们直接融进三层闭环语义里（不做旧框架的映射表）：

状态变更视角：把一次执行当作一个 run，用事件流与产物清单让“做过什么”可查；用“可撤销分级”让不同动作配得上不同门禁。
协作合同视角：跨节点协作更依赖共同语言，不能只靠“差不多就行”。A2A Profile（Hybrid）不属于三层之一，但为 agents team 模式提供任务/结果/证据、审批与见证、最小披露（capsule）与对拍（conformance）这些底座，决定外部结果能否被稳定回收与验收。
产品信任视角：多端形态更像是把门禁、审计回放、撤销、记忆写入这些入口放到用户手边。文中用 A2-UI/UCP 作为占位符举例，强调语义位置，不押注某一种生成式 UI 协议或商业化方案。

对应到三层闭环：编排层把目标推进成一次可交付（交付包）；治理层把对象/门禁/审计/撤销写成硬语义；自我层把记忆从“能检索”升级为“能负责地成长”（候选、证据、对账、写入、激活、衰减/撤销都有规矩）。在产品形态上，以“移动端 + 桌面端 + 网页端 landing page/docs”作为例子。不同终端的交互密度会不同，但共享同一套对象语义与审计/撤销纪律。

本文聚焦 Personal Agent 控制平面本身，不讨论外部执行 Agent（例如 OpenClaw）内部如何做“隔离式多 worker 编排”。那是 worker 的工程问题，不会反向污染控制平面的对象语义与责任边界。

一、为什么 Personal Agent 需要“控制平面”

当 agent 还停留在“回答”，可以用对错与表达去评价它；一旦它开始“执行”，评价方式会变得更像工程：动作有没有越界，出了问题能不能停，事后能不能说清楚，影响能不能撤回。控制平面更关心两件很现实的事。

第一，可撤销不是二选一。删一个临时文件、改一行代码、发一封邮件、下一个订单，它们的撤销成本完全不同。把动作按可逆性分级，再把不同级别挂到不同门禁与审计要求上，是把能力带进现实世界的起点。

第二，协作会放大不确定性。网络会断、远程会卡、工具会失败、外部结果回流可能缺证据，甚至带来安全风险。没有统一的对象语义与对拍口径，很难在多端、多节点场景里把责任链捋清。

因此 v2 的策略比较“老派”：先把对象/门禁/审计/撤销四件事写清楚，让系统先可控、可回放、可撤回；自动化程度与体验再迭代。

二、融合后的三层闭环（不做映射，直接内生）

三层更像同一个闭环里的三个阀门：编排层负责把目标推进到可交付形态，治理层负责把高能力收敛在可追责边界内，自我层负责让系统在时间里保持连续并可纠偏。

在这个框架里，A2-UI 与 Lead 也可以被更具体地理解：

Lead 更接近编排层的一段“面向用户的机制”：负责把自然语言目标定稿成 GoalSpec，提出关键决策点，并在交付时把 DeliveryBundle 讲清楚。
A2-UI 更接近治理语义对人的呈现与交互外壳：它让门禁、审批作用域、审计回放、撤销与记忆写入这些动作有明确入口，而不是散落在对话与实现细节里。

此外，三层闭环讨论的是控制平面的运行时语义；但一旦进入外部协作，还需要一套“对外可验收”的接口语言。对我们来说，这个底座来自 A2A Profile（Hybrid）：它不替代三层，但为外部 Agent 的协作、回流与对拍提供了共同语义与证据形态。

A2A Profile（Hybrid）：基于 A2A 协议的 Personal Agent 2 External Agents 拓展协议。

2.1 协议与生态：A2A Profile（Hybrid）是协作的地基

三层闭环解决的是“系统内部如何收敛”，协议解决的是“跨系统如何对齐”。没有协议约束，生态协作很容易走向两种极端：要么只认自然语言的“看起来差不多”，要么每家都发明自己的一套产物/运行记录/审批字段，最后很难对拍、也很难验收。

在本文的语境下，A2A Profile（Hybrid）更像是协作的底座语言，主要解决三类问题：

任务要说清楚：让我做什么、怎么算做完、要交付哪些东西、需要什么证据（任务/结果/证据）。
授权要说清楚：谁允许了什么、作用域多大、有效期多久、能不能撤销（审批台账 + 见证/来源链）。
外发要可控：只发最小上下文，带 TTL 与撤销口令（capsule）。

放到 agents team 模式里，它还能支撑更“产品化”的动作：健康检查、能力探测、兼容对拍。在控制台里看到的“这个远程节点现在能做什么、它回流的证据长什么样、出了事怎么回放与追责”，背后都需要一套可对齐的 profile。

它不属于三层中的任何一层，但会直接影响三层能否闭环：编排层能否稳定回收外部产物，治理层能否跨节点表达授权作用域，自我层能否把回流结果先落到候选层、再经过写入门禁进入长期自我。

Personal Agent 三层架构）

编排层负责把目标推进成一次“能交付的结果”，治理层负责在关键动作前后拦住风险、留下可回放的记录、并提供撤销入口，自我层负责把可信经验沉淀成可迁移资产并控制记忆写入；Lead 是编排层面向用户的定稿与决策机制，控制台 UI（这里用 A2-UI 指代这一类形态）把门禁/回放/撤销/记忆这些入口摆到明面上。

三、编排层（Orchestration）:把目标编译成可交付闭环。

3.1 v2 必须写清的对象

如果编排层只剩下一条线性聊天记录，它在多任务、跨端、远程委派与回放场景里会很吃力。v2 建议把编排层的最低闭环收敛为以下对象族：

目标定稿（GoalSpec）：Lead 输出的“目标定稿件”（目标、约束、成功标准、交付物期望、风险初判）。
任务图（TaskGraph）：把 GoalSpec 编译成 DAG 或等价结构。每个 TaskNode 都必须可独立验收，并挂载门禁点（Gates）。
上下文预算（ContextBudget）：上下文往往是稀缺资源。预算需要显式分块预留（policy/plan/self/evidence），否则治理约束容易被历史与细节挤掉。
执行记录（Run + EventLog）：一次执行更像一个可回放的 run，而不只是一次回答。事件是事实的前置形态，UI 状态应消费事件流，而不是猜测运行时。
产物与清单（Artifacts + Manifest）：产物更适合被当作“可验收对象”来管理，而不是对话里的附件。Manifest 要能回答：它是什么、在哪里、由哪个事件生成、与哪个 run 关联。
交付包（DeliveryBundle）：面向用户的一次性交付包（总结 + 产物索引 + 证据入口 + 风险与下一步）。它不替代 Result/Evidence，而是把它们组织成可用视图。

3.2 三模式：同一闭环的三种运行态

Charon 在 v2 同时支持 session、project、agents team 三种模式。产品最终更可能是移动端为主、桌面端配套、网页端承载 docs 的形态；但不管入口在哪个端，这三种模式的运行时语义应当是同一套对象语义的不同视角：

session 更像“连续对话 + 工具执行”的 run 工厂。pi-mono 的 session tree、compaction、branch summary、steer/follow-up 语义，为“可打断、可分叉、可回放”提供了非常工程化的底盘。
project 把 workspace 变成一等上下文域。比起“把文件都塞进 prompt”，更重要的是让“文件引用、变更、证据与回放”都能被 TaskGraph 与 ArtifactManifest 描述。
agents team 把远程节点当作可管理对象而不是 URL 收藏夹：健康、能力探测、适配、委派合同、回流证据，最终都回收到本地的 artifacts 与事件流里。模式可以不同，但交付必须一致：最终仍然以 DeliveryBundle 交付，并能从 bundle 回放到事件与证据链。

3.3 Gates：把“停下来”变成运行时语义

Gates 的关键价值在于：把“该不该继续”从 prompt 临时问答提升为运行时语义。v2 建议至少固化三类门禁：

Plan Gate：执行前范围与参数确认，防止跑偏。
Policy Gate：外发、支付、破坏性动作、敏感数据访问等高风险动作拦截。
Review Gate：交付前的结构化验收与证据完整性检查（Result/Evidence/Witness 是否闭环）。当 gate 触发时，系统不应“继续跑并在事后道歉”，而应进入等待态，并在 A2-UI 把“等待什么”说清楚。

四、治理层（Trust）:把对象/门禁/审计/撤销写成硬语义。

治理层不只是安全提示，也是一段主逻辑：它把编排层的动作语义与自我层的边界语义编译成可执行策略，并把决策写进审计底盘。

4.1 风险与策略：policy pack 必须可组合、可覆盖、可解释

经验上，治理失败常见于两种情况：

规则散落在代码与提示词里，导致“看起来问了确认，但其实问的不是同一件事”。
allow_always 没有 scope，授权被悄悄扩大，最后只能靠事故复盘补洞。因此 v2 建议把 policy pack 至少拆成 defaults/rules/scopes/exceptions，并明确覆盖顺序（全局 < 项目 < 会话）。当某个动作被拦截或需要审批时，系统应能指出命中哪条规则，而不是让用户猜。

4.2 审计与回放：witness/provenance/ledger 必须能串成链

长期托付的底线是“说得清发生过什么”。治理层至少要能把以下对象串成可回放链路：

关联编号（correlation_id）：贯穿 task、approval、witness、artifact 的主键。
审批台账（Approval Ledger）：授权决策台账（决策、scope、TTL、撤销、回放引用）。
关键动作见证（Witness Events）：外发、工具调用、写入、UCP 资金动作等高风险事件的可追责记录。
来源链（Provenance Chain）：引用链，防止“证据被悄悄换掉”。回放应当能走通一条固定路径：DeliveryBundle → Result/Evidence → Witness/Provenance → 原始工具输出或来源指针。

4.3 UCP（交易/支付/履约）：v2 可以后置实现，但必须先钉语义

这里用 UCP 作为“交易/支付/履约对象域”的代称，目的是把对象与约束讲清楚，而不是暗示只有这一种实现方式。也可以把它理解成 Agentic Commerce 类问题的一种表达：只要代理开始参与商业动作，治理层就需要更早、更硬地定义边界与回放口径。

UCP 的难点往往不在于“接哪个支付渠道”，而在于它天然把三种风险绑在一起：

资金风险（扣款、退款、争议）。
承诺风险（对外承诺了什么、何时交付、交付不达标怎么办）。
外部协作风险（交付往往要委派给外部执行器与服务）。

因此 v2 的 UCP 必选语义是四件事：对象、门禁、审计、撤销。

对象（最小集合）：

Quote：报价（价格、范围、有效期、条款）。
Order：订单（承诺交付什么、由谁交付、何时交付、验收口径）。
Payment Authorization：支付授权（金额上限、收款方、时间窗、用途绑定）。
Settlement：结算（资金实际流动的凭证与可追溯指针）。
Refund：退款/冲正（与 settlement 的关联与原因码）。

门禁（默认策略）：

任何导致“资金承诺或资金流动”的动作默认触发 policy gate + approval（优先 allow_once）。
允许的 scope 必须绑定金额、收款方、有效期与关联 quote/order，防止授权被挪用。

审计（最低要求）：

所有 ucp.* 事件必须能回指 witness：用户看到过什么、同意过什么、当时的风险摘要是什么。
ledger 必须能把 quote/order/payment/settlement/refund 串成链，并能回放到 correlation_id。

撤销（必须是一等能力）：

撤销授权（阻止未来扣款）。
取消订单（阻止未来履约）。
在能力允许时发起退款/冲正；无法完全撤销时必须显式标注“不可逆影响”并留下处置记录。

4.4 生态协作：对外只发 capsule，回流必须带证据

治理层在生态协作里通常需要守住两条纪律：

对外只发 capsule（最小披露 + TTL + revoke），不外发原始证据包与长期记忆。
回流必须带 evidence refs。没有证据的结果只能进入候选层，不能驱动高风险动作，也不能写入长期自我。

这既是协议互操作要求，也是现实世界的事故防线。开源生态的“技能市场化”会放大供给，也会放大攻击面，治理层必须默认把外部输入视为不可信并可追责。

五、自我层（Self）:把记忆从“能检索”升级为“能负责地成长”。

自我层的任务更偏向于“在时间里保持连续身份，并能纠偏”。v2 的取舍是把记忆写入从默认动作变成治理动作，并把写入与注入解耦。

5.1 身份资产：宪法/自传/表达风格是长期锚点

在长期系统里，把身份资产当成可读写、可审计、可回滚的文件，比把它当成一段隐藏提示词更稳。

constitution：价值排序与硬边界（永不外发凭据、未授权不支付、不可逆动作必须确认）。
biography：近期状态与时间线摘要（只给指针，不塞原文证据）。
voice policy：表达风格与对外表态规则（避免“语气一致但越界表态”）。

关键纪律是：高影响资产变更必须可回滚，并且默认走治理层审批或用户确认。

5.2 Parenting 状态机：候选 → 证据 → 策略 → 对齐 → 提交 → 激活 → 衰减/撤销

记忆的生命周期不应是“召回即注入”，而应是一条明确流水线。一个可落地的最小状态机是：

候选（Candidate）：从 run 中抽取候选信号（偏好、流程、实体、经验）。
初筛（Screened）：基础筛除（敏感分区、黑名单模式、重复噪声）。
证据通过（EvidenceChecked）：达到证据门槛（能回指工具输出、来源或 evidence refs）。
策略通过（PolicyChecked）：通过 Trust 的 write gate（数据边界、脱敏、授权）。
对齐（UserAligned）：触及身份资产或存在冲突时，等待用户对齐/对账。
入库（Committed）：写入长期层（可审计、有 lineage），但默认不注入。
激活（Active）：在特定任务/阶段被上下文编译器选中注入（注入本身也应可回放）。
衰减/撤销（Decayed/Revoked）：衰减或撤销，停止默认注入并保留原因码。

这里有一条很实用的原则是 committed vs injected：写入进入长期层，不等于下次默认注入。否则一次噪声容易被放大成长期漂移。

5.3 迁移、导出与删除权：让“自我”成为资产，而不是锁在实现里

长期托付必须有主权工具链：可导出、可迁移、可撤销、可删除（在审计与合规允许范围内）。实践上建议把资产分三类：

canonical（必须迁移）：身份资产文件、自我 profile、长期记忆条目。
evidence（可选迁移）：精选 run/evidence/witness 片段与 checkpoints。
derived（不必迁移）：索引、缓存、队列（可重建）。

删除也必须拆开：canonical/derived/audit 不是同一种删除。v2 的最低要求是先支持撤销与降权（revoked/decayed）并阻止默认注入，在更严格场景再谈硬删除与合规策略。

六、多端形态下的最小技术路线（Charon v2 的工程落点）

这部分不打算写成 PRD，而是把三层语义落到“工程上应该长什么样”。它的目标是减少实现者在关键对象上各自发明同义词。

6.1 本地数据根：让可迁移资产收敛到一个目录

客户端形态（移动/桌面）的一个共同优势是“本地可控”。v2 建议把可迁移资产收敛到单一 data root，并按对象类型拆分：

sessions/：会话树（JSONL，append-only），承载 session 模式的对话与分支摘要。
runs/<run_id>/events.jsonl：本次 run 的事件流（UI 状态与回放的真相源）。
runs/<run_id>/taskgraph.json：任务图与门禁点（最小可回放表示）。
runs/<run_id>/manifest.json：run 元信息与 artifacts 索引（DeliveryBundle 的索引底盘）。
artifacts/<artifact_id>/：产物本体与 metadata（Result/Evidence/Failure）。
projects/<project_id>/：工作区绑定信息、上下文清单、checkpoints 元信息。
agents/registry.json、agents/probes/：远程节点 registry 与 health/capability 快照。
policies/：policy packs 与 override 记录（全局/项目/会话）。
ledgers/：approval ledger、ucp ledger（或等价结构）。
self/：身份资产与长期记忆（canonical files）。
exports/：交付包与诊断包导出结果。

6.2 事件命名：宁可少，但要稳定

事件类型建议使用前缀族，保持可扩展但不碎片化：

ui.*（用户操作）
run.*（run 生命周期）
task.*（任务节点）
gate.*（门禁触发/等待/通过/拒绝）
approval.*（请求/决策/撤销）
tool.*（工具调用）
artifact.*（产物写入/引用）
context.*（上下文编译/compaction/branch summary）
agent.*（委派、回收、改派、探测）
memory.*（proposal/commit/revoke）
ucp.*（报价/下单/授权/确认/撤销/退款）
error.*（失败分类、重试与降级）

6.3 控制台 UI：六个表面（A2-UI 作为一种命名/示例）

多端也不只是“同一套聊天界面的缩放”，更像是让控制平面的关键语义在不同端各有合适的呈现密度：移动端更适合随身确认与回放入口，桌面端更适合深度配置与工作区操作，网页端更适合作为 landing page 与 docs 的承载（以及只读分享与入口导航）。

这里把这类控制台形态暂称为 A2-UI，只是为了讨论方便。具体实现可以是传统 UI，也可以结合生成式 UI 组件与协议；但无论采用哪种技术路线，底层的 TaskGraph、门禁点、审计与撤销语义都应当能被看见、能被操作、能被回放。

在此基础上，v2 建议把 UI 至少拆成六个稳定表面（不同端可以合并或降级呈现，但语义尽量不丢）：

Chat：自然语言入口，但不承载全部运行时真相。
Task Board：TaskGraph 的可视化与状态机视图（INPUT_REQUIRED 的等待原因必须可读）。
Artifacts：交付物与证据入口（manifest 驱动，而不是消息附件）。
Replay：从 correlation_id 回放到事件与 witness/provenance。
Trust Center：审批与风险解释（scope、TTL、撤销必须可见）。
Memory View：已写入 vs 是否注入、冲突队列、撤销与回滚入口。

七、v2 的落地策略：先把硬语义跑起来，再堆能力

如果只能选一条 v2 的工程策略，我建议是：先把“对象/门禁/审计/撤销”跑通，再谈更强的自动化。因为这四件事很大程度上决定了系统能否被长期托付：没有对象就难以验收，没有门禁就难以守边界，没有审计就难以解释，没有撤销就很难在现实世界里承担后果。

八、案例速写：用具体系统校准“控制平面语义”

下面这组案例不做产品评测，也不复述功能清单。我更在意的是：当一个系统开始替“把事跑起来”，控制平面会被迫补上哪些硬语义，才能让它进入可托付状态。

8.1 OpenClaw：强执行器会逼把“回收闭环”做硬（技术侧）

OpenClaw 这类开源执行器很像“打工人”：它擅长在具体环境里把事做完，能跑脚本、能操作工具，也能通过扩展持续长出新能力。把它接进控制平面后，很快会发现更难的是：怎么把它做的事管起来。

从控制平面的角度，它会逼出三个很具体的要求：

交付要可验收。不能只让它“去做一下”，再把一段自然语言回复当作事实；更可靠的方式是让它回传一组可验收的产物（文件、报告、变更、截图等），并带上能回指来源/工具输出/日志的证据引用。
外发要最小披露。执行器需要上下文，但控制平面要尽量只发“这次任务必要的那一小包”，并给出有效期与撤销机制，避免把项目细节与长期记忆外溢出去。
动作要进审计。高风险动作必须能挂到门禁点上，并留下可回放的记录：谁发起、谁批准、做了什么、影响面是什么。

另外，扩展生态会放大攻击面。无论是技能市场、扩展仓库还是远程节点复用，只要存在“第三方能力输入”，就会出现供应链风险与提示注入风险。控制平面把对外外发收敛为 capsule（最小披露包）、把高风险动作挂到 gate（门禁）、把回流结果先落到候选层再进入写入门禁，本质上是在为“强执行器时代”打底。

8.2 Manus：用户期待更聚焦在交付（技术 + 产品）

Manus 这类交付导向产品值得被放进讨论，是因为它把用户的心智从“看过程”拉回到“看交付”：输入目标，系统自己推进，最后给出一个能用的结果。用户不一定想看每一步怎么想，但会在意交付是否可用、是否可复查、以及出了问题能不能解释与撤回。

这会反向逼出几条控制平面语义。

交付以产物为中心。把“交付包”（总结 + 产物索引 + 证据入口 + 风险与下一步）做成第一等对象，它就自然成为跨端体验的共同语言：移动端看摘要与审批，桌面端看细节与工程操作，网页端承载 docs 与只读分享。
把一次执行当作一个对象。产品越“自动跑”，越需要把一次执行做成可观察、可暂停、可回放的东西，并避免把所有真相塞进聊天记录里。

还有一个更朴素的事实：系统越能自驱执行，越需要在关键点停下来。外发、支付、破坏性写入、身份资产改写，这些动作不能只靠“顺口问一句”，而需要被表达为可回放的 gate 事件，并在 UI 上有明确入口与解释。

8.3 Second Me / Macaron / Pi：把“自我”与“信任感”前台化（产品理念侧）

如果说 OpenClaw/Manus 更像是在推动“执行能力上限”，Second Me、Macaron、Pi 这类产品更像是在提醒另一件事：长期使用的关键不只在于会不会做事，还在于用户是否愿意把“自己的一部分”交给系统长期托管。（这里的 Pi 指 pi.ai 的产品，不是本文前面提到的 pi-mono。）

这些产品给控制平面带来的启发，往往不是某个具体功能，而是交互位置的选择：

自我不应只藏在提示词里。用户需要能看见并编辑自己的身份资产（原则、偏好、表达风格），也需要能知道系统到底记住了什么、为什么记、怎么撤销。
信任感来自“边界感”。当系统能清楚解释权限范围、外发对象、记忆写入与撤销影响面时，用户才更容易接受

更高自治度；反之，用户会用更多确认与限制把系统重新拉回“聊天助手”。这也是为什么本文反复强调对象/门禁/审计/撤销：它们不仅是工程约束，也是产品层面建立长期信任感的结构化语言。

参考资料（deep research）

#人工智能 #Personal Agent