企业官网建设流程全解析

最近，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 可能会：

1. 搜索商品；
2. 读取价格；
3. 比较评价；
4. 检查库存；
5. 确认配送时间；
6. 把候选商品交给用户；
7. 在用户确认后提交订单。

从用户角度看，这比传统搜索更加方便。

但从平台角度看，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 scoped

Agent 不应该直接拥有用户的原始密码。

三、这不是单纯的反爬虫问题

很多人看到 Amazon 拦截 Muse 后，第一反应是：

这不就是封 IP 或反爬虫吗？

实际上，Agent 和传统爬虫并不完全一样。

传统爬虫主要关注：

• 抓取网页内容；
• 建立搜索索引；
• 批量采集数据；
• 读取价格和库存。

Agent 则可能进一步执行：

• 登录；
• 选择商品；
• 填写地址；
• 提交订单；
• 使用支付方式；
• 发起退款；
• 修改账户设置。

因此，Agent 的问题不只是"能不能读网页"，而是：

能不能代表用户完成具有法律、财务和业务后果的操作？

可以把访问分成四个等级：

未来平台可能允许 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 platform

1. 用户层

负责确认：

• 用户是谁；
• 用户提出了什么目标；
• 哪些操作需要确认；
• 用户是否允许 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_key="SERVER_API_KEY", base_url="https://genvis.xyz/v1" ) response = client.responses.create( model="gpt-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，但生产系统更应该使用：

• 官方 API；
• OAuth；
• MCP；
• 合作方接口；
• 明确的权限范围。

启示五：模型能力不是完整产品

真正的 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 takeover

Amazon 给 Muse 挡住的，不只是一个购物入口。

它挡住的是一种未经平台同意、缺少标准身份和权限边界的 Agent 访问方式。

而对于开发者来说，接下来要解决的问题也越来越明确：

如何让 Agent 足够自动化，同时让平台、用户和业务系统都知道它是谁、能做什么，以及什么时候必须停下来？

参考资料

• Axios：Amazon 阻止 Meta Muse 在 Amazon.com 浏览和下单
• Axios：Meta Muse 个人 Agent 定位与消费者关注