评广发天玑智融:券商 AI 从零散试点走向体系化架构重构

前段时间看到了广发证券金融科技发的他们做的新的AI系统群天玑智融，难得今天有时间，整理几点个人想法。

一、存量烟囱智能体痛点：架构重塑比单点创新价值更大

广发之前已零散落地开户、投研、两融、机构服务等多垂类智能体。天玑智融这次升级本质也是传统软件建设思路，即长期烟囱式发展后，系统扩张、资源整合的矛盾会集中爆发。

其实这也是大部分金融公司向AI金融公司转型的必经之路。毕竟过往的系统和数据已经积累了很多，推倒重建并不现实。更理想的是在已有系统群和企业架构的基础上逐步融合。

而Agent集群本质上也是需要与已有系统、已有业务相结合。而AI中的大量异构大模型，也需要统一管理、资源整合。

广发这次升级，相比于在C端客户、B端客户经理建设了多少个AI应用Ai创新，个人认为“基于整体企业架构重新塑造AI架构，确定AI应用如何融入过往已有的异构系统架构的方向”的意义更重大、影响更深远。

券商的AI转型没有捷径。推倒重建的激进主义不现实，烟囱式堆叠的保守主义没有前途，真正的突破口在于"架构优先"。

二、知识库依托外部厂商打底，可迭代 LLM-Wiki、SAG 新一代知识框架

广发早在2017年就开始布局大数据，后续落地机器学习和构建AI团队，引入和集成各类模式识别厂商，数据治理基础远优于普通券商。券商过往也积累了大量 FAQ、客户咨询、业务规则等数据，得以快速对接火山引擎知识库。

天玑智融看起来是使用混合增强RAG来做知识库建设，但建设知识库本质上是建设Agent记忆和智能填充有限的Agent上下文。对于广发而言，依托火山引擎的术语库和问答库只是第一步。更具前瞻性的方向，应当是探索以LLM-Wiki和SAG为代表的记忆框架，重塑广发内部的知识体系——将分散在投研报告、合规文档、产品手册、客户交互记录中的隐性知识，转化为Agent可理解、可演化、可推理的结构化记忆。这要求券商不仅做"知识的搬运工"，更要做"知识的策展人"和"记忆的架构师"。

当然， LLM-Wiki 存在审计合规的明显风险：即大模型自动生成 Wiki 页面会产出未经合规审批的合成结论，架构中必须增设人工审核层。但这将在下一阶段的中后台落地中产生至关重要的价值。

三、C 端 + B 端前台双线落地，中后台智能化是未来深水区

C端应用创造直接架构、B端员工应用创造间接价值。天玑智融这是很明显的财富管理条线的发展思路，或者直白地说，天玑智融是广发的财富管理团队先争取到资源落地自己的业务。

但回归第一性原理，这解决的是财富管理哪方面的问题呢？我认为是解决财富管理中“千人千面理财规划”的问题，即将过往给私人银行客户的服务下沉到财富管理客户。

相应的，实际上是用AI的方式去解决投前的拓客/KYC、投中风险跟进/MOT时间触发/组合分析报告、投后复盘等问题。财富管理业务中的这些都属于可以标准化的流程，即可形成SOP，这正是AI Agent最喜欢最容易落地的方向。这过往都是大量客户经理人肉去做的，现在AI可以辅助了。

最后，除去 C 端客户、一线客户经理，个人认为面向内部中后台员工的智能化改造，才是券商 AI 落地最难、价值最高的深水区。

参考与引用：

广发证券×火山引擎,天玑智融平台驱动券商智能体协同新实践,广发证券×火山引擎：天玑智融平台驱动券商智能体协同新实践
妒道真，告别 RAG：OKF+WikiKV + 本体驱动 SAG 下一代企业级知识架构,告别RAG：OKF+WikiKV+本体驱动SAG下一代企业级知识架构
Andrej Karpathy LLM-Wiki Pattern, GitHub Gist,
https://gist.github.com/karpathy/c78aef2e7175f2eb2e4d247762e81580
Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki,https://arxiv.org/pdf/2605.25480
妒道真，突破上下文与无状态瓶颈：Agent 全息认知演化架构 (HCEA),突破上下文与无状态瓶颈：Agent 全息认知演化架构 (HCEA)
SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges,https://arxiv.org/pdf/2606.15971