一位客户从未访问过你的店面。没有购物车被放弃，没有页面浏览日志，分析工具中也没有记录到“加入购物车”的点击。然而，一笔付款到账了，一份订单发货了，而一项拒付风险现在正挂在你的账簿上，与一个实际上从未看过屏幕的买家绑定在一起。
这正是 2026 年占比日益增长的交易写照。一个 AI 代理（位于 ChatGPT、Gemini 内部，或基于新型智能体商业协议构建的购物助手）代替人类进行了浏览、对比和购买。人类批准了预算和一系列偏好；代理完成了剩下的工作。对于商家来说，这并非假设。Etsy 卖家已经接入了 OpenAI 的即时结账功能（Instant Checkout），超过百万的 Shopify 商家正在陆续加入，而 PayPal 自身的智能体商业服务器预计将在今年年底前将数千万小企业带入这一轨道。
问题在于，大多数小企业的簿记仍然假定是人类点击了“购买”。由代理发起的订单打破了这一假设，其带来的问题首先表现为对账令人头疼，如果予以忽视，则会演变成真正的财务和合规风险。
“智能体商业”对你的账簿究竟意味着什么
抛开炒作不谈，智能体商业（Agentic Commerce）实际上就是委托购物：客户设定一个目标（“帮我找一件 150 美元以下、深蓝色、中号的防水夹克”）和一些限制条件（支出上限、认可的零售商，也许还有一张卡），然后 AI 代理在极少需要进一步输入的情况下处理寻找和购买。大约 58% 的消费者表示，他们已经开始使用生成式 AI 工具进行产品推荐来替代传统搜索——从“浏览后购买”到“委托后批准”的转变已经全面展开，而非未来的趋势。
三个协议家族已经出现以实现这一目标，如果你长期在网上销售，你很可能会遇到这三种协议：
- ACP（智能体商业协议，Agentic Commerce Protocol）——由 Stripe 和 OpenAI 构建，正是它为 ChatGPT 中的即时结账提供支持。代理无法看到客户的真实卡号，而是由客户的支付服务商发行一个共享支付令牌（Shared Payment Token）：这是一个有特定范围、有时限且可撤销的凭证，仅对单一商家和单一金额有效。Stripe 将其描述为一种可编程授权，可通过 webhook 事件进行观察——这至关重要，因为这些 webhook 是你判断非人类买家刚刚完成交易的唯一实时信号。
- AP2（智能体支付协议，Agent Payments Protocol）——谷歌的竞争性标准，得到了包括万事达卡（Mastercard）、PayPal 和美国运通（American Express）在内的 60 多家合作伙伴的支持。AP2 将每次代理购买表现为三个已签署的“授权书”（Mandates）：意图授权书（购物者想要什么）、购物车授权书（代理组合了什么）和支付授权书（扣除什么费用）。每一个都是可验证且经过密码学签署的记录——在理论上，如果你的系统知道如何读取它，这将比典型的人类结账提供更清晰的审计轨迹。
- UCP 等协议——旨在推动机器可读的交付窗口、退货政策和履行数据标准化的更广泛努力，以便代理可以在一致的条款（而不仅仅是价格）上对商家进行比较。
实际结果是：你的店面可能很快就会服务于两种截然不同的客户——人类和在人类授权下行动的软件代理——而你的簿记需要将它们区分开来。
为什么对账变得更难，而不是更容易
你可能会认为，机器生成且经过密码学签署的订单会比人类订单更容易对账。然而在实践中，由于一些具体原因，商家发现情况恰恰相反。
授权链分散在多个地方
单次 ACP 交易可能会涉及授权记录、订单收据、来自支付处理商的结算事件，以及确认是哪个代理（以及在谁的授权下）发起购买的身份记录。当结算事件进入你的银行流水时，将其与实际订单上下文进行匹配——并在发生争议时能够证明这一链路——在早期实施中已经被描述为“多源对账练习”。这是一种委婉的说法，意指：入账金额与该金额所属的订单之间，现在夹杂着比单纯的发票号码更多的层级。
退款需要附加“谁、什么和为什么”
如果 AI 代理自身的客服对等体在你的平台上发起退款——随着零售商自动处理退货，这种情况变得越来越普遍——该退款需要元数据：哪个代理授权了它，基于什么政策，以及为什么。财务需要这些来核对交易；你需要它来防御拒付争议，因为客户也可能通过他们的银行对同一笔费用提出争议，从而产生双重退款风险。多件商品订单的拆分退款以及订阅的比例退款只会使这一问题更加复杂。
拒付敞口已经很大且在持续攀升
预计到 2026 年，拒付争议将给商家造成大约 280 亿美元的损失，交易量自 2023 年以来增长了约 41%——而这还没有考虑到“账户持有人是否真的授权了此操作，还是其代理人逾越了授权范围”这一新增的模糊性。你输掉的每一次争议都会让你损失交易金额、通常在 15 到 100 美元之间的处理商费用，以及在紧迫的网络截止日期前收集证据所需的员工时间。
缺乏清晰授权记录的代理发起订单，在辩护时将变得更加困难，而非更容易。
银行流水无法区分其中的差异
你的银行对账单只显示一笔资金入账。它不会显示该笔入账是来自用户点击“下订单”，还是来自代理（Agent）在 150 美元的预算内执行购物车授权。如果你的会计科目表和对账工作流无法标记来源，你以后就会失去回答基本问题的能力：本季度有多少收入来自代理结账？代理渠道的退款率是多少？代理发起的交易量是否与争议率不成比例？这些并不是抽象的问题——它们是贷款机构、会计师或收单机构最终会问到的问题。
针对代理发起订单的实用对账框架
你不需要成为支付工程师也能很好地处理这个问题。你只需要在现有的任何记账系统中，养成几个规范的习惯。
1. 在销售点标记渠道，而不是事后。 无论你使用的是 Shopify、Etsy 还是自建的技术栈，大多数代理商业（agentic commerce）集成都会传递一个标志或元数据字段，表明订单是通过 ACP、AP2 或类似协议生成的。将该标志捕获为交易标签或子科目（例如“销售收入 — 代理渠道”），而不是将其混入普通的销售收入中。在分不清代理销售和人工销售的状态下运行六个月后再去补救，远比从第一天起就进行标记要痛苦得多。
2. 保留授权或订单收据，而不仅仅是结算记录。 你的支付处理商的款项拨付报告只能告诉你资金发生了转移，但通常无法告诉你完整的授权过程。无论是平台提供的收据、授权引用（mandate reference）还是随订单附带的 Webhook 负载，请将其与你的普通发票记录一并保留。像对待签署的采购订单一样对待它——如果遇到争议，当被问及“这是否真的经过了授权？”时，这就是你的证据。
3. 明确地按扣除费用后的净额进行对账。 例如，OpenAI 的 Instant Checkout 会对已完成的购买向商家收取 4% 的交易费。这是一项真实的成本支出，需要有独立的科目——如果你想真实地对比代理渠道和直接销售之间的利润率，就不要把它埋在通用的“支付处理费”中。
4. 针对代理订单建立独立的退款/争议日志——至少在你对交易量建立信任之前是这样。 因为在这里，“谁发起了退款以及为什么”的问题更加重要。一个简单的流水账日志（刚开始甚至可以用电子表格）记录订单 ID、授权引用、原因以及是由代理还是人工发起，在你第一次遇到同一笔订单同时发生拒付和退款时，能为你节省数小时的时间。
5. 慎重决定是否要接受代理引导的购买。 在 AP2 等协议下，你的店铺可以决定是否接受代理发起的交易，或者对其进行差异化处理（例如验证码、不同的价格、禁用礼品卡），甚至完全选择退出。这既是一个技术决定，也是一个商业决定——在做出决定时，不仅要考虑开拓销售渠道的意愿，还要考虑你的记账和争议处理能力。
核心启示：可审计性一直都是关键所在
代理商业揭示了一个一直以来都成立的事实：交易的可信度完全取决于其背后的记录。从某种意义上说，加密签名的授权和有范围限制的支付令牌（scoped payment tokens），正是代理商业试图解决一个优秀账目一直在努力解决的问题——确切地知道谁授权了什么、授权了多少金额，并能够在日后予以证明。
已经保持账目整洁、标记完善且可审计的小企业，将能够非常轻松地将代理渠道的销售无缝叠加到现有系统中。而那些账目混乱、未作区分的企业则会发现，随着这些渠道交易量的规模化增长，代理商业会把一个微小的记账漏洞放大成棘手的对账和争议抗辩问题。
让你的账目随时迎接下一波商业变革
无论一笔销售是来自人类点击“购买”，还是来自 AI 代理代表他们执行签署的授权，其核心本质都不会改变：每笔交易都需要一条从订单到结算的清晰、可审计的轨迹。Beancount.io 为你提供设计上完全透明且支持版本控制的纯文本会计服务，因此标记一个新的销售渠道（包括代理发起的订单）只需添加一个科目，而无需重构你的账目。免费开始使用，亲身体验为什么在下一波商业变革到来之前，开发者和具有财务思维的企业主都在转向纯文本会计。