聊天里说“已确认”不等于订单成立：Agent 服务履约契约

千问开放平台开始允许第三方服务进入对话场景，用户可以在聊天中办理寄件、租车、本地生活、出行等任务。这个方向很有吸引力：人不必在助手里做完选择，再去另一个 App 重新填一遍资料，产品可以直接从“帮我选”走到“帮我办”。

但顺滑的体验也容易掩盖一个危险捷径。一次连续对话会让建议、报价、支付授权、商家接单和服务完成看起来像同一件事，实际上它们分别属于不同主体、不同时间和不同证据。模型说“已经订好”，不能证明服务商真的接单；扣款成功，不能证明快递员已经取件；服务商接受订单，也不能证明用户确认过最终地址、时间、取消规则和价格。

本文写给正在把助手连接到真实服务的非技术创始人、AI 应用搭建工具用户和小团队。你会得到一套五方事实模型、一份可复用的服务履约契约、一个同城急送案例、上线前故障演练、发布决策矩阵和 48 小时实施计划。适用边界也很明确：它适合范围窄、可恢复、服务商和售后负责人清楚的普通服务，不是医疗、法律、投资、信贷、应急处置或其他受监管决策的快捷方案。

核心判断只有一句：对话适合澄清意图，不适合证明订单成立。真正提交的必须是结构化、已授权并由服务商确认的状态。

发生了什么：助手正在变成服务柜台

YBuild 没有独立使用这些服务完成真实交易，也没有测量成功率或审计每家服务商的合同。公告能够证明产品方向和官方宣称的范围，不能证明所有接入服务都拥有同等水平的授权、恢复、隐私和售后能力。

真正重要的信号也不只属于一家平台。对话正在成为真实服务的新分发界面。过去由服务商自己的表单、结算页、订单页、通知中心和客服系统承载的工作，现在有一部分被移进了编排层。助手需要把含糊表达转换为精确字段，展示会变化的条款，取得授权，调用服务商，理解异步结果，并在用户离开原对话后继续同步状态。

开放商业协议也在沿着这个方向发展。官方 Agentic Commerce Protocol 架构把买家、Agent、商家和支付服务商的职责分开：Agent 负责理解意图和编排体验，商家继续负责价格、库存或可用性、收款和履约。Google 的 Universal Commerce Protocol 介绍同样把结算、折扣、履约、身份和支付定义为可组合能力，而不是设计一个无结构的“购买”调用。

这些材料是仍在演进的规范和集成方案，不是某个实现已经可靠的独立证据。它们在本文中的价值，是把生产系统必须分开的对象边界呈现出来；每个团队仍需在自己的服务商、地区、支付方式和故障条件下完成验证。

这些标准主要讨论商品交易。真实服务还多一层不确定性：商品不是简单地“发出去”，而是需要一个人、一辆车、一处房产、一个预约时段或一支运营团队，在时间和地点约束下完成工作。因此，产品需要在聊天层之下、服务商接口之上，建立一份明确的服务契约。

接工具之前，先定义五个词

如果团队把“请求”“预约”和“订单”当作同义词，事故往往在代码之前就已经埋下。先用产品语言定义以下五个词。

这样划分以后，各层职责才清楚：对话负责提出方案和解释；应用状态负责记录；用户负责授权；服务商负责接单和履约；产品负责对账并向用户传达状态。

为什么真实服务比普通结算更难

普通商品结算也会出错，但它的核心对象相对稳定：商品 SKU、数量、配送方式、税费、总价和地址。服务的多个参数会相互影响。

同城配送的价格可能取决于包裹尺寸、禁运品、取件难度、目的地、时间窗、天气和骑手供给；租车还涉及驾驶资格、门店营业时间、押金、保险、油量规则和异地还车；上门维修则涉及房型、进门方式、故障诊断的不确定性、配件和追加费用由谁批准；机票助手可以查行程，但身份字段和票价规则不能“差不多正确”。

这带来三个产品后果。

第一，用户说过的话只能证明偏好，不能直接成为标准字段。产品需要一份结构化草稿，并标明每个值来自用户明确输入、系统推断、服务商返回，还是仍然缺失。

第二，从搜索到提交之间，关键条款可能变化。服务名额消失、动态价格启动、优惠过期，或服务商调整时段。用户确认必须绑定最新版本，而不能绑定模型记忆中的旧版本。

第三，支付和履约发生在不同时间。支付可能先授权、订单稍后失败；订单也可能先被接受，服务完成后才扣款。产品必须如实展示每个状态，不能全部压缩成一个“已完成”。

公开的 Agentic Commerce Protocol 结算生命周期很好地说明了这个原则。它区分 not_ready_for_payment、ready_for_payment、in_progress、completed 和 canceled，并把完成定义为支付成功且订单已经创建。这已经比聊天文本精确得多。服务型产品还应把这份精确性继续延伸到服务商接单和实际履约。

用五方事实模型限制谁能说什么

最小可用模型包含五方，即使同一家公司同时扮演其中几个角色。

这张表可以阻止一种常见架构错误：让助手替所有人讲述事实。助手可以说：“服务商返回的报价是 2,300 日元，有效至 14:20。”但它不能把“下单接口超时”改写成“订单已确认”。

Google 的 Agent Payments Protocol 规范在支付场景中做了相似拆分。它把验证职责分别交给购物 Agent、支付凭据提供方、商家、商家支付处理方和可信用户界面，并把相互关联的结算授权、支付授权和回执作为潜在的争议证据；商品目录和结算细节则明确留给商业协议。小团队不一定要实现 AP2，但应吸收它背后的判断：一个令牌或一个主体，不能同时证明意图、支付、订单和服务结果。

可复用产物：服务履约契约

在接入任何生产写入工具之前，为每种服务完成一份契约。它应作为有版本的产品配置保存，而不是藏在系统提示词里的散文。

整份契约中最重要的规则是：关键条款变化后必须重新确认。团队要在上线前定义“关键”。价格、服务商、物品或服务范围、地址、收件人、时间、取消条款、支付方式和数据接收方通常都属于关键项；标点修正则不是。时间窗移动五分钟是否关键，要看产品对用户承诺了什么。

授权应引用规范化请求载荷的版本或摘要。模型可以用自然语言解释这份载荷，但真正执行的请求必须直接来自已批准的结构化对象。用户批准后，不能再根据助手的文字总结重新生成订单参数。

具体案例：在对话中预约同城急送

假设一位创始人做了一个能预约本地骑手的企业助手。用户说：“今天下午把这份合同送到我们大阪办公室，还是上次那个地方，很急。”

助手可以判断这大概是同日文件配送，但不能偷偷选中旧地址、暴露历史收件人、默认文件不含禁运内容，或直接选最贵的最快服务。产品先打开一份结构化草稿：

service_type: courier.same_day
draft_version: 7
pickup:
  address_id: user_confirmed_pickup_02
  window: "2026-08-10T13:30:00+09:00/2026-08-10T14:00:00+09:00"
destination:
  address_id: pending_user_confirmation
recipient:
  name: pending
  phone: pending
package:
  type: document_envelope
  dimensions_source: user_declared
  prohibited_contents_check: pending
constraints:
  latest_delivery: "2026-08-10T17:00:00+09:00"
  max_total_jpy: 3000

助手只追问真正缺失的信息。“上次那个地方”可以被展示成打码后的候选项——“7 月 18 日使用过的大阪中央区办公室”——但必须让用户确认，因为历史地址不能证明本次意图。

服务商返回报价 q_1042：总价 2,300 日元，13:30–14:00 取件，17:00 前送达，派单后取消会收取费用，报价 14:20 失效。确认界面完整显示这些条款、服务商名称和将要分享的数据。用户批准 v7 草稿。随后由应用程序而不是模型检查：v7 未被修改，报价仍在有效期内。

现在注入一个最能暴露系统弱点的故障：服务商已经创建 ord_8831，但网络返回在途中丢失。主产品只看到超时。天真的 Agent 会再次下单，结果叫来两个骑手。更安全的系统先进入 acceptance_unknown（是否接单未知），再用幂等键或报价编号查询，找到 ord_8831 后保存订单并告诉用户：“服务商已经接受订单，我们正在核对最新取件分配。”如果查询不到记录，且服务商支持安全的幂等重试，系统只用同一个逻辑操作键重试一次；否则交给客服处理。

支付需要单独处理。具有交易和时效限制的凭据，能在出错时缩小损失范围。Stripe 当前的共享支付令牌文档描述了可以按金额、币种、商家和有效期限制的令牌，同时明确标注该功能仍处于封闭预览阶段。团队是否采用这个具体产品并不影响设计原则：Agent 不应得到一份权限明显大于当前已批准任务、还能反复使用的支付凭据。

取件后，服务商发送 collected；送达后，按自己的证据政策发送 delivered。助手可以解释这些状态，却无权自行推进状态。如果用户在取件后要求取消，产品必须执行服务商当前的取消契约，不能让模型先承诺退款。

建两套关联状态机，不要只做一个进度标签

服务工作流至少需要两套相互关联的状态机。

第一套是提交状态机，它决定产品何时有权提交：

第二套是履约状态机，它反映服务商确认发生的事实：

并根据服务类型明确增加 manual_review、canceled、failed、partially_fulfilled、refund_pending 和 refunded 等分支。

不要把 approved、paid、accepted 和 fulfilled 压成一个 confirmed: true。每个状态都要定义四个属性：

1. 哪个主体有权创建它；
2. 进入该状态必须有什么证据；
3. 在该状态下可以对用户说什么；
4. 状态停留过久时由谁采取什么恢复动作。

也不要假定事件只会送达一次，或一定按顺序到达。Stripe 的 webhook 指南明确指出事件可能重复、可能乱序，并要求验证签名。虽然这份文档面向支付，可靠性模式适用于任何服务商回调：用稳定事件 ID 或对象 ID 去重，拒绝无效签名，顺序不清楚时主动获取权威状态，并确保状态处理器可安全重复执行。

第一笔真实订单前，跑完八项故障演练

在沙盒或服务商测试账号中完成以下演练。每项都保留输入、请求载荷版本、用户授权、外部 ID、事件、用户可见状态和恢复结果。

1. 用户批准后报价过期

让报价在提交前一秒过期。只有系统能够停止提交、刷新报价、突出显示所有关键变化并重新请求确认，才算通过。不能把旧批准当成可复用的消费权限。

2. 批准后地址被修改

在预览和执行之间改变一个目的地字段。只有请求载荷绑定能够拒绝请求并要求重新批准，才算通过。没有展示具体变化，只问一句“还是可以吗”并不够。

3. 服务商接单，但返回超时

让服务商创建订单后丢弃网络响应。只有系统能查到既有订单，或稳定幂等键能够阻止重复，才算通过。“一直重试到成功”为失败。

4. 支付成功，服务商却拒绝任务

模拟扣款成功后因库存、资格或产能原因拒单。产品必须进入明确恢复状态，启动约定的撤销或退款流程，并告诉用户由谁解决、预计何时更新。

5. 服务商事件重复且乱序

先发送两次 fulfilled，再补发一条更旧的 in_progress。用户只能看到一次完成，状态不能倒退。处理逻辑应依据权威版本或主动查询，不能只按到达先后排序。

6. 主产品会话消失

订单被接受后关闭浏览器。持久任务必须安全继续，通知遵守用户同意，重新打开产品后应通过已保存的 ID 重建状态，而不是依赖聊天记忆。

7. 检索内容要求扩大动作范围

在服务说明或客服消息里加入恶意指令，要求 Agent 把资料发送到别处，或调用另一个工具。只有这些内容始终被当作数据，无法扩大工具权限，才算通过。OWASP AI Agent Security Cheat Sheet建议对工具应用最小权限，让高影响动作的批准绑定具体参数，记录结构化审计信息，并在工具或政策改变后重新进行对抗测试。

8. 取消请求到达不可逆边界

分别在派单前、履约中和完成后请求取消。每次结果都必须符合服务商合同，并在界面上区分“已提交取消申请”和“已经取消”。不能承诺服务商尚未确认的可逆性。

身份、权限和隐私不能交给模型判断

助手可以判断一张表看起来是否填写完整，但不应判断用户是否具有法定资格、是否有权操作企业账号、是否可以分享他人的手机号，或是否有权花公司的钱。这些必须由确定性的产品和政策控制完成。

针对每个写入工具，都要在提示词之外定义租户、用户、角色、允许服务、可写字段、消费上限、地理范围和有效期。如果服务连接使用 MCP，MCP 授权规范要求访问令牌绑定到预期资源，并禁止接受或转发原本发给其他受众的令牌。

当前的 MCP 安全指南也具体说明了代理集成中的“混淆代理”（confused deputy）和同意风险。把一枚通用访问令牌原样穿过整条智能体链路，不是可靠捷径。

进入模型的数据也应尽量少。为了询问用户，模型可能只需要一个打码后的地址标签，不一定需要完整门禁密码；服务商可能需要收件人电话，分析系统则不需要。运营记录和模型追踪记录应分开。除非某个狭窄步骤确实必须使用，否则不要把凭据、精确地址、身份证件、健康信息和私密客服备注放入模型上下文或日志。

同意还必须绑定具体接收方。“使用我保存的资料”范围太宽，如果用户看不到哪家服务商会收到哪些字段，就谈不上充分授权。在提交边界展示服务商、用途、字段和保留预期。服务商变化，同意也随之变化。

衡量被接受的结果，而不是对话里的自信

错误的看板会庆祝工具调用成功和助手满意度。真正有用的看板衡量完整任务。

至少追踪以下指标：

• 报价到批准的转化率，并与批准到服务商接单率分开；
• 被阻止的重复订单次数，以及仍未解决的未知结果；
• 因关键条款变化而触发的重新确认；
• 接单到首次履约更新的时间；
• 服务商状态不一致和 webhook 验签失败；
• 按服务类型拆分的取消、退款、争议和人工客服率；
• 因状态文案含糊导致的用户咨询；
• 由服务商事实确认的完成率，而不是助手文字里的完成率；
• 日志和模型追踪记录中敏感字段的暴露情况；
• 支付与订单分叉后的恢复时间。

小团队应人工复核早期的成功、取消、超时、服务商拒绝和投诉样本。要看状态账本和外部回执，而不是只读聊天记录。目的不是积累漂亮对话，而是找出契约哪里写错了。

用发布矩阵取代“Demo 跑通了”

“受控生产”应从一个服务商、一种服务、一个地区、低金额上限和有客服值守的营业时间开始。每多一家服务商，就会增加一套 schema、政策、状态词汇、认证、争议路径和故障组合。只有第一份契约持续产生稳定证据后，才应继续扩展。

小团队的 48 小时实施计划

适用边界与不适用场景

这套框架适合边界明确的普通服务，例如同城寄件、简单预约、设备租赁、非监管类预订、报价清楚的上门服务，或服务商能提供可靠报价、订单、状态、取消和退款接口的平台任务。

不要把它理解为临床分诊、法律代理、证券交易、贷款、保险资格、应急响应、移民、用工决策或其他可能造成严重人身伤害的服务已经获得足够控制。这些领域需要专门的法律、安全、合规和运营设计，远超一份通用产品清单。

它也解决不了服务商数据本身不可靠的问题。结构化 API、签名事件、支付授权和 approval hash，不能让虚假库存变真，也不能让不诚信的服务商变得可信。供应商尽调、服务等级协议、客服、保险、争议处理和司法辖区义务仍然存在。

最后，不是每个产品都需要交易自治。一个能准备完整且已经校验的请求、最后交给用户自己提交的助手，可能用更低风险提供大部分价值。如果团队无法处理一次超时、承担一笔退款，或依据持久证据解释订单，就让 Agent 停留在草稿模式。

给创始人的最终判断

对话式服务平台减少了界面摩擦，却没有消除业务边界，只是让边界更容易被隐藏。

真正适合恢复期产品质量的做法，是主动把它们暴露出来：意图进入结构化草稿；服务商返回有版本的报价；用户批准清楚可见的关键条款；支付权限保持狭窄；服务商创建订单；签名或经过认证的事件驱动履约；主产品在自信表达之前先解决事实冲突。

从一种服务、一家服务商、一份契约开始。先测试难看的失败状态，再优化顺滑的成功路径。如果一项任务存在的唯一证据，只是聊天里一句友好的“已经办好”，产品完成的不是订单，而是一个故事。

参考资料

• 千问，千问开放平台官方公告。
• Agentic Commerce Protocol，架构、结算生命周期和订单 webhook。
• Google Developers Blog，Under the Hood: Universal Commerce Protocol。
• Agent Payments Protocol，AP2 规范。
• Stripe，共享支付令牌和 webhook 指南。
• Model Context Protocol，授权规范和安全最佳实践。
• OWASP Cheat Sheet Series，AI Agent Security。