AI原生应用架构白皮书和POC
 ](https://github.com/coolksrini/ai-native-application-architecture-whitepaper) 
构建应用程序的技术指南，其中AI编排您的微服务而不是人类。
______________________________________________________________________
核心思想
范式转变：从点击到意图
用户发生了根本性的变化 他们希望如何与系统交互ChatGPT、Claude和AI助手已经训练用户更喜欢 基于意图的交互 （“与我聊天以获取结果”）结束 基于点击的交互 （“浏览菜单和表单”）。
这不是一种偏好——它正在成为新的基线。用户越来越觉得 点击不如聊天自然他们希望系统理解他们的意图，而不是强迫他们通过预定的UI流。
问题：传统应用程序是针对基于点击的流进行硬编码的。用户点击按钮→ 前端决定调用什么API→ 后端决定调用什么服务。一切都是由开发人员在构建时预先确定的。
后果：对于体验过ChatGPT的用户来说，这些应用程序显得过时了。他们觉得自己不够灵活、有限，而且是错误的。
AI原生：让LLMs了解您的服务
为了保持相关性，应用程序必须适应这种新的交互模型。您可以让LLM：
- 了解现有的服务 （通过MCP-模型上下文协议）
- 解读用户意图 （用户真正想要什么？）
- 决定打什么电话 （哪个服务解决了这个问题？）
- 动态执行 （在运行时生成UI/流，而不是在构建时生成）
这需要一个不同的架构 --不是因为MCP比REST好，而是因为 用户的期望已经发生了根本性的变化.
新颖的建筑模式
本白皮书确定了三种专门为人工智能编排系统设计的架构创新，这些模式在传统应用程序架构或LLM文献中并不常见：
- 三层授权（用户+代理+意图） --针对人工智能代理独特风险面的安全模型。不仅是“用户是否被授权？”，还有“此代理是否被授权行事？”和“用户声明的意图是否与代理即将执行的意图相匹配？”请参阅 第7章：安全 为了实施。
- 三维函数调用评估 --为什么传统的软件测试在AI编排方面失败。测试必须在三个独立的维度上进行验证：短语概括（已知意图的新短语）、零样本工具概括（培训期间从未见过全新的API）和多转弯编排（AI链工具是否正确？）。看 第10章：测试 评估框架。
- 集中式跨服务测试团队 --捕获编排失败的组织模式。服务水平测试验证单个工具的工作；端到端场景测试验证了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分钟）
- 阅读 第一章范式转换 -理解核心概念
- 浏览上面的“实际变化”部分——掌握实际变化
运行代码（15分钟）
- 首选 POC自述文件
- 设置并运行演示
- 看到概念发挥作用
了解细节（2-4小时）
根据你的角色
- 工程负责人：阅读第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日| 概念验证: ✅ 完成| 白皮书: ✅ 完成
______________________________________________________________________
🤝 社区与贡献
问题、反馈或想要贡献？