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 的分水岭不会出现在发布会上，而会出现在真实业务流程里。

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