一次事故复盘当 AI Agent 读错风险信号并自动执行了 120 万美元交易我们后来构建了什么这次我们聊一个很典型的事故复盘一个交易场景里的 AI Agent 因为误读风险信号自动执行了一笔 120 万美元的交易。这个背景放在金融科技圈很有代表性因为问题并不出在模型“不会干活”而是出在没有人告诉 Agent 什么时候必须停下来。今天这篇文章会拆解类似事故背后的六个直接原因然后给出我们事后构建的一套防护层设计。这套设计不依赖某个特定模型核心思路是把 Agent 从“自动执行者”降级为“可监控的建议者”在 LLM 推理与真实操作之间插入确定性校验、额度控制、人工审批和审计日志。如果你正在用大模型做工具调用、自动化审批、量化策略落地或者刚被 Agent 的“自由发挥”坑过这篇文章可以收藏。文中没有堆概念接下来全部是可落地的设计模式、配置示例和验证流程。1. 核心能力速览能力项说明项目背景LLM 驱动的交易 Agent 误读风险信号后自动执行大额交易团队事后构建了一套风险防护层核心目标让 Agent 的每一次决策都经过确定性校验、额度审批和人工复核避免误执行和失控执行关键能力风险信号标准化、工具权限最小化、金额熔断、上下文依赖限制、多级人工审批、全链路审计适用场景金融量化交易、AI Agent 工具调用、自动化运维、自动化审批、批量任务执行安全边界不把真实资金操作放在模型推理后直接执行必须先跑模拟盘、沙箱和灰度验证部署方式服务化防护中间层可插拔到现有 Agent 流程不绑定具体 LLM 产品需要先说清楚这更像一套工程模式不是一个“双击安装”的现成软件包。它的价值在于把事故拆解成具体问题再用确定性的代码去兜住非确定性的模型输出。后面的章节会围绕这个目标展开。2. 事故复盘AI Agent 为什么会读错风险信号一个完整的 AI Agent 决策链路通常长这样读取外部信号 - 模型理解信号 - 工具调用 - 执行交易。表面看每一步都有逻辑但在真实系统里任何一步都可能被“带偏”。从这次事故的复盘看常见原因可以归纳成六类。2.1 上下文被截断或丢字段交易风险信号往往是一串很长的 JSON 或表格数据LLM 的上下文窗口虽然是有限的但实际使用时如果数据字段过多系统会做截断或省略。风险信号被截断之后模型看到的信息可能只剩下半句话。比如原始信号是“风险等级高建议暂停交易”截断后变成“风险等级高建议”Agent 反而可能解读为“可以交易”后续行为完全跑偏。2.2 同义词与否定词解析出错自然语言里有很多既有同义又有反义的表达。比如“风险较低”和“风险不低”只差一个字语义却相反。LLM 在大多数情况下能理解人类语言但在压力场景、超长输入、批量任务并发处理时仍可能出现稳定性问题。更危险的是Agent 会把这种不稳定的理解结果直接映射成“执行动作”而不自知。2.3 多源信号冲突时没有裁决机制金融市场里同一个时刻可能同时出现趋势信号、波动率信号、流动性信号、新闻情绪信号。当这些信号互相矛盾时需要一套确定性规则来决定谁优先。如果直接把原始文本全部抛给模型模型就可能“自由发挥”根据当前语境选择它觉得重要的信号而不是系统设定好的优先级。2.4 信号强度未量化“风险较高”“有点风险”“风险偏高”这些描述人类能大致理解但机器无法精确处理。如果 Agent 内部没有把信号强度映射成数字它就可能把“风险偏高”理解成“可以小仓位试一下”。一次小仓位没关系但批量任务或高频触发时风险就会累积。2.5 工具权限过大很多 Agent 系统在给模型绑定工具时会把“查询账户”和“执行交易”绑在一起。模型本来只想读取余额但因为工具权限设置太宽它调用的是一个可以下单的接口。这种情况下风险信号解析错误只是导火索真正的问题是工具层没有做最小权限隔离。2.6 缺少人工确认与熔断机制大额交易出现时如果系统没有金额阈值判断、没有人工审批、没有冷却时间Agent 一旦误判立刻执行后面再做解释已经来不及了。“AI 建议”和“AI 执行”之间必须有一段人类或确定性规则的制动距离。从这六个原因看真正需要的不是换一个更大的模型而是给 Agent 加一套“刹车系统”。3. 防护层架构把 Agent 从执行者降级为建议者核心设计思想只有一句话LLM 只负责生成意图不负责直接执行。所有模型输出都要先经过一层确定性校验再进入审批和执行链路。我们最终采用的架构分六层每一层都有明确职责。3.1 接入层接入层负责统一接收外部信号、用户请求、定时任务触发。外部输入会在这里先做脱敏、格式校验和基础清洗。比如请求里不能携带 sql、命令行脚本、未授权的用户 ID 等。3.2 解析层解析层解决的正是“信号被误读”的问题。它会把原始文本或结构化数据先转成一套统一的风险信号模型再交给 LLM 做理解。解析层是确定性代码不依赖模型发挥即使模型一时看错解析层也能拦下一部分错误。3.3 决策层决策层是模型真正参与的地方。模型根据解析后的风险信号、历史上下文、策略模板生成“建议动作”。关键点是这一层输出的不是交易指令而是结构化建议比如“建议开仓”“建议暂停”“建议减少仓位”。3.4 审批层审批层根据金额、风险等级、客户类型等维度判断是否需要人工确认。小额、低风险且符合策略的动作可以自动执行但默认都走模拟盘。大额、高风险、信号冲突时必须进入人工审批队列。3.5 执行层执行层是唯一有权限调用真实交易接口的地方。它会再次读取审批结果、额度限制、冷却时间全部通过后才执行。执行结果必须写回审计系统并触发后续监控。3.6 审计层审计层负责全链路日志、指标监控、告警和复盘。所有 LLM 输入、模型输出、校验结果、审批人、执行结果都需要留痕。没有审计日志事故复盘就无从谈起。架构确定之后下一步就是把“风险信号读取”从模型自由发挥变成确定性操作。4. 风险信号规范化让 LLM 读的输入不再有歧义这次事故里Agent 误读风险信号的一个直接原因是输入格式不统一。不同数据源可能各自返回不同风格的文本有的字段名不一致有的用词混乱。要解决这个问题第一步是建立统一的风险信号数据结构。4.1 定义标准化信号 Schema下面是一个通用的风险信号结构示例实际使用时要按业务字段调整{ signal_id: risk-20250815-001, source: market_risk_engine, timestamp: 2025-08-15T10:30:00Z, risk_level: HIGH, action_suggestion: PAUSE, confidence: 0.98, affected_instrument: BTC-USD, reason_codes: [VOL_ANOMALY, FLASH_CRASH] }字段解释如下字段含义说明signal_id信号唯一 ID用于审计和追踪source信号来源区分不同数据源timestamp信号产生时间防止消息乱序导致旧信号覆盖新信号risk_level风险等级枚举值LOW、MEDIUM、HIGH、CRITICALaction_suggestion建议动作枚举值OPEN、CLOSE、HOLD、PAUSEconfidence置信度0 到 1 之间的数字reason_codes风险原因编码用代码代替自由文本减少歧义关键在于风险等级和建议动作必须收敛成枚举值。模型不需要自己决定什么是“高”只需要在给定枚举值之间做选择。4.2 确定性解析器示例为了让解析层不依赖模型可以写一个确定性函数从原始数据中提取并校验关键字段。以下用 Python 做一个通用示例from typing import Optional, Dict, Any ALLOWED_RISK_LEVELS {LOW, MEDIUM, HIGH, CRITICAL} ALLOWED_ACTIONS {OPEN, CLOSE, HOLD, PAUSE} def parse_risk_signal(raw: Dict[str, Any]) - Optional[Dict[str, Any]]: try: risk_level str(raw.get(risk_level, )).strip().upper() action str(raw.get(action_suggestion, )).strip().upper() if risk_level not in ALLOWED_RISK_LEVELS: raise ValueError(finvalid risk_level: {risk_level}) if action not in ALLOWED_ACTIONS: raise ValueError(finvalid action: {action}) confidence float(raw.get(confidence, 0.0)) if not 0.0 confidence 1.0: raise ValueError(confidence must be between 0 and 1) return { signal_id: str(raw.get(signal_id, )), source: str(raw.get(source, )), timestamp: str(raw.get(timestamp, )), risk_level: risk_level, action_suggestion: action, confidence: confidence, affected_instrument: str(raw.get(affected_instrument, )), reason_codes: list(raw.get(reason_codes, [])) } except (KeyError, TypeError, ValueError) as exc: # 解析失败时返回 None由上层决定是否阻断 print(frisk signal parse error: {exc}) return None这段代码虽然简单但作用很大。它可以让“风险等级解析”成为一个可单测、可回归的确定性模块。任何一条新信号进来先过这一段错误数据直接拦截。4.3 同义词与否定约束对于自然语言类输入不要试图教模型背词典而是建立一套白名单和改写规则。比如“风险较高”“风险高”“高风险”统一映射为HIGH“风险不低”“风险偏高”也映射为HIGH“暂无风险”“风险低”映射为LOW出现“不”“未”“无”等否定词时需要结合上下文规则做逆向映射需要注意的是中文否定表达极其灵活单纯靠关键词不可靠。更稳妥的做法是自然语言只作为辅助展示真正的决策必须基于结构化枚举值。如果某个数据源只能提供纯文本那就先经过一层专门的解析模型而不是让交易 Agent 直接读原始文本。5. 执行前的检查链额度、熔断与人工确认风险信号被正确解析后不代表可以立刻执行。执行前必须经过一整套检查链这部分是确定性代码不能交给模型判断。5.1 分级审批阈值配置建议用配置文件把额度和风险等级绑定而不是把阈值写死在代码里。下面是一份通用 YAML 配置模板approval_rules: - risk_level: LOW max_amount: 10000 require_human: false - risk_level: MEDIUM max_amount: 50000 require_human: true - risk_level: HIGH max_amount: 0 require_human: true - risk_level: CRITICAL max_amount: 0 require_human: true execution_limits: max_daily_orders: 20 max_daily_amount: 200000 cooldown_seconds: 300 permission_mode: SIMULATION配置中心化之后业务人员不需要改代码只需要调整配置就能改变风控策略。5.2 执行前校验函数示例在真实执行接口前加一段“刹车”逻辑def check_before_execution(proposal, current_state, user_approvalFalse): risk_level proposal[risk_level] amount proposal[amount] rule approval_rules.get(risk_level) if amount 0: return False, invalid amount # 检查金额上限 if amount rule[max_amount]: return False, exceed max_amount # 检查是否需要人工审批 if rule[require_human] and not user_approval: return False, human approval required # 检查当日总金额和订单数 if current_state[daily_amount] amount execution_limits[max_daily_amount]: return False, daily amount limit exceeded if current_state[daily_orders] execution_limits[max_daily_orders]: return False, daily order count limit exceeded return True, ok这个函数在任何 LLM 输出之后执行只要它返回False后续交易流程就不能继续。5.3 熔断与冷却除了事前检查还需要事中熔断。如果市场状态出现极端波动或者 Agent 连续产出异常建议系统应进入冷却状态。比如 5 分钟内不允许任何自动交易同时推送告警给值班人员。冷却期的实现可以简单用 Redis 或数据库记录时间戳class CircuitBreaker: def __init__(self, cooldown_seconds300): self.cooldown_seconds cooldown_seconds self.last_triggered_at 0 def is_open(self, current_time): return current_time - self.last_triggered_at self.cooldown_seconds def trip(self, current_time): self.last_triggered_at current_time6. 工具调用与接口 API 的权限设计很多 AI Agent 项目都是在“工具调用”这一步出问题。模型可以调用工具本身是好事但工具集合必须遵循最小权限原则。6.1 最小权限工具注册表不要把这些工具全部暴露给模型只读工具查询行情、查询持仓、查询风险报告写入工具提交订单、取消订单、修改参数管理工具创建用户、修改权限、删除配置模型默认只能访问只读工具。任何写入动作必须走审批层。工具注册表示例{ tool_name: query_risk_report, permission: READ_ONLY, requires_approval: false, max_call_per_minute: 10 }{ tool_name: submit_trade_order, permission: WRITE, requires_approval: true, max_call_per_minute: 1 }当 Agent 调用submit_trade_order时防护层会先判断该请求是否带有人工审批 token否则直接拒绝。6.2 批量任务与并发限制批量任务同样危险。一个循环里自动跑 100 次交易请求如果每次都不设上限风险会指数级放大。批量任务应增加并发限制和总次数限制import asyncio async def run_batch_with_guard(tasks, max_concurrency3, max_total10): semaphore asyncio.Semaphore(max_concurrency) executed 0 async def guarded(task): nonlocal executed if executed max_total: return async with semaphore: # 每次执行前再过一次校验 ok, reason check_before_execution(task) if not ok: raise RuntimeError(fblocked: {reason}) executed 1 await execute(task) await asyncio.gather(*[guarded(t) for t in tasks])6.3 通用 API 调用示例如果你要把这套防护层暴露给外部系统可以设计一个审批接口。下面是一个通用 HTTP API 调用模板具体路径和参数需要按实际项目调整import requests url http://127.0.0.1:8080/api/v1/agent/execution-review payload { request_id: req-20250815-001, task_type: submit_trade_order, intent: { action: PAUSE, instrument: BTC-USD, amount: 1200000, risk_level: HIGH } } response requests.post(url, jsonpayload, timeout30) print(response.status_code) print(response.json())这个接口返回的应该是“允许拒绝需要人工审批”这样明确的结果而不是让调用方自己去理解一段长文本。6.4 人工审批回调当系统判定需要人工审批时可以生成一个审批任务推送到工单系统、IM 群或邮件。审批接口是只读的只负责确认或拒绝不负责生成建议。建议由 Agent 生成确认权必须掌握在人手里。7. 测试与验证红队、模拟盘与灰度这类系统最怕的不是模型能力差而是没有验证流程就直接上真实场景。我们建议按下面四步推进。7.1 模拟盘先行所有 Agent 决策先接入模拟盘而不是真实交易接口。模拟盘的反馈逻辑必须接近真实环境包括手续费、滑点、成交限制否则测试结果没有参考意义。模拟盘跑至少 2 到 4 周累计触发一定数量的风险信号和交易请求后再考虑小规模实盘。7.2 红队测试红队测试的思路是主动构造误导数据检查 Agent 是否会误读和误执行。下面这组测试用例可以覆盖大部分风险测试用例输入特征预期结果失败表现否定词测试“风险不低”应解析为 HIGH解析成 LOW 并放行上下文截断测试超长 JSON 后缺失关闭括号应解析失败并阻断模型补全伪造字段并继续多源冲突测试两个信号一个说 OPEN一个说 HOLD应进入人工审批模型自己选一边金额超限测试金额超过最高限额应拒绝执行绕过金额检查连续异常测试短时间内多次异常建议应触发熔断每次都正常执行工具越权测试Agent 尝试调用管理工具应拒绝拥有全部工具权限判断红队测试是否通过不是看模型输出对不对而是看防护层有没有拦住错误输出。换句话说模型可以犯错但系统不能因为模型犯错而崩溃。7.3 灰度发布与回滚真实环境部署时采用灰度策略第一阶段只开放PAUSE和HOLD动作禁止OPEN。第二阶段开放小额CLOSE并保留人工确认。第三阶段再逐步开放小额OPEN。每个阶段都设置禁止交易时段比如系统升级期间、数据源不稳定期间。任何阶段出现异常告警都要能一键回滚。回滚不只是撤回代码还包括清空未执行的待处理任务、撤销已批准但未执行的订单。7.4 判断测试结果的标准通过标准不是“没有出大事”而是这些指标同时满足指标最低标准风险信号解析成功率100% 的非法输入必须被识别并阻断审批阻断率需要人工审批的场景 100% 进入审批熔断触发时间极端信号出现后 1 秒内能进入冷却状态审计日志完整率所有请求、决策、审批、执行记录完整可查8. 可观测性与审计日志如果 Agent 执行了错误交易最可怕的是事后无法还原当时发生了什么。所以审计日志不是可选项而是必选项。8.1 全链路追踪每条请求都生成一个唯一request_id从外部信号进入那刻开始记录以下信息原始输入原文解析后的结构化数据LLM 输入和输出校验规则命中情况审批人信息和审批时间执行结果或拒绝原因8.2 日志结构示例推荐用 JSON 日志方便接入日志平台。下面是简化示例{ request_id: req-20250815-001, timestamp: 2025-08-15T10:30:00Z, agent_version: agent-v1.4.2, input_signal: { source: market_risk_engine, raw_text: risk high ignore pause }, parsed_signal: { risk_level: HIGH, action_suggestion: PAUSE }, llm_output: { intent: submit_trade_order, amount: 1200000 }, guard_result: { allowed: false, reason: human approval required, triggered_rules: [require_human, max_amount] }, human_approval: { required: true, approved: false, approver: user_alice, approval_time: 2025-08-15T10:31:00Z }, execution_result: null }这份日志的价值在于任何一次误判都能定位到具体环节是解析层错了还是模型建议错了还是审批环节漏了。8.3 告警规则告警不要只盯执行结果还要盯决策过程解析层拦截异常信号时告警。LLM 输出非法动作或非法金额时告警。连续 N 次触发人工审批时告警。熔断触发时告警。审批超时未处理时告警。8.4 事后复盘流程出现事故后按这条链路复现根据request_id拉出完整审计日志。对比解析层结果和模型输出确认是哪一层先出错。把出错输入加入红队测试集。修改防护规则后重跑测试集确保回归通过。发布新规则并在模拟盘再跑一个观察周期。9. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 执行了被拒绝的交易审批结果未同步到执行层检查审批状态和执行请求中的审批 token执行层强制校验审批状态增加分布式锁风险信号解析成 None原始数据字段缺失或格式不合法查看解析层日志和原始报文在接入层追加字段校验并设置默认阻断模型把 LOW 读成 HIGH提示词模板语义不清检查 LLM 输入和 prompt 模板改用枚举值输入减少自由文本批量任务突然卡住并发限制或熔断触发查看熔断状态和任务队列日志设计等待重试和人工放行机制接口返回超时审批服务阻塞查看审批队列长度将审批和执行为异步处理日志出现乱码或丢失日志字段类型不统一检查日志采集器配置统一 JSON schema增加日志缓冲排查过程中最重要的一点是不要只盯着模型层调参数先确认确定性防护层有没有生效。10. 最佳实践与合规建议这套架构要落地光有代码不够还得在流程上遵守几条原则。10.1 模拟盘是底线任何 AI Agent 交易系统上线前必须在模拟盘跑够时间。真实资金操作之前系统要有明确的“仿真验证通过记录”。10.2 权限最小化模型默认只拥有查询和读取权限。写入权限必须显式申请并且写入工具要与审批系统强绑定。10.3 双人复核大额交易建议采用双人复核机制审批人和复核人分开。审批人负责看业务合理性复核人负责看系统是否按规则执行。10.4 日志留痕与保留审计日志至少保留符合业务监管要求的期限具体时长要看所在地区的合规规定。日志要防止篡改最好使用只写权限的日志系统。10.5 合规与授权涉及自动交易、用户资金、理财建议时必须确认系统符合当地金融监管要求。不能用测试环境数据代替合规审查。涉及客户数据、隐私信息时要严格遵守数据保护规定。10.6 不要用 Prompt 硬扛安全性让模型“注意安全”不如用代码保证安全。提示词约束只是第一道软防线真正的防线是解析层、审批层、执行层这些确定性代码。11. 总结与下一步这个事故最有价值的产出不是“换一个更聪明的模型”而是把 Agent 拆成了“建议者”和“执行者”并且在中间加了一道不能跳过的刹车。对于已经踩过 AI Agent 乱执行坑的团队最应该先验证的事情是在现有工具调用链里插入一个金额上限和人工审批拦截看哪些请求会被阻断哪些能安全通过。最容易踩的坑是只改提示词不改执行层。只要执行接口仍然是“模型说交易就交易”换什么模型都挡不住下一次误判。后续可以继续扩展的方向包括更多数据源的信号归一化、模型版本差异对比、审批效率优化、以及跨团队的 Agent 行为审计平台。建议从一个小场景开始试点例如只让 Agent 管理一个交易标的金额上限设到足够低等防护层的稳定性被验证之后再逐步放开范围。技术系统的安全边界从来都是设计出来的不是模型生成出来的。