商业银行的Agent化：一场关于协同与工程化的硬仗

2026 年的银行圈，有一个微妙的变化正在发生：高层管理者不再问"我们要不要上 AI"，而是开始问"我们怎么上 AI，才能不被淘汰"。

这个问题比听起来要难得多。银行不是创业公司，不可能在核心系统上推倒重来；银行也不是互联网公司，不可能在风控、合规、审计的重重约束下随意试错。更何况，Agent 化不是上一个系统，而是重塑一套工作方式——它需要业务部门与科技部门的深度协同，也需要工程化能力的长期积累。

本文想讨论的，是商业银行 Agent 化的真实路径：它为什么这么难，哪些因素真正决定成败，以及哪类银行最有可能率先跑出来。

为什么银行的 AI 转型和互联网公司不一样

互联网公司的 AI 转型，本质上是「在已有的技术能力上叠加智能」——搜索加上 LLM 就是智能搜索，客服加上 LLM 就是智能客服，改造成本相对低，迭代速度可以很快。

银行的 AI 转型则完全不同。它面对的是三重约束：

合规约束：模型要可解释，决策要留痕，不能有歧视性定价，出现问题要能追溯到具体决策节点。这些要求不是银行自己加的，是监管明文规定的。这意味着银行没法直接拿一个通用 LLM 跑在核心业务上，必须做大量的「合规适配」。

系统约束：很多大行的核心系统跑在大型机上，接口设计是几十年前的逻辑，API 化程度极低。Agent 要调用这些系统，得先花大量时间做系统改造。这不是 AI 技术问题，是工程化问题。

数据约束：银行数据量大，但「干净可用」的数据远没那么多。历史数据质量参差、私有部署的模型调用成本高、各业务部门之间的数据孤岛严重。很多时候，模型效果不好不是因为算法不行，是因为喂进去的数据本身就是错的。

这三重约束，决定了银行的 Agent 演进必然是「分层推进、步步为营」，而不是互联网式的「一步到位」。

银行 Agent 化的三层架构

根据场景风险等级，银行 Agent 化可以划分为三个层次：

第一层：低风险先行区

这一层主要是内部效率工具，不直接面对客户，也不触碰核心业务决策。

• 文档智能：合同解析、监管报告自动生成、合规审查辅助。这些场景的输出最终由人确认，AI 只负责提效，出错成本可控。
• 内部知识库：政策文件检索、业务流程查询、培训辅助问答。银行有大量内部制度文件和业务规范，这类知识的检索和问答是 Agent 最容易落地的场景之一。
• IT 运维辅助：代码审查、故障排查 Agent，日志分析。这类工具面向的是科技部门自己，迭代速度快，试错成本低。

这一层的价值不只是提效，更是让科技部门积累 Agent 开发、部署、运维的实战经验。这是后续深水区的前提。

第二层：增强型工具区

这一层开始面向业务部门，Agent 以「Copilot」模式辅助人工作，而不是替代人做判断。

• 信贷决策支持：帮助客户经理快速分析企业财报、生成尽调报告摘要、追踪企业舆情。决策权仍在客户经理手中，Agent 只负责把信息整理好、把分析框架搭好。
• 反欺诈辅助：AI 发现异常交易模式，实时推送预警给风控人员，由人判断是否需要拦截或进一步调查。
• 客服 Copilot：AI 实时给客服坐席提供答案建议，人工最终回复客户。这比纯 AI 客服更稳妥，也更容易通过监管审查。

这一层是银行 Agent 化最可能「真正产生业务价值」的地带。核心逻辑是：让人跑得更快，而不是让人消失。

第三层：深水区

这一层涉及模型直接参与业务判断，是 Agent 化的高风险区。

• 小额贷款自动化审批：针对标准化、高频的小额信贷场景，模型可以直接给出审批结论。
• 动态存贷款利率定价：基于客户画像和市场数据，模型参与利率定价建议。
• 投资组合辅助调整：AI 根据市场信号给出组合调整建议，理财经理参考执行。

这些场景的共同特点是：出错成本高、监管关注度高。目前最现实的路径是「人机协同 + 决策留痕」——模型给出建议，最终决策由人签字，审计日志完整保留。

真正的卡点：不是技术，是工程化能力

技术层面，当前的 LLM 在大多数场景已经能跑到 60-70 分。但银行的 Agent 化缺的不是模型能力，而是把模型变成「可部署、可监控、可审计」的企业级产品的工程能力。

核心系统的 API 化是第一道坎。很多银行的核心系统是 90 年代设计的，根本不支持现代 Agent 的调用方式。要让 Agent 能操作账户系统、交易系统、风控系统，就得先做接口改造。这个工作量巨大，且牵一发动全身。

数据治理是第二道坎。Garbage in, garbage out。银行的数据量大，但「干净、结构化、标注好」的数据远没那么多。很多时候科技部门花最多时间的地方，不是调模型 prompt，而是在清洗数据、打通数据孤岛、建立数据质量标准。

合规即代码是第三道坎，也是最容易被忽视的一道。银行 Agent 必须满足监管的审计要求——每个决策要能追溯到具体模型版本、具体输入数据、具体推理路径。这需要的不是模型层面的创新，而是 MLOps 和合规工程化层面的投入。

科技部门：最不坏的选择

说了这么多约束和工程化挑战，银行 Agent 化最终还是要有人来落地实施。科技部门是不是「懂金融」？客观来说，大多数科技部门做的是「需求实现」而非「业务设计」——他们可能对某个系统的局部了如指掌，但对业务全局的视角未必比得上业务骨干。

但这不意味着外部乙方就是更好的选择。恰恰相反，科技部门的价值不在于「懂业务」，而在于三点外部乙方难以复制的东西：

第一，系统全貌的隐性知识。 科技部门多年浸泡在各个系统的对接、数据流转、跨部门协调中——他们知道业务「实际上是怎么跑的」，而不是「文档里怎么写的」。这种隐性知识来自无数次踩坑和扯皮，乙方靠访谈和文档根本学不到。

第二，生产数据的接触权。 科技部门能访问脱敏后的真实业务数据，这是训练和迭代银行垂直 Agent 的必要条件。乙方再强，拿不到真实数据，做出来的东西永远是 demo 级别。

第三，历史债务的承担者。 银行 Agent 化不是在一张白纸上画画，而是要在几十年积累的存量系统上做改造。谁最了解这些历史债务？是科技部门，不是乙方。乙方可以建议推倒重来，科技部门必须接受「带着镣铐跳舞」的现实。

所以科技部门不是「最懂金融」的选择，而是「最有条件把 Agent 化做成功」的选择——前提是它与业务部门真正形成协同。

科技部门的天花板，由协同深度决定

需求定义的职责始终是业务部门的主责——业务目标、业务价值、业务边界，这些判断权不可能也不应该归科技部门。但「需求实现者」和「需求共创者」之间，有一道重要的分水岭。

前者是业务部门把需求文档写好，科技部门照单开发；后者是业务部门提出业务目标和痛点，科技部门从技术可行性和系统架构的角度与业务部门共同打磨——AI 能做什么、风险在哪里、如何分步推进，两边共同判断。

这种协同共进的模式，对业务部门提出了新的要求：愿意了解 AI 的能力和边界，能跟科技部门用同一种语言对话。对科技部门也提出了新的要求：愿意蹲下来理解业务目标和现实约束，而不是拿着技术方案去找业务部门「推销」。

银行 Agent 化最理想的状态，不是科技部门单独冲锋，也不是引入外部乙方包揽一切，而是业务部门与科技部门在需求侧协同共创，在技术侧各有专攻。这条路走通了，银行积累的不只是几个 AI 应用，而是一套「人机协同的业务重构能力」——这才是 AI 时代最有价值的组织能力沉淀。