一、AI应用架构的演进与核心范式
传统架构是"给系统加AI功能"，AI仅作为外挂模块存在；而AI原生架构是"用AI重构系统"，以大模型为核心驱动核心业务流程。在AI原生架构下，整体设计应具备三个核心特点：以智能体为中枢驱动业务行为，由Agent根据上下文、工具和业务意图进行动态编排与决策；模型选择是动态的，通过智能路由实现各类大模型的自由切换；通过MCP协议拓展模型能力，接入各类业务系统。整体可概括为：Agent为中枢、LLM为大脑、MCP为手。
二、AI应用分层架构设计
七层架构模型
学术界提出了AI计算架构的七层模型，从底到上依次为：物理层（Physical Layer）、链路层（Link Layer）、神经网络层（Neural Network Layer）、上下文层（Context Layer）、智能体层（Agent Layer）、编排层（Orchestrator Layer）和应用层（Application Layer）。
7层核心架构（自上而下）：
- 业务应用层：面向最终用户的业务场景，如智能问答、数字员工、ChatBI、智能客服等
- 应用网关层：统一接入终端请求，负责流量路由、身份认证、AI安全防护
- AI Agent Core（智能体核心层）：所有业务逻辑和任务的编排中心，由Agent进行动态决策和调用
- AI网关层：连接Agent与底层模型/工具，负责模型路由、Token配额管理、内容安全过滤
- 大模型层：各类LLM的接入与管理，支持多模型动态切换
- 知识与数据层：向量数据库、知识库、业务数据的存储与检索
- 基础设施层：GPU/NPU算力资源、容器编排（K8s）、存储等底层支撑
侧横切关注点：可观测性 & 评估、安全治理 & 合规------这两者贯穿所有层级，是保障AI系统稳定运行的关键。
三、核心组件详解
（一）智能体（Agent）- 架构中枢
1、Agent 和聊天机器人到底差在哪？
聊天机器人的工作模式是"一问一答"，对话结束它不会主动做任何事。Agent 的工作模式是"给一个目标，它自己想办法完成"-你告诉它"帮我整理这周的销售数据并找出异常"，它会自己规划步骤：先查数据库、发现数据量太大需要聚合、写 SQL 做汇总、发现某个区域数据异常、深入查询明细、最后生成分析报告。
这个差异的本质是控制权在谁手里。如果分支与顺序在编码阶段就写死了，那是工作流；如果下一步调用哪个工具、要不要再试一次，是模型在运行时看着执行结果临时决定的，那才是 Agent。
Agent 处在大模型应用能力层次的"行动层"-模型不再只是回答问题，而是去调用外部系统、读取真实数据、修改真实状态，并根据执行结果调整下一步。工程形态从"提示词技巧"转向了控制流、状态管理、错误处理和权限控制。
2、架构中枢图解
理解 Agent 架构有两个视角：横向的栈式分层（每一层解决什么工程问题）和纵向的中枢闭环（核心组件如何协同运转）。两个视角结合起来，才能看清全貌。
2.1 横向：Agent 技术栈的六层架构
2024年Letta发布的AI Agent 栈图曾成为半个工程团队的默认参考。到2026年，这个栈已经演变为六个独立层，其中至少三层在原始版本中还不存在。
2024到2026年间，有三件事重新画了这张图：MCP标准化了工具连接，工具层因此成为独立类别；推理模型改变了Agent 能自主完成的事情，单次调用Agent开始替代部分多步链；记忆成为一等架构原语，不再只是向量数据库的附属功能。
每层的关键工程问题：记忆层和框架层是状态管理最困难的地方，也是多数团队卡住的位置；协议层涉及供应商锁定风险，MCP是开放标准，供应商原生SDK不是。
2.2 纵向：四个核心组件的中枢闭环
从功能组件角度看，一个完整的Agent架构围绕 规划、记忆、工具调用、执行与反思四个模块构成闭环。
规划模块的拆解不是预设的，而是根据目标和可用工具动态生成的。如果中间步骤的结果不符合预期，规划模块需要调整后续步骤。记忆模块让Agent不会"转身就忘"，它知道自己已经做了什么、接下来要做什么。工具的种类和质量直接决定了Agent 的能力边界：一个只能"聊天"的Agent和一个能"操作十几个业务系统"的Agent，完全不是一个物种。反思循环则是Agent区别于固定流程 Workflow 的关键-如果结果不符合预期，分析原因并调整方案。
3、编排层：中枢的"调度台"
在纵向闭环之上，编排层处于接入层和智能体核心层之间，负责任务级别的调度。对于复杂任务，编排层要做三件事：拆解（把大目标分解为可并行的子任务）、分派（决定每个子任务由哪个Agent或哪个工具执行）、协调（管理多个Agent之间的依赖和通信）。
多Agent协作有两种典型拓扑：层级式（一个编排Agent作为监督者，动态分派任务给研究Agent、分析Agent、写作Agent等专业角色）和顺序式（流水线模式，每个Agent处理一个环节后传给下一个）。真实生产系统中，混合形态最常见-外层用工作流保证关键路径可控，把"路径不确定"的环节包成Agent节点嵌进去。
4、业务示例
4.1 金融展业合规智能体-在强规则场景中嵌入不确定性处理
4.2 系统架构图
4.3 运行时序图-一次展业沟通中的合规检测
4.4 模块职责
|---------|-------------------------------------------------|------------------------|
| 模块 | 在本案例中的职责 | 关键输入/输出 |
| 编排层 | 创建合规检测任务；Workflow主干保证关键路径可控；Agent分支处理不确定性；按风险路由 | 输入：对话/材料；输出：提醒、工单、审计记录 |
| 记忆层 | 沉淀监管规则、过往案例、违规话术/模式 | 检索规则与相似案例；沉淀新案例 |
| 工具层 | 连接产品数据库、客户信息系统、规则引擎、审计日志、人工工单 | 拉取产品/客户上下文；写审计；触发人工 |
| Agent核心 | 实时理解沟通内容；判断是否违规；推理规则在具体情境下如何适用；生成修正建议 | 输出风险等级、理由、修正建议 |
| 人工兜底 | 高风险时合规专员复核与处置 | 处置结果反馈，沉淀回案例库 |
5、架构选型实用判断
在设计Agent系统时，最容易犯的错误是用Agent的架构做工作流的事。一个实用的判断标准是：如果某个任务的步骤在编码阶段就能完整枚举，那就写工作流；只有当"下一步做什么取决于上一步的结果，而结果在运行前无法预测"时，才需要Agent。
Agent技术栈的六层结构本身就是这个判断的延伸：不需要管理复杂状态的场景，用模型层 + 工具层就够；需要跨会话记忆和自主规划的场景，记忆层和编排层才成为必需品。在每一层增加复杂度之前，先问清楚------这一层要解决的问题，在当前场景中是否真实存在。
（二）AI网关-连接枢纽
1、AI网关的位置-它解决什么"连接问题"
AI网关的核心价值，是把所有AI调用入口收拢成一个统一控制点-它不只是"转发请求的路由器"，而是承担了协议收敛、Token治理、语义缓存、安全护栏、多模型故障转移和成本归因的治理中枢。
在LLM应用落地过程中，如果让每个应用直接连接模型供应商，会暴露显著风险：深度绑定单一模型导致切换成本极高、无法精确统计各租户的Token消耗形成FinOps盲区、敏感数据在未脱敏情况下直接流向公有云。AI网关的核心价值在于建立一个统一入口，让所有AI/LLM交互通过一个集中控制点完成，从而抽象掉多供应商的复杂性、执行治理策略、追踪成本并提供统一可观测性。
这种定位可以从"从网关到AI网关"的演进脉络来理解：传统流量网关管理的是"流量"，API网关管理的是"接口/服务"，而AI网关管理的对象变成了"模型"和"智能体"，面对的挑战从服务粒度转向了模型推理、Token管控、内容安全等全新维度。
AI网关是API网关的一个专门分支，治理对象从"普通 HTTP 请求"变成了"大模型调用"。两者的核心差异不在功能列表，而在计量单位和失败模式：传统网关按请求数限流，AI网关必须按Token数计费与限额；传统网关遇到502重试即可，AI网关需要在模型返回429时自动切换到备用模型。
2、核心架构-控制面与数据面分离
AI网关普遍采用控制面 / 数据面分离的架构模式。控制面负责配置和管理，数据面直接承接用户流量并转发给后端模型服务。
控制面会将变更后的网关配置准实时下发至数据面节点；数据面识别到配置更新后，在运行时动态切换代理逻辑，同时保证老的逻辑处理完当下已分配的请求，实现无损更新。
B站在实际落地中将数据面的请求过滤器抽象为两类：请求过滤器作用于原始请求，处理鉴权、限流等逻辑；模型过滤器作用于请求转发至具体模型时，处理API兼容逻辑，例如深度思考标签 `<think>`的处理、推理引擎自定义参数的兼容修正等。
3、核心功能模块-数据面处理流水线
请求进入 → 鉴权 → 限流 → 语义缓存查找 → 安全护栏(输入) → 路由选择 → 模型调用 → 缓存写入 → 流式缓冲 → 安全护栏(输出) → 审计日志 → 响应返回
|-------------|-------------------------------------|
| 功能模块 | 关键机制 |
| 统一鉴权 | API Key / JWT / HMAC，每个Key可授权不同模型范围 |
| Token级限流 | TPM（每分钟Token 数）配额，而非请求数配额 |
| 语义缓存 | Embedding → 向量检索 → 相似度阈值判定 |
| 安全护栏 | 输入/输出双向敏感词与合规过滤 |
| 路由与Fallback | 主模型429/超时 → 毫秒级切换备用模型 |
| 协议转换 | OpenAI/Claude客户端协议双向翻译 |
| 流式处理 | SSE / HTTP/2流式响应，无缓冲区代理 |
| 可观测性 | Token消耗、QPS、首包RT、缓存命中率、错误率 |
语义缓存是AI网关独有的优化手段。它不要求两次请求的文本完全一致，而是将请求通过 Embedding转为向量，在向量库中检索语义相似的已缓存响应。实测命中率可接近 60%，准确率F1达到0.89，命中时直接返回缓存答案，跳过昂贵的LLM调用。阿里云AI Gateway 的做法是双引擎：Redis精确缓存 + DashVector语义缓存。
安全护栏需要嵌入数据面主链路，而非旁路挂载。Higress接入Qwen3Guard 的方式是把内容提取、安全外呼、风险决策、流式缓冲和拒答整形全部放进请求与响应真正经过的数据面链路中，按 `maxBodyBytes` 设置缓冲上限。Cloudflare的身份感知AI网关则会在请求发出前自动剥离员工姓名、密码等敏感数据。
4、部署拓扑-控制面托管+数据面自管
Kong的AI Gateway采用混合部署模型：控制面由Konnect全托管，提供集中式UI和API来配置AI实体（AI Providers、AI Models、AI Agents、AI MCP Servers、AI Policies、AI Consumers 等）；数据面是运行在用户自己基础设施中的代理节点，接收LLM请求流量。
5、业务示例
5.1 三诺生物的AI应用
5.2 体系总览：四层架构的分层逻辑
三诺生物的AI体系并非简单的"应用叠加"，而是围绕"感知---评估---干预"糖尿病智慧管理闭环 构建的四层递进架构。从底向上依次为：
|-------|------|--------------------------------|--------------------|
| 层级 | 核心命题 | 关键组件 | 解决的业务挑战 |
| 观测层 | 全局可视 | Token消耗监控、响应延迟追踪、调用链路审计 | Token消耗与响应延迟缺乏全局可视 |
| AI防护层 | 合规可信 | 数据安全治理、算法审计、权限管控、ISO 27001体系 | 个人健康数据敏感、医疗器械行业合规 |
| AI平台层 | 统一底座 | SinoGPT垂直大模型平台 + iCanNet可信数据空间 | 多厂商API碎片化适配 |
| AI应用层 | 场景落地 | 五大并行AI应用 | 慢病管理场景的多样化需求 |
这一架构的演进逻辑是：从工具应用到组织进化，将AI深度嵌入核心业务流程，而非简单工具化应用。三诺自2022年起前瞻性提出深度布局AI的战略，用三年时间完成了从战略布局到技术落地的"三级跳"。
关键技术底座由三层构成：动态血糖仪精准感知 → iCanNet可信数据空间治理 → SinoGPT垂直大模型思考，让CGM从"监测设备"进化为全天候在线的"AI控糖管家"。
5.3 AI应用层：五大场景×多厂商接入
|--------|----------------------------|-----------------------------------|
| 应用场景 | 核心功能 | 技术实现 |
| 周期性评估 | 基于CGM连续血糖数据的趋势分析与阶段性健康报告生成 | 专属血糖分析模型 + 深度学习算法挖掘血糖变化规律 |
| 异常波动分析 | 识别血糖异常波动的诱因（饮食、运动、睡眠、情绪等） | 多维数据关联分析（打通华为运动健康平台行为数据） |
| 升糖预测 | 基于历史数据和实时监测，预测未来血糖走势 | 餐后血糖评价模型 + AGP血糖特征定位等垂直场景专用AI模型矩阵 |
| 饮食相机 | 拍照识别食物，自动估算升糖负荷并关联血糖变化 | AI图像识别 + 个人食物升糖库构建 |
| 饮食指导 | 个性化饮食建议，形成"记录-分析-优化-再指导"闭环 | 小诺智能体对话式交互 + 动态干预方案生成 |
多厂商接入格局：三诺已与阿里、华为、京东健康等合作打造AI慢病管理闭环，首批接入蚂蚁阿福，并与荣耀达成生态合作将小诺智能体延伸至腕上终端。应用层的并行接入意味着同一业务能力需要面向不同大模型供应商的API规范进行适配-这正是平台层需要解决的核心问题。
5.4 体系核心逻辑
第一，平台层做"收敛"，应用层做"发散"。SinoGPT将多厂商大模型适配、业务能力编排、数据治理统一收敛到平台层，使五大AI应用可以专注于场景逻辑本身，而不必为每家模型厂商的API差异重复开发。
第二，防护与观测是合规的"基础设施"而非"附加功能"。在医疗器械行业，AI输出的可追溯性、数据访问的可审计性不是可选项。iCanNet的数据可信度校验、专项数据安全治理团队的算法审计机制、以及DSLC流程的全程日志记录，共同构成了合规底座。
第三，三层技术底座支撑一个战略目标。"动态血糖仪精准感知 → iCanNet可信数据空间治理 → SinoGPT垂直大模型思考"的三层结构，最终指向的是让CGM从监测设备进化为"AI控糖管家"，实现从"中国血糖仪普及推动者"向"全球领先的糖尿病数字管理专家"的战略跃迁。
6、模块职责
|-------------|---------|--------------------------------------|
| 模块 | 核心职责 | 关键能力 |
| 控制面 | 配置与管理 | 模型注册、消费者管理、策略配置、审计查看 |
| 数据面 | 流量处理 | 鉴权、限流、缓存、护栏、路由、Fallback |
| 统一鉴权 | 身份与权限 | API Key/JWT/HMAC，细粒度模型级授权 |
| Token限流 | 用量管控 | 按TPM 配额，而非请求数；防止单租户击穿后端 |
| 语义缓存 | 成本与延迟优化 | Embedding + 向量检索 + 相似度阈值；命中跳过 LLM 调用 |
| 安全护栏 | 内容合规 | 输入/输出双向过滤，嵌入主链路而非旁路 |
| 路由与Fallback | 高可用 | 多模型负载均衡，429/5xx自动切换备用模型 |
| 协议转换 | 兼容性 | OpenAI/Claude 协议双向翻译，支持MCP工具治理 |
| 可观测性 | 透明治理 | Token 消耗、QPS、首包 RT、缓存命中率、成本归因 |
（三）RAG（检索增强生成）- 知识增强
1、RAG到底在解决什么
直接让大模型回答私有知识的问题，有三个绕不过去的坎：
上下文窗口受限：即使模型支持长文本，输入信息量一旦过大，模型会出现"迷失在中间（Lost in the Middle）"的现象，准确率直线下降。
推理成本高昂：按Token计费的模式下，每次提问都携带几十万字的长文档，API调用成本不可承受。
推理速度极慢：海量输入上下文导致模型消化时间指数级上升，用户体验极差。
RAG的破局思路是：不要求大模型死记硬背整本书，而是给它配一个"超级图书馆管理员"。
用户提问时，先去知识库里把最相关的几段话找出来，再让大模型看着这几段话来回答。
这个差异的本质是知识来源的分离：模型负责语言理解和推理，知识库负责事实供给。模型不再需要"记住"一切，只需要"读懂"检索到的上下文。
2、RAG全局架构
离线索引流水线回答的是"知识怎么存进去"：文档经过预处理、分块、向量化，最终存入向量数据库和全文索引。这一步通常在生产环境外完成，可以容忍较高的计算成本和较长的处理时间。
在线检索生成流水线回答的是"问题怎么被回答"：用户提问后，系统先改写查询，然后同时走向量检索和关键词检索，融合重排后取Top-K片段拼入Prompt，交给LLM生成回答。
评估层是两个流水线之间的反馈回路：通过RAGAS等框架量化检索和生成的质量，把Bad Case归因到具体环节，反哺分块策略、检索参数和提示词模板的优化。
3、数据准备-从文档到知识库的五个步骤
这是RAG最容易被低估的环节。真实系统中，检索质量的上限在数据准备阶段就被决定了。
步骤1：预处理与提取
从PDF、Word、HTML、数据库等异构来源中提取干净文本。需要处理：文本格式标准化、特殊字符处理、去除无关或过期内容、跟踪不同内容版本、处理含表格/图片的内容、提取元数据。元数据（来源、版本、权限、时间）在检索时可以用于过滤和权限控制。
步骤2：分块（Chunking）
机器处理信息的颗粒度不能太大，需要将长文档按规则切分成独立文本片段。分块策略直接决定了检索的召回和精度上限。
|-------|--------------------|----------------------------|
| 分块策略 | 适用场景 | 关键参数 |
| 固定长度 | 通用起点，结构不明显的文档 | 400~512 tokens，10%~20%重叠 |
| 递归分块 | 结构化文档（Markdown/代码） | 按标题层级递归切分 |
| 语义分块 | 叙述性内容，段落边界模糊 | 相似度阈值0.5~0.8 |
| 结构化分块 | 表格、合同条款、法规条文 | 按章节/条款/表格行切分 |
2026年的工程默认建议是：从RecursiveCharacterTextSplitter起步，400~512 tokens，10%~20%重叠；只有当评测指标显示需要时，才转向语义或页面级分块。重叠是防止切断语义的保险，从0加到20%时召回提升很明显。
步骤3：向量化（Embedding）
将文本块通过Embedding模型转为高维向量。关键特性：语义相近的句子，转换后的向量在多维空间中的距离也非常近；反之则相距甚远。
步骤4：索引构建
将文本块、对应向量和元数据一起存入向量数据库。注意，向量仅用于空间匹配，数据库中必须同时存储原始文本。同时构建全文索引（BM25），供混合检索使用。
步骤5：更新策略
知识库不是一次性的。文档更新、新增、下架都需要同步到索引中。常见方案是增量索引：只对变更的文档重新分块和向量化，避免全量重建。
4、在线检索生成-一次请求的完整旅程
查询改写是检索优化中最大的单点杠杆。在多轮对话中，用户的提问常常包含指代（"它"、"那个"），直接拿去检索效果很差。用LLM把上下文依赖的问题改写为独立查询，可以一步把正确答案从第2~4名提升到第1名。实测中，查询改写带来的提升是8/8的问题都能被正确检索到。
混合检索同时执行向量检索（语义匹配）和BM25关键词检索（字面匹配）。向量检索能理解"换个方式说的同一件事"，BM25能精确匹配产品型号、法规编号等专有名词。两者是短板互补，混合检索的结果优于任何一种单一策略。
有一个重要的行为差异需要记住：向量检索永远会返回k个结果，即使最近的邻居其实并不相似。文档的原话是"即使没有更接近的向量，它们仍然是最近的向量"。所以一个完全离谱的问题，向量检索也会一本正经地给你k个答案，只是分数都很低。关键词检索遇到没有的词会老老实实返回零结果。
RRF融合（Reciprocal Rank Fusion）负责把两路召回结果合并成一个候选列表。它不看原始分数，只看排名：每个列表给文档贡献 1/(k+rank) 的分数，然后重新排序。这样避免了向量相似度和BM25分数不可直接比较的问题。
Cross-Encoder重排在漏斗尾部做精排。向量检索和BM25都是"粗筛"，重排模型逐个审视"查询-文档"对，给出更精确的相关性分数。重排候选集大小从20~50起步，更大给重排更多素材，但延迟和成本同步上涨。重排的价值在候选池里有多个长得很像的选项时才体现-也就是在真实的、几十万条规模的知识库里。
上下文组装与生成：将Top-K片段按相关性排序后拼入Prompt。标准RAG prompt由三部分组成：指令（你是严谨的问答助手，只根据材料回答，材料没有就说"我不知道"）、上下文（检索到的材料片段，标注编号）、用户问题。指令中应要求模型在答案末尾标注引用的材料编号，实现引用溯源。
5、检索优化-从朴素RAG到生产级RAG
朴素RAG只做"向量检索+直接拼接"，在真实业务中远远不够。生产级RAG在检索链路的每个环节都有优化手段
|------|---------------|-----------------|--------------------|
| 优化层 | 技术 | 解决什么问题 | 关键参数/工具 |
| 查询层 | 查询改写/扩展 | 多轮指代、词汇鸿沟 | LLM 改写，Nano-LLM 也可 |
| 检索层 | 混合检索 | 语义匹配 vs 字面匹配的互补 | 向量 + BM25 并行 |
| 融合层 | RRF | 两路分数不可直接比较 | k=60常用 |
| 重排层 | Cross-Encoder | 粗筛后的精排 | 候选集20~50 |
| 上下文层 | 压缩/去噪 | 减少无关片段干扰 | LLM压缩、MMR多样性 |
微软Azure AI Search 的标准做法完整复刻了这套架构：一次请求里同时带 `search`（全文）和 `vectorQueries`（向量），两者并行执行；用RRF把两路结果融合；在融合结果之上用从必应迁移的深度模型做语义重排，取前50条重新打分。
6、评估-怎么知道RAG系统"答得准不准"
|--------------------------|-------------------------|--------------|
| 指标 | 衡量什么 | 输入数据 |
| Faithfulness（忠实度） | 生成的答案是否忠于检索到的上下文，有没有编造 | 回答 + 检索上下文 |
| Answer Relevance（答案相关性） | 回答是否真正针对用户的问题，有没有跑题 | 回答 + 用户问题 |
| Context Precision（上下文精度） | 检索结果中相关片段是否排在靠前位置，噪声多不多 | 检索上下文 + 参考答案 |
| Context Recall（上下文召回） | 检索结果是否覆盖了回答问题所需的所有信息 | 检索上下文 + 参考答案 |
RAG评估的核心框架是RAGAS，它把RAG质量拆成四个可量化的维度：
这四个指标覆盖了RAG两个阶段：Context Precision和Context Recall衡量检索器的质量，Faithfulness和Answer Relevance衡量生成器的质量。当系统答错时，先看是检索没找到（Recall低）还是生成编造了（Faithfulness低），才能对症下药。
KDDI 在开发 Buffmee时，用Gemini Enterprise Agent Platform Evaluation Service实现了自动化评估，用 LLM-as-a-Judge 替代人工测试。他们构建了数百个自动化测试用例和基准数据集，groundedness 分数提升了25%。
7、业务示例
川崎重工-3000页质量规程的RAG检索门户
7.1 业务背景
川崎重工的能量解决方案与船舶事业部，有大量质量相关规程。仅设计审查规程（不含细则）就合计约 3000页。全6个阶段的审议会必须通过才能进入下一制造阶段。员工要从这3000 页中找到业务所需的信息，需要一定的知识和经验，检索环境的整备成为课题。过去曾出现找规程对应位置耗时过长、遗漏的情况。
原有方案：文档存在 SharePoint上，使用SharePoint自带的搜索功能。问题在于关键词检索无法理解语义-员工搜"设计审查流程"可能返回一堆包含这些字但不相关的文档，真正的规程反而排后面。
7.2 RAG方案架构
7.3 工作流程
员工在SharePoint的搜索框中输入自然语言问题（比如"设计审查第3阶段需要提交哪些材料"），RAG系统先理解问题意图，然后从3000页规程中检索最相关的片段，生成带引用来源的回答。回答内包含链接，点击可直接打开SharePoint上对应的规程页面。
检索对象文档通过SharePoint API定期自动获取，确保规程更新后知识库同步刷新，不会出现"规程已经改了但系统还在用旧版回答"的问题。
7.4 关键设计决策
|------|----------------------|-----------------------------------------------|
| 决策 | 选择 | 原因 |
| 分块策略 | 按规程章节/条款切分 | 质量规程天然有条款边界，结构化分块保留条款完整性 |
| 检索策略 | 混合检索 | 规程中有大量专有术语和编号，BM25精确匹配不可缺；员工提问又是自然语言，需要向量语义匹配 |
| 查询改写 | 业务场景 → 规程查询 | 员工不知道规程的正式措辞，改写填补词汇鸿沟 |
| 引用溯源 | 回答内嵌SharePoint 链接 | 质量规程是强合规场景，必须能追溯到原文 |
| 更新机制 | SharePoint API定期自动同步 | 规程会更新，知识库不能过期 |
（四）可观测性-系统闭环
1、为什么传统可观测性对AI不够用
传统微服务应用由确定性代码逻辑驱动，输入与输出之间的因果关系清晰。出问题时，看日志、查链路、对指标，三板斧基本能定位。但AI应用，尤其是Agent的行为模式完全不同：它会自行规划任务、调用外部工具、沉淀记忆与知识库，任何一次请求在其内部都涉及大量复杂的工作流，整体复杂性呈指数级增长。
这带来三个传统手段无法回答的新问题：
执行过程黑盒化：一轮包含10次ReAct 推理的Agent任务，传统方案仅能识别出10条独立HTTP请求，无法还原分层、有序的完整决策流程。
行为轨迹难追溯：Agent具备较高的自主操作权限，可读写本地文件、执行系统命令、调用第三方API。在缺少专项审计能力的前提下，无法完整追溯其全部操作行为。
成本失控风险：在传统微服务场景里，成本是可控的。但在Agent场景中，一旦出现逻辑偏差，可能在极短时间内触发巨量的大模型调用，导致Token消耗呈指数级激增，使成本陷入危险境地。
AI可观测性的本质，是从"看请求成功/失败"升级为"看Agent为什么做了这个决策"------可见性回答"发生了什么"，可解释性回答"为什么"，可行动性回答"怎么优化"。
2、AI可观测性的四层架构-从采集到闭环
与传统可观测性"采集 → 存储 → 展示"的三段式不同，AI可观测性增加了一个关键层-语义建模层。它负责把零散的LLM调用、工具执行、推理步骤组织成可理解的决策链路。
为什么多了一个语义建模层？
传统可观测性的采集数据（HTTP 请求、数据库调用）天然具有结构化特征，采集完就能直接存储和分析。但AI可观测性的原始数据是高度碎片化的：很长的System Prompt、层层嵌套的JSON、模型中间输出、工具调用记录。这些信息不是没有，而是太碎、太散、太难关联。语义建模层的职责就是把离散事件组织成可追踪Trace链路，让Agent从不可见变为可追踪、可解释、可优化。
这一层的关键标准是OpenTelemetry GenAI语义规范。它为LLM调用、工具调用和Agent Span定义了统一的标准属性名（`gen_ai.`），包括 `gen_ai.system`（模型提供方）、`gen_ai.usage.input_tokens`（输入Token数）、`gen_ai.request.model`（请求模型）等。2026年的行业共识已经收敛到OTel GenAI 语义规范+ OpenInference + eval-as-span-attribute 三层结构。Microsoft Agent Framework、Langfuse、OpenLIT 等主流平台都已原生支持这一标准。
3、三层观测指标体系-运行层、业务层、治理层
AI可观测性的指标不能只看"成功率/耗时/并发"。
某保险集团建了统一监控看板加虚拟运行环境，支撑六百多个场景、累计数万小时运行，靠的就是三层指标分级视图。业务层指标让管理层看懂价值，运行层指标让运维看清健康。某大型银行把故障模式建成知识库后，重复告警自动归并，值班人员的有效处理率明显提升。
4、一次Agent 请求的完整Trace瀑布图
这是AI可观测性最核心的展示形式。传统日志是一堆平铺的文本，Trace瀑布图把Agent 的"思维链"变成可视化链路。
Session: user_12345\] \[Trace: task_abc\] \[耗时: 3.2s\] \[Token: 4,820\] \[成本: $0.12
├─ Span 用户输入解析 120ms ██
│
├─ Span 任务规划 (LLM Call #1) 680ms ████████
│ ├─ model: gpt-4o
│ ├─ prompt_tokens: 1,200 / completion_tokens: 350
│ └─ 规划结果: "查询订单", "计算退款", "生成回复"
│
├─ Span 工具调用: 查询订单 API 340ms ████
│ ├─ 入参: {order_id: "ORD-2026-001", user_id: "u_123"}
│ ├─ 出参: {status: "已发货", amount: 299.00}
│ └─ 状态: 成功
│
├─ Span 工具调用: 计算退款逻辑 280ms ███
│ ├─ 入参: {order_amount: 299.00, policy: "7天无理由"}
│ ├─ 出参: {refund_amount: 299.00, deduction: 0}
│ └─ 状态: 成功
│
├─ Span 推理: 是否需要人工介入 (LLM Call #2) 520ms ██████
│ ├─ model: gpt-4o
│ ├─ 评估: 金额 < 500，无需人工
│ └─ eval_score: 0.95（LLM-as-Judge）
│
├─ Span 生成最终回复 (LLM Call #3) 860ms ██████████
│ ├─ model: gpt-4o
│ ├─ prompt_tokens: 2,100 / completion_tokens: 420
│ └─ 输出: "您的退款申请已受理..."
│
└─ Span 输出合规检查 400ms █████
├─ 护栏: 通过
└─ 审计日志: 已写入
告警事件: 无
评估分数: Faithfulness=0.92, Answer_Relevance=0.88, Task_Success=1.0
这个瀑布图解决了AI可观测性最核心的问题：可见性。当用户反馈"退款金额算错了"，工程师不需要翻几十个日志文件，而是直接打开这个Trace，逐层下钻到"计算退款逻辑"这个Span，看入参和出参是否匹配预期。
5、可观测性闭环-从观测到优化的反馈回路
可观测性的最终目的不是"看到"，而是"少犯第二遍"。闭环包含四个环节：
检测环节的关键是告警分级。影响业务的红色告警、影响效率的黄色告警、纯提示的蓝色告警，只有红色才夜里叫人。
诊断环节的核心能力是根因归因。当一个Agent请求失败时，需要快速判断是检索没找到（Context Recall低）、生成编造了（Faithfulness低）、还是工具调用失败了。某大型银行的监控体系把常见故障模式建成知识库，新告警先匹配历史根因，能自动给处置建议。
行动环节需要与Agent的配置系统打通。如果根因是Prompt约束过严导致模型频繁走静默策略，那就需要自动或半自动地调整Prompt；如果根因是检索参数（Top-K太小）导致召回不足，那就调整检索配置。这个环节的自动化程度决定了可观测性能否从"被动救火"走向"主动预防"。
6、AI可观测性技术栈
2026年的技术栈已经明显收敛：OpenTelemetry GenAI语义规范成为事实标准，Langfuse和Grafana AI Observability是两个最主流的平台选择。Langfuse的v3架构引入了 ClickHouse、Redis和S3作为后端组件，Python和TypeScript SDK都原生构建在 OpenTelemetry 之上。Grafana在2026年4月发布了AI Observability公开预览版，将Prompt、Response和执行路径作为可观测信号与传统指标、日志、链路并列处理。
7、业务示例
Expedia的STAR-用确定性工作流做AI运维可观测
7.1 业务背景
Expedia Group是全球最大的在线旅游平台之一，拥有大量基于Kubernetes的微服务。当生产环境出现故障时，工程师需要从Datadog、Kubernetes事件、JVM指标等多个数据源中手动收集信息，定位根因的过程耗时且依赖经验。
7.2 方案选择：不用自主Agent，用确定性工作流
Expedia推出了Service Telemetry Analyzer（STAR），这是一个内部AI辅助可观测性平台。值得注意的是，STAR并没有采用自主AI Agent，而是遵循一种确定性的工作流：先收集遥测数据，再使用领域专属提示词进行分析，将分析结果汇总为中间发现，最终生成包含潜在根因和建议后续步骤的报告。
STAR以FastAPI应用的形式实现，集成了Datadog用于获取服务指标，同时接入内部生成式 AI网关用于管理身份认证和对LLM服务商的访问。系统分析的指标包括请求吞吐量、延迟、HTTP/gRPC/GraphQL错误率、CPU和内存使用情况、容器重启事件、Kubernetes 就绪探针和存活探针失败情况、Java堆内存使用率以及垃圾回收活动。
随着平台演进，Expedia用基于Celery的异步架构替换了FastAPI后台任务，并使用Redis 同时作为消息代理和结果存储后端。大部分处理过程属于I/O密集型操作，异步执行模型让 STAR能够并发处理多个分析任务，同时适应Datadog以及公司内部AI网关施加的速率限制。
7.3 可观测性闭环体现
|------|--------------------------------------------|
| 闭环环节 | STAR的实现 |
| 观测 | Datadog 遥测数据 + Kubernetes 事件 + JVM 指标，统一接入 |
| 检测 | 工程师发起调查请求，或系统自动触发分析 |
| 诊断 | Prompt Chain 多步分析 → 中间发现汇总 → LLM 生成根因报告 |
| 行动 | 工程师审查系统生成的分析结果后采取行动，使平台成为辅助工具而非自主运维系统 |
（五）安全治理-保障底线
1、AI安全治理到底在"治"什么
传统信息安全的保护对象是明确的：防黑客、防泄露、防篡改。防火墙、入侵检测、加密，三板斧对应的是"谁进来了、数据有没有被偷、系统有没有被改"。
AI系统把这些假设全部打乱了。模型不是确定性程序，而是一个概率系统-同样的输入可能产生不同的输出，你无法用if-else来保证它永远不说错话。Agent获得了自主规划和工具调用的权限，它可以在没有人工确认的情况下读文件、调 API、改数据。训练数据从外部供应链来，投毒在源头发生，影响面波及全域。
三个根本差异决定了AI安全治理不能简单复用传统安全框架：
保护对象变了：传统安全保护的是"系统和数据"，AI安全治理还要保护"模型行为本身"-它会不会产生有害内容、会不会被诱导做出越权操作、会不会在自主决策中失控。
威胁模型变了：传统攻击来自外部，AI的威胁既来自外部（提示注入、对抗样本），也来自内部（幻觉、偏见、过度自主）。
治理节奏变了：传统安全可以年度审计、季度巡检，AI安全治理必须是运行时的持续过程。一份1月份写的政策文档，防不住3月份出现的新型提示注入攻击。
2、AI安全治理架构总览
AI安全治理的完整体系可以拆成三层：治理层（谁负责、什么原则）、控制层（用什么技术手段防）、运行层（日常怎么运转）。三层从上到下逐级落地，从下到上逐级反馈。
《人工智能安全治理框架3.0》提出的治理原则包括包容审慎、风险导向、技管结合、开放合作、可信应用五条，同时把AI安全风险分为内生安全风险、应用安全风险和衍生安全风险三大类，每类风险都对应具体的技术应对措施和综合治理措施。工信部发布的YD/T 7173-2026标准则进一步明确了分层治理权责-领导层决策、管理层审批、执行层落地-以及风险识别、评估、处置的完整流程。
3、风险分类图谱-AI安全的"敌人"有哪些
理解AI安全治理的第一步，是知道要防什么。AI面临的风险不是单一维度的，可以按"风险来自哪里"和"风险如何表现"两个维度来组织。
3.1 按来源分类（基于《人工智能安全治理框架3.0》）
内生风险是模型"天生"带的-幻觉、偏见、不可解释，这些源于深度学习技术本身的局限。应用风险是"用出来的"-部署时给了过高权限、没有做输入过滤、没有做输出校验。衍生风险是"传导出去的"-模型产生的内容影响到社会层面。
3.2 按OWASP LLM Top 10分类（2025版）
OWASP的清单更偏工程视角，直接列出开发者需要防范的10个具体风险：
|-------|---------|----------------------------------|
| 编号 | 风险 | 核心问题 |
| LLM01 | 提示注入 | 模型无法区分"指令"和"数据"，所有输入都被当成文本流平等处理 |
| LLM02 | 敏感信息泄露 | 模型输出中可能包含训练数据或上下文中的隐私信息 |
| LLM03 | 供应链漏洞 | 预训练模型、数据集、LoRA 适配器、RAG 知识库都可能被污染 |
| LLM04 | 数据与模型投毒 | 在训练或微调阶段植入后门或偏差 |
| LLM05 | 输出处理不当 | 未经验证的模型输出直接进入下游系统执行 |
| LLM06 | 过度代理 | 赋予模型过高的工具调用权限，导致越权操作 |
| LLM07 | 系统提示词泄露 | 通过对话诱导模型套出系统提示词 |
| LLM08 | 向量与嵌入缺陷 | RAG向量数据库被污染，导致检索到错误信息 |
| LLM09 | 虚假信息 | 模型生成看似合理但实际错误的内容 |
| LLM10 | 资源消耗失控 | 攻击者通过高复杂度请求耗尽GPU配额或资金池 |
OWASP的核心防御理念是零信任：不假设模型本身是安全的，不相信模型的自我约束能力，不相信模型的输出是安全的，也不相信模型能完美执行系统指令。安全逻辑必须建立在模型之外，由确定的代码和规则来执行。
4、技术控制防线-四道关口的纵深防御
安全治理不能靠单点防御。OWASP明确指出，真正的安全架构必须跨越数据、模型、输出与运营的立体网络，才能抵御系统性风险。四道关口构成纵深防御：
第一关：输入防护。提示注入是首要威胁。OWASP中国区的防护指南建议在输入层对外部内容做来源标记与不可信隔离，杜绝"看到即执行"。微软的实践是用安全元提示将系统指令优先级置于用户输入之上，同时部署输入验证管道做对抗性测试。
第二关：模型防护。供应链安全是这一关的核心。AI供应链的风险特点是深度渗透并成为看不见的"黑盒"，在训练上游单点投毒，就可能向下游全域扩散。防御手段包括：只使用通过主管部门审核备案的基础模型，对第三方模型和数据集做加密验证和来源审计。
第三关：输出防护。模型输出不能直接信任。需要做内容合规过滤（拦截违法违规内容）、幻觉检测（事实一致性校验）、引用溯源（回答标注来源），以及输出脱敏（清洗结果中的敏感数据）。
第四关：权限控制。这是Agent时代最关键的一关。OWASP建议为每个工具设置独立的最小权限凭证，在沙箱中运行，禁止默认高权限。对高影响动作（删除、外发、支付）引入人工确认或策略网关。
一个容易被忽略的交叉点：第三关和第四关之间需要特别的防护-输出处理不当（LLM05）和过度代理（LLM06）的组合风险。当模型生成的输出未经验证就进入下游系统，同时模型又被赋予了调用该系统的权限时，一次幻觉就可能变成一次真实的越权操作。
5、运行时防护闭环-AISM五阶段操作防御环
静态治理不够。一份1月份写的政策文档，防不住3月份出现的新型攻击。年度审计抓不住正在失控的Agent。安全治理必须是一个持续运行的操作闭环。
AI SAFE2框架提出的AISM（AI Safety Management）操作防御环，把运行时防护拆成五个阶段，构成一个永不停止的闭环：
Shield（清洗与隔离） ：在每个AI交互的入口点做防护。检测提示注入、验证输入结构、过滤有害内容、脱敏敏感数据、验证模型工件的供应链完整性。Shield不能保证零攻击通过，所以需要后面的阶段兜底。
Ledger（审计与清单） ：记录AI系统做的每一件事。不是选择性地记录，是全部记录。每个Agent动作、工具调用、API请求、记忆读写、决策推理轨迹、Agent间通信-全部留痕。没有Ledger，后面所有阶段都是在盲人摸象。
Circuit Breaker（熔断与恢复） ：当Agent行为超出安全参数时，实时熔断。这是"最后一道防线"，当 Shield漏掉了攻击、Command Center还没来得及响应时，Circuit Breaker负责把损失控制在最小范围。
Command Center（监控与响应） ：接收Ledger的遥测数据，实时监控Agent行为，检测异常模式，触发响应流程。
Learning Engine（进化与教育）：从每次安全事件中学习，把威胁情报反馈给Shield，让下一次防御更精准。这是闭环的"学习"环节，没有它，系统永远不会变强。
这个闭环有两个速度：主循环（A→B→C→D→E→A）是标准操作周期，加速反馈路径（Ledger直接到Command Center、Learning Engine直接到Shield）是在紧急情况下绕过完整周期的快速通道。
6、从风险到行动映射
安全治理的实用工具不是"知道有风险"，而是"知道什么风险该用什么手段"。下表把 OWASP LLM Top 10的风险映射到四道防线的具体控制措施：
|---------------|---------|---------------------|----------|
| OWASP风险 | 主要防线 | 具体控制 | 关键指标 |
| LLM01 提示注入 | 输入防护 | 语义注入检测、来源标记、安全元提示 | 注入拦截率 |
| LLM02 敏感信息泄露 | 输入+输出防护 | 前置脱敏、输出脱敏、审计留存 | 泄露事件数 |
| LLM03 供应链漏洞 | 模型防护 | 来源验证、加密校验、备案审核 | 供应链审计覆盖率 |
| LLM04 数据投毒 | 模型防护 | 训练数据审计、异常检测 | 投毒检出率 |
| LLM05 输出处理不当 | 输出防护 | 事实校验、Schema 验证、下游准入 | 输出合规率 |
| LLM06 过度代理 | 权限控制 | 最小权限、沙箱、人工确认 | 越权拦截数 |
| LLM07 系统提示词泄露 | 输入+输出防护 | 元提示保护、输出检查 | 泄露尝试拦截率 |
| LLM08 向量与嵌入缺陷 | 模型防护 | RAG数据源验证、检索结果审计 | 检索准确率 |
| LLM09 虚假信息 | 输出防护 | 幻觉检测、引用溯源 | 事实一致性评分 |
| LLM10 资源消耗失控 | 权限控制 | Token 限额、速率限制、异常检测 | 异常消耗告警数 |
7、业务示例
中国农业银行-以AI手段应对AI应用风险
7.1 业务背景
中国农业银行是国内最早系统性推进AI安全治理的金融机构之一。2026年陆家嘴论坛上，农业银行董事长谷澍明确提出了"以AI手段应对AI应用风险"的治理思路，并分享了四方面的实践。
农业银行面临的核心问题是：大模型在信贷调查报告生成等场景中规模化应用，但模型幻觉可能导致信贷判断失误，Agent的自主操作可能触及敏感业务边界。怎么在"用得好"和"管得好"之间找到平衡？
7.2 AI安全治理三层架构
三层架构的核心逻辑是：治理原则定方向，四道控制建防线，运行闭环做迭代。农业银行的治理体系是"权责明晰与风险包容并重"的体系，确保AI既用得好、又管得好。
谷澍在论坛上特别回应了智能体应用的安全挑战。他指出现有定义和规范标准尚未统一，各机构披露的智能体数量从几百到上万个不等，差异巨大，不利于科学评估各机构的智能体应用水平。
谷澍建议：将功能相对单一、业务流程比较固定的智能体做成"标准件"，避免重复开发、实现反复调用，从而把更多精力聚焦于开发具备自主规划和决策能力的高价值智能体。同时强调，智能体范式的推广对工具接口的调用会进一步放大模型风险，将"信息幻觉"推向"行为失控"。
农行的实践与2026年实施的行业标准 YD/T 7173---2026《人工智能安全治理系统风险管理能力要求》高度对应。该标准规范了AI系统的组织建设能力、流程管理能力以及风险防护能力，要求AI系统在可靠性、可控性、安全性、公平性、透明性、可解释性、隐私保护性、可问责性八个维度具备控制风险的能力。
7.3 治理要素与对应标准
|--------|--------------------|----------|
| 治理要素 | 农业银行的实现 | 对应标准维度 |
| 模型可解释性 | 分类施策，差异化技术路线 | 可解释性、透明性 |
| 幻觉控制 | 业务标尺 + 模型互检 + 模型反思 | 可靠性、可控性 |
| 安全防御 | 以AI对抗AI，纵深防御 | 安全性 |
| 责任追溯 | 权责明晰，杜绝黑箱即免责 | 可问责性 |
| 隐私保护 | 提示词注入防御、多租户隔离 | 隐私保护性 |
| 人类主导 | 关键内容人工审核 | 可控性 |
四、架构设计核心原则
|------------|----------------------|--------------------|------------------------|
| 原则名称 | 描述 | 实现方式 | 作用 |
| 演进式法则 | AI技术发展快，架构需有可演进性 | 版本控制与模块热插拔 | 让AI能力灵活组合，快速适应业务需求变化 |
| 先进性法则 | 架构设计应应用前沿技术 | 容器化部署、微服务架构、模型加速 | 提升系统性能，为未来技术升级预留空间 |
| SRP与松耦合原则 | 单一责任和松耦合保障系统特性 | 拆分为独立模块，每个模块负责单一功能 | 提升系统灵活性和可维护性，避免牵一发而动全身 |
| 领域驱动原则 | 以业务为中心构建AI平台 | 围绕具体业务建立"领域服务"模型 | 使AI能力与业务场景紧密结合 |
| 分层架构与CAP法则 | 架构分层防止问题，分布式系统需权衡CAP | 分为接入层、服务层和基础设施层 | 防止逻辑混乱和性能瓶颈 |
五、关键架构模式
1、微服务架构
将组件分成独立可部署的服务，以提高可伸缩性和可维护性，使团队能够同时处理应用程序的不同部分。在AI应用中，微服务架构使各个AI能力组件（如推理服务、检索服务、工具服务）能够独立部署和扩展。
2、事件驱动架构
使用事件来触发操作，使解耦组件和实时处理能够使系统更具响应性并适应不断变化的数据。在AI场景中，事件驱动架构可用于异步处理Agent的慢请求、实时数据流处理以及多Agent之间的消息传递。
3、模型路由模式
使用模型路由器将请求路由到正常模型以提高可用性，或通过实时为特定任务选择最佳模型来提高响应质量。当工作负载可以容忍增加的可变性和延迟，或需要在不同模型之间平衡成本和功能时，模型路由器尤为有用。但需注意，在需要针对特定任务进行优化精确答案的场景中，或在使用包含窄SLO的微调模型时，应避免使用模型路由器。
4、RAG增强模式
许多AI应用通过访问外部知识源来提供准确的最新信息。可将检索视为强制授权的服务背后的代理工具或知识调用。关键模式包括：知识路由（根据查询类型、领域或用户上下文将查询定向到适当知识源）、上下文分层（组合多个知识源和上下文类型提供全面响应）、动态锚定（根据不断变化的要求调整知识源和定位策略）。
六、技术栈选型参考
|---------|-------------|------------------------------------------|
| 架构层次 | 技术组件 | 推荐选项 |
| 前端展现 | 前端框架/可视化 | Vue.js、React、Flutter、ECharts |
| 应用网关 | API网关 | Kong、APISIX、Spring Gateway、Zuul |
| AI网关 | LLM网关/MCP网关 | APISIX AI Gateway、Azure APIM AI Gateway |
| Agent框架 | 智能体开发 | LangChain、LlamaIndex、AutoGen、CrewAI |
| 模型推理 | 推理引擎 | vLLM、TGI、ONNX Runtime、TensorFlow Serving |
| 模型管理 | 生命周期管理 | MLflow、DVC、ModelDB |
| 向量存储 | 向量数据库 | Milvus、Pinecone、FAISS、Chroma |
| 关系存储 | 关系数据库 | MySQL、PostgreSQL |
| 文档存储 | NoSQL | MongoDB、Elasticsearch |
| 缓存 | 内存缓存 | Redis |
| 对象存储 | 文件存储 | MinIO、AWS S3 |
| 容器编排 | 基础设施 | Kubernetes、Docker |
| 监控告警 | 可观测性 | Prometheus、Grafana、ELK Stack |
| 分布式追踪 | 链路追踪 | OpenTelemetry、Jaeger |
| 消息队列 | 异步通信 | Kafka、RabbitMQ |
| CI/CD | DevOps | Jenkins、GitLab CI、ArgoCD |
七、附录
1、模型与推理API
1.1 OpenAI API Platform
主文档：https://developers.openai.com/api/docs
Agents指南：https://developers.openai.com/learn/agents
Chat Completions参考：https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create
1.2 Anthropic Claude API
主文档：https://docs.anthropic.com
消息API：App unavailable in region | Claude by Anthropic
API Primer：App unavailable in region | Claude by Anthropic
1.3 Google Vertex AI Generative AI
主文档：https://cloud.google.com/vertex-ai/generative-ai/docs
RAG/检索API：https://cloud.google.com/generative-ai-app-builder/docs
2、云平台AI服务与Agent开发
2.1 Microsoft Azure AI
主文档入口：https://learn.microsoft.com/azure/ai-services/
2.2 阿里云百炼（Model Studio）
主文档：全链路模型服务应用构建-大模型服务平台百炼-阿里云_大模型服务平台百炼(Model Studio)-大模型服务平台百炼(Model Studio)-阿里云帮助中心
DashScope API参考：DashScope API Reference - Alibaba Cloud Model Studio - Alibaba Cloud Documentation Center
《AI原生应用架构白皮书》：
AI 原生应用架构白皮书免费下载_在线阅读_藏经阁-阿里云开发者社区
2.3 百度千帆
推理服务API V2：推理服务API V2 - 百度千帆·大模型服务及Agent开发平台
2.4 腾讯混元
主文档：腾讯混元生图简介_腾讯混元生图购买指南_腾讯混元生图操作指南-腾讯云
OpenAI兼容接口：腾讯混元生图 混元 OpenAI 兼容接口调用示例_腾讯云
3、Agent框架与编排
3.1 LangChain / LangGraph
主文档：LangChain overview - Docs by LangChain
RAG与检索文档：Retrieval - Docs by LangChain
3.2 LlamaIndex
主文档：LlamaIndex Framework, by the makers of LlamaParse | Developer Documentation
4、协议与标准
4.1 Model Context Protocol (MCP)
规范文档：Specification - Model Context Protocol
GitHub规范仓库：https://github.com/modelcontextprotocol/specification
4.2 OpenTelemetry GenAI语义规范
规范地址：Moved: Generative AI semantic conventions | OpenTelemetry
5、安全治理
5.1 NIST AI Risk Management Framework
主文档：AI Risk Management Framework | NIST
CAISI（Center for AI Standards and Innovation）：NIST下属AI标准与创新中心，负责AI安全标准制定
5.2 国内
YD/T 7173---2026：人工智能安全治理系统风险管理能力要求（工信部）
GB/T 45654：生成式人工智能服务安全基本要求
《人工智能安全治理框架3.0》：包含内生安全风险、应用安全风险、衍生安全风险分类