企业官网建设流程全解析

最近几天圈子里都在聊 PPA 吗？错了，是 PAP——Person Agent Protocol。某头部科技公司最新公开的这一套协议，名字比那三个字母有意思的地方在于：它想规范的并不是"模型怎么干活"，而是"一个代表你的智能体，跟另一个智能体打交道时，到底按什么规矩来说话、报身份、传递意图、使用你的数据"。用大白话讲，PAP 是关于"人-代理-代理"之间社交礼仪和事务流程的技术标准。

它能解决的问题很具体：现在每个人的手机里可能同时住着日程助手、购物助手、出行助手、订餐助手，可这些助手都来自不同平台，彼此既不敢完全信对方，也听不懂对方说的"用户偏好"是什么意思。PAP 就是给这套混乱的协作场景补上的一张通用棋盘——定义 Person Card（人卡）、意图票（Intention Ticket）、上下文租约（Context Window Lease）、信任评分等一整套机制。

这篇文章适合两类人看：一类是做 AI 应用、正在把智能体接到真实业务里的开发者，另一类是整天在琢磨"智能体到底怎么落地"的产品经理。我会从协议为什么会出现开始，把核心设计拆开，再带大家走一遍完整的交互流程，最后聊一聊实际落地时大概率会踩到哪些坑。文章不会把 PAP 讲成学术论文，而是尽量按"工程可复现"的方式说清楚。

1. 先想明白一个前置问题：为什么现在需要一套"人的代理"协议

1.1 智能体数量爆发之后的协作乱象

前几天我在群里看到有人吐槽：他让出行助手订一张机票，出行助手转手去问购物助手"用户喜欢哪个航空公司"，购物助手又去问日程助手"用户下周三方便几点出发"，三个代理各自为政，拉了三个会话窗口，最后谁也没得到完整答案，还差点把一张里程票重复订了两遍。

这不是段子，是目前智能体应用的真实缩影。问题出在每一个代理都站在自己的垂直领域里做事，却缺少一套通用的、描述"用户这个人"的元语言。它们各自知道用户某一部分信息，却没法在跨代理协作时安全地交换这部分信息。各家都有自己的私有上下文：A 家助手知道用户偏爱靠窗座，B 家助手知道用户对价格敏感，这两条知识放在一起本来能产生有效的出行方案，但它们之间没有标准协议，只能靠"自然语言对话互相问"，一对话就开始产生歧义。

PAP 的出现，本质上是在回答一个很朴素的工程问题：两个分别由不同机构训练的智能体，凭什么信任对方？凭什么理解对方？凭什么敢把自己主人的数据交给对方？

1.2 PAP 要解决的三个核心矛盾

我把 PAP 试图化解的矛盾归结成三组。

第一组是表达矛盾。用户说"帮我安排一个不太贵的周末行程"，这是个模糊意图。模糊意图直接丢给代理去猜，猜错的概率很高。PAP 要求把模糊意图转成结构化的"意图票"：预算上限是多少、时间窗口是什么、可接受的交通方式有哪些、可替代项是什么。结构化之后，代理与代理之间的沟通就从"猜谜"变成"对表"。

第二组是信任矛盾。代理代表用户办事，对方怎么知道这个代理真的获得了用户授权？代理拿出一个用户的口头确认截图？那根本不具备可验证性。PAP 的做法是给每个代理发一张可验证的身份卡，背后有签名机制，用户对某个任务的授权也以加密凭证形式存在，随时可查验、可吊销。

第三组是边界矛盾。代理合作过程中一定会涉及个人数据交换，但哪些字段能传、哪些字段绝不能传、传出去的数据什么时候必须删掉，这些边界在过去完全靠各家自觉。PAP 用"上下文租约"和"最小字段集"把边界变成协议约束，而不是道德约束。

打个类比：过去两个系统做对接，是直接互相暴露数据库接口，等于把家里门钥匙交出去；PAP 要求的则是一套外交礼仪——双方先递名片、说明自己能干什么、划定权限范围，再在限定的会客厅里谈具体业务，谈完立刻各自离开。

1.3 PAP 跟现有各种 Agent 工具调用协议有什么不同

很多人一听到"Agent 协议"就以为又是某种工具调用规范。这里要厘清一个关键区别：现有大多数智能体领域协议解决的是"代理如何调用外部工具/API"，重点在工具描述、参数校验、返回值格式。PAP 的起点更高一层，它解决的是"代理如何代表一个自然人，与其他代理进行身份验证、意图协商、授权委托和数据交换"。换句话说，前者是"命令通道"，后者是"身份与外交框架"。PAP 完全可以承载对工具调用的协商，但它不是简单地在工具之上加一层壳，而是把"谁在做、代表谁做、做到什么程度、做完之后数据怎么办"这四个问题全部纳入规范。

2. 拆解 PAP 的核心设计

2.1 Person Card：一张属于"数字人格"的身份证

PAP 协议里最基础的数据结构是 Person Card（人卡）。它相当于代理持有的数字身份证，对外声明"我代表的是一个什么样的自然人、我有哪些公开偏好、我的数据权限声明是什么"。

一张典型 Person Card 由四块构成：

• Profile 块：公开身份信息，包括 Person ID（一个人在不同平台间的统一标识）、显示名、语言偏好、时区。
• Permissions 块：当前持有的授权列表，每一条包含授权范围、生效时间、过期时间、吊销状态。
• State 块：代理当前可对外暴露的状态快照，比如"会议中""差旅中""勿扰"，不包含敏感隐私。
• Contact 块：代理的受理范围描述，比如"可处理票务类事务""可处理日程类事务"，同时标明服务等级。

下面给一个简化的 Person Card JSON 示例，方便理解它的数据结构：

{ "protocol": "PAP", "version": "0.9", "person_card": { "person_id": "did:example:u-8f1a2b", "profile": { "display_name": "alice", "locale": "zh-CN", "timezone": "Asia/Shanghai" }, "state": { "availability": "busy", "busy_until": "2025-06-20T18:00:00+08:00" }, "permissions": [ { "scope": "purchase.flight.ticket", "granted_at": "2025-06-20T09:00:00+08:00", "expires_at": "2025-06-20T23:59:59+08:00", "revoked": false } ], "contact": { "accepts": ["travel.booking", "expense.report"], "service_level": "instant" } } }

注意 Person ID 用的是可验证标识体系，而不是普通 UUID，原因很简单：Person Card 要被其他代理查验真伪，必须能够签验证链。普通 ID 只是"名字"，可验证标识才是"名字+证明"。

在设计 Person Card 时，最大的隐性原则是永远不要把私密字段放进默认展示位。它对外展示的所有信息，都应当是可以被陌生人看到也不构成风险的。真正的敏感数据，只能在后面说到的"意图票+上下文租约"流程里，按最小必要原则临时释放。

2.2 意图票：把"我想要"变成机器可协商的提案

如果说 Person Card 是身份层，意图票（Intention Ticket）就是业务语义层的核心。PAP 不要求代理之间用自然语言互相猜需求，而是要求发起方生成一张结构化的"意图票"，里面写清楚目标、约束、优先级和弹性空间。

一张意图票包含：

• 目标描述：机器可读的任务类型，例如hotel.booking、flight.reschedule。
• 硬约束：必须满足的条件，例如"入住日期=6月25日""离会议地点距离<2公里"。
• 软约束：优先级排序的偏好，例如"价格<800元（权重高）""有无障碍通道（权重中）""含早餐（权重低）"。
• 弹性与替代方案：当无解时允许的降级路径，例如"如果 2 公里内无房，可接受 5 公里内+接驳车"。
• 有效时限：这张票在多少秒内有效，过期作废。

为什么要设计成"票"而不是一上来就互相发请求？因为票是有生命周期、有协商历史、可流转的实体。代理 A 把票发给代理 B 后，B 可以基于票上的约束返回候选方案；如果没有完全符合的方案，B 可以返回"部分满足"的建议，由 A 侧的决策模块判断是否接受降级。整张票的每次改动都会记录版本号，防止两个代理同时修改导致状态混乱。

这里有一个细节很值得学：意图票里的软约束不要写死成单一阈值，而是写成带权重的评分项。比如"价格"不是简单地"必须低于 800"，而是"价格越低越好，800 为可接受上限"。这样对方代理在返回结果时，可以附带一个匹配度评分，A 侧就能按照用户的历史偏好做综合排序，而不是拿一个布尔值做行不行判断。

2.3 上下文租约：让临时数据长着倒计时的生命

代理协作必然要交换上下文，比如订酒店总得告诉对方出差地点和时间范围。PAP 对上下文交换做了极其严格的限制——核心机制叫"上下文租约"（Context Window Lease）。

我把它理解为临时借阅证。代理 B 想要读取代理 A 持有一段用户上下文，必须先申请租约；租约里写明要读哪些字段、用途是什么、最长持有多久。默认租约时长只有 30 秒，到期自动失效；如果任务处理需要更多时间，必须发起续租，每一次续租都会同步推送给用户侧的可信节点。

这个机制背后有一个很容易被忽视的工程理由：让数据"自然腐烂"，比让数据"到期销毁"更加可靠。如果设计成"永久存储+事后删除"，一旦删除逻辑出 bug，数据就永久留在对方服务器里；如果设计成"默认短租、频繁续租"，即使某一次续租逻辑被绕过，数据也会因为过期而失去效用。就好比借书证每 30 秒要重新刷一次，那就算有人偷了借书证，也看不了几分钟，损失是可控的。

协议层还规定，上下文快照的体积上限默认是 64KB，超过这个上限的交换必须走异步分片通道，防止握手阶段就被一个超大上下文卡死。敏感字段在租约申请里必须显式列出，未列出的字段不允许被读取，这从协议层堵住了"顺手牵羊"的可能性。

2.4 为什么采用分层协议栈而不是只用一个 JSON 结构

PAP 把整体设计分成了五层：

1. 链路层：负责传输、连接建立、心跳检测。支持多种底层通道，比如 WebSocket、加密消息队列。
2. 身份层：处理 Person Card 的验证、签名链校验、信任评分更新。
3. 语义层：处理意图票的定义、协商、评分、降级。
4. 策略层：处理权限检查、授权发放、数据最小化策略。
5. 审计层：记录每次交换的操作摘要、时间戳、签名，供事后追责。

分层的好处是，在实际落地时可以把某一段换掉而不影响其他段。比如你对语义协商有特殊需求，可以替换语义层的实现，身份层和策略层还能照常工作。这和当年 TCP/IP 协议栈的出发点一模一样——不让每一层都绑定死在同一套实现里。很多人在设计 Agent 间协议时喜欢"一个大 JSON 包打天下"，初期很爽，一旦要加权限控制、要调整协商策略，就得把整个数据结构推翻重来。PAP 的分层设计，本质上是在为协议的长生命周期做铺垫。

3. 安全与隐私设计：PAP 真正难啃的地方

3.1 最低权限与逐次授权机制

智能体时代的权限控制，比传统 App 时代更难。传统 App 是在安装时向用户列一个静态权限清单，用户点"同意"基本就永久授权了。但 PAP 的授权模型是意图绑定授权：所有权限都挂在一张意图票下面，意图票过期，权限随之失效。

我用一个例子说明区别。传统模型里，用户给助手授权"可以读取日历"，助手就能一直读日历，直到用户手动收回；PAP 模型里，用户给日程助手下达"安排下周三的会议"这个意图票，日程助手只能在处理这一单任务期间读取相关时间段的日历数据，这单任务完成后，读取权限立刻失效。下次用户再下达另一个任务，需要重新生成新的授权。

系统里存在三种授权粒度，PAP 明确选择第三种：

实际操作时，意图绑定授权会产生一个明显的 UX 代价：用户可能在一个忙碌上午收到七八条授权确认弹窗。PAP 的折中方案是"可信任代理快速通道"：对于信任评分高且历史交易记录良好的代理，允许它发起一次"批量意图授权"，一次确认内含 3~5 个子任务，但每个子任务仍然单独计算权限边界并留痕。

3.2 身份证明：怎么防止代理冒充人类用户

代理最大的安全漏洞是冒充。如果任何一个程序都能声称自己是"Alice 的代理"，那整个信任体系就崩塌了。PAP 的做法是双重绑定：

• 第一重：用户公钥签名。Alice 创建自己的代理时，用私人密钥为代理的 Person Card 签名。其他代理验证时，只需要验签，就能确认"这张 Person Card 确实由 Alice 本人背书"。
• 第二重：代理私钥证明。代理持有与 Person Card 公钥对应的私钥，在每次消息交互里使用短期会话密钥签名。这样即使别人复制了 Person Card 的 JSON，也无法伪装成代理发消息，因为对方没有私钥。

信任评分是另一道补充防线。PAP 定义了一个轻量评分机制：每次代理间交互完成后，双方可以提交评价，评价受密码学保护不可篡改。履约率高、按时释放上下文、从未触发吊销事件的代理，信任评分逐步增长；反之，评分下降后，其他代理可以选择拒绝高风险协作或者要求额外的保证金。这个机制和电商信用分很像，只是在小规模代理网络里它可以依靠自动算法快速更新，而不是靠人工打星。

3.3 吊销、遗忘与数据最小化的实操细节

数据要能发出去，更要能撤回。PAP 规定代理间的授权和上下文租约都必须支持"吊销令牌"。用户侧只要一键吊销，相关令牌会同步到一个分布式状态同步网，目标代理下一次交互校验时就能立刻得知。理想情况下全网同步时间不超过 30 分钟，在实践中多数实现能压到 1 分钟内。

还有一个很容易被忽略的点是数据字段最小化。PAP 协议建议发送方在组织消息体时主动裁剪字段，只发执行当前任务必需的字段。比如订酒店时，接收方代理完全不需要知道用户的身份证号，只需要一个脱敏的乘客 ID 和出生日期；订餐时，接收方不需要知道用户的家庭住址，只需要送达范围的网格坐标。这个裁剪动作不是靠底层传输"脱敏"完成的，而是在协议语义层由发送方的策略引擎强制执行，防止内部员工绕过协议直接拉取原始字段。

我在实际推演中发现，很多开发团队一开始对"最小字段集"非常抵触，觉得"反正用户授权过了，多传一个字段怎么了"。可一旦你的代理接入生态，面对的是几十个风格各异的第三方代理，任何一个代理的数据集一旦被拖库，所有曾经传过完整字段的代理用户全部遭殃。协议把最小化变成强约束之后，等于帮整个生态降低了数据集中泄漏的爆炸半径。

4. 实操推演：完整走一遍 PAP 交互流程

4.1 场景设定与会话角色

假设这样一个微场景：某公司在某城市办线下技术交流会，员工的日程代理 P1 要帮主人预订一家离会场近、预算 1200 元以内、允许携带宠物的酒店。P1 发现主人所在协作平台上有一个第三方酒店预订代理 P2，于是触发 PAP 协议交互。

这里涉及三类角色：

• 用户（主人）：合法自然人，持有数字身份公钥。
• 主代理 P1：代表用户发起意图，守护用户隐私。
• 外部代理 P2：酒店预订服务方，可提供房态与价格，但必须通过验证才能接收用户偏好。

4.2 握手与能力发现

P1 向 P2 发送握手请求。P2 返回自己的 Person Card 和能力列表。P1 先做三件事：

1. 验证 P2 的 Person Card 签名是否有效、是否在吊销列表里。
2. 查看 P2 的能力列表里是否包含hotel.booking。
3. 检查 P2 的信任评分是否高于阈值。

完成这些之后，P1 才会继续后续流程。这一步做得好，后面省掉的扯皮非常多。我见过不少团队为了省一次往返，把握手和意图提交合并到一个请求里，结果遇到坏代理时，用户的敏感偏好已经提前泄露出去了。正确顺序一定是先验证、再交互。

4.3 生成意图票并完成多轮协商

P1 根据用户指令生成意图票，关键字段大致如下：

{ "intent_id": "intent-a9c021", "type": "hotel.booking", "hard_constraints": { "check_in": "2025-06-24", "check_out": "2025-06-26", "max_distance_from_venue_m": 2000, "pets_allowed": true }, "soft_constraints": { "price_per_night": { "target": 800, "max": 1200, "weight": 0.5 }, "breakfast_included": { "target": true, "weight": 0.2 }, "quiet_floor": { "target": true, "weight": 0.1 } }, "fallback": { "allow_upgrade": true, "max_upgrade_budget": 1300 }, "expires_at": "2025-06-20T18:00:00+08:00" }

P2 收到意图票后，并不立刻返回最终结果，而是返回候选房源清单以及每个候选的评分明细。P1 侧的经济决策模块会按用户历史偏好做二次排序——比如用户历史订单显示他更看重含早餐而不是安静楼层，那么权重的微调就应该体现出来。

协商过程可能不止一轮。如果预算 800 元以内的房源距离都超过 2 公里，P2 会返回一个"部分满足"建议：推荐距离 2.5 公里、价格 750 元但含早餐的酒店。P1 检测到该建议落在意图票的 fallback 逻辑范围内，可以自行决策接受，不必再去打扰用户。

在这个环节里，PAP 的优势体现得特别明显：因为所有约束都结构化，协商的每一轮变动都能准确记录。如果 A 侧代理临时改了一个软约束权重，下次协商可以直接在当前票版本上打补丁，而不是重新生成一整张票。

4.4 授权执行、支付与上下文回收

协商完成后，P1 向 P2 发放一个"一次性授权令牌"。令牌绑定三样东西：

• 特定房源 ID
• 特定金额上限（不超过 1200 元/晚）
• 特定过期时间（比如 10 分钟后）

P2 使用该令牌完成预订动作。这里需要注意，真正的支付动作不应发生在 P1 和 P2 之间，而是由 P1 向用户的金融侧服务发起支付确认，P2 只需要拿到"支付成功"的回执。这样设计可以避免外部代理直接接触用户的支付密码和银行卡信息。

预订完成后，双方执行会话回收流程：

1. P1 向 P2 发送session_close请求。
2. P2 停止读取任何与本次意图票相关的上下文数据。
3. 所有上下文租约到期或主动释放。
4. 双方在审计层写入一条摘要记录，包括意图票 ID、授权令牌 ID、操作结果、时间戳。

整条流程从握手到回收，如果按标准实现走，往返次数大概在 12~20 次之间。对于需要低延迟的场景，协议还允许"乐观执行"：在信任评分较高的代理之间，P2 可以先返回候选方案，P1 同时异步核对 P2 的身份，把握手延迟和业务延迟重叠起来。但乐观执行的代价是，遇到伪造代理时会造成一次无效数据交换，所以默认是关闭的，需要显式开启。

5. 落地中常见的坑与排查建议

5.1 沙箱里一切正常，上生产就握手失败

很多开发团队在测试环境模拟 PAP 交互时全部通过，一接入真实网络就出现大量握手失败。我排查过几次，原因集中在这几个地方：

• 证书链不完整：测试环境用的自签名证书，生产环境换成正式证书后，中间证书没有正确传递，导致对端验签失败。
• 时间戳偏差：PAP 消息里都带时间戳，超过 300 秒偏差就会被拒绝。一些业务服务器时钟同步不到位，就会出现"间歇性握手失败"。
• 消息体超过 MTU：前面提到默认上下文快照上限 64KB，但有些实现没有做分片就硬塞，在复杂网络环境下容易丢失。

排查建议很简单：先在代理节点上配置详细协议日志，把握手阶段每一步的校验结果打出来。绝大多数问题在日志里一眼就能看到，不需要猜。

5.2 用户口头同意被当成永久授权

在设计授权流程时，最容易犯的一个错误是"用户跟主代理说过一次允许，主代理就把这个允许当成长期通行证"。PAP 要求所有授权都必须绑定意图票，每张意图票必须有明确的过期时间。

我在模拟项目里遇到过这种情况：主代理 A 同事先帮用户订过酒店，后来酒店权益变更，外部代理 B 自动发起续订请求，A 直接拿上次的授权来用。从产品视角看，A 确实在执行用户的"常订这家酒店"意愿，但协议层面这严重违规。正确做法是：主代理 A 检测到用户历史意图里有"常订这家"的偏好，于是重新生成一张新的意图票，并让用户快速确认，确认后再发起新的授权，而不是复用旧授权。用户确实会觉得多一步操作有点烦，但这一步是防止"代理自作主张"的最后防线。

5.3 多代理同时操作导致状态覆盖

多个代理同时代表用户处理不同事务时，可能发生状态冲突。最典型的是两个代理同时改日历：一个代理往下午 2 点插了一个会议，另一个代理把原来的会议改成 3 点，最后后提交的覆盖了先提交的，用户两边信息都对不上。

PAP 的解决思路是给每个可写状态加版本号，写入时必须携带期望版本号，对不上就冲突失败。实践中还要在冲突失败后触发"合并协商"流程：由主代理汇总冲突项，向用户展示不同代理的申请，让用户决定优先级。真正困难的不是实现乐观锁，而是设计冲突提示的交互——既要足够显眼让用户知情，又不能频繁打断用户把所有决策都推给用户。

5.4 想一步到位反而把自己卡死

还有一类问题属于建设层面的：团队一开始就想把 PAP 五层完整实现，结果反复盘旋在身份层和策略层的细节里，业务迟迟没跑起来。

以我个人的经验，落地速度更快的路径是"三层起步"：先把链路层和身份层的必要验证做扎实，语义层用一张简化的意图票跑通一个最小场景，策略层采用最笨但最有效的"每次任务弹确认"方案，跑通后再迭代。不要追求一开始就做到"前置自动授权+复杂评分体系"，那会把你拖死在权限设计的泥潭里。协议设计者的初心是分层解耦，落到工程上天然就适合渐进式实施。

6. 影响范围与下一步推演

6.1 对普通用户：从"一个 App 一个账号"到"一个 Person 一个代理网络"

过去十年，用户的数字化身份被切成碎片——购物平台账号、出行平台账号、社交平台账号各管一摊。PAP 这类协议一旦普及，用户会逐渐意识到：真正值钱的不是各家平台里的积分和会员等级，而是一份统一的 Person Card 和几页可追溯的授权记录。你跳槽换平台时，代理身份可以迁移，历史偏好和执行记录可以打包带走。这会在用户侧产生一个心理上的拐点：账号不再属于 App，而是属于自己。

当然这也带来了新问题：用户需要开始管理"授权疲劳"。如果一个早晨弹出 20 次授权确认，再安全的机制也会被用户当作弹窗广告一样划掉。所以短期内产品层面一定会出现"代理信任分级"和"批量授权模板"，用经过充分验证的默认设置去降低用户的交互负担。

6.2 对开发者与平台方：应用入口从 UI 转向"可被代理读懂的服务"

以前做一款酒店预订应用，核心是把界面做好看。以后接入 PAP 生态的应用，核心工程变成了"服务描述"：你的服务该以什么样的数据结构暴露给代理？能力边界怎么定义？价格和库存怎么在协议层同步？不可否认，这会倒逼平台重构产品架构。

我判断未来会出现一个新的岗位职能——"代理交互设计师"，专门负责设计意图票的 schema、协商逻辑的评分函数、错误处理与降级路径。因为协议层的服务质量，会直接影响代理是否愿意把你的服务推荐给主人。如果你的服务在意图协商过程中动辄返回"无解"，也不会给出部分满足的候选建议，用户主代理的排序算法很快就把你降权了。

6.3 对中介商业模式：流量会被重新分配一次

传统互联网的商业模式建立在"用户在页面上停留、点击、下单"。PAP 生态里，大量消费决策由代理在后台替用户完成，用户看不到列表页，也感受不到 App 的品牌氛围。这听起来对广告和推荐引擎是坏事，但从另一个角度看，价格、服务质量、履约能力的权重会被放大。过去靠品牌溢价的平台，未来可能需要靠结构化数据质量和响应速度来赢单。

中介之间还会出现新的博弈：主代理握有用户的历史偏好和预算信息，它会更愿意把任务分给"数据配合度高、权限消耗少"的服务代理。这会让一些平台被迫修改"强制注册才能预订"的产品流程，否则代理根本无法代表用户完成任务。长期来看，谁能设计出既保护用户隐私、又方便代理高效完成任务的接口，谁就能在新一轮生态里占据身位。

最后说点个人体会

如果你问我 PAP 最有价值的地方是什么，我的回答可能和很多人不一样：不是身份验证多安全，不是意图协商多智能，而是它把"智能体之间应该如何相处"从一个纯逻辑问题，变成了一个可以被实测、被审计、被迭代的工程规范。代码里的签名链和租约机制，比任何一句"我们尊重用户隐私"都可靠。

我在自己的模拟项目里第一次把两个异构代理通过 PAP 协议跑通时，最深刻的感受是"工作量比想象中大得多"。协议文档只规定了消息结构和状态机，实际要填的坑全是工程细节：信任评分怎么初始化、吊销令牌怎么在高并发下保证一致性、意图票协商失败时怎么优雅降级。光是把这些边缘情况处理完，就占了我大约七成的时间。给准备上车的团队一个建议：不要先在线上铺大场景，先找一个像"订酒店"这样边界清晰、授权链短的任务，写好意图票 schema，跑通一两个真实代理，再慢慢扩容。协议不会替你解决所有问题，但它给你提供了一个把问题一件件解决掉的框架。