一、说明
在充分保证包括系统性产品工程分离（门户、业务、数据、运维）在内的批量可交付性前提下，可以在一定程度上考虑产品架构演进的先进性问题，面向AI的架构适应就是其中之一。关于AI原生产品架构，已经谈过不少。在应用架构层面，大体图景是清晰的："统一入口 + 智能体平台 + 业务地图 + 物料"。这套框架点出了AI时代产品架构的四个要素（交互形态、执行主体、业务知识与工具资产）及其关系，总体上没有问题。
但在实践中，这套框架还需要结合产品具象化针对性落地：入口以什么形态嵌入业务？所谓AI中台与已有产品怎么结合？业务地图到底是什么结构？已有产品AI适配的步骤是什么？
本文结合实践，特别针对资管场景提出AI Inside原生产品架构演进，进行探讨。
二、入口层的两种形态
实践表明，入口层至少可分为两种情况（见下面架构图上部入口层），分别对应AI Inside的原生产品模式与典型的统一工作台AI原生产品模式。
形态一：AI入口嵌入原UI的UI Inside（但本质属于AI原生的龙虾形态， 而不是传统理解的+AI，可称AI原生嵌入**）。** AI入口以对话或按钮的方式，嵌入原有应用的交互界面，与后端AI智能体平台连接。用户的工作主界面还是原来的交易终端、指令管理平台，AI以"副驾"姿态出现在界面的一处------一个对话窗、一个"智能优化"按钮。
**形态二：原生对话工作台。**用户的整个工作界面就是一轮轮对话，业务动作通过卡片（表单、图表、确认框、审批条）在对话流中完成，菜单、按钮、页面跳转被对话+卡片取代。
两种AI原生形态的差别不在技术高下，而在业务适配。
三、两种形态与业务的适配
（一）AI原生嵌入：贴近实时交易业务
形态一适用于贴近实时交易的产品在AI维度上的架构演进，典型如资管投交与投管的实时主体业务。这类业务的特征：
- 实时性要求高：行情、头寸、指令下达均有时效，交互链路每多一跳都可能错失交易时点；
- 对实时数据获取要求高：持仓快照、盘口流动性、风控指标必须取自当下系统状态；
- 对数据与语义精确性要求高：数字必须是确定的，"大概、可能"在交易场景是事故而不是答案；
- 操作复杂性有时也高：一个动作背后是多约束、多步骤、多系统协同。
对这样的业务，把用户迁到全新对话工作台，风险大于收益------交易员的操作习惯、系统的确定性保障、监管对操作留痕的要求，都不支持推倒重来。合适的做法是AI嵌入：界面还是那个界面，AI在恰当的节点出现。
这种AI原生嵌入更完整的形态，是模型Inside：把小参数大模型（Qwen 27B级别），连同智能体运行框架，装到一台数万元成本的机器上，作为产品设计的一部分------是产品出厂时就内置的一颗"AI引擎"，随产品一起交付、运行、进化；同时，对原有架构开放目标中的API与数据开放工作面向AI友好升级。这个模式之所以能纳入考虑，来源于两个驱动力：一是小模型的企业级成熟度与成本可达性拐点已经到来；二是云上大模型（很多情况下也包括私有云）对核心交易系统的难以触达性------API网关、数据脱敏、审批流程层层加锁之后，AI能力在交易域内所剩无几。AI Inside可能绕开这道墙：不是把数据送出去，而是把模型请进来。
下面三个场景，来自某基金公司的项目，是与O45/O32/OOrder、CMC、FC等产品相关的首批AI Inside增强功能，入口全部嵌入原有产品之内，而不是另开AI工作台。这类设计有共同原则：LLM当"脑"、计算引擎当"算"、风控试算当"裁判"。模型只做意图理解、任务编排与结果解读，任何精确数值都由确定性计算引擎产出------金融场景绝不让大模型直接算数。
场景一：股票投资组合指令优化Agent。 组合调仓指令可能触发股票池、双十、流动性、集中度等合规约束，传统模式是"下达---拦截---人工调整"的循环。AI嵌入后：指令下达前，Agent自动完成"试算 → 识别违规 → 优化调整 → 再试算"的闭环，验证通过才输出"零拦截"可行指令。LLM负责理解意图与软性偏好、按约束优先级决定调整方向；带约束的最小偏离优化由求解器完成；风控试算当裁判。模型从头到尾没有算过一个持仓权重。
界面示例：OOrder指令终端。 下图是该形态在OOrder指令终端上的落地：左侧原有"指令复核"面板保持不变，AI以"生成AI调优指令""AI下达"两个按钮嵌入------AI在后台完成试算与优化调整、生成调优指令，交易员复核后一键下达；右侧指令表格与下方任务管理时间轴照旧，每一步调优过程在"调优过程"列留痕。界面还是那个界面，AI原生在恰当的节点出现。令终端的AI原生嵌入示例（原有指令复核界面保留，AI以按钮嵌入）
图：OOrder指令终端的AI原生嵌入示例（原有指令复核界面保留，AI以按钮嵌入）
场景二：指令管理平台组合分析模块Agent。 组合分析本身是确定性计算------Brinson归因、VaR、因子暴露都是数学公式，不应让LLM去算。Agent的价值在三个环节：意图理解（"这个月为什么跑输基准"→归因+暴露+对比的结构化任务）、任务编排（决定调用哪些工具、按什么顺序、传什么参数）、结果解读（把指标翻译成可读结论，支持多轮下钻）。计算引擎层是纯函数，Agent只能通过工具调用------LLM幻觉污染不了分析结果。
场景三：权益+固收投资指令多智能体。 围绕指令全生命周期，订单拆分与执行Agent依据冲击成本与盘口流动性拆分母单，市场监控Agent实时观测盘口与资金面，交易归因复盘Agent在成交后测算滑点、评价执行质量。多个智能体协同，但每个"手"都是确定性的交易与计算接口。
总结：形态一的架构实质是"原有界面 + AI嵌入 + AI中台（智能体平台+业务地图）+ 物料"，前端保留确定性界面，执行在智能体平台上。如果再把小参数模型与智能体框架也加入到原有产品组件中，就形成了完整的、自闭环的AI Inside原生产品模式。
AI Inside 的产品模式，还有助加速解决云端AI够不着时的其它各类问题。 例如解决数据底座的多域异构数据的语义/口径一致性问题**：**来自O45、非标、估值、TA、风控、场外衍生品等多源异构系统，同一个名词，各系统定义不一样："持仓成本"O45里是交易成本、估值系统含税费、非标系统是摊余成本；"敞口"一词，风控和投管口径也不通用。靠人写ETL、映射表成本极高，冲突经常漏检，而大模型的语义理解与逻辑推理能力恰好对症；再如加速现场问题排查：很多现场问题（类似CMC的指标计算错误）必须在真实数据环境里逐步比对，"日志脱敏甚至照片传回厂商分析"的做法，要么信息不完整、要么周期漫长。AI Inside则可能改进这个格局。
**模型Inside不是一次性交付，而是一条可持续演进的路线，可分三步走。**第一步，原生小模型；第二步，场景专属后训练模型，形成差异化竞争力。同时，后训练数据集与训练过程与具体模型解耦------升级底座模型时一次性迁移；第三步，内置自进化能力：模型机器上内置自进化开源框架（类似Reef），将智能体的真实工作轨迹、执行结果与用户反馈，持续转化为对模型权重与工具链（提示词、技能、编排逻辑）的更新，越用越强。
归纳起来，这种产品模式的优点是：交易域AI原生轻松可达、可交付，成本低廉，场景与模型松耦合；而随着时间的推移，先发的现场数据与场景积累，会形成难以复制的护城河。
（二）原生工作台：金融中后台及创新产品
形态二适合金融中后台业务，如经纪开户、运营、财富管理，以及资管业务中投资经理事后报告报表的生成，或者创新产品：如果一个业务面对的是开放式需求，任务目标和执行路径无法预先穷举，后续要做什么、调用什么能力、走哪条业务路径，需要根据用户持续变化的意图和上下文动态判断、规划和组织，那么它就更适合 AI 原生工作台。这类业务恰好相反：
- 流程步骤间允许停顿，没有分秒必争的时效压力；
- 数据是存量与准存量，而非实时行情；
- 交互以"发起---确认---流转"为主，天然适合"对话出卡片、卡片即表单"；
- 用户是运营、中台、管理岗，诉求本来就是少在多个系统间切换。
比如开户，一句"帮客户开一个两融账户"，对话流中逐步出现身份核实、适当性评估、风险揭示确认卡片，办结后自动推送通知。再如投资经理的月报季报，从取数到图表到成稿，本身就是对话式工作流。这类业务的正确选择是全面的AI原生架构：入口即对话，工作台即产品。
**入口形态由业务特性决定，而不是由技术先进性决定。**金融机构的AI版图里，两种AI原生形态会长期并存，同时对部分业务域（如资管），相当长时间内AI Inside原生可能是主体。
四、AI中台与业务地图的结构化
无论哪种形态，架构上都绕不开AI中台：智能体平台负责执行（意图理解、任务编排、工具调用、结果解读），与智能体平台对接的正是业务地图（见图中部）。业务地图是整个AI中台里最值得深化的部分------它是智能体"懂业务"的来源。业务地图分为三层：
操作地图。 对业务流程的建模：一个业务域有哪些业务动作、动作之间如何流转、前置后置条件、每个环节需要什么数据与工具。它是业务地图的骨架。
对象地图。 对数据向语义层的建模：业务概念、实体、属性、关系、术语口径。对象地图让"持仓成本"这样的字段在不同系统、不同口径下可被准确理解与对齐。
物料层（MCP、API、Skills）。 智能体的手和脚。业务动作与数据的闭环，靠API/MCP调用，与AI友好的数据语义（对象地图）连接来实现。
结构之上，有两点实践认知需要特别强调：
第一，对象地图是挂载到操作地图上的，即数据挂载到业务运作上。 脱离业务流程去建"企业级数据语义大图"，图谱本身完备，但智能体执行具体动作时依然不知道该用哪几个数据对象------数据语义必须出现在它被消费的位置上才有用。但要注意的是：
（1）操作地图与对象地图并不存在固定的从属关系，二者的主导关系取决于业务过程是由流程驱动，还是由 Agent 动态驱动。对于流程相对确定的业务，业务主流程、状态迁移和关键动作已经明确，只是在某几个节点存在"需要理解、判断、生成、优化"的认知型任务，是流程决定 Agent 在哪里工作。此时应以操作地图为主导，由操作地图定义业务动作、前后置关系和执行路径；对象地图主要服务于具体动作，为每个业务节点提供准确的业务对象、属性和出入参语义，使 Agent 能在既定流程中准确理解当前上下文、调用相应能力，并推动流程顺利运行。此时，数据语义应围绕业务动作按需组织，而没有必要让 Agent 面对一个庞大而开放的对象语义空间。
（2）对于开放式、探索式业务，用户需求和任务路径无法预先穷举，是Agent 根据用户意图决定接下来走什么流程。此时应以对象地图为主导，尽可能完整地描述业务对象、属性、关系、状态和业务语义，为 Agent 提供理解业务世界和判断下一步行动所需的语义基础；操作地图则更多作为可被 Agent 选择和调用的业务能力集合，描述"可以做什么、如何做以及调用需要满足什么条件"。Agent 基于对象地图理解当前业务状态和目标，再从操作地图中选择、组合相应的业务动作，动态形成执行路径。
第二，MCP、API、Skills要精准挂载到具体的业务动作节点上。 这与WorkBuddy等通用智能体平台对物料注册的组织方式很不一样。通用平台把所有物料平铺注册到全局工具池，靠语义检索去"猜"该用哪个工具。这在通用场景是合理的，但业务场景实践证明问题很多：业务人员无法按业务位置理解工具（不友好）；成百上千物料平铺，命名冲突、版本漂移难治理；同一动作词可能命中多个工具，错调漏调在金融场景不可接受。
把物料挂到操作地图的具体动作节点上，情况完全不同：智能体走到"指令试算"节点，可用工具就是挂在该节点上的试算MCP。挂载式结构，让"在该做什么的时候就恰好看到能做什么"成为架构内生的性质，而不是靠提示词工程外挂的运气。
五、总体架构图
|---|----------------------------------------------------------------------------|
| |
| | 
|
上述讨论的AI部分可以下图表示：上层是两种UI入口及各自适用场景；中层是智能体平台与业务地图（操作地图为骨架、对象地图挂载其上、物料挂载到动作节点）；底座是大模型------既包括通用大模型，也包括场景专属的小参数大模型（AI Inside，可随产品交付自成闭环）。操作地图部分以场景一"股票投资组合指令优化闭环"为示例。
图上三个要点：其一，两种入口殊途同归，都汇入同一个AI中台------一份投入、两种入口收益；其二，业务地图内部，对象地图与物料都"挂"在操作地图上，箭头表达从属关系而非调用关系；其三，模型底座是"通用+场景专属"的复合结构，通用模型承担意图理解与编排推理，场景专属小参数大模型承担现场语义一致与场景深化。
六、AI Inside落地的动作与次序
现在，抛开创新产品不讲，一个已有产品的AI Inside原生适配，在技术架构上要做的动作，可以简单分解为如下两大步，实质上是原有架构开放目标面向AI的深化：
首先是对现有架构开放目标面向AI的升级。在具体的AI原生场景接入之前，首先把这一问题提上日程：虽然架构开放的工作其实已经在做，但"AI友好"在开放之上还是有更多的要求。现在，原有API开放工作升级为API/MCP的AI友好化开放（注意不必要求非得是MCP，很多情况下API已经足够），原有的数据开放工作升级为面向AI的数据语义层建模。这些工作决定了智能体调工具与数据的准确率，是整个体系的地基。
接下来，则是在具体场景驱动下，开展交互层接入、业务语义层（即产品业务地图）、智能体平台/AI中台的接入以及物料挂载等动作，逐步实现已有产品的AI原生架构适配与演进，系统性的承载未来各种场景涌现的开发与运行。
七、总结
"统一入口+智能体平台+业务地图+物料"的框架没有错，实践中需要结合产品具象化：入口按业务特性分化为AI Inside原生嵌入与原生工作台两种形态；业务地图结构化为"操作地图为骨架、对象地图挂载、物料精准挂点"的三层结构；模型底座走向"通用+场景专属"的复合形态。执行上沿"架构开放向AI升级------场景驱动AI Inside原生迭代"的步骤，已有产品可以逐步向AI原生形态演进。
下一篇：金融产品架构演进之二：高性能Scalable的以"合"解"分"与以"分"解"合"