调研时间：2026 年 7 月 | 基于对 Robinhood、OKX、Binance、Futu 等平台的实际产品分析
一、问题背景：为什么需要云端 Agent
1.1 手机端的硬限制
普通用户的主要终端是手机，不是电脑。但手机作为 Agent 的运行环境存在不可回避的硬限制：
| 限制 | 技术原因 | 对 Agent 的影响 |
|---|---|---|
| 锁屏杀后台 | iOS 约 30 秒，Android 约 10 分钟后回收后台进程 | 长时间运行的策略/监控任务中断 |
| 网络不稳定 | 移动网络切换、地铁/电梯无信号 | Agent 无法调外部 API，监控盲区 |
| 电量有限 | 用户关机、低电量自动关机 | Agent 完全停止 |
| 算力受限 | 手机 CPU/GPU 功耗和散热约束 | 复杂推理慢、耗电、发热 |
| 系统权限受限 | iOS/Android 对后台网络、文件访问有严格限制 | Agent 功能覆盖不全 |
这些限制不是”优化一下就能解决的”——它们是操作系统级别的硬约束，手机厂商出于电池续航和安全考量刻意设计的。
1.2 手机端能做什么，不能做什么
| 任务类型 | 例子 | 手机端能否完成 | 说明 |
|---|---|---|---|
| 即时执行 | “帮我买入 100 美元比特币” | ✅ 可以 | 一次性指令，几秒完成。签名（HMAC/OAuth）等技术问题在手机端均可解决 |
| 条件触发 | “腾讯股价低于 350 就买 100 股”、”机票降价到 500 就买” | ❌ 不可以 | 需要持续监控条件，时间跨度不确定（几秒到几天），手机无法保证 7×24 在线 |
即时执行类任务手机端完全可以完成——一条指令发出去，几秒内得到结果，不需要持续运行。无论验证方式是 OAuth 还是 HMAC 签名，都可以在手机端实现（平台自有 App 内嵌 Agent 直接处理，或通过 OS 内嵌 Agent 调用平台 API）。
真正的问题出在条件触发类任务——这类任务必须在服务端运行，因为”持续监控”这个环节需要 7×24 可靠的运行环境，手机端的断电、断网、锁屏杀后台等硬限制使得它无法胜任。
1.3 桌面端 Agent 也不是答案
当前的桌面端 AI Agent（OpenClaw、Claude Desktop、Cursor 等）解决了算力和后台运行问题，但带来了新的硬伤：
- 电脑必须不断电、不断网地开着——OpenClaw Mobile 的架构是”手机遥控电脑 Gateway”，电脑一旦关机 Agent 就断了
- 普通人不会一直开着电脑——使用门槛高，只有少数开发者/高级用户接受
- 桌面端 Agent 是过渡现象——少数人使用，不是主流用户入口
结论：需要一个”不依赖用户设备持续在线”的执行环境——这就是云端 Agent 的核心价值。
二、两类使用场景的架构需求
2.1 即时执行（Immediate Execution）
定义：一条指令，立即执行完成。
| 场景 | 用户指令 | 期望结果 | 时间跨度 |
|---|---|---|---|
| 加密货币交易 | “买入 100 美元 BTC” | 订单提交成功 | 几秒 |
| 券商下单 | “买 100 股腾讯” | 订单提交成功 | 几秒 |
| 查询持仓 | “我现在有多少资产” | 持仓明细列表 | 几秒 |
| 转账 | “给张三转 500 USDT” | 转账完成 | 几秒到几分钟 |
| 机票查询 | “明天去上海的直飞有哪些” | 航班列表 | 几秒 |
即时执行的特点：
- 一次性——做完就完了，不需要持续运行
- 低延迟敏感——用户在等结果，几秒到几十秒内完成
- 结果即时反馈——用户马上能看到成功/失败
- 手机端基本可用——只要网络通畅、平台提供 Agent 接口
即时执行的架构要求：
用户（手机App/OS Agent）→ 表达意图 → Agent 推理（理解意图+选择工具）→ 调用平台 API → 返回结果 → 用户看到结果
关键问题：Agent 推理在哪做？
| 推理位置 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 手机本地 | 快、隐私好、不依赖网络 | 算力弱、模型能力有限 | 简单意图理解、单步工具选择 |
| 云端大模型 | 推理能力强、可处理复杂意图 | 需要网络、数据过云 | 复杂多步规划、跨上下文推理 |
| 端云协同 | 简单本地做、复杂云端做 | 架构复杂 | 全场景覆盖 |
2.2 条件触发（Condition-Triggered Execution）
定义：设定监控条件，条件满足时触发执行动作。时间跨度不确定。
| 场景 | 触发条件 | 执行动作 | 时间跨度 |
|---|---|---|---|
| 股票价格监控 | 腾讯股价 < 350 HKD | 买入 100 股 | 几秒到几周 |
| 机票降价监控 | 上海机票 < 500 CNY | 自动购买 | 几小时到几天 |
| 加密货币网格交易 | BTC 价格波动 ±3% | 买入/卖出对应数量 | 持续运行 |
| 定投策略 | 每月 1 号 | 买入 500 USDT BTC | 持续数月 |
| 快递到达提醒 | 物流状态 = 已签收 | 推送通知 | 1-3 天 |
| 期权到期提醒 | 到期日前 3 天 | 推送通知 + 建议操作 | 固定时间触发 |
条件触发的特点：
- 时间跨度不确定——可能几秒触发，也可能几周才触发
- 需要持续监控——条件检测器必须 7×24 运行
- 触发后立即执行——条件满足时不能延迟（股价低于 350 时如果延迟几分钟，价格可能已经涨回去了）
- 手机端完全不可靠——关机、锁屏、断网任何一个都会导致监控中断
条件触发的架构要求：
用户（手机）→ 表达意图 + 设定条件 → Agent 翻译成可执行规则 → 上传到服务端
↓
服务端 → 7×24 运行条件检测器 → 条件满足 → 执行动作 → 推送结果通知到手机
条件检测器必须跑在服务端——这是没有妥协空间的硬需求。
三、云端 Agent 的两种服务形式
3.1 平台自有云服务持续运行规则引擎
定义：服务平台（交易所/券商/携程）在自己的服务器上持续运行策略或监控逻辑，为用户提供条件触发类任务的可靠执行环境。
注意：这里的”云服务”指的是服务端持续运行的规则引擎/策略 Bot，不是 AI Agent 在云上自主推理和执行。 目前行业尚无”AI Agent 在平台云服务器上持续运行自主决策”的产品——现有的 App 内嵌 AI 功能（OKX AI 策略、Binance Ai Pro、Futu 牛牛AI）本质上是”AI 做推理 + 客户端做一次性执行”，不属于此类别（详见 3.3）。
代表产品
| 平台 | 产品 | 运行方式 | 说明 |
|---|---|---|---|
| OKX | 策略交易 / Trading Bots | 服务端 7×24 运行规则引擎（网格/DCA/套利等） | 规则 Bot，不是 AI Agent |
| Futu | 量化平台（积木式量化+牛牛量化） | 服务端 7×24 运行用户策略代码 | 规则引擎 + 用户自定义代码，不是 AI Agent |
| 携程 | 低价提醒 | 服务端持续监控票价 + 推送通知（不自动购买） | 监控服务，不是 AI Agent |
| 各券商 | 条件单/止损单 | 服务端监控触发条件 + 自动下单 | 规则引擎，不是 AI Agent |
架构特征
┌──────── 手机端 ─────────┐ ┌──────── 平台服务端 ──────────┐
│ │ │ │
│ 创建策略：设定条件+参数 │ ──→ │ 规则引擎接收策略配置 │
│ │ │ 规则引擎 7×24 运行 │
│ 审批高风险操作 │ ←── │ 条件满足时执行动作 │
│ （推送通知确认） │ │ 异常时暂停+推送通知 │
│ │ │ │
│ 查看策略状态 │ ←── │ 状态/日志持久化 │
│ （仪表盘） │ │ │
└──────────────────────────┘ └───────────────────────────────┘
关键特征：这些都不是 AI Agent
| 特征 | 说明 |
|---|---|
| 执行逻辑是确定性的 | 网格 Bot、DCA Bot、止损单都是 if-then 规则，不是 AI 推理 |
| 运行在服务端 | 规则引擎在平台服务器上 7×24 运行，不依赖用户设备在线 |
| 执行权限天然具备 | 平台本身就有下单/购买 API，不需要用户额外授权 |
| 安全模型是平台内部隔离 | 策略运行在平台内部，不涉及第三方信任边界 |
| 没有 AI 自主决策 | 所有判断逻辑都是用户设定的规则，AI 不参与执行过程 |
优势
| 优势 | 说明 |
|---|---|
| 7×24 可靠运行 | 交易所/券商的服务器本身就是 7×24 运行的，手机关机不影响策略 |
| 执行权限天然具备 | 平台本身就有下单/购买 API，不需要额外授权 |
| 低门槛 | 用户在 App 里设定条件即可，不需要安装 MCP/CLI/配置 API Key |
| 确定性执行 | 规则引擎行为可预测、可审计，没有 AI 推理的不确定性 |
劣势
| 劣势 | 说明 |
|---|---|
| 只限本平台 | OKX Trading Bots 只能在 OKX 交易，不能调 Binance 或携程的 API |
| 灵活性受限 | 预设策略类型（网格/DCA/套利等），不支持用户自定义逻辑（Futu 量化除外） |
| 没有 AI 参与 | 策略执行过程中没有语义层面的验证，无法检测”这个下单量是否匹配用户意图”这类语义问题 |
3.2 用户通用 Agent 云服务
定义：第三方提供的通用 Agent 云平台，用户可以在上面运行自己的 Agent，连接各种外部服务。
代表产品
| 产品 | 架构 | Agent 运行位置 | 接入方式 | 发布/可用时间 |
|---|---|---|---|---|
| ChatGPT App + MCP | Cloud-first | OpenAI 云服务器 | OAuth MCP Connector | 2025 年 11 月 |
| OpenClaw Gateway | Local-first（遥控器模式） | 用户电脑 | MCP + Skills | 2026 年 6 月 |
| 荣耀 YOYO | OS 内嵌 | 手机端+云端协同 | 系统级 MCP + GUI Agent | 2026 年 |
ChatGPT Cloud-first 架构
┌──────── 手机端 ─────────┐ ┌── OpenAI 云 ──┐ ┌── 公网 MCP Server ──┐
│ │ │ │ │ │
│ 用户在 ChatGPT App 对话 │ ──→ │ GPT 推理 │ ──→ │ Robinhood MCP │
│ │ │ 选择 MCP 工具 │ │ OAuth 2.1 验证 │
│ │ ←── │ 返回结果 │ ←── │ 执行交易 │
│ │ │ │ │ │
└──────────────────────────┘ └────────────────┘ └──────────────────────┘
OpenClaw Local-first 架构
┌──────── 手机端 ─────────┐ ┌── 用户电脑 ──┐ ┌── 本地/公网 MCP ──┐
│ │ │ │ │ │
│ OpenClaw Mobile App │ ←→ │ Gateway │ ──→ │ OKX MCP (本地) │
│ （遥控器模式） │ │ Agent 推理 │ │ HMAC 签名 (本地) │
│ │ │ 执行任务 │ ←── │ 返回结果 │
│ │ │ │ │ │
└──────────────────────────┘ └───────────────┘ └────────────────────┘
↑ ↑
审批/查看 必须不断电不断网
3.3 一次性AI推理+客户端执行
定义：平台在 App 内接入 AI 大模型做推理，但执行动作由客户端（手机 App）完成。这是一次性指令执行，不是服务端持续运行的 Agent。
这类产品的本质是”AI 做意图理解 + 客户端做一次性执行”——用户在 App 里对 AI 说话，AI 理解意图后直接在 App 内执行操作，做完就结束。没有服务端 Agent 持续运行，也不涉及云端 Agent 架构。
| 平台 | 产品 | 工作方式 | AI 的角色 |
|---|---|---|---|
| OKX | AI 策略 | 用户描述逻辑 → AI 推理 → App 内执行下单 | AI 做意图理解+策略推荐，客户端执行 |
| Binance | Ai Pro | 用户对话 → AI 推理 → App 内执行操作 | AI 做意图理解+操作推荐，客户端执行 |
| Futu | 牛牛AI 专家模式 | 用户对话 → AI 多步推理 → App 内执行操作 | AI 做意图理解+信息分析，客户端执行 |
| Robinhood | Agentic Trading | 用户在桌面 Agent 对话 → Agent 调 MCP 工具 → 一次性执行 | 外部 AI Agent 做推理，Robinhood MCP 做执行 |
这些产品对即时执行场景有价值（让普通人用自然语言操作），但对条件触发场景不适用（手机不稳定、AI 不持续运行）。条件触发需要的是 3.1 中的”平台自有云服务持续运行规则引擎”或 3.2 中的”通用 Agent 云服务持续运行”，而不是 3.3 的”一次性AI推理+客户端执行”。
三种服务形式的对比
| 维度 | 3.1 平台自有云持续运行规则引擎 | 3.2 通用 Agent 云 | 3.3 一次性AI推理+客户端执行 |
|---|---|---|---|
| 跨平台能力 | ❌ 只限本平台 | ✅ 可连接多个服务 | ❌ 只限本平台 App |
| 执行权限 | ✅ 天然具备 | ❌ 需要用户授权 | ✅ 天然具备（App内） |
| 使用门槛 | ✅ App 内设定条件即可 | ❌ 需要配置 MCP/API Key | ✅ App 内对话即可 |
| 持续运行 | ✅ 7×24 服务端运行 | △ 取决于云服务稳定性 | ❌ 不持续运行 |
| 适用场景 | 条件触发 | 即时执行（跨平台） | 即时执行（本平台内） |
| AI 参与 | ❌ 无（纯规则引擎） | ✅ AI 做推理和工具选择 | ✅ AI 做意图理解 |
3.2.1 Cloud-first vs Personal Cloud：两种 Agent 云架构的深度对比
原始 OpenClaw 的最大硬伤是”电脑必须一直开着”。如果把 OpenClaw Gateway 从用户物理电脑搬到用户个人 VPS（云虚拟服务器），这个硬伤彻底消失——VPS 天然 7×24 在线。这产生了一个新的变体架构：OpenClaw Personal Cloud。
┌──────── 手机端 ─────────┐ ┌── 用户个人 VPS ──┐ ┌── 全类型 MCP ──┐
│ │ │ │ │ │
│ OpenClaw Mobile App │ ←→ │ Gateway │ ──→ │ OAuth MCP ✅ │
│ （遥控器模式） │ │ Agent 推理 │ ──→ │ HMAC MCP ✅ │
│ │ │ 执行任务 │ ──→ │ 本地网关 ✅ │
│ │ │ │ │ │
└──────────────────────────┘ └───────────────────┘ └─────────────────┘
↓
Secret 全在用户 VPS 上
VPS 天然 7×24 在线（无需电脑不断电）
七维度系统对比：
| 维度 | ChatGPT Cloud-first | OpenClaw Personal Cloud | 说明 |
|---|---|---|---|
| HMAC 服务 | ❌ 不可用 | ✅ 可用 | Secret 在用户 VPS 上，安全可控 |
| OAuth 服务 | ✅ 可用 | ✅ 可用 | 两种架构都支持 |
| 本地网关 | ❌ 不可用（云端无法访问 localhost） | ✅ 可用（可在 VPS 上运行 OpenD 等） | Personal Cloud 覆盖范围 = 1 → N |
| 条件触发 | ❌ 一问一答，不支持后台策略 | ✅ VPS 7×24 运行策略 | Cloud-first 天然缺失 |
| 集中风险 | 高——OpenAI 被攻破 = 数百万用户凭证同时泄露 | 低——单 VPS 被攻破 = 只影响该用户 | 量级差异：数百万 vs 一 |
| 隐私 | 低——对话+交易数据经过 OpenAI 云 | 高——数据只在用户 VPS 上 | 金融合规场景关键差异 |
| 使用门槛 | 零——下载 App + OAuth 授权 | 中等——买 VPS + SSH + 配 Gateway + 配 MCP | 5 分钟 vs 1-3 小时 |
| 月成本 | ChatGPT Plus $20/月 | VPS $5-20/月 + LLM API | 差距不大 |
| 模型选择 | 只能用 OpenAI 模型 | 任意模型（GPT/Claude/DeepSeek/本地） | Personal Cloud = 万能插座 |
| 网络效应 | 强——数亿用户 + 开发者优先适配 | 弱——极少数用户 + 无商业推力 | Cloud-first 正循环 |
安全模型的深层矛盾：
| 真正的风险层级 | ChatGPT Cloud-first | OpenClaw Personal Cloud |
|---|---|---|
| 执行权风险（谁拿着钥匙能替你做事） | ❌ OpenAI 云既看数据，又拿着 OAuth Token 能执行——看到意图 + 能替你操作 | ✅ LLM 提供商只看到数据，Secret 在用户 VPS 上——看到意图但不能替你操作 |
| 意图隐私（谁看到你的交易意图） | △ 对话数据过 OpenAI 云 | △ 同样过云——这是所有调云端 LLM 的 Agent 架构的共同问题，非 Personal Cloud 独有 |
核心区分：看到意图 ≠ 拿着钥匙。 只要调云端大模型做推理，对话意图数据就过云——ChatGPT Cloud-first、OpenClaw Personal Cloud、荣耀 YOYO、华为小艺都一样，这是普遍存在且目前无很好解决方案的问题。真正的差距不在”谁看到意图”（都看到），而在”谁拿着钥匙能替你做事”——Cloud-first 里 OpenAI 既看又做，Personal Cloud 里 LLM 提供商只看不做。看到意图 = 知道你想买 BTC；拿着 Secret = 能替你买 BTC。前者是隐私问题（普遍存在），后者是安全问题（不可妥协）。
安全-能力-成本三角约束：
| 配置 | 执行权安全 | 意图隐私 | 能力 | 成本 | 适用人群 |
|---|---|---|---|---|---|
| Cloud-first | 低（OpenAI 既看又做） | 低（意图过 OpenAI 云） | 强（GPT-4o/5） | 低（$20/月） | 普通人 |
| Personal Cloud + API LLM | 高（LLM 只看不做） | 低（意图同样过云） | 强（GPT-4o/5） | 中（VPS+API） | 进阶用户 |
| Personal Cloud + 本地 LLM | 高（双重本地） | 高（意图不过云） | 弱（7B 模型） | 高（VPS+GPU） | 极少数硬核 |
注意：中间配置（Personal Cloud + API LLM）在意图隐私维度与 Cloud-first 没有本质差异——两者都调云端 LLM，意图数据都过云。真正的差异只在执行权安全（谁拿着钥匙）。意图隐私是所有云端 LLM Agent 的普遍问题，不是某一种架构的独有弱点。
哪一种是未来？
| 时间线 | 判断 | 核心变量 |
|---|---|---|
| 短期 1-3 年 | Cloud-first 是主流未来 | OAuth 扩散速度——交易所 1-2 年内采纳 OAuth，Cloud-first 硬伤大幅缓解；网络效应不可逆（数亿用户基数）；普通人不会学 Linux |
| 中长期 3-5 年 | 分层共存，不是单选 | 普通人（95%）→ Cloud-first + OS Agent；进阶用户（3-4%）→ Personal Cloud；开发者（1%）→ REST API + SDK。各层核心诉求不同：普通人要方便，进阶用户要控制，开发者要确定性 |
| 终局变量 | OAuth 扩散速度 | OAuth 1-2 年内被主流交易所采纳 → Cloud-first 覆盖 90%+ 金融场景 → Personal Cloud 差异化只剩隐私/本地网关 → 不足以支撑大众市场。OAuth 扩散缓慢 → Personal Cloud 在加密交易领域长期保持”唯一可用方案”（被迫刚需而非主动选择） |
类比理解：Cloud-first = 银行 APP（安全由银行管，功能受限，但不用操心）；Personal Cloud = 自建金库（安全自管，功能无限，但你要砌墙买锁雇保安）。自建金库安全得多，但绝大多数人选择银行 APP——因为他们不想成为保安。
四、信任边界：云端 Agent 的安全架构
4.1 三种验证机制与信任模型
云端 Agent 调用外部服务 API 时，验证机制决定了信任边界：
| 验证机制 | 原理 | 代表平台 | Agent 能安全放在云端吗 |
|---|---|---|---|
| OAuth 2.1 | 第三方只拿到有限权限+有限时效的 access token，密码不经过第三方 | Robinhood、Google Drive、Slack | ✅ 能——token 权限受限、到期失效、可随时撤销 |
| HMAC API Key + Secret | 每次请求用 Secret 做签名验证身份，Secret 是私钥绝对不能泄露 | OKX、Binance、Futu | ❌ 不能——Secret 被偷 = 完全控制账户，无法止损 |
| 本地网关密码隔离 | API Key 通过本地网关访问，交易密码在网关界面手动输入 | Futu OpenD | ❌ 不能——网关必须在用户本地运行 |
4.2 OAuth 的”酒店房卡”模型
OAuth 的核心设计理念：密码永远不经过第三方。
流程（以 Robinhood + ChatGPT 为例）：
1. 用户在 ChatGPT 说"帮我用 Robinhood 买股票"
2. ChatGPT 弹出授权提示，重定向到 Robinhood 登录页
3. 用户在 Robinhood 自己的页面输入账号密码（密码只经过 Robinhood，不经过 OpenAI）
4. Robinhood 问"愿意授权 ChatGPT 查看持仓+下单（需每次确认）吗？"
5. 用户点击"同意"
6. Robinhood 给 ChatGPT 一张"房卡"（access token）
7. ChatGPT 用这张房卡调 Robinhood MCP Server
8. 房卡权限有限、时效有限、可随时注销
Token 的安全属性：
| Token 类型 | 有效期 | 被盗影响 | 止损手段 |
|---|---|---|---|
| Access Token | 1-24 小时 | 有限——只能在授权范围内操作 | 到期自动失效；用户可随时撤销 |
| Refresh Token | 30-90 天或永久直到撤销 | 较大——可无限续卡 | 用户可在授权方设置里撤销 |
OAuth 被盗的风险是”有限的、可止损的”。
4.3 HMAC Secret 的”万能钥匙”模型
HMAC 签名的核心设计理念：私钥即身份。
1. 用户在交易所生成 API Key + Secret
2. 每次请求用 Secret 做 HMAC-SHA256 签名
3. 交易所验证签名正确就执行（不看是谁发的，只看签名对不对）
4. Secret = 万能钥匙——拿到 Secret = 完全控制账户
如果把 Secret 放在 OpenAI 云服务器上：
- OpenAI 云被攻破 → 黑客拿到所有用户的 Secret → 完全控制所有用户账户
- Secret 没有到期机制、没有权限分级、止损窗口极短（黑客可能在几分钟内转走资产）
- 这是不可接受的风险
所以 OKX、Binance 的 MCP Server 无法通过 ChatGPT 的 Cloud-first 架构安全使用——这就是 OKX 坚持 Local-first 的根本原因。
4.4 三种架构的安全信任边界总结
| 架构模式 | OAuth 服务 | HMAC 服务 | 本地网关服务 |
|---|---|---|---|
| ChatGPT Cloud-first | ✅ 安全可用 | ❌ 不可用（Secret 不能放云端） | ❌ 不可用（localhost 云端无法访问） |
| OpenClaw Local-first | ✅ 可用 | ✅ 安全可用（Secret 在本地） | ✅ 可用（网关在本地） |
| 平台自有云服务 | N/A（内部调用） | ✅ 可用（平台内部有 Secret） | N/A（平台内部有网关） |
信任边界决定了架构选择——没有一种架构能安全地覆盖所有验证机制。
五、即时执行场景的架构设计
5.1 通用架构
┌────────────────────────────── 用户层 ──────────────────────────────┐
│ │
│ 手机 App / OS Agent / 桌面 AI 客户端 │
│ → 用户表达意图（语音/文字/界面操作） │
│ → 接收执行结果 │
│ → 审批高风险操作（推送通知确认） │
│ │
└────────────────────────────── Agent 层 ─────────────────────────────┐
│ │
│ ┌── 端侧推理（简单意图）──┐ ┌── 云端推理（复杂意图）──┐ │
│ │ 模型：轻量端侧 LLM │ │ 模型：GPT-4/Claude/等 │ │
│ │ 场景：查余额、看持仓 │ │ 场景：跨策略分析、复杂下单 │ │
│ │ 延迟：< 1 秒 │ │ 延迟：2-5 秒 │ │
│ │ 依赖：不依赖网络 │ │ 依赖：需要网络 │ │
│ └──────────────────────────┘ └──────────────────────────┘ │
│ │
└────────────────────────────── 接口层 ──────────────────────────────┐
│ │
│ ┌── MCP ──┐ ┌── Skills ──┐ ┌── CLI ──┐ ┌── REST API ──┐ │
│ │ 工具连接 │ │ 行为指引 │ │ 便捷操作 │ │ 基础执行 │ │
│ │ │ │ │ │ │ │ │ │
│ │ AI一步 │ │ 教AI怎么 │ │ 人类/脚本 │ │ 开发者写 │ │
│ │ 调用 │ │ 做SOP │ │ 快速操作 │ │ 确定性代码 │ │
│ └──────────┘ └────────────┘ └──────────┘ └──────────────┘ │
│ │
└────────────────────────────── 平台层 ──────────────────────────────┐
│ │
│ 交易所 API / 券商 API / 携程 API / ... │
│ → 实际执行交易/购买/查询等操作 │
│ │
└──────────────────────────────────────────────────────────────────────┘
5.2 四种接口层的分工
| 接口层 | 目标用户 | 核心功能 | 代表产品 |
|---|---|---|---|
| API（REST/gRPC/FIX） | 人类开发者 | 基础执行层——给开发者写确定性代码用 | 所有交易所都提供 |
| Skills（SKILL.md） | AI Agent | 行为指引层——教 AI 该怎么做、SOP/领域知识/执行方式 | Futu Skills Hub、Binance Skills Hub |
| MCP（JSON-RPC 工具 schema） | AI Agent | 工具连接层——让 AI 一步调用结构化工具 | Robinhood MCP、OKX Agent Trade Kit |
| CLI（命令行工具） | 人类+脚本 | 便捷操作层——快速调试和轻量自动化 | OKX okx-trade-cli |
四层互补而非冗余：API 是原料，Skills 是方法论，MCP 是连接器，CLI 是快捷方式。
5.3 即时执行的具体流程
以”买入 100 美元 BTC”为例，不同架构下的执行路径：
路径 A：App 内嵌 AI + 客户端执行（OKX AI 策略 / Binance Ai Pro / Futu 牛牛AI）
用户在 OKX App 说"买入100美元BTC"
→ OKX App 内嵌 AI 模型理解意图
→ App 内直接调 OKX 交易 API
→ 订单提交
→ 结果显示在 App
- 用户不需要配置任何 API Key
- AI 推理 + 客户端一次性执行，不是云端 Agent 持续运行
- 安全通过 App 内账户隔离/交易密码保护
路径 B：通用 Agent 云服务 + OAuth MCP（ChatGPT + Robinhood）
用户在 ChatGPT App 说"帮我用 Robinhood 买100美元苹果股票"
→ ChatGPT 云端 GPT 理解意图
→ 选择 Robinhood MCP 工具
→ 用 OAuth access token 调 Robinhood MCP Server
→ Robinhood 执行 review_equity_order（模拟下单+确认）
→ 推送确认请求到用户手机
→ 用户确认
→ 正式下单
→ 结果返回 ChatGPT App
- 用户只需一次 OAuth 授权（浏览器点击”同意”）
- 之后 ChatGPT 拿 token 调 MCP，不需要再次登录
- Robinhood 的 review 流程确保每笔交易都经过用户确认
路径 C：通用 Agent 云服务 + HMAC MCP（ChatGPT + OKX）——不可行
用户在 ChatGPT App 说"帮我用 OKX 买100美元BTC"
→ ChatGPT 云端需要 OKX API Key + Secret 做 HMAC 签名
→ Secret 不能交给 OpenAI（安全风险不可接受）
→ ❌ 流程中断
这就是 Cloud-first 架构的根本性安全矛盾——HMAC Secret 不能放在第三方云端。
路径 D：Local-first Agent + HMAC MCP（OpenClaw + OKX）
用户在 OpenClaw Mobile 说"帮我用 OKX 买100美元BTC"
→ 手机遥控电脑 Gateway
→ Gateway 上的 Agent 理解意图
→ 通过 OKX MCP 工具调 okx-trade-mcp
→ 本地签名（Secret 不离本地）
→ 调 OKX API
→ 结果推送到手机
- Secret 100% 留在用户本地设备
- 但电脑必须一直开着
5.4 即时执行的安全总结
| 平台类型 | 验证方式 | 通用 Agent 云可行性 | 手机端 App 内嵌 AI | 说明 |
|---|---|---|---|---|
| 传统券商（Robinhood） | OAuth | ✅ 可行（ChatGPT + MCP） | ✅ 可行 | OAuth 安全可用，两种路径都行 |
| 加密交易所（OKX/Binance） | HMAC Secret | ❌ 不可行于第三方云 | ✅ 可行（App 内直接执行） | App 内嵌 AI 不需要 HMAC 签名暴露给第三方 |
| 券商（Futu） | 本地网关密码 | ❌ 不可行于任何云 | ✅ 可行（App 内直接执行） | App 内嵌 AI 调内部接口，不需要 OpenD 网关暴露 |
结论：即时执行场景下，手机端 App 内嵌 AI 可以覆盖所有验证机制（因为执行发生在 App 内部，不需要把凭证交给第三方）。通用 Agent 云服务只覆盖 OAuth 机制——对 HMAC 服务存在信任边界矛盾。
六、条件触发场景的架构设计
6.1 条件触发的核心架构
条件触发类任务的架构与即时执行完全不同——它需要一个持续运行的条件检测器和条件满足时的执行引擎：
┌─────────── 用户手机 ───────────┐
│ │
│ 创建策略：表达意图 + 设定条件 │ ← 输入
│ 审批确认：高风险操作推送确认 │ ← 审批
│ 查看状态：策略运行仪表盘 │ ← 监控
│ 收到告警：异常情况推送通知 │ ← 告警
│ │
└─────────── 服务端 ─────────────┐
│ │
│ ┌── Agent 编排层 ──┐ │
│ │ 理解意图 │ │
│ │ 翻译成规则卡 │ │
│ │ 收集所有参数 │ │
│ │ 用户确认后编译 │ │
│ └──────────────────┘ │
│ ↓ 规则卡 │
│ ┌── 执行引擎 ──┐ │
│ │ 规则引擎 7×24 运行 │ ← 确定性代码执行
│ │ 条件检测器持续监控 │
│ │ 条件满足 → 执行动作 │
│ │ 定时触发 → 执行动作 │
│ └──────────────┘ │
│ ↓ 关键节点 │
│ ┌── Agent 监督层 ──┐ │
│ │ Wake/Sleep 模式 │ ← Agent 按需唤醒
│ │ 关键节点审计（语义验证） │
│ │ 异常时暂停 + 通知用户 │
│ │ 权力只有一个：暂停 │
│ └──────────────────┘ │
│ ↓ │
│ ┌── Policy Engine ──┐ │
│ │ Size limits（下单量上限） │ ← 硬性安全约束
│ │ Circuit breaker（3级熔断） │
│ │ Mandatory review gate │
│ │ Audit log（全量审计日志） │
│ │ Dead man's switch（心跳超时停）│
│ └──────────────────┘ │
│ │
└─────────── 平台 API ───────────┐
│ │
│ 交易所 API / 券商 API / ... │
│ │
└─────────────────────────────────┘
6.2 从意图到规则卡的五步流程
| 步骤 | 在哪做 | 做什么 | 输出 |
|---|---|---|---|
| ① 多轮对话理解意图 | 手机 App | 用户跟 AI 对话，逐步明确意图 | 明确的意图描述 |
| ② 翻译成规则卡 | 服务端 | Agent 把意图翻译成结构化规则中间层 | 规则卡（触发条件+执行动作+参数+容忍度） |
| ③ 编译成可执行代码 | 服务端 | 规则卡编译成确定性代码（if-then 逻辑） | 可执行程序 |
| ④ 交给系统执行 | 服务端 | 程序 7×24 运行，条件检测+触发执行 | 执行结果 |
| ⑤ Agent 在关键节点审计 | 服务端 | Agent Wake/Sleep 模式，按需唤醒做语义验证 | 审计通过/暂停+通知 |
核心原则：代码执行，Agent 监督，用户决策。
- 规则卡编译成代码后，程序直接运行，不需要 AI 在每个判断节点介入
- Agent 只在关键节点短暂唤醒，做语义层面的合理性验证（”这个下单量是否匹配用户的意图？”）
- Agent 发现异常时只有一个权力：暂停——不能替用户做决策，不能修改代码逻辑
- 用户是所有调整的决策者——策略修改、参数变更、异常处理，全部来自用户
6.3 规则卡的结构
一个”腾讯股价低于 350 就买 100 股”的规则卡示例：
strategy_id: "strat_20260730_001"
name: "腾讯低价买入"
created_at: "2026-07-30T10:00:00"
status: active
trigger:
type: price_threshold
symbol: "HK.00700"
condition: price < 350
check_interval: 5s
action:
type: place_order
symbol: "HK.00700"
side: buy
order_type: limit
quantity: 100
price: current_market_price
max_slippage: 2% # 容忍度参数
tolerance:
slippage: 2% # 价格偏离容忍度
partial_fill: accept_up_to_80% # 部分成交容忍度
data_anomaly: pause_and_notify # 数据异常处理策略
risk_control:
max_order_value: 50000 HKD # 单笔最大金额
circuit_breaker:
level_1: 暂停策略 + 通知用户 # 单笔偏离超容忍度
level_2: 暂停所有策略 + 等用户确认 # 连续3次异常
level_3: 全量冻结 + 人工介入 # 系统级异常
dead_man_switch: 3600s # 心跳超时1小时无响应则自动暂停
agent_supervision:
checkpoints:
- before_order: "验证下单量与意图匹配"
- after_order: "验证订单结果是否符合预期"
- after_fill: "验证成交结果是否在容忍度范围内"
wake_mode: on_checkpoint # 只在检查点唤醒
max_steps_per_wake: 5
token_budget_per_wake: 2000
6.4 条件触发的不同模式
| 模式 | 触发条件 | 执行动作 | 代表场景 | 时间跨度 |
|---|---|---|---|---|
| 价格触发 | 价格 < 阈值 | 买入/卖出 | 股票/加密货币价格监控 | 几秒到几周 |
| 定时触发 | 时间 = 指定时刻 | 执行操作 | 定投策略（每月1号买入） | 固定周期 |
| 事件触发 | 事件发生（财报发布/新闻/CEO丑闻） | 执行操作 | 新闻驱动的交易策略 | 不确定 |
| 波动触发 | 价格波动 ±X% | 买入/卖出 | 网格交易策略 | 持续运行 |
| 状态触发 | 物流状态变化/订单状态变化 | 通知/操作 | 快递提醒/机票降价 | 几小时到几天 |
前四种是金融场景的常见模式，第五种是生活场景的模式。架构上统一处理——都是”条件检测器 + 触发执行”。
6.5 携程机票降价的例子
“明天去上海的直飞机票，降价到 500 以下就买”的规则卡：
strategy_id: "strat_ctrip_001"
name: "上海机票低价购买"
created_at: "2026-07-30T08:00:00"
status: active
trigger:
type: price_threshold
service: ctrip_flight_api
route: "北京→上海"
date: "2026-07-31"
flight_type: direct
condition: lowest_price < 500 CNY
check_interval: 30min
action:
type: auto_purchase
service: ctrip_order_api
passenger: ["张三"]
payment_method: credit_card # 需要用户预授权
max_price: 500 CNY
tolerance:
price_range: 450-500 CNY # 不低于450避免异常低价（可能是错误数据）
seat_class: economy_only
airline_preference: any # 不限航司
risk_control:
max_payment: 600 CNY # 单笔最大支付金额（含税费）
auto_purchase_limit: 1 # 最多自动购买1张
require_manual_confirm_if: price < 300 CNY # 异常低价需人工确认
agent_supervision:
checkpoints:
- before_purchase: "验证航班信息完整性（时间/航司/舱位）"
- after_purchase: "验证订单确认号有效"
wake_mode: on_checkpoint
关键差异：携程目前只做”低价提醒”不做”自动购买”——因为自动扣款涉及资金安全。如果携程要做自动购买，需要用户预授权支付方式（类似券商的交易授权），这是平台方需要做出的安全设计决策。
七、Agent 的角色定位
7.1 三种 Agent 角色
| 角色 | 出现场景 | 权力范围 | 触发条件 |
|---|---|---|---|
| 意图翻译者 | 策略创建阶段 | 无——只翻译意图，不执行 | 用户主动发起对话 |
| 监督者/QA | 策略执行阶段 | 只有暂停——不能替用户决策 | 关键检查点自动唤醒 |
| 异常处理者 | 异常发生时 | 暂停+诊断+通知——等用户决定 | 异常检测触发 |
Agent 永远不是决策者——代码做确定性执行，Agent 做语义验证，用户做所有决策。
7.2 Agent Wake/Sleep 模式
正常运行：
规则引擎 7×24 运行 → 条件满足 → 代码执行 → 结果记录
Agent: Sleep（不消耗资源）
检查点唤醒：
代码执行到关键节点 → Agent Wake → 语义验证 → 正常 → 放行 → Agent Sleep
Agent: Wake（短暂唤醒，5步以内）
异常唤醒：
代码检测到异常 → Agent Wake → 诊断 → 暂停策略 → 通知用户 → Agent Sleep
Agent: Wake（诊断后暂停，等用户介入）
每次唤醒的 Context Brief（新鲜状态摘要，替代长对话）：
{
strategy_id: "strat_001",
current_state: "条件满足，准备下单",
intent_summary: "腾讯股价<350时买入100股",
order_details: {symbol: "HK.00700", qty: 100, price: 349.8},
tolerance: {slippage: 2%, partial_fill: 80%},
recent_events: ["5秒前股价从350.2跌至349.8"]
}
Wake/Sleep 模式的价值：控制成本。Agent 不需要一直在线，只在关键节点短暂唤醒。
7.3 Agent 的权力边界
| Agent 能做的 | Agent 不能做的 |
|---|---|
| 翻译用户意图成规则卡 | 替用户做决策（买/卖/调整参数） |
| 在关键节点做语义验证 | 修改正在运行的代码逻辑 |
| 发现异常时暂停策略 | 绕过暂停继续执行 |
| 推送通知告警用户 | 替用户处理异常 |
| 记录审计日志 | 自主调整策略参数 |
Agent 的唯一执行权力是”暂停”——这是一种安全机制而非决策机制。暂停后的一切操作由用户决定。
八、行业现状：各平台的云端 Agent 实现
8.1 金融类平台
| 平台 | 产品 | 即时执行 | 条件触发 | 实质 | 安全模型 |
|---|---|---|---|---|---|
| OKX | AI 策略 | ✅ App 内嵌 AI 推理 + 客户端执行 | ❌ 不持续运行 | AI 推理 + 客户端一次性执行 | App 内账户隔离 |
| OKX | 策略交易 / Trading Bots | ❌ 无 AI | ✅ 7×24 规则引擎运行 | 服务端规则引擎（非 AI Agent） | 服务端托管 |
| OKX | Agent Trade Kit | ✅ MCP/CLI 工具调用 | ❌ 不支持持续运行策略 | 外部 Agent 工具集（本地执行） | Local-first HMAC 签名 |
| Robinhood | Agentic Trading | ✅ MCP 工具调用 | ❌ 对话关闭 = 策略停止 | 外部 Agent + MCP Server（一次性执行） | OAuth + Agentic 账户隔离 |
| Binance | Ai Pro | ✅ App 内嵌 AI 推理 + 客户端执行 | ❌ 不持续运行 | AI 推理 + 客户端一次性执行 | 虚拟子账户隔离 + $9.99/月 |
| Binance | Trading Bots | ❌ 无 AI | ✅ 7×24 规则引擎运行 | 服务端规则引擎（非 AI Agent） | 服务端托管 |
| Futu | 牛牛AI 专家模式 | ✅ App 内嵌 AI 推理 + 客户端执行 | ❌ 对话依赖，不持续运行 | AI 推理 + 客户端一次性执行 | DeepSeek 私有化 + 交易密码隔离 |
| Futu | 策略交易/量化平台 | ❌ 无 AI | ✅ 7×24 规则引擎运行 | 服务端规则引擎/用户代码 | OpenD 网关密码隔离 |
| Futu | Skills + MCP | ✅ 外部 Agent 调 OpenD | ❌ OpenD 必须本地运行 | 外部 Agent 工具集（本地执行） | OpenD 三重防火墙 |
关键发现：目前行业中有两种不同的”AI + 交易”产品——一种是 AI 推理 + 客户端一次性执行（即时执行场景），一种是规则引擎 + 服务端持续运行（条件触发场景）。二者都没有”AI Agent 在云上持续运行自主决策”——这是行业的空白地带。
8.2 生活服务类平台
| 平台 | Agent 功能 | 即时执行 | 条件触发 | 云端形式 |
|---|---|---|---|---|
| 携程 | 低价提醒 | ✅ 查询航班 | ✅ 服务端监控+推送通知（但不自动购买） | 平台自有云 |
| 滴滴 | 无 Agent | — | — | — |
| 美团 | 无 Agent | — | — | — |
生活服务类平台目前只做”提醒”不做”自动执行”——因为自动扣款/自动下单涉及资金安全和商业利益（平台不希望 Agent 替用户操作，减少广告曝光和交叉销售机会）。
8.3 OS 内嵌 Agent
| 产品 | 即时执行 | 条件触发 | 限制 |
|---|---|---|---|
| 荣耀 YOYO | ✅ 系统级 GUI Agent（订票/发消息等） | ❌ 手机不稳定 | 绑定荣耀手机品牌 |
| ChatGPT App | ✅ 对话+MCP 工具调用 | ❌ 一问一答，不自主运行 | OAuth 服务才能安全使用 |
| OpenClaw Mobile | ✅ 遥控电脑 Gateway | ✅ 电脑持续运行 | 电脑必须不断电不断网 |
九、云端 Agent 的关键设计决策
9.1 谁来运行云端 Agent？
| 方案 | 适合的平台类型 | 优势 | 劣势 |
|---|---|---|---|
| 平台自有云服务 | 交易所、券商、携程等有执行权限的平台 | 执行权限天然具备、7×24 可靠、低门槛 | 只限本平台、封闭生态 |
| 通用 Agent 云平台 | 跨平台编排需求（如同时管理 OKX+Binance+券商账户） | 跨平台、自由编排 | HMAC 安全矛盾、只覆盖 OAuth 服务 |
| 混合架构 | 平台自有云做核心执行 + 通用云做跨平台编排 | 兼顾安全与灵活性 | 架构复杂度增加 |
现实结论：条件触发场景目前只有”平台自有规则引擎”这一种可靠方案——没有”AI Agent 在云上持续运行”的产品。即时执行场景则有多条路径可选（App 内嵌 AI / 通用 Agent 云 / Local-first Agent）。真正的”云端 Agent”——AI 在平台服务器上持续运行自主决策——是行业空白，需要新的架构设计。
9.2 Agent 在执行中的角色
| 设计哲学 | Agent 角色 | 执行方式 | 适用场景 |
|---|---|---|---|
| 哲学 A：代码执行 + Agent 监督 | Agent 是监督者/QA | 规则编译成代码，代码 7×24 运行，Agent 按需唤醒审计 | 条件触发类（量化策略、价格监控） |
| 哲学 B：Agent 决策 | Agent 是决策者 | Agent 在每个判断节点做推理决定 | 即时执行类（App 内嵌 AI 一次性指令） |
| 哲学 A+B 混合 | 创建阶段用 Agent 翻译意图，执行阶段代码运行 + Agent 监督 | 确定性部分走代码，语义验证走 Agent | 全场景 |
哲学 A 的优势：确定性高、成本低、责任清晰（代码行为可审计）。哲学 B 的优势：灵活性强、可处理未预设的情况。但在金融场景下，哲学 B 的责任风险不可接受——Agent 替用户做决策意味着平台要对 Agent 的错误决策承担责任。
9.3 条件检测器的实现方式
| 方式 | 说明 | 适用场景 |
|---|---|---|
| 规则引擎 | if-then 逻辑，确定性执行 | 价格阈值、定时触发、状态变化 |
| WebSocket 实时推送 | 交易所推送行情 tick，规则引擎实时检查 | 高频价格监控（几秒级响应） |
| 定时轮询 | 每隔 X 分钟/小时调 API 查状态 | 低频监控（机票价格、物流状态） |
| Agent 推理判断 | LLM 在每个间隔判断是否该操作 | OKX AI 策略宣传此模式，但实际是 AI 推理 + 客户端执行，非云端 Agent 持续运行 |
规则引擎是主流方案——确定性高、成本低、7×24 可靠。OKX AI 策略尝试让 AI 参与策略执行，但本质仍是客户端一次性执行而非云端 Agent 持续运行。真正的”Agent 推理判断 + 服务端持续运行”目前没有产品实现。
9.4 策略生命周期管理
创建 ──→ 运行 ──→ 监控 ──→ 调整 ──→ 终止
创建：用户在手机 App 对话 → Agent 翻译意图 → 生成规则卡 → 用户确认 → 编译成代码
运行：代码 7×24 在服务端运行 → 条件检测 → 触发执行 → Agent 关键节点审计
监控：手机 App 仪表盘查看状态 → 异常推送通知 → 用户决定是否介入
调整：用户主动修改参数 → Agent 重新翻译 → 更新规则卡 → 重新编译运行
终止：用户主动终止 → 策略停止 → 结果汇总 → 通知用户
整个生命周期中，Agent 的介入点只有两个：创建时翻译意图、运行时关键节点审计。其余全部由确定性代码完成。
十、架构选型建议
10.1 按场景选架构
| 场景 | 推荐架构 | 原因 |
|---|---|---|
| 金融即时交易（加密货币 + 传统券商） | App 内嵌 AI | App 内执行不需要 Secret 暴露给第三方，零门槛，手机即可完成 |
| 金融条件触发策略（加密货币 + 传统券商） | 平台自有规则引擎 | 必须服务端 7×24 运行，平台规则引擎天然具备执行权限；加密货币用 OKX/Binance Trading Bots，传统券商用 Futu 量化/条件单 |
| 机票/生活服务条件触发 | 平台自有服务端监控 + 用户手动确认购买 | 平台不愿开放自动购买 API，用户手动确认是目前的安全平衡点 |
| 跨平台信息整合 | 通用 Agent 云（ChatGPT / OpenClaw） | 不涉及执行权限，只做查询和分析 |
10.2 按用户类型选架构
| 用户类型 | 推荐方案 | 原因 |
|---|---|---|
| 普通零售用户（手机为主） | App 内嵌 AI（即时执行）+ 平台自有规则引擎 Bot（条件触发） | 即时执行手机就能做，条件触发靠平台服务端；加密货币和传统券商逻辑一致 |
| 进阶用户（有电脑、愿意配置） | OpenClaw + MCP/CLI（即时执行+条件触发） | Local-first 安全、跨平台自由编排，但电脑必须一直开着 |
| 量化开发者 | REST API + SDK | 确定性代码、完全自定义、高性能 |
| AI Agent 开发者 | MCP + Skills | 结构化工具接口 + 行为指引，一次部署多平台适配 |
10.3 平台方的关键决策
10.3 关键决策：谁需要做云端 Agent？
交易平台不需要做——没动机、没需求
对交易平台（交易所/券商）来说，提供”云端 Agent”既没有动机也没有需求：
没有动机做跨平台编排——跨平台编排 = 把用户操作引导到其他平台 = 流量外泄 = 商业自杀。OKX 不可能帮你比较 Binance 的价格差，Binance 不可能帮你把资产转到 OKX 去开策略。
没有需求做单平台云端 Agent——因为单平台的所有场景已被现有方案覆盖：
| 用户需求 | 已有方案 | 是否需要云端 Agent |
|---|---|---|
| 即时执行 | App 内嵌 AI（OKX AI策略 / Binance Ai Pro / Futu 牛牛AI） | ❌ 不需要 |
| 条件触发（精确数值） | 规则引擎 / Trading Bots / 条件单 | ❌ 不需要 |
| 条件触发（语义判断） | 规则引擎 + AI 定期唤醒 | ❌ 不需要——唤醒式够用 |
| 策略配置 | App 内嵌 AI 辅助一键创建 Bot | ❌ 不需要 |
更优的架构是三层各司其职，没有一层需要 AI 7×24 持续运行：
– 执行层：规则引擎（确定性、低成本、7×24）
– 配置层：App 内嵌 AI（一次性推理，帮用户创建/调整 Bot）
– 审计层：AI 定期唤醒（每小时/每天检查一次市场状态，判断是否需要调整策略参数）
交易平台的角色是被编排的对象，不是主动提供 Agent 的一方。 它要做的是开放 API / MCP / Skills，让别人（OS Agent、通用 Agent 云）来调用，而不是自己去做 Agent。
真正需要做决策的是两类角色
| 角色 | 动机 | 能力 | 限制 |
|---|---|---|---|
| 交易平台 | ❌ 无——留住用户是核心利益 | ✅ 有——7×24 服务器、执行权限 | 跨平台违背商业利益；单平台场景已有方案覆盖 |
| OS 厂商（荣耀/华为/Google） | ✅ 有——OS 天然是跨 App 入口 | ✅ 有——系统级权限、GUI Agent | 手机不稳定做不了条件触发；App 厂商抵触自动操作 |
| LLM 提供商（OpenAI/Anthropic） | ✅ 有——Agent 是下一个增长点 | ✅ 有——云端推理、OAuth Connector 目录 | HMAC Secret 安全矛盾；一问一答模式不支持条件触发 |
| 开源社区（OpenClaw） | ✅ 有——理念驱动 | ✅ 有——可以调所有 API | 用户门槛太高；无商业推力 |
OS 厂商 vs LLM 提供商的关系：
- OS 厂商的优势是入口——用户每天打开手机第一件事不是打开 ChatGPT，而是看到手机桌面。荣耀 YOYO、华为小艺、Google Gemini 是”贴着用户的入口”，不需要额外安装
- LLM 提供商的优势是大脑——OS 厂商的端侧模型能力有限（7B 参数级），真正复杂的推理还是要调 GPT-4o / Claude
- 两者的关系正在变成分销关系：华为小艺调 DeepSeek，荣耀 YOYO 调阿里千问，Google Gemini 在 Android 17 里既是 OS Agent 又是自家 LLM 产品
入口在 OS 手里，大脑在 LLM 提供商手里。 这个格局意味着 OS 厂商在 Agent 生态中有更大的话语权——他们决定用户首先接触谁，LLM 提供商只能做”被调用的后台服务”。但条件触发场景目前双方都做不好：OS 厂商受限于手机不稳定，LLM 提供商受限于一问一答模式。
各角色的关键决策
OS 厂商的关键决策：
| 冺策 | 选项 A | 选项 B | 推荐 |
|---|---|---|---|
| 跨 App 操作方式 | API 直调（MCP/AppFunctions） | GUI 模拟（视觉 Agent） | 双路线——API 优先、GUI 兜底 |
| 条件触发实现 | 本地后台监控 | 云端代为监控 | 云端代为监控——手机不稳定是硬伤 |
| LLM 来源 | 自研端侧模型 | 调第三方云端 LLM | 混合——简单意图走端侧，复杂推理走云端 |
| 支付等高风险操作 | 允许 Agent 自动完成 | 阻断自动化、强制人工确认 | 强制人工确认——安全底线不可妥协 |
LLM 提供商的关键决策：
| 冺策 | 选项 A | 选项 B | 推荐 |
|---|---|---|---|
| Agent 运行架构 | Cloud-first（只支持 OAuth MCP） | 支持 Personal Cloud（用户自带 Secret） | Cloud-first 为主流未来，但需推动 OAuth 扩散 |
| 条件触发能力 | 一问一答模式（不支持后台运行） | 增加后台任务调度能力 | 必须增加——条件触发是刚需，一问一答无法满足 |
| 与 OS 厂商的关系 | 竞争（自己做独立 App 入口） | 合作（做 OS Agent 的后台推理） | 合作优先——入口在 OS 手里，独立 App 是补充 |
| 对交易平台的策略 | 等交易平台自己开放 OAuth | 主动推动 OAuth 标准 | 主动推动——OAuth 扩散速度决定 Cloud-first 的服务覆盖范围 |
交易平台的关键决策（角色是”被编排方”，不是”Agent 提供方”）：
| 冺策 | 选项 A | 选项 B | 推荐 |
|---|---|---|---|
| 对外开放方式 | OAuth 授权服务器 | HMAC API Key + MCP/CLI/Skills | 两者都要——OAuth 覆盖 Cloud-first Agent，MCP/CLI 覆盖 Local-first Agent |
| App 内嵌 AI | 做（OKX AI策略 / 牛牛AI） | 不做，只提供规则引擎 Bot | 做——即时执行场景 App 内嵌 AI 是最优方案 |
| 跨平台态度 | 封闭（只在自己 App 内提供服务） | 开放但可控（提供接口但不做 Agent 本身） | 开放但可控——提供 API/MCP/Skills 供外部 Agent 调用，让 OS/LLM 厂商来编排 |
十一、总结
云端 Agent 的核心命题
手机端存在断电断网的硬伤，条件触发类任务必须跑在服务端。云端 Agent 的价值不是”让 AI 替人思考”，而是”让策略在可靠环境中 7×24 运行，AI 只在关键节点做语义验证”。
两个核心场景的架构差异
| 维度 | 即时执行 | 条件触发 |
|---|---|---|
| 时间跨度 | 几秒到几分钟 | 几秒到几天甚至持续运行 |
| 运行环境 | 手机基本可用 | 必须服务端 7×24 |
| Agent 角色 | 意图理解 + 工具选择 | 意图翻译（创建时）+ 语义审计（运行时） |
| 执行方式 | Agent 调工具一步完成 | 规则引擎确定性代码 + Agent 关键节点唤醒 |
| 安全要求 | 单次操作的安全验证 | 全生命周期的持续安全监控 |
云端服务的两种形式
| 形式 | 优势 | 劣势 | 适用 |
|---|---|---|---|
| 平台自有云 | 执行权限天然具备、7×24 可靠、低门槛 | 只限本平台、封闭生态 | 金融交易、生活服务核心执行 |
| 通用 Agent 云 | 跨平台、自由编排 | HMAC 安全矛盾、条件触发能力缺失 | 信息整合、OAuth 服务操作 |
关键洞察
- 即时执行手机端完全可以完成——App 内嵌 AI + 客户端执行覆盖所有验证机制，不需要云端 Agent
- 条件触发必须服务端 7×24 运行——手机端断电断网是硬伤，没有妥协空间
- 目前行业没有”AI Agent 在云上持续运行自主决策”的产品——条件触发靠规则引擎（非 AI），即时执行靠 AI 推理 + 客户端一次性执行（非云端 Agent）
- 信任边界决定架构选择——OAuth 服务可用 Cloud-first（ChatGPT），HMAC 服务必须 App 内嵌或 Local-first
- 代码执行 + Agent 监督是条件触发的最优架构——确定性高、成本低、责任清晰，但目前行业只实现了”代码执行”部分，”Agent 监督”部分仍是空白
- 生活服务平台的”自动执行”缺口是行业级问题——平台不愿开放 API，短期内只能做提醒不做自动购买
- OS 内嵌 Agent 解决一次性指令，不解决条件触发——两者是分工关系而非替代关系
- 四层接口（API + Skills + MCP + CLI）互补而非冗余——覆盖不同用户类型和不同使用模式
本文基于对 Robinhood Agentic Trading、OKX Agent Trade Kit & AI 策略 & Trading Bots、Binance Ai Pro & Skills Hub & Trading Bots、Futu 牛牛AI & OpenD & 量化平台 等产品的实际分析，以及对 OAuth、HMAC、Skills、MCP 等技术机制的深度讨论。
分享到