银行Agent卡在了真实业务里

作者 | 郑嘉意

Agent的热潮，正在席卷整个银行业。

6月18日的陆家嘴论坛上，农行董事长谷澍、中行行长张辉等多位大行高管分享了对金融Agent的观点；

近乎同日，阿里云副总裁张翅也在中国国际金融展上表态，金融Agent已迎来真正的元年。

从大行的科技规划、大厂的产品策略，到金融科技公司的应用探索，Agent正在成为银行数字化转型的新抓手。

但在银行一线，Agent的真实使用远未达到论坛叙事中的热度。

枢纽调研多家大中型银行发现，出于合规、数据安全和业务流程复杂性考虑，多数银行Agent仍主要停留在研发侧、办公侧或测试环境，距离核心业务流程仍有距离。

在银行语境中，Agent至少包含三层：办公、编程和知识问答类工具；客服、营销、风控等业务辅助工具；以及能够嵌入生产流程、调用系统并参与任务执行的流程型Agent。

当前推进较快的仍是第一类，后两类距离规模化仍有距离。

这构成了银行Agent当下的核心落差：战略叙事已经展开，真实业务仍在门外。

一

业务侧门槛

从流程拆解看，信贷、财富、客服、营销、风控和运营等银行业务，都有被Agent重组的空间；

但金融业务的核心不只是效率，而是授权、审计和追责，只有当Agent接触真实数据、嵌入业务流程并参与任务执行时，业务侧的门槛才真正出现。

这也是银行保持谨慎的根本原因。

来自股份行总行科技部门的陈华（化名）对枢纽透露，公司允许研发人员在测试环境中自由发布各类Agent，但一旦涉及真实场景的运用，审核权限极其严格。

“测试环境肯定是自由的，也就是跑快跑慢的问题。”陈华表示，“但出于安全需求，这些Agent的审核权限最多通过到办公环境，不可能进入业务侧。”

另有多位来自国有行、股份行科技部门人士向枢纽确认，目前真正进入核心业务流程、并参与任务执行的Agent仍然很少，多数尝试仍停留在办公、研发、客服辅助或低风险试点场景。

这种谨慎，源于金融行业本身的复杂性。

神州信息AI创新中心总经理晋梅博士将这种复杂性总结为“严、密、贵”三个字：

一是监管严，敏感数据不能离开行内环境，方案必须私有可控，每一步判断都必须可复现、可审计；

二是业务环节密，金融场景中业务环环相扣，任何一点问题都可能带来风险；

三是人力资本贵，资深员工多年积累的判断力，难以被完整写成规则。

当然，业务侧并非完全没有尝试。

一名国有大行科技部门人士对枢纽透露，公司已经有少量业务类Agent落地，但场景主要集中在个人金融业务和行内办公，形态上更接近客服助手。

该人士坦言，目前Agent开发仍由科技部门主导，“流程大概是让业务部门根据实际情况提报需求，但项目还是由研发部门牵头”。

相较业务侧的谨慎，研发侧的突破要快一些。

多位国有行、股份行科技部门人士对枢纽表示，所在银行已经或准备采购阿里、腾讯的编程Agent，此类Agent主要以内嵌插件形态出现，可以浏览代码上下文、识别Bug、辅助生成代码。

研发侧更容易突破，并不难理解。

编程场景链路清晰、反馈明确，天然比金融业务更容易Agent化，如今OpenAI和Anthropic在Coding领域的竞争，也说明代码生成正在成为Agent最先规模化的方向之一。

但研发侧的突破，并不能直接外推到信贷、财富、风控等核心业务，后者涉及真实客户、资金流转和责任划分，门槛明显更高。

二

场景之外

业务侧是一套能力检验场，银行能否让Agent进入真实业务流程，取决于其是否已经具备承载Agent的基础设施。

自2025年DeepSeek出圈之后，银行业部署本地模型、探索Agent的意愿明显增强。

枢纽注意到，多家国有大行已经在年报中开始强调大模型应用。

在这个过程中，“场景”成了一个高频词：

例如，2025年，某国有大行已经推动大模型落地500余个场景；另一家大行的大模型技术，则赋能集团398个场景应用，渗透财富管理、普惠金融、风险管理、科技研发等领域。

但动辄成百的应用场景，并不等同于Agent基建成熟。

金融科技公司人士黄依丽（化名）向枢纽介绍，部分银行对“场景”的计数方式较为宽泛。

例如，同一套话术优化智能体被分发给私行、财富中心、客户服务等N个部门，就可能被记录为N个场景。

这可能放大大模型应用的表观渗透率。

因为场景数量增加，不代表模型能力更丰富，也不代表应用进入了核心业务链条；

而Agent落地需要的支撑，绝对不只是几个问答助手，而是模型、数据、系统、权限、流程、审计和评测机制之间的连接。

更关键的数据是未被披露的使用频次和活跃度，相比场景数量，它们更能反映AI工具是否真正被一线员工接受。

黄依丽表示，目前银行为了数据安全，大多选择完成模型的私有化部署。

“但有的管理者要追求模型私有化，会选择参数较小的模型。”她表示，“银行在安全和好用之间选择了安全，代价就是使用频率下降。”

黄依丽透露，在一线试点调研中，许多员工表示鲜少使用行内研发的话术优化类Agent，认为其使用体验不如外部免费的豆包、DeepSeek。

由此来看，银行Agent的现实进展仍然迟缓。

战略表述积极，业务侧谨慎；场景数量增加，实际体验仍需验证。

这些落差共同指向一个问题：限制Agent进入业务侧的，已经不只是模型能力。

真正的难点，开始从模型部署转向组织协同。

三

组织困局

过去开发软件产品时，银行的路径相对清晰：科技部门与技术公司对接，向业务部门调研需求，再分析、研发、交付，最后将产品交由业务部门使用。

但Agent承载的是业务判断力和经验，而这些东西本身就在不断演进。

一位金融科技公司人士用“运维”和“运营”来概括二者的区别：传统软件更像运维，重在稳定运行；Agent更像运营，重在持续反馈、训练和校准。

该人士指出，传统软件和Agent的成本投入阶段不同：

前者成本集中在建设期，后续主要是维护和修复；后者前期可以很快跑出原型，但真正成熟依赖持续的业务反馈、用户训练和迭代。

该人士总结称，“所以好的Agent开发，需要业务、产品、研发从第0天就持续坐在一起”。

但部分银行一线员工对于Agent的抵触，最直观地反映了现实的困难。

黄依丽表示，“从业务部门牵头、收集需求开始，有些员工的积极性就很低。科技部门满腔热情想设计出Agent，但收回来的问卷对于需求的描述只有寥寥几个字。”

这类反馈并不只是技术接受度问题，更像是岗位价值重估带来的防御性反应。

Agent不是简单帮客户经理减负，它也在改写客户经理原本用来证明工作价值的方式。

一家股份行的科技部门主管的观察给出了更具体的答案。

该主管表示，在引入零售多智能体系统后，客户经理在信息整理、制度查询等事务性工作上耗时显著缩短，系统生成的资产配置方案草案减少了重复文书。

但效率的提升表象下，隐藏着更深层的组织挑战，一些员工欢迎系统带来的便捷，也有人担心自身价值被替代；

更根本的是，当系统接管了信息整合和基础方案生成后，客户经理的核心价值本应向审核、优化、关系维护迁移，不少银行的考核指标没有同步调整。

“银行现有的培训体系和KPI考核中，对于电话数量、报告数量的要求，还没有调整。”该主管表示，“这导致员工即使有空闲时间，也不知该往何处发力，或不愿改变既有工作习惯”。

该主管表示，公司正在设计新的“人机协同”培训方案和考核指标，但也深感闭门造车之难。

这意味着，Agent落地不只是技术上线，还会触及岗位定义、评估体系和激励机制，已超出科技部门单独能解决的范围。

四

复制难题

在这样的困局中，协同创新提供了一种突破的可能。

晋梅表示，其团队曾与一家区域性银行共创业务侧Agent。对方提供资深理财顾问评判AI答案，也安排新员工验证效果，双方先用模拟数据打磨，再进入现场部署。

在她看来，金融业务反馈链条长，要让Agent迭代形成足够快的闭环，业务和技术就必须频繁互动。

但即便成功共创，Agent又可能会面临新的困境：难以复制。

枢纽了解到，如今有大量中小银行对业务侧Agent有诉求，但组织架构不支持进行费时费力的共创，他们最常问的问题是：别人家的Agent已经落地了，我能直接买过来用吗？

答案往往是否定的。

一个成功Agent的背后，往往嵌入了特定银行的业务规则、数据结构、风险偏好和权限体系。

它在A银行跑通，并不意味着能直接迁移到B银行；

即便在同一家银行内部，从零售理财复制到对公信贷，也常常需要重新建模和验证。

一位股份行的科技部门主管用“场景墙”来形容这个困境。

该主管表示，公司曾成功将零售业务的多智能体架构应用在理财和基金场景，但当试图向对公信贷场景复制时，立刻撞上了困难。

例如，对公信贷与零售业务的规则、文档和决策链条差异明显：输入材料从客户画像变成财报、合同和流水，系统也需要对接核心账务、信贷审批等更复杂的流程；

原有智能体几乎无法直接迁移，业务逻辑和数据模型都要重建。

该主管认为，如今的银行仍缺少跨场景描述业务能力的“元语言”，也就是一套能把不同业务流程抽象成可复用模块的表达方式。

这也解释了为什么，不少第三方公司以项目制、系统集成或定制服务交付Agent，而不是像传统SaaS那样标准化销售。

一位金融科技公司人士表示，所在团队曾为客户开发经营贷Agent，用于辅助客户经理评估商户资质，但这类能力通常只是整体项目中的子模块，并不单独售卖。

对银行而言，真正有价值的不是通用Agent外壳，而是对具体业务约束的长期适配。

但这种模式，也可能天然限制规模化。

大行有资源推进共创，但流程链条长、跨部门协同成本高；中小银行需求更迫切，却未必有组织和预算承接复杂共创，最终，Agent在供需两端都存在错位。

要真正突破规模化困局，需要行业层面的共同努力。

谷澍指出，行业对智能体的定义和规范标准尚未统一，不利于科学评估各家机构的应用水平。

据此，他建议先建立“标准件”：把功能单一、业务流程固定的智能体做成标准化产品，同时聚焦开发具备自主规划和决策能力的智能体。

只有查询、摘要、提醒、资料核验等流程固定、风险较低的能力先标准化，Agent才可能从单点项目变成可复用组件。

五

治理先行

协同创新可以改变工作方式，行业标准可以促进规模化，但这一切的前提是：Agent必须被有效地治理。

目前，金融机构在这个问题上还缺乏统一答案。

当一笔交易经过Agent推荐、人工确认后发生纠纷，责任如何在模型建议、人工确认和业务审批之间划分？

如果监管追问决策依据，银行能否通过审计日志复现Agent的输入、输出、工具调用和人工干预节点？

这不仅是技术问题，更是法律和治理问题，行业缺少一套统一的、能让合规与科技部门对话的智能体决策审计标准。

谷澍在论坛上指出，金融应用中Agent可能存在“黑箱、幻觉、自主决策”等风险，这些都需要分类施策的治理思路来应对。

对银行来说，Agent能否进入核心业务，最终取决于治理框架是否先立起来。

晋梅强调，这套框架至少包括四件事：

第一是权限边界，明确Agent能查询什么、调用什么，能否触发交易或审批动作。

第二是责任边界，明确AI建议、人工确认、业务审批之间如何划分责任。

第三是审计边界，记录Agent的输入、输出、调用链条和人工干预节点，确保关键流程可追溯。

第四是评测边界，为不同场景建立不同验收标准，单看回答准确率并不足以衡量Agent效果。

因此，治理不只是合规框架，也会反向推动岗位、考核和激励机制调整。

换言之，治理不是为了限制Agent，而是为了让Agent获得进入业务侧的资格。

对银行而言，Agent的分水岭不会出现在发布会上，而会出现在真实业务流程里。

只有当它能够被授权、被审计、被追责，并被一线员工持续训练和使用时，才算真正进入银行业务。

*本文为枢纽Ledger（ID：gh_21d64eee348b）原创作品，全天候科技经授权转载，如需转载，请联系原作者。

点“在看”，变好看哦。