面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？

📌 一句话摘要

本文系统阐述了从传统工程架构向 AI Friendly 架构演进的三范式（确定性→概率性、结构化→语义化、静态→动态），并结合淘宝秒杀业务中的 AI 审核与答疑系统实战，详细讲解了 Multi-Agent、Context Engineering、AI Friendly API 及 AI 可观测等核心能力的实现方法。

📝 详细摘要

文章以淘宝营销业务中的 AI 实践为背景，深入探讨了传统工程架构（平台型与业务型）在面对 AI 的「不确定性」时产生的冲突，并提出了 AI Friendly 架构的演进三范式：从确定性到概率性、从结构化到语义化、从静态到动态。作者基于此范式构建了一套完整的架构大图，核心包括基础依赖层（模型、知识、工具管理）、Agent 层（BaseAgent/ReActAgent/PlanAgent）、意图层和会话层，以及 AI 可观测与评测体系。文章结合秒杀 AI 审核（准确率 95.7%）和 CogentAI 答疑系统（问题解决准确率 98%+）两个实战案例，详细讲解了 ReAct 与 Plan 范式结合、Multi-Agent 中心化决策模式、Context Engineering（历史案例库、混合审核决策）、AI Friendly API 改造（工具原子化、出入参拟人化）以及基于黄金数据集的评测飞轮等核心能力的落地过程。最后强调，并非所有 AI 应用都需要架构升级，应根据业务深度需求选择合适方案，避免「为用 AI 而用 AI」。

💡 主要观点

- AI Friendly 架构的核心是赋能传统工程以驾驭「不确定性」的能力。 传统架构基于确定性逻辑（y=f(x)），而 AI 具有概率性和涌现性。架构升级的关键在于通过三范式转变（确定性→概率性、结构化→语义化、静态→动态）来适配 AI 的运行范式。

Multi-Agent 系统采用中心化决策模式，形成 MOE 形态的专家协作。 在秒杀 AI 答疑场景中，中心 Agent 负责意图识别与任务分发，各业务域（商品、订单、库存等）的 Agent 基于 ReAct+Plan 范式独立推理，最终汇总结果，实现了复杂问题的自主解决。

Context Engineering 比 Prompt Engineering 更具长期价值，核心在于信息的精心组织。 随着大模型能力增强，简单指令即可完成任务。上下文工程的关键不是堆砌提示词，而是通过历史案例库、混合审核决策、知识图谱等高级 RAG 技术，在有限窗口内提供最优知识。

AI 时代的工具接口应从 REST-ful 转向 LLM-ful，即做 AI Friendly API。 工具的使用主体从人变为 AI，接口定义需进行原子化拆分、出入参拟人化改造，并设计清晰的错误描述，以便大模型理解、推理和决策。

AI 应用的评测与可观测是迭代飞轮的核心，且评测投入远超 Agent 构建。 基于黄金数据集的「线上采样→评测→优化→AB 测试」正向循环是持续改进的基础。AI 可观测需关注 Agent 执行路径、Token 消耗等 LLM 特有指标，而非传统微服务指标。

💬 文章金句

- AI Friendly 架构并非对传统工程经验的全盘否定，而是在我们过去十几年构建的坚实工程地基之上，为应对「不确定性」所进行的一次精准架构升级。

• Prompt Engineering 始终是一门经验学科……处于 AI 时代的工程师们，更应该关注的是 Context Engineering：即上下文工程。
• 在 AI 时代，工具的使用主体会从「人」转变成「AI」，所以接口的定义也应该从 REST-ful 到 LLM-ful。
• 从笔者的实践来看，评测所花费的时间甚至要超过 Agent 构建所花时间的两倍以上。
• 使用适合的架构做合适的系统，才是最重要的。

📊 文章信息

AI 初评：90

来源：大淘宝技术

作者：大淘宝技术

分类：人工智能

语言：中文

阅读时间：39 分钟

字数：9593

标签： AI Friendly 架构, Multi-Agent, Context Engineering, ReAct, AI 可观测

阅读完整文章