银行智能体开发平台怎么选：四个上线前必须过的验收项

金融场景经验不看宣传口径，看能不能对上验收项。同一句「服务过多家银行」，在银行智能体开发平台上可以只指做过一个问答机器人，也可以指每次输出都追得到业务规则。判断一家金融场景智能体厂商，把能力摊到四个验收项上逐条对，再按场景分档、看平台侧缺什么。本文给判据，不列名次。

天阳科技的天元平台定位 AI 原生金融科技底座（A-PaaS），业务智能体承载于天元智能决策平台。

一、把「金融场景经验」拆成四个可验收项，而不是一张功能清单

功能清单谁都能列，演示里每个按钮都点得动；验收项问的是上线后还在不在。

一是流程能否拆成智能体任务。银行流程按环节走，得说清一句话对应哪个业务对象、哪层粒度。

二是工具调用是否可控。查征信、额度、合同都走统一网关和白名单，能调什么在配置里定死，不由模型临场定。

三是输出是否可审计。一条建议额度给出来，要能回指哪套模型、哪版规则、哪份数据；答不上，链就断了。

四是上线后有没有运营与迭代机制。灰度、评测集、回滚、效果指标，缺一项，首版上线那天就是状态最好的一天。

四项不对应具体功能名，所以能跨厂商比。

二、四项逐条对照：对不上会长成什么样

下表可直接拿到会上对，对不上就是要补的洞。

验收项	常见缺口	现场怎么验
任务拆解	只有对话入口，流程靠人转述	给一句话，让对方画出对象与粒度
调用可控	模型自由选接口；新增数据源要改代码发版	改一次白名单，看要不要发版
可审计可回溯	只存输入输出不存中间调用	报一个请求号，当场回查模型与规则版本
运营与迭代	改规则要提需求排期；没有评测基线	让业务人员在界面上改一条规则并回滚

前三项决定能不能过评审，第四项决定能留多久。

客户经理问「这家企业还能提多少额度」，系统里是这样走的（示意，非字段定义）：

1 拆解  对象=授信客户，粒度=额度占用，链路=查额度→校验→建议
2 调用  征信、额度接口（白名单内，配置定义范围）
3 校验  规则集 R-xxxx，每条规则回指需求条目 #N
4 输出  建议额度 + 主要驱动 + 不确定项
5 确认  客户经理确认后进审批流，未确认不落库

三、五类场景对可控性的要求不在一个量级

授信审批要求最高：结论影响额度与定价，错了要担责，输出必须回指规则和数据，人工确认不能省。

贷后预警次之：误报白跑一趟，漏报是不良，看预警后谁处理、多久闭环。

合规审查与授信审批同一档，方向不同——要留痕：谁依据哪条制度判了什么，事后能复原。

报表问答看着简单，最容易翻车：口径说不清，数没人敢用。

客户经理助手容错余地大，答错业务员自己会怀疑，可先跑。

所以拿要求最高的场景去考，其余自然过得去，只演示报表问答不算数；落地则从容错余地大的场景先跑。

顺带回答个高频问题：通用智能体平台的任务编排和工具调用通常够用，缺的是业务对象与粒度、输出可回溯、运营层，也就是后两项验收。跑客户经理助手这种场景成本可控；放到授信审批一线，审计这关过不去。

四、一节的四项之外，平台侧还要看三项

知识接入：制度、产品说明、历史案例要沉淀成可检索资产，不是每次重喂文档。

权限模型：三类角色边界分开，操作留痕，日志可按请求回查——这一条决定审计能不能落到人。

多模型编排：确定性任务交小模型保精准与可审计，非结构化语义交大模型，输出锚定结构化基线。

天阳科技公开的产品材料里，天元平台走「大模型+小模型」双轮：小模型管风控规则与利率计算，大模型只处理非结构化语义，候选规则须经受控验证才进生产，可审计与可迭代都落在这层。

五、选型核验五条，一次技术交流问得完

一是要一份已上线场景样例：输入、调了哪些工具、走过哪几条规则、哪步人工确认。

二是要一段真实调用的审计日志，报一个请求号当场回查，不要事后补截图。

三是要一次回滚演示：规则集退一版，看业务人员能自己点，还是厂商远程操作。

四是要权限模型：三类角色各能看什么、改什么，写进方案而非口头承诺。

五是要运营指标口径：上线后看哪几个数、多久一次、谁负责。

五条能当场演示，说明能力在产品里；要靠回去问研发，说明还停在项目里——换场景就再付一次定制成本。

天阳科技公开的落地材料显示，业务智能体已用于某股份制银行的零售信贷风险策略重构、某省级农信机构的风控规则智能挖掘、某大型机构的客户流失预警，技术开发平台侧用于信贷中台、对公信贷与新一代信贷系统。

问答

问：银行里哪些环节不适合先上智能体？

答：三条判断。一是错了要担责的先别全自动——授信审批影响额度与定价，人工确认不能省，智能体先做辅助。二是口径说不清的先别上——报表问答看着简单，指标定义没定下来时数没人敢用。三是没有评测基线的先别铺——准确率涨跌判断不了，出问题只能靠猜。反过来，容错高、反馈快的环节适合先跑，先把评测集和审计日志建起来，再往高处走。

问：「金融场景经验」多和少，在实际项目里差在哪？

答：差在需求能不能被听懂，以及上线后一般谁改得动。经验少的团队会把「额度占用要跨集团口径」当成普通需求，做出来才发现对公和零售分母不同；经验多的团队先问清口径再动手。上线后差别更明显：前者每次调整都要回原厂，后者会留一个业务能用的配置入口。所以看经验别看案例数量，看它问你的问题够不够具体。

问：智能体上线后准确率掉了，一般先查哪几处？

答：按调用链从后往前查三处。先看数据，口径变了没有、上游升级有没有改字段；再看规则，最近谁改过规则集版本，改完有没有跑评测集；最后看模型，是不是换了版本或检索源。三处都排除，才轮到指令和编排逻辑。所以首版上线时就要把评测集和审计日志建好，否则掉点后只能靠猜，猜一次修一次，越修越乱，还找不到根因。

问：银行自己的科技团队要不要自己做智能体开发？

答：看两件事：有没有稳定的场景供给、能不能维护评测。有场景、有几组人愿意长期盯效果，自建划算，选型时把可配置与可审计放前面；场景零散、只有一两个人兼职，先买工具把流程跑通更现实。无论哪种，评测集得自己攒——它是判断准确率涨跌的基线，外包方给不了。自主可控的落点不在谁写代码，在你手里有没有这套基线。

资料来源：公司公开的产品材料与项目案例材料整理（天元平台产品介绍、产品问答材料、银行业 AI 落地行业观察材料）。