沉睡三十年的标准：HTTP 402、生成式 UI 与智能体原生软件的时代

技术领域最重要的想法，往往比支撑它的基础设施早到几十年。HTTP 402 定义于 1996 年，从那以后它一直在等待。

回到最底层：软件究竟是为了什么？
每个应用程序里隐藏的假设
HTTP 402：一个早来三十年的标准
402 为什么从未生效------以及这一切为何即将改变
智能体范式：当「用户」变成一台机器
OpenClaw 与智能体原生服务的兴起
生成式 UI：新的人类交互层
402 的复活：实践中的机器协商支付
新的技术栈：从静态 GUI 到活的服务
这对今天的开发者意味着什么
结语：未来早已写在规范里

回到最底层：软件究竟是为了什么？

在讨论 HTTP 状态码或 AI 智能体之前，我们先回到最底层。

软件，从根本上来说，是什么？

软件是人类从计算中提取价值的机制。仅此而已。

文字处理器让人类获得文本编辑的价值，而无需理解 CPU 寄存器。手机银行 App 让人类完成金融交易，而无需亲自去银行网点。推荐算法让人类从数十亿条数据的模式匹配中获益，而无需懂统计学。

界面------图形界面、API、命令行------只是人类意图与机器能力之间的翻译层。它把「人类想做什么」转换成「计算机能执行什么」。

这听起来显而易见。但它有一个深刻的推论，我们四十年来一直在悄悄忽视：

如果软件的「用户」不再是人类，整个翻译层就需要从头重新思考。

每个应用程序里隐藏的假设

每一款软件都隐藏着一个如此普遍的假设，以至于大多数开发者从未有意识地说出来：

会有一个人类盯着屏幕看。

这个假设深入到骨髓，它塑造了一切：

我们为什么有 UI ------ 人类需要视觉线索来理解哪些操作是可行的
我们为什么有登录流程 ------ 人类需要通过浏览器或 App 证明身份
我们为什么按月订阅 ------ 人类每月付一次费，反复使用服务
我们为什么有新手引导 ------ 人类需要被引导完成第一次使用
我们为什么写文档 ------ 人类需要在使用前阅读说明

这些都不是自然规律，它们是「人类将使用 UI」这一假设的设计后果。

一旦你移除这个假设，软件的整个架构就变得可以重新商量。

HTTP 402：一个早来三十年的标准

来说说 HTTP 状态码。

当你在浏览器里输入网址，你的电脑向服务器发送一个 HTTP 请求。服务器用一个三位数的状态码回应，告诉客户端发生了什么：

200 ------ 成功。这是你要的内容。
301 ------ 已移动。资源换地方了。
404 ------ 未找到。这里什么都没有。
500 ------ 服务器错误。我们这边出问题了。

这些状态码构成了客户端与服务器之间机器可读的通信词汇表。HTTP 的优雅之处在于：任何人都可以构建客户端或服务器，它们都能互相沟通------因为协议定义了对话的规则。

现在看看这个：

复制代码

402 Payment Required

这个状态码定义于 RFC 1945，即 1996 年发布的原始 HTTP/1.0 规范。规范描述它为：

"此代码保留供将来使用。最初的设想是，该代码可能用作某种形式的数字现金或微支付方案的一部分，以允许访问信息。"

三十年后，这个状态码仍然在 RFC 中标注为「保留供将来使用」。

不是因为这个想法很糟糕------这个想法极具远见。而是因为支撑它所需的基础设施------机器可读的、标准化的支付协商协议------在 1996 年根本不存在。于是这个状态码就躺在规范里，偶尔被某些服务以特殊方式使用，但从未被标准化为通用协议。

一个合理的 402 流程应该是什么样的？大概像这样：

http 复制代码

GET /api/premium-data HTTP/1.1
Host: example.com
Authorization: Bearer <token>

http 复制代码

HTTP/1.1 402 Payment Required
Content-Type: application/json
X-Payment-Methods: lightning-network, stripe, usdc
X-Payment-Amount: 0.001
X-Payment-Currency: USD
X-Payment-Endpoint: https://pay.example.com/invoice

{
  "error": "payment_required",
  "message": "此接口需要付费才能访问。",
  "pricing": {
    "model": "per-request",
    "amount": 0.001,
    "currency": "USD"
  }
}

服务器说：「我有你要的东西，收费 0.001 美元，这是付款方式。」客户端付款后重试。

这很优雅。这是正确的。这正是软件处理微支付的应有方式。

问题在于：谁是客户端？

402 为什么从未生效------以及这一切为何即将改变

HTTP 402 失败的原因只有一个：浏览器不是支付智能体。

浏览器的工作是为人类渲染 HTML。当浏览器遇到 402，它不知道该怎么办。它不能：

读取支付元数据并理解被请求的内容
从钱包中自主选择支付方式
自主执行支付交易
携带支付证明重试请求

所以即使服务器返回了一个结构完整的 402 响应，附带完整的支付元数据，浏览器也只是......给人类渲染一个报错页面。

然后人类需要：

阅读报错信息
跳转到一个付款页面（通常是完全不同的 URL）
在表单里填写信用卡信息
等待确认
回来再试一次

这不是机器协商支付------这是人类在服务器和银行之间充当支付中继。就像一台自动售货机，却让你打客服电话来付款。

根本问题在于：传统网络软件中的「客户端」是一个需要人类在循环中的浏览器，而不是自主智能体。 只要这一点不变，402 就永远无法如愿生效。

现在来看看，当客户端是 AI 智能体时会发生什么。

智能体范式：当「用户」变成一台机器

AI 智能体与人类浏览器用户有着根本的不同：

维度	人类 + 浏览器	AI 智能体
速度	每次操作需要秒到分钟	毫秒到秒
并行度	串行（一次一件事）	大规模并行
支付	手动、高摩擦	程序化、零摩擦
理解方式	视觉、情感、情境	语义、结构化、逻辑
记忆	有限的工作记忆	任意大小的上下文窗口
目标	隐式的（必须通过 UI 线索提取）	显式的（以指令形式给出）
对摩擦的容忍度	低（会放弃任务）	实际上为零（自动重试）

在网络上浏览的 AI 智能体不需要 GUI。它不点击按钮------它调用 API。它不读取视觉布局------它解析结构化数据。它不因为放在「已保存」文件夹里就能记住东西------它维护显式状态。

更重要的是：AI 智能体可以持有加密货币钱包、签署交易、自主为 API 调用付费。 它可以读取 402 响应、理解被请求的内容、选择合适的支付方式、执行支付并重试------全程无需任何人类介入。

这正是 HTTP 402 一直在等待的基础设施。

在一个 AI 智能体而非人类成为软件主要消费者的世界里，软件分发的整个经济学都会改变：

不再有月度订阅 ------ 按请求、按 Token、按计算量付费
不再有账号注册流程 ------ 智能体用加密密钥进行身份认证
不再有新手引导 ------ 智能体自主读取 API 文档
不再等待付款确认 ------ 链上结算在毫秒内完成

RFC 1945 在 1996 年为其「将来使用」预留的空间，现在终于要被填满了。

OpenClaw 与智能体原生服务的兴起

OpenClaw 范式代表了新一代软件架构，它建立在一个简单的洞察上：先为智能体设计，再把人类监督作为一层叠加在上面。

传统软件架构是这样的：

markdown 复制代码

人类意图
    ↓
GUI（表单、按钮、菜单）
    ↓
业务逻辑
    ↓
数据层

每一层都是为了在人类认知和机器执行之间进行调解而设计的。GUI 的存在是为了将视觉线索翻译成操作。业务逻辑的存在是为了强制执行人类可能会忘记或违反的规则。就连数据层通常也是围绕人类对信息的思考方式来组织的，而非机器处理信息的方式。

OpenClaw 范式翻转了这个栈：

markdown 复制代码

人类意图
    ↓
AI 智能体（理解自然语言、推理、规划）
    ↓
能力协议（HTTP 402、机器可读的服务描述）
    ↓
服务执行
    ↓
生成式 UI（为人类监督而渲染，而非人类输入）

在这个模型中：

智能体负责将人类意图翻译成机器可执行的操作
能力协议提供机器可读的服务发现、定价和认证
HTTP 402 处理智能体与服务之间的支付协商
生成式 UI 以人类可理解的形式呈现智能体操作的结果

这不是现有网络的小幅进化，而是建立在同一传输层之上的不同计算范式。

生成式 UI：新的人类交互层

这里有一个听起来像哲学问题、实则是架构问题的问题：

如果 AI 智能体是服务的主要消费者，用户界面是为了什么？

传统答案------「让用户与服务交互」------已经不再成立。交互是由智能体完成的。人类不需要点击按钮或填写表单。他们需要的是别的东西：

他们需要看到正在发生什么，并确认自己对此认可。

这就是生成式 UI 的洞察。在智能体原生的世界里，UI 从交互层 转变为监督与透明层。

生成式 UI 不渲染固定的界面、固定的按钮和固定的工作流，而是渲染：

智能体正在做什么 ------ 「我即将调用天气 API，费用 0.0001 美元」
智能体找到了什么 ------ 对结构化数据的人类可读摘要
智能体在计划什么 ------ 任务计划中的后续步骤
智能体完成了什么 ------ 已执行操作和已支付款项的收据
智能体需要你做什么 ------ 针对高风险操作的具体确认请求

生成式 UI 不是由服务渲染的------它是由智能体根据服务返回的结构化数据渲染的。服务只返回 JSON，智能体决定如何向人类呈现它。

来看一个具体例子。假设你告诉智能体：「帮我找下周去东京最便宜的机票。」

传统软件：

智能体打开机票搜索网站
网站渲染一个有 47 个输入字段的复杂 UI
智能体填写字段（或者人类手动填写）
网站渲染一个有 200+ 个选项的结果页面
人类扫描结果，选择一个
网站渲染一个付款表单
人类填写信用卡信息

智能体原生 + 生成式 UI：

智能体调用机票搜索服务 API：GET /flights?from=PEK&to=TYO&date=2026-03-07
服务返回 402 Payment Required，附带 X-Payment-Amount: 0.005 USD
智能体自动付款，重试
服务以 JSON 形式返回结构化的机票数据
智能体根据你的偏好评估所有选项
智能体渲染生成式 UI：「找到 3 个符合条件的航班。最便宜的：3 月 7 日全日空航班，¥6,234。要我帮你订吗？」
人类确认
智能体调用预订 API，用存储的支付方式付款

整个人类交互：读一个摘要，说「好的」。

其余所有事情------搜索、比较、付款、预订------都由智能体使用机器可读协议完成。生成式 UI 只是人类了解智能体在做什么的那扇窗。

402 的复活：实践中的机器协商支付

来具体说说在智能体原生世界中，一个合理的 HTTP 402 实现是什么样的。

第一步：能力发现请求

智能体遇到一个服务，发出能力发现请求：

http 复制代码

GET /.well-known/agent-capabilities HTTP/1.1
Host: data-service.example.com
Accept: application/json
X-Agent-Version: openclaw/1.0

服务以机器可读的能力清单响应：

json 复制代码

{
  "name": "FinancialDataService",
  "version": "2.3.1",
  "endpoints": [
    {
      "path": "/api/stock/:symbol/price",
      "description": "获取指定股票代码的实时股价",
      "pricing": {
        "model": "per-request",
        "amount": 0.0001,
        "currency": "USD"
      },
      "payment_methods": ["lightning", "stripe", "solana"],
      "auth": "none"
    }
  ]
}

第二步：实际请求 + 402

http 复制代码

GET /api/stock/AAPL/price HTTP/1.1
Host: data-service.example.com

http 复制代码

HTTP/1.1 402 Payment Required
Content-Type: application/json
X-Payment-Amount: 0.0001
X-Payment-Currency: USD
X-Payment-Methods: lightning,stripe
X-Payment-Invoice: lnbc100n1p3...
X-Payment-Expiry: 60

{
  "error": "payment_required",
  "invoice": "lnbc100n1p3...",
  "expires_in_seconds": 60
}

第三步：智能体付款并重试

持有闪电网络钱包的智能体自动支付发票：

http 复制代码

GET /api/stock/AAPL/price HTTP/1.1
Host: data-service.example.com
X-Payment-Preimage: abc123...

http 复制代码

HTTP/1.1 200 OK
Content-Type: application/json
X-Payment-Receipt: receipt_xyz

{
  "symbol": "AAPL",
  "price": 178.42,
  "timestamp": "2026-03-01T14:23:01Z",
  "currency": "USD"
}

整个支付协商耗时不到 100 毫秒。无需人类介入，无需注册账号，无需月度计费。只是以原子支付换取数据。

这带来了什么

这个简单的模式开启了全新的服务经济学：

对服务提供商来说：

不再需要计费基础设施------只需返回 402 并指定发票
不再需要账户管理------任何有钱包的智能体都可以成为客户
不再有免费套餐滥用------每次请求都有收费
不再有退款纠纷------闪电支付是最终的、不可逆的

对智能体（以及其背后的人类用户）来说：

不再有订阅疲劳------只为实际使用付费
不再有注册摩擦------认证是加密的
不再有供应商锁定------智能体可以根据价格和质量动态切换服务
不再有支付表单------一切都是自动的

新的技术栈：从静态 GUI 到活的服务

让我们梳理从传统软件到智能体原生软件的完整转变。

传统软件技术栈

diff 复制代码

+------------------------------------------+
|              人类用户                    |
|         （注意力有限）                   |
+------------------+-----------------------+
                   |
                   v
+------------------------------------------+
|             静态 GUI                     |
|      （为引导人类交互而设计）             |
+------------------+-----------------------+
                   |
                   v
+------------------------------------------+
|             业务逻辑                     |
|        （强制规则，验证输入）             |
+------------------+-----------------------+
                   |
                   v
+------------------------------------------+
|              数据层                      |
|      （按人类思维模型组织）               |
+------------------------------------------+

问题所在：

每一层都给人类增加摩擦
业务逻辑与 UI 深度耦合
变现需要复杂的计费基础设施
新用户需要大量引导
使用数据无法捕捉真实意图

智能体原生软件技术栈

lua 复制代码

+------------------------------------------+
|              人类意图                    |
|         （用自然语言表达）                |
+------------------+-----------------------+
                   |
                   v
+------------------------------------------+
|             AI 智能体                    |
|      （推理、规划、执行、付费）            |
+------------------+-----------------------+
                   |
          +--------+--------+
          |        |        |
          v        v        v
    +--------+ +--------+ +--------+
    | 服务 A | | 服务 B | | 服务 C |
    |  402   | |  402   | |  免费  |
    +--------+ +--------+ +--------+
          |        |        |
          +--------+--------+
                   |
                   v
+------------------------------------------+
|            生成式 UI                     |
|         （为人类监督而渲染）              |
+------------------+-----------------------+
                   |
                   v
+------------------------------------------+
|              人类监督                    |
|         （确认、调整、批准）              |
+------------------------------------------+

优势所在：

人类只在意图和监督层交互
服务解耦，可独立替换
变现是原子化的、无摩擦的
不需要引导------智能体自我配置
使用量完美反映用户意图

这种转变微妙但深刻。在传统技术栈中，人类操作软件。在智能体原生技术栈中，人类指挥软件并监督它。

软件从一个工具变成了一个协作者。

这对今天的开发者意味着什么

你不需要把现有软件全部推倒重来。但你确实需要开始以不同的方式思考你的服务。

原则一：为智能体设计 API，而不只是为人类

你今天的 API 文档是为人类写的。在智能体原生世界里，你需要机器可读的 API 描述，让智能体无需人类介入就能使用。

json 复制代码

{
  "endpoints": [
    {
      "path": "/api/translate",
      "description": "将文本从一种语言翻译成另一种语言",
      "parameters": {
        "text": "string，要翻译的文本",
        "from": "ISO 639-1 语言代码",
        "to": "ISO 639-1 语言代码"
      },
      "pricing": {
        "model": "per-character",
        "amount": 0.000001,
        "currency": "USD"
      }
    }
  ]
}

原则二：实现有意义的 402 响应

不要在真实原因是「你还没付钱」时返回 403 Forbidden。返回带有结构化支付元数据的 402 Payment Required：

rust 复制代码

// Rust + axum 示例
async fn handle_request(
    State(state): State<AppState>,
    headers: HeaderMap,
) -> Result<Json<ResponseData>, (StatusCode, Json<serde_json::Value>)> {
    if !has_valid_payment(&headers, &state).await {
        return Err((
            StatusCode::PAYMENT_REQUIRED,
            Json(serde_json::json!({
                "error": "payment_required",
                "invoice": state.generate_invoice(0.0001).await,
                "expires_in_seconds": 60
            }))
        ));
    }
    // ... 处理请求
}

原则三：添加生成式 UI 钩子

即使你今天的主要用户是使用浏览器的人类，也要添加智能体可以用来渲染生成式 UI 的结构化数据响应。这意味着：

返回带有清晰字段描述的语义 JSON
在响应中包含操作建议（「下一步」或「相关操作」）
提供智能体可以解读的机器可读状态

原则四：以微支付思考，而非订阅制

不是每个服务都需要完全切换到微支付，但可以考虑：

哪些功能现在是订阅门控的，可以改为按使用付费？
如果按 API 调用计费（每次 0.0001 美元），你的定价会是什么样的？
如果注册摩擦降为零，你的使用模式会怎样变化？

原则五：把 CLI 当作一等公民

在所有软件形态里，CLI 是最接近智能体原生的。

图形界面是为人眼设计的------颜色、布局、动画都是写给人类视觉系统的信号。而 CLI 天然就是结构化的：输入是纯文本指令，输出是可被程序解析的文本流，错误通过退出码和 stderr 标准化传递。这正是智能体最容易消费的格式。

一个设计良好的 CLI 让智能体可以：

通过 --json 或 --output json 拿到机器可读的结果，无需解析 HTML
通过标准 exit code（0 成功、非 0 失败）判断执行状态
通过 --help 和 man page 自主理解可用命令，无需阅读文档网站
组合进 shell 脚本或 agent tool 调用链，形成自动化工作流

反观图形界面：智能体要么需要视觉识别屏幕（慢且脆），要么需要模拟浏览器点击（fragile，依赖 DOM 结构不变），两者都是用"人类翻译层"绕了一大圈。

实践建议：

bash 复制代码

# 不友好：只有 GUI，或 CLI 输出人类可读的格式化文本
$ mytool status
  ✅ Service is running on port 8080
  📊 Memory: 256 MB / 1 GB

# 智能体友好：支持 --json 输出
$ mytool status --json
{"running": true, "port": 8080, "memory_mb": 256, "memory_limit_mb": 1024}

# 智能体友好：exit code 语义明确
$ mytool healthcheck --json && echo "deploy"
{"healthy": true, "latency_ms": 12}
deploy

如果你的产品今天只有 Web UI，考虑先补一个能被脚本调用的 CLI。不是为了「开发者体验」，而是因为 CLI 是智能体能稳定调用的最小接口。

原则六：暴露能力，而不只是数据

最具智能体原生性的服务不只是返回数据------它们暴露能力：智能体可以代表用户完成的事情。

传统天气 API 返回数据：{"temperature": 25, "condition": "晴"}

智能体原生的天气能力返回数据和操作：

json 复制代码

{
  "temperature": 25,
  "condition": "晴",
  "capabilities": [
    {
      "action": "set-alert",
      "description": "当温度低于阈值时提醒我",
      "parameters": {
        "threshold": "摄氏度数字",
        "method": "webhook|email|sms"
      }
    },
    {
      "action": "get-forecast",
      "description": "获取 7 天天气预报",
      "pricing": {"amount": 0.0002, "currency": "USD"}
    }
  ]
}

一个完整的场景：用 OpenClaw 购买或定制商品

上面的原则读起来可能有些抽象。让我们用一个具体的电商场景把所有东西串起来。

假设你打开 SafeClaw，对智能体说：「帮我找一双合适的跑步鞋，要支撑性好、适合平足、预算 800 元以内。」

传统电商是怎么做的

你被跳转到某购物平台。平台给你渲染了一个搜索框，你要自己输入关键词，然后手动勾选品类、价格区间、鞋型、品牌......平台给你展示 300 个商品，你一页一页地翻，自己对比评分和参数，最后点进去，填收货地址，进支付宝，完成支付。

整个过程：你的注意力全被消耗在「操作界面」上，而不是「做决策」上。

智能体原生电商是怎么做的

复制代码

用户 → 智能体 → 服务能力协议 → 电商服务

第一步：服务发现

智能体调用电商平台的能力接口：

http 复制代码

GET /.well-known/agent-capabilities HTTP/1.1
Host: shop.example.com
X-Agent-Version: openclaw/1.0

平台返回结构化的能力清单：

json 复制代码

{
  "capabilities": [
    {
      "action": "search-products",
      "description": "按自然语言查询商品",
      "pricing": { "model": "per-request", "amount": 0.001, "currency": "CNY" }
    },
    {
      "action": "get-product-detail",
      "description": "获取商品完整规格、库存和评价摘要",
      "pricing": { "model": "per-request", "amount": 0.0005, "currency": "CNY" }
    },
    {
      "action": "customize-product",
      "description": "为支持定制的商品配置颜色、材质、尺寸",
      "pricing": { "model": "per-request", "amount": 0.002, "currency": "CNY" }
    },
    {
      "action": "place-order",
      "description": "提交订单并完成支付",
      "pricing": { "model": "per-order", "amount": 1.0, "currency": "CNY" }
    }
  ]
}

第二步：语义搜索（带 402 支付）

http 复制代码

POST /api/search-products HTTP/1.1
Host: shop.example.com

{"query": "跑步鞋 平足支撑 800元以内", "limit": 10}

服务返回 402 Payment Required，附带 0.001 元的支付发票。智能体自动付款，重试，拿到结构化商品列表。

第三步：自主评估

智能体并发调用多个商品的详情接口，对比关键参数：

json 复制代码

{
  "products": [
    {
      "id": "A001",
      "name": "ASICS Gel-Kayano 30",
      "price": 749,
      "arch_support": "high",
      "pronation": "overpronation",
      "avg_rating": 4.8,
      "review_summary": "平足跑者普遍反馈稳定性优秀，适合长距离训练"
    },
    {
      "id": "B002",
      "name": "Brooks Adrenaline GTS 23",
      "price": 799,
      "arch_support": "high",
      "pronation": "overpronation",
      "avg_rating": 4.7,
      "review_summary": "导向轨道技术有效纠正内旋，缓震出色"
    }
  ]
}

智能体根据「平足支撑」「预算 800 元」「评分」三个维度自动过滤和排序，无需你翻页。

第四步：生成式 UI 呈现结果

智能体渲染生成式 UI，向你展示它的判断：

找到 2 款高度符合条件的跑步鞋：

推荐：ASICS Gel-Kayano 30 --- ¥749，专为过度内旋（平足常见问题）设计，评分 4.8，3000+ 条评价，平足跑者好评率 94%。比预算便宜 51 元。

备选：Brooks Adrenaline GTS 23 --- ¥799，同样针对内旋，评分略低但缓震反馈更好。

是否继续购买推荐款？如需定制颜色或尺码，我也可以帮你配置。

你只需说「好，买推荐款，42 码，黑色」。

第五步：定制与下单（可选的智能体主导流程）

http 复制代码

POST /api/customize-product HTTP/1.1

{"product_id": "A001", "size": 42, "color": "black"}

服务返回定制确认和最终价格。智能体再次渲染确认界面，你点「确认」。

http 复制代码

POST /api/place-order HTTP/1.1

{
  "product_id": "A001",
  "options": {"size": 42, "color": "black"},
  "shipping_address": "<from agent profile>",
  "payment_method": "lightning"
}

订单创建，支付通过 HTTP 402 + 链上结算在毫秒内完成。你收到订单号。

整个人类交互：表达需求（一句话）→ 阅读推荐摘要（10 秒）→ 确认（一句话）。你不需要操作任何表单，不需要填收货地址（智能体从你的配置里读取），不需要输入支付密码。

定制商品场景：对话式协商

对于可定制的商品，整个流程变成一个对话式协商：

用户：「帮我定制一件工作衬衫，需要修身版型，我的肩宽 44cm，胸围 96cm，袖长 62cm。」

智能体调用定制服务的能力接口，服务返回可配置的参数列表（面料、领型、袖扣、刺绣等）以及价格组成。智能体不会把 47 个选项全部抛给你，而是：

根据你的历史偏好自动预填常见选项（假设你偏好纯棉、无刺绣）
只把有歧义的决策呈现给你：「这款衬衫有三种领型：标准领、立领、暗扣领。你偏好哪种？」
每次你确认一个选项，智能体就在内部更新配置，直到所有参数齐全再下单

这就是生成式 UI 在电商场景里最核心的价值：它不给你一个大表单，而是把复杂的决策流程变成一个自然的对话，每一步只问你真正需要你决策的问题。

这对电商开发者意味着什么

如果你在构建电商平台，上面的场景意味着几个具体的架构变化：

暴露语义搜索接口，而不只是基于关键词的全文检索。智能体需要能用「平足」「支撑性好」这样的自然语言描述来查询，服务端需要做语义理解。
把商品属性结构化。「适合平足」不能只出现在商品详情的文字描述里，需要成为可过滤的结构化字段。
实现能力清单接口 （/.well-known/agent-capabilities），让智能体知道你的平台支持哪些操作、每个操作的价格和参数格式。
支持 HTTP 402 流程，让智能体可以在授权范围内自主完成搜索、浏览、比价，而不需要用户为每一步操作手动付费确认。
提供定制参数的结构化描述，让智能体能代替用户填写配置，而不是把一个大表单扔给人类。

传统电商的竞争维度是：谁的搜索更好、谁的首页推荐更精准、谁的支付流程更顺畅。

在智能体原生的电商世界里，竞争维度变成了：谁的能力接口设计得更好、谁的商品语义描述更丰富、谁的 402 支付流程更低延迟。因为智能体会根据这些维度动态选择服务商------就像程序员选择 SDK 一样，谁的 API 文档更清晰、谁的接口更稳定，谁就赢得更多智能体的调用。

结语：未来早已写在规范里

HTTP 402 已经等待了三十年。不是因为这个想法是错误的------而是因为生态系统还没有准备好。

它需要：

能够自主推理和执行任务的 AI 模型（约 2023 年到来）✅
毫秒级结算的轻量级微支付基础设施（闪电网络，约 2018 年，目前日趋成熟）✅
机器可读的能力描述协议（目前正在涌现）✅
能持有钱包并自主执行支付的智能体运行时（目前正在涌现）✅

四个要素现在都已就位或正在被积极构建。

其影响难以言过其实。当软件的主要消费者从「拿着浏览器的人类」转变为「持有钱包的 AI 智能体」，一切都会改变：

商业模式从订阅制转向按请求的原子支付
认证从密码和 OAuth 转向加密密钥
用户界面从固定 GUI 转向生成式监督面板
分发从应用商店和 SEO 转向智能体能力注册表
定价从月度估算转向精确的按用量计量

在接下来十年里成功的软件开发者，不会是那些构建最好的静态 GUI 的人。而是那些构建最好的智能体原生能力的人------任何 AI 智能体都可以在毫秒内发现、付费并使用的服务，整个过程对人类来说零摩擦。

规范在 1996 年就告诉我们这一切即将到来。我们只是没有基础设施去倾听。

A3S 正在为智能体原生网络构建基础设施：一个支持 TEE 的隐私优先 AI 运行时，具备智能体间通信能力和原生 HTTP 402 支付集成。了解更多，请访问 a3s-lab.github.io/a3s。

沉睡三十年的标准：HTTP 402、生成式 UI 与智能体原生软件的时代

目录

回到最底层：软件究竟是为了什么？

每个应用程序里隐藏的假设

HTTP 402：一个早来三十年的标准

402 为什么从未生效------以及这一切为何即将改变

智能体范式：当「用户」变成一台机器

OpenClaw 与智能体原生服务的兴起

生成式 UI：新的人类交互层

402 的复活：实践中的机器协商支付

第一步：能力发现请求

第二步：实际请求 + 402

第三步：智能体付款并重试

这带来了什么

新的技术栈：从静态 GUI 到活的服务

传统软件技术栈

智能体原生软件技术栈

这对今天的开发者意味着什么

原则一：为智能体设计 API，而不只是为人类

原则二：实现有意义的 402 响应

原则三：添加生成式 UI 钩子

原则四：以微支付思考，而非订阅制

原则五：把 CLI 当作一等公民

原则六：暴露能力，而不只是数据

一个完整的场景：用 OpenClaw 购买或定制商品

传统电商是怎么做的

智能体原生电商是怎么做的

定制商品场景：对话式协商

这对电商开发者意味着什么

结语：未来早已写在规范里