在《从传统开放平台到 AI 时代：当调用方从人变成 Agent》里，我讨论的是开放平台如何变得 AI-friendly：让 coding Agent 能读懂文档、理解业务语义、找到正确接口，并生成可以直接跑通的集成代码。
那里的 Agent，本质上还是“开发者”的延伸。它在做的是接入、开发、调试。开放平台要解决的问题是：文档是否可读，接口是否自描述，错误码是否可解析，场景说明是否足够清楚。
所以第一篇文章的核心问题是 AI-friendly context：平台如何把能力、术语、接口、约束和错误处理方式，表达成 Agent 能理解、能选择、能调用的上下文。
但如果 Agent 不再只是开发者，而是开始代表用户直接调用开放平台提供的 MCP、CLI 或 API，问题就变了。
这个变化已经能在一些开放平台的工具形态里看到苗头。比如我在《拆开飞书同一份 API 的两套 Agent 连接方式：MCP 与 CLI》里拆过飞书开放平台的 lark-mcp 和 lark-cli：同一份 OpenAPI 被封装成两套 Agent 可调用的入口，一套偏广覆盖，一套偏高频任务的封装。
不过飞书这个案例更适合说明“Agent 怎么拿到工具、怎么调用工具”，还不是本文真正要挖的方向。因为它当前开放出来的能力主要集中在协作、文档、消息、表格等场景，整体还不是调价、退款、资金、履约这类高危执行操作。本文关心的是再往前一步：当 Agent 不只是调用工具，而是代表用户执行有现实后果的服务操作时，开放平台需要补哪一层边界。
这时 Agent 不是在“写一个应用”，而是在“执行一次服务操作”。
它可能查询订单、调整价格、修改库存、发起退款、创建发货单、修改投放预算。开放平台面对的也不再只是开发效率问题，而是执行边界问题。
1. 两种 Agent 身份
我现在更倾向于把开放平台面向 Agent 的场景拆成两类，而不是混在一起讨论。
| Agent 身份 | 它在做什么 | 平台核心问题 |
|---|---|---|
| 开发者 Agent | 读文档、写代码、生成集成应用 | AI-friendly context：能否读懂、接入、跑通 |
| 服务调用方 Agent | 代表用户直接调用工具或接口 | Agent-safe execution：能否在确认、风控、审计约束下执行 |
第一类是开放平台 AI 友好化改造。平台要优化的是文档结构、OpenAPI、MCP/CLI 封装、llms.txt、错误码、示例和评测。
第二类是 Agent 作为服务调用方。平台要回答的不是“Agent 能不能调通”，而是：
当 Agent 能调通之后，哪些操作可以让它直接执行？哪些只能让它提交草案？哪些必须回到平台可信界面确认？
这两个问题共享同一套底层 API，但它们不是同一个问题。
如果把它们混在一起，就容易得出过于宽泛的判断，比如“OAuth 不够用了”或者“MCP 需要人类确认”。这些说法都太粗。
更准确的说法是：
开放平台过去主要解决“谁可以调用接口”；Agent 作为服务调用方后，平台还要解决“这一次高风险调用是否带有平台可验证的本次意图证明”。
这里的 Agent-safe execution，不是给 Agent 多加一层按钮，而是让 Agent 在执行真实后果操作时，仍然被确认、权限、风控和审计共同约束。
2. 现有开放平台的边界
开放平台不是今天才开始管理风险。
过去的平台治理里，已经有一套相对成熟的边界设计：哪些数据可以开放，哪些能力可以开放；谁可以调用；scope 应该怎么拆；主体什么时候认证；测试环境和生产环境怎么隔离；高敏数据能否被访问。
这套旧边界大致可以拆成四类：
- 准入边界：开发者注册、主体认证、应用审核、经营资质、类目准入、AppKey / AppSecret 发放，解决“谁可以进来”。
- 权限边界：scope、权限包、敏感字段拆分，解决“进来之后允许做什么”。
- 环境边界：test key / live key、沙盒数据、测试店铺、测试态禁用敏感 scope，解决“什么时候还没有现实后果”。
- 运行时边界：限流、配额、请求日志、异常审查、风控、封禁、幂等、回滚、补偿、审计留痕，解决“即使有权限，行为是否仍然合理”。
这四类边界说明一件事：开放平台一直在做边界设计。
只是过去的边界主要围绕“谁可以接入、可以做什么、什么时候进入生产、调用后如何治理”。它默认高风险执行的关键界面仍然大多在平台 UI、开发者应用或可追责的业务系统里。
Agent 时代不是推翻这些边界，而是在它们之上多了一个新问题：当真实执行发生在第三方 Agent 界面里，平台还能否拿到可信的本次确认记录？
3. OAuth scope 与本次意图
OAuth scope 很适合表达静态授权。
商家授权某个应用读取订单、管理库存、修改价格，这些都可以通过 scope、权限包、应用审核、主体资质来管理。
但高风险写操作往往不是只看“有没有权限”就够了。
一个应用拥有 bidding:write，不代表它每一次调价都合规。一个 Agent 被授权管理库存，不代表它可以在模型误判后批量改掉几百个 SKU。一个三方工具拥有退款权限，更不等于它发起的每一笔退款都承载了用户的真实意图。
这里的关键区别是：
- scope 解决的是 事前授权：这个应用可以做什么；
- 高风险执行还需要 本次意图：这一次具体动作是否经过了用户理解后的确认。
在传统开放平台里，本次意图确认有一部分被平台 UI 吸收了。用户在平台后台点按钮、看预览、确认弹窗、做二次验证，平台仍然控制关键执行界面。
但当执行界面迁移到第三方 Agent，平台就失去了这层天然确认。
如果第三方 Agent 调用接口时传一个 user_confirmed=true，服务提供方并不能知道这背后是否真的有人确认过。这个字段可能来自真实用户点击，也可能是 Agent 自动点击，也可能是宿主产品代点，甚至可能只是 Agent 自己生成的参数。
所以问题不是第三方 Agent 一定恶意，而是平台无法验证确认是否真的发生、确认内容是什么，以及最终执行是否和确认内容一致。
更本质地说，第三方 Agent 的执行界面对平台来说是一个不透明信道（opaque channel）。平台看到的是一组由第三方系统转述过来的参数，而不是确认行为本身。只要确认过程不发生在平台可信域内，user_confirmed、点击记录、页面截图、甚至“用户已经确认”的日志，对服务提供方来说都只是确认声明，而不是防篡改的意图证明。
可以用一个模拟场景把问题说清楚。
假设一个商家在第三方经营 Agent 里说：“把 SKU-A 到 SKU-Z 的价格统一下调 20%，今晚 8 点生效。”Agent 生成方案后，直接调用平台的调价接口，并传入 user_confirmed=true。从平台视角看，它只收到了一个批量调价请求和一个确认声明。平台不知道用户看到的预览是不是“26 个 SKU 全部下调 20%”，不知道用户是否理解这会影响毛利和活动价，也不知道 Agent 最终提交的参数是否和用户确认时看到的一致。
如果平台把它改造成 pending action，流程会不同：第三方 Agent 只能提交待确认调价方案；平台生成自己的确认页，展示影响 SKU、价格变化、预计风险和生效时间；用户回到平台可信界面确认；平台再按确认对象执行，并把发起方、确认人、确认参数、执行结果写入审计。这个流程可以很轻，也可以很重，取决于风险等级。但关键点不变：平台信任的不是第三方传来的“已确认”字段，而是发生在自己可信域内的确认行为。
这就是 Agent 作为服务调用方后，开放平台需要重新面对的问题：
确认发生在哪里，决定了确认能否被平台信任。
4. Agent 调用方身份的变化
从开放平台治理角度看，Agent 不一定带来一组全新的 API 资源。订单、库存、价格、物流、售后，这些 What 早就存在。
真正变化的是 Who：调用方不再只是人类开发者写出来的应用、ISV、企业系统或内部团队，也可能是平台自有 Agent、第三方 Agent，甚至是用户自己组装的 Agent。
同一个接口，在不同调用方手里，风险不一样。
Agent 的特殊性不只在于“更聪明”，而在于它有几个新的风险特征：调用速度更快，错误会被放大；自主性更高，可能在用户没有逐步审阅的情况下连续执行；行为更难预测，模型可能走出人类开发者不会走的路径；平台也不一定能触达它的决策和确认界面。
所以，开放平台不能只问“这个接口是否能开放”，还要问：
这个接口被 Agent 直接执行时，平台是否仍然保有足够的管控点？
而当这种更快、更自主、也更不可预测的调用方身份在市场上增加时，平台面对的就不只是安全防线问题，也会变成自家 Agent 与外部 Agent 之间的生态话语权博弈。
5. 一方 Agent 与三方 Agent 的竞争边界
可信执行边界会直接改变一方 Agent 和三方 Agent 的竞争关系。
平台自有 Agent 和第三方 Agent 都可以调用同一组底层 API，但它们在执行高风险操作时的位置并不对等。
一方 Agent 的优势不只是更了解平台业务，也不只是可以接入更多内部上下文。更关键的是，它处在平台自己控制的产品环境里。
当一方 Agent 建议商家调价、修改库存、处理退款时，平台可以在自己的界面里展示操作预览、风险提示、二次确认、强认证、回滚说明。用户是否点击确认，确认的是哪些参数，确认发生在什么时间，是否经过了平台要求的认证强度，这些都可以被平台记录和验证。
也就是说，一方 Agent 不需要向平台“声称用户同意了”。它本身就在平台可信界面里完成确认。
第三方 Agent 的问题不是一定恶意，而是当确认发生在平台控制域之外，服务提供方通常只能看到一个确认声明，却看不到确认本身：是真实用户点击、Agent 自动点击、宿主产品代点，还是根本没有展示过确认，都需要额外机制证明。
所以一方 Agent 在高风险执行场景里有结构性优势：
- 它的确认、执行和审计都发生在平台可信域内；
- 它能在同一界面里完成解释、预览、确认和执行；
- 它不需要通过跨域协议来证明“用户真的确认了”。
这意味着，未来一方 Agent 和第三方 Agent 的竞争，不只是模型能力、工具数量或上下文质量的竞争，也是可信执行边界的竞争。
对于低风险任务，第三方 Agent 可能体验更好、覆盖更广、聚合能力更强。用户可能更愿意在一个统一 Agent 里管理多个平台。
但对于高风险操作，平台自有 Agent 会拥有天然优势。因为平台可以说：你可以让第三方 Agent 提交草案，但最终确认和执行必须回到我这里完成。
这并不意味着第三方 Agent 没有机会。相反，它可能会成为跨平台意图收集和方案生成层：帮用户比较、规划、生成待执行方案，再把高风险动作提交给各个平台完成可信确认。
更进一步，如果未来出现开放的跨域可信确认标准，第三方 Agent 也可能把今天的不透明确认信道，升级成平台可以验证的意图证明。只是标准形成之前，平台的理性选择大概率会偏向把高风险执行收回自有界面。这也是为什么 Agent 生态未来可能在“开放联合标准”和“更强的围墙花园”之间摇摆。
于是未来可能形成一种分工：
| Agent 类型 | 优势 | 适合任务 |
|---|---|---|
| 第三方 Agent | 跨平台、聚合上下文、替用户规划 | 查询、比较、生成方案、批量草案 |
| 一方 Agent | 可信界面、平台风控、真实执行闭环 | 高风险确认、强认证、最终执行 |
这会改变开放平台的策略问题。
过去开放平台只需要问：我要不要开放 API 给开发者？
Agent 时代还要问：哪些能力允许第三方 Agent 直接执行？哪些能力只允许它提交草案？哪些能力必须回到一方 Agent 或平台原生界面完成？
这不是单纯的安全策略，也是一种产品竞争策略。
当 Agent 开始替用户执行真实操作，平台自有 Agent 最大的优势，可能不是更懂用户，而是它的确认、执行和审计都发生在平台可信域内。
6. 从 AI-friendly Context 到 Agent-safe Execution
如果说 AI-friendly context 解决的是“让 Agent 更容易接入”，Agent-safe execution 解决的就是下一层问题：当 Agent 已经可以调用之后，平台如何避免它越过应该守住的执行边界。
这里可以把开放能力分成五档，而不是简单分成“开放 / 不开放”。
| 能力档位 | 含义 | 适合场景 |
|---|---|---|
| 直接执行 | Agent 拿到授权后可以直接调用 | 低风险读、低影响可逆操作 |
| 限额执行 | Agent 可以执行，但受额度、频率、范围限制 | 小范围库存修改、低金额配置、低风险自动化 |
| 草案提交 | Agent 只能生成待确认方案，不能直接落地 | 批量调价、批量库存、复杂履约变更 |
| 平台确认后执行 | Agent 提交 pending action，用户回到平台可信界面确认后执行 | 退款、发货、投放预算、重要商家经营动作 |
| 不开放执行 | 即使有 Agent 场景，也不提供三方直接执行能力 | 资金、高敏风控、不可逆平台级影响动作 |
这个分层比“高风险操作要人确认”更可执行。它能回答开放平台真正要做的产品决策：每一个能力到底是给第三方 Agent 直接执行，还是只给它提交草案，还是要求回平台确认，还是根本不开放执行。
在这五档里，真正进入治理深水区的是“草案提交”和“平台确认后执行”。因为它们都承认同一个事实：第三方 Agent 可以很好地理解意图、生成方案、组织上下文，但到了高风险落地动作，平台需要一种机制承接“待确认操作”。
7. 平台确认作为新边界
如果平台要支持第三方 Agent 发起高风险操作，pending action 是一个更现实的产品形态。
它不是第 6 节五档之外的另一套方案，而是“平台确认后执行”这一档的实现方式：第三方 Agent 不直接调用最终写接口，而是先提交一个平台侧可验证的待确认对象。
这个对象至少要说明：这次动作是谁发起的、代表谁、要改哪些资源、关键参数是什么、风险等级如何、用户看到的预览是什么、确认是否过期、最终执行是否和确认内容一致。换句话说，它要把第 3 节里的确认声明，转化为平台能验证、能审计、能追责的可信确认。
这并不意味着所有操作都要做重。读文档、查状态、生成草案可以低摩擦；真正需要讨论的是第一个产生现实后果的动作。到了调价、退款、发货、扣款这类操作，平台是否应该要求 Agent 先提交草案，再让用户回到平台可信界面确认？
这个问题目前比具体字段设计更重要。
这件事不会长期停留在每个平台各自发明确认字段的阶段。只要第三方 Agent 真的开始跨平台执行敏感操作，行业头部平台或协议生态一定会尝试把“可信确认”定义成事实标准，然后由其他服务提供方跟进。
8. 服务端风控的底线角色
即使有平台侧确认，也不能把风险控制全部压在“用户点了确认”上。
原因很简单：用户可能误解，Agent 可能解释不清，确认界面可能被用户快速跳过，真实业务后果也可能在执行后才显现。
所以 Agent-safe execution 至少需要两层：
第一层是意图确认：这次动作是否经过用户在可信界面确认。
第二层是服务端风险控制：即使用户确认了，平台也要判断这个动作是否超出合理边界。
比如：
- 调价幅度超过阈值，先拦截或进入人工复核；
- 单日批量修改 SKU 数超过上限，分批执行或降级为草案；
- 新授权应用只能执行小额度、低频次操作；
- 涉及资金、退款、履约的动作必须走更强认证；
- 异常失败率、异常调用时间、异常参数分布触发冻结或回滚；
- 所有高风险写操作必须有幂等键、审计日志和补偿路径。
这与开放平台传统的限流、风控及异常审计机制在底层逻辑上是一致的。区别在于，Agent 会把调用速度、自主性和错误放大，因此这些控制不能只作为后台治理工具，而要成为 Agent 工具设计的一部分。
9. 为什么现在值得问这个问题
今天，第三方 Agent 大规模调用另一个第三方服务的 MCP/CLI/API 来完成敏感操作，还没有真正普及。所以行业里还没有形成成熟共识。
但这恰恰是值得提前讨论的原因。
如果开放平台只把 Agent 当成新的开发者，那么改造重点会停留在文档、OpenAPI、MCP、CLI、llms.txt、上下文成本和 First-Pass Success Rate。
这些都重要，但它们服务的是“接入”。
一旦 Agent 变成服务调用方，开放平台就要面对另一个问题：当执行界面不在平台手里，平台如何证明这一次操作不是第三方系统单方面转述的确认声明？
MCP 让工具可调用，OAuth 让身份可授权，scope 让权限可表达。
但对于高风险动作，它们都不天然证明：这一次操作，经过了用户理解后的本次意图确认。
这就是开放平台从 AI-friendly API 走向 Agent-safe execution 时，必须补上的一层边界。