为什么金融场景的 Agent 自动化必须设人闸？

当用户对交易 Agent 说「全部买入特斯拉」，模型理解的「全部」可能是账户现金的 100%，而风控规则允许的最大仓位可能是 50%。这中间的差距就是意图解析的致命鸿沟。FinClaw 作为金融专用 Agent 框架，其核心设计原则是：自然语言到订单执行必须经过三重人闸，且每道闸门的延迟可控、审计留痕。

第一重人闸：指令结构化与限额预检

1. 强制 Schema 转换：所有交易类指令必须匹配预定义的 TradeIntent schema（示例为 TypeScript 类型）：

   interface TradeIntent {
     symbol: string; // 标的代码
     direction: 'BUY' | 'SELL';
     quantityType: 'AMOUNT' | 'SHARES' | 'PERCENT';
     quantityValue: number; // 需配合校验规则
     timeInForce?: 'DAY' | 'IOC';
     notes?: string; // 原始指令文本留存
   }

2. 实时限额检查：在结构化阶段即触发风控接口预检，例如：
3. 单笔交易金额 ≤ 账户当日可用额度 × 动态系数（盘口流动性自适应）
4. 禁止交易 ST 股票等黑名单标的
5. 模糊指令拦截：当模型无法将自然语言指令映射到 schema 时（如「梭哈比特币」），必须返回澄清请求而非猜测用户意图

第二重人闸：双人复核与 STP 边界

• 关键操作分离：订单生成与提交必须由不同角色完成（类似银行 U 盾机制），技术实现上需：
• 使用 JWT 分片签名，生成者和执行者持有不同密钥片段
• 复核界面强制显示原始指令与结构化结果的差异对比
• STP（直通处理）白名单：仅允许对流动性高、波动率低的标的（如 ETF）启用自动执行，且需满足：

  if (symbol in STP_WHITELIST 
      and order_amount < LIQUIDITY_THRESHOLD 
      and not is_market_volatile()):
      execute_stp()
  else:
      require_manual_approval()

• 语音二次确认：对于金额超过 10 万元的指令，MiClaw 语音模块会发起实时通话验证（VAD 检测是否本人声纹）

第三重人闸：回放测试与监管沙箱

• 历史行情回测：用过去 3 年同期的市场数据验证该指令是否会导致异常损失，具体方法：
• 加载指令日期的盘口快照
• 模拟以当时最优 N 档价格成交
• 计算冲击成本与潜在亏损比例
• 辖区差异拦截：例如中国大陆账户不得自动交易加密货币，即使原始指令包含相关词汇。系统维护全球 200+ 个监管区域的限制清单，每日自动更新
• 沙箱执行观察：可疑指令会先在模拟账户执行 24 小时，实际资金变动需人工最终确认

工程实现关键点

1. Langfuse 跟踪链：所有人闸操作生成 OTLP traces，包含：
2. 原始指令文本与结构化耗时
3. 每道闸门的通过/拒绝状态与操作人
4. 最终执行价格与滑点数据
5. 熔断设计：当检测到以下情形时立即冻结账户自动化权限：
6. 单日指令拒绝率 >30%
7. 市场波动率超过预设阈值
8. 监管政策临时变更推送
9. 成本账本：记录每个指令消耗的：
10. Token 数量（API 调用成本）
11. 人工复核工时（换算为货币成本）
12. 执行手续费与滑点损耗

延迟优化实践

通过以下手段将人闸延迟压缩到业务可接受范围： - 预结构化模板：高频指令（如「定投 5000 元沪深 300」）可提前配置为快捷命令 - 异步审批队列：非时效性指令进入批量处理通道，避开人工复核高峰时段 - 自动通过率预测：基于历史数据训练模型，对低风险指令提前生成预批准结果

开发者自查清单

部署金融 Agent 前需确认： ✅ 是否所有交易类工具都声明了 requires_human_gates=3 参数 ✅ 人闸操作界面是否集成二次确认的语音/生物识别 ✅ 是否禁用 eval() 等动态执行功能处理金额字段 ✅ 是否每个环节的决策日志包含完整的 Mermaid 流程图溯源 ✅ 是否设置独立的审计密钥，确保日志不可篡改

金融领域的自动化不是「能不能做」，而是「失控时怎么止损」。FinClaw 的三重人闸设计，本质上是在效率与安全之间寻找最大公约数——让模型理解意图的模糊性，让人承担决策的确定性。