金融AI原生技术应用生态建设白皮书 2026 -高质量发展新质生产力构筑数智金融新生态 从 Chat 到 Work • 从数字金融到数智金融 • 从云原生到 AI 原生

高质量发展新质生产力构筑数智金融新生态中国工商银行股份有限公司2026年9月ICBC版权与免责声明本白皮书面向金融行业，旨在为金融机构规划和建设人工智能原生技术架构提供体系化参考。版权归中国工商银行股份有限公司、华为技术有限公司所有，受法律保护。转载、引用或以其他方式使用本白皮书的原文、图表或观点，应注明来源。相关权利主体保留对违反上述说明及侵害相关权益的行为依法追究法律责任的权利。本白皮书不构成具体产品采购、监管合规或法律意见。涉及具体技术版本、产品能力、监管适用范围和机构内部制度时，应以正式发布的产品文档、法律法规及机构制度为准。正文保持行业中立；为有助于说明技术路线、生态兼容或公开实践，本白皮书中提及的厂商、产品与开源项目名称均作为技术示例，不构成采购推荐、能力背书或排他性选型结论。序序言这一变化正在推动技术架构的基本问题发生迁移。过去，系统行为主要由代码、配置和规则预先与行为形成，执行路径还可能随任务和环境动态变化。概率性智能因此不能仅作为一个外挂能的工程与治理体系承载这种变化。Al原生也不意味着推倒重来，更不意味着追求最大化自治。金融机构多年建设形成的核心系统、主张以继承式演进推进Al原生建设：确定性核心继续由代码、规则和流程守住底线，智能体在授务和存量系统能力由知识工厂与技能工厂通过知识工程和资产Al原生化，沉淀为可被智能体理解和调用的生产资料；技术支撑层以算力、统一模型服务的词元工厂和基于AgentOS理念建设的融合型智能体平台提供稳定运行底座。运营管理体系与安全治理体系纵向贯穿上述三层，分别保障基于这一判断，本白皮书形成十二章递进结构。趋势篇回答“为什么变”,挑战篇回答“难在哪原生资产层以知识工厂和技能工厂组织资产供给，技术支撑层提供算力、模型服务和智能体运行底座；运营管理体系与安全治理体系纵向贯穿三层。算力篇、词元篇和中枢篇共同承接技术支撑与行业生态演进。为“三横两纵”的共同对象：智能体应用层把能力转化为可验收的业务结果，AI原生资产层通过的生产资料，技术支撑层把算力、模型服务和智能体运行能力稳定供给到任务；运营管理体系负面共同决定从资源与资产投入到可信业务结果的转化效率，任何单点技术领先都不能自动等同织能力选择适宜路径，在不牺牲金融稳定性与责任体系的前提下，让智能逐步成为可复用、可治1.1战略引领：从政策驱动到体系落地，金融智能化1.4价值跃迁：从局部提效到全要素生产力重塑83.2总体架构：构建“三横两纵”的金融AI原生技术应用生态213.3度量基准：以“三横两纵”有效性衡量建设成效253.4实施路径：以任务牵引推动“三横两纵”分阶演进264.3弹性与韧性：在资源复用和服务保障之间取得平衡34385.1需求识别：先明确任务，再选择模型405.4经营反馈：让成本能够关联任务结果456.2工程成材：以正向与逆向方法提炼可用知识536.4运营成环：以智能赋能数据与数据驱动智能形成持续进化567.1技能规划：围绕业务任务确定建设范围617.3能力接入：复用已有服务，统一调用接口63859.3统一护栏：形成全链路标准防护9510.2进入流程：以智能融合重塑模式10.3沉淀复用：以实践淬炼设计方法11.2事前治理：以场景识别和分级准入把住建设入口12.1差异化重构：竞争力将更多沉淀在机构上下文12012.3建设普惠：降低建设门槛，统一公共标准12112.5风险范式：从检查结果到证明过程122第一章趋势篇：第一章趋势篇：——Al原生重塑金融新范式2察势者明，趋势者智。习近平总书记指出，人工智能作为引领新一轮科技革命和产业变革的战略性技术，深刻改变人类生产生活方式[1]。当前，国家战略、行业监管、技术演进与成本生命周期治理明确了行业路径[2][6]。对于金融机构而言，“人工智能+”已不再是可选项，而从政策驱动到体系落地系统内生智能统一运行闭环生态协同持续演进图1-1战略、能力、范式与价值共同推动金融AI原生演进人工智能发展正在同时跨越三道门槛：从技术创新上升为国家战略，从生成式工具演进为可行动的智能体，从局部试验进入受监管的规模应用。国家战略、行业监管、技术演进和成本曲线形成同向合力，推动金融机构的AI建设由“是否应用”转向“如何深度融合、如何安全发以数据和智能重塑金融价值链数据一知识一判断受控行动一运行反馈以系统化能力构建可持续竞争力“人工智能+”能力培育一融合发展规模普及一规范治理健康有序发展[1];2025年8月，国务院印发《关于深入实施“人工智能+”行动的意见》(国发〔2025〕11号),明确以科技、产业、消费、民生、治理和2026年3月，《中华人民共和国国民经济和社会发展第十五个五年规划纲要》进一步提出深化拓展“人工智能+”,加强人工智能数据治理和安全技术研究应用，推动人工智能赋能经济2026年5月，国家网信办、国家发展改革委、工业和信息化部联合印发《智能体规范应用与创新发展实施意见》,从基础技术、工具链、标准协议、场景开放、创新生态和安全治理等方面作出系统部署，明确智能体应具备自主感知、记忆、决策、交互与执行能力，并突出权限管理、行为管控、分类分级和全生命周期安全[5]。这意味着智能体已从技术探索进入规范发展中央金融工作会议提出做好科技金融、绿色金融、普惠金融、养老金融、数字金融“五篇大文章”[4],数字化能力成为提升金融服务实体经济质效的重要基础。随着数字金融政策持续深化，数据、系统和流程的数字化积累正在向知识化、智能化和行动化升级。2026年6月，国家金融监督管理总局发布《关于银行业保险业人工智能安全开发应用的指导意见》(金发〔2026〕8号),从治理架构、开发应用、数据治理、算力建设、风险管理、能力提升、保障与监督等方面提出32项指导性意见，进一步明确了金融AI规模应用的治理边界与实施路径[6]。4把判断转化为受控行动，并通过运行反馈持续优化。其能力重心由“记录业务、连接渠道、固化流程”，进一步转向“理解客户、辅助决策、组织任务、协同执行”，推动金融服务由数据1.1.3机构层面：AI建设从分散试点走向企业级能力经营对金融机构而言，战略窗口已经打开，但建设逻辑必须同步升级：从单点技术验证走向生产级应用，从部门分散创新走向企业级统筹，从一次性交付走向持续运营，从追求模型数量和场景数量走向关注任务完成质量、资产复用效率、单位任务成本与风险暴露。AI由局部赋能工具演进为基础生产能力，需要业务、科技、数据、安全、合规和运营共同参与，并建立可复制1.2能力突破：从Chat到Work，智能应用走向行动与协同随着大模型在理解、推理、规划和工具使用等方面持续演进，生成式AI正在从Chat走向Work。Chat阶段的核心价值是理解信息与生成内容；Work阶段则进一步围绕业务目标分解任务、组织上下文、调用工具、维护状态并交付结果。AI由“信息生产工具”转变为进入真实业务流程的“数字生产力单元”，评价标准也由回答是否流畅，升级为任务是否完成、过程是否1.2.1能力演进：从内容生成到任务闭环这一能力跃迁大体经历四个阶段：Chat以自然语言交互完成问答和生成；Copilot嵌入专业工作台，为员工提供检索、分析与建议；Agent开始围绕目标自主规划并调用工具，承担可验证四个阶段并非相互替代，而是按照任务复杂度、风险方案建议还要满足适当性、可解释和依据可追溯；工具执行必须叠加身份识别、权限校验、参从Chat到Work不是增加一次工具调用，而是从“生LLM:决定智能上限|Harness:守住可信下限在既定边界内持续、可靠地把任务做完能力和人机协作图1-3从内容生成到任务闭环的能力与工程演进当智能体进入Work阶段，仅依赖模型本身已不足以支撑稳定的业务执行。工程焦点随之由提示词工程扩展到上下文工程，并进一步走向Harness工程：提示词工程解决“如何表达任务”,上下文工程解决“在有限窗口中供给什么信息”,Harness工程则解决“如何让智能体在既定边Harness是面向智能体全过程的运行与控制框架，通过定边界、供上下文、控执行、管状态、验结果、能修复，将模型的概率性智能转化为可执行、可控制、可验证、可追溯的业务行动。从工程视角看，金融自主智能体可以概括为Agent=LLM+Harness:LLM提供理解、推理、规划和工具调用能力，决定智能上限；Harness提供运行环境、行为约束、反馈闭环和观测治理，随着模型能力增强，用于弥补认知不足的显式规划和重型编排会逐步变薄，但身份权限、执行隔离、状态管理、结果验证、异常恢复和审计追踪不会消失。Harness将由“帮助模型想明白”更多转向“确保模型做得对、做得稳、做得可追溯”,最终演进为轻编排、强环境、强治真实金融业务通常跨越多个专业领域、岗位和系统，单一智能体难以同时承载全部知识、当智能体进一步与岗位职责、业务流程和组织机制相映射，AI便不再是分散的工具，而成为组织中的数字生产力单元，形成“自然人员工+智能体团队”的新型人机协同工作方式。人负责目标设定、价值判断、例外处置和责任承担，智能体承担信息处理、跨系统操作、方案生成当人工智能从“生成内容”走向“理解目标、规划任务并调用工具完成工作”,系统的基本运行单元开始由确定性应用扩展为具有概率性、状态性和行动能力的智能体。架构所要解决的问题，也由“如何稳定运行预先编写的软件”,升级为“如何让智能在动态环境中持续、可靠、安全地形成业务结果”。因此，金融机构需要的不是在既有技术栈上简单增加一个模型接口，而是沿云原生、AI增强到AI原生完成一次继承式架构演进。形成新的“AI烟囱”云原生以容器、微服务、声明式接口、弹性调度、持续交付和可观测性为核心，将大型单体应用拆解为边界清晰、可独立发布的服务，显著提升了软件交付效率、资源利用率和系统韧性。其基本前提是：系统行为主要由代码、配置和规则预先定义，输入、处理路径与输出边界总体可预测。对于账户、账务、交易、清算等确定性要求极高的金融核心能力，这套范式仍然但云原生无法单独胜任智能体工作负载。智能体面对的往往是开放目标而非固定接口，执其输出具有概率性，任务可能长时间运行、反复重试或跨智能体协同，风险也会从“服务是否可用”扩展到“理解是否正确、计划是否合规、权限是否匹配、行动是否可逆、结果是否可信”。云原生能够承载模型和智能体服务，却没有原生回答这些智能行为的组织、控制、验证AI增强通常是在既有应用或流程节点上接入大模型，为问答、摘要、生成、检索或辅助决策提供能力。其优势是改造成本低、上线速度快，适合验证场景价值；但系统主流程仍由传统7代码固化，模型只承担局部输入或建议，无法围绕目标自主组织跨系统任务。随着场景增多，能力难复用、状态难贯通、成本难归集、风险难统一治理。模型能力即使持续增强，只要智能AI原生从业务目标和用户意图出发，将模型、知识、上下文、记忆、工具、规则、流程与人机协同设计为统一的运行闭环，并以智能体作为新型运行单元。代码不再单方面决定全部路径，而是负责划定确定性边界；模型负责理解、推理与规划；知识和上下文提供事实依据；工具承接真实行动；Harness负责状态管理、过程控制、结果核验、异常恢复和审计追踪。由此，系统既获得应对复杂任务的灵活性，也保留金融业务所要求的严谨性1.3.2金融AI原生是什么：内涵、特性与价值就把模型、智能体、知识、数据、上下文、工具、算力，以及安全治理和运营机制纳入统一架构，使AI能够参与业务流程、任务执行和系统运行，形成面向智能化生产与服务的新型业务与技术范式。其判断标准不是“使用了多少AI”，而是智能是否进入系统行为的形成机制，能否在明确边界内持续产生可验证、可控制、可客户权益和监管要求的核心环节，仍应由规则、代码和确定性流程严格控制；AI重点承担复杂意图理解、非结构化信息处理、任务规划、方案生成与跨域协同。低风险、可验证、可撤销的任务可提高自动执行程度，高风险或难以撤销的任务必须强化权限校验、规则拦截和人工确认，形成“智能负责理解与执行、规则负责约束、人工负责决策与兜底1.能力内生。模型、知识、智能体、工具和规则在架构设计阶段即被纳入系统，可标准化2.意图驱动。系统从用户目标出发，结合身份、情境与约束动态组织服务路径，实现从3.智能执行。智能体能够规划任务、调用工具、管理状态、核验结果，并在异常时重试、4.上下文认知。综合会话、身份、业务状态、实时环境和权威知识形成连续判断，同时控5.持续演进。模型、提示词、Skill、知识、规则和评测集基于运行数据与人工反馈持续优8从价值上看，AI原生将AI由零散工具提升为可规模化生产、装配和运营的企业级能力：对客户，可围绕意图动态组合跨产品、跨渠道服务，提升体验与问题解决效率；对员工，可将查询、分析、操作和跟进组织为端到端任务，释放专业人员的判断与创造能力；对机构，可沉淀模型、知识、Skill、工具和评测等可复用资产，降低重复建设成本；对治理，可通过统一运1.3.3AI原生与云原生：继承工程底座，拓展智能生产范式AI原生不是对云原生的替代，而是在云原生之上的能力继承和范式拓展。没有云原生形成的资源池化、服务化解耦、弹性调度、持续交付、可观测、韧性与安全前置，模型服务难以高效供给，智能体任务难以稳定运行，智能资产也难以规模复用；但仅有这些能力，仍不足以处表1-1云原生与AI原生的继承与区别比较维度云原生AI原生核心问题软件如何高效构建、交付和运行系统如何围绕目标组织智能并可信行动基本运行单元应用、服务、容器智能体，以及模型、知识、Skill和工具等智能资产行为形成机制代码、配置和规则预先定义代码边界与模型推理、上下文、工具、规约共同决定主要状态服务、实例、调用链与资源状态任务、会话、记忆、业务、环境与智能体协同状态工程重点微服务治理、弹性、持续交付、可观测与韧性上下文工程、Harness、知识与技能资产治理、评测反馈与智能体运营风险治理可用性、性能、漏洞、访问控制与供应链安全在继承左侧能力基础上，增加幻觉、提示注入、越权规划、工具误用与行动失控治理演进关系构成稳定可靠的数字化工程底座继承云原生纪律，并建立面向概率性智能的生产与治理体系因此，面向金融智能化转型，合理路径不是在云原生与AI原生之间二选一，而是以云原生保障稳定，以AI原生实现智能，以金融级安全治理确保可控：确定性核心继续由代码和规则守住底线，智能体在授权范围内动态组织任务，两类体系通过标准接口、统一身份权限、全链路1.4价值跃迁：从局部提效到全要素生产力重塑金融AI原生让智能进入客户旅程、员工工作、能力生产和治理过程，重新组织人、数据、知识、规则与系统之间的关系，其价值不应以智能体数量规模衡量，而应看有多少任务能够被可信交付、有多少能力能够跨场景复用、有多少产品功能供给客户全旅程运营价值跃迁·评价闭环个人效率组织生产力治理价值质落地应用数据反馈图1-5金融AI原生的四类价值与“效、质、新、稳”评价闭环一是客户服务实现从产品功能供给走向客户全旅程运营。传统金融服务以产品、部门和功能菜单组织，客户需要理解机构内部结构，再把真实需求拆解成多次查询和操作。AI原生以客户意图为入口，在授权范围内综合身份、情境、历史交互、风险承受能力和实时业务状态，动态连接咨询、测算、申请、审核、办理、提醒与售后，使服务从单次触点响应走向跨产品、跨渠道、跨阶段的连续旅程。这种“千人千面”不是生成不同话术，而是在适当性、消保和隐私边界内，为不同客户组织不同的服务路径、信息解释和交互节奏。其价值体现在问题解决率提二是员工工作质效提升，并进一步转化为组织生产力。单点助手主要缩短写作、查询和分析时间，价值容易停留在零散的个人效率。AI原生智能体能够把信息收集、规则核验、方案生成、系统操作和持续跟踪组织为端到端任务链，受益员工群体由重复操作的执行者进一步扩大为目标管理者、专业判断者和例外处置者。智能体承担高频、标准化、可验证的工作，人聚焦复杂沟通、价值判断与责任决策。人机协同的衡量重点，应由使用次数转向有效工时释放、流程周期缩短、一次通过率提升、人工接管率下降和专业服务产能增长。只有当节省的时间被重三是人工智能赋能从烟囱作坊式建设走向能力标准化量产与持续运营。传统项目制下，每个场景分别建设模型接入、知识检索、流程编排和安全控制，试点越多，重复投资和治理复杂通过统一运行时和工程平台进行装配，使新场景能够复用成熟能力并快速复制。同时，智能体可以把实时数据、制度规则、市场信息和历史经验组织为动态任务上下文，持续完成“监测一识别一分析一建议一执行一反馈”,推动经营管理从静态报表和人工跟进走向动态闭环。运行数据又反向沉淀为知识、规则和评测资产，形成能力复用、规模应用、数据反馈和持续优化的增长飞轮。因此，衡量体系化建设成效的关键，不只是首个场景是否成功，而是第N个智能体四是治理价值，从事后控制走向过程内生。当AI由生模型输出扩展为任务全过程。身份校验、最小权限、内容安全、计划审查、工具确权、参数核验、隔离执行、敏感信息保护、结果验证和审计留痕，需要嵌入感知、规划、执行与反馈各阶段，并根据任务风险实施自动放行、规则拦截、人工确认、降级或终止。治理不再是上线后的附加门槛，而成为支撑智能体扩大授权范围和提升自动化自动化覆盖率与单位任务成本；质，衡量准确率、一次通过率、客户满意度和问题解决率；新，衡量新服务、新流程、新岗位协同与可复用资产增长；稳，衡量安全事件、越权调用、人工接管、异常恢复与合规审计。四类指标共同回答一个核心问题：AI是否以可控风险持续交付了可第二章挑战篇：深度剖析，知困识难——直面金融智能体规模应用的双重挑战金融智能体办事的本质是概率性智能开始进入严谨、复杂、强责任的金融生产体系。它既要理解开放目标、灵活组织资源，又要始终遵守身份、权限、额度、流程和责任边界。因此，金融智能体兼顾灵活、严谨、准确、安全四重特性，要实现从“能说会道”向“能做会办”的图2-1业务“三困”与技术“六难”共同制约规模化应用当前，金融行业普遍缺乏一套指导金融智能体架构、研发、治理的工程化方法论，同时面临“业务部门各自统筹、跨部门协同壁垒”等工程化组织保障隐患，智能体建设整体统筹难度一是建设方法缺失。企业在智能体规模化推广过程中，普遍面临智能体建设缺标准、难定义、低复用等问题，需要回答“企业内建多少、建什么、怎么建、谁来建”等核心问题。若缺少统一方法，容易出现烟囱林立、重复建设、建而不用和用而不管等现象，制约体系化AI原生二是权责机制尚不清晰。业务掌握场景和规约，平台负责工程与运行，安全合规界定风险边界，但谁识别场景、谁批准上岗、谁持续运营、谁对结果负责，往往缺少贯通机制，导致业务与科技协同不畅、质量管控责任分散。金融机构需要建立企业统筹、平台供给、领域负责、当前，金融机构在智能体建设上已实现一定规模的功能覆盖——客服问答、合同审核、风控辅助、营销文案生成等单点能力陆续上线，但普遍在业务系统中加入AI能力实现AI增强，一是智能体场景覆盖碎片化，跨领域智能体之间的调用链路尚未有效打通。当前智能体的建设多以单一业务场景为切入点，按业务条线或部门需求独立构建，各智能体之间缺乏统一的用户意图识别与任务灵活编排机制，导致用户需要在不同功能板块间跳转切换以完成复杂金融二是智能体意图理解浅层化，个性化服务能力不足。当前多数金融智能体普遍缺乏对用户身份、情境、偏好与任务进度的综合感知能力——系统难以稳定判断用户此刻为何而来、处于什么阶段、下一步可能需要什么。用户画像的调用往往停留在静态标签层面，而非基于实时行为与上下文的动态理解。例如，一个刚完成大额购房支出的用户，与一个账户余额稳步增长的用户，即便同属高净值标签，其当下的金融需求截然不同，但智能体呈现给他们的，仍是基于2.1.3运营之困：有上线，尚未形成价值与运营闭环可量化、可持续的运营评估体系，是金融机构以合理成本释放模型效能、支撑智能化应用规模一是成本计量难，算力投入看得见，词元消耗算不清。金融智能体的成本构成远比传统IT系统复杂。一方面，同一智能体在不同业务峰谷期的芯片利用率、词元消耗差异巨大，且多智提示词工程的持续迭代、知识库的定期更新维护、人机协同中人工审核与兜底的人力投入，以及因模型幻觉或误判导致的业务纠偏成本，均未纳入现有IT成本核算框架。当前多数金融机构仍沿用传统项目的预算制和摊销逻辑，尚未建立与智能体“按需调用、弹性伸缩”特性相匹配二是价值判定难，效果可感知，收益难归因。智能体的业务价值呈现典型的间接性和滞后性特征。以客服智能体为例，其直接价值可体现为人工座席替代率、响应时效提升等可量化指标，但其深层价值——如客户体验改善带来的留存率提升、标准化应答带来的合规风险降低——则难以建立清晰的因果归因链路。更复杂的是，在多智能体协作场景中（如营销智能体+风控智能体+运营智能体联动），最终业务成果是多个智能体与人工协同的复合产出，单一智能体的边际贡献几乎无法剥离衡量。当前金融行业普遍缺乏一套既覆盖效率提升、又涵盖效果改善，还纳入风险缓释的多维价值评估框架，使得智能体的业务价值评价往往停留在定性描述，难以支撑规模化推广的定量决策闭环。图2-2统筹、服务与运营三类业务困境及其建设指向当前，金融机构已在研报初稿生成、专业制度问答、辅助材料审核等内容生成类场景中应用智能体，但当智能体进入涉及真实业务操作的任务流程时，稳定性与可控性问题更加突出。例如，授信调查跨越征信、抵押、审批多个系统，财富服务涉及客户识别、产品匹配、合规审查多个岗位，运营处置包含前置条件判断、异常分支处理和状态回写。意图误判、工具选错、参数填错或状态不一致，任何一个环节的偏差都可能沿任务链持续放大，从一步走偏演变为全链失控。因此，金融机构真正需要的，不是“能说会想”的智能体，而是能在复杂规则与多重要达到上述标准，面对长流程、多系统、强规则的金融任务，技术侧需要同时解决六类问题：智能体运行中枢能否稳定规划与执行，知识能否准确进入上下文并持续保鲜，存量数字资产能否通过技能工厂转化为模型可理解、可授权、可调用的任务技能与执行能力，安全控制能否覆盖感知、规划、执行与反馈全链路，异构算力能否形成稳定的有效供给，以及多模型能力能否进一步转化为质量、时延和成本边界清晰的词元服务。六类问题分别对应中枢、知识、技中枢之难中枢之难知识之难金融机构的智能体建设涉及不同业务条线、专业岗位和分支机构，任务特点、研发方式与运行环境各有差异。单个项目可以选择适合自身的框架，完成局部功能验证；向全行推广时，则要进一步解决能力能否复用、任务能否协作、运行能否持续等问题。中枢建设的难处，在于既容纳业务与技术的差异，又使不同实现遵循共同的生产要求，将分散的项目成果逐步积累为一是共性机制难以跨框架复用。意图识别、上下文组织、记忆使用和规划校验，是不同智能体反复需要的基础能力，但各类框架对任务、状态和执行结果的定义并不一致，也难以直接衔接金融机构已有的身份、权限和业务规约。缺少共同约定时，同一项能力换到另一个框架，往往需要重新适配，原有控制与验证结果也难以沿用。如何沉淀稳定的公共机制，并在保留不二是多种研发方式难以形成一致交付。自然语言辅助、可视化编排和专业代码研发，可以满足不同任务的建设需要，但生成内容、流程配置和代码工程的交付形态各不相同。如果职责边界、能力依赖、权限条件和验证依据未能一并交付，成果进入生产时就需要重新补充运行条件，跨团队复用也离不开原研发人员解释。降低研发门槛，不能以增加后续集成与维护负担为三是跨域任务难以保持协作与运行的连续性。金融任务往往跨越多个系统和专业岗位，材也不意味着业务已经办结。遇到补充材料、人工复核或执行中断时，任务还需保留进度，核实已有业务结果，避免重复办理。应用范围扩大后，不同业务的数据、容量和连续性要求又带来部署差异，如何共用框架标准，同时保留必要的运行与故障边界，也是规模应用必须面对的问四是资产版本与运行反馈难以贯通。智能体的实际行为取决于框架、模型、知识、Skill、工具及策略等多项依赖，任何一项变化都可能影响既有任务。如果仓库登记、版本发布与实际运行各自记录，便难以确认某项任务使用了什么、变更影响了哪些应用，以及问题应当回到哪个环节修正。金融机构既需要维护清楚的资产与版本关系，也需要将任务过程、业务回执和资源消耗关联起来，为质量分析与运营管理提供可靠依据。缺少这层技术支撑，成熟成果难以放2.2.2知识之难：知识工程如何高质量作用于智能体应用金融机构普遍拥有海量的制度文件、产品条款、操作规程，但这些知识大多停留在静态存储的状态，尚未通过知识工厂的持续加工与治理，转化为智能体在推理时可以按需调用、可信一是知识准确进入推理上下文的“最后一公里”尚未打通。大模型内生知识难以承载金融业务中实时变化、严格分权和需要证据的事实与规则，当前多数金融机构的做法是将文档放入适用且有权使用”。一个已废止的信贷政策片段与现行政策在语义上可能高度相似，模型无法产品上下架每天都在发生，但知识库的更新往往依赖人工定期维护，滞后于业务变化。同时，运行中的问题案例和人工修正普遍缺乏系统化的知识回流机制，智能体给出了错误答案或错误执行，在人工纠正后，这一修正并未自动反馈到知识库，同样的错误可能在下一次推理中重复出现。综上，金融机构亟须以知识工厂贯通知识工程、管理与运营，构建知识飞轮能力，加速2.2.3技能之难：海量数字资产如何规模化、标准化转化为智能体可复用的技能与执行能金融机构经过多年数字化建设，已积累大量核心系统、微服务、API、规则、据服务等数字化技术资产。然而，这些资产主要面向人工操作或传统应用集成设计，缺少业务语义，智能体难以直接理解、编排与复用，导致智能体构一是存量数字化能力缺少大模型可理解的业务语义。例如，一个账户查询接口对人而言含义明确，但对模型来说，它不知道这个接口在什么业务场景下可以调用、调用需要什么前置条件、返回结果中哪些字段涉及敏感信息、异常时应该如何处理。当前大量存量API缺少使用条件、权限范围、风险等级和异常说明等语义描述，模型要么因缺乏上下文而无法正确选择，要么在缺少约束时产生误调用风险。存量数字化资产的语义化成为智能体规模建设前必须补齐的二是海量数字资产服务金融智能体缺乏企业级治理框架。智能体规模化应用的关键，是通过技能工厂，把存量数字化能力封装为可发现、可理解、可授权、可组合、可评测、可观测的任务技能与执行能力，并关联Skill、Tool、Workflow、API和业务服务等不同形态。这需要建立企业级目录、语义规范、身份映射、版本准入和运行治理等机制。由于相关资产形态仍在快速演进，面向智能体的质量标准、准入和运营流程仍需完善，避免“能力资产数量持续增长，2.2.4安全之难：智能体全链路安全如何保障金融智能体需兼顾灵活性与合规性，但在动态决策、跨系统协作和数据交互中，风险已从“说错话”升级为“做错事”，大模型单一的内容生成安全无法满足智能体动态自主规划执行的全程安全防护要求，难以平衡自主运作与风险可控、审计可追溯的要求。提示词注入可能诱导其生成或发起未经授权的操作，知识或记忆污染可能使判断依据发生系统性偏移，工具描述被篡改可能导致错误调用敏感接口，身份或权限控制失效则可能使低权限主体触达高权限操作。针对这些风险，金融机构需要建立覆盖感知、规划、执行和反馈全过程的2.2.5算力之难：异构算力如何从资源规模转化为有效供给金融机构的智算投入持续增长，但物理卡数和集群规模并不等同于可供智能体稳定消费的检索、解析、校验等负载的资源特征也存在明显差异。若只以设备规模或平均芯片利用率衡量供给能力，容易出现资源看似繁忙、任务却排队等待，或局部过载与一是异构资源统一调度难。不同芯片、集群、网络与存储环境在模型适配、通信效率和故障特征上存在差异，业务高峰又具有明显的时段性和突发性。缺少统一资源抽象、拓扑感知调度、弹性伸缩和故障迁移机制时，跨集群等待、模型冷启动和资源碎片会直接转化为响应抖动二是有效算力缺少面向业务结果的度量。算力运营如果停留在卡时、利用率和容量水位，难以判断资源是否真正支撑了成功任务。金融机构需要把资源消耗与模型实例、智能体、任务2.2.6词元之难：多模型能力如何转化为稳定、高效、可度量的服务供给在智能体规模应用中，业务实际消费的不是模型本身，而是由模型服务持续输出的词元（Token）能力。即使底层算力充足，如果模型选择、推理服务、上下文组织和配额管理缺乏统一治理，仍可能出现时延波动、吞吐不足、成本失控或服务质量不稳定，算力也难以转化为可一是多模型服务的质量、时延与成本难以同时平衡。不同任务对推理能力、上下文长度、响应时延和成本敏感度不同，简单任务调用高成本模型会造成浪费，复杂任务选用能力不足的模型又会降低完成质量。缺少统一评测准入、智能路由、负载均衡、缓存复用和故障降级机制二是词元消耗难以精细计量和持续优化。智能体一次任务往往包含多轮推理、检索增强、工具调用与多智能体协作，词元消耗受上下文长度、重试次数和模型路由影响显著。若仍按模型或项目粗粒度统计调用量，无法识别无效上下文、重复推理和过度模型使用。需要将词元消耗归集到具体任务和业务结果，结合首词时延、吞吐、有效词元占比和单位成功任务成本等指第三章蓝图篇：——金融AI原生技术应用生态总体架构3.1问题再聚焦：业务与技术双重挑战指向体系化建设第二章所述问题虽然表现为业务侧“三困”和技术侧“六难”，但根本矛盾并不在于单个场景、单项技术是否可用，而在于金融机构尚未形成支撑智能体规模应用的完整体系。业务侧需要解决建设如何统筹、服务如何以用户为中心、价值如何持续运营；技术侧六类挑战中，中枢、知识、技能、算力和词元主要指向可复用的技术供给与运行能力，安全之难则同时跨越应用设计、建设管理和运行执行，具有贯穿全局的风险治理属性。由此，第二章的“三困六难”从业务看，智能体仍较多沿用项目制建设方式：场景按部门立项、能力按项目重复开发、上线后缺少持续运营，导致试点能够做成，却难以复制和经营。要改变这一状态，需要把智能体作为持续运营的数字生产力单元，统一场景识别、建设标准、责任边界、质量门槛和价值度从技术上看，模型能力只是智能体完成任务的一个组成部分。长流程任务能否可靠交付，还取决于运行时是否能稳定管理状态与异常，知识工厂供给的知识是否权威且适用，技能工厂供给的Skill、Tool等能力是否具备清晰语义与使用规范，底层算力和模型服务能否形成稳定的有效供给，以及安全防控能否贯穿全过程。这些挑战需要统筹解决，形成稳定、可复用的统一因此，破解上述问题不宜采用“业务逐场景补、技术逐模块建”的方式，而应把智能生产链与两类贯穿治理机制放在同一架构中统筹设计：智能体应用层定义任务和业务结果，AI原生资产层通过知识工厂与技能工厂沉淀可被智能体理解与调用的生产资料，技术支撑层提供稳定的算力、模型服务与智能体运行平台；运营管理体系贯穿三层统一标准、责任、度量和持续经21知识+技能技术“六难”算力底座+词元工厂+融合型智能体平台统筹/运营之困→运营管理体系安全之难→安全治理体系中枢之难算力之难“三横两纵”总体架构重新组织安全治理体系运营管理体系面向金融智能体从试点走向规模应用，本文提出“三横两纵”的金融AI原生技术应用生态。再到底层能力的主链；两纵分别是运营管理体系和安全治理体系，从场景规划、资产建设、研发发布一直贯穿到运行运营和价值复盘。三横回答“业务如何承载、能力如何沉淀、底座如何支撑”,两纵回答“如何持续经营、如何可信运行”。第二横是AI原生资产层，解决“智能体依据什么理解、凭什么行动”。该层以知识工厂和技能工厂组织两类供给：知识工厂生产、治理和运营知识、数据、规则、指标、记忆与上下文等知识类资产；技能工厂封装、验证和供给任务技能(Skill)、工具(Tool)、工作流 第三横是技术支撑层，解决“靠什么稳定生产和运行”。该层由算力底座、统一模型服务时延和成本边界清晰的模型服务，融合型智能体平台以AgentOS理念形成稳定内核与运行时，22评测发布、运行监测、AgentOps和价值经营；安全治理体系覆盖风险分级、身份权限、内容与数据安全、计划与工具校验、隔离执行、关键动作确认、审计留痕和策略运营。技术能力可以面向业务任务组织智能服务把数字化沉淀转化为智能体可消费的技术支撑层产与运行底座图3-2金融AI原生技术应用生态“三横两纵”总体架构三横两纵围绕同一业务任务形成闭环：应用层提出任务目标并消费资产；资产层生产、治理并供给来源、版本、权限和适用范围明确的知识与工具；技术支撑层提供模型推理与资源供给，并由融合型智能体平台依据具体任务完成资产选择、装配、过程控制和运行；运营管理体系持续统一标准、责任、质量和价值度量；安全治理体系依据身份、风险和动作边界实施全链控制。运行结果再反向更新资产、平台策略和应用设计，由此形成“任务牵引—资产供给一运智能体应用层重点解决场景碎片化和服务割裂问题。其设计不追求智能体数量最大化，而维护必要的任务上下文，并将跨域需求路由给相应专业能力。超级智能体的职责是组织服务而二是专业智能体。专业智能体围绕相对独立的专业责任和业务结果组织，可进一步分为领域类和岗位类。领域类专业智能体面向跨岗位、端到端的专业领域任务，负责串联多个岗位和能力；岗位类专业智能体围绕具体岗位职责，聚合岗位所需知识、技能和任务能力。两类均应三是组件智能体。对于需要保留一定自主判断、但又具有较高复用价值的局部任务，可采用轻量组件智能体承接；而文档处理、信息核验、客户尽调、分析计算等可标准化能力，更适合由技能工厂沉淀为Skill、Tool或Workflow等AI原装配。由此形成“统一入口一专业承接一资产装配”的协同关系：用户无需理解机构内部系统和部门划分，专业任务由具备相应责任边界的智能体承接，共性能力通过标准资产复用。这样既AI原生资产层连接“会思考的智能体”和“能执行的技术底座”。知识工厂与技能工厂的核心不是分别建立新的资产仓库，而是让既有知识、数据、规则、流程、接口和系统能力具备面向智能体的语义、约定、权限、版本、状态和证据，使其能够被发现、理解、授权、装配和二是技能工厂，解决“智能体如何完成任务并受控行动”。围绕任务技能(Skill)、工具 (Tool)、工作流(Workflow)以及API、业务服务和规则执行能力，完成能力封装、依赖关联、验证发布和持续维护。Skill组织任务方法，Tool分支，三者配合使用但不互相替代。相关资产不仅要描述“能做什么”,还要明确适用条件、调用主体、数据范围、参数约束、幂等与超时、状态查询、成功回执、补偿或冲正以及审计证客户超级智能体员工超级智能体合规智能体专业智能体图3-3统一入口、专业承接与运行时资产装配的协同关系3.2.3技术支撑层：形成算力、词元与智能体运行的统一底座技术支撑层聚焦不同场景共同依赖的基础供给与运行能力，避免把知识、数据和业务服务本身再次复制到平台内部。它主要由算力底座、统一模型服务的词元工厂和融合型智能体平台构成，并通过标准接口消费知识工厂与技能工厂供给弹性与故障迁移等能力，把物理资源转化为满足任务质量、时延、连续性、成本和能耗约束的二是词元工厂，对应“词元之难”。围绕模型引入、适配、评测准入、版本管理、智能路由、缓存复用、推理加速、配额与计量，把多模型能力转化为质量、时延和成本边界清晰的统通过异构融合适配机制兼容不同智能体框架和运行范式，统一任务、上下文、状态、能力、策略和证据等关键对象。AgentOS在这里是指导公共运行机制沉淀的建设理念，而非要求所有资3.2.4运营管理体系：贯穿建设、运行与价值经营运营管理体系重点解决“有试点无体系、有上线无闭环”的问题。其位置不是应用层与技术层之间的一道中间层，而是纵向贯穿三横，使每个业务任务及其智能体、依赖资产和运行结一是建立贯穿场景规划、资产研发、测试评测、准入发布、运行监控和价值运营的全生命周期闭环；二是形成企业统筹、平台供给、领域负责、多方共治的责任机制；三是以统一任务标识关联模型调用、知识资产与任务技能装配、工具执行、人工介入、资源消耗和最终结果，运营管理体系不替代知识工厂、技能工厂和技术平台各自的专业责任。源域负责内容与实现的真实性、版本和变更，管理体系负责企业级标准、门禁、责任和经营规则；通过依赖关系3.2.5安全治理体系：以统一边界贯穿设计、建设与运行安全治理体系对应“安全之难”，同样不是底层技术能力域，而是贯穿智能体应用、AI原生资产和技术支撑三层的风险控制机制。其核心是把风险控制嵌入“感知—规划—执行—反馈”一是形成统一安全控制面，围绕身份、权限、数据、内容、计划、工具、代码和结果建立策略模型，对不同风险等级的任务定义可调用资产、权限范围、参数约束、人工确认、降级和终止条件；二是把安全治理前移并持续运营，研发态开展模型与资产安全测试，运行态实施实时检测、确权、隔离和审计，运营态根据事件、误拦截、漏拦截由此，三横负责把价值、资产和技术能力组织成生产链，两纵负责让这条生产链可持续经营并始终处于可信边界内。安全检测、鉴权、沙箱、观测等能力可以由技术平台工程化承载，但安全标准、风险决策和责任归属由安全治理体系统一组织；运营工具可以由平台提供，但场总体架构回答了“建什么、如何协同”,还需要统一回答“建得好不好”。若仍以卡数、模型参数、词元调用量、资产数量或智能体数量作为主要指标，容易出现资源、资产和应用分别优化，却难以判断是否真正形成稳定业务产出。因此，应以业务任务为共同度量对象，把三横看作从价值到资产再到技术供给的生产链，把两纵看作决定规模转化效率与可信边界的贯穿机制。金融AI生产力应衡量从资源、模型和数字化沉淀投入，到可信业务结果之间的端到端转化。三横中任何一层供给不足，都会直接影响任务完成；两纵中运营机制缺失会使能力难以复制经营，安全边界失效则会限制授权范围甚至阻断生产。因此，度量既不能只看“有多少”,也不为强调体系的短板效应，可将其概念性表达为：金融AI生产力∞应用有效性×资产可用性×技术有效供给×运营转化效率×安全可信系数。这里的“乘法”不是财务核算或严格数学模型，而是提醒五个方面相互制约。三类生产能力决定“能不能稳定产出”,两类贯穿机制决务与资产可用性可理解、可调用、可复用善运营转化效率应用有效性关注“任务是否真正产生价值”。评价重点不是智能体数量，而是高价值任务覆盖率、端到端成功率、问题解决率、人工接管率以及业务结果改善，并区分建议类、辅助类资产可用性关注“生产资料是否能够被正确理解和复用”。可观察知识工厂的知识适用率与时效性、技能工厂的能力语义和权限声明准确性、服务承诺兑现度、资产复用率、版本一致性以及源系统变更后的影响识别与适配效率，避免用资产目技术有效供给关注“底座是否转化为任务成功”。算力、模型服务与智能体运行机制应共同以可用性、时延、成功任务占比、异常恢复和单位成功任务成本衡量，避免以芯片利用率、运营转化效率与安全可信系数构成两类贯穿约束。前者关注资产复用、第N个场景的边际交付周期与成本、版本迭代、价值归因以及优化退出；后者关注越权调用、敏感信息暴露、计划与工具风险拦截、关键动作人工确认、异常处置和审计完整性。两者并不与三横分离，而是把标准、责任和风险要求持续映射到应用、资产与3.4实施路径：以任务牵引推动“三横两纵”分阶演进运营规则和安全边界尚未稳定时快速铺开场景。更稳妥的方式是以代表性业务任务为牵引，在每个阶段同步推进应用、资产和技术三横，并让运营管理与安全治理两纵从第一天起贯穿其中。阶段门槛应依次验证任务闭环、资产复用与规约稳定、规则边界清晰、风险可控且结果可度量的代表性任务；AI原生资产层由知识工厂和技能工厂围绕任务补齐必要的知识、数据、规则、Skill、Tool与接口规约，形成最小可用资产集；技术支撑层按需补齐算力、模型服务和最小运行机制。运营管理体系至少覆盖责任矩阵、评测发布、运行监控和价值复盘，安全治理体系完成风险分级、身份权限、关键动作控制和审计留痕的最小闭环。阶段完成的判断标准，是任务能够在预定服务等级和风险边界内稳定完成，关键资产第二阶段，规模复制：以“复用、降本”为目标。应用层从已验证任务向相邻领域扩展，逐步形成专业智能体与成熟应用组合；资产层通过知识工厂与技能工厂，把反复出现的知识、技术支撑层把共性能力服务化，强化资源调度、模型路由、运行时与异常恢复。运营管理体系该阶段重点检验第N个场景交付周期与单位成功任务成本是否下降，同时保证资产质量、服务第三阶段，体系运营：以“稳定、持续”为目标。应用层在明确权限和责任边界内形成跨专业连续服务；知识工厂与技能工厂形成常态化保鲜、版本兼容、变更通知和依赖联动，使知识资产、任务技能与执行能力能够持续演进；技术支撑层提升资源弹性、模型服务和融合型智能体平台的韧性与可替换性。运营管理体系根据价值、成本、质量和风险决定扩面、优化、降级与退出，安全治理体系基于运行风险、异常行为和审计结果持续校准策略，对关键授权和高闭环验证闭环验证规模复制体系运营(贯穿全阶段)操作留痕·合规审计应用层资产层技术层应用层资产层技术层应用层资产层技术层复杂任务生态接入扩面三个阶段不是单纯的技术成熟度升级，而是“三横两纵”从可用走向可复用、再走向可经营的同步演进。业务任务始终是共同对象：应用兑现价值，资产层以知识工厂与技能工厂形成第四章算力篇：——形成面向业务任务的算力供给第三章已经把算力定位为技术支撑层的基础能力，但进入生产阶段后，算力问题不能再只用“卡数是否充足”来回答。一个金融智能体任务往往涉及模型推理、文档解析、信息检索、规则计算、工具调用和结果核验等多个环节；同一时刻，机构内部又并存客户联机服务、批量生产、模型研发和评测任务。资源总量看似充足，任务仍可能因显存不足、拓扑不匹配、数据本章沿“任务需求—系统协同—弹性韧性—建设选择”的路径展开。联机、批量与研发负载并存，需要先将业务优先级、SLA、模型、状态与数据边界转化为任务画像，再明确设施、物理资源、软件定义和统一调度各自的责任。评价算力供给，应看任务能否在质量、时延、连续性、成本和能耗边界内稳定完成，并以真实负载决定技术形态，以数据与连续性决定部署边界，以运维能力决定自建深度，通过运行结4.1负载变化：业务任务如何改变算力需求AI原生负载首先改变的不是设备型号，而是任务结构。传统机器学习平台可以把训练、批处理和联机推理相对独立地规划；智能体进入生产后，这些负载开始共享模型、缓存、存储与网络，并在一天内呈现明显的潮汐变化。若仍按“训练池、推理池、研发池”静态划分资源，4.1.1复合负载：联机、批量与研发任务并存联机服务重点关注首词元时延、并发承载能力和服务连续性，对资源波动较为敏感；批量处理更关注吞吐和完成窗口，通常允许错峰、暂停或重试；研发与后训练任务则具有更长的运行周期、更复杂的并行通信和更高的资源占用。三类任务的优先级、可中断性和状态保存方式更重要的是，单个智能体任务本身也不是单一计算阶段。长上下文会增加预填充和KVCache压力，多轮推理会反复访问缓存和记忆，工具执行又会等待CPU、数据库或外部系统。此时即使加速器仍有计算余量，任务也可能被显存、网络、I/O或外部依赖拖慢。所谓“卡数充4.1.2任务画像：把业务要求转换为资源约束因此，算力规划需要先形成任务画像。一个可用于资源决策的画像，至少应包含：任务类型与业务优先级、模型及并行方式、输入输出长度、并发和完成窗口、显存与缓存需求、数据敏感度与驻留要求、状态位置、可中断性与可重算性，以及目标SLA和成本边界。只有这些信息明确后，平台才能判断某项任务究竟需要高带宽超节点、普通加速器、CPU密集节点，还是任务画像还应区分“资源需求”和“服务等级”。同样一个模型，面向客户实时交互时需要预留热实例和冗余容量；用于内部批量分析时，则可以接受一定时间的排队、较低的资源优先级和相对宽松的恢复时限。服务等级越高，通常意味着更多预留、隔离和容灾成本。算力规任务类型与业务优先级完成窗口状态位置缓存需求可中断性服务等级(示例)·更高的隔离与容灾·相对宽松的恢复时限任务画像(用于资源决策)资源决策与服务保障资源需求(示例)面向用户的在线服务内部批量分析面向内部的离线任务密集节点高带宽任务画像明确后，需求才应向下传导。计算密集程度决定加速器类型和并行规模；模型与上下文决定显存和缓存层级；参数、KVCache、检查点和数据集决定存储带宽与容量；专家并行、张量并行和跨节点缓存迁移决定网络拓扑；机柜密度和功率波动进一步约束供电与冷却。这里不存在单一的“最强配置”,只有与负载相匹配的配置。容量也不宜一次性按远期峰值建设。可将需求拆分为稳态容量、可预测峰值、突发弹性和容灾底线：稳态部分承担高频稳定任务，峰值部分围绕月末、季末、营销活动等可预测窗口准备，突发部分依靠共享池或受控外部资源补充，容灾容量按关键业务的恢复目标和故障状态服务等级确定，并明确允许降级的任务范围及顺序。这种分层方式既可以减少长期闲置，也能为基础设施层提供空间、电力和冷却条件；物理算力层把计算、存储与网络组织为系统能力；软件定义算力层对资源进行抽象、切分、隔离和状态管理；统一调度与服务层再根据任务画像选择资源、分配服务等级并完成计量。四层的意义不是增加新的平台层级，而是明确“哪一类问题应在哪一层解决”,避免设备能力、调度策略和业务SLA相互混淆。资源切分资源隔离电力供给统一调度率营围计量计费冷却系统机房空间资源抽象网络图4-2系统协同：四层共同形成可交付算力随着高功率加速器和高密计算部署增加，电力和冷却条件逐渐成为设备选型与算力交付的前置约束。当拟部署设备的功率密度和散热要求超出现有机房承载能力时，冷却条件就会成为算力交付的约束。此时，可结合设备散热要求、预计利用水平和容量增长计划，比较液冷与其他可行方案。若负载规模有限、增长尚不明确，或现有冷却方式仍能满足需求，则不宜仅因采液冷是否值得，最终取决于在满足承载能力和业务连续性要求的前提下，其收益能否覆盖维护成本和预期使用周期。PUE(PowerUsageEffectiveness,电能利用效率)可用于观察设施能效，但不能单独证明整体投入划算；单位成功任务能耗与任务SLA则用于检验算力体系的整超节点的核心价值在于形成高带宽、低时延的紧耦合计算域，适合专家并行、张量并行、长上下文、较大显存池和部分后训练任务。它能够减少跨节点通信和显存不足带来的等待，但同时会扩大故障域，提高设备、网络和软件栈的一体化要求。因此，超节点不应成为所有推理是否采用超节点，建议以真实模型和真实任务做基线对比，而不是只看峰值参数。应同时比较并行扩展效率、应用可用带宽、可用显存、P99时延、故障影响范围、软件适配难度和单位成功任务算力成本。只有当这些系统收益能够覆盖更高的采购、运维和故障域成本时，才说网络则需要区分域内紧耦合通信、跨节点Scale-0ut通信、存储流量和控制流量。带宽峰值不是通算侧同样是算效的一部分。鲲鹏等Arm通算平台与x86平台可按适配结果承载文档解析、支持的方案中卸载网络、存储或虚拟化等基础设施处理，减少主机CPU在外围工作上的占用。三类处理器的组合价值不能只看单项指标，要以任务等待时间和系统总成本验证：如果预处理异构通算落地还依赖软件与数据路径。Arm与x86环境需要分别构建和验证对应架构的镜像、二进制与依赖，统一的是发布与运维规范，不能默认镜像可以互换；DPU卸载功能也应逐项确认驱动、网络与存储协议的支持范围。预处理结果尽量就近送达加速器，卸载前后的监控与故障记录保持可关联，才能避免出现局部CPU占用下降、端到端时延却没有改善的情况。不同任务对计算、显存和带宽的需求差异很大，整卡不应天然成为所有场景的最小服务单元。通过硬件分区、虚拟化、时分或空分复用，可以把物理资源组织成不同逻辑规格，用于小细粒度切分可能增加规格管理复杂度和资源碎片，不同切分方式还需分别评估其隔离能力和运行开销。计算核心、显存和带宽若不能联合控制，多个任务在同一卡上仍可能相互干扰，导致时延失控；频繁切换还会增加缓存失效和显存碎片。主流加速器提供的实例切分能力在算力、显存与故障域上的隔离粒度各有边界。因此，资源切分应建立“任务类型一切分方式一性能基线”,在吞吐、P99时延、干扰系数、隔离软件定义资源切分|按需组合逻辑规格时分复用是否放量使用关键约束建立基线硬件分区空分复用显存统一调度层不只是“找一张空卡”。它需要综合任务优先级、模型版本、数据驻留、资源拓扑、权重位置、KVCache位置、网络拥塞和服务等级，选择合适的资源池与逻辑规格。对通信密集任务优先保证拓扑连续，对缓存命中敏感的会话尽量保持状态亲和，对高敏数据限制跨统一也不意味着抹平异构差异。不同芯片、推理引擎和集群的兼容性、吞吐、功耗和故障特征应显式保留，并以服务目录的方式向上抽象。调度层负责“把合适的资源交给任务”,模型服务层则负责“把合适的模型服务交给任务”;两者协同但边界不同，这一边界将在第五章服务目录图4-4统一调度：让合适的资源承接合适的任务资源池化之后，金融机构往往希望进一步通过混部、Serverless和跨池调度提高利用率。但弹性能力的价值不能只看“扩得多快”,还要看扩容过程中模型是否就绪、状态是否连续、关键任务是否受到影响。与之类似，韧性也不是追求“故障零扩散”的绝对承诺，而是让故障被弹性与韧性建设需要通过真实任务验证资源复用是否带来稳定产出。混部场景应比较共享前后的联机时延、批量任务完成窗口和抢占重算开销；扩缩场景应记录从提出扩容需求到模型能够承接请求的完整时长，检验预热和备用容量能否覆盖业务峰值；故障场景则应验证资源恢这些验证结果应反向约束资源共享范围、热容量配置和恢复策略。若利用率提升伴随任务超时或重复执行增加，就需要收紧共享或调整恢复机制；只有任务质量、服务等级和单位成功联机服务、批量推理、训练和研发任务具有不同的可中断性。高优先级联机任务通常需要热容量、稳定拓扑和明确的性能隔离；批量、评测和部分训练任务可以在高峰到来时暂停、降速或迁移。实施混部前，应先根据任务的可抢占性、状态保存成本和恢复窗口进行分层，再确混部收益来自潮汐互补，但要以干扰可测为前提。平台需要持续观察联机任务时延、离线任务被抢占次数、检查点开销、迁移耗时和整体资源碎片率。当共享导致关键服务SLA下降，·需要明确性能隔离确定可共享的资源范围批量/评测/符合条件的训练任务可暂停降速迁移目批量推理/评测任务〈1>研发任务断从中断到恢复可接受的时间范围可抢占性任务被中断的可能性和影响程度大模型扩容与通用微服务不同。启动一个实例不仅要拉起进程，还要完成权重装载、通信域建立、算子或引擎初始化以及必要的缓存预热。只有在权重已就近缓存、资源池有可调度余量、运行环境已准备、模型无需长时间编译等条件下，扩容时延才可能显著缩短。因此，不宜把“秒级弹性”作为跨模型、跨硬件的一般承诺，应该按模型大小、权重位置和预热策略分别较稳妥的做法是分层管理热度：高频关键模型保持满足恢复目标的热实例；中频模型维持少量预热容量，靠快速克隆或资源切分扩展；长尾模型可以采用更激进的缩容，但需要接受更长首访时延。容量预测、权重多级缓存、模型池化和预热排程共同决定弹性效果，单一编排平AI任务的故障影响往往跨越设备、模型实例、缓存和长周期状态。韧性设计首先需要明确故障域：单卡、单机、超节点、机架、集群和园区分别应具备怎样的检测、隔离与替代路径。扩大紧耦合资源域可能改善特定负载的并行性能，但也可能扩大故障影响范围，因此需要在性恢复机制也应与任务类型匹配。短请求可以重试或路由到备用实例；长周期任务需要检查点、任务状态和可重放机制；多轮智能体任务还需要保存会话、记忆引用和工具执行状态，避免“算力恢复了但任务上下文丢失”。涉及扣款、提交、放款或写入等外部动作时，重试前必须先确认执行回执与幂等条件，再决定是否重放，防止基础设施层的重试造成业务重复执行；算力层负责恢复资源和模型实例，任务从何处接续由中枢运行时判断。RTO、RPO、允许重试算力架构可以形成共同能力框架，但不应按机构规模直接套用建设模式。采用自建、托管还是共享模式，主要取决于负载特征、数据边界、连续性要求和运维能力：高敏数据是否必须本地处理，关键任务需要什么连续性，稳态负载是否足以支撑长期资产投入，机房是否具备电第一看负载稳定性。长期高利用、模型和业务相对稳定的负载，更容易支撑自建资产；需求不确定、波峰明显或模型更替较快的场景，则需要更高弹性。第二看数据与模型边界。涉及高敏客户数据、核心模型或监管约束的任务，需要明确数据驻留、访问控制和外部处理限制。第三看连续性。对客关键服务、风险监测和生产链路需要确定容灾、备份与替代模型路径。第四看运维能力。异构芯片、驱动、推理引擎、网络和液冷系统需要长期运营能力，如果组织无满足业务需求与长期发展·电冷系统机构规模可作为背景因素，但不能替代四类条件的判断。·数据驻留要求自建/托管/共享，按条件匹配从四类条件评估建设可行性图4-6投入前置判断与建设模式自建适合负载较稳定、数据边界严格、长期资源利用可预期且具备设施和技术运营能力的场景，优势是版本、数据、SLA和成本结构可控，代价是前期投入、折旧、机房和适配责任较重。专属托管适合需要隔离资源、跨地域部署或阶段性快速扩容，但机构仍需要管理网络、SLA、数据销毁、故障响应和退出迁移。共享或服务化供给适合研发验证、低敏通用任务和峰值弹性，优势是起步快、技术更新快，风险在于价格变化、供应连续性、集中度和数据处理边实践中可以形成“稳态能力自持、弹性能力受控补充”的组合，也可以主要依托区域或行业平台，同时保留关键任务的本地应急能力。关键不是追求哪种模式占比更高，而是为每类任4.4.3以运行结果校准投入：容量规划形成闭环峰值规律、排队时间、资源碎片、缓存命中、网络与存储等待、SLA达成、故障影响、卡时、能耗和成本，再把这些结果反馈到容量规划。确认预留超出既定连续性和峰值保障需求后，可回收或扩大资源共享。对模型与上下文变化引起的成本上升，应先区分必要需求增长与可优化这种闭环也有助于避免对增长速度作脱离场景的统一判断。智能体应用确实可能显著增加推理需求，但增长幅度受用户规模、任务复杂度、模型选择、上下文长度、缓存命中和自动化程度共同影响，不能简单用“百倍级增长”作为普遍规划的前提。更稳妥的方式，是用真实任务量和单位任务资源曲线滚动预测，并通过容量水位和弹性资第五章词元篇：第五章词元篇：算力可用只是基础，业务真正需要的是能够满足质量、时效和成本要求的词元服务。同一项制度问答、材料审核或复杂分析任务，采用不同的模型、上下文、检索结果和推理方式，可能产生明显不同的任务效果和服务成本。高能力模型有助于处理复杂任务，但如果简单任务也全部调用高规格模型，会造成不必要的消耗；反之，过度压缩上下文或一味降低模型规格，也词元篇围绕任务建立模型服务的经营逻辑：需求识别先明确规则、检索、小模型或大模型统一接入和服务等级管理，将经过验证的模型能力转化为可交付的词元服务；消耗优化减少上下文、缓存、推理引擎和调用路径中的重复计算与无效调用；经营反馈再把模型服务成本关联到完整任务结果。词元是用量与成本的计量单位，任务才是经营对象。“有效词元”在本章中指模型服务在既定质量、时延、成本和连续性边界内有效支撑任务完成，不表示每一枚词元都词元的有效供给，既取决于模型选择、推理效率和消耗管理，也依赖专业知识与任务执行现行、适用且有权使用，执行过程是否符合业务规则，都会影响最终结果。因此，