很多人可能被这个标题里的“立规矩”三个字吸引了。亚马逊这次确实动手了，而且针对的就是现在最火的AI Agent：以后凡是Agent替用户在亚马逊上下单，必须先向买家声明“我是AI在替你操作”；不声明身份就代替用户买买买，账号可以直接被清退，订单也可能不认账。做技术的人看到这条消息，第一反应可能是“平台又要限制自动化了”，但真正研究过规则的人会明白，这是一次规范化的信号，远比表面上的限制有意思。

我第一时间把这条规则和手头几个购物Agent项目做了对照，越看越觉得，这不仅是平台治理的升级，更是所有Agent开发者迟早要面对的合规门槛。这篇就围绕“不亮身份，别想替用户下单”展开，聊聊规则背后的治理逻辑、Agent开发侧怎么接招，以及它对整个Agent生态的连锁影响。

1. 亚马逊这波操作，等于给Agent划了一条“身份红线”

1.1 政策原文拆解：下单前不说实话，订单就作废

要理解这个政策的全貌，得先把它当成一纸合同条款来读。亚马逊这次更新的核心内容，用大白话翻译就是三句话：第一，如果你在购物场景里用了Agent，在下单之前，这个Agent必须主动向消费者披露“我是AI，我在替你操作”；第二，这个披露不能藏在犄角旮旯里，必须是消费者在确认订单前能看到的信息；第三，如果Agent没有做这个披露，就代替用户完成了购买，亚马逊保留关闭账户、终止服务的权利。

条款里提到的对象是“purchasing agents”，也就是所有干购买这件事的Agent一视同仁，不管你是自己写的脚本，还是接的第三方AI购物助手。这个定义范围很关键，它不是只针对某个品牌的Agent工具，而是把所有能独立完成下单动作的智能体全部纳入了管理范围。换句话说，只要你的程序具备“代替用户完成交易”的能力，就落在这个规则的射程之内。

有意思的是，亚马逊没有选择一刀切禁止Agent下单，而是选择“必须先亮明身份”。禁止当然更省事，但那等于放弃了整个购物Agent市场；强制披露，则把信任问题前置化：允许你做，但你得让所有人知道你是AI。这种思路其实是很多平台从“堵”转向“治”的典型路径，先把行为主体识别清楚，后续策略才有落地的抓手。

1.2 亚马逊真正在防的，是这四类失控风险

为什么亚马逊偏偏在这个时间点给Agent立规矩？表面看是治理补位，实际上是为了堵住四类已经出现苗头的失控风险：

第一个是批量下单和虚假订单。Agent的可怕之处在于它可以把“快”发挥到极致，真人手速再快，一两分钟也就完成一笔订单；Agent却可以在同一时间开几十个会话，高频创建订单、反复取消，把平台的库存和推荐系统当成压力测试场。批量操作恰恰是电商平台最头疼的行为，因为它会直接扭曲商品的真实销量和库存数据。

第二个是责任主体模糊。真人用户下单出问题，平台可以找用户沟通，可以走退款流程；Agent下单出问题，用户一句“我没看清，是Agent选的”就能把责任推得干干净净。如果没有身份标记，平台连找谁核实都说不清楚，后续的投诉、退款、纠纷调解全部陷入死循环。

第三个是数据污染。Agent的访问模式和人完全不同，它会跳过很多人类才会有的浏览行为，直接命中目标商品、直接下单。这种流量大量涌入之后，点击率、转化率、停留时长全部失真，平台的推荐算法和商家的投放策略都会被带偏。数据污染有时候比经济损失更麻烦，因为它是慢性腐蚀。

第四个是自动化扩散的不可控性。一套Agent框架可能被部署到上千个账号上使用，一旦策略出问题，爆发的不是单个账号违规，而是规模化合规事故。这个风险在信用卡风控、账号安全领域已经有过很多教训，平台必须提前约束。

2. 为什么偏偏是“下单”这个动作最需要身份声明

2.1 购物Agent带来的信任缺口，比想象中更严重

你可能会想，Agent帮用户搜商品、比价格、看评论，这些动作平台怎么不限制，偏偏盯上下单？因为购物链路里的大量动作属于“浏览型”操作，搜商品、看评价、比价格，Agent做这些时平台最多损失一点流量和用户注意力，风险可控。但下单是“契约型”动作，涉及付款、履约、退款、售后，法律上讲，这个动作必须由具有民事行为能力的主体来负责。

Agent一旦介入下单环节，信任缺口就出现了。用户不在场，Agent自作主张；商家收到订单，却找不到真实决策人。我举个特别常见的例子：用户给Agent设了一个“500元以内帮我买一双通勤鞋”的指令，Agent凌晨看到一个促销活动，觉得符合要求就下单了，结果鞋码不对、款式不喜欢。这时候用户说“我没仔细看，是Agent选的”，商家说“订单明明是你账号下的”，平台夹在中间，如果连这个操作是不是Agent完成的都不知道，根本没有办法做出裁决。

这种模糊状态就是交易信任的腐蚀剂。身份声明机制的作用在于，把这个模糊的状态拉回到明面上：用户知道自己在用AI代劳，商家知道这单背后是个Agent，后续所有的售后、投诉、退换货都按规则来，谁也不吃亏。

2.2 身份披露落地后，责任边界才能说得清

身份披露一旦成为硬性规则，其实是在帮三类角色划清责任边界。

对消费者来说，看到“此操作由AI Agent执行”的提示，就会本能地多看一眼订单详情，不会出现“我以为是人推荐的”这种误解。这一点非常重要，因为Agent购物最大的隐患不是技术失灵，而是用户预期错位。用户以为Agent比自己还懂自己的需求，实际Agent只是按预设参数匹配，披露提醒能有效降低这种预期落差。

对平台来说，Agent订单可以走专用的风控通道。比如限制Agent下单的品类、金额阈值、频次，或者在高峰期对Agent请求做排队限流。没有身份标记时，平台只能靠行为特征去猜“这是不是机器人”，规则永远慢半拍；有了身份标记，策略可以直接命中，又不会误伤真人用户。

对开发者来说，披露本身是自我保护。Agent拥有独立身份后，出了争议可以有完整的链路日志，能说清楚“这个订单在什么条件下、由哪个Agent、依据什么用户指令产生”，反而比身份不明的脚本更有公信力。说白了，身份披露不是一个单方面被管束的动作，它同时给开发者和用户上了一道保险。

3. Agent开发者怎么接招：合规身份声明的落地方案

3.1 让Agent学会“自报家门”的三种实现路径

明确了规则之后，技术问题就来了：Agent怎么才能做到“自报家门”？目前业内没有统一标准，但可以从三个层级去实现，我分别说一下优缺点。

界面层声明是最直观的。Agent在它的交互界面，比如浏览器插件、App、桌面客户端里，在下单前弹出一个明确的提示：“当前操作由AI Agent执行，是否继续？”这个方案适合有独立客户端的购物Agent产品，它的优势是用户看得见、感知强，劣势是只能覆盖自家界面。如果Agent是通过脚本方式直接操作网页，这种声明方式就失效了。

请求层声明是偏技术的手段。在HTTP请求层面加自定义头，比如X-Agent-Declared: true，同时在User-Agent里带上Agent的名称和版本。平台的风控系统只要读到这个头，就能识别出这是一次Agent操作。这个方案实现成本低，适合脚本型Agent，但需要平台主动认账，如果平台没有对应的识别逻辑，这个头基本上属于“我声明了但对方没听见”。

平台API对接是最规范的路径。如果Agent调用的是平台官方API，可以在请求参数里显式传递agent_id和purpose字段，平台在授权时就给Agent一个独立的开发者身份。这个方案的合规强度最高，也最能拿到平台侧的业务支持，但前提是平台开放了相关接口权限，并且你的Agent通过了申请。

三个方案不是三选一，现实的工程里往往是组合拳。我的建议是：前端声明用来获取用户确认，请求头声明用来给平台做风控识别，官方API对接用来做深度合作。只做其中一项，遇到较真的平台还是会被卡。

3.2 从框架到生产：把“Agent身份标签”放进开发生命周期

如果你的Agent项目现在还没有任何身份披露机制，不用慌，补起来并不难，关键是别把它当成最后才加的补丁，而是当做一个基础模块，嵌入Agent的开发、测试、上线的整个生命周期。

第一步，在Agent的配置文件里增加一个身份信息段。以最常见的YAML配置为例，可以这样写：

agent: name: "shopping-helper" version: "1.0.0" disclosure: enabled: true message: "当前操作由AI Agent执行" level: "before_purchase"

这段配置干的事，是让Agent在每次下单前自动触发披露逻辑，而不是依赖开发者临时想起来。配置化设计的价值在于：以后政策调整，比如某个平台要求更严格、或者允许放宽，改配置就能适配，不用大改代码。

第二步，把“下单前声明”封装成一个通用的Agent Skill。现在业界常说Agent Skill，其实就是把一些高频动作沉淀成可复用的能力模块。购物类Agent完全可以共用一个“身份声明”Skill，它负责生成统一的披露文案、记录披露时间、把披露状态写进会话日志。这样任何Agent在走到购买节点时，都会自动先调用这个Skill，而不是每个项目各写各的、各有各的漏。

第三步，给Agent的每一次会话绑定唯一的agent_session_id。这个ID贯穿搜索、浏览、加购、下单、支付全链路，出了纠纷可以精确回溯。我特别强调这一点，是因为很多团队只给用户账号做日志，但同一个用户可能在不同时间、用不同Agent执行了不同任务，如果没有独立的会话ID，排查问题时根本分不清是哪次操作出了问题。

第四步，在Agent Memory里加一个状态位，记录“当前站点是否已经完成身份声明”。Agent记忆不光是用来记住用户偏好的，它同样可以记住自己的操作状态。比如Agent访问某个平台，第一次请求时声明了身份，Memory里就把这个状态置为“已声明”；下一次请求直接复用，不用重复弹窗打扰用户。如果Agent发现平台规则变了或者声明被拒绝，也可以基于这个状态位做快速响应。

这几个步骤看起来琐碎，组合起来就是一套完整的Agent身份基础设施。以后不管你做的Agent跑在什么框架里，是用Rust从零写的高性能Agent，还是基于Spring AI搭的企业级Agent中台，这套身份模块都能无缝嵌入。

4. 这波规矩对整个Agent生态的连锁反应

4.1 平台治理进入“Agent可治理”时代

亚马逊这步棋最大的信号，不是针对某一个Agent产品，而是宣告平台开始把Agent当成“一类用户角色”来管理。以后购物、外卖、出行、订票、内容社区，各类平台大概率会跟进类似的披露规则，只是形式上可能各有差异。这对Agent开发团队其实是利好：规则明确了，运营策略就好落地。

以前Agent在平台眼里是灰色地带，做得太活跃容易被封，做保守了又没效果，全凭平台风控的心情。现在有了合规路径，平台完全可能反过来给已声明的Agent开绿灯。比如允许Agent使用更高频的商品查询接口，但限制下单频次；允许Agent批量比价，但要求它不能绕过页面的交易流程。这就像给Agent修了一条专用道，虽然有限速，但至少比在车流里穿插安全得多。

这种“可治理”的思路还会催生一个新的技术方向：Agent声明协议。虽然现在还是各平台各出各的规则，但已经有讨论在往标准化方向走。比如网站可以通过公开文件声明“此处允许Agent访问，但必须携带身份标识”，Agent访问前先去读这个文件，再决定要不要声明。这个思路很像当年的robots.txt，只不过约束对象从搜索引擎变成了智能体。

4.2 “多Agent协作”和Agent中台需要重新考虑合规层

单Agent的场景还相对简单，真正麻烦的是多Agent协作。你可能已经预想到了：用户唤醒一个购物主Agent，主Agent又调度好几个子Agent去各个平台比价、查库存、最后下单。此时每个子Agent访问的都是不同的平台，如果它们各自不带身份标识，平台根本无法区分这三个操作来自同一个用户、同一个任务，外在表现就是三股独立的陌生流量，很容易同时触发三边的风控。

这是很多多Agent项目容易踩的坑。主Agent声明了一次身份，并不代表它的子Agent也声明了。合规身份必须是每个对外请求的携带属性，而不是某个顶层组件的局部配置。所以在做Agent编排的时候，要把身份信息做“透传”，主Agent的任务上下文里带着用户授权和Agent身份信息，子Agent每次对外发起请求时都要从上下文里读取并带上。

企业级Agent平台和中台就更需要提前规划了。我的建议是，中台可以做一个“身份披露中心”，统一管理所有接入Agent的对外身份配置，包括Agent类型、调用方、使用场景、授权状态、声明话术。这个中心对外提供一套统一SDK，无论底层Agent是用什么框架写的，接入中台后都走同一套身份声明逻辑。这样既避免各团队各做各的，也为未来对接不同平台的规则留出了统一出口。

5. 留给从业者的几个实操提醒

5.1 别把合规当负担，这是Agent基础设施的一部分

我看到不少同行第一反应是“平台又来限制Agent了”，但其实换个角度看，强制披露是在帮Agent行业建立基本的信任基础。没有身份披露机制以前，平台分不清Agent和真人，为了安全只能一刀切，结果真正的优质Agent产品也被误伤。现在有了规矩，至少多了个对话空间。

我自己维护的几个购物Agent项目，最近全部把身份披露加到了默认配置里。刚开始确实觉得多此一举，但跑了一段时间后发现，调试反而更顺畅了。因为所有对外请求都带了Agent标识，日志里能一眼看出哪个功能、哪个Agent、哪次会话出了问题，不用再从一堆混在一起的行为数据里大海捞针。身份声明这个机制，在合规之外还给了开发者一个免费的“可观测性”增益。

5.2 从亚马逊的规则反推Agent产品设计的五个检查项

最后给大家整理一份自查清单，做购物类Agent，或者任何一个涉及替用户执行交易的Agent，上线前过一遍这五个检查项：

一是用户能否在可见界面看到Agent身份。这不只是合规要求，也是用户体验的底线。用户有权知道正在替自己做决定的是一个程序。

二是服务端能否识别Agent身份。也就是说，你的Agent技术栈里有没有对应的头和标识，不是只在界面上显示，而是每个请求都要带上。

三是订单和会话有没有独立ID。没有独立会话ID，就没有追溯能力，一旦出现争议你会非常被动。

四是平台拒绝时能否快速降级。比如平台读到Agent声明后返回拒绝，Agent能不能优雅地停止操作，而不是强行重试直到被彻底封禁。

五是下单前有没有二次确认。这一点尤其重要。身份声明是给平台看的，二次确认是给用户看的，两个动作叠加才算完成了合规闭环。

我个人的判断是，亚马逊这一步开了个头之后，类似的披露规则很快会成为各类交易平台的标准配置。现在就把身份声明当成Agent系统的默认组件来设计，后面政策怎么变你都不会慌。把身份亮在前面，把丑话说在前面，反而是Agent生态走得远的必要条件。最后分享一个自己写代码时的习惯：凡是涉及支付、下单、权限变更的动作，我都会强制绑定“身份声明加用户确认”两个前提。以前觉得这么设计有点过于保守，现在平台直接把它变成规则，反倒觉得当初的坚持值了。这个习惯，建议做Agent的同学都尽早养成，省得到时候手忙脚乱。