银行业 AI Agent 的企业级架构——从“服务导向”到“智能导向”的体系化重塑

AI Agent 广泛应用带来的架构级挑战

回顾银行业过去十余年的科技架构演进，从大机下移、SOA 治理到微服务与中台化，其主旋律是走向“服务导向”，旨在解决业务解耦与敏捷交付的难题。然而，随着大模型的成熟与 AI Agent 的崛起，从客户交互到流程执行，再到底层数据支撑，科技体系正面临前所未有的范式更新。

在前期的场景探索中，无论是面向内部赋能的“办公助手”、“客服助手”，还是面向业务增效的“零售营销锦囊”、“对公尽调助手”，我们都遭遇了共性的“落地墙”：前端交互显得生硬反人性、插件生态匮乏导致能力受限、与核心系统对接的边际成本居高不下、跨域数据难以打通、以及 Prompt 工程化管理混乱等。

透过这些表象，我们意识到这已非常规的技术修补，而是深层次的架构级挑战：银行 IT 架构需要从一套确定性的、被动响应的指令执行系统，进化为具备概率性推理、自主规划与主动感知的“智能导向”生态。

具体而言，我们总结了如下层面的挑战：

• 1、交互范式的重塑：从“人找服务”到“服务找人”。银行当前主流的应用模式是“人找服务”式的，银行的各种金融产品如手机银行、网上银行等展示出了层层叠叠的菜单、宫格和导航栏，用户的操作需要分解为界面上一系列的浏览点击，进而对应后台一系列的接口服务。而在 Agent 架构下，交互模式转变为“人机协作”甚至“机器自主”，用户表达意图，Agent 通过对意图的“语义理解”和任务的“推理规划”动态生成服务路径，这样对于金融产品的形态、客户旅程的设计都是新的挑战。
• 2、架构拓扑的演进：从微服务到 Agentic Mesh。微服务架构通过将单体应用拆分为独立部署的服务单元，解决了开发效率和扩展性问题。然而，微服务之间的交互依赖于刚性的 API 契约，缺乏灵活性。当业务需求变化时，往往需要重新编排服务调用链。而 Agent 则不然，它可以身处于“Agentic Mesh”（智能体网格）之中，能够自我描述、自我注册和动态发现，Agent 之间也不是严格的架构层级关系，调用的链路从单向线性变成了多向网状。这种关系将使得底层的服务治理、通信协议和数据交换格式发生大的变化。
• 3、研发运营的变革：从 Devops 到 LLMOps。近些年来，银行科技在研发运营层面大力推进了 DevOps 和 DataOps，但在 Agent 级别缺少新的生命周期管理机制。Agent 的开发不仅涉及代码，还涉及提示词（Prompt）、模型参数、知识库和技能（Skills|Tools）的配置。如何对这些非代码资产进行版本控制、测试和发布？如何构建 Agent 特有的 CI/CD 流水线（即 LLMOps），实现从 Prompt 工程到模型微调的自动化？如何构建合适的评估框架进行非确定性调用测试？如何优化 APM 工具实现对 Agent 思维链中所使用资源的监控？这都是新的课题。
• 4、数据与资产的跃迁：从数据资产到新的数智资产。银行的数据当前以“结构化数据”为主，数据模型承袭于库表思想。所构建的数据资产是企业业务模型的低维静态投影，以服务人的分析为目标，但对大模型和 Agent 并不友好。故而更容易为大模型所用的语义模型开始引人关注，实现方案之一的“本体模型 (Ontology)”成为了新的资产建设目标。此外在 Agent 应用当中的非结构化数据、提示词、知识库、Skill 等新的数智资产也需要进行规范和管理。
• 5、安全与合规的增强：新的防御要求。在传统的漏洞扫描和安全攻击之外，Agent 的应用带来新的威胁，尤其是提示词注入（Prompt Injection）这种因自然语言的边界模糊不清而更难防御的攻击，以及越权访问这种难以觉察的隐患。如何构建新的 Agent 防护栏已经是迫在眉睫的要求。

故而，当前的银行 IT 架构——以结构化数据为底座、以刚性 API 为连接、以偏静态规则引擎为中枢——在面临 Agent 广泛应用时，需要提前思考并应对架构的挑战，从而构建一个既具备高度智能又符合金融级风控要求的 Agent 生态系统。

银行 AI Agent 的架构蓝图

2.1 总体架构视图

基于前面的分析，银行 AI Agent 架构蓝图，不能只考虑模型能力的引入和 Agent 功能的构建，必须进行体系化设计。我们总结出“4+1”的架构蓝图，即一个总体架构视图，包含四个核心横向层次（数据层、平台层、资产层、应用层）以及一个纵向贯穿的安全层，具体结构如下：

2.2 数据层 (Data Layer)：数据模型与本体模型的双模驱动

数据层是 Agent 智能的基石。在传统的数据模型的基础上，银行必须引入本体模型，完成从“Human-Ready”到“AI-Ready”的跃迁。

在实际的权衡上，我们虽然深知全行级的本体模型是目标态，但是实施的成本和推行难度极大。一方面湖仓数据和集群规模体量巨大，部分能力还需要持续建设和运营；另一方面业务部门基于宽表的数据分析中沉淀了大量的经验，尚未形成成熟的本体分析方法论。因此我们的策略是双模驱动，将数据模型的优化和本体模型的局部建设并行推进。

在数据模型层面，主要是保鲜和提质。持续利用 CDC 及流批一体技术，将银行核心资产（账户、交易、余额）实时孪生至数据湖仓中，为 Agent 提供精准、鲜活的“事实”来源；同时通过持续的数据治理，捍卫数据的一致性、完整性与时效性。

在本体模型层面，主要是补齐与建模。一是补齐非结构化数据的存储和处理能力，二是引入金融企业业务本体（FEBO - Financial Enterprise Business Ontology）,构建一套机器可读的业务语义模型。考虑到实施周期和成本，我们优先针对针对客户画像、交易分析等业务领域进行“微本体”建设，其核心步骤包括：

1、语义构建

从业务实体出发，结合已有的数据模型，设计 FEBO 本体模型。既可以将本体模型中的实体、属性、关系等与物理表进行映射，也可以重新设计模型与物理数据进行编织。这样，当 Agent 接收到“查询高风险客户”的指令时，它能通过本体模型理解“高风险”和“客户”的定义，并自动生成正确的 SQL 查询。

2、知识推理

将散落的业务规则、策略以及本体间的约束进行语义化封装，作为本体模型的一部分、或者是独立的业务逻辑层，赋予 Agent“业务逻辑自洽”的能力。例如，本体定义了“某个金融产品只能推荐给风险承受等级高的客户”，当 Agent 进行个性化推荐时，即使没有显式规则，它也能基于本体约束自动推理并校验客户的风险等级，确保业务合规。

2.3 平台层 (Platform Layer)：Agent 开发运营一体化

平台层主要解决 Agent “如何制造”和“如何运行”的问题。

在实际的权衡上，我们深入对比了开源（如 Dify）、商业私有化（如 HiAgent）和 SaaS（如 Coze）三种模式。考虑到我行目前的 AI 平台工程师资源相对紧缺，且行内需求较为旺盛，我们当前采取了“商业软件私有化部署为主，开源技术跟进为辅”的策略。这既能快速获得成熟的工具链和生态能力，快速满足研发态和运行态需求，又能为后续自主掌握和深度定制做好储备。

1、研发态：一站式的 Agent 工厂

（1）可视化编排：提供拖拽式的工作流定义能力，支持将大模型推理、RAG 检索、工具调用等原子能力灵活组装，降低业务人员的开发门槛。

（2）Prompt 工程化：建立 Prompt 的全生命周期管理，支持版本控制、在线调试与 A/B 测试。例如，可直观对比 Deepseek 与千问在同一 Prompt 下的生成差异，辅助模型选型。

（3）自动化评测：内置针对 Agent 的测试集，对回答准确率、响应延迟、Token 消耗等指标进行量化打分，确保上线质量。

（4）敏捷发布：打通现有的 DevOps 流水线，支持 Agent 的容器化部署与独立发布。特别是在上线前增设合规检测卡点，防止潜在的安全风险流入生产环境。

2、运行态：智能调度与可观测性

（1）模型路由：根据任务的复杂度与成本预算，动态选择模型。简单任务路由到低成本的小模型，复杂推理任务路由到大模型，实现“算力成本”与“智能水平”的最优平衡。

（2）任务调度：支持同步与异步双模式。对于生成研报等长耗时任务，自动降级为异步队列处理，保障系统吞吐量。

（3）全链路可观测 ：不仅是对容器、Token 吞吐量的监控，更重要的是对 Agent“思考链” 的完整记录与审计。确保每一个决策步骤都可回溯、可解释，满足金融审计要求。

2.4 资产层 (Asset Layer)：核心数智资产库

这一层是 Agent 架构中区别于传统架构最显著的部分，管理着 Agent 的“大脑”内容。

在实际的权衡上，鉴于当前 Agent 技术生态仍在剧烈演进，我们在资产治理上确立了“集中管控，标准先行”的原则。为了避免各业务条线重复造轮子或形成新的“知识孤岛”，我们暂不鼓励领域级的独立建设，而是构建全行统一的资产库；同时，面对多团队协作的现状，提前制定资产接入的标准化规范，在建设初期就通过形式化约束确保资产的高质量与可复用性。

具体资产包括：

1、提示词库 (Prompts)

Prompt 是 Agent 的源代码。我们建立企业级的 Prompt 仓库，支持：

（1）版本化管理：类似于 Git 的代码版本控制，确保每一次 Prompt 的修改都有迹可循，且可回滚。

（2）模板化：提供通用的 Prompt 模板（如“角色设定+任务描述+约束条件+输出格式”），降低开发门槛。

2、知识库 (Knowledge)

知识库用于存储银行的非结构化知识（制度文档、产品手册、投研报告）并提供向量化检索，同时也是基于本体模型构建的实例填充。

我们使用 RAG (检索增强生成) 进行常规的文本分片和向量检索，进一步可以利用 GraphRAG (图增强检索)，将文档中的实体与关系提取出来构建知识图谱。Agent 在检索时，不仅能找到关键词匹配的片段，还能沿着图谱关系进行多跳推理（Multi-hop Reasoning），从而提升回答的全面性和准确性。

3、记忆体 (Memory)

记忆体是 Agent 维持对话连续性的关键。

（1）短期记忆：管理当前会话的 Context，采用滑动窗口或摘要机制，防止超出 Token 限制。

（2）长期记忆：基于向量数据库存储历史交互信息，并支持将会话中的关键信息（如客户的风险偏好变化）“写回”到 L1 层，实现记忆的持久化，并可经过数据加工完善用户画像。

4、技能库 (Skills)

技能库封装了 Agent 可调用的能力。包括基于服务接口的原子能力，例如：“查询余额”、“冻结账户”等；也包括执行一个业务流程的复杂技能，如“对客户进行尽调分析并给出报告”。这些能力需要标准化封装与分目录呈现，支持被不同的场景复用。

2.5 应用层 (Application Layer)：全渠道触点

包括面向人的统一入口以及面向系统的智能服务。

1、Agent 门户。为银行内部员工和外部客户提供统一的 Agent 交互界面，通过多层权限进行管控。支持多模态交互（语音、文本、图片），并集成了人工介入（Human-in-the-loop）的审核流程。

2. Agent Service。将 Agent 封装为标准的 API 或其他服务（MCP|A2A 等），供手机银行 App、柜面系统、OA 系统以及其他 Agent 调用。通过 AI Gateway 进行流量管理、鉴权和计费。

2.6 安全层 (Security Layer)：纵向支撑

在实际的权衡上，考虑到 Agent 打破了传统边界，安全必须无处不在。从零信任接入到红蓝对抗演练，再到针对 Prompt 注入的全生命周期防护，需要构建动态的防御体系，并渗透在上述所有层级中。

1、数据层安全：数据分类分级、向量数据库的加密存储。

2、模型层安全：输入端的 Prompt 注入检测、输出端的敏感词过滤。

3、应用层安全：基于 RBAC 的权限控制，确保 Agent 只能访问其被授权的数据和工具。

架构中关键组件的建设策略

3.1 平台建设选型

在平台选型上，银行面临着“自主可控”与“功能丰富度”的权衡。我们对主流的三种模式进行了对比评估：

由于银行对于合规性要求较高，一般不选取云端模式，但是上面的方案也不是非此即彼的关系：

1、创新验证域。对于非敏感、不涉及数据出行或需要快速试错的场景（如会议助手、营销文案生成等），可以尝试使用 Coze 等 SaaS 平台，利用其丰富的插件生态快速构建应用，验证可行后再迁移行内。

2、核心业务域。对于科技资源较匮乏的银行，可以使用商业软件私有化部署的方式，实现 Agent 的开发运营。对于科技资源较为充足的银行，可以在行内同时部署开源与商业软件，再分场景应用：对于需要深度定制、有复杂处理逻辑的场景，可以使用开源软件进行研发；对于较简单的功能性 Agent 或者工作流场景，可以使用商业化软件进行快速构建和批量复制。

3.2 连接协议：MCP vs Skills

Agent 如何连接银行庞大的遗留系统和存量 IT 资产，这也是架构中要考虑的问题。

Model Context Protocol (MCP)是由 Anthropic 推出的一种开放标准，存量的服务可以基于它封装为 MCP 资源（Resources）和工具（Tools），从而将系统集成的“网状复杂度（N x M）”降低为“星型复杂度（N + M）”。Skills更侧重于应用层的业务逻辑封装。它定义了完成某项任务的“流程知识”，描述了“如何做”，通常以代码或 Markdown 文件的形式存在。

这两种其实并不是一个层面的东西，可以进行分层协同：

1、底层：利用 MCP 协议标准化封装银行的原子能力，如数据库读写、API 调用。这层关注的是连接性和安全性。

2、上层：利用 Skills 封装复杂的业务流程逻辑。Skill 内部调用底层的 MCP 工具。这层关注的是业务逻辑和可复用性。

3、演进路径：在网关层（Agent Gateway）适配 MCP 协议，使其成为银行内部 Agent 互联互通的标准总线。长期来说更应推进核心系统原生支持 MCP。

3.3 记忆体构建

银行客户的交互往往是跨渠道、跨周期的。Agent 必须具备长时记忆，才能提供连续、个性化的服务。

1、短期记忆：上下文窗口管理。

大模型的 Context Window 是昂贵且有限的资源，可优化的方式包括：

（1）滑动窗口：仅保留最近 N 轮对话，确保 Token 不超限，但可能丢失早期关键信息 。

（2）摘要机制：利用一个小模型对历史对话进行摘要，提取关键事实（如“客户有贷款需求”），保留摘要而丢弃原对话。这在长对话场景中效果更佳。

2、长期记忆：向量数据库与用户画像的融合。

（1）向量数据库：存储历史交互的 Embedding。当客户再次咨询时，Agent 通过语义检索召回相关的历史对话，实现“未卜先知”的体验。

（2）结构化用户画像：这是银行 Agent 记忆体建设的关键。Agent 不仅要“读”记忆，还要能“写”记忆。会话信息和短期记忆数据要进行集中存储与分析，其中的一些客户关键信息（如“我刚生了宝宝”），可以构建新的标签写入数据层的客户画像中，从而增强动态个性化服务的能力。

（3）构建策略：Memory Bank 模式。一般而言，商业化的 Agent 平台软件会自带记忆模块，但从长远看，银行应该构建统一的 Memory Bank 服务。它独立于具体的 Agent 存在，维护着全局的用户记忆图谱。无论是客服 Agent、理财 Agent 还是 App 搜索 Agent，都连接同一个 Memory Bank，确保用户在不同触点获得一致的体验；并可以为其他的业务服务。

3.4 Agent 安全

Agent 的引入打破了传统的网络边界，攻击面从网络层延伸到了语义层。对应的安全机制也需要随之升级。

1、Prompt 注入防御：多层过滤

（1）输入侧：部署专门的“指令分类模型”，识别并拦截试图覆盖系统指令的恶意 Prompt。

（2）隔离沙箱：Agent 执行代码（如 Python 解释器）必须在严格隔离的沙箱环境（Sandbox）中运行，禁止访问外网，限制系统调用，防止恶意代码逃逸

2、业务权限控制：身份认证与人工介入

（1）Agent 在访问受控系统时，至少需要两层权限控制，第一层是 Agent 本身这一个“虚拟用户”是否具备访问系统或者服务的权限，第二层是使用 Agent 的用户对应的身份（如员工或者客户）是否具备访问具体内容的权限。这两部分都需要相关的权限认证。

（2）人工介入（Human-in-the-loop）：对于高风险操作（如大额转账、修改利率），Agent 无权直接执行，必须触发一个审批卡片，由拥有权限的人类主管确认后方可执行

3、数据权限控制：一般认证与差分隐私

（1）Agent 在访问具体数据模型或者本体模型时，应当复用已有的数据控制策略进行访问控制，部分验证还可以委托到业务系统进行，以防止访问越界；

（2）更为复杂的是，Agent 在运转时，可能会把敏感信息发送大模型，或者保留在记忆中，再通过其他的处理或者使用被共享出去。这里的一个做法是，在 Prompt 发送给 LLM 之前，先经过一个个人身份信息过滤器。利用 NLP 技术识别姓名、卡号、手机号，并进行脱敏处理。模型返回结果后，再还原为可读信息来保障敏感数据不落地、不出域。

3.5 待解的困惑

尽管蓝图清晰，上述的策略也已在分阶段实施中，但也确实遇到了一些意料之中与意料之外的困境，这也是我们希望和同业共同探讨的课题。

1、商业产品路径与本地化的矛盾。商业化 Agent 平台的 Roadmap 往往由厂商掌控，这与行内深度的二次定制需求（如特殊的审计逻辑、复杂的权限映射）常发生冲突，如何把握平衡点？

2、资产的属主与管理职责问题。Agent 的资产，如 Prompt、Skills 等的属主如何确定，是业务部门还是科技部门，谁来定标准？资产的管理执行端放在哪个团队，谁来负责全生命周期的维护？

3、记忆体的合规问题。记忆体中数据涉及跨部门（如零售与对公）的客户数据共享。在当前的隐私保护法规下，如何在合规的窄门中实现记忆共享？如何进行记忆体中数据的分类分级？

4、安全的“体验税”。如何在安全防控、建设成本与用户体验这‘不可能三角’中找到平衡点？

组织级的建设团队

Agent 架构的落地无法依靠单一的开发团队，我们组建了包含架构专家、算法工程师、Prompt 工程师与安全专家等的联合战队。

同时，为了解决产能瓶颈，我们以联合团队为核心，将业务人员也催动起来，以用促建，逐步培育 Agent 的生态。

结论

从“服务导向”到“智能导向”架构的演进，也是银行从“数字化”迈向“数智化”的必由之路。以企业级 Agent 架构为指引，逐步解决 Agent 落地过程中的幻觉、安全、集成等工程难题，更能构建起一套能够自我进化、自我优化的企业级智能操作系统。

在这个架构体系中：

• 数据层通过 FEBO 本体实现了对世界的“理解”；
• 平台层提供了强大的“动力”；
• 资产层沉淀了银行的“智慧”；
• 应用层重塑了“体验”；
• 安全层保障了“底线”。

只有系统化地构建这一工程，银行才能真正将 AI Agent 从“演示玩具”转化为驱动业务增长的核心引擎。