前两篇写的是开发者主动给 agent 上锁：OpenChart 干脆不给下单键，NOFx 用 Go 代码钳住每笔订单。写完那晚我在 r/mcp 刷到一份审计日志，数字把我的预期打翻了——过去 7 天，agent 提交 230 次回测，人类 40 次；轮到部署机器人上线，agent 1 次，人类 16 次。我随即把 Robinhood 的 agentic 交易产品页、两个实盘讨论帖全文和 HN 时间线逐一抓下来核对。我没连任何券商账户，以下全部来自页面和帖子原文。三份材料指向同一个反常识：所有人都在防 AI 乱下单，而数据里最不敢按按钮的，恰恰是 AI。

券商把逐笔审批写进了默认设置

先看事件本身。Robinhood 已经把 agentic trading 做成一条官方产品线，我把产品页抓下来核对，几个关键设置值得逐条看：

• • 专属账户：给 agent 单独资金账户，活动独立追踪；
• • 逐笔审批，默认开启——官方原话是 "approvals turned on by default"；
• • 外部 agent 经 MCP 接入，页面直接提供 MCP 文档入口；
• • Agent Loops（定时自动研究+交易）标注 Coming soon。

风险披露写得毫不含糊："trades may be executed by an AI agent without your direct input on each transaction"，同时声明 "Robinhood does not control, supervise, monitor, recommend, or audit these AI agents"——券商提供管道和审批开关，不对 agent 行为负责。

时间线上这是一场半年时间的推进：5 月中旬 HN 上出现带安全护栏的 agentic trading 项目（55 分 33 评论），月底 American Banker 把 Robinhood 的动作称为"给银行的 wake-up call"，6 月底 Robinhood 页面登上 HN。我在 GitHub 搜了一圈，面向量化场景的 MCP server 已经冒出一批——行情因子、回测、筛选都有人做了。管道标准化在发生，这不是趋势预测，是已经落地的事实。

真正值得注意的反而是那个默认值。券商级产品线完全有条件宣传"全自动"，它却把"每笔交易等人工批准"设成了出厂状态。

7 天审计日志：6 倍测试，1/16 部署

默认审批只是制度设计，实际行为要看数据。10 月 11 日，Quantradin 的运营者在 r/mcp 发了一份审计日志，他先声明了利益相关：server 是他运营的，paper trading，无真实资金，帖子不带链接。

这份日志把过去 7 天的两类用户分开统计——用浏览器的人，和持 MCP key 的 agent：

两条日志规则先交代清楚：两列所有动作都是 allowed——没有发生拒绝，因为没有任何请求超出 key 权限；12 把 key 全部由人铸造。

the agents test about 6x more than the people and almost never pull the trigger

agent 的测试量是人类的 6 倍左右，部署量是 1/16。有意思的是作者没有急着下结论，他给了三种解释并承认自己分不清：agent 恰当地谨慎，回测多部署少正是理想形状；或者连 agent 的人群本来就把 agent 当研究工具，部署留给人手动做；又或者 deploy 工具的描述写得太重，agent 犹豫的是文案——"I'm reading a docs problem as good judgement"，把文档问题读成了好判断。

权限设计也值得看一眼：只读 key 能看一切，还能执行回退类动作（平仓、撤单、暂停）；但开新仓位、启动机器人，需要人有意铸造对应 scope 的 key。agent 不是不能动，是动钱的权限从来没给到它手上。

我原以为这篇该写"怎么防模型幻觉下单"，日志说的却是另一件事：模型根本不碰部署按钮。

拒绝下单的是助手，不是 MCP

还剩最后一个环节没解释：如果 agent 被允许下单，它到底下不下？10 月 4 日 r/algotrading 有个帖子问的正是这个，标题是"有人真的通过 Robinhood 的 Agentic MCP 跑实盘吗"。

楼主的进度卡在一个具体位置：他验证了本地 Codex App Server 的只读账户读取（无需模型回合，链路是通的），然后是这句——"the assistant says it cannot submit or cancel real orders, even with my approval"。他批准了，助手仍然拒绝。楼主的现实约束很典型：上班时间和开盘重叠，"alert telling me to close a trade isn't enough if I can't get to my phone"。

同题转发到 r/ai_trading 的讨论串里，一个叫 QuanTradin 的用户给出了这批讨论里最关键的一句判断：

The assistant refusing to submit is the assistant's policy, not the MCP. The setups I've seen that actually run live don't let the model press the button at all.

拒绝下单的是模型自身的政策，不是 MCP 协议的限制。而真正在实盘跑起来的 setup，干脆不让模型碰按钮。

把三个来源放在一起，"agent 不下单"的原因至少有三层：模型厂商的政策（助手拒绝提交）、工具描述的措辞（Quantradin 怀疑自己的 deploy 工具文案吓退了 agent）、key scope 的设计（动钱权限从未铸造）。排查"我的 agent 为什么不下单"时，这三层得一层层分开验——它们的表现一模一样，责任方完全不同。

实盘在跑的架构里，模型不在下单路径上

那真正跑实盘的人怎么搭？评论区几个互不相识的用户给出的架构高度一致。Alpaca 实盘用户 Signal_Pace_7968 的版本：模型只产出结构化提案——symbol、方向、数量、入场、止损、目标；审批在自己的 app 里完成；然后一个纯服务器进程校验提案（仓位上限、交易时段、每日亏损上限），经 broker API 提交。"No model in that path"——下单路径里没有模型。退出单直接在 broker 侧挂 bracket，覆盖"我在开会够不到手机"的场景。

另一位用户补充的是工程细节：模型和 broker 之间放一个确定性策略网关，订单放行前要求显式的 symbol、方向、数量、价格边界、账户范围和幂等键；paper 模式起步；记录每次 tool call；设置一个模型无权修改的独立 kill switch。

还有一条值得单独记下来的教训来自断线场景：不要相信"我以为撤单成功了"，除非收到 broker 回调确认。自己维护订单状态、记录每次更新的 id 和时间戳、重连后先对账再发新单——原话是 "A lot of duplicate-order bugs are really just 'I assumed the last request worked.'"，很多重复下单 bug 的本质就是假设上一次请求成功了。

把这几条合成最小形态，大概长这样：

proposal = model.propose(symbol, side, qty, entry, stop, target)  # 模型只到这里if not human.approve(proposal):        # 审批在人的手里    reject(proposal)order = gateway.validate(              # 确定性网关，模型不在路径里    proposal,    max_position=..., market_hours=True, daily_loss_cap=...,    idempotency_key=uuid4(),           # 断线重发不会变成双倍仓位)broker.submit(order)                   # 自己的脚本经 broker API 执行broker.attach_bracket(order, stop, target)  # 退出单挂交易所侧

一个必须知道的坑：Robinhood 不支持 bracket 单，无人值守的退出要么挂普通止损单，要么把执行换到支持 OCO 的 broker（Alpaca 和 IBKR 都支持）——评论区有人自纠过这一点，且没人见过经 Robinhood agentic MCP 本身跑通无人值守退出的案例，被验证过的只有读取侧。

官方托管还是自建三段式

回到选择。前两篇的 OpenChart 和 NOFx、今天的 Robinhood 和实盘用户，四个互不相干的来源收敛在同一个原则上：下单按钮不放在模型手里。差别只是闸门由谁造——项目自己造（代码闸门）、券商造（默认审批）、模型厂商造（助手政策），或者你自己造（三段式）。

官方托管适合不想维护执行代码、要券商流程兜底的人，代价是逐笔审批的响应速度和产品当前的限制（股票侧 API 未开放、Agent Loops 未上线）。自建三段式适合有自己的策略逻辑、需要无人值守退出、愿意自己维护订单状态对账的开发者。对任何人不适用的选项只有一个：把带下单 scope 的 key 直接铸给模型。

同一个时间窗口里，X 上流传着另一极的内容——一条 prompt 让 Opus 5.5 从零搭建 24/7 交易系统的帖子拿了 200 多赞。零售端在传播一键魔法，工程端在给每个订单加幂等键，这两个世界的距离本身就是风险。

最后交代证据边界：Quantradin 的审计日志是运营者自述、paper trading、单一平台样本，数字我只核对了帖子原文，无法独立复现；Robinhood 产品页和两个帖子是我直接抓取核对的，但 Robinhood 的 MCP 文档是 JS 渲染页面，具体工具清单我没拿到；我没有连接任何券商账户，实盘架构的描述全部来自实盘用户的一手发言，多个独立来源互相印证但没有统一的基准实现。文中没有任何收益数据，这也不构成投资建议。

如果你正在把 agent 往券商 MCP 上接，先去产品页找到 "View MCP docs" 把工具清单过一遍，然后从 paper 模式起步。评论区想统计一个数：你的 agent 从提案到真实订单之间，隔了几个动作？把这篇转给正在接券商 API 的朋友，他省下的可能是一次"以为撤单成功了"的重复下单。下一篇写断线重连后的订单对账，把"我以为"这个坑做成最小实现——想看的点个在看。