--- source_url: https://mp.weixin.qq.com/s/EezA0kT_hQCXze9LEOeuqg title: "面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？" source: "大淘宝技术" ingested: 2026-06-01 sha256: 3ec35f9aef271974af12412a717e0e451719fa232e23bfe7c43ae0d45d01f7e1 --- # 面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？ **作者：** 久游，淘天集团-营销&交易技术团队 **发布日期：** 2026年6月1日 ## 摘要 2025年成为AI智能体(Agentic AI)元年，传统工程架构面临与AI"不确定性"的冲突。AI Friendly架构通过三范式实现演进：1)确定性→概率性，将输出收敛至安全区间；2)结构化→语义化，基于意图而非格式响应；3)静态→动态，从规则转向规划。核心能力包括Multi-Agent系统、Context Engineering(上下文工程)、AI Friendly API及AI可观测体系。实际应用中，AI审核准确率达95.7%，AI答疑系统CogentAI问题解决准确率超98%，为业务带来80%以上效率提升。 ## 内容 25年伊始，智源研究院提出了《十大AI技术趋势》，2025年成为AI智能体（Agentic AI）的元年，更通用、更自主、深入工作与生活场景的智能体成为各行各业争相追逐的目标。 站在新年，回望AI应用的发展历程，随着一些大模型明星产品的出现，可以清晰的感知到行业对于AI应用形态的理解也已经越发深入： - 从Chatbot、Copilot到AI Agent，AI从提供建议，跨度到可以辅助完成任务； - 随着AI Agent应用编排框架不断收敛、Agentic AI概念的提出，从更强调产品概念的AI Agent，跨度到可以独立完成任务，集自主规划、决策、执行于一身，更强调应用智能程度的Agentic AI。 可以预见，此后也将看到智能化程度更高、对业务流程理解更深的多智能体系统在应用侧的落地，而对处于时代弄潮之巅的AI工程师来说，如何将工程架构完成从传统工程架构向AI Friendly架构的转变，已然成为进入AI时代的重要门票。 ## 冲突：当 AI 遇见传统工程架构 传统的工程架构按照服务主体的不同，通常可以划分为业务型架构和平台型架构： **传统平台型架构**（DDD思想）：系统设计核心是领域模型的标准化与业务流程的抽象化，通过统一抽象实现新增功能可配置、可组合、可沉淀，达到80%~90%功能的复用。 **传统业务型架构**（MVC思想）：简单成熟的分层架构，通过引入恰当的设计模式和数据结构来支持业务的快速发展。 两种架构都秉承着"以人为本"的设计理念，趋向于处理确定性逻辑——输入格式规范、输出内容可预测、基于预定义的流程来执行、依赖于规则和配置。 但AI天生具有概率性和涌现性，当以"不确定"为基础的AI遇见以"确定性"为基础的传统架构时，产生难以调和的矛盾： - 当AI的输出没有遵循既定的schema格式时，传统架构便束手无策，只能默默报错； - 当流程/工具/函数需要根据上下文动态选择时，传统架构便无计可施； - 当以高延迟、低吞吐为特点的Agent进入以低延迟、高吞吐为设计原则的传统架构中，各种超时、可用性问题的确层出不穷。 ## 演进：从"传统"到"AI Friendly" 核心逻辑：**赋能传统工程以驾驭"不确定性"的能力**。AI Friendly架构并非对传统工程经验的全盘否定，而是在坚实工程地基上，为应对"不确定性"的一次精准架构升级。 ### 演进的三范式 **1. 从确定性到概率性** 传统工程建立在确定性逻辑之上，系统输出严格遵循 y=f(x) 的映射关系。AI工程则运行于概率空间之中，系统输出是大模型、提示词、上下文与环境共同"涌现"的结果。架构设计的核心目标不再是追求零误差，而是通过RAG增强、提示词或上下文工程及评测机制，将概率性输出收敛至业务可接受的"安全区间"。 **2. 从结构化到语义化** 传统工程遵循严格的结构化约定，输入数据必须精确符合预定义的Schema。AI工程则拥抱语义化的柔性交互，系统能够直接理解自然语言、非结构化数据等模糊输入的意图，基于"意图"而非"格式"进行响应，系统边界演变为一层弹性的膜。 **3. 从静态到动态** 传统工程基于预定义流程开发，执行路径依赖硬编码的逻辑判断或规则。AI工程能够基于模型作出决策，系统具备根据当前环境和目标进行推理的能力，无需人工干预地拆解任务、调用工具并响应未知的变化。架构设计核心目标需要从"规则"转向"规划"。 ### AI Friendly架构大图 **基础依赖层：** - 模型管理：依托ideaLab提供的API，可基于OpenAI协议调用各大厂商不同版本的大模型 - 知识管理：依托ideaLab知识库，可将不同来源知识（如钉钉、语雀）进行向量化存储和检索 - 工具管理：ZETTA（HSF团队开发的MCP管理平台，将HSF接口快速转化为MCP Server）+ ideaLab（基于MCP协议实现MCP Client）+ RPA实现Computer Use的Skills 采用Spring AI Alibaba作为开发框架，管理模型、知识、工具等基础依赖，以及上层Agent、意图、会话等能力。 **AI Friendly架构独有的三层模型：** - **Agent层**：实现不同业务场景下Agent的构建和管理。分两类：具备动态规划解决问题能力的Agent + 具有固定流程编排的Agent。具体实现为BaseAgent（普通ChatBot/AI Workflow）、ReActAgent（ReAct推理范式）、PlanAgent（Plan计划范式）。 - **意图层**：负责对任务的真实目的进行识别和处理，实现从结构化到语义化的转变。需关注"并行意图"、"顺序依赖意图"、"逻辑依赖意图"的处理方式，结合Query改写和扩写实现意图优化。 - **会话层**：重点需要关注多轮会话及长短期记忆能力。记忆的本质就是上下文工程，其重要程度甚至高于模型本身。 **质量和稳定性管理：** - AI可观测、AI评测、Agent安全——基于AI应用特点，SLA衡量标准与传统架构不同。 ### 架构升级的边界 作者强调：**并非所有AI工程都需要向AI Friendly架构演进。** 对于仅需要接入AI Workflow获取结果的系统，将构建好的Agent当作接口使用，只需关注API调用和结果处理即可，无需关注"记忆管理"、"工具管理"、"上下文工程"、"Multi-Agent调度"、"自主规划"、"AI可观测性"、"数据采样与评测"等更深层次的AI能力维度。只有当所面临的业务场景需要涉及到更深层次的AI应用时，才需要对系统架构进行升级。 ## 落地：AI驱动的业务系统 ### 业务场景 **AI审核（秒杀业务）：** 在秒杀业务"高频迭代、节奏紧凑、供给海量"的环境下，AI审核覆盖商品全生命周期，解决两大核心问题： - 审核负担重、风险识别滞后 → 基于多模态AI模型实现风险自动分级（自动通过/驳回） - 在团商品"只管上线、不管表现" → 实时巡检健康度指标，对劣质商品自动预警或下架 **成果：** - AI审核准确率达到**95.7%**，召回率达到**99.1%** - 每天审核2-3w报名商品，小二**80%以上**审核效率提升 - 通过微调、MOE等能力优化，可识别未定义的潜在问题 **AI答疑（CogentAI）：** 基于秒杀业务答疑场景，具备自主规划、推理解决问题能力的AI助理。与传统QA问答机器人或RAG问答机器人不同： - 可以根据问题进行意图识别 - 自主规划问题的解决路径 - 灵活选择工具和知识库使用 - 根据结果动态调整计划 AI问题解决准确率在**98%以上**，带来**80%以上**的效率提升。 ### 从ReAct到Multi-Agent **ReAct范式的实现：** ReAct (Reasoning + Acting) 的核心逻辑是让大模型在执行任务时，按照 思考(Thought) -> 行动(Action) -> 观察(Observation) 的循环来工作。但ReAct更擅长解决理性类问题，对于主观类问题不能很好地解决，因此通常会结合Plan范式。 **ReAct And Plan范式的结合：** - Plan产出全局计划，通过沉淀优秀的计划模板来解决可能出现的低质量计划问题 - ReAct来执行细分领域的推理，在垂直领域表现出更好的效果 **Multi-Agent实现（秒杀场景-中心化决策）：** 将答疑分为多个业务域（商品域、订单域、库存域、报名域、补贴域、素材域等），每个域基于ReAct And Plan范式实现具备"计划-推理能力"的Agent，由中心Agent统一做意图识别与任务分发，形成"MOE(混合专家)"形态的Multi-Agent。 ### 从Prompt Engineering到Context Engineering 上下文工程的核心：**如何精心挑选、组织和压缩信息，以便在有限的窗口内，让大模型获得回答问题所需的最优知识。** 秒杀AI审核场景下的上下文工程实践： - **历史审核案例库：** 通过沉淀历史审核的优秀案例并存入向量数据库，对当前审核商品做图片、标题等维度的相似性向量检索，召回最佳案例提供给大模型做参考，**优秀的案例可以为AI审核带来8%左右的准确率提升** - **混合审核决策：** 通过引入水位有差异的多模型进行多次判断，将投票后的结果给到大模型做参考，结论一致且置信度较高的情况下为AI审核带来**10%以上的准确率提升** ### 从REST-ful到LLM-ful 工具接口的定义应从REST-ful到LLM-ful，即做AI Friendly API和AI Friendly Error。在秒杀AI答疑业务场景中，对原生的商品、订单、报名等接口做了AI Friendly改造： - **工具原子化改造：** 将接口拆分成适配大模型ReAct推理过程的原子工具 - **工具出入参改造：** 对接口的名称和出入参做拟人化调整，接口名称清晰直接体现用途，出入参仅保留核心参数和字段，尽量使用平铺的KV对来描述 - **工具Error改造：** 预期内的情况提供简短的错误描述，方便大模型做推理决策；预期外的情况提供堆栈信息，方便大模型识别错误原因 ### 从评测到AI可观测 **评测链路：** "线上数据采样 → 样本集构建 → 评测（自动、人工） → 优化（工程优化、模型微调） → 线上AB → 指标观测"的正向循环链路。 **AI可观测：** 面对大模型的语义性和不确定性，可观测应关注Agent执行路径、首Token响应时间（TTFT）、Token消耗与成本、TPM、QPM等，必须深入到决策链、上下文等LLM或Agent层面。 ## 补充阅读建议 作者推荐的上下文工程进阶技术关键词：知识图谱与结构化（GraphRAG）、动态上下文剪枝（Context Pruning）等。