Agent间交易
一个 Agent 代表用户调用另一个 Agent 或服务能力，完成询价、授权、支付、签约、交付和确认等流程的 AI 生态交易形态。
简介
Agent间交易描述的是 Agent 生态从“人问 AI 答”走向“Agent 之间直接调用能力并完成业务闭环”的下一阶段。传统软件交互里，用户在多个 App 之间切换、搜索、比较、下单、确认；Agent 时代则可能由用户委托一个入口 Agent，让它调用餐饮、差旅、采购、合同、客服、支付等其他 Agent 或服务能力，完成整个任务。
在 2026-07-07-woshipm-ai-pm-five-judgments 中，作者提出一个判断：Agent 之间就能交互和做生意，交互的终极形态不是纯对话，而是“对话 + 多模态传输”。人类需要文件传输来承载 100 页合同，AI 之间更不需要靠模拟人类打字聊天，而应通过接口、文件、结构化数据和多模态对象传输。一个 Agent 可以代表用户去调用另一个 Agent 的服务，完成支付、签约、交付，整个流程不需要人类在中间做“胶水”。
这个概念与 AI产品场景连接、AI商业化趋势 中的 To A、服务封装、连接密度 和 AI Agent 智能体 高度相关。它给产品经理提出的新问题是：你的产品是否只是一个给人看的界面，还是一个可以被其他 Agent 稳定调用、理解、计费和交付的能力单元？
关键信息
| 维度 | 说明 |
|---|---|
| 交易主体 | 代表用户或组织目标的 Agent，以及提供能力的服务型 Agent/接口 |
| 交互方式 | 自然语言意图 + 文件/多模态传输 + API/工具调用 + 状态回执 |
| 关键流程 | 授权、询价、能力发现、执行、支付、签约、交付、审计 |
| 核心挑战 | 身份、权限、信任、价格、责任、回滚、证据链和标准协议 |
| 产品机会 | 把产品能力封装为可被 Agent 调用的服务单元，参与 To A 流量分发 |
核心特性
1. 对话不是唯一交互形态
Agent 生态容易被误解为“很多 AI 在聊天”。实际上，人类都不会靠对话讲完一份 100 页合同，Agent 更没有必要用自然语言逐句传递结构化信息。真正高效的 Agent 间交互应是自然语言用于意图与协商，结构化接口用于执行，文件和多模态对象用于承载复杂材料，状态回执用于确认和审计。
因此 Agent间交易不是“两个聊天机器人互相发消息”，而是由入口 Agent 理解用户目标，选择合适服务，传输必要材料，调用对方接口，接收结构化结果，再把关键决策点交给用户确认或自动执行。
2. 产品必须成为可调用能力单元
如果未来用户不再直接打开 App，而是让 Agent 代办任务，那么产品的前台界面可能不再是唯一入口。一个服务要在 Agent 生态中保留位置，必须能被其他 Agent 调用：有稳定 API、清晰能力描述、权限机制、价格规则、返回格式、错误码和审计记录。
这与 AI产品场景连接 的连接密度相连。浅层 API 接入很容易被绕过，真正有壁垒的是把上下文、规则、执行、兜底做深，让 Agent 调用你比直连上游更可靠、更省心、更合规。Agent间交易会放大这种差异：服务能力越可被机器理解和交付，越可能成为 Agent 生态中的基础设施。
3. 信任和授权是交易前提
Agent 代表用户做生意，本质上涉及代理权。它需要知道自己能花多少钱、能签什么合同、能提交哪些资料、能访问哪些个人或企业数据、哪些动作必须人类确认。没有授权体系，Agent 只能停留在“建议”；有授权但没有审计，风险会迅速放大。
因此 Agent间交易需要产品层面的身份与权限设计：用户授权范围、组织审批链、金额阈值、数据最小化、关键动作二次确认、可撤销机制、日志留痕和责任归属。这里不能只靠模型“懂事”，而要靠系统约束。
4. 交易需要价格与结算规则
Agent 调用服务不只是技术调用，也是商业调用。未来一个 Agent 可能为了完成差旅任务调用航司、酒店、地图、支付和报销 Agent；也可能为了采购任务调用供应商、合同审查、预算审批和 ERP Agent。每个调用都可能涉及费用、佣金、分成或资源消耗。
这与 AI产品价值分成 形成连接：Agent间交易会让结果收费和按价值分成更自然，因为服务可以围绕“完成一次任务”“节省一次人工”“促成一次交易”计费，而不只是按页面访问或 API 次数计费。但结算必须有证据链，否则入口 Agent、服务 Agent 和用户之间很难确认价值归属。
不同素材中的观点
来自 2026-07-07-woshipm-ai-pm-five-judgments：
- 作者判断未来 AI 生态有两个关键特征：软件和硬件一定打通，Agent 之间能够直接交互和做生意。
- 交互终极形态是“对话 + 多模态传输”：人类用耳朵、眼睛、鼻子、嘴巴交互，但信息存储和传递依赖文件；Agent 之间更应依赖接口传输，而不是模拟人类打字聊天。
- 一个 Agent 可以代表用户调用另一个 Agent 的服务，完成支付、签约、交付，整个流程不需要人类做中间胶水。
- 对产品经理的挑战是：设计的产品能否作为一个可被其他 Agent 调用的能力单元存在。
实用信息
Agent 可调用服务的产品清单
- 能力说明：用机器可读方式描述服务能做什么、输入需要什么、输出是什么。
- 权限模型：定义用户授权、组织授权、金额阈值和敏感操作确认机制。
- 接口与协议：提供稳定 API、工具 schema、MCP 服务或其他标准调用入口。
- 状态回执：每一步返回处理中、成功、失败、需人工确认、可撤销等状态。
- 证据链：保存输入材料、调用记录、关键判断、价格、版本和交付结果。
- 价格规则：明确按调用、按任务、按结果、按分成还是按订阅结算。
- 兜底机制：失败时如何重试、转人工、退款、撤销、补偿或升级处理。
典型场景
- 差旅 Agent：入口 Agent 调用航班、酒店、日程、预算审批和报销 Agent，完成预订和报销。
- 采购 Agent：调用供应商报价、合同审查、库存、预算和支付服务，完成采购闭环。
- 电商导购 Agent：调用多个商品库、KOL 导购、优惠券和支付服务，完成比价、推荐和下单。
- 企业办公 Agent：调用飞书/钉钉/CRM/ERP 服务，完成会议安排、资料查找、审批和客户跟进。
- 内容生产 Agent：调用素材库、版权校验、生成工具、发布平台和数据分析服务，完成内容分发闭环。
常见风险
- 授权过宽：Agent 可以执行超出用户预期的支付、提交或删除动作。
- 责任不清：入口 Agent 推荐错误、服务 Agent 执行错误、用户授权错误之间责任难划分。
- 价格黑箱：Agent 推荐服务可能演变为竞价排名，损害用户信任。
- 证据缺失：交易完成后无法解释为什么选这个服务、花了多少钱、谁确认过。
- 接口脆弱：服务返回格式不稳定，导致上游 Agent 错误理解结果。