最近AI Agent 又遇到了一次现实世界的拦截。Amazon 阻止了 Meta 的 Muse AI Agent 在 Amazon.com 上浏览和下单。Amazon 方面称Meta 没有获得授权Muse 也没有明确标识自己是自动化 Agent同时还涉及用户凭据、隐私和平台控制权等问题。Axios 报道这件事的意义不只是Amazon 不让 Meta 的 AI 买东西。它真正暴露的是一个更大的问题当 AI Agent 代表用户访问第三方平台时平台有没有权利拒绝它过去我们讨论 AI Agent更多关注的是模型够不够聪明能不能调用工具能不能自动执行任务能不能使用浏览器能不能替用户完成购物、订票和发邮件。但现在Agent 开始进入真实商业系统新的问题出现了Agent 是否获得了平台授权平台能不能识别这是 Agent用户授权是否等于平台授权Agent 是否应该保存用户密码自动下单失败后由谁负责平台是否必须开放自己的数据和交易流程Amazon 封禁 Muse说明 AI Agent 的下一阶段竞争不只是模型能力的竞争也会是身份、协议、授权和平台规则的竞争。一、Meta Muse 想做什么Meta 推出的 Muse不是传统的聊天机器人。它的目标是让 AI 直接替用户完成一系列线上任务例如搜索商品比较价格选择产品代替用户填写表单处理线上事务进行购物取消订阅管理部分数字生活。Axios 报道称Muse 被 Meta 定位为一个可以代替用户执行日常线上任务的个人 Agent并且已经获得了较高的消费者关注。Axios 对 Meta Muse 的报道传统聊天机器人通常是User asks ↓ Model answers ↓ User acts on their own而 Muse 代表的新模式是User states a goal ↓ Agent understands intent ↓ Agent searches and compares ↓ Agent calls websites or tools ↓ Agent executes the action ↓ User confirms or receives the result例如用户不再需要自己打开电商网站、输入关键词、比较商品和填写订单而是直接说帮我找一款适合通勤的降噪耳机预算不超过 200 美元明天送到。Agent 可能会搜索商品读取价格比较评价检查库存确认配送时间把候选商品交给用户在用户确认后提交订单。从用户角度看这比传统搜索更加方便。但从平台角度看Agent 可能正在绕过原本的入口、广告、推荐和结算流程。二、为什么 Amazon 会封禁 Muse根据 Amazon 对外的说法主要涉及几个问题。1. 没有得到平台授权Amazon 认为第三方 Agent 不能默认获得访问和购物权限。用户愿意让 Meta 帮自己购物不一定代表 Amazon 已经同意 Meta 的 Agent 使用 Amazon 的商品、库存、账号和结算流程。这里存在两种授权User authorization Platform authorization用户授权解决的是用户是否允许 Agent 代替自己操作平台授权解决的是Amazon 是否允许这个 Agent 访问自己的服务这两种授权不是同一件事。2. Agent 没有明确表明身份如果一个普通用户访问 Amazon平台可以按照普通用户请求处理。但如果请求实际来自 Agent平台可能需要知道这是人还是机器是哪个 Agent代表哪个用户是否得到了用户确认是否允许自动下单是否需要额外风控。如果 Agent 把自己伪装成普通用户平台就无法准确判断风险。这也是未来 Agent 身份标准必须解决的问题。3. 用户凭据如何处理Amazon 还担心第三方 Agent 如何处理用户登录信息和支付凭据。最危险的方式是User gives Amazon password to the Agent ↓ Agent stores the password ↓ Agent mimics user login and places order这种方式的问题非常明显Agent 服务可能保存敏感信息密码可能进入日志账号可能被滥用订单操作无法细粒度撤销平台无法知道操作是否得到用户确认。更合理的方式应该是 OAuth 或平台官方授权机制User completes authorization on Amazon page ↓ Amazon returns a scoped access Token ↓ Agent uses Token to call permitted APIs ↓ Token can expire, be revoked, and be scopedAgent 不应该直接拥有用户的原始密码。三、这不是单纯的反爬虫问题很多人看到 Amazon 拦截 Muse 后第一反应是这不就是封 IP 或反爬虫吗实际上Agent 和传统爬虫并不完全一样。传统爬虫主要关注抓取网页内容建立搜索索引批量采集数据读取价格和库存。Agent 则可能进一步执行登录选择商品填写地址提交订单使用支付方式发起退款修改账户设置。因此Agent 的问题不只是能不能读网页而是能不能代表用户完成具有法律、财务和业务后果的操作可以把访问分成四个等级级别行为风险L1阅读公开页面低L2搜索、比较和提取信息中低L3登录并操作用户账户中高L4下单、付款、退款和修改数据高未来平台可能允许 Agent 完成 L1、L2但对 L3、L4 要求额外认证和人工确认。四、AI Agent 的权限墙是什么所谓平台权限墙可以理解为Agent wants to execute a task ↓ Platform checks whether it is eligible to access ↓ Platform checks which data it can access ↓ Platform checks which actions it can perform ↓ Platform decides whether to allow it to continue这和传统 API 权限控制很像但 Agent 场景更加复杂。传统 API 通常是Application A - API B而 Agent 系统可能是User ↓ Agent ↓ Model ↓ Tool ↓ Third-party platform ↓ Payment, order, or production system中间多了一层模型决策。这意味着系统不仅要验证请求来自哪个应用还要验证代表哪个用户模型做了什么判断用户是否确认Agent 是否有权限工具是否被允许这次操作是否超过风险阈值。五、Agent 调用外部平台的正确架构一个更安全的 Agent 系统可以拆成以下几层User layer ↓ Agent application layer ↓ Model invocation layer ↓ Permission and policy layer ↓ Tool invocation layer ↓ Third-party platform1. 用户层负责确认用户是谁用户提出了什么目标哪些操作需要确认用户是否允许 Agent 执行。2. Agent 应用层负责保存任务状态规划流程管理会话展示操作进度在高风险节点暂停。3. 模型调用层负责选择合适模型处理自然语言生成工具调用参数返回结构化结果。4. 权限和策略层负责判断工具是否允许调用判断用户是否有权限设置金额、次数和范围限制判断是否需要人工审批。5. 工具调用层负责使用 OAuth Token调用平台 API处理错误记录请求屏蔽敏感凭据。6. 第三方平台负责验证 Agent 身份验证用户授权执行最终业务操作保留平台侧审计记录。六、为什么模型 API 网关变得更重要过去模型网关主要用来解决一个 Key 调用多个模型统一管理 API切换模型供应商做请求限流统计模型费用。但 Agent 时代的网关还要解决Agent 身份工具调用用户授权模型路由会话管理任务审计风险拦截多模型协作。可以理解为Plain model gateway: Request - Model - Response Agent model gateway: User - Agent - Model - Tool - External platform ↓ Permission, rate limit, audit一次 Agent 任务可能会调用多个模型Fast model: intent detection Reasoning model: task planning Code model: handle web pages or data Vision model: recognize product images Real-time model: voice interaction with user如果每个模型都由不同代码直接调用就会出现API Key 分散成本无法统一统计线路故障难以切换工具调用无法统一审计不同 Agent 使用不同安全规则。通过统一模型接口可以把这些模型调用集中管理。例如后台推理部分可以这样调用from openai import OpenAI client OpenAI( api_keySERVER_API_KEY, base_urlhttps://genvis.xyz/v1 ) response client.responses.create( modelgpt-6-astra, input[ { role: system, content: ( You are a shopping task planning assistant. Only plan tasks, never directly execute payment, refund, or account changes. ) }, { role: user, content: ( Find commuting-friendly noise-cancelling headphones under 200 dollars, compare products first, do not submit the order. ) } ] ) print(response.output_text)这里的重点不是让模型直接控制 Amazon而是让模型负责规划再由后端权限系统决定下一步。七、一个更安全的购物 Agent 流程推荐使用建议—确认—执行三阶段。第一阶段建议User states a shopping goal ↓ Model retrieves and compares products ↓ Return candidate list这个阶段可以自动完成。第二阶段确认Agent shows product, price, shipping, and return policy ↓ User explicitly confirms用户需要明确看到商品名称实际价格配送费用税费退货条件最终支付金额。第三阶段执行User confirms ↓ Backend issues a one-time authorization ↓ Call the official order API ↓ Write audit record ↓ Return order result不要让模型自行推断用户应该已经同意了。例如if not user_confirmed: return { status: awaiting_confirmation, message: Please confirm product, price, and delivery info before submitting the order. } if total_amount user_spending_limit: return { status: manual_review_required, message: Order amount exceeds the automatic execution limit. } submit_order()八、Agent 不能只依赖模型自觉一个常见错误是在系统提示词里写Do not perform dangerous actions. Must get user consent before payment. Do not visit unrelated websites.这类指令有帮助但不能作为唯一防线。更可靠的做法是把规则写进代码HIGH_RISK_ACTIONS { submit_order, refund_payment, change_account, delete_data } if action in HIGH_RISK_ACTIONS: require_user_confirmation() if action not in ALLOWED_ACTIONS: reject_action()也就是说Prompts guide the model Code constrains the model Platform verifies permissions Human handles high-risk fallback不能把最终权限交给模型自己决定。九、未来平台会如何识别 Agent目前行业还没有统一的 Agent 身份标准但未来可能出现类似的机制Agent-ID User-ID Authorization-Scope Tool-Scope Session-ID Audit-ID一次请求可能包含{ agent_id: shopping-agent-001, user_id: user-123, scope: [ read_products, compare_prices ], requires_confirmation: true, session_id: session-456 }平台就可以知道哪个 Agent 发起了请求代表哪个用户允许读取什么不允许执行什么是否已经得到用户确认后续如何追踪和撤销。相比让 Agent 伪装成浏览器标准化身份和正式 API 授权更有可能成为长期方案。十、Amazon 封禁 Muse 对开发者的启示启示一用户授权不等于平台授权用户愿意使用某个 Agent并不意味着所有网站都必须允许它访问。启示二Agent 必须公开身份一个不表明身份、模拟普通用户行为的 Agent更容易被平台限制。启示三高风险操作需要明确确认浏览商品和提交订单不是同一类操作。启示四浏览器自动化不是长期 API 方案浏览器自动化可以快速做 Demo但生产系统更应该使用官方 APIOAuthMCP合作方接口明确的权限范围。启示五模型能力不是完整产品真正的 Agent 产品还需要权限授权审计账单限流失败恢复人工接管服务降级。结语Amazon 封禁 Meta Muse说明 AI Agent 正在进入一个新的阶段。以前大家关注AI 能不能理解用户现在平台更关心AI 能不能在得到授权的前提下代表用户行动当 Agent 开始访问购物、支付、邮件、日历、企业系统和生产环境时真正的竞争不只是模型参数和回答质量。还包括Identity is clear Authorization is explicit Permission is minimal Tools are controllable Actions are auditable High-risk actions need confirmation因此未来的 AI Agent 不应该只是A model a set of tools更应该是User identity Agent identity Model invocation Tool permission Platform authorization Risk control Audit and human takeoverAmazon 给 Muse 挡住的不只是一个购物入口。它挡住的是一种未经平台同意、缺少标准身份和权限边界的 Agent 访问方式。而对于开发者来说接下来要解决的问题也越来越明确如何让 Agent 足够自动化同时让平台、用户和业务系统都知道它是谁、能做什么以及什么时候必须停下来参考资料AxiosAmazon 阻止 Meta Muse 在 Amazon.com 浏览和下单AxiosMeta Muse 个人 Agent 定位与消费者关注 Amazon 封禁 Meta Muse，AI Agent 开始撞上“平台权限墙“
最近AI Agent 又遇到了一次现实世界的拦截。Amazon 阻止了 Meta 的 Muse AI Agent 在 Amazon.com 上浏览和下单。Amazon 方面称Meta 没有获得授权Muse 也没有明确标识自己是自动化 Agent同时还涉及用户凭据、隐私和平台控制权等问题。Axios 报道这件事的意义不只是Amazon 不让 Meta 的 AI 买东西。它真正暴露的是一个更大的问题当 AI Agent 代表用户访问第三方平台时平台有没有权利拒绝它过去我们讨论 AI Agent更多关注的是模型够不够聪明能不能调用工具能不能自动执行任务能不能使用浏览器能不能替用户完成购物、订票和发邮件。但现在Agent 开始进入真实商业系统新的问题出现了Agent 是否获得了平台授权平台能不能识别这是 Agent用户授权是否等于平台授权Agent 是否应该保存用户密码自动下单失败后由谁负责平台是否必须开放自己的数据和交易流程Amazon 封禁 Muse说明 AI Agent 的下一阶段竞争不只是模型能力的竞争也会是身份、协议、授权和平台规则的竞争。一、Meta Muse 想做什么Meta 推出的 Muse不是传统的聊天机器人。它的目标是让 AI 直接替用户完成一系列线上任务例如搜索商品比较价格选择产品代替用户填写表单处理线上事务进行购物取消订阅管理部分数字生活。Axios 报道称Muse 被 Meta 定位为一个可以代替用户执行日常线上任务的个人 Agent并且已经获得了较高的消费者关注。Axios 对 Meta Muse 的报道传统聊天机器人通常是User asks ↓ Model answers ↓ User acts on their own而 Muse 代表的新模式是User states a goal ↓ Agent understands intent ↓ Agent searches and compares ↓ Agent calls websites or tools ↓ Agent executes the action ↓ User confirms or receives the result例如用户不再需要自己打开电商网站、输入关键词、比较商品和填写订单而是直接说帮我找一款适合通勤的降噪耳机预算不超过 200 美元明天送到。Agent 可能会搜索商品读取价格比较评价检查库存确认配送时间把候选商品交给用户在用户确认后提交订单。从用户角度看这比传统搜索更加方便。但从平台角度看Agent 可能正在绕过原本的入口、广告、推荐和结算流程。二、为什么 Amazon 会封禁 Muse根据 Amazon 对外的说法主要涉及几个问题。1. 没有得到平台授权Amazon 认为第三方 Agent 不能默认获得访问和购物权限。用户愿意让 Meta 帮自己购物不一定代表 Amazon 已经同意 Meta 的 Agent 使用 Amazon 的商品、库存、账号和结算流程。这里存在两种授权User authorization Platform authorization用户授权解决的是用户是否允许 Agent 代替自己操作平台授权解决的是Amazon 是否允许这个 Agent 访问自己的服务这两种授权不是同一件事。2. Agent 没有明确表明身份如果一个普通用户访问 Amazon平台可以按照普通用户请求处理。但如果请求实际来自 Agent平台可能需要知道这是人还是机器是哪个 Agent代表哪个用户是否得到了用户确认是否允许自动下单是否需要额外风控。如果 Agent 把自己伪装成普通用户平台就无法准确判断风险。这也是未来 Agent 身份标准必须解决的问题。3. 用户凭据如何处理Amazon 还担心第三方 Agent 如何处理用户登录信息和支付凭据。最危险的方式是User gives Amazon password to the Agent ↓ Agent stores the password ↓ Agent mimics user login and places order这种方式的问题非常明显Agent 服务可能保存敏感信息密码可能进入日志账号可能被滥用订单操作无法细粒度撤销平台无法知道操作是否得到用户确认。更合理的方式应该是 OAuth 或平台官方授权机制User completes authorization on Amazon page ↓ Amazon returns a scoped access Token ↓ Agent uses Token to call permitted APIs ↓ Token can expire, be revoked, and be scopedAgent 不应该直接拥有用户的原始密码。三、这不是单纯的反爬虫问题很多人看到 Amazon 拦截 Muse 后第一反应是这不就是封 IP 或反爬虫吗实际上Agent 和传统爬虫并不完全一样。传统爬虫主要关注抓取网页内容建立搜索索引批量采集数据读取价格和库存。Agent 则可能进一步执行登录选择商品填写地址提交订单使用支付方式发起退款修改账户设置。因此Agent 的问题不只是能不能读网页而是能不能代表用户完成具有法律、财务和业务后果的操作可以把访问分成四个等级级别行为风险L1阅读公开页面低L2搜索、比较和提取信息中低L3登录并操作用户账户中高L4下单、付款、退款和修改数据高未来平台可能允许 Agent 完成 L1、L2但对 L3、L4 要求额外认证和人工确认。四、AI Agent 的权限墙是什么所谓平台权限墙可以理解为Agent wants to execute a task ↓ Platform checks whether it is eligible to access ↓ Platform checks which data it can access ↓ Platform checks which actions it can perform ↓ Platform decides whether to allow it to continue这和传统 API 权限控制很像但 Agent 场景更加复杂。传统 API 通常是Application A - API B而 Agent 系统可能是User ↓ Agent ↓ Model ↓ Tool ↓ Third-party platform ↓ Payment, order, or production system中间多了一层模型决策。这意味着系统不仅要验证请求来自哪个应用还要验证代表哪个用户模型做了什么判断用户是否确认Agent 是否有权限工具是否被允许这次操作是否超过风险阈值。五、Agent 调用外部平台的正确架构一个更安全的 Agent 系统可以拆成以下几层User layer ↓ Agent application layer ↓ Model invocation layer ↓ Permission and policy layer ↓ Tool invocation layer ↓ Third-party platform1. 用户层负责确认用户是谁用户提出了什么目标哪些操作需要确认用户是否允许 Agent 执行。2. Agent 应用层负责保存任务状态规划流程管理会话展示操作进度在高风险节点暂停。3. 模型调用层负责选择合适模型处理自然语言生成工具调用参数返回结构化结果。4. 权限和策略层负责判断工具是否允许调用判断用户是否有权限设置金额、次数和范围限制判断是否需要人工审批。5. 工具调用层负责使用 OAuth Token调用平台 API处理错误记录请求屏蔽敏感凭据。6. 第三方平台负责验证 Agent 身份验证用户授权执行最终业务操作保留平台侧审计记录。六、为什么模型 API 网关变得更重要过去模型网关主要用来解决一个 Key 调用多个模型统一管理 API切换模型供应商做请求限流统计模型费用。但 Agent 时代的网关还要解决Agent 身份工具调用用户授权模型路由会话管理任务审计风险拦截多模型协作。可以理解为Plain model gateway: Request - Model - Response Agent model gateway: User - Agent - Model - Tool - External platform ↓ Permission, rate limit, audit一次 Agent 任务可能会调用多个模型Fast model: intent detection Reasoning model: task planning Code model: handle web pages or data Vision model: recognize product images Real-time model: voice interaction with user如果每个模型都由不同代码直接调用就会出现API Key 分散成本无法统一统计线路故障难以切换工具调用无法统一审计不同 Agent 使用不同安全规则。通过统一模型接口可以把这些模型调用集中管理。例如后台推理部分可以这样调用from openai import OpenAI client OpenAI( api_keySERVER_API_KEY, base_urlhttps://genvis.xyz/v1 ) response client.responses.create( modelgpt-6-astra, input[ { role: system, content: ( You are a shopping task planning assistant. Only plan tasks, never directly execute payment, refund, or account changes. ) }, { role: user, content: ( Find commuting-friendly noise-cancelling headphones under 200 dollars, compare products first, do not submit the order. ) } ] ) print(response.output_text)这里的重点不是让模型直接控制 Amazon而是让模型负责规划再由后端权限系统决定下一步。七、一个更安全的购物 Agent 流程推荐使用建议—确认—执行三阶段。第一阶段建议User states a shopping goal ↓ Model retrieves and compares products ↓ Return candidate list这个阶段可以自动完成。第二阶段确认Agent shows product, price, shipping, and return policy ↓ User explicitly confirms用户需要明确看到商品名称实际价格配送费用税费退货条件最终支付金额。第三阶段执行User confirms ↓ Backend issues a one-time authorization ↓ Call the official order API ↓ Write audit record ↓ Return order result不要让模型自行推断用户应该已经同意了。例如if not user_confirmed: return { status: awaiting_confirmation, message: Please confirm product, price, and delivery info before submitting the order. } if total_amount user_spending_limit: return { status: manual_review_required, message: Order amount exceeds the automatic execution limit. } submit_order()八、Agent 不能只依赖模型自觉一个常见错误是在系统提示词里写Do not perform dangerous actions. Must get user consent before payment. Do not visit unrelated websites.这类指令有帮助但不能作为唯一防线。更可靠的做法是把规则写进代码HIGH_RISK_ACTIONS { submit_order, refund_payment, change_account, delete_data } if action in HIGH_RISK_ACTIONS: require_user_confirmation() if action not in ALLOWED_ACTIONS: reject_action()也就是说Prompts guide the model Code constrains the model Platform verifies permissions Human handles high-risk fallback不能把最终权限交给模型自己决定。九、未来平台会如何识别 Agent目前行业还没有统一的 Agent 身份标准但未来可能出现类似的机制Agent-ID User-ID Authorization-Scope Tool-Scope Session-ID Audit-ID一次请求可能包含{ agent_id: shopping-agent-001, user_id: user-123, scope: [ read_products, compare_prices ], requires_confirmation: true, session_id: session-456 }平台就可以知道哪个 Agent 发起了请求代表哪个用户允许读取什么不允许执行什么是否已经得到用户确认后续如何追踪和撤销。相比让 Agent 伪装成浏览器标准化身份和正式 API 授权更有可能成为长期方案。十、Amazon 封禁 Muse 对开发者的启示启示一用户授权不等于平台授权用户愿意使用某个 Agent并不意味着所有网站都必须允许它访问。启示二Agent 必须公开身份一个不表明身份、模拟普通用户行为的 Agent更容易被平台限制。启示三高风险操作需要明确确认浏览商品和提交订单不是同一类操作。启示四浏览器自动化不是长期 API 方案浏览器自动化可以快速做 Demo但生产系统更应该使用官方 APIOAuthMCP合作方接口明确的权限范围。启示五模型能力不是完整产品真正的 Agent 产品还需要权限授权审计账单限流失败恢复人工接管服务降级。结语Amazon 封禁 Meta Muse说明 AI Agent 正在进入一个新的阶段。以前大家关注AI 能不能理解用户现在平台更关心AI 能不能在得到授权的前提下代表用户行动当 Agent 开始访问购物、支付、邮件、日历、企业系统和生产环境时真正的竞争不只是模型参数和回答质量。还包括Identity is clear Authorization is explicit Permission is minimal Tools are controllable Actions are auditable High-risk actions need confirmation因此未来的 AI Agent 不应该只是A model a set of tools更应该是User identity Agent identity Model invocation Tool permission Platform authorization Risk control Audit and human takeoverAmazon 给 Muse 挡住的不只是一个购物入口。它挡住的是一种未经平台同意、缺少标准身份和权限边界的 Agent 访问方式。而对于开发者来说接下来要解决的问题也越来越明确如何让 Agent 足够自动化同时让平台、用户和业务系统都知道它是谁、能做什么以及什么时候必须停下来参考资料AxiosAmazon 阻止 Meta Muse 在 Amazon.com 浏览和下单AxiosMeta Muse 个人 Agent 定位与消费者关注