AI导哈

AI原生应用架构

一种技术指南，用于构建由AI而非人类编排微服务的应用程序，适用于需要动态UI和意图交互的场景。

  • by coolksrini
  • Python
  • 本地部署
  • 3 星标
  • 更新于
在 GitHub 查看 coolksrini/ai-native-application-architecture-whitepaper

使用说明

AI原生应用架构白皮书和POC

构建应用程序的技术指南，其中AI编排您的微服务而不是人类。

核心思想

范式转变：从点击到意图

用户发生了根本性的变化 他们希望如何与系统交互ChatGPT、Claude和AI助手已经训练用户更喜欢 基于意图的交互 （“与我聊天以获取结果”）结束 基于点击的交互 （“浏览菜单和表单”）。

这不是一种偏好——它正在成为新的基线。用户越来越觉得 点击不如聊天自然他们希望系统理解他们的意图，而不是强迫他们通过预定的UI流。

问题：传统应用程序是针对基于点击的流进行硬编码的。用户点击按钮→ 前端决定调用什么API→ 后端决定调用什么服务。一切都是由开发人员在构建时预先确定的。

后果：对于体验过ChatGPT的用户来说，这些应用程序显得过时了。他们觉得自己不够灵活、有限，而且是错误的。

AI原生：让LLMs了解您的服务

为了保持相关性，应用程序必须适应这种新的交互模型。您可以让LLM：

  1. 了解现有的服务 （通过MCP-模型上下文协议）
  2. 解读用户意图 （用户真正想要什么？）
  3. 决定打什么电话 （哪个服务解决了这个问题？）
  4. 动态执行 （在运行时生成UI/流，而不是在构建时生成）

这需要一个不同的架构 --不是因为MCP比REST好，而是因为 用户的期望已经发生了根本性的变化.

新颖的建筑模式

本白皮书确定了三种专门为人工智能编排系统设计的架构创新，这些模式在传统应用程序架构或LLM文献中并不常见：

  1. 三层授权（用户+代理+意图） --针对人工智能代理独特风险面的安全模型。不仅是“用户是否被授权？”，还有“此代理是否被授权行事？”和“用户声明的意图是否与代理即将执行的意图相匹配？”请参阅 第7章：安全 为了实施。

  2. 三维函数调用评估 --为什么传统的软件测试在AI编排方面失败。测试必须在三个独立的维度上进行验证：短语概括（已知意图的新短语）、零样本工具概括（培训期间从未见过全新的API）和多转弯编排（AI链工具是否正确？）。看 第10章：测试 评估框架。

  3. 集中式跨服务测试团队 --捕获编排失败的组织模式。服务水平测试验证单个工具的工作；端到端场景测试验证了AI在服务之间的正确编排。这需要一个具有全面系统理解的专门团队。看 第12章：移民 组织结构。

这些模式源于以下基本要求 人工智能代理（而非人类）在运行时做出编排决策.

实际变化是什么

方面 之前 之后 为什么
服务编排 开发人员硬编码流程 LLM根据意图做出决定 更灵活，处理边缘情况
UI渲染 前端开发构建组件 LLM在运行时选择组件 为每个用户的实际需求提供更好的用户体验
测试 确定性测试 概率评估（95%以上的准确率） 无法预测所有LLM决策
授权 用户可以做X 用户+代理+意图全部授权 LLM需要权限才能操作
训练 可选精度 所需核心练习 通用模型达到70-80%的准确率；需要微调95%以上
成本 基础设施+开发 基础设施+开发+LLM推理 每次用户交互都需要LLM代币（但节省了开发时间）

实际影响

  • 相同的微服务：后端服务没有任何变化
  • 新协议：REST变为MCP（JSON-RPC而不是HTTP）
  • 新的评估方法：你衡量的是概率准确性，而不是确定性错误
  • 新的团队角色：快速工程师、评估工程师、人工智能平台团队
  • 组织演变：随着人工智能工具减少开发时间并在任何地方集成，团队必须提高技能——这不是可选的，保持相关性是不可避免的
  • 18-24个月的旅程：组织转型的4个阶段

包含什么

📚 白皮书（15章）

第一部分：基础 -有什么变化，没有什么变化，有什么新变化

第二部分：建筑 -如何实际构建这个

第三部分：操作 -在生产环境中运行此程序

第四部分：转型 -如何到达那里

👉 从这里开始: 主文件 （概述）或 全部15章 （按主题浏览）

💻 概念验证

展示每个概念的工作实施：

  • 4微服务：产品、订单、付款、带MCP包装的库存
  • AI编排器：发现服务、对用户意图进行分类、执行工具
  • 99测试：核心功能已验证
  • 6个可运行的演示：每章一个
  • 完全集成：显示整个系统的端到端工作流

👉 从这里开始: POC自述文件 （设置并运行）或 POC来源 （探索代码）

🎬 演示文稿（49张幻灯片）

用于向团队解释的交互式演示文稿，可在线或本地实时提供。

👉 从这里开始: 现场演示

如何探索这个

快速定向（15分钟）

  1. 阅读 第一章范式转换 -理解核心概念
  2. 浏览上面的“实际变化”部分——掌握实际变化

运行代码（15分钟）

  1. 首选 POC自述文件
  2. 设置并运行演示
  3. 看到概念发挥作用

了解细节（2-4小时）

  1. 主文件 -链接所有章节的完整概述
  2. 全部15章 -深入探讨特定主题

根据你的角色

  • 工程负责人：阅读第1章+第12章（迁移）+POC自述
  • 建筑师：阅读第5-8章（架构）+POC代码
  • 工程师：从POC README开始+运行演示+阅读第5章
  • ML/平台工程师：专注于第10-11章（测试/培训）+评估框架
  • 学习/研究：从主文档开始+按兴趣探索章节

💻 工作代码

所有概念都通过工作代码进行验证：

概念 代码位置 测试 演示
微服务与MCP poc/services/ poc/tests/test_orchestration.py poc/demo/chapter_5_*.py
AI编排 poc/agent/orchestrator.py 21测试 poc/demo/chapter_5_*.py
意图分类 poc/agent/intent_classifier.py 22个测试 所有演示
上下文管理 poc/agent/context_manager.py 21测试 poc/demo/chapter_8_*.py
三层安全 poc/core/auth.py 23测试 poc/demo/chapter_7_*.py
服务发现 poc/agent/discovery.py 19项测试 poc/demo/chapter_5_*.py
工具执行 poc/agent/tool_executor.py 16个测试 所有演示

状态: ✅ 99/99测试通过

常见问题解答

Q： 这只是REST与MCP的对比吗？

A： 不，协议比它所能实现的更重要。真正的变化是，你的UI变得动态（LLM选择组件），你的测试变得概率化（你衡量的是准确性而不是bug），而你的组织结构发生了变化（新的角色、新的团队设计）。

Q： 我需要MCP吗？

A： 如果你正在构建人工智能编排的系统，是的。MCP让LLM安全地理解和调用您的服务。正是接口层使AI编排成为可能。

Q： 我可以将其改装到现有系统上吗？

A： 是的。您现有的微服务保持不变。您可以添加MCP包装器，部署AI编排器，并逐步迁移流量。见第12章。

Q： 是否需要微调？

A： 对于生产，是的。通用LLM在特定领域的任务上实现了约70-80%的准确率。微调可以让你达到95%以上。见第11章。

Q： 这需要多长时间？

A： 对于大多数组织来说，需要18-24个月，分为4个阶段：试点、平台、推出、优化。详见第12章。

Q： 这只适用于大公司吗？

A： 不是。初创公司有一个优势——从第一天开始就构建人工智能原生系统，而不是对传统系统进行现代化改造。见第14章案例研究。

Q： 这对跟踪、分析和营销有何影响？

A： 戏剧性的。当用户通过聊天/LLM直接与后端服务交互时，传统的基于UI的分析部分过时了。您将失去对UI交互的可见性。企业功能必须适应：跟踪从UI事件到意图/API调用的转变，分析侧重于LLM决策模式和结果，营销必须使用算法UI选择而不是设计体验。这是ChatGPT渗透的一个明显影响——当用户可以通过自然语言直接与服务交互时，UI变得多余。

根据以下许可 CC 4.0.免费使用、改编、分享并注明出处。

最后更新：2025年10月27日| 概念验证: ✅ 完成| 白皮书: ✅ 完成

🤝 社区与贡献

问题、反馈或想要贡献？

  • 问题 -报告错误或请求功能
  • 讨论 -提出问题并讨论想法
  • 贡献 -贡献指南

相关 MCP