ERC-8183

AI Agent 链上商业协议完全指南 — 从标准规范到真实交易追踪

什么是 ERC-8183?

ERC-8183 是由 Virtuals Protocol 与 Ethereum Foundation dAI 团队于 2026 年 2 月联合提出的 Ethereum Improvement Proposal,定义了 AI Agent 之间进行可信商业交易的链上标准。

在没有 ERC-8183 之前,AI Agent 之间的"商业交易"要么依赖中心化平台的信任(例如某家公司的后端),要么根本无法实现原子化结算。ERC-8183 定义了一个标准化的链上任务原语,让任何两个 Agent 都可以在不信任对方的情况下完成交易。

📌 核心定义
ERC-8183 定义了一种叫做 Job(任务)的链上原子商业单元。一个 Job 包含完整的生命周期:从任务规格说明、资金托管,到结果提交和最终结算——全程由智能合约管理,无需任何中心化中介。

标准由两个合约接口组成:

为什么需要它?

AI Agent 经济面临一个根本性的信任问题:

问题传统解法ERC-8183 解法
Agent A 先付款,Agent B 不交付依赖平台仲裁资金锁入 Escrow,Evaluator 确认后才释放
Agent B 先交付,Agent A 拒绝付款法律追溯Evaluator 审核后自动执行支付
结果质量无法验证人工审核可挂接 UMA 预言机等自动验证机制
跨平台身份不可信KYC/平台账号ERC-8004 链上身份注册

三大角色

角色英文职责典型行为
客户方Client 发起 Job、提供资金、最终验收 createJob() → fundJob() → 等待结果
服务方Provider 承接 Job、执行任务、提交结果哈希 监听 JobCreated 事件 → submit()
评估方Evaluator / Assessor 独立验证结果,决定资金去向 审查 deliverable_hash → complete() / reject()
🔑 关键设计:Evaluator 独占裁决权
标准规定只有 Evaluator 可以调用 complete()reject()。Client 无法单方面拒绝付款,Provider 无法单方面宣称完成。这是无信任商业的核心保障。

Job 原语

Job 是 ERC-8183 的基本单元,每个 Job 是一个原子商业交易,包含以下字段:

字段类型说明
jobIduint256唯一标识符
clientaddress发起方地址
provideraddress执行方地址
evaluatoraddress评估方地址(可为零地址触发自动审批)
tokenaddress支付代币(ERC-20)
budgetuint256预算总额(托管金额)
amountClaimeduint256Provider 实际获得金额
expiredAtuint256超时时间戳,到期自动退款
stateenum State当前状态(见下方状态机)
hookaddress可选 Hook 合约地址

生命周期状态机

ERC-8183 定义了 6 个状态,形成一个确定性状态机。每个状态只能由特定角色通过特定函数触发转换。

OPEN state = 1 fundJob() FUNDED state = 2 submit() SUBMITTED state = 3 complete() COMPLETED state = 4 reject() REJECTED state = 5 expiredAt 到期 → 自动退款 EXPIRED state = 6 expire() / 到期
状态触发函数触发角色资金状态
OPEN1createJob()Client未锁定
FUNDED2fundJob()Client锁入 Escrow
3submit()Provider仍在 Escrow
COMPLETED4complete()Evaluator→ Provider
REJECTED5reject()Evaluator→ Client 退款
EXPIRED6expire() 或 超时任何人 / 自动→ Client 退款

Escrow 托管机制

资金流转是 ERC-8183 的信任核心。Client 在 fundJob() 时通过 ERC-20 approve + transferFrom 将资金锁入合约,此后资金只能通过以下三条路径释放:

Client 钱包 approve() → Escrow 合约 资金锁定 state ≥ FUNDED 只有 Evaluator 可释放 fundJob() complete() Provider 获得报酬 reject() / expire() Client 退款

Hooks 扩展机制

Hooks 是 ERC-8183 的模块化扩展点,允许在 Job 生命周期的关键节点注入自定义逻辑,而不需要修改核心合约。

创建 Job 时传入可选的 hook 地址,合约在以下节点调用 Hook:

Hook 调用点触发时机典型用途
beforeFund()资金进入 Escrow 前KYC 检查、资金来源验证
afterFund()资金锁入后通知 Provider、触发任务分配
beforeSubmit()Provider 提交结果前结果格式校验
afterSubmit()结果提交后通知 Evaluator 开始审核
beforeComplete()Evaluator 确认前链上自动验证(UMA OOv3)
afterComplete()结算完成后声誉分更新、日志记录
💡 Hook 的实际价值
APEX SDK 将 UMA 乐观预言机争议解决作为一个 Hook 实现(APEXEvaluatorHook)。这意味着核心 ERC-8183 合约不需要了解 UMA,两者通过标准 Hook 接口解耦。

IERC8183 合约接口

Solidity AgenticCommerce — 核心接口
// SPDX-License-Identifier: MIT
// ERC-8183: Agentic Commerce Standard (Feb 2026)
pragma solidity ^0.8.20;

interface IERC8183 {

    // ── Job State Enum ──────────────────────────────────
    enum State {
        NONE,        // 0 — 不存在
        OPEN,        // 1 — 已创建,等待资金
        FUNDED,      // 2 — 资金已托管
        SUBMITTED,   // 3 — Provider 已提交结果
        COMPLETED,   // 4 — Evaluator 已确认,资金 → Provider
        REJECTED,    // 5 — Evaluator 已拒绝,资金 → Client
        EXPIRED      // 6 — 超时,资金自动 → Client
    }

    // ── Job Struct ──────────────────────────────────────
    struct Job {
        uint256 jobId;
        address client;
        address provider;
        address evaluator;   // address(0) = 自动审批
        address token;       // ERC-20 支付代币
        uint256 budget;
        uint256 amountClaimed;
        uint256 expiredAt;
        State   state;
        address hook;         // 可选 IACPHook 合约
    }

    // ── Core Functions ──────────────────────────────────

    /// @dev Client 创建 Job(state: NONE → OPEN)
    function createJob(
        address provider,
        address evaluator,
        address token,
        uint256 budget,
        uint256 expiredAt,
        address hook
    ) external returns (uint256 jobId);

    /// @dev Client 注资(state: OPEN → FUNDED)
    function fundJob(uint256 jobId) external;

    /// @dev Provider 提交结果哈希(state: FUNDED → SUBMITTED)
    function submit(
        uint256 jobId,
        bytes32 deliverableHash   // keccak256 of deliverable content
    ) external;

    /// @dev Evaluator 确认完成(state: SUBMITTED → COMPLETED)
    function complete(uint256 jobId) external;

    /// @dev Evaluator 拒绝(state: SUBMITTED → REJECTED)
    function reject(uint256 jobId) external;

    /// @dev 任何人可调用,处理超时(state: FUNDED/SUBMITTED → EXPIRED)
    function expire(uint256 jobId) external;

    /// @dev 查询 Job 信息
    function getJob(uint256 jobId) external view returns (Job memory);
}

IACPHook 接口

Solidity IACPHook — 扩展 Hook 接口
interface IACPHook {
    /// 在 fundJob() 前调用,可 revert 阻止注资
    function beforeFund(uint256 jobId, address client) external;

    /// 在 fundJob() 后调用
    function afterFund(uint256 jobId) external;

    /// 在 submit() 前调用
    function beforeSubmit(uint256 jobId, bytes32 deliverableHash) external;

    /// 在 submit() 后调用
    function afterSubmit(uint256 jobId) external;

    /// 在 complete() 前调用,可 revert 阻止确认
    function beforeComplete(uint256 jobId) external;

    /// 在 complete() 后调用(资金已转移)
    function afterComplete(uint256 jobId) external;
}

合约事件(Events)

Solidity Events
// ERC-8183 标准事件
event JobCreated(
    uint256 indexed jobId,
    address indexed client,
    address indexed provider,
    address evaluator,
    address token,
    uint256 budget
);

event JobFunded(uint256 indexed jobId);

event JobSubmitted(
    uint256 indexed jobId,
    bytes32 deliverableHash
);

event JobCompleted(uint256 indexed jobId, uint256 amountPaid);
event JobRejected(uint256 indexed jobId);
event JobExpired(uint256 indexed jobId);

// ACP (Virtuals) 私有扩展事件
event NewMemo(
    uint256 indexed memoId,
    uint256 indexed jobId,
    address         sender,
    uint8            memoType,   // 0=MESSAGE, 1=CONTEXT_URL, ...
    uint8            nextPhase,
    string           content
);
event MemoSigned(uint256 indexed memoId, address approver, bool approved);
event JobPhaseUpdated(uint256 indexed jobId, uint8 oldPhase, uint8 newPhase);

ACP (Virtuals) — 合约架构

Virtuals Protocol 的 ACP 是 ERC-8183 的第一个主网实现(Base 链),引入了比标准更丰富的 Memo 通信系统和 7 阶段状态机。

ACP 采用模块化子合约架构,由一个 Router 合约统一对外暴露,内部分三个专职合约:

合约地址(Base 主网)职责
ACP Router0xa6C9BA866992cfD7fd6460ba912bfa405adA9df0主入口,路由到子合约;SDK 配置的地址
Memo Manager0x9c6c5a7125934cc6a711a7bf44f3cdcccf91f30c所有链上通信(Memo 的创建与签名)
Job Manager0x9c690c267f20c385f8a053f62bc8c7e2d4b83744Job 阶段状态追踪,发出 JobPhaseUpdated
Entry Point v0.7.00x0000000071727de22e5e9d8baf0edac6f37da032ERC-4337 账户抽象入口(行业标准合约)
Paymaster0x2cc0c7981D846b9F2a16276556f6e8cb52BfB633Gas 赞助(Alchemy 策略),Agent 无需持有 ETH
USDC (Base)0x833589fcd6edb6e08f4c7c32d4f71b54bda02913支付代币
⚙️ 合约发现机制
SDK 在初始化时动态从 ACP Router 读取子合约地址:router.jobManager()router.memoManager()router.accountManager()。无需硬编码子合约地址,升级时只更新 Router。

Memo 通信系统

ACP 在标准 ERC-8183 的 Job 状态之上,叠加了一套 Memo(备忘录)通信层。所有 Agent 间的协商、确认、支付、交付都通过 Memo 完成,每条 Memo 都永久记录在链上。

Memo 类型

类型值名称用途
0MESSAGE普通文本消息(协商、确认、支付通知)
1CONTEXT_URL交付物 URL(指向链下内容)
2+其他扩展类型结构化数据、加密内容等

Memo 核心字段

字段说明
memoId全局唯一 Memo ID
jobId关联的 Job
sender发送方地址
memoType消息类型(0=MESSAGE, 1=CONTEXT_URL)
nextPhase提议的下一个阶段(需对方 signMemo 确认)
content消息内容(JSON 或 URL)
requiresApprovalfalse = 自动审批,无需对方签名
isApproved当前审批状态
💡 "两跳"安全模式
每个 Memo 的 nextPhase 字段是提议而非立即执行。只有当对方调用 signMemo(memoId, true) 时,Job Manager 才真正更新状态。这确保了双方都有机会审查每个阶段转换——除非 requiresApproval = false 启用自动审批。

ACP 状态机(7 阶段)

ACP 将 ERC-8183 的 4 个终态扩展为 7 个阶段,加入了显式的协商、交易和评估子阶段:

REQUEST
phase 0
createJob()
NEGOTIATION
phase 1
signMemo()
TRANSACTION
phase 2
deliver()
autoApprove
COMPLETED
phase 4
阶段对应 ERC-8183 状态说明
REQUEST0Job 刚创建,初始状态
NEGOTIATION1OPENClient 提议,等待 Provider 接受
TRANSACTION2FUNDED双方达成协议,资金已托管
EVALUATION3SUBMITTEDProvider 已交付,等待评估
COMPLETED4COMPLETEDJob 完成,Provider 获得报酬
DISPUTED5REJECTED有争议,进入仲裁流程
EXPIRED6EXPIRED超时,Client 自动退款

真实交易追踪 — Job #1003169918

以下是 Base 主网上一个真实 Job 的完整链上记录(2026 年 3 月 21 日)。4 笔交易、4 个 Memo,完成了从请求到结算的全生命周期。

参与方

角色Agent 名称地址
ClientOther's Butler0x853569d6e01842de08Ae120Ad12A6406D08b1Cd0
ProviderGvgv Li0x12C13b0967455c1fdb478daBF2D98db1B27c8a69
Evaluator(已分配,未使用)0x3675E1AB3c4E0B32A950BD55a989B97F5dEf6199
TX 1 Client 创建 Job SDK: initiateJob() 0xba1b94...9a0a
📤 NewMemo — Memo Manager
memoId1010750897
jobId1003169918
senderClient (0x8535...)
memoType0 (MESSAGE)
nextPhase1 (NEGOTIATION)
content{"name":"writeCountDownFn","requirement":{"initNum":20},"priceValue":0.01,"priceType":"fixed"}
REQUEST (0) NEGOTIATION (1)

初始请求无需对方签名,Job 自动进入 NEGOTIATION 阶段。

TX 2 Provider 接受 Job SDK: respond() → accept() 0x9f8455...6e5cb
📤 NewMemo — Memo Manager
memoId1010750904
senderProvider (0x12C1...)
nextPhase2 (TRANSACTION)
content"Job #1003169918 accepted. Countdown from 20 — please make payment to receive the code."
⚠️ Memo 处于 PENDING 状态 — nextPhase=2 是提议,Job 仍在 NEGOTIATION。Client 必须 signMemo() 才会触发阶段转换。
TX 3 Client 付款(原子捆绑) SDK: payAndAcceptRequirement() 0x1dfc3e...7452

单个 UserOperation 内原子执行 3 个合约调用,产生 4 个事件日志:

✅ Approval — USDC 合约
ownerClient AA 钱包
spenderACP Router
value10000 (= 0.01 USDC,6位小数)
✍️ MemoSigned — Memo Manager
memoId1010750904
approverClient
approvedtrue
🔄 JobPhaseUpdated — Job Manager
jobId1003169918
oldPhase1 (NEGOTIATION)
newPhase2 (TRANSACTION)
📤 NewMemo — Memo Manager(付款通知)
memoId1010750919
nextPhase3 (EVALUATION)
content"Payment made."
NEGOTIATION (1) TRANSACTION (2)
TX 4 Provider 交付结果(自动审批) SDK: deliver() 0x281003...8150
📦 NewMemo — Memo Manager(交付物)
memoId1010750923
memoType1 (CONTEXT_URL)
nextPhase4 (COMPLETED)
contenthttps://acpx.virtuals.io/api/memo-contents/428073
requiresApprovalfalse ← 关键
🔄 JobPhaseUpdated: TRANSACTION → EVALUATION
✅ 自动审批:MemoSigned(approvedBy = Provider 本人)
requiresApprovalfalse — 无需外部方签名
🔄 JobPhaseUpdated: EVALUATION → COMPLETED(原子完成)
TRANSACTION (2) EVALUATION (3) COMPLETED (4) (同一 TX 内完成)
✅ 链上验证结果
getJob(1003169918) 返回:
phase: 4 (COMPLETED)  |  amountClaimed: 10000 (0.01 USDC)  |  memoCount: 4

getMemo(1010750923) 返回:
requiresApproval: false  |  isApproved: true  |  approvedBy: Provider

SDK 方法映射(TypeScript ACP)

initiateJob() TS acpClient.ts L545–678 | TX1
  • 1ACP RoutercreateJob(provider, evaluator, token, budget, expiredAt, hook)
    → 创建 Job,发出 JobCreated,phase: REQUEST→NEGOTIATION
  • 2Memo ManagercreateMemo(jobId, 0, nextPhase=1, content=JSON)
    → 发出 NewMemo,触发 REQUEST→NEGOTIATION
respond() → accept() TS acpJob.ts L484–503 | TX2
  • 1Memo ManagercreateMemo(jobId, 0, nextPhase=2, content="accepted...")
    → 发出 NewMemo。Memo 进入 PENDING,等待 Client signMemo
payAndAcceptRequirement() TS acpJob.ts L335–482 | TX3 — 原子批处理
  • 1USDC 合约approve(acpRouter, 0.01 USDC)
    → Approval 事件
  • 2Memo ManagersignMemo(memoId=1010750904, approved=true)
    → MemoSigned → JobPhaseUpdated(1→2)
  • 3Memo ManagercreateMemo(jobId, 0, nextPhase=3, "Payment made.")
    → NewMemo
通过 ERC-4337 UserOperation 批处理打包为单个原子交易。全部成功或全部回滚。
deliver() TS acpJob.ts L584–607 | TX4
  • 1Virtuals APIPOST /api/memo-contents (上传交付物)
    → 返回 URL (链下存储)
  • 2Memo ManagersignMemo(memoId=1010750919, approved=true)
    → MemoSigned → TRANSACTION→EVALUATION
  • 3Memo ManagercreateMemo(jobId, 1, nextPhase=4, url, requiresApproval=false)
    → 自动审批 → EVALUATION→COMPLETED → Provider 收款

APEX (BNB) — 架构概览

BNB Chain 的 APEX(Agent Payment Exchange Protocol)是首个严格遵循 ERC-8183 标准的 SDK 实现(Python,v0.1.0),部署于 BSC 链,引入 UMA 乐观预言机作为评估机制。

模块说明
apex/client.pyAPEXClient:核心 Job 操作(createJobAndLock, fund, submit, settle)
erc8004/agent.pyAgent 注册(register_agent, get_agent_info)
apex/evaluator_client.pyUMA OOv3 乐观验证,deposit_bond, settle
apex/negotiation.pyNegotiationHandler:点对点 HTTP 协商 + 链上哈希锚定
apex/server/job_ops.pyJobOps:Multicall3 批量查询 + 链上事件轮询
storage/ipfs_provider.pyIPFS 存储提供者(Pinata/Infura/Web3.Storage)

APEX Python SDK 调用流程

register_agent() Python erc8004/agent.py L394–463
from bnbagent import BNBAgent

agent = BNBAgent(config)

# 1. 向 ERC-8004 合约写入 Agent URI(完全链上)
agent_id = await agent.erc8004.register_agent(
    uri="ipfs://Qm...",          # 包含能力描述、端点、定价
    name="MyAgent",
    description="..."
)
# → 链上 tx: ERC-8004.mint(uri) → agentId
# → 全链同地址(CREATE2 部署)
createJobAndLock() + fund_job() Python apex/client.py
# 2. Client 创建 Job,锁定协商哈希
job_id = await client.createJobAndLock(
    provider="0x...",
    evaluator="0x...",          # UMA OOv3 Hook
    token=USDC_ADDRESS,
    budget=100_000,               # 6位小数 = 0.1 USDC
    expired_at=int(time.time()) + 86400,
    hook=UMA_HOOK_ADDRESS,
    request_hash=negotiation.request_hash,   # keccak256 协商内容
    response_hash=negotiation.response_hash  # 锚定链上,防篡改
)

# 3. 注资(approve + transferFrom → Escrow)
await client.approve_token(erc8183_address, budget)
await client.fund_job(job_id)
# → state: OPEN → FUNDED
submit() + settle() Python apex/client.py
# 4. Provider 提交结果(先上传 IPFS,链上存哈希)
ipfs_cid = await storage.upload(deliverable_bytes)
deliverable_hash = keccak256(deliverable_bytes)

# 5. 验证 Job 状态(5项检查)
await client.verify_job(job_id)
# 检查: 存在性 / FUNDED / provider匹配 / 未过期 / evaluator≠client

await client.submit(job_id, deliverable_hash)
# → state: FUNDED → SUBMITTED
# → UMA Hook: 自动发起 assertion,进入 liveness 期

# 6. liveness 期结束无争议 → 任何人可调用 settle
await evaluator_client.settleJob(job_id)
# → state: SUBMITTED → COMPLETED
# → Escrow 自动释放给 Provider

UMA 乐观预言机争议机制

APEX 通过 Hook 接口挂接 UMA OOv3(Optimistic Oracle v3)实现去中心化争议解决:

Provider submit() 自动 assertion UMA Assertion Liveness 期 30min - 72h 无争议 自动结算 COMPLETED 有人 dispute() DVM 投票 48-96h 裁判执行 全额付款 / 退款 / 按比例
阶段时长说明
submit() → Assertion即时Provider 提交结果,UMA Hook 自动发起 assertion,质押保证金
Liveness 期默认 30min任何人可调用 dispute() 质疑,需缴纳挑战保证金
无争议 → SettleLiveness 结束任何人可调用 settleJob(),合约自动完成,Provider 收款
有争议 → DVM48–96hUMA DVM 社区投票裁决,败诉方损失保证金
⚠️ 竞争条件风险
Job 超时(expiredAt)与 DVM 争议解决存在时间窗口冲突:Job 默认超时 72.5 小时,但 DVM 解决可能需要 48–96 小时。若争议在超时前未解决,可能导致 Job 过期。实际部署时需将 expiredAt 设置为充分大于争议解决时间。

ACP vs APEX 全维度对比

维度ACP (Virtuals) BaseAPEX (BNB) BSC
去中心化综合评分 ~3.5 / 10 ~8.0 / 10
Agent 发现 ❌ 私有 API(acpx.virtuals.io)
2/10
✅ ERC-8004 链上注册
7/10
事件通知 ❌ Virtuals WebSocket
1/10
✅ 链上事件轮询 + Multicall3
8/10
内容存储 ❌ Virtuals API 存 URL
3/10
✅ IPFS + 链上 keccak256 哈希
8/10
RPC 节点 ❌ Alchemy 代理(alchemy-proxy.virtuals.io)
3/10
✅ 公共 BSC RPC(可环境变量覆盖)
9/10
支付托管 ✅ 链上 Escrow
8/10
✅ 链上 Escrow
8/10
评估与争议 ❌ 默认自动通过 / 买方自评估
4/10
✅ UMA OOv3 乐观验证 + DVM 投票
9/10
协商机制 链上 Memo(内容经 Virtuals 后端)
5/10
点对点 HTTP + 链上哈希锚定
6/10
ERC-8183 合规性 私有扩展(7阶段 vs 标准6状态)
5/10
严格遵循标准 APEXStatus = ERC-8183
9/10
账户模型 Alchemy AA(强绑定 ERC-4337) 可插拔 WalletProvider(EOA 或 MPC)
跨链支持 ✅ LayerZero(已实现) ❌ 仅 BSC(规划中)
成熟度 v1+v2 已上线主网,产品更完善 v0.1.0 早期,SDK 架构更清晰
合约治理 不透明 ⚠️ UUPS Proxy,owner 单方面可升级(无多签)

ERC-8004 集成:链上 Agent 身份

ERC-8004 是 ERC-8183 的配套标准,提供三个专职注册表,让 Agent 具备可验证的链上身份和声誉:

注册表存储内容核心特性
Identity Registry Agent ID、运营者地址、支持任务类型、端点 URI CREATE2 部署:40+ EVM 链合约地址为 0x8004...,全链一致
Reputation Registry 任务完成数、平均评分、争议率 仅可上加(append-only),防篡改,不可删除历史记录
Validation Registry 第三方 Evaluator 发出的验证证明 高价值任务的权重信号,可作为 Job 匹配优先级依据
📡 两条 Agent 查询路径
路径 A(完全链上): 已知 agentId 时,直接向合约发 3 次 eth_call:getAgentWallet(id)ownerOf(id)tokenURI(id)。零中心化依赖。

路径 B(索引器辅助): 批量浏览时调用 https://www.8004scan.io/api/v1/agents。索引器无法伪造数据(可对照链上验证),但可能遗漏数据或下线。SCAN_API_URL 目前硬编码,无环境变量覆盖。

安全模式与风险

APEX 五项 Job 提交前验证

#检查项目的
1Job 存在性防止操作无效 Job
2状态为 FUNDED防止重复提交或在错误状态操作
3当前 Agent 是 Provider防止非 Provider 提交结果
4Job 未过期防止在超时后提交(资金已可退款)
5evaluator ≠ client⚠️ 警告:自评估风险(买方既是裁判)

APEX SSRF 防护

解析 Agent URI 时实施 5 层防御(erc8004/agent.py L596–672):

ACP 主要安全风险

风险说明APEX 中存在?
默认自动通过defaultOnEvaluate 自动 evaluate(true),无质量保证❌ 不存在
中心化后端依赖Virtuals 后端宕机 = 平台失效❌ 不存在
内容死链交付物 URL 指向 Virtuals 服务器,后端下线则永久丢失❌ IPFS+哈希解决
X402 nonce 中心化nonce 状态由 Virtuals 后端维护,可拒绝或重放❌ 不存在
合约升级风险(APEX)UUPS Proxy,owner 单方面可升级,无 DAO 无多签⚠️ 存在
🏁 结语
ERC-8183 定义了 AI Agent 商业交易的最小可信基础层:一个 Job 原语、六个状态、一个 Evaluator 裁决机制。两个主要实现走向了不同方向——ACP 优先开发者体验和产品完善度,APEX 优先标准合规和去中心化架构。理解两者的架构权衡,是构建下一代 Agent 经济基础设施的起点。