1. 金融 Agent 到底在重构什么1.1 从“工具”到“同事”金融 Agent 的定位跃迁过去几年金融机构对 AI 的期待基本停留在“提效工具”层面——OCR 识别票据、NLP 做舆情监控、规则引擎跑反洗钱。这些场景有一个共同特征AI 只负责一个环节做完就交还给人类。但金融 Agent 的出现打破了这个边界。它不再是一个被动等待调用的函数而是一个能自主规划、调用工具、串联流程、甚至主动发起任务的“数字同事”。我所在的团队从 2023 年底开始接触金融 Agent 的落地项目最初的想法很简单能不能让 Agent 自动完成一份信贷尽调报告的初稿结果发现一旦 Agent 接入了企业工商数据、财报解析、舆情接口、内部风控规则库它产出的东西已经不只是“初稿”而是一份带推理链路、带数据溯源、带风险标注的半成品。人类分析师的角色从“写报告的人”变成了“审报告的人”。这个变化看似微小实则触及了金融机构最核心的东西工作如何重组价值如何分配。一个 Agent 能顶三个初级分析师那这三个人的去向是什么Agent 产出的报告署名权归谁如果 Agent 调用外部模型厂商的 API数据主权怎么界定这些问题不解决Agent 就永远停留在 POC 阶段。1.2 金融场景为什么是 Agent 的“硬骨头”金融行业对 Agent 的要求和其他行业有本质区别。电商客服 Agent 说错一句话顶多赔个优惠券金融 Agent 说错一句话可能触发合规审查甚至监管处罚。这就决定了金融 Agent 必须满足三个硬性条件可解释性每一步推理都要有依据不能是黑盒。监管问起来你得说清楚“为什么给这个企业打 72 分而不是 68 分”。可追溯性Agent 调用了哪些数据源、经过了哪些中间步骤、最终输出基于哪条规则全链路要留痕。可干预性人类必须能在任意节点介入暂停、修改、回滚。不能像某些通用 Agent 那样“一口气跑完错了重来”。我见过不少团队拿着通用 Agent 框架直接往金融场景套结果卡在合规评审上动弹不得。原因很简单通用框架的默认设计是“最大化自动化”而金融场景的第一性原理是“最小化不可控风险”。这两个目标在架构层面就是冲突的。1.3 谁在推动这场重组四股力量的博弈金融 Agent 的落地不是某一家的事而是四股力量在博弈中寻找平衡参与方核心诉求对 Agent 的态度关键动作金融机构降本增效、风险可控谨慎乐观先试点后推广建内部 Agent 平台锁定数据不出域模型厂商扩大 API 调用量、占领生态位激进推广强调通用能力推出金融垂直版本降价抢市场Agent 开发方快速交付、可复制夹在中间既要满足合规又要控制成本做行业模板抽象通用层监管方穿透式管理、责任可界定观望中逐步收紧要求算法备案、输出留痕这四股力量的拉扯直接决定了金融 Agent 的“生意”怎么做。模型厂商想让你多用 API但金融机构想的是“核心数据不能出内网”开发方想快速复制但每个金融机构的合规要求都不一样。最后的结果往往是Agent 跑在金融机构的内网里调用的是私有化部署的模型开发方提供的是可配置的流程模板。2. 工作重组谁被替代谁被增强谁被创造2.1 被替代的环节标准化信息处理先说最直接的影响。金融行业里有大量工作是“读材料、填表格、做比对”比如信贷审批中的财报数据录入与交叉验证反洗钱中的可疑交易报告初筛投研中的公告摘要与财务指标提取合规中的合同条款比对与风险点标注这些工作的共同点是输入格式相对固定输出标准明确判断逻辑可以用规则描述。这正是 Agent 最擅长的领域。我实测过一个财报解析 Agent接入 PDF 解析、表格识别、科目映射、勾稽关系校验四个模块后一份 200 页的年报从上传到生成结构化财务数据耗时 4 分半准确率在 95% 以上。人工做同样的工作熟练分析师也需要 2 小时。但这里有个关键细节Agent 替代的是“操作”不是“判断”。它能告诉你“应收账款周转天数从 45 天上升到 67 天”但“这个变化意味着什么、要不要调整授信额度”仍然需要人来拍板。所以被替代的环节准确说是“信息搬运和初步加工”而不是“决策”。2.2 被增强的环节复杂判断与客户交互Agent 对中高级岗位的影响是“增强”而非“替代”。我观察到的几个典型场景场景一投研分析师的“第二大脑”。一个分析师覆盖 30 只股票每天要读几十份公告、研报、新闻。Agent 可以帮他做三件事第一实时监控持仓股票的相关信息按重要性排序推送第二对每份新公告做初步解读标注“超预期/符合预期/低于预期”第三当分析师提出一个假设比如“这家公司毛利率提升是因为产品结构优化”Agent 能快速拉取历史数据做验证。分析师的效率提升不是 20%而是能覆盖的股票数量翻倍。场景二理财经理的“超级助理”。理财经理最头疼的是“客户太多、需求太杂、产品太复杂”。Agent 可以在客户来访前自动生成一份客户画像最近三个月持仓变化、风险偏好漂移、关注过的产品类型、上次沟通的遗留问题。理财经理拿到这份材料沟通效率完全不同。更关键的是Agent 可以在沟通中实时提示“客户提到的这个需求对应三款产品分别是……”把理财经理从“记忆和检索”中解放出来专注于“建立信任和促成交易”。场景三风控人员的“规则实验室”。传统风控规则更新周期长因为每次调整都要跑历史数据回测。Agent 可以把这个过程压缩到小时级输入一个新规则自动跑过去三年的数据输出通过率、坏账率、误杀率的变化甚至能给出“规则阈值调到多少最优”的建议。风控人员从“跑数的人”变成“定策略的人”。2.3 被创造的岗位Agent 训练师与流程编排师每次技术变革都会创造新岗位金融 Agent 也不例外。我目前看到的两类新角色Agent 训练师不是写代码而是“教 Agent 理解金融业务”。具体工作包括整理业务规则文档、标注训练数据、设计 Prompt 模板、评估 Agent 输出质量、反馈 bad case。这个岗位需要的是懂业务 懂 AI 边界的复合型人才。我认识的一个训练师之前是信贷审批员现在专门负责“教” Agent 识别各种财报造假手法。她的优势是知道“哪些地方容易出问题”这是纯技术背景的人不具备的。流程编排师金融 Agent 很少单打独斗通常是多个 Agent 协作。比如一个信贷流程可能涉及资料收集 Agent、财报分析 Agent、舆情监控 Agent、规则校验 Agent、报告生成 Agent。流程编排师的工作是设计这些 Agent 之间的协作关系谁先谁后、什么条件下触发、异常怎么处理、人类在哪个节点介入。这个岗位有点像“导演”需要同时理解业务逻辑和技术边界。2.4 重组后的团队形态小前台 大中台 强后台我观察到的一个趋势是金融机构的团队结构正在从“金字塔型”向“哑铃型”演变前台变小一线业务人员数量减少但每个人负责的客户数增加因为 Agent 承担了大量事务性工作。中台变大Agent 开发、训练、运维、合规审查等岗位集中在中台成为核心能力部门。后台变强数据治理、模型管理、安全审计等后台职能的重要性提升因为 Agent 的运转依赖高质量数据和严格管控。这个变化对个人的启示很明确要么往前台走成为“会用 Agent 的业务专家”要么往中台走成为“懂业务的 Agent 专家”。夹在中间、只会做标准化操作的岗位压力会越来越大。3. 价值分配钱从哪里来到哪里去3.1 成本结构拆解一个金融 Agent 的钱花在哪很多人以为 Agent 的成本就是“调用大模型的 API 费用”实际远不止。我拆解过一个中等规模信贷 Agent 项目的成本结构成本项占比说明模型推理成本25%包括私有化部署的 GPU 折旧或 API 调用费数据接入与治理30%对接工商、司法、舆情、内部系统数据清洗和标准化Agent 开发与调优20%Prompt 工程、流程编排、工具开发、测试合规与审计15%算法备案、输出留痕、人工复核环节运维与监控10%系统稳定性、异常告警、版本管理这个结构说明一个关键问题模型不是最贵的数据和合规才是。很多团队在 POC 阶段只算了模型成本觉得“很便宜”一到生产环境发现数据对接和合规改造的费用是模型的好几倍。3.2 模型厂商的生意从卖 API 到卖“金融能力包”模型厂商在金融 Agent 生态里的角色正在变化。早期大家拼的是“模型参数多大、跑分多高”现在金融机构关心的是“你能不能帮我解决具体问题”。我观察到几个趋势趋势一垂直版本溢价。通用模型 API 价格战打得厉害但金融垂直版本经过金融语料微调、内置金融工具调用能力的价格通常是通用版本的 3-5 倍。金融机构愿意付这个溢价因为省去了自己微调的成本。趋势二从 API 到 Agent 平台。头部模型厂商不再只卖 API而是提供“Agent 开发平台 预置金融工具 合规组件”的一站式方案。这个策略的意图很明显锁定生态位。一旦金融机构的 Agent 跑在你的平台上迁移成本就很高了。趋势三私有化部署的博弈。大型金融机构坚持私有化部署模型厂商则希望“混合模式”——敏感数据本地处理通用推理走云端。这个博弈的结果直接影响模型厂商的营收模型私有化是一次性 license 收入云端是持续性 API 收入。3.3 金融机构的账省了多少赚了多少金融机构算账的逻辑和模型厂商不一样。他们不看“API 调用量”看的是单位业务成本和风险损失变化。我参与过的一个项目信贷审批 Agent 上线后几个关键指标的变化单笔审批耗时从 4.2 小时降到 1.1 小时下降 74%审批人力投入从 3 人/天降到 1 人/天下降 67%审批通过率从 68% 提升到 73%因为 Agent 能处理更多维度的数据不良率从 2.1% 降到 1.7%因为 Agent 的风险识别更一致这些数字背后是实打实的钱。但金融机构在评估时还会算另一笔账Agent 出错的代价。如果 Agent 漏掉一个风险点导致坏账损失可能抵消掉几个月的效率收益。所以金融机构在 Agent 上线前通常会设置一个“人机双审”的过渡期这个期间成本反而上升。3.4 开发方的生存空间做“脏活累活”还是做“标准产品”Agent 开发方在价值链里的位置比较尴尬。往上模型厂商在推平台化方案试图把开发方变成“平台上的配置员”往下金融机构的定制化需求无穷无尽每个项目都像从零开始。我看到的几种生存策略策略一做垂直场景的标准化产品。比如专门做“财报解析 Agent”或“舆情监控 Agent”把单个场景做深做透形成可复制的模板。这种策略的关键是选对场景需求足够普遍、标准化程度足够高、合规风险足够低。策略二做“最后一公里”的集成服务。金融机构内部系统复杂Agent 要真正跑起来需要对接大量遗留系统。这个“脏活累活”模型厂商不愿意干金融机构自己干成本太高正好是开发方的机会。策略三做 Agent 运维和调优。Agent 上线只是开始后续的 Prompt 调优、bad case 修复、规则更新是持续投入。很多金融机构没有这个能力需要外部团队支持。这个模式的好处是收入持续坏处是规模不经济。4. 实操落地一个金融 Agent 项目的完整复盘4.1 项目背景与目标设定去年我参与了一个股份制银行的“对公客户风险监控 Agent”项目。背景是该银行有 2000 对公客户客户经理每月需要手动排查风险信号工商变更、司法诉讼、舆情负面、财报异常平均每个客户耗时 15 分钟一个月就是 500 小时的工作量。目标是用 Agent 自动完成 80% 的排查工作客户经理只处理高风险信号。项目周期 3 个月团队配置1 个项目经理、2 个 Agent 开发、1 个数据工程师、1 个银行业务专家兼职、1 个合规顾问兼职。预算控制在 80 万以内不含模型私有化部署的硬件成本。4.2 技术选型与架构设计技术选型上我们做了几个关键决策模型选择没有用最大的模型而是选了一个 70B 参数的开源模型做私有化部署加上一个 7B 的小模型做意图识别和路由。理由金融场景对“通用智能”要求不高对“稳定性和可控性”要求极高。大模型虽然能力强但推理成本高、输出不稳定不适合高频调用的场景。Agent 框架没有用市面上流行的通用 Agent 框架而是基于 LangChain 做了一层封装。核心考虑是通用框架的抽象层次太高很多细节不可控。比如工具调用的超时处理、异常重试、输出格式校验通用框架的默认行为不一定符合金融场景要求。架构设计采用“主 Agent 子 Agent”的模式。主 Agent 负责接收任务、拆解步骤、调度子 Agent子 Agent 各自负责一个数据源或一个分析维度。这样设计的好处是每个子 Agent 可以独立测试、独立替换、独立监控。# 简化的主 Agent 调度逻辑伪代码 class RiskMonitorAgent: def __init__(self): self.sub_agents { business_change: BusinessChangeAgent(), legal_risk: LegalRiskAgent(), sentiment: SentimentAgent(), financial: FinancialAgent() } def analyze(self, company_id): results {} for name, agent in self.sub_agents.items(): try: result agent.run(company_id, timeout30) results[name] result except TimeoutError: results[name] {status: timeout, risk_level: unknown} except Exception as e: results[name] {status: error, message: str(e)} # 汇总各子 Agent 结果生成综合风险评分 return self.aggregate(results)4.3 数据接入的坑与解法数据接入是项目中最耗时的环节没有之一。我们对接了 6 个数据源工商数据、司法数据、舆情数据、财报数据、内部信贷系统、内部客户关系系统。每个数据源都有各自的“脾气”工商数据接口返回的是 JSON但字段命名不规范同一个含义在不同接口里叫法不同。解法是建了一个字段映射表把 200 个字段统一成标准命名。司法数据数据量大全量拉取不现实。解法是做增量同步每天凌晨拉取过去 24 小时的变更加上一个“重点客户全量刷新”的机制。舆情数据噪音大一条负面新闻可能只是转载。解法是加了一个“去重和权威性排序”的预处理步骤只保留原始来源和高权威媒体的报道。内部系统最大的坑。内部系统的 API 文档不全有些接口还有隐藏的限流。解法是找内部系统负责人喝了三次咖啡拿到了真实的调用限制和字段说明。实操心得数据接入阶段一定要留足时间至少占项目周期的 40%。不要相信任何“接口文档”一定要实际调用测试。我习惯在项目启动第一周就写一个“数据源健康检查”脚本每天跑一次记录每个数据源的可用性、响应时间、数据量变化。4.4 Prompt 设计与输出控制金融 Agent 的 Prompt 设计和通用场景有本质区别。通用场景追求“创造性”金融场景追求“一致性”。我们的 Prompt 模板遵循几个原则原则一输出格式强制约束。每个子 Agent 的输出必须是 JSON字段名和类型预先定义好。如果模型输出不符合格式自动重试或降级处理。原则二推理链路显式要求。Prompt 里明确要求“先列出你参考的数据再给出判断最后给出风险等级”。这样做的目的是可解释客户经理能看到 Agent 为什么这么判断。原则三不确定性显式表达。如果数据缺失或矛盾Agent 必须输出“数据不足建议人工核查”而不是强行给一个判断。这个设计一开始被业务方吐槽“不够智能”但后来成了最受欢迎的功能——因为它避免了 Agent “一本正经地胡说八道”。# Prompt 模板示例简化版 RISK_ANALYSIS_PROMPT 你是一个对公客户风险分析助手。请基于以下数据分析该客户的风险状况。 数据 - 工商变更{business_change_data} - 司法诉讼{legal_data} - 舆情信息{sentiment_data} - 财务指标{financial_data} 要求 1. 先列出你参考的关键数据点至少 3 条 2. 逐项分析每个维度的风险信号 3. 给出综合风险等级低/中/高/未知 4. 如果数据不足或矛盾明确说明 输出格式JSON {{ referenced_data: [..., ...], dimension_analysis: {{ business: ..., legal: ..., sentiment: ..., financial: ... }}, overall_risk: 低/中/高/未知, reasoning: ... }} 4.5 人机协作界面的设计Agent 的输出最终要给人用界面设计直接影响落地效果。我们踩过的坑坑一信息过载。第一版界面把所有 Agent 输出都展示出来客户经理反馈“比我自己查还累”。第二版改成“风险信号卡片”每个卡片只显示最关键的信息点击展开详情。坑二操作路径太长。客户经理看到风险信号后需要“确认/忽略/转人工”三个操作。第一版把这些按钮放在页面底部客户经理要滚动才能看到。第二版改成悬浮操作栏随时可点。坑三反馈闭环缺失。客户经理的“确认/忽略”操作没有回流到 Agent 训练中。第三版加了一个反馈收集机制客户经理的每次操作都记录下来用于后续的 Prompt 调优和规则更新。4.6 上线后的效果与意外发现项目上线 3 个月后的数据风险排查覆盖率从 60% 提升到 100%之前客户经理只排查重点客户平均排查耗时从 15 分钟/客户降到 3 分钟/客户客户经理只处理高风险信号高风险信号发现数从每月 45 个提升到每月 78 个Agent 能发现人忽略的信号客户经理满意度4.2/5.0主要扣分项是“偶尔误报”意外发现有几个发现一Agent 改变了客户经理的行为模式。以前客户经理是“想起来才查”现在是“每天上班先看 Agent 推送的风险清单”。这个变化带来的风险防控效果比 Agent 本身的准确率更重要。发现二Agent 的输出成了“培训材料”。新入职的客户经理通过阅读 Agent 的风险分析报告快速学习风险识别的方法。这个价值是我们之前没预料到的。发现三数据质量问题的暴露。Agent 上线后很多之前被忽略的数据质量问题浮出水面。比如某个内部系统的客户行业分类字段有 30% 是空的或错误的。这个问题之前没人关注因为人工排查时会“用常识补全”但 Agent 不会。5. 常见问题与排查技巧实录5.1 Agent 输出不稳定怎么办这是金融 Agent 最常见的问题。同一个客户今天跑出来是“高风险”明天跑出来是“中风险”。原因通常有三个原因一模型推理的温度参数设置过高。金融场景建议把 temperature 设到 0 或 0.1牺牲一点“创造性”换取一致性。原因二数据源本身在变化。比如舆情数据每天更新今天多了一条负面新闻风险等级自然变化。解法是在输出中标注“数据截止时间”让用户知道这是基于哪个时间点的判断。原因三Prompt 中的示例不一致。如果 few-shot 示例里类似的案例给了不同的风险等级模型就会困惑。解法是定期审查 few-shot 示例确保逻辑一致。5.2 工具调用失败怎么处理Agent 调用外部工具如工商数据接口时失败是常态。我们的处理策略失败类型处理策略用户感知超时重试 2 次间隔 1 秒无感知只是稍慢接口返回错误码记录日志降级处理该维度显示“数据获取失败”数据格式异常尝试解析失败则跳过该维度显示“数据异常”限流排队等待超过 30 秒则降级该维度显示“数据延迟”关键原则单个工具失败不能导致整个 Agent 崩溃。每个子 Agent 都要有独立的异常处理逻辑。5.3 如何评估 Agent 的输出质量金融 Agent 的质量评估不能只看“准确率”要分维度看完整性该分析的数据维度是否都覆盖了一致性相同输入是否产生相同输出可解释性推理链路是否清晰、可追溯时效性从数据更新到 Agent 输出延迟是否可接受鲁棒性数据缺失或异常时是否能优雅降级我习惯建一个“黄金测试集”人工标注 100 个客户的风险等级每月用 Agent 跑一遍对比准确率变化。这个测试集不参与训练纯粹用于监控。5.4 合规审查的常见卡点金融 Agent 上线前通常要过合规审查几个常见卡点卡点一算法备案。如果 Agent 涉及“自动化决策”比如自动拒绝贷款需要进行算法备案。解法是尽量把 Agent 定位为“辅助决策”最终决策权保留在人类手中。卡点二数据出境。如果 Agent 调用了外部模型 API数据可能出境。解法是私有化部署或者使用境内模型厂商的服务。卡点三输出留痕。监管要求 Agent 的每次输出都要可追溯。解法是建一个日志系统记录每次调用的输入、输出、中间步骤、时间戳。卡点四责任界定。如果 Agent 给出错误建议导致损失责任归谁解法是在用户协议中明确“Agent 输出仅供参考最终决策由人类做出”。实操心得合规审查最好在项目启动时就介入不要等到上线前才找合规部门。我见过太多项目因为合规问题延期数月甚至直接夭折。提前沟通的好处是合规顾问可以帮你设计“合规友好”的架构而不是事后打补丁。6. 这个生意接下来怎么走6.1 短期趋势从“单点 Agent”到“Agent 网络”接下来一年我判断金融 Agent 的形态会从“单个 Agent 解决单个问题”向“多个 Agent 协作解决复杂问题”演变。比如一个完整的信贷流程可能涉及 10 个 Agent资料收集、财报分析、舆情监控、规则校验、风险评估、报告生成、合规审查……这些 Agent 之间需要协作、需要共享上下文、需要处理冲突。这对开发方提出了新要求不仅要会做 Agent还要会做 Agent 之间的编排和通信。目前这块还没有标准方案是机会也是挑战。6.2 中期变量模型能力提升会吃掉多少 Agent 开发工作一个必须面对的问题是随着模型能力提升很多现在需要“Agent 编排”的工作未来可能模型直接就能做。比如现在需要多个子 Agent 协作完成的任务未来一个大模型可能一次推理就搞定了。这对 Agent 开发方的影响是简单的流程编排价值会下降复杂的业务理解和合规适配价值会上升。换句话说如果你做的只是“把几个 API 串起来”护城河很浅如果你做的是“理解金融业务规则并转化为 Agent 可执行的逻辑”护城河就深得多。6.3 长期格局金融 Agent 会成为基础设施吗我的判断是金融 Agent 最终会像今天的“风控系统”一样成为金融机构的基础设施。它不会是一个独立的产品而是嵌入到各个业务流程中的能力层。就像今天没人会说“我们银行有一个风控系统”而是说“我们的信贷流程里有风控环节”。这个判断如果成立意味着现在的“金融 Agent 生意”只是一个过渡形态。最终活下来的要么是提供基础设施的平台方模型厂商或大型金融科技公司要么是深耕某个垂直场景的服务方比如专门做财报解析、专门做反洗钱。夹在中间的“通用 Agent 开发方”生存空间会被挤压。6.4 给从业者的几个建议如果你正在或准备进入金融 Agent 领域几个个人体会第一业务理解比技术能力更重要。我见过技术很强的团队因为不懂金融业务做出来的 Agent 业务方不愿意用。也见过技术一般但业务理解深的团队做出来的 Agent 虽然“不酷”但业务方离不开。第二合规不是障碍是护城河。很多团队把合规当成负担但换个角度想合规要求越高能进来的玩家越少。如果你能帮金融机构解决合规问题你就有了议价权。第三从小场景切入快速验证价值。不要一上来就做“信贷全流程 Agent”先做一个“财报解析 Agent”或“舆情监控 Agent”用 1-2 个月跑通拿到业务方的反馈再扩展。第四关注“人机协作”而不是“完全自动化”。金融场景的容错率太低完全自动化在短期内不现实。设计一个好的“人机协作”界面让 Agent 做它擅长的让人做只有人能做的这个组合的落地效果最好。最后分享一个我在项目中总结的小技巧每次 Agent 输出错误时不要只修 Prompt要问“这个错误反映了什么业务规则的缺失”。很多时候Agent 犯错不是因为模型不行而是因为业务规则没有被显式地表达出来。把业务规则整理清楚Agent 的准确率自然就上去了。这个工作看起来慢但一次整理长期受益。