Agent 金融场景：先把权限、审计和人工审批做起来，再谈投顾自动化
金融 Agent 最容易被写成一个自动赚钱或自动风控的黑盒，但真正能落地的，通常是把研究、合规、欺诈排查和人工审批串成受控流程。
01.金融 Agent 最危险的误区，是把它当成自动决策机器
金融场景里，大家最容易被吸引的想象通常是：
- •自动给出买卖建议
- •自动调仓
- •自动识别所有欺诈
- •自动完成合规审查
但真实金融系统里，问题从来不只是“答案对不对”，而是：
- •这个建议依据了什么数据
- •谁对这个建议负责
- •是否满足适当性、授权和审批要求
- •模型有没有越权访问账户或执行动作
- •结果能不能被审计、解释和追责
所以金融 Agent 更适合被设计成“受控的研究与流程协作者”，而不是替代受监管决策链路的自动黑盒。
02.先选一个低权限、可审计的切入点，而不是直接碰交易执行
如果第一版就想做“AI 投顾 + 自动下单 + 自动风控”，项目通常会在权限、责任和审计要求上很快失控。
更现实的切入点通常是：
- •研究资料整理和摘要
- •客户问答与流程引导
- •欺诈或异常线索初筛
- •合规文档比对和检查清单
以“投研与合规助手”为例，一个可交付的第一版通常已经很有价值：
- •汇总公开披露文件和内部研究资料
- •生成结构化研究摘要
- •标记缺失证据和高风险表述
- •输出给分析师或合规人员复核
- •不直接给出交易指令，不直接触发资金动作
这样的链路更容易在真实团队里落地，也更符合审计和留痕要求。
03.一条可上线的金融链路，通常由四层组成
1. 资料与事实层
这一层负责把系统能合法、合规使用的数据准备好，例如：
- •公告与财报
- •客户已授权的账户信息
- •交易流水与异常日志
- •内部政策、适当性规则、审批流程
如果事实层不清楚，后面的总结和判断就没有可靠基础。
2. 分析与分类层
这一层更适合让模型发挥：
- •识别客户问题属于哪一类
- •总结长文档和风险提示
- •把非结构化材料整理成待审核项
- •生成欺诈调查或合规排查的初步清单
它的价值更像“降低人工检索和整理成本”，而不是替代金融判断。
3. 控制与审批层
这一层决定系统是不是可上线。常见要求包括：
- •是否命中授权范围
- •是否需要双人审批
- •是否涉及客户适当性判断
- •是否涉及资金划转、下单或高风险变更
这类动作不能只凭模型输出推进，必须由系统规则和审批流程显式控制。
4. 监控与追责层
金融场景尤其重视：
- •留痕
- •审计
- •版本记录
- •例外处理
如果 Agent 做了摘要、建议或异常标注，但后面无法追踪它看过哪些数据、调用了哪些工具、谁批准了动作，这条链路就很难进入正式环境。
04.模型负责整理和提醒，系统负责权限和动作控制
在金融场景里，一个更稳的职责拆分通常是：
更适合模型处理的部分
- •理解客户问题
- •总结研究材料和风险披露
- •提取合同、公告或规则里的关键点
- •生成异常调查的初步解释
更适合系统处理的部分
- •控制账户和资金权限
- •校验是否满足适当性和审批条件
- •限制工具调用范围
- •记录审计日志和版本信息
- •决定是否允许进入执行环节
如果让模型同时负责“分析 + 建议 + 执行”，最后最先失控的就是权限边界。
05.用结构化计划把任务和权限先锁住
相比直接让模型给出投资建议或风险结论，我更建议先让它输出一个受限的任务计划，再由系统控制后续动作。
from typing import Literal
from pydantic import BaseModel, Field
class FinancePlan(BaseModel):
lane: Literal["research", "fraud_triage", "compliance_review", "handoff"]
subject: str
evidence_ids: list[str] = Field(default_factory=list)
risk_level: Literal["low", "medium", "high"]
requires_human_approval: bool = True
allowed_actions: list[str] = Field(default_factory=list)
def run_finance_workflow(plan: FinancePlan, tools):
evidence = tools.fetch_authorized_records(plan.evidence_ids)
draft = tools.generate_summary(plan.lane, plan.subject, evidence)
checks = tools.run_control_checks(plan.allowed_actions, plan.risk_level)
if checks.blocked or plan.requires_human_approval:
return tools.route_to_supervisor(draft=draft, checks=checks)
return tools.prepare_controlled_action(draft=draft, checks=checks)这个模式的价值在于：
- •先区分当前是在做研究、欺诈初筛还是合规审查
- •可访问的数据和允许动作可以被显式限制
- •高风险任务默认进入人工审批
06.欺诈和异常检测，别做成“模型拍脑袋判断”
金融团队很容易把 Agent 想成一个万能反欺诈引擎。但真实风险排查里，更稳的链路通常是：
- •规则、统计模型或图谱系统先发现异常
- •Agent 帮忙整理关联记录和时间线
- •人工调查员确认是否为可疑行为
也就是说，Agent 更适合做：
- •汇总证据
- •解释为什么被标红
- •生成调查摘要
- •推荐下一步核查动作
而不是单独决定“这个客户一定有问题”或“这笔交易一定违规”。
07.面向客户的回答，必须比内部问答更保守
很多金融 Agent 项目一开始先做聊天入口，但如果它面对的是客户而不是内部员工，风险会立刻升高。
因为它一旦输出：
- •收益承诺
- •误导性比较
- •未披露风险
- •不符合客户情况的建议
后果会远比内部摘要错误更严重。
所以客户侧 Agent 更适合先做这些事情：
- •产品资料检索
- •流程解释
- •风险揭示
- •转接到人工持牌人员
而不是直接做个性化投资建议生成器。
08.审计日志不是附属品，而是主功能
金融场景里，很多团队把“模型效果”看得太重，却把审计留到最后补。实际顺序应该反过来。
至少要能回答这些问题：
- •这次输出用了哪些资料
- •模型版本是什么
- •调用了哪些工具
- •谁审批了最终动作
- •哪一步被人工改写过
只有这样，出了问题时系统才能复盘，也才能持续改进。
09.评估不要只看回答速度，要看合规和误伤成本
金融 Agent 的评估，不应该只问“总结得快不快”或“回复像不像分析师”，更应该看：
- •高风险输出拦截率
- •越权动作阻断率
- •人工复核发现的问题类型
- •欺诈初筛的误报与漏报
- •客户问答中的误导性表述率
这类指标比表面上的对话流畅度更接近真实业务价值。
10.三个常见误区
1. 直接把 Agent 接到下单或资金操作
只要没有充分审批和权限隔离，这就是把模型不确定性直接放大到资金层。
2. 把研究摘要误当成投资建议
摘要可以帮助专业人员提效，但不能自动等价为面向客户的正式建议。
3. 没有留痕，却想做正式金融流程
缺少审计、版本记录和审批链，系统几乎无法进入真正受监管的业务环境。
11.总结
金融 Agent 真正可交付的方向，不是做一个“自动赚钱”的智能顾问，而是把原本分散在研究、排查、合规和审批里的工作组织成一条受控流程：
- •先限定数据和权限
- •让模型承担检索、整理和提醒
- •让系统负责规则、审批和执行控制
- •把最终建议和动作留在人工负责的链路里
只要把这几层边界守住，Agent 才能在金融场景里真正创造效率，而不是把风险从人工环节转移到一个更难解释的黑盒里。