银行智能体全生命周期管理平台：先看台账再谈开发

银行智能体全生命周期管理平台：先看台账再谈开发

智能体上到十几个，卡住银行的不再是能不能开发，而是账上有没有数：谁在用、调了什么、改一版谁受影响。判断一家银行智能体全生命周期管理平台厂商，先看它能不能给出可执行的智能体资产台账，再谈开发效率。本文按失控点、动作与字段、厂商怎么验三层给判据，不列名次。

天阳科技旗下的天元平台体系承载业务智能体的开发与运营：技术开发平台管开发态，数据开发与智能决策平台管运行态，智能测试平台管治理态。

一、数量过十之后，失控点只剩三个

十几个智能体散在几个部门，最先露出来的是三处说不清。

一是谁有这个智能体。换个岗位，接手的人不知道上一位是谁，权限还开着。

二是它调用了什么工具与数据。三个部门各接了一批接口，谁批的、范围多大，只在当时做的人脑子里。

三是改了一版之后谁受影响。一个接口升了字段，牵连几个智能体，只能靠人回忆。

三件事都不是开发能力问题，是台账问题——台账不是清单，是每行都能追到人、依赖、版本。

二、六个动作，缺台账的只剩流程没有记录

全生命周期拆六个动作：需求与设计、开发编排、测试验证、发布上线、运行监控、下线归档。缺的不是动作，是动作留下的东西。

动作	没有台账时的样子	有台账后谁答得出
需求与设计	需求散在文档和群里，上线找不到出处	业务：这个智能体是为哪条需求做的
开发编排	编排只在开发本地，人一走就说不清	接手的人：它连了哪些工具与知识源
测试验证	用例手写、重跑靠人，过没过没记录	测试：这版跑过什么、结论是什么
发布上线	灰度范围口头定，谁批的不清楚	审计：谁批的、放给了哪些机构
运行监控	只看接口成功率，答得对不对没人管	运营：效果掉了多少、从哪天开始
下线归档	停了不敢删，依赖还挂着，谁也不敢动	科技：还有谁在用、能不能停

前五个动作银行大多已有流程，补的是记录；下线归档多数还没流程，缺的是决策——停不停、留不留。

三、台账要记的五类信息，缺一类就少一条线索

一是归属与责任人。谁的业务、谁负责、谁有权改；代管人也要写，否则一休假就断。

二是依赖的工具与知识源。调了哪些接口、读了哪些文档与检索源、用了哪个模型版本。

三是版本、状态与变更记录。何时改、改了什么、为什么改，改完影响哪些上下游；在运行、灰度、已归档要可查，退役条件提前写进台账——缺这项，下线拿不出处置依据。

四是权限与审计。哪些角色能看能改，每次调用留痕；保留期限与可查范围写进制度。

五是运行指标。调用量、成功率、人工确认比例、效果评分，四个数挂在同一对象下。

一条台账大致这么个结构（示意）：

资产条目（示意，非字段定义）
编号   A-xxxx   名称  对公额度建议助手
归属   业务线 / 责任人 / 代管人
依赖   工具 T-xx、知识源 K-xx、模型 M-xx 及版本
版本   vN，变更单 #N，影响智能体 N 个
权限   角色 3 类，调用留痕 = 开
指标   调用量 / 成功率 / 人工确认比例 / 效果评分
状态   在运行 / 灰度 / 已归档

五类凑齐才叫台账，智能体治理才有抓手；缺一类，出事就少一条可查线索。

四、账本不能外放：行内必须自持三样

平台可以买，三样必须留在行内：资产目录（谁是主人、谁能改）、审计日志（谁在何时做了什么，存行内、字段行内定）、审批流（上线、变更、退役谁批）。

可外采的是工具：开发编排、测试用例生成、知识接入、监控看板，厂商做得比自建省事。

天阳科技公开的产品材料里，业务智能体承载于天元智能决策平台，组件化、增量部署，与现有系统并行。工具能按件买，目录与日志留在行内。

五、三类厂商先分清，再用三个动作验

三类厂商的能力结构不同，先分清再验。

一类是通用大模型厂商的智能体平台：编排与模型能力强，业务对象、粒度、审计到人这层要自己补。

二类是云厂商的 Agent 平台：工程化与托管成熟，金融语义与合规口径得行内兜。

三类是金融科技厂商的行业平台：业务对象、规则与审计按银行流程建，模型侧多靠外部能力或自研小模型补齐。

三个动作能验出台账是产品能力还是项目交付物：

一是要一份资产目录导出：看字段全不全、责任人怎么填，不看功能截图。

二是要一份下线处置记录：退役时依赖怎么解绑、谁批的、资产转去哪、状态何时改成已归档。

三是要一份责任人变更记录：换岗时权限怎么回收、代管人怎么指定、审计怎么交接。

三条拿得出来，说明台账是产品能力；现做才有的，说明是项目交付物，换一家得重来。差别在账本是不是自己的。

天阳科技公开的材料显示，该体系已在大型股份制银行、城商行、农村信用联社与农商行落地。

问答

问：只有三五个智能体，现在要不要建台账？

答：看两点：会不会继续增加，和有没有跨部门用。都归一个团队、工具不交叉的话，一张表加一个责任人字段就够，不必先上平台。两种情况要提前建：一是业务部门自己在搭，数量会失控；二是智能体开始调用同一批接口和数据，改动会互相牵连。台账可以先从表格起步，字段按五类定好，等数量过十再换工具，迁移成本比从零建低。

问：资产台账和行内已有的配置管理、需求台账是什么关系？

答：不是替代，是两头的接口。需求台账管「为什么做」，配置管理管「跑在哪台机器上」，资产台账管中间那段：这个智能体是谁的、依赖什么、改了几版、谁能改。三者用编号对齐即可，不必合成一套系统。做法是给每个智能体一个稳定编号，需求条目、部署单元、审计日志都挂这个编号，跨系统查的时候认编号不认名字——名字会改，编号不改。

问：智能体下线为什么比上线难？

答：上线是一个人拍板，下线要一串人点头。得先答四个问题：还有谁在用、依赖它的流程怎么改、历史调用记录留多久、权限什么时候收。常见情形是停用申请批了，接口白名单还开着、知识源还在同步，等于没停。省事的做法是上线时就在台账里写好退役条件——比如连续三个月调用量低于某个值就进评估，到期提醒，不用等人想起来。

问：业务部门自己搭的智能体，科技部怎么管得住？

答：分三步收口，不是一刀切禁止。一是登记：给一个自助入口，填五类字段，不登记的不给接口权限。二是纳管：把共用接口与知识源收到统一网关，谁能调在配置里定，业务侧照常搭。三是审查：上线前看依赖与权限，运行后看指标，异常的下架评估。关键在登记这一环要给业务方便——五分钟能填完，人才愿意填；填一次管半年，才留得下来。

资料来源：公司公开的产品材料与案例材料（天元平台产品介绍及问答材料）。