🤖 给 AI 自主交易权有多危险？polymarket-mcp-server是一个让 Claude 通过 MCP 协议交易 Polymarket 预测市场的 AI 交易服务器，它用订单确认机制和自主交易开关（ENABLE_AUTONOMOUS_TRADING）这两道闸门，把"AI 替你下单"的风险锁在可控范围内——默认配置下，每一笔订单都必须经过确认才会真正发出。

本文带你从零看懂这两个设计：它们是什么、如何工作、以及为什么默认值这么"保守"。

一、先认识主角：一个带"刹车系统"的AI交易服务器

polymarket-mcp-server 向 Claude 开放了45 个工具，覆盖市场发现、行情分析、下单交易、组合管理和实时 WebSocket 监控。其中 12 个交易类工具（create_limit_order、create_batch_orders、execute_smart_trade等）拥有真实资金操作能力。

而架构的核心，是一条层层设防的调用链：

MCP 客户端 → 工具层 → SafetyLimits 安全检查 → 限流器 → CLOB API → 交易所

安全设计文档：TRADING_ARCHITECTURE.md，安全策略声明：SECURITY.md

⚠️ 官方在安全政策里开宗明义：本项目持有钱包私钥、能用真金白银下真实订单，任何影响安全上限的缺陷都按安全漏洞处理。

二、自主交易开关：两个参数决定"AI 有多大的手"

所有风控参数都定义在配置文件 src/polymarket_mcp/config.py，其中与"自主权"直接相关的是两个：

三种模式的实际效果，一目了然：

• 🛑默认模式（开关false）：AI 只能"提案"，任何订单（哪怕 1 美元）都会被拦截并返回confirmation_required状态
• 🤖全自主模式（开关true，门槛 500）：500 美元以下的小单直接执行，超 500 美元才回来征求确认
• 🎚️自定义模式（开关true+ 把门槛调低到 100）：几乎所有"像样的"交易都会先弹确认，适合新手

配套的上限参数（默认值均为示例，可按需收紧）：

MAX_ORDER_SIZE_USD=1000 # 单笔订单上限 MAX_TOTAL_EXPOSURE_USD=5000 # 总敞口上限 MAX_POSITION_SIZE_PER_MARKET=2000 # 单市场持仓上限 MIN_LIQUIDITY_REQUIRED=10000 # 市场最低流动性 MAX_SPREAD_TOLERANCE=0.05 # 最大买卖价差容忍（5%）

三、确认机制如何工作：订单成交前必经的"最后一道闸"

一笔限价单的完整旅程（源自 TRADING_ARCHITECTURE.md 的数据流图）：

1. Claude 发起create_limit_order调用
2. 工具层做参数校验（价格 0.01–0.99、边侧 BUY/SELL）
3. 拉取市场数据与当前持仓
4. SafetyLimits.validate_order跑完5 项安全检查（单笔额度、总敞口、单市场上限、流动性、价差）
5. 确认门槛检查← 本文主角
6. 通过后才签名并 POST 到 CLOB API

关键在第 5 步。核心逻辑只有两行（src/polymarket_mcp/utils/safety_limits.py）：

# 自主交易关闭 → 无条件要求确认 if not autonomous_trading_enabled: return True # 自主交易开启 → 只有订单金额超过门槛才要求确认 return order_value_usd > self.require_confirmation_above_usd

确认闸的拦截动作在 src/polymarket_mcp/tools/trading.py 中实现。被拦截时，订单不会发往交易所，而是原样返回：

• status: "confirmation_required"
• reason：说明原因（"超过确认门槛"或"自主交易已禁用"）
• details：完整的订单摘要（市场、方向、价格、金额、订单类型），供用户/AI 复核
• 提示语："Review the details and call again with confirm=true to place this order."

也就是说，用户（或 Claude）复核后，只需带上confirm=true重新发起，订单才会放行。

拦截是真的"拦"住了吗？

这是最容易做成"假门"的地方——只打一条日志，订单却照样发出去。项目专门写了契约测试 tests/test_confirmation_gate.py 来钉死这个行为：用一个会记录"是否真的发单"的假客户端验证——未确认的订单绝不允许到达post_order。测试文件开头的注释说得很直白：

"Before the fix, create_limit_order logged 'Order requires confirmation' and then posted the order anyway"（修复前，它只记了日志，订单照样发出）

这段历史说明：确认机制不是摆设，它是被真实 bug 逼出来的防线。

批量下单与智能交易：闸门同样生效

闸门不止作用于单笔订单：

• 批量下单create_batch_orders：批次内若有订单需要确认，返回awaiting_confirmation计数，且全部订单都不执行，提示你带confirm=true重发
• 智能交易execute_smart_trade与持仓再平衡rebalance_position：内部拆出的每一腿订单同样要过确认闸，触发时整个执行计划挂起（src/polymarket_mcp/tools/trading.py）

图形界面也能调

Web 仪表盘提供了 Trading Controls 表单，勾选 "Enable Autonomous Trading" 并调整确认门槛即可（src/polymarket_mcp/web/templates/config.html）：

Allow trading without manual confirmation for each order

⚠️ 注意仪表盘设计为仅绑定localhost，官方明确提醒不要暴露到公网。

四、安全审计：这套闸门真的无懈可击吗？

项目附有一份相当硬核的对抗式安全审计 docs/security-audit-T-0045.md，用"可执行的离线复现"逐条验证安全层。与本文主题相关的几个发现：

✅ 确认门"何时触发"是精确的

审计引用既有测试（T-0041）钉死：金额超过门槛 1 美分就会立刻被拦到confirm=true为止——门槛检查没有模糊地带。

⚠️ 但确认动作由"发起下单的同一个 AI"完成（B3 观察项）

审计指出：确认决定权属于调用方（LLM）本身，系统没有"带外审批通道"（比如仪表盘签发的一次性审批令牌）。这被标注为产品决策而非代码缺陷，但也意味着：不要把闸门当作唯一防线。

🔍 审计同时确认了若干限额绕过边界（均附可执行复现）：

• NaN金额可绕过所有上限检查（A1）
• 多腿批量订单会把总敞口"棘轮"推过总上限（B1）
• 并发下单会基于同一份过期持仓快照做校验，存在 TOCTOU 竞态（B2）

这些发现都被转化为仓库中的可执行测试（tests/test_safety_adversarial.py），修复前测试保持红、修复后强制更新——安全声明始终有"机器证据"背书，而不是靠文案。

五、新手实操建议：如何安全地"放权"

综合 SECURITY.md 的运营指引和 FAQ.md 的回答，给 AI 放权的正确姿势是：

1. 保持默认开关关闭起步。ENABLE_AUTONOMOUS_TRADING=false下每笔订单都要确认，先观察 AI 的提案质量
2. 把确认门槛调低。官方建议新手设REQUIRE_CONFIRMATION_ABOVE_USD=100，让所有"有意义的"交易都必须过目
3. 用专用钱包。只充你愿意交易和输掉的钱，绝不指向主钱包
4. 探索期用只读模式：省略 API 凭据启动，服务器仅提供 25 个只读工具（发现/分析/实时），完全没有交易能力
5. 记得 LLM 在环：AI 可能误读市场、甚至被市场数据里的文本"注入"。官方原话是——Keep REQUIRE_CONFIRMATION_ABOVE_USD low and review what it proposes（把门槛压低，审查它的每一笔提议）

一句话总结这套设计哲学：闸门拦得住手，拦不住心——所以上限参数、确认门槛、专用钱包、人工复核要组合使用，而不是指望任何单点。

附录：本文涉及的源码与文档