AI白皮书

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 10.1 AI安全风险的来源和分类 系统风险：AI模型软件的供应链风险、暴露面风险以及算力劫持风险。 网络风险：面向公网的入侵攻击，以及内网的隔离风险。 身份风险：对非人类身份的管控，越权访问，身份冒充等。 数据风险：Agent模型训练时的数据投毒，以及输入/输出阶段的敏感信息泄露等。 模型风险：Agent模型输入输出内容的恶意诱导、提示词攻击等风险。 应用风险：当AI在线上提供服务时，会面临Web入侵、DDoS攻击导致服务不可用等风险。 10.2 保护应用安全 10.2.1 背景和挑战 攻击者不再需要直接寻找暴露在公网服务中的漏洞，他们只需操纵相关的AI Agent，就能让这些AI Agent代为攻击内外部的弱电服务。 服务器端请求伪造（SSRF）是引入AI Agent后最突出的威胁。攻击者仅需通过自然语言提示，即可诱导受信任的Agent向内部网络发起恶意请求，窃取云环境凭证或扫描内网资产。Agent也可能被攻击者诱导产生包含SQL注入或XSS等恶意载荷，攻击与之交互的后端服务。 10.3.2 新的攻击面 构造恶意的语言诱导，让AI Agent变为一个无节制的资源消耗工具，使其无法正常为其他用户提供服务。构造复杂度炸弹式的指令，诱使AI Agent陷入生成海量文本的陷阱，生成数万乃至数十万的Token，导致其自身的计算成本飙升。 攻击者也可以攻击AI Agent调用的外部API，高频或海量触发复杂或昂贵的API调用。攻击者还能将恶意指令隐藏在AI Agent将要处理的网页、表格、PDF等外部数据中，当AI Agent处理这些被污染的数据时，隐藏的指令就会被执行。 10.3.3 防护思路 沿用并强化传统的应用安全最佳实践，同时实施严格的资源治理策略，针对工作流劫持类攻击，则需要设计更加完善的上下文隔离机制。 10.3.4 解决建议 一方面，对在AI场景下输入输出做安全检测的AI安全护栏方案，以及相关AI应用开发平台和网关对AI安全护栏的集成。另一方面，由于AI Agent进一步打破了传统的攻击面和网络边界，要更加关注纵深防御、动态检测、运行时安全等多种安全措施的组合。 例如当AI Agent未经过WAF或防火墙直接在内网发起恶意请求时，可以通过RASP等运行时检测方案或VPC防火墙来做防护，当AI Agent在用各种方式泄露敏感数据时，可以通过API安全、NDR等流量安全方案，从敏感数据流转的角度去及时发现风险。 10.3 保护模型安全 10.3.1 背景与挑战 输入层威胁：包括对抗样本攻击（如通过微调图像/音频诱导多模态Agent误判）、提示词注入的变种攻击（如上下文分割攻击、语义混淆攻击），以及通过恶意文件（如PDF隐写术）触发供应链漏洞。 推理层威胁：涵盖模型越狱导致的伦理失控、RAG知识库的定向爬取引发的数据资产泄露，以及函数调用劫持（如篡改API参数执行未授权操作）。 输出层威胁：设计生成式钓鱼内容（如伪造银行通知）、模型幻觉在医疗/金融场景的致命误导，以及通过隐写术在AIGC内容中植入隐蔽指令。 10.3.2 防护机制 内容合规审核，提示词攻击防御，敏感信息防护，恶意文件检测，恶意URL拦截，提示词反爬机制，模型越狱检测，模型幻觉抑制，数字水印标识。 10.3.3 模型安全的未来 自定义检测Agent可满足不同行业客户的特定业务风险识别需求。它引入了专用算法模型，并支持多行业多场景灵活配置，从而实现从通用到专属的安全检测能力升级。 10.4 保护数据安全 10.4.1 背景和挑战 10.4.2 防护框架 打造“平台可靠、链路可信、数据可控、自主可选、操作可审、责任可追”的数据安全保障体系。 10.4.3 构建全数据全生命周期的安全保障 1、数据收集 （1）数据来源：用户上传类数据、模型文件和推理数据、运行日志类数据。 （2）数据分类：以阿里云数据安全中心为例，从数据价值、敏感性、数据合规和业务需求等多角度将数据分为4个安全级别：S1、S2、S3、S4。 （3）数据脱敏 （4）数据去毒：对自有的存储资源中多种违规内容（例如涉黄、涉政、暴力、违法等）进行实时监控、检测和拦截。 2、数据传输 （1）面向数据传输提供私有网络加密 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 9.1 基于评估降低AI应用的不确定性 9.1.1 从确定性到不确定性 传统软件在很大程度上是确定性的，而AI应用其行为本质上是非确定性和概率性的。不确定性，就意味着对于相同的输入，它们可能产生不同的输出。 传统的QA流程，专为可预测的、基于规则的系统而设计，已无法充分应对这些由数据驱动的、自适应系统的挑战。 9.1.2 幻觉和不确定性的根因 AI应用的核心功能是基于从海量数据中学到的统计模式，来预测序列中的下一个词，而非真正意义上的理解。这就导致了“幻觉”现象，即模型生成听起来合理但实际上不正确或无意义的输出。 产生幻觉和不确定性的根本原因错综复杂：数据导致的缺陷、架构与建模的产物、错位与不确定性。 9.1.3 AI评估的重要些 从服务客户上看，评估是构建信任的核心机制。从商业视角看，严格评估直接转化为竞争优势。 AI的非确定性催生了评估经济，这是一个由可观测性平台、持续监控、自动化评估与治理即服务构成的新生态。评估不再是阶段性任务，而是与开发并行的持续工程实践，标志着AI原生时代质量保障的新范式。 9.2 AI评估体系 9.2.1 评估方法的基础二分法 1、内在评估 vs 外在评估 内在评估：侧重于孤立地评估模型输出的固有质量，而不考虑其在特定任务中的应用效果。评估的维度通常包括流畅性、连贯性、语法正确性以及事实准确性。 外在评估：通过衡量模型在特定下游任务或应用中的表现来评估其质量。 2、自动化评估 vs 人工评估 自动化评估：利用计算指标或利用其他AI模型来对模型输出进行打分。 人工评估：依赖人类评估员的判断来评估AI系统的输出质量，特别是在衡量帮助性、创造力、用户满意度等主观维度时。 在实践中，最佳的评估策略通常是自动化和人工评估的混合模式，利用自动化的效率进行大规模初步筛选，并结合人工的深度洞察力对关键或模糊的案例进行精细评估。 9.2.2 从静态到动态评估的演进 静态基准：静态基准是固定的、预先定义的数据集和任务组成。 动态评估：动态评估旨在模拟真实世界场景的复杂性和不可预测性，通过变化的变量、意外的输入和演进的上下文来测试系统。主要的动态评估方法包括：基于模拟的测试、实时对抗性基准、程序化生成。 9.2.3 现代AI评估的多范式全景 6个主要的评估范式：基准测试范式、“Evals”范式、心理测量学范式、人机交互范式、形式化方法范式、社会技术范式。 一个组织的评估栈，即其选择、组合和优先排序不同评估范式的策略，深刻地揭示了该组织在性能、用户价值和风险规避之间的权衡。 9.2.4 构建一个整体性的评估体系 一个完整的评估体系应包含8个核心组件： 性能指标，包括准确率、精确率、召回率、F1分数等。 鲁棒性与泛化测试 偏见与公平性评估 可解释性 合理性与伦理考量 持续监控与模型飘移检测 决策框架 自动化与人在回路 9.3 基于LLM的自动化评估 9.3.1 传统指标的局限性 传统的自动化评估指标，其核心是基于词汇或短语的重叠度来计算分数，这种方法对于需要捕捉语义、风格、语气和创造力等细微差别的现代生成AI模型来说，存在根本性不足。 另一方面，虽然人工评估被视为评估质量的“黄金标准”，但其高昂的成本、漫长的周期和固有的主观性，使其难以适应AI技术快速迭代的开发节奏。 9.3.2 LLM-as-a-Judge范式介绍 LLM-as-a-Judge范式，利用一个功能强大的大型语言模型来扮演裁判的角色，对另一个AI模型或应用的输出进行评分、排序或选择。 核心应用场景：数据标注、实时验证、为模型优化提供反馈。 9.3.3 LLM裁判的评估模式 逐点评估：裁判独立地评估单个模型输出，并根据预定义的量表给出一个绝对分数。 成对比较：裁判会同时看到两个来自不同模型的、匿名的输出，并被要求判断哪一个更好，或者两者是否相当。这是聊天机器人竞技场这样的众包评估平台所采用的核心方法。 9.3.4 控制LLM裁判的负面影响 1、系统性偏见：位置偏见、冗长偏见、自我偏好偏见、情绪与语气偏见、评分粒度有限。 LLM裁判产生的定量分数看似是精确的、数据驱动的，但实际上它们是通过一个充满主观偏见的过程生成的。因此一个来自LLM裁判的排行榜分数，并非对模型质量的纯粹客观测量，而是对裁判模型内在偏好和价值取向的反映。 2、递归依赖：能力天花板、推理幻觉。 一个较弱的LLM裁判无法公正地评估一个比它更强的候选模型。随着AI模型变得越来越强大，在评估其安全性和可靠性时，对人类专家和红队演练的依赖将会增加，而不是减少。 9.3.5 提升裁判可靠性的缓解策略 1、提示工程技术：思维链与分布推理、少样本提示、清晰的评分指南。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 8.1 AI可观测 8.1.1 什么是AI可观测 AI应用具有非确定性，即便是相同的提示，在不同次的运行中也可能产生不同的输出。如果没有可观测，在发生幻觉虚假错误等严重问题时根本无从查起。相反，一个好用的可观测工具会记录每一次的提示与响应、追踪使用模式，并标记异常。AI可观测是确保AI应用高效稳定安全运行的基础能力。 8.1.2 可观测 vs 监控：从“是什么”到“为什么” 监控关注“什么”：比如API响应时间、错误率、请求吞吐量和Token使用量等指标。 可观测性探究“为什么”：比如一个聊天机器人的回答不正确且耗时过长，监控可能只会显示错误率上升或延迟过高，但可观测能揭示为什么：可能是一次长时间的RAG请求最终得到了错误的召回，导致模型给出不准确的答案。 AI应用的每一次请求，都可以被弯针的追溯，包括调用工具的出入参、发送给大模型的具体提示词、任何中间步骤（如调用数据库或其他API），以及最终收到的输出。可观测工具就可以提供极其丰富的排查数据和上下文，帮助定位问题的根因。 8.1.3 AI可观测应对的核心挑战 性能与可靠性问题：大模型是资源密集型的，延迟峰值和瓶颈时有发生。 成本问题：许多大模型服务按Token使用量收费，若无控制，成本可能意外飙升。 质量问题：大模型的可能输出从训练数据中继承偏见或有害内容，也很可能产生幻觉。 8.1.4 AI可观测解决方案的关键能力 端到端全链路追踪：提供端到端的日志采集和链路追踪，可视化请求在整个AI应用中的执行路径。 全栈可观测：包含应用、AI网关、推理引擎可观测3个维度。 自动化评估功能：通过引入评估Agent，对应用和模型的输入输出进行自动化的评估，检测幻觉、不一致或答案质量下降等问题。 8.2 端到端全链路追踪 一个典型的LLM应用架构可能包含用户终端、认证模块、会话管理、对话服务、大模型路由、流程编排等。需要具备3项可观测能力：标准化的数据语义规范、低成本高质量的数据采集、端到端全链路追踪。 8.2.1 端到端全链路追踪的实现方式 面向AI应用的领域化Trace语义 基于OpenTelemetry的高质量数据采集 标准化协议 8.2.2 核心技术路径 1、链路插桩技术 Python探针，Monkey Patch Java探针，字节码增强技术。 Go探针，编译时插桩技术。 多语言兼容，其他语言通过OpenTelemetry开源框架支持。 2、链路采集与加工 数据采集策略 流式场景优化 3、LLM Trace查询与分析 全链路透视 高级过滤 智能诊断 8.3 全栈可观测：应用可观测 8.3.1 AI原生应用开发的痛点 工具选择盲区、错误排除困难、Token消耗黑洞、循环调用陷阱。 8.3.2 AI原生应用可观测需要具备哪些能力 零代码接入、可视化工具选择过程、精准故障定位、Token成本分析、端到端链路追踪。 8.3.3 演示场景架构 使用LangChain框架构建一个Agent，大模型使用Qwen Turbo。SLS MCP服务器通过SLS HTTP OpenAPI访问日志的接口，完成日志分析请求。LangChain Agent与MCP服务器产生的观测数据会自动采集到可观测平台中。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 7.1 AI应用运行时的演进趋势 7.1.1 从云原生到AI原生 云原生时代的核心是应用。将单体应用拆解为更小、更独立、更具弹性的微服务，并高效地在云基础设施上进行部署、扩展和管理。 而Agent的工作流，不再是执行一段固定的main函数，而是一个动态的、长周期的、充满不确定性的“思考-行动”循环。需要极致弹性和成本效益。需要数小时上下文记忆、拥有完整文件系统、并能与浏览器进行复杂交互。 7.1.2 Agentic AI应用的典型场景 场景一：交互式智能内容创作助手 对轮对话、上下文记忆、模型自托管、异构任务流、流式响应。 场景二：个性化AI客服 事件驱动、企业数据、实时在线。 场景三：通用Agent平台+病毒式传播的AIGC创意应用 Agent智能体、代码执行验证、部署与分享、脉冲式流量、大文件处理。 7.1.3 AI原生应用运行时的核心能力 1、面向会话的状态管理与安全隔离 2、大规模实时弹性与精益成本管理 3、异构算力与标准化工具连接能力 7.2 模型运行时 7.2.1 企业模型使用的核心痛点 资源浪费：业务流量波动大，高峰10万，平日几千，预留峰值会导致算力闲置。 冷启动：低频模型无法保持实例存活，使用时冷启动耗时长。 定制化：业务产品需要定制化，产品迭代周期长。 7.2.2 Serverless模型运行时的核心能力 Serverless是什么？ Serverless不是完全没有服务器，而是开发者不需要关心服务器的管理。对于开发者来说，只需关注代码，其他的交给云平台。主流Serverless平台包括阿里云函数计算、腾讯云云函数等。 Serverless和云服务器的区别？ 云服务器只是一台远程的服务器；Serverless只上传代码片段（函数），不管服务器，当有请求触发时，代码才会运行。 1、异构算力和1/N卡切分使用 在算力层，Serverless模型运行时通过GPU虚拟化技术将单张GPU显卡划分为N个独立计算单元，每个实例具备隔离的显存空间与算力资源，不同实例通过GPU分时复用技术实现并行推理。 Serverless模型运行时通过池化技术，将CPU/GPU/XPU统一纳管到一个资源池，开发者可根据模型特性按需配置算力模型，比如语音识别等轻量任务分配CPU，图像生成等算力密集型任务分配GPU碎片，大语言模型等显存密集型任务分配GPU整卡或多卡。 2、负载感知调度和毫秒级闲置唤醒 在调度层，Serverless模型运行时通过负载感知调度系统实时监测请求队列深度、GPU显存占有率、实例健康状态等多维指标，基于池化技术构建三级响应机制：请求优先分配至活跃实例；当资源吃紧时，毫秒级唤醒闲置实例了；仅在极端流量下触发冷启动。 其核心技术突破在于利用CRID（用户空间检查点/恢复）技术冻结显存状态，并将显存数据临时置换至内存，并在新的请求调度前实现毫秒级/秒级状态恢复，较传统虚机/容器方案提速百倍。 3、集成加速框架和开发调试工具链 在开发层，Serverless模型运行时预集成加速框架深度优化模型运行效率：vLLM框架的Paged Attention技术通过显存分页管理提升3倍吞吐量；SGLang的RadixAttention实现注意力机制并行编译，降低60%推理延迟；TensorRT-LLM的量化融合策略提升2倍能效比。 开发工具链提供DevPod交互式环境，开发环节实现白屏化操作和实时反馈，集成在线IDE如VSCode/JupyterLab/SSH终端，开发者在云端环境具备比本地环境更高的生产效率；生产部署环节实现革命性简化——上传模型文件后，系统在30秒内自动生成Dockerfile、构建推理服务、输出OpenAPI文档及SDK。 总结，GPU碎片化技术提供原子级算力单元，为智能调度奠定资源基础；负载感知引擎通过毫秒级实例弹性，将碎片化算力转化为即时服务能力；开发工具链则构建自动化流水线，使技术红利直达开发者工作台。 7.2.3 Serverless模型运行时——AI大脑的终极载体 Serverless模型运行时实现了异构算力革命、智能调度进化、开发范式升级三重突破，是承载AI大脑的核心基座。 7.3 智能体运行时 7.3.1 AI应用形态的持续演进 1、“请求-响应”模式：无状态的事务性AI任务 通过快速复制无状态的计算实例来应对流量变化。 2、“对话”模式：有状态的协作式Agentic AI应用 7.3.2 Agent运行时的核心架构目标 1、围绕会话请求和资源调度模型，维持长时运行的状态延续 2、实现面向Active-Idle资源管理，解决长时运行的成本困境 7.3.3 现有架构支撑Agent运行时对比分析 7.3.4 为AI原生的“会话式”Serverless运行时 AI应用的会话既需要状态持久化，又需要高性能的本地计算和会话维度隔离能力。 一个会话，一个独立运行时： 原生会话状态保持 灵活可靠的安全隔离 毫秒级的弹性速度 7.4 工具与云沙箱 7.4.1 AI Agent与工具：从概念到能力 Agent常用工具类型： ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 6.1 网关的演进历程 是什么在推动软件架构的演进呢？业务规模。业务从互联网、移动互联网以及即将到来的万物互联，其规模仍然在高速增长，也就意味着软件架构的复杂度也会越来越高，网关的特性也会越来越多。越来越复杂、越来越智能。 6.1.1 流量网关 代表软件是Nginx，将客户请求分配到不同的服务器上，从而实现流量负债均衡，避免单点故障，确保服务的稳定性和连续性。 6.1.2 ESB网关 ESB，企业服务总线，通过集中管理消息路由、转换和安全，实现服务的快速部署和高效运作。 6.1.3 微服务网关 微服务网关可以实现负载均衡、限流、熔断、降级、身份验证等功能，通过统一入口管理和优化各微服务间的交互。Spring Cloud Gateway是一个广泛应用的微服务网关。 6.1.4 云原生网关 云原生网关是伴随K8S的广泛应用而诞生的一种创新网关。既能有流量网关的特性来处理海量请求，又具备微服务网关的特性来做服务发现与服务治理，同时要求网关也具备弹性扩缩容能力解决容量调度问题。 6.1.5 AI网关 之前的几种类型网关处理的流量基本是以HTTP、RPC为主，多采用长连接，长连接采用request-response模式。AI采用的协议以SSE/Websocket为主，虽然也是长连接，但跟request-response模式相比，Server可以主动发送数据给Client，Websocket更是一种全双工协议，主要在语音类的实时通讯场景中使用。 AI场景对网关有新诉求，比如：多模型代理、智能路由、模型增强、安全防护、流式传输、无损变更等。 Higress网关已经在阿里云内部大规模生产落地，可以访问项目地址了解：https://higress.ai/ 6.1.6 API网关 从流量网关，再到AI网关，都是API网关在不同软件架构下的网关形态。HTTP/gRPC/Dubbo/Websocket都可以称之为API，MCP、A2A也可以称之为API。 6.2 AI网关的定义、特点与应用场景 AI网关是提供多模型流量调度，MCP和Agent管理，智能路由和AI治理的下一代网关。AI网关不仅完整继承了API网关的通用能力，如安全认证、路由转发、流量控制等，也演进出了大模型Fallback、大模型负载均衡、Token级别的精细化流量管控、语义化缓存、内容安全、联网搜索、MCP协议转化和管理、工具精选和搜索效果优化等面向AI场景的能力。 6.2.1 AI应用的流量特征 高延时 大带宽与流式传输 长连接 API驱动 6.2.2 AI网关的应用场景 1、模型服务提供商（MaaS）的接入层 2、AI应用的开发网关 3、企业内部的中央AI网关 4、MCP工具生态的统一入口 5、构建企业AI能力货币化的统一开放平台 6.3 AI网关的核心能力和最佳实践 6.3.1 核心能力 1、多模型代理 2、多模型回退/容灾 3、消费者认证 4、内容安全防护 5、Token限流 6、语义缓存 7、可观测性 8、MCP代理 9、工具的动态组装 10、工具的智能路由 6.3.2 最佳实践 AI网关的原子能力可以总结为面向LLM、Agent、MCP和AI开放平台四大类，这里总结了8类常见的实践，多模型代理、消费者认证、内容安全与防护、Token限流、语义缓存、多模型容灾、多模型可观测和AI开放平台。 1、多模型代理 需求场景： 文本、图像、音频、3D等多模态业务场景。 企业不同垂直领域，需要调用专用模型。 任务需要多个模型分工协作。 医疗机构，处理患者数据使用私有模型，其他和患者无关使用通用模型。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 5.1 AI工具简介 5.1.1 Function Calling Function Calling需要编写代码，并且存在规格碎片化、可靠性挑战、工程治理缺位、厂商锁定与迁移成本高等问题。 5.1.2 MCP MCP，Model Context Protocol，模型上下文协议，是一个开放标准，帮助连接AI助手与数据所在的系统，包括内容存储库、业务工具和开发环境。 MCP可以看作是AI应用程序的“USB-C端口”，就像USB-C为连接设备与各种外设提供了标准化方式，MCP为AI模型连接不同数据源和工具提供了标准化方法。 MCP把工具（Tools）、资源（Resources/用于检索与长上下文读写）、提示（Prompts）、会话（Sessions）、取样/推理（Sampling）等能力统一纳入协议语义，并标准化“枚举-描述-请求-响应-权限-审计”的全链路。传输层上，MCP不限定具体载体，既可以通过HTTP/WebSocket，也可以通过stdio等方式交换消息。 5.1.3 MCP就足够了吗 无论是RAG、Function Call还是MCP，其实都是为了让模型获取更多知识，调用更多工具来完成更复杂的事情。MCP并不是万能的，短期内存在不确定性与不同声音，国内是否成为事实标准亦未定。以MCP为协议底座，叠加AI工具接入的最佳实践与企业级安全治理，才能把“可接入”变成“可规模、可移植、可审计”的Agent能力。 5.2 AI工具标准化 5.2.1 MCP协议介绍 MCP协议遵循客户端-服务器（Client-Server）架构，允许AI应用程序通过MCP客户端与多个MCP服务器建立连接。MCP架构包含以下几个部分： MCP Host：协调和管理一个或多个MCP客户端的AI应用程序，如Claude Desktop、Visual Studio Code等，需要通过MCP协议访问数据。 MCP Client：MCP客户端，运行在MCP Host内部，负责与MCP Server建立并维护连接。MCP Host会为每一个MCP Server单独创建一个Client，Client与Server保持一对一连接。 MCP Server：MCP服务器，轻量级程序，通过MCP协议公开特定功能。MCP协议规定了MCP Server可为Client提供工具、资源文件以及提示词模板。 MCP协议采用JSON-RPC 2.0作为通信规范，所有消息均使用JSON格式进行序列化。消息类型包括：Request、Result、Error、Notification。示例如下： 请求： 响应： AI应用程序与MCP Server交互的整体流程如下： 5.2.2 MCP的核心优势 标准化模型与工具的连接方式 灵活的资源调度方式 支持双向、异步通信 支持能力共享 构建方式便捷 5.2.3 MCP面临的挑战 安全问题 大规模应用问题 集中管理问题 5.2.4 可行的解决方案 1、AI网关解决MCP安全问题 下一章将详细介绍AI网关。 2、工具优选和语义检索提升批量MCP的调用质量、降低调用耗时 工具优选：当模型请求在经过网关调用LLM时，携带含有大量工具的tool_calls数组时，网关侧基于Qwen3 Embedding和Qwen3 Reranker的方案，提供工具的精选能力，将tool_calls的数量压缩至目标数量，以提升模型响应速度与工具选择精确性。 语义检索：基于Higress网关的WASM插件机制，通过创建一个“All-in-One”的MCP Server，将用户在网关实例中注册的所有MCP工具进行统一聚合和管理，并提供智能的语义化检索能力。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 4.1 提示词工程 提示词工程，不是简单的提问，而是一套涵盖指令设计、上下文注入、角色设定和格式控制的综合性技术。 4.1.1 优秀提示词的核心实践 明确角色与目标 范例：“假设你是一位拥有10年经验的市场营销总监，请为一款新型智能手表起草一份面向年轻专业人士的产品介绍文案。” 提供清晰指令与完整上下文 范例：“请总结以下技术文章的核心观点（不超过200字），并列出其中提到的三个关键数据。不要添加个人评论。文章内容如下：[在此处粘贴文章]” 运用范例进行引导 范例：“请分析以下句子的情感及关键对象。范例：输入：‘我喜欢这部电影的剧情。‘输出：{‘sentiment’: ‘positive’, ‘aspect’: ‘plot’}。现在，请分析这个句子：‘这台相机的画质很棒，但电池续航太短。’” 定义结构化输出格式 范例：“请将你的回答组织成JSON格式，包含’product_name’和’key_features’两个字段，其中key_features是一个包含至少三项功能的数组。” 4.1.2 提示词工程的固有局限性 应对动态及长流程任务的局限 应对模型固有的无状态特性 无法突破模型固有的知识边界 长上下文中的信息利用不均衡 正是因为提示词工程有诸多局限性，上下文工程（Context Engineering）应运而生。 4.2 上下文工程 上下文工程的核心理念，在于将AI应用开发的焦点从优化单次交互的指令，转向为模型的每一次推理动态构建一个完整、准确且高效的认知环境。它不再局限于设计静态的提示词模板，而是致力于创建一个系统，确保模型在执行任务时，能够实时获取并利用完成该任务所需的所有相关信息，包括外部知识、历史记忆、可用工具及执行环境。 4.2.1 上下文工程与提示词工程的核心区别 4.2.2 上下文工程的关键组成部分 外部知识库的动态供给 长期与短期记忆系统 工具与能力的扩展 运行时的上下文管理 4.3 RAG技术原理与挑战 4.3.1 RAG的基础范式：三阶段工作流 1、第一阶段：索引（Indexing） 将原始的外部知识转化为机器可高效检索的格式。文档解析与提取，文本分块（Chunking），语义向量化（Embedding），构建向量索引库。 2、第二阶段：检索（Retrieval） 根据用户的自然语言查询，从已构建好的向量索引库中，快速、准确地找出最相关的N个知识块（Top-K）。 3、第三阶段：生成（Generation） 将前一阶段检索到的多个相关知识块与用户的原始查询进行整合，构建一个增强的提示词（Augmented Prompt）。比如： 4.3.2 RAG在工程化落地中面临的挑战 知识单元的完整性与信息密度的抉择 难以精准捕捉模糊、多样的用户意图 召回匹配时难以兼顾语义相关性与关键词精确性 需要探索如何在检索精度与完整性之间取得平衡 应对需要多知识点综合推理的查询实现 4.4 RAG系统优化实践：索引构建 4.4.1 基础文本分块策略 1、固定大小分块 2、基于句子或段落分块 3、语义分块：引入Embedding技术计算相邻文本单元间的语义相似度，在相似度得分显著下降的位置进行切分，从而识别出文本中的语义边界。 4.4.2 高级分块优化策略 1、滑动窗口（Sliding Window） 2、小块检索，大块生成（Small-to-Big） 3、元数据标注与过滤 4.4.3 处理复杂文档的索引策略 文档除了纯文本，还包括表格、图片、代码、脚注等复杂结构。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 3.1 智能体的定义与主流开发范式 3.1.1 什么是智能体 智能体（Agent）可以理解为一个具备自主理解、规划、记忆和工具使用能力的数字化实体。 我们在前面了解到LLM、MCP，它们和Agent是啥关系呢？LLM是“大脑”，Agent是“身体”，Agent通过MCP协议访问外部能力（Tools / Resources）。 【纯LLM交互】 用户：帮我分析main.py文件 LLM：我无法直接访问文件，请您将文件内容粘贴给我 【Agent交互】 用户：帮我分析main.py文件 Agent：我来读取并分析这个文件 → 调用文件读取工具 → 分析代码结构 → 提供详细分析报告 智能体让AI从一个只会内容生成的语言模型，进化成一个具备自主规划能力的行动者。 3.1.2 智能体的主流开发范式 简单LLM应用：直接调用模型API实现内容生成 单智能体：增加RAG、Tool、Memory等，让模型具备与特定环境交互的能力 工作流：将应用拆分，形成多个独立子智能体，再按照预定义的流程编排起来 多智能体系统：相比于工作流，多智能体系统采用的是模型驱动的、对话式的流程编排，各个子智能体具备更多的自主决策权 3.1.3 单智能体 典型的单智能体架构如下： 单智能体非常依赖底层模型能力。 3.1.4 工作流 1、Chain - 链式工作流 每一步由一个独立的LLM调用完成，并将上一阶段的输出作为下一阶段的输入。 2、Routing - 路由工作流 对输入进行分类，将它们分派到专门设计的下游任务或处理路径。 3.1.5 多智能体系统 由多个具备一定自治能力的Agent组成，每个Agent有自己的角色、能力或工具使用范围。它们之间可以通过消息或上下文进行交互，协同完成复杂目标。 3.2 开发一个简单的智能体 3.2.1 智能体框架选型 Python：LangChain、LlamaIndex、AutoGen、CrewAI，开源的Google ADK、Strands等，阿里云开源的AgentScope等 Java：Spring AI Alibaba等 这本白皮书是阿里出的，后面就用Spring AI Alibaba为例进行介绍。 3.2.2 Spring AI Alibaba中的Agent定义 React Agent，采用ReAct模式，将推理（Reasoning）和行动（Action）交错进行，形成一个动态的“思考-行动-观察”循环。 思考（Thought）：LLM分析当前的任务目标、已有的信息和可用的工具，然后生成一个关于下一步应该做什么的推理过程或计划。这个思路过程通常会以自然语言文本展示，解释了它的决策逻辑。 行动（Action）：智能体决定调用的外部工具（如搜索引擎、数据库查询API或自定义函数）。它会生成结构化的指令，明确指出要调用的工具名称和所需的参数。 观察（Observation）：应用程序执行工具调用，并将返回的结果（如搜索结果、API响应或函数返回值）作为观察信息反馈给智能体。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 2.1 模型 大模型扮演着大脑的角色，负责核心的理解、推理与生成任务。 2.1.1 模型分类 通用大模型：GPT、Claude、Qwen、DeepSeek、Gemini等通用大模型。 垂直领域模型：情感分析、语言翻译、意图分类等垂直领域模型。 通用大模型适合处理复杂、开放的任务，垂直领域模型适合处理简单、高频的任务。 2.1.2 模型能力和微调 模型的知识是固化的，需要不断地“喂”它，把这些信息结构化地描述清楚并且提供给它，它会在每次的交互中动态地理解你提供的内容，并结合自身的通用知识来完成内容的生成。 企业专属模型的训练和微调的成本是巨大的，它不仅包括高昂的计算资源费用，还需要海量的高质量标注数据、专业的算法团队以及漫长的开发周期。对于绝大多企业来说，投入与产出不成正比，很难持续。 2.1.3 如何选择模型 基于企业的实际业务场景，权衡任务复杂度、性能要求、开发成本和响应延迟等多个因素来综合选择和组合最合适的模型。 一个务实的策略是从顶配开始，逐步优化：先用能力最强的模型搭建原型以验证业务逻辑，再逐步将流程中的非核心、简单任务替换为更经济、更快速的小模型，最终找到成本与性能的最佳平衡点。 2.2 框架 Spring或Dubbo开发一个微服务应用，代码确定，容易形成标准化的框架。而开发一个AI Agent应用，LLM存在高度不确定性，设计模式的落地方式差异很大。 2.2.1 Agent设计模式 1、Chain of Thought（思维链） 让模型在回答前，把推理过程一步步写出来。 2、Self-Ask（自问自答） 让模型在回答时学会反问自己，把大问题拆成多个小问题，然后逐个回答。 3、ReAct（推理+行动） 在推理和外部行动（比如调用搜索引擎或API）之间交替进行。 4、Plan-and-Execute（计划与执行） 把任务拆成两个阶段，先生成计划，再逐步执行。 5、Tree of Thoughts（ToT，树状思维） 不是单线思维，而是生成多条思路分支，像树一样展开，再通过评估机制选出最佳分支。 6、Reflexion / Iterative Refinement（反思与迭代优化） Agent自我纠错，犯错后会总结失败原因，再带着反思尝试下一次。 7、Role-playing Agents（角色扮演式智能体） 把任务拆分给不同角色的Agent，通过对话协作完成任务。 这些模式不是互斥的，可以混搭使用。 其中ReAct已经被LangChain、LlamaIndex、Dify、Spring AI Alibaba等开发框架内置为基础框架。 2.2.2 Agent开发框架 1、从低代码到高代码 低代码平台是对于高代码的一层封装，其抽象层次很难满足所有场景，无法在性能、扩展性和复杂业务逻辑方面满足大规模生产的要求。 高代码是当下AI原生应用生产落地的主流形态，ADK、LangGraph、AutoGen、AgentScope、Spring AI Alibaba等框架，为开发者提供了面向Agent的编程接口。 2、高代码的演进 高代码模式本身经历了从ChatClient→Workflow→Agentic的演进过程。 ChatClient，一次单一的LLM调用。Workflow，将传统工作流转化为LLM节点编排。Agentic，提供面向Agent的API，并内置多种通用的协作模式（Pattern）。 3、零代码的愿景 尝试让用户完全通过自然语言即可驱动开发。目前处于探索与验证阶段，难以承担大规模生产任务。 2.3 提示词 在AI原生应用中，不再编写复杂的代码，而是使用更接近人类语言的方式与AI沟通，这就是Prompt（提示词）。提示词的质量很大程度上影响了AI应用的输出效果。 2.3.1 提示词是什么 提示词可以是一个具体的问题、一段描述、一组关键词，或是相关的上下文，不仅限于自然语言文本，还可以包含代码片段、数据格式说明，甚至是图像与文字相结合的多模态输入。 2.3.2 提示词质量=AI输出质量 大模型的输出质量，既要看大模型本身，也要看提示词是否清晰、完整、具体。比如，“写点关于人工智能的东西”，生成的内容是泛泛而谈。“以科技专栏作家的身份，撰写一篇800字左右的文章，探讨人工智能在医疗影像诊断中的最新应用、优势与挑战，并列举实例”，能生成一篇逻辑严谨、信息详实、专业度高的文章。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 1.1 大模型技术发展回顾和产业价值 1.1.1 大模型发展回顾与展望 2022年11月，ChatGPT横空出世，模型即服务（MaaS）模式快速兴起，AI从实验室走向商业场景。2024年，OpenAI推出o1模型和4o模型，大模型技术迎来质的飞跃。2025年，多家大模型厂商支持模型上下文协议（MCP），Google推出A2A架构，AI从单点工具向系统级生产力工具转变。 1.1.2 大模型的五大产业价值 效率新工具、服务新体验、产品新形态、决策新助手、科研新模式。 1.2 AI时代应用架构的演进 1.2.1 IT应用架构的演进脉络 云原生架构是指，Kubernetes等技术通过容器化、集群化管理，实现按量使用、秒级弹性的极致资源调度。 每一次架构升级，都是在满足业务规模更大、需求变化更快、资源成本更低的述求。 1.2.2 云原生应用架构向AI原生应用架构的跃迁 如果说，云原生解决的是如何高效地运行，那么AI原生是在此基础上解决如何智能地运行。 在云原生应用架构中，我们讨论的是容器如何管理、服务如何拆分、流量如何治理。而在AI原生应用架构下，其目标是在满足可扩展、可观测、安全合规的同时，最大化释放模型的智能潜力。 在大语言模型（LLM）出现之前，AI只能以功能模块形态嵌入系统。LLM具备通用理解、推理和生成能力，并能通过函数调用、外部工具联动和知识库，形成可扩展的Agent体系。AI原生应用的运行逻辑不再完全由工程师编写的代码所决定，而是由大模型进行自出判断、行动和生成，并具备以下3个特征： 以LLM为核心，用自然语言统一交互协议； 以多模态感知扩展输入边界，以Agent框架编排工具链； 以数据飞轮驱动模型持续进化，实现系统的自我优化。 1.3 AI原生应用及其架构的定义 AI原生应用架构，涵盖了模型、应用开发框架、提示词、RAG、记忆、工具、网关、运行时、可观测、评估和安全等关键要素。 1.3.1 大模型推理决策 传统应用使用编程语言（Java、C++等）进行编码，AI原生应用使用大语言模型（LLM），通过Prompt（提示词）等自然语言方式进行构建。 LLM具有语义理解与推理方面的能力，能够在面对模糊和复杂的开放式任务时，自主生成和调整业务执行逻辑，并根据需要完成工具调用与流程编排。 1.3.2 Agent编排和执行 传统应用是工具，Agent是助手。单Agent无法完成复杂任务时，可以协同多Agent编排完成复杂任务。自身能力受限时，可以扩展工具，甚至自己编写工具完成任务。 1.3.3 数据优化决策 模型输出可能存在偏差，甚至在某些情况下完全不符合用户或业务方的预期。为了解决这个问题，AI原生应用必须具备基于数据驱动的持续进化能力。在多轮交互中，持续保留并利用历史信息，理解用户的偏好、行为习惯与目标。同时，应用还需要通过数据采集构建高质量的评测数据集，并结合行业数据、用户反馈数据和客户业务数据进行持续评估与优化。 1.3.4 工具调用与环境连接 大语言模型运行机制的本质仍是基于“输入Token→输出Token”的序列生成过程。受限于这一机制，模型既无法直接感知外部环境，也无法获取实时更新的知识，更缺乏对物理世界的直接操控能力。 AI原生应用通常通过工具调用的方式扩展模型的环境连接能力。一是支持语音、图像乃至动作等多模态输入；二是支持联网检索获取最新信息，并且通过API对接外部系统，或直接驱动企业内部系统的业务流程。“模型+工具”协同运行。 1.4 AI原生应用架构成熟度 1.4.1 AI原生应用架构成熟度的定义 AI原生应用架构成熟度，是指用于综合衡量AI原生应用在技术实现、业务融合与安全可信等方面所达到的水平，客观反映其从简单功能集成到复杂智能决策的演进阶段与发展层次。 1.4.2 AI原生应用架构成熟度的演进 1、概念验证级：单点功能辅助 2、早期试用级：场景化初步闭环 3、成熟应用级：核心业务深度集成 4、完全成熟级：企业级自适应迭代 1.4.3 AI原生应用架构成熟度的评估 以五大能力特征作为核心评估维度：自然语言交互能力、多模态理解与生成能力、动态推理与自主决策能力、持续学习与迭代能力、安全可信。 本评估体系旨在为AI原生应用的规划、开发、部署与优化提供一套完整的诊断工具和行动指南，最终推动其从概念验证走向规模化、高价值的产业应用。 参考资料： https://developer.aliyun.com/ebook/8479