可点击、可折叠、可传播的交互式分层架构图，把”AI Native ≠ 处处用 LLM”变成视觉直觉。
“AI Native”这个词被频繁提起，但多数讨论停留在口号层——仿佛加上 ChatGPT 调用就是 AI Native 了。真要动手设计一个 AI Native 系统时，第一个问题就卡住：LLM 应该放在哪里？放多少？怎么放？
答案不是一个技术选型，而是一套架构准则。我们的核心判断是：以认知性质决定技术分层——一个能力到底属于”新颖决策”“程序性知识”还是”确定性计算”，决定了它该落在哪一层。这套准则最终收敛为一张交互式 HTML 架构图，把抽象定义变成了一个视觉金字塔。
在落地 AI Native 的过程中，有三个高频反模式不提不快：
| 反模式 | 典型表现 | 后果 |
|---|---|---|
| Agent 化一切 | 每个函数都封装成 LLM Agent，连简单的条件分支也走推理循环 | 成本失控、延迟爆炸、输出不可靠 |
| 确定性逻辑伪装成推理 | 本该是 if-else 的规则，硬塞进 prompt 让模型”判断” | 幻觉风险、不可审计、无法回测 |
| 只搭架构不建治理 | LLM 直接面对生产环境，没有人在回路、没有成本预算、没有追溯链 | 出问题找不到原因，改不动也不敢改 |
这些反模式的根因相同：没有用一个统一准则来裁定每个能力应该落在哪一层。于是我们引入了三层金字塔结构。
架构由两个部分组成：纵向的三层技术栈和横向的共享治理平面。纵向三层从窄到宽堆叠为金字塔——宽窄表达的不是重要性，而是”能力递增”与”代价递增”的互逆关系。
| 层 | 宽度 | 承载的能力 | 本质上是什么 |
|---|---|---|---|
| Agent 层（塔尖） | 最窄 | 新颖情况下决定下一步做什么 | LLM 推理循环（ReAct / Plan-Execute），唯一需要多轮工具调用的层 |
| Skill 层（中间） | 中等 | 程序性知识与 SOP 编排 | 提示词 + 状态机 + 工作流 DAG，LLM 仅在异常处置时介入 |
| Tool 层（塔底） | 最宽 | 确定性能力实现，经强类型协议（MCP）暴露 | 普通应用 / 函数 / MCP Server，可回测、可验证正确性 |
塔尖最窄但代价最高——每一次 Agent 推理都消耗 token 与时间；塔底最宽但代价最低——确定性计算在正确性和延迟上都可预期。越接近塔底，代价越小，但承载的能力也越基础。
三层之上横跨一个治理平面，包含七项工程实践，缺一不可：
新增任何能力，先过三问——这是一个代价从低到高的决策漏斗：
三问同时定义了 AI Native 应用的识别标准：至少一个能力通过第三问（答案为是），其余能力退守至 Skill / Tool。
上述架构已编译为一张单文件 HTML 交互图（零依赖，拖进浏览器即看）。点击任意卡片可查看组件的本质、落地形态与 KPI；点击层头可折叠/展开三层卡片网格；Esc 关闭详情 panel。
三层金字塔不是万能模板，它有几个明确的设计边界：
| 取舍 | 说明 |
|---|---|
| 不追求”处处用 LLM” | 确定性能力坚决下放到 Tool 层。这看起来”不够 AI”，但换来的是可回测、可审计、低延迟 |
| 治理不是可选项 | 七项工程缺一不可——没有治理平面的 Agent 系统是”能跑但不能上线” |
| 分层准则是认知性质，不是团队结构 | 不是按前端/后端/算法切，而是按”这个能力到底需不需要 LLM 推理”切 |
| 框架可迁移，组件名不能照搬 | 分层逻辑（Agent / Skill / Tool / MCP）通用；但具体组件名、KPI 需按业务替换 |
这些取舍的回报是清晰的：每一次推理、调用、决策都可被预算、可被审计、可被回滚。