AI Native ≠ 处处用 LLM：一张图说清 Agent / Skill / Tool 三层金字塔

可点击、可折叠、可传播的交互式分层架构图，把"AI Native ≠ 处处用 LLM"变成视觉直觉。

背景：AI Native 到底长什么样

"AI Native"这个词被频繁提起，但多数讨论停留在口号层——仿佛加上大模型调用就是 AI Native 了。真要动手设计一个 AI Native 系统时，第一个问题就卡住：LLM 应该放在哪里？放多少？怎么放？

答案不是一个技术选型，而是一套架构准则。我们的核心判断是：以认知性质决定技术分层——一个能力到底属于"新颖决策""程序性知识"还是"确定性计算"，决定了它该落在哪一层。这套准则最终收敛为一张交互式架构图，把抽象定义变成了一个视觉金字塔。

问题：没有分层准则的三种反模式

在落地 AI Native 的过程中，有三个高频反模式不提不快：

这些反模式的根因相同：没有用一个统一准则来裁定每个能力应该落在哪一层。于是我们引入了三层金字塔结构。

方案：三层金字塔 + 共享治理平面

三层结构

架构由两个部分组成：纵向的三层技术栈和横向的共享治理平面。纵向三层从窄到宽堆叠为金字塔——宽窄表达的不是重要性，而是"能力递增"与"代价递增"的互逆关系。

塔尖最窄但代价最高——每一次 Agent 推理都消耗 token 与时间；塔底最宽但代价最低——确定性计算在正确性和延迟上都可预期。越接近塔底，代价越小，但承载的能力也越基础。

共享治理平面

三层之上横跨一个治理平面，包含七项工程实践，缺一不可：

• • HITL 人在回路：极端状态挂起 Agent 转人工
• • 版本管理与灰度：回测 + shadow mode + champion-challenger 双跑
• • 决策追溯链：每一步推理、调用、参数入溯源库
• • MCP 安全中间层：OAuth2 / mTLS + 配额 + 二次确认
• • 对手建模偏差：漂移监测 + 降级策略
• • 成本可观测性：Token / 算力预算，超限熔断降档
• • 组织拓扑适配：平台工程 + 领域专家 + 风控合规三角协同

决策启发法：三问

新增任何能力，先过三问——这是一个代价从低到高的决策漏斗：

1. 1. 第一问（代价最低）：能否用非 LLM 系统以可验证正确性完成？→ 是：落在 Tool 层（MCP 暴露）
2. 2. 第二问：是否是固定流程只需被编排？→ 是：落在 Skill 层
3. 3. 第三问（代价最高）：是否需在新颖情况下决定下一步做什么？→ 是：落在 Agent 层

三问同时定义了 AI Native 应用的识别标准：至少一个能力通过第三问（答案为是），其余能力退守至 Skill / Tool。

架构图呈现

上述架构已编译为一张单文件 HTML 交互图（零依赖，拖进浏览器即看）。点击任意卡片可查看组件的本质、落地形态与 KPI；点击层头可折叠/展开三层卡片网格；Esc 关闭详情 panel。

取舍：这套架构不做什么

三层金字塔不是万能模板，它有几个明确的设计边界：

这些取舍的回报是清晰的：每一次推理、调用、决策都可被预算、可被审计、可被回滚。