2. 金融智能体基础
在讨论安全护栏与权限控制之前，必须先建立对金融智能体本体的清晰认知。金融智能体并不是“会聊天的模型”，而是以大模型为推理内核、以工具调用为行动手段、以记忆与规划为持续能力的软件实体。它被嵌入到账户、交易、风控、投研等真实业务链路中，因此其架构决定了风险从哪里来，也决定了护栏应该装在哪里。
一、核心原理：金融智能体的四层架构
从工程视角看，一个可落地的金融智能体通常由四层构成，自下而上分别是模型层、能力层、编排层与接入层。模型层提供语义理解、推理与生成；能力层把金融系统封装为可调用工具，如账户查询、额度计算、行情获取、工单创建；编排层负责规划、任务分解、工具选择与结果整合；接入层则面向柜面、App、客服坐席或内部运营平台。
理解这一分层的关键在于：风险不是均匀分布的。模型层主要带来幻觉与越权建议风险；能力层直接触碰资金与数据，是权限控制的主战场；编排层容易出现“多步组合越权”，即单步都合规、组合起来却违规；接入层则涉及身份冒用与渠道伪造。护栏必须按层布防，而不是只在入口做一次校验。
二、核心组件与协作流程
把架构落到组件，金融智能体一般包含六类核心部件：身份与上下文管理器（确定“谁在什么场景下发起”）、规划器（把目标拆成步骤）、工具注册表（声明可用能力及其参数模式）、执行器（真正发起调用）、记忆库（短期会话与长期偏好）、审计与策略引擎（记录与拦截）。
一次典型请求的流转如下：用户提出“帮我查一下这张卡近三个月的大额消费并生成说明”，身份管理器先绑定客户号与坐席权限；规划器拆为“查询交易—筛选大额—生成说明”三步；工具注册表返回可用工具及参数约束；执行器逐条调用；策略引擎在每次调用前校验权限与金额阈值；审计组件落库全链路日志。可以看到，权限校验点应设在执行器之前，而不是模型输出之后，否则越权调用已经发生。
三、金融场景中的典型应用
金融智能体的落地场景高度集中在“高频、规则明确、需多系统协同”的环节。下表列出四类典型应用及其权限敏感度，便于后续设计差异化护栏。
| 应用场景 | 核心能力 | 涉及数据/资金 | 权限敏感度 |
|---|---|---|---|
| 智能客服与工单 | 意图识别、知识检索、工单创建 | 客户基本信息、历史工单 | 中 |
| 账户与交易查询 | 账户检索、流水筛选、汇总说明 | 账户余额、交易明细 | 高 |
| 信贷与额度辅助 | 资料核验、额度试算、风险提示 | 征信、收入、授信额度 | 极高 |
| 投研与行情解读 | 行情获取、指标计算、报告生成 | 公开行情、内部研报 | 中低 |
以“账户与交易查询”为例，智能体需要调用核心系统的查询接口。若工具注册表中该接口未声明“仅限本人账户”约束，模型可能因上下文混淆而查询他人账户。这类问题无法靠提示词根治，必须在工具层做参数级白名单。
四、风险特征与常见误区复盘
金融智能体的风险与通用智能体有本质差异，主要体现在四点：一是资金不可逆，一次错误支付无法像文本一样撤回；二是强合规约束，数据访问需留痕、可追溯、可解释；三是权限边界刚性，坐席、客户、管理员的能力集合必须严格隔离；四是多步组合风险，单步合规的组合可能突破业务规则。
常见误区二：只在入口做一次身份校验。智能体多轮调用中身份上下文可能被覆盖或继承错误。
常见误区三：工具粒度过粗。一个“账户操作”工具同时包含查询与转账，等于把高风险能力暴露给低权限场景。
复盘一个真实教训：某智能体在测试中表现良好，上线后却出现坐席通过多轮对话逐步诱导，最终让智能体调用了超出其权限的额度调整接口。根因不是模型“变坏”，而是工具注册表未按角色做能力裁剪，且执行器缺少二次校验。修复方案是：在工具注册表中为每个工具标注所需角色与参数约束，并在执行器前增加策略引擎校验，同时把每次调用写入审计日志。
# 工具注册表示例（角色约束）
tool: query_transaction
roles: [customer, agent, admin]
params:
account_id: must_equal(context.bound_account)
date_range: max_days=90
tool: adjust_credit_limit
roles: [admin]
params:
amount: max=50000
require_approval: true
理解架构、组件、场景与风险特征，是后续设计护栏与权限模型的前提。金融智能体的安全不是附加功能，而是架构的一部分：能力越强，约束越要前置。只有把权限、审计与策略引擎作为一等组件嵌入，智能体才能在真实金融业务中可控地运行。