《AI进入工作之后》· 第三季“当AI开始代表组织”· 第九篇
买方AI发现某项库存低于安全水平，向三个供应商询价。供应商AI根据库存和客户等级返回价格。买方AI选择最低总成本，要求缩短交付期；供应商AI同意，但提高运费。双方系统交换确认，采购订单自动生成，发票稍后进入财务系统。
整个过程只用了几秒，没有人读过全部消息。货物到达后，买方认为约定包含加急配送；供应商认为加价只是优先处理，并不保证日期。双方各自保存了一段自然语言对话，却没有相同的最终条件版本。
机器之间能够互相说话，并不等于企业之间已经建立一笔可证明的交易。自动交易需要同时解决四件事：身份、授权、共同语义和最终记录。缺少其中任何一项，速度只会更快地产生争议。
把交易看成状态机，而不是一段聊天
人类可以从语气和上下文理解“我们大概可以”“请按这个条件进行”“已确认”的差异。AI高速交互不应依赖这种模糊性。每笔交易需要明确状态：
询价 REQUEST_FOR_QUOTE
→ 非约束报价 QUOTE
→ 反建议 COUNTEROFFER
→ 待批准 PENDING_APPROVAL
→ 正式接受 ACCEPTED
→ 已下单 ORDERED
→ 已履行 / 已取消 / 争议状态转换应由结构化事件触发，并记录谁有权触发。自然语言可以解释条件，但不能单独承担交易状态。否则一句友好的“没问题”可能被一方系统解析为接受，另一方解析为继续讨论。
每次状态变化还要绑定完整条件版本。价格变化后，旧交付期是否仍有效？修改数量后，折扣是否重算？系统应产生新的整体版本，而不是假定双方会从散落消息中拼出相同答案。
先验证组织身份，再验证代理身份
电子交易中的“谁”至少有三层：法律实体、代表该实体的系统账户，以及本次任务中的具体代理实例。
域名或API密钥只能证明某个技术凭证被使用，不一定证明凭证仍有效、调用来自批准工作流，或代理有权处理这类交易。一个被盗令牌、测试环境或离职员工遗留集成，也可能发出格式完全正确的订单。
双方应交换并验证：法律实体标识、服务提供者或接入点、代理角色、授权范围、凭证状态和时间。高价值交易还需要更强确认，不能因为前几次低额订单成功就永久扩大信任。
澳大利亚电子发票采用Peppol框架，使企业能够通过标准化网络交换结构化发票数据。澳大利亚税务局：《eInvoicing》 电子发票并不等于AI自主谈判，但它展示了关键方向：可靠的机器交易依赖共同网络规则、参与者身份和结构化业务文档，而不只是两个聊天机器人互相理解。
授权必须附着在交易上，而不是藏在企业内部
买方可能允许AI自动购买日常耗材，但只限于批准供应商、单笔金额和月度预算。供应商可能允许AI接受标准条款，却无权改变责任或交付保证。
当系统发送订单或接受时，应附带可验证的授权上下文：授权政策版本、金额范围、商品类别、审批标识和有效期。对方不一定能看到内部政策全部内容，但至少应能验证此次动作来自具有相应权限的渠道。
授权还需要双向检查。买方AI不能只确认自己有权购买，还要确认供应商系统有权承诺价格和交付；供应商同样要确认订单不是未经批准的试探性请求。
澳大利亚《1999年电子交易法》提供电子通信归属、发送和接收等规则。澳大利亚联邦立法登记册：《Electronic Transactions Act 1999》 具体交易的法律效果仍依事实与适用法判断，但系统设计不能假定“来自对方服务器”就解决所有授权问题。
共同语义比共同语言更重要
两个AI都使用英文，不代表它们对“工作日”“交付”“收到”“取消”或“总价”有相同定义。一个系统可能把税费计入总价，另一个不计；一个以发货时间为履行，另一个以签收为履行。
结构化交易需要数据字典、单位、币种、时区、税务处理、产品标识和条款引用。自然语言解释应指向明确字段，而不是代替字段。
例如：
price_total: 12,500 AUD including GST
delivery_commitment: received_by
delivery_time: 2026-08-20T17:00:00+10:00
quantity: 500 units
terms_version: SUPPLIER-STANDARD-4.1
status: PENDING_BUYER_ACCEPTANCE这种记录看起来比聊天笨重，却使双方系统和后来的人能够判断同一事实。AI仍可帮助把复杂对话映射到字段，但在状态改变前必须验证所有必要字段一致。
Peppol BIS Billing规范展示了机器可读商业文档怎样使用统一业务术语和验证规则。OpenPeppol：《Peppol BIS Billing 3.0》 自动采购涉及更多文件和条款，但原则相同：互操作性来自约定语义，不来自模型猜测。
最终记录必须由双方共同确认
如果每家公司只保存自己的对话摘要，争议时会出现两个“真实版本”。一笔自动交易应产生双方可验证的最终记录，包含：
- 双方实体和授权身份；
- 完整条款与引用版本；
- 所有重大变更；
- 正式接受事件与时间；
- 交易唯一标识；
- 完整性校验，例如文件哈希或数字签名；
- 撤回、替换和纠正记录。
双方不一定使用同一数据库，但应各自保存内容一致、可验证关联的版本。后来生成的AI摘要可以帮助阅读，不能替代原始结构化事件。
最终记录还应区分商业文件：报价、订单、订单响应、发货通知、发票和贷项通知不是同一东西。发票不能反过来证明对方接受了此前从未确认的条件。
错误处理必须成为协议的一部分
机器交易总会遇到重复消息、延迟、超时和不一致。若买方重试请求，供应商是否会创建两份订单？如果接受消息到达但回执丢失，买方能否安全重发？如果价格源在交换中途更新，哪一版有效？
系统需要幂等标识、确认回执、超时状态和冲突规则。任何一方不应根据沉默推断接受，除非适用制度和双方协议明确允许。
UNCITRAL的《自动化缔约示范法》处理自动系统参与合同、输入错误和归属等问题，为各国可能采用的法律框架提供模型。UNCITRAL：《Model Law on Automated Contracting》 技术协议不能替代适用法律，但可以减少本可由系统避免的事实争议。
错误也要分层：格式错误可自动拒绝；库存变化可要求重新报价；超出授权应转人工；疑似凭证泄露则应暂停交易渠道。不能让AI用自然语言自行“协商解决”一个身份或安全事件。
人类不能只在争议后出现
完全自动并不意味着完全没有人。双方企业需要预先指定交易所有者、权限政策所有者和争议联系人。达到金额、条款、新供应商或异常模式阈值时，交易必须在正式接受前暂停。
人工界面应展示状态差异和未决条件，而不是完整聊天记录。决定者需要知道：标准条款偏离在哪里，总成本怎样变化，哪个代理提出变化，对方是否已依赖，以及接受后能否撤回。
还应定期抽样已完成交易，比较机器记录、实际交付、发票和付款。若系统总能完成订单却不断产生贷项和争议，自动交易只是把问题推到下游。
两个AI之间也需要最少必要信息
为了谈判，代理不需要交换完整客户画像、内部库存预测或对方无法验证的模型理由。每方只应分享完成交易必要的条件和证明。
外部消息始终是不可信输入。交易网关应验证结构、大小、附件和允许字段，把自然语言与系统指令隔离，再交给AI解释。执行层不能让对方文本直接触发内部付款、权限改变或敏感资料访问。
这使机器交易成为制度间接口，而不是两个模型的私人对话。真正建立信任的是协议、身份、权限和记录；模型只是在这些边界内提高理解与协商效率。
结论：有效交易不是两台机器达成一致，而是两个组织能够证明一致
AI之间可以很快交换语言，却可能以不同方式理解身份、状态和条款。自动交易成熟的标志，不是人从流程中完全消失，而是每一步都能被组织重建并承担。
最终原则是：
机器之间的订单只有在双方身份可验证、代理权限与交易相称、条款使用共同语义、接受状态明确，并且双方保存同一可验证最终版本时，才应进入正式执行。
速度不应靠省略交易形成过程获得。最好的自动交易，把人从重复录入中移开，却保留企业必须共同回答的问题：谁同意了什么，在什么时候，根据哪一版条件，以及错误怎样撤回。
主要资料
- 澳大利亚税务局：eInvoicing
- 澳大利亚联邦立法登记册：Electronic Transactions Act 1999
- OpenPeppol：Peppol BIS Billing 3.0
- UNCITRAL：Model Law on Automated Contracting
继续阅读：浏览《AI进入工作之后》系列文章
了解 Geoffrey Chen 的更多信息
订阅后即可通过电子邮件收到最新文章。