1. 重新理解信创：Agent产品落地的新底座

1.1 信创到底改了什么——不只是换操作系统

很多朋友第一次接触信创项目时，脑子里跳出来的第一个念头是：“不就是把Windows换成麒麟，把Oracle换成达梦嘛？”但真把国产Agent产品往这套环境里一放，问题立刻就复杂起来了。

信创的全称是信息技术应用创新，落在Agent产品上其实涉及四层：第一层是芯片与整机，比如飞腾、鲲鹏、海光、龙芯这些；第二层是操作系统与基础软件，包括麒麟、统信UOS、openEuler这些OS，以及国产中间件；第三层是数据库、缓存、消息队列这些数据组件；第四层才是业务应用，Agent产品恰好就站在第四层，并且它还要反向依赖前两层的全部能力。

我做一个不太严谨但很形象的类比：以前你在x86服务器上部署Agent，就像是给一辆标准底盘的车装发动机，市场上所有零件都是配套的；到了信创环境，底盘及底盘上的每一个接口都换成自主品牌了，你那个发动机虽然是好的，但进气道、排气管、仪表盘全都不一样。所谓适配，就是让发动机跟新底盘严丝合缝地咬合在一起。

所以信创对Agent产品的影响，不是“能不能跑”这么简单，而是“跑得快不快”、“稳不稳”、“出问题能不能查”。很多时候大家做完适配测试，第一轮觉得功能都通了，但一上生产环境就暴露问题：国产数据库的锁机制和并发控制行为和Oracle不一样，导致Agent在做知识库写入和会话状态存储时出现偶发死锁；ARM架构的推理节点上某些Python依赖没有预编译wheel包，编译一次耗时惊人。这些都属于“换底座”之后必然遇到的坑。

1.2 Agent产品为什么要主动适配信创

有人会问：我的Agent产品明明在通用x86云服务器上跑得挺好，为什么非要往信创环境里搬？答案是：客户在哪，产品就得在哪。

做政企、央国企、金融、医疗、能源这类行业的项目，交付现场对信创是有明确要求的。客户的基础设施已经按信创标准规划，你如果不适配，连入场资格都没有。尤其是那些涉及数据敏感的场景，客户对软硬件自主可控的要求是硬性的，不是可选项。你给客户一套依赖国外GPU生态和闭源组件的Agent方案，首先在采购环节就过不了关。

另外一个现实原因是技术演进。现在的信创算力已经不是我几年前做原型验证时那个样子了，昇腾、寒武纪、昆仑芯这些加速卡在推理场景的兼容性越来越成熟，配合MindIE、CANN这类推理栈，跑开源模型的性能已经有了质的提升。与其等客户硬压下来再做适配，不如在方案设计阶段就把信创兼容性当成核心需求来对待——这可以省掉后期大量改造返工的时间。

我在实际项目里的体感是：主动适配信创，最大的收益不是“合规”本身，而是让产品的部署形态变简单了。你提前把容器镜像、依赖库、数据库脚本都按信创环境整理干净，现场实施基本就是解压、导入、起服务三步走。如果等到客户验收时才来研究CPU架构差异和操作系统兼容性，那现场的焦头烂额真的会把人逼疯。

1.3 一套典型信创Agent架构长什么样

讲适配之前，先给一套我在几个项目中反复使用的主干架构，大家可以把这个当成基准架构来看。

典型组网大概是这样的：

• 接入层：通过统一API网关暴露Agent服务，网关做鉴权、限流和审计，这是安全的第一道闸。
• 应用层：承载Agent的编排逻辑、会话管理、工具调用（function calling）、记忆模块，无状态化设计，方便横向扩容。
• 模型推理层：承载向量化模型和生成式模型的推理服务。信创环境下通常用国产加速卡或高性能CPU推理，模型多为开源的中文基座模型。
• 数据层：Agent的知识库、会话历史、业务数据分库存储。在实际信创项目中，我会把关系型数据放国产数据库（如达梦、人大金仓），向量数据放Milvus或Elasticsearch，缓存用Redis（信创环境也有国产替代版本）。
• 安全与审计层：统一身份认证、密钥管理（KMS）、日志审计系统、数据防泄漏（DLP）探针，全部单独部署。

这套架构的好处是每一层都有明确的国产化替代方案，也方便客户安全团队逐层做检查。记住一个原则：Agent产品在信创项目里永远不是孤立交付的，它是嵌在客户整体数据安全体系里的一个“智能组件”。所以你交付的不只是模型和代码，还有一整套和客户安全组件对接的能力。

2. 数据安全合规：过不了这几关别谈上线

2.1 数据分类分级：先给数据定“身份”

数据安全合规的第一件事，不是加密也不是审计，而是先搞清楚你的Agent到底会碰哪些数据。没有分类分级，后续所有的权限控制、脱敏策略、加解密方案都是空谈。

我在项目里通常会把数据分成四个维度来做分类分级：业务敏感度、是否涉及个人信息、是否属于重要或核心数据、数据的开放范围。对于Agent产品来说，尤其要关注“数据的开放范围”，因为Agent天然会跨系统检索和调用，经常会拿到超出它应知范围的数据。

具体做法分三步：第一步，配合客户梳理Agent相关的数据资产清单，包括模型训练语料、RAG知识库文档、会话记录、客户业务系统的结构化数据；第二步，依据客户的分类分级规范，给每类数据打上标签，比如分为L1公开、L2内部、L3敏感、L4机密；第三步，把数据标签映射到Agent的能力范围上，比如L3及以上的数据，Agent只能检索脱敏后的结果，不能直接读取原始文档。

注意，这个映射关系要落到代码里，不能只写一份制度文件。常见的落地方式是在RAG管道中加一层数据访问策略引擎：用户请求进来后，先通过向量检索粗召回候选文档，再由策略引擎根据用户身份和文档标签决定哪些片段可以进入模型的上下文窗口。这层过滤必须发生在送入大模型之前，而不是在生成之后再“补救”，否则敏感信息早已经被模型处理了一遍，理论上存在记忆泄露的风险。

2.2 模型语料和RAG库的边界管控

大模型产品有一个特殊的合规难点：它不仅仅处理显式的输入输出，还会把数据“吞进”参数里。虽然主流开源模型的微调成本让大多数项目不会轻易做全量微调，但RAG知识库的本地化存储、向量化过程、以及推理时的上下文拼接，依然会产生大量的数据流动。

RAG库的敏感信息管控，是我在信创项目里强调最多的环节。一个很容易踩的坑是：客户给了你几百份内部制度文档当作Agent的知识库，文档里面包含了大量涉密字段（员工身份证号、客户联系方式、内部审批意见），这些数据被向量化后存储在向量数据库里。一旦Agent的访问控制做得不够细，任何一个普通用户都可以通过巧妙的提示词让Agent“检索”到本不该看见的内容。

所以RAG库落地的时候，我会强制要求做三件事：第一，入库前敏感信息识别，用规则和NLP模型扫描文档内容，对包含高敏感字段的段落做拆分标签；第二，检索时基于角色的属性过滤，向量检索之外增加元数据过滤条件，比如用户所属部门、职级、数据密级，从物理上排除不合法的文档；第三，输出前做一次敏感内容检测，对模型生成结果再做一次正则和模型双重扫描，防止检索过滤失灵时的数据外泄。

另外要特别提醒一个细节：很多人只检索引文，却忘记了附件。很多知识库文档包含了Excel、PDF里的图片表格，OCR解析出来的结果中敏感信息密度非常高，这部分内容也需要纳入同样的过滤链路，不能成为漏网之鱼。

2.3 认证、加密与密评：Kerberos、国密和等保2.0

Agent产品要接入客户的统一身份认证体系，这是数据安全合规的底线。信创环境里，客户的认证体系通常是基于CAS或OIDC协议，底层目录服务用LDAP或国产目录。值得注意的是，很多大数据平台会启用Kerberos认证，Agent服务端如果要从这些平台拉取数据，就必须认真处理Kerberos票据的获取与更新问题。

这里简单说一下Kerberos的原理：KDC（密钥分发中心）分成AS（认证服务）和TGS（票据授予服务）两个角色。客户端第一次向AS请求时，AS返回一个TGT（票据授予票据），并给客户端和KDC之间建立一把会话密钥；客户端拿着TGT再去请求TGS，TGS发回一张访问特定服务（比如HDFS或Hive）的服务票据。Agent作为服务端集成时，通常用keytab文件里的长期密钥代替用户密码来申请票据，实现无人值守的认证。

在实际项目中，Kerberos集成常见的坑有两个：一是票据有效期设置太短，Agent长任务运行到一半票据过期，访问数据服务直接报错；二是时间同步问题，Kerberos对客户端和服务端的时间偏差容忍度极低（通常小于5分钟），节点时钟漂移会导致认证失败。排查这类问题，第一步永远是检查NTP同步状态，第二步才是看keytab文件的有效性。

加密层面，信创项目绕不开商用密码算法。比较常见的是SM2（非对称）、SM3（哈希）、SM4（对称）。Agent产品在信创环境下的HTTPS改造，至少要支持国密SSL证书的配置；数据库连接和重要数据传输，也需要考虑是否启用透明加密。如果项目涉及“密评”（商用密码应用安全性评估），那就不是“考虑一下”，而是必须在方案设计初期就按密评要求逐项对照，比如密钥管理要有专人负责、密钥全生命周期要有审计日志、密码算法不能使用已知不安全协议。这些看起来是“合规活”，但选型做晚了，改造成本呈指数级上升。

2.4 日志审计与数据防泄漏：出了问题要能追溯

Agent产品比普通应用更需要注意日志审计，因为它有“自主决定调用什么工具”的行为特征，传统应用那种“谁在什么时间做了什么操作”的记录方式完全不够。你不仅要知道用户问了什么、系统回答了什么，还要知道Agent在回答问题之前调了哪些API、查了哪些数据库表、向RAG库检索了哪些文档、上传了哪些附件。

我通常建议把Agent的审计日志拆成两类：一类是功能日志，记录请求处理链路和性能指标；另一类是合规审计日志，记录用户、会话ID、Prompt原文、检索到的文档ID列表、调用的工具名称与参数、生成的回复全文、以及命中的数据分级标签。合规审计日志需要加载到独立平台上，至少保存半年以上，并且不支持任意删除。

DLP这块同样要提前设计。Agent生成的内容如果被用户复制粘贴转发到外部，主体数据安全措施就失效了。政企客户的终端上一般会装DLP终端探针，如果你的Agent产品走的是Web页面，那至少要在前端配合做水印和剪切板管控；如果Agent还提供API给第三方系统调用，那输出内容就要经过敏感信息识别后再出网。经验之谈：这部分最好在需求阶段就和客户安全团队对齐，否则验收时安全测试能列出几十个整改项。

3. 技术选型与适配：从x86到国产算力的迁移逻辑

3.1 硬件层：GPU受限时的推理方案迁移

国产Agent产品部署最大的变数在于算力。x86服务器+英伟达GPU的方案当然性能很好，但信创环境下，客户可能只提供国产芯片服务器，比如鲲鹏920、飞腾S2500配昇腾加速卡，或者海光服务器的DCU卡，甚至干脆就是纯CPU环境。

纯CPU跑大模型，听上去很唬人，实际上通过量化手段是可以做的。开源社区里llama.cpp、Ollama这些都支持在CPU上跑量化后的模型，7B模型配合INT4量化，在主流服务器CPU上大概能到每秒10到20个token，做客服问答、文档助手这类交互延迟要求不高的场景完全够用。如果客户环境有昇腾加速卡，那就可以走MindIE推理引擎，配合CANN工具链，性能比纯CPU高一个数量级。

选型的时候要做的第一件事是画出“可运行矩阵”。我在项目里会把模型、精度、推理框架、芯片组合起来做一份二维表，比如Qwen2.5-7B支持INT4/INT8/FP16，可以跑在CPU、昇腾310P、昇腾910B上；DeepSeek-R1-Distill-Qwen-7B在昇腾上需要配合MindIE-Lite版本，不支持旧版CANN。这张表不是凭空拍脑袋的，而是从厂商文档和社区实测经验里一点点整理出来的。整理完这张表，硬件采购和方案报价才有了依据。

3.2 软件栈：国产OS、数据库和向量检索的适配

软件栈适配是真正磨人的环节，因为细节实在太多。

操作系统层面，麒麟和统信UOS的默认软件仓库和CentOS并不完全相同。安装Python依赖时，常见的坑是有些包在aarch64架构上缺少预编译wheel，只能通过源码编译安装。以transformers和torch为例，在老版本上，aarch64的兼容性经常出问题，必须锁定到特定的兼容版本组合。我建议直接采用容器化封装，把整个Python环境和依赖都打进镜像，规避宿主机OS差异，这是在信创环境里被反复验证过的高效方案。

数据库层面，达梦、人大金仓、openGauss都是兼容PostgreSQL或Oracle生态的，但语法细节和索引行为存在差异。比如人大金仓的并行查询、自动增长序列和Oracle行为有区别，Agent的会话状态表如果设计成依赖自增主键，就需要在初始化脚本里做适配；达梦对某些复杂JSON操作函数的支持也跟MySQL不一样，JSON存储字段建议直接用原生JSON类型，别用TEXT类型自己拼，否则查询和排序都会让你头疼。

向量检索层面，Milvus在信创环境里用得比较多，因为它有独立部署形态，不依赖特定云厂商。ES也是常见选择，但ES的IK分词与向量检索结合的方案在国产OS上需要额外安装插件，建议把ES镜像和插件在项目初期就构建好，现场直接加载。另外，如果你的项目规模不大（比如只有几万个文档片段），完全可以用轻量级的向量方案（如SQLite-VSS对接到国产SQLite版本），省去独立向量库的部署成本。

3.3 一份可以直接抄的国产化替代清单

为了方便大家做方案，我把经常用到的组件做了一个替代清单，这不是绝对标准，但覆盖了Agent产品最常见的组成部件：

这个表的核心逻辑不是“把组件换成国产品牌就完事”，而是“在换的同时确认新组件的行为和旧组件的一致性”。很多现场问题都出在“名字换成国产了，行为也悄悄变了”，比如数据库的默认隔离级别、字符串排序规则、时区处理方式，这些微小的差异都能让Agent的会话状态数据出现乱码或排序混乱。

4. 实战上线：信创环境Agent产品落地的完整路径

4.1 部署前适配排查清单

不要一上来就装机部署，先花半天对着清单过一遍环境，绝对值得。

• 确认CPU架构是x86还是ARM，这会直接决定软件包选型；
• 确认操作系统版本和内核版本，用于匹配驱动和依赖库；
• 确认是否配备国产加速卡，以及加速卡驱动的版本是否与推理框架匹配；
• 确认Python版本（3.8/3.9/3.10）和pip源，信创环境一般需要配置内部镜像源；
• 确认数据库版本和访问方式，拿到数据库初始化脚本模板；
• 确认中间件和网关版本，核对是否与Agent的服务注册方式兼容；
• 确认客户已有的认证体系和权限模型，拿到接口文档或协议说明；
• 确认日志审计平台的对接规范，例如syslog或者HTTP API的推送格式。

这份清单做完，你大概率会发现一些“纸面上看起来没问题但实际不可用”的地方。比如某个组件在客户的技术清单上标注支持ARM，但实际可用的版本是几年前的旧版，无法满足Agent产品对现代指令集或多线程性能的要求。这类问题前置暴露，比在现场再排查高效得多。

4.2 容器化交付和中间件改造

把Agent产品打包成Docker镜像，在信创环境几乎是最优解。容器可以屏蔽操作系统差异，让同一套组件在麒麟、UOS、openEuler上跑出基本一致的行为。但容器化不是万能的，有两点容易出问题：第一，宿主机内核的某些参数会影响容器网络性能，比如TCP连接数限制、文件句柄数上限，这些需要在宿主机上做系统参数调优；第二，国产加速卡的驱动通常需要以特权模式挂载到容器里，镜像构建时不能忽略。

中间件这块，最常见的是Nginx网关和后端服务之间的通信。在信创环境里，如果客户强制要求使用国产中间件，那就要注意东方通或宝兰德这类产品对Spring Cloud Gateway的兼容性问题。我的建议是：网关和中间件尽量选择开源版本，并且在客户允许的前提下，以“开源版本+安全加固”的形态交付，既满足安全要求，也降低技术风险。

4.3 数据接入与API安全治理

Agent产品真正开始接客户业务数据时，安全和稳定性问题才会集中爆发。

数据接入的第一原则是“最小权限”。Agent作为一个服务账号，访问数据库和API的权限要严格限制到业务必需的范围。比如一个做内部制度问答的Agent，它只需要读取制度文档库，那就不应该给它关联业务系统的写权限。很多项目实施时图省事，用DBA账号让Agent连库，这等于把整个数据库的钥匙交给了AI，风险不可控。

API安全治理还有一个容易忽略的维度：Agent的function calling能力。Agent产品通常会定义一批工具，比如“查询员工信息”、“创建工单”、“发送通知”，这些工具本质上是对外暴露的API。一定要给每个工具配置独立的鉴权策略和ABAC属性标签，比如“创建工单”要求用户必须在某部门且拥有指定角色，并且在Agent执行工具调用前，由策略引擎做一次显式的授权校验，而不是完全依赖Agent模型的自主判断。

4.4 验收清单与量化指标

信创项目验收通常包含功能测试、安全测试、性能测试、兼容性测试四个维度。安全测试的重点在于身份认证绕过、越权访问、敏感信息泄露这几个方向，兼容性测试则要覆盖不同的信创浏览器和终端设备。

性能指标的设定不能照搬互联网产品的标准。Agent产品的性能瓶颈通常在模型推理，如果客户要求“对话首字返回小于2秒”，那纯CPU推理的7B量化模型可能勉强达标，但并发用户数一上来就会明显恶化。所以在项目启动时就要和客户确认好性能指标的具体含义——是单用户延迟还是并发下的P95延迟？并发度是多少？是否包含检索耗时？这些不确认清楚，验收时就是扯皮现场。

5. 踩坑记录：真实案例与排查思路

5.1 典型问题速查表

5.2 三个真实踩坑复盘

第一个坑发生在ARM架构服务器上。当时选定了Qwen2.5-7B模型，准备用vLLM框架部署，结果发现vLLM在ARM+CANN编译器组合下报错，问题出在vLLM的某些算子实现依赖特定的CPU指令集，而ARM架构在编译时才暴露出来。最后换成了MindIE-Lite推理引擎才解决。这次的教训是：跨架构部署时，不能只验证主流推理框架，要把所有候选框架都在目标硬件上做一轮冒烟测试，否则生产环境的意外会让你措手不及。

第二个坑是数据权限过滤的绕过。当时我们给RAG库加了部门过滤，测试时候发现，用部门A的账号通过巧妙的提示词让Agent输出部门B的文档标题，虽然正文因为过滤被拦住了，但标题和摘要片段还是因为composition的问题泄露了。后来我们重新设计了流程：在向量检索阶段就根据账号属性过滤候选集，同时把文档的“标题+摘要”整体作为一条元数据记录进行同样的权限校验，问题才根治。这也说明Agent安全不能只看一面，要“入口过滤+输出校验”双重卡关。

第三个坑是会话状态存储。Chat类Agent天然会把上下文存进数据库，起初用了MySQL的JSON字段存会话状态，数据量小的时候没感觉，后来客户要求保留一年以上的会话记录，查询“某用户最近30天所有会话”时延迟飙升。数据库切换成国产数据库后，这个问题被放大了——国产数据库对复杂JSON搜索的优化尚不如原版。最终我们把会话状态拆成了“元数据表+消息表”两张表，靠标准SQL分页查询，性能才恢复正常。

6. 运维与调优：上线之后才是考验

6.1 国产环境的性能调优

Agent产品上线后的调优重点有两个：模型推理性能和检索链路性能。

推理性能方面，首选是模型量化。FP16到INT8的精度损失在大多数问答场景是可接受的，INT4需要谨慎评估，因为长文本生成时语义漂移会更明显。第二个手段是并发控制。在国产CPU或加速卡上跑模型，千万不要试图把并发数拉到最大，线程切换开销会吃掉大部分收益。我从实践中的经验是，先并发1路压测，观察延迟和资源利用率，再逐步增加并发数，寻找吞吐量曲线中的拐点，并留20%余量作为生产水位。

检索链路方面，最大的瓶颈往往在Embedding模型对长文档的分块处理上。建议对知识库文档做精细的分块策略：结构化文档按标题和段落切分，表格单独切块；固定200~500字的分块并不适合所有场景。上线后还要关注RAG的召回率，如果用户问题经常答非所问，很可能是分块粒度不合适或向量模型与领域词汇不匹配，可以做一次“用户问题聚类分析”，再针对性调整分块策略。

6.2 安全基线的持续运维

安全合规不是上线那一刻的“一次性工作”，而是持续的过程。Agent产品在运行期间，模型权重和配置会被更新，知识库增删文档也会影响安全边界，所以运维端一定要建立几条安全基线：

• 模型权重文件的完整性校验机制，防止被篡改；
• 知识库文档的新增审批流程，敏感文档入库前必须过安全扫描；
• 日志审计的每日巡检，重点看是否有异常的敏感数据检索行为；
• 依赖库和基础镜像的定期漏洞扫描，信创环境下尤其要关注上游软件包源的更新滞后问题；
• 密钥和票据的轮换周期，Kerberos keytab和API Token都要有自动轮换脚本。

还有一点常常被忽略：Agent模型本身可能被持续注入恶意指令，导致“该回答的不回答、不该调用的工具却被调用”。虽然技术上很难完全根除，但可以通过上线后的日志分析捕捉模式：比如某个用户反复诱导Agent执行高风险工具调用，这类行为应触发告警并进入风控名单。把安全运维从被动响应变成主动监测，这是Agent产品规模化交付必备的能力。

7. 讲了这么多，最后说几句实在话

我做了这么多信创环境下的Agent产品落地项目，最大的心得是：这个领域没有捷径，也没有“一招鲜吃遍天”的方案。数据安全和信创适配看起来是“硬性要求”，但实际上它们反而能逼着我们把产品做得更干净、更规范。有几个细节想再强调一下：

第一，凡是涉及数据权限的代码，一定要尽早设计、尽早测试，千万不要等到客户安全团队来“找茬”时才补。我在项目上吃的亏已经够多了，权限过滤补丁打多了以后，代码逻辑会越来越绕，运维难度直线上升。

第二，信创环境的兼容性验证，千万不要只信文档。厂商的兼容性列表写得再天花乱坠，都不如在客户给的真实硬件上跑一次基准测试来得硬核。每次部署适配，我都会预留至少两到三天的“技术验证时间”，专门用来实测推理框架、数据库连接、模型量化和日志推送这些关键路径。宁可前期慢几天，也不要上线后折腾几周。

第三，Agent产品在信创环境下的性能指标一定要留余地。客户说“首字要2秒”，你按1.5秒目标来调优；客户说支持20并发，你按30并发压测。这个领域变量太多了，OS、中间件、加速卡驱动版本稍有变化，性能就可能有20%以上的波动。给自己留冗余，其实就是给项目留生存空间。

最后再分享一个小技巧：在信创项目里，把每次部署适配遇到的坑和解决方案整理成一份内部的“环境兼容性知识库”，不用很复杂，就是Markdown文件加一个目录索引。这个动作看起来不起眼，但在做第二个、第三个同类项目时，它能让你从“现场救火”变成“按图施工”，省下的时间和精力，比你加一个月班都值。