LLM Wiki

AI-Friendly架构

10分钟阅读

AI Friendly架构

一句话定义

AI Friendly架构是面向AI/LLM系统设计的工程架构范式，核心目标是赋能传统工程以驾驭AI的”不确定性”，通过三范式演进（确定性→概率性、结构化→语义化、静态→动态）实现传统架构向AI时代的升级。

摘要

AI Friendly架构由大淘宝技术团队在秒杀AI审核/答疑实战中提出，针对传统DDD/MVC架构与AI概率性、涌现性之间的矛盾，系统性地提出了架构演进方法论。该架构不是对传统工程的全盘否定，而是在已有坚实工程地基之上，为应对”不确定性”进行的精准架构升级。核心能力包括Multi-Agent系统、Context Engineering、AI Friendly API、AI可观测体系等。

详情

起源与背景

AI Friendly架构由大淘宝技术团队的久游在2026年提出，源于秒杀业务场景中AI应用落地的实际需求。传统架构（DDD平台型/MVC业务型）在设计之初秉承”以人为本”的理念，处理确定性逻辑，而AI天生具有概率性和涌现性，二者产生了难以调和的矛盾：

  • AI输出未遵循既定Schema时，传统架构束手无策
  • 流程/工具需根据上下文动态选择时，传统架构无计可施
  • Agent的高延迟低吞吐与传统架构的低延迟高吞吐设计原则冲突

核心机制 / 工作原理

三范式演进

1. 确定性 → 概率性

传统工程建立在确定性逻辑之上，系统输出严格遵循 y=f(x) 的映射关系。AI工程则运行于概率空间中，系统输出是大模型、提示词、上下文与环境共同”涌现”的结果。架构设计的核心目标不再是追求零误差，而是通过RAG增强、提示词或上下文工程及评测机制，将概率性输出收敛至业务与用户可接受的”安全区间”之内。

2. 结构化 → 语义化

传统工程遵循严格的结构化约定，系统输入数据必须精确符合预定义的Schema，系统边界是一堵刚性的墙。AI工程则拥抱语义化的柔性交互，系统能够直接理解自然语言、非结构化数据等模糊输入的意图，系统边界演变为一层弹性的膜。

3. 静态 → 动态

传统工程基于预定义流程（Workflow）开发，系统执行路径依赖于硬编码的逻辑判断。AI工程能够基于模型作出决策，系统具备根据当前环境和目标进行推理的能力，架构设计的核心目标需要从”规则”转向”规划”。

架构分层

┌─────────────────────────────────────────┐
│           AI可观测 / AI评测 / Agent安全    │  质量与稳定性
├─────────────────────────────────────────┤
│    Agent层 → 意图层 → 会话层              │  AI核心三层
├─────────────────────────────────────────┤
│  MCP能力层 │ RAG能力层 │ Agent编排层      │  能力层
├─────────────────────────────────────────┤
│  模型管理 │ 知识管理 │ 工具管理           │  基础依赖层
└─────────────────────────────────────────┘
  • 基础依赖层：模型管理（ideaLab API）、知识管理（向量化存储检索）、工具管理（ZETTA MCP平台 + RPA Skills）
  • 能力层：MCP能力、RAG能力、Agent编排
  • Agent层：BaseAgent（无动态规划）、ReActAgent（推理范式）、PlanAgent（计划范式）
  • 意图层：并行意图、顺序依赖意图、逻辑依赖意图的处理
  • 会话层：多轮会话及长短期记忆能力

应用场景

适用场景：

  • 需要AI自主规划、决策的复杂业务
  • 多意图识别与处理的场景
  • 需要Multi-Agent协作的系统
  • 对上下文工程有深度需求的应用

不适用场景：

  • 仅需接入AI Workflow获取结果的系统
  • 将Agent当接口使用的简单调用场景
  • 不需要”为用AI而升级AI架构”

后端分布式系统视角：无人值守开发的 AI Friendly 标准（阿里·刘瑞洲）

上面是大淘宝技术从「前端/应用 Agent」视角提出的范式；阿里技术的刘瑞洲则从后端分布式系统、面向 7×24 无人值守开发的角度给出一套互补标准。核心命题：过去建设的是「可维护系统」，未来要建设「可被智能体维护的系统」——本质是把藏在人脑、群聊、口头约定、历史事故里的系统知识，显式化、结构化、可检索化、可执行化、可验证化。

第一原则·六类机器可读「事实」底座：架构事实（全局架构地图）、服务事实（每服务的职责/依赖/接口/数据/消息）、领域事实（实体/状态机/不变量）、接口事实（幂等/重试/兼容/废弃策略）、数据事实（字段语义/枚举/分库分表/敏感字段）、运行事实（QPS/TP99/错误率/热点）。AI 对字段语义的猜测是自动化开发最危险的风险点之一。

关键工程资产：

  • Architecture Map：可被人读、AI 检索、工具引用、CI 校验、Harness 执行的全局系统地图，让 AI 进入任一服务前先获得「系统级方向感」，避免把局部修复做成全局破坏。
  • System Card / Service Card（服务身份证）：每个微服务一张标准化卡片（定位/职责/实体/数据所有权/接口/消息/依赖/运行特征/变更约束/测试入口/发布回滚），部分自动生成（接口从 IDL/OpenAPI、依赖从调用链、表结构从 schema），由 CI 校验。
  • Domain Clarity：显式化不变量、状态机、幂等与一致性策略、风险等级，并补「跨域链路模型」保护系统级一致性。
  • Skill-Based：把高频工程任务（加字段灰度兼容、新增 consumer、排查 TP99…）沉淀为 Spec-Driven-Development 式的可调用 SKILL，把资深工程师经验变成可执行资产。
  • Harness Augmentation：为 AI 建安全执行轨道，七层——上下文装载、工具（权限边界，生产库默认只读）、计划、执行（独立分支/worktree/sandbox）、验证、审计、回滚；更进一步让 Harness-Engineering 成为「全局架构规则执行器」（Architecture Policy 自动校验分层/依赖方向/数据 owner）。
  • Test-Gated AI Development：测试从「防人出错」升级为「约束和指导 AI 行为」的红绿灯/checkpoint，含单测、契约测试、集成、回归用例库、数据迁移测试、性能测试、架构级测试（验证系统结构是否被破坏）。
  • AI-Observable Architecture：可观测性变成 AI 的眼睛——日志结构化（traceId/bizId/errorCode）、错误码有语义、Trace 关联业务实体、指标有业务含义、告警带 Runbook（详见 AI可观测性）。
  • Tiered Access Control（L0–L5 分级权限）：从「只读代码」到「执行生产修复（强审计+人类预授权）」，让 AI 在不同风险场景获得刚好足够的权限；数据安全要求脱敏、生产库只读限行限时全量审计、密钥经 secret manager。
  • Docs/Architecture as Code：文档与架构都进 CI——architecture.yaml/ownership.yaml/critical-path.yaml/risk-policy.yaml 让全局架构成为可被 AI 读取、CI 校验、Harness 执行的工程资产。

成熟度三阶段：Copilot（辅助写代码）→ Coworker（独立完成中低风险任务，需 Service Card/SKILL/契约测试/CI）→ Operator（Loop-Engineering 式的「黑灯工厂」：接告警、定位、修复、回滚、复盘，需完整可观测/权限分级/审计/灰度）。落地路线的关键是「先追求可验证，再追求无人化」——逐步扩大 AI 的「可信半径」。

局限与注意事项

  • 架构升级需根据业务深度需求，避免”为用AI而用AI”
  • 评测所花时间可能超过Agent构建时间的两倍以上
  • Prompt Engineering仍是经验学科，Context Engineering更值得关注
  • AI发展日新月异，架构经验可能很快过时

关系图谱

反向链接