从 prompt 直连反模式到企业 AI 中台：一次架构演进的完整拆解算力、模型、智能体、技能、MCP 五件套自持

一句话总结 ：模型迟早会变成像数据库、像 CDN 一样可替换的基础设施。真正该被你攥在手里的，是模型上面那一层 ------ 算力、模型路由、智能体、技能、MCP。这一层，我管它叫企业 AI 中台。

本文从 2026 年 7 月 1 日 Palantir CEO 那场采访讲起，但重点在后半段的架构设计。全文约 8000 字，7 张原创架构图。

一、先说个真实的问题
[二、事件回顾：Karp 到底说了什么](#二、事件回顾：Karp 到底说了什么)
三、白皮书的四层模型：一份意外好用的架构清单
[四、核心矛盾：你的 know-how 存在哪](#四、核心矛盾：你的 know-how 存在哪)
[五、企业 AI 中台：架构设计](#五、企业 AI 中台：架构设计)
六、五件套的工程细节
七、治理：贯穿五件套的那条线
八、落地路径：别一步到位
[九、开源实现：MateCloud 与 MateClaw](#九、开源实现：MateCloud 与 MateClaw)
十、总结与自检清单

一、先说个真实的问题

上个月一位客户 CIO 问我：

「我们今年在 AI 上花了小两百万，除了几个员工用得挺爽，我说不清楚它给公司留下了什么。」

他不是不相信 AI。他问的是一个非常工程化的问题：这笔投入的沉淀物是什么？

传统 IT 建设，钱花完了你至少能指着几样东西：这套 ERP、这个数据仓库、这些表结构。AI 呢？如果你的架构是「业务代码直接调 OpenAI SDK」，那一年下来，你的沉淀物是：

一堆散落在各个服务里的 prompt 字符串
一份月度账单
以及一整年免费送出去的业务语境

这不是危言耸听，这是很多公司现在真实的架构现状。我把它叫做 prompt 直连反模式：

java 复制代码

// 反模式：业务代码直接绑死某个厂商的 SDK 和某个具体模型
@Service
public class ContractService {
    private final OpenAiChatModel model;   // ← 绑死厂商

    public String review(String text) {
        return model.call("你是一个专业的合同审核专家，请审核：" + text);
        //                 ↑ prompt 硬编码在代码里，换模型要重测，换厂商要重写
    }
}

这段代码能跑，能演示，能在立项会上拿到掌声。但它有三个致命问题：

厂商绑死 ：OpenAiChatModel 是具体实现，换成通义要改代码
知识不沉淀：那句 prompt 就是你全部的「know-how」，它既不版本化，也不可评测，更谈不上复利
治理无处挂载：谁调的？调了什么？花了多少 token？数据出没出去？------ 无处可查

有意思的是，一个月之后，一个美国人在电视上把同一件事吼了出来。

二、事件回顾：Karp 到底说了什么

2.1 先交代下背景

Palantir（帕兰提尔）：2003 年成立，联合创始人里有 Peter Thiel，早期投资人之一是 In-Q-Tel ------ 中央情报局的风投部门。主营业务是给 CIA、FBI、美国国防部、各国政府和大型企业做数据整合与分析平台。四个产品：Gotham（情报国防）、Foundry（商业）、AIP（AI 平台）、Apollo（部署）。市值约 3200 亿美元（2026 年 7 月），过去十二个月收入 52 亿美元。

Alex Karp：58 岁，联合创始人兼 CEO。哲学本科 → 斯坦福法学博士 → 法兰克福歌德大学社会理论博士（导师是哈贝马斯）。住新罕布什尔乡下，练太极和气功，2020、2024 两次成为全美上市公司薪酬最高的 CEO，说话从不经过公关团队打磨。

这个背景对理解他的话很重要：他这二十多年只干一件事 ------ 把软件卖进这个星球上最敏感的地方。这些客户从第一天起就只问一个问题：「我的数据会不会出去？」

2.2 他说了什么

2026 年 7 月 1 日，CNBC《Squawk Box》。原话：

"Something has gone completely wrong, and the basic view among enterprises in this country is I'm going to chillax and waste my time with tokens, I'm gonna get no value, and they're gonna get my IP."

他转述客户的话更狠：

"I am paying for tokens that create no value. These people are stealing the weights and alpha of my business."

（我在为不产生价值的 token 付钱。这些人在偷我业务的权重和 alpha。）

关于客户到底想要什么：

"What aligns me with Nvidia, and I think is what the technical customers want, is control over their compute, their models, their data stack, and their alpha."

（对算力、模型、数据栈、alpha 的控制权。）

注意一个被大量误读的点 ：他明确说了 "I'm not throwing shade at them"（我不是在阴阳他们）。国内不少标题写成「最强 AI 公司要完了」，那是标题党。他攻击的不是 AI 方向，也不是这两家公司的技术，而是这套路径：闭源模型 + 外部 API + 按 token 计费 + 企业持续投喂。

这张图的重点是那两条线的差异：

	流向	有账单吗	有人算吗
钱	企业 → 模型商	✅ 每月都有	✅ 财务盯着
数据 / 语境 / alpha	企业 → 模型商	❌ 没有	❌ 没人算

第二条线没有账单，所以在大多数公司的成本模型里，它的成本是零。这就是问题所在。

三、白皮书的四层模型：一份意外好用的架构清单

采访两天后，Palantir 放出了白皮书《Institutional Sovereignty in the Age of AI》，副标题是「政府和企业都能采取的 15 个步骤，用来复利你的 alpha」。

抛开它的营销属性，这份清单的分层方式对做架构的人特别有参考价值：

复制代码

基础层 (I--IV)    ZDR / AI 决策树 / 架构机会点 / 警惕错配激励
模型层 (V--VI)    模型流动性 / 拥有模型飞轮
算力层 (VII--IX)  按保障等级选硬件 / 敏感流程自有硬件 / 验证不属于你的算力
控制层 (X--XV)    模型无关 / 细粒度权限 / 审计日志 / 自适应安全 / 分支式构建 / 拥有上下文飞轮

15 条里 6 条落在控制层，模型层只有 2 条。 这个分布本身就是结论：价值不在模型层。

挑三条工程上最有嚼头的说。

3.1 ZDR：承诺是软的，结构是硬的

第 1 条 ZDR（Zero Data Retention，零数据保留）讲的不是「厂商承诺不拿你数据训练」，而是结构上根本不落盘。

白皮书举了个特别工程化的例子：模型厂商在非 ZDR 合同里写过「除非法律要求我们保留」。一旦涉诉，美国的证据开示程序（Discovery）可以把几百万条模型交互记录全部调走 ------ 但 ZDR 下的数据调不走，因为它从来没被存过。

翻译成我们熟悉的话：不要用流程约束解决架构问题。「我们规定不能这么做」和「架构上根本做不到」，是两个安全等级。

3.2 模型流动性：能换本身就是筹码

第 5 条定义：无摩擦切换到任何模型的能力。

白皮书列的威胁很现实：宕机、数据政策变更、拒答策略摇摆、地缘限制。结论：

"Reliance on a single model provider makes any of these threats existential."

但它真正点破的是博弈层面：能切换，你才有谈判筹码。厂商要动你的数据，你得能可信地说「那我换一家」。

还有个技术细节容易被忽略 ------ 聚合带来匿名性：如果你通过一个模型无关的中间层访问模型，很多组织的流量打在同一个端点上，模型厂商在推理这一刻分不清哪条是你的。这本身就是一层结构性保护。

3.3 模型无关：把智能当模块

第 10 条，一句话点出了整个架构的核心：

"This is the natural consequence of treating model intelligence as modular and distinct from your knowledge layer."

（把模型智能视为模块化的、与你的知识层相分离的，这是自然而然的结果。）

模型是模块，知识是资产。 这句话是后面所有架构设计的地基。

四、核心矛盾：你的 know-how 存在哪

压轴的第 15 条「拥有上下文飞轮」，是整份白皮书最锋利的一刀，也是开头那个 CIO 问题的答案：

"If your only assets are prompts combined with hidden model weights, there is nowhere for this signal to persist independent of the model you are using at that moment in time. The knowhow is trapped inside this single model relationship rather than owned by your institution."

回到第一节那段反模式代码。它每天在产生大量极其值钱的信号：

哪些合同条款最常被判定为高风险
哪些 AI 给的意见被法务采纳了，哪些被推翻了
什么情况下模型会答错，人怎么纠的

这些信号如果只存在于一次次 API 调用里，它们就不落地。明年你换个模型，这一年的积累基本归零。

白皮书给的解法只有一句，但它是可执行的架构约束：

知识层必须独立于模型智能层存在，而模型智能层必须是模块化、可替换的。

顺带一提，这不是纸上谈兵。采访前两天（6 月 29 日），Palantir 和 NVIDIA 联合发布了在主权环境部署 Nemotron 开放权重模型的引擎，面向美国政府机构，支持涉密和气隙（air-gapped）环境。观点、白皮书、产品，三件套是一起出的。

也得说句公道话

这段不写就成软文了：

闭源前沿模型在很多任务上确实最强 ------ 复杂推理、代码、多模态。企业买它们是因为好用，不是因为喜欢闭源。
开源不是免费午餐 ------ GPU、推理调优、MLOps、安全隔离、评测、版本治理、回归测试，成本可能比 API 账单高。
不是所有企业都值得自建 ------ 大多数公司没有强到需要维护完整模型栈的独有数据。
Palantir 的叙事天然自利 ------ 它不靠训最强模型赢，它强在数据整合、权限、工作流、编排。把价值中心从模型层挪到控制层，正好挪到自己屁股底下。

屁股歪不代表脑子错。 他这套话之所以有回响，是因为它戳中了一个真问题。下面讲我自己的答案。

五、企业 AI 中台：架构设计

Karp 讲「主权」讲得对，但太抽象 ------ CIO 拿这个词回公司，没法立项、没法排期、没法验收。

「主权」翻译成工程语言，我的答案是：企业 AI 中台。

「中台」这词被喊臭了，但在 AI 这件事上它恰好精准 ------ 因为你要的东西正好就是中间那一层：上面接业务场景，下面接模型算力，自己不产生智能，但所有智能都得从它这儿过。

5.1 分层

复制代码

┌─────────────────────────────────────────────┐
│  业务场景层  合同审核 / 问数 / 公文 / 运维...      │  ← 变化最快
├─────────────────────────────────────────────┤
│                                             │
│  ★ 企业 AI 中台（这一层必须是你自己的）          │
│                                             │
│    自有算力 · 自有模型 · 自有智能体             │  ← 控制面 + 语境面
│    自有技能 · 自有 MCP                        │     价值沉淀在这
│    ── 治理贯穿：双轴隔离 / 审计 / 权限 / 评测 ──  │
│                                             │
├─────────────────────────────────────────────┤
│  模型层（可替换的基础设施）                      │  ← 谁强用谁，谁崩换谁
│  通义 / 文心 / 豆包 / DeepSeek / 本地权重...      │
└─────────────────────────────────────────────┘

三条设计原则：

原则	含义
模型是零件	业务代码永远不直接引用具体模型/厂商
知识是资产	知识层、技能、agent 定义必须落库，独立于模型生命周期
治理内建	不是在业务里写 if，是在链路上挂 filter

5.2 中台不是重建，是接管控制面

先澄清一个最容易被误解的点，免得被理解成「推倒重来」。

建 AI 中台 不等于 自己造模型、自建机房、重写业务系统。它只做一件事：把控制面接管过来。

模型：继续用别人的
算力：大部分继续租
业务系统：一行不动

变的只是这几个问题的答案归属：

复制代码

谁能调什么？  →  从「供应商的控制台」搬到「你的权限系统」
跑在哪？      →  从「默认公有云」搬到「你的路由策略」
留了什么痕？  →  从「查不到」搬到「你的审计库」
沉淀在哪？    →  从「散在 prompt 里」搬到「你的知识层」

这是一次接管，不是一次重建。 理解这一点，立项难度会降低一个数量级。

六、五件套的工程细节

6.1 自有算力：按保障等级选，不是按性价比选

先泼冷水：自有算力 ≠ 全公司都上自己的卡，那是烧钱。

它的含义是：你得有一块自己说了算的算力，用来跑那些「绝对不能出门」的流程。其余通用任务该上公有云上公有云。

白皮书那句话说得好：硬件按「保障等级」选，不是按「性价比」选。合同条款推理跑在自己机房 vs 跑在别人那儿，成本可能差三倍，但这三倍买的不是算力，是「这件事出不了门」这个确定性。

关键工程点：部署形态必须是配置，不是架构。

yaml 复制代码

# 同一个 workflow，部署形态是配置项
hive:
  compute:
    default: cloud                # 默认走公有云
    overrides:
      - scene: contract-review    # 合同审核
        compute: on-premise       # 强制本地
      - scene: policy-qa
        compute: vpc

如果你的系统做不到「改个配置就换部署形态」，那所谓「以后可以本地化」就是空话 ------ 到时候是一次重构，不是一次配置变更。

6.2 自有模型：不是自己训，是随时能换

这条最容易被误解。一说「自有模型」，老板就以为要自己训一个 ------ 千万别，99% 的企业不该干这事。

「自有」的真实含义：模型对你来说是可替换的零件，而不是绑死的地基。

工程上的核心设计：用途（purpose）是一等公民，模型是二等公民。

yaml 复制代码

# 正例：业务声明「我要什么能力」，不声明「我要哪个模型」
hive:
  model:
    routes:
      - purpose: chat                 # 通用对话
        primary: qwen-max
        fallback: [deepseek-v3, glm-4.6]   # 熔断后按序切换

      - purpose: rerank               # 重排
        primary: bge-reranker-local

      - purpose: sensitive-review     # 敏感场景
        primary: local-qwen-32b       # 本地权重
        fallback: []                  # 不许出门，没有回落

业务代码长这样：

java 复制代码

// 正例：业务只声明用途，不认识任何厂商
@Service
public class ContractService {
    private final ModelRouter router;      // ← 中台提供

    public ReviewResult review(Contract c) {
        ChatClient client = router.resolve(Purpose.SENSITIVE_REVIEW);
        // ↑ 具体路由到哪家、是否熔断、是否降级，业务不关心也不该关心
        return client.call(...);
    }
}

对比第一节的反模式，差异是根本性的：

	反模式	中台模式
业务代码引用	`OpenAiChatModel`	`Purpose.SENSITIVE_REVIEW`
换厂商	改代码 + 重测	改配置
一家挂了	整条链路挂	自动切备
敏感场景管控	靠人自觉	路由策略强约束

主备路由与熔断是这一层的硬需求，不是锦上添花。真实生产里，厂商限流、超时、5xx 是常态。

6.3 自有智能体：agent 定义必须落库

你花三个月调出来一个「合同审核专员」：人设、审查立场、要点模板、能调哪些工具、越权找谁审批、犯过什么错怎么纠 ------ 这一整套是组织资产，不是 prompt。

反模式：agent 配置写在 yaml 或代码里，换平台就没了。

java 复制代码

// 正例：agent 是一等领域对象，落库，带租户/工作区归属，带版本
public record AgentDefinition(
    String  agentId,
    String  tenantId,          // ← 租户轴
    String  workspaceId,       // ← 工作区轴
    String  name,
    String  persona,           // 人设
    Purpose purpose,           // 要什么能力，不是要哪个模型 ★
    List<String> toolCodes,    // 授权工具
    List<String> knowledgeIds, // 绑定知识库
    GuardrailPolicy guardrail, // 护栏策略
    int     version,
    boolean published          // 草稿槽 / 发布槽双槽
) {}

几个设计要点：

purpose 而不是 modelId ------ 换模型不用重建 agent，这是 6.2 的自然延伸
草稿/发布双槽 ------ 调试不影响线上，发布可回滚
双轴归属 ------ 见第七节
上岗体检：数字员工发布前要过就绪探针（模型通不通、知识绑没绑、合规过没过），不达标不让发布。真人入职都要背调，数字员工凭什么直接上岗。

6.4 自有技能：把老师傅的方法论写进系统

这是最被低估的一件，也是我认为国内企业最有机会的一件。

每家公司都有几个老师傅：干了十五年招投标的、闭眼能看出报表哪里不对的、处理过三百起线上事故的。他们脑子里那套「先看什么、再查什么、什么情况下停下来问人」的方法论，才是真正的护城河。

技能（Skill）就是把这套方法写成可复用、可版本化、可评测的 playbook。

注意它和 prompt 的本质区别：

diff 复制代码

- prompt：  「你是一个专业的招投标专家，请帮我评标」
+ skill：   一套结构化的作业流程

markdown 复制代码

---
code: tender-evaluation
version: 3
tools: [extract_document, calc_benchmark_price, review_qualification]
---

## 评标作业流程

1. 先抽评分办法，确定价格分/技术分/商务分权重
2. 逐项核对资质，缺项直接标红，**不允许推断**
3. 价格分走基准价法，由 `calc_benchmark_price` 工具计算
   ------ 禁止让模型口算，算错一次就是事故
4. 交叉验证：总分 = 各项之和，不一致则中止并告警
5. 命中废标条款 → 立即停止，转人工

前者喂给谁都一样，后者是你独有的。它沉淀在中台里，五年之后就是你跟同行的差距。

技能这一层还有个关键工程约束：确定性的事必须交给代码，不能交给模型。上面第 3 步的基准价计算就是典型 ------ 模型负责理解和编排，工具负责算数。这条原则我们踩过坑：让模型算价格分，它能给你算出个「看起来很合理」的错数。

6.5 自有 MCP 能力：让 AI 够得着业务系统

AI 只会聊天没用，得能干活。干活就得连上 ERP、OA、工单、数据库。

MCP（Model Context Protocol）现在是这件事的事实标准。 它的工程价值在于把「AI 怎么调你的系统」标准化了 ------ 以前每接一个模型都要重写一遍适配，现在接口一套，模型随便换。

你会发现，这跟 6.2「模型可替换」是同一件事的两面：

复制代码

没有 MCP：  工具适配 × 模型厂商 = N × M 的适配矩阵
有了 MCP：  工具适配 + 模型适配 = N + M

而且它是双向的：

java 复制代码

// 方向一：消费外部 MCP 工具
mcpClient.register("github", "npx -y @modelcontextprotocol/server-github");

// 方向二：把自家业务能力标准化输出成 MCP 服务
@McpTool(name = "query_order", desc = "按订单号查询订单状态与物流")
public OrderVO queryOrder(@McpParam("orderNo") String orderNo) {
    return orderService.query(orderNo);
}

方向二做完，你的系统就从「被 AI 调用的对象」变成了「AI 生态里的一个节点」------ 上下游、客户、甚至监管都能标准化地调你。

一个实践提醒：MCP 工具必须分级管控。能读的、能写的、能花钱的，风险完全不同。工具接入必须走审批和风险分级，不能谁都能往 agent 上挂。

七、治理：贯穿五件套的那条线

上面五件，每一件都要能管得住、审得清。这部分在金融和央国企不是加分项，是入场券。

7.1 双轴隔离

租户轴 （这家机构）× 工作区轴（这个部门/项目组），两个维度同时过滤。

架构上的关键：不要在业务代码里写 if 判断租户，那是灾难 ------ 漏一个地方就是越权。正确做法是把它做成声明式的：

java 复制代码

// 端点级强制标注，拦截器统一执法
@HiveTenantAccess(mode = AccessMode.READ)
@GetMapping("/agents")
public Result<List<AgentVO>> list() {
    return Result.ok(agentQuery.list());   // 业务代码干干净净
}

配合数据层拦截器自动拼接过滤条件（MyBatis 的 InnerInterceptor 就是干这个的），做到读过滤、写盖戳：

读：自动追加 tenant_id = ? AND workspace_id IN (?)
写：自动盖上当前上下文的租户/工作区戳

踩过的坑 ：写的时候归属字段为空 → 这条数据在所有列表页都查不到（因为都按归属过滤），但它还在向量索引里 ------ 管理面看不见，检索面还能召回。我们管这个叫隐身孤儿 ，是越权召回的种子。所以写侧必须强校验：缺归属，不落库。

7.2 治理挂载点：Filter 链而不是 if

治理逻辑不应该散在业务里，而应该是执行链上可插拔的一环：

java 复制代码

public interface AgentExecutionFilter extends Ordered {
    FilterResult before(ToolCall call, AgentContext ctx);
}

// 按 @Order 自动编排：
// ToolGuardFilter(20) → AuditFilter(30) → DesensitizeFilter(40) → 真正执行

这样设计的好处：加一层治理 = 加一个 Bean，拔掉 = 删一个依赖，核心代码零改动。这跟 MyBatis 的 InnerInterceptor 链、Spring 的 Filter 链是同一个思路，没什么新东西 ------ 但很多 AI 项目恰恰是把这些逻辑硬写进 agent 循环里的。

7.3 审计要能回答什么问题

判断标准很简单，审计问你一句：

「这条结论是哪个部门的哪份文件、谁在什么时候、用哪个模型跑出来的？」

能一条 SQL 答出来，这个系统就能进生产；答不出来，就进不了。 所以 Thought / Action / Observation 全轨迹要落库，runId 要贯穿网关 → 应用 → 工具 → 模型调用全链路。

八、落地路径：别一步到位

「以后我们全都本地化」------ 这是口号，不是方案。真这么干，钱烧完了业务还没跑起来。

务实做法：中台只建一次，部署方式按敏感度挑。

档位	场景	部署方式	说明
低敏感	写周报、翻译、润色	公有云闭源 API	出事顶多重做一遍，这档纠结本地化是浪费钱
中敏感	内部知识问答、项目材料	私有云 / VPC + ZDR	数据不落盘，写进合同
高敏感	合同条款、风控、投研	自有算力 + 开放权重	这是你的 alpha，必须自持

关键在于：三档共用同一个中台、同一套工作流和权限，变的只是这一次推理跑在哪。 这才是中台的价值 ------ 它让「部署在哪」退化成配置项，而不是一次架构重构。

落地顺序：先建控制层，再谈算力

我的建议非常明确：

复制代码

第一步：模型路由 + 权限 + 审计 + 知识层   ← 花不了几个钱
        让所有 AI 调用都从中台走一遍
        立刻得到三样东西：账算得清、口子收得住、数据留得下

第二步：技能沉淀 + MCP 接入              ← 开始复利
        把老师傅方法论和业务系统接进来

第三步：按需下沉高敏感场景到本地算力      ← 这时候只是换个后端

反过来的顺序 ------ 先买一堆卡，再想怎么用 ------ 我见过好几次，基本都躺着。

九、开源实现：MateCloud 与 MateClaw

讲了这么多架构，得有能跑的东西。上面这套中台我们写了两年，开源了一大半。

MateCloud ------ AI 原生的 DDD 微服务底座

GitHub：github.com/matevip/matecloud · Apache 2.0

维度	内容
技术栈	Spring Boot 4 + Spring Cloud 2025 + Spring Cloud Alibaba + Dubbo 3 + Spring AI 2.0
Starter	28 个即插即用：持久化、缓存、分布式锁、MQ、任务调度、分库分表、多租户、安全、可观测、AI...
服务	5 个可跑服务（网关 / 认证 / 系统 / 通知 / 管理端），完整 DDD 四层架构
CLI	`mate-cli`：脚手架、Nacos 配置、服务发现、健康检查，还能当 MCP Server 接进 Claude Code
Java	21（虚拟线程）

设计哲学一句话：最小公共，每个模块只做一件事，starter = 即插即用的能力。

MateClaw ------ AI Agent 平台

GitHub：github.com/matevip/mateclaw · Apache 2.0

基本就是上面「五件套」的开源实现：

五件套	MateClaw 对应实现
自有模型	14+ 家模型厂商路由与故障切换（模型流动性）
自有智能体	数字员工：ReAct + Plan-and-Execute 编排
自有技能	Skills 体系，按员工粒度绑定
自有 MCP	MCP / ACP 双协议接入
治理	RBAC、审批流、审计留痕、内容合规扫描
附加	LLM Wiki（带引用溯源）、工作流引擎（7 种步骤模式）、多渠道（8 个 IM 平台）

技术栈：Spring Boot 3.5 + Spring AI Alibaba + MyBatis Plus + Flyway；前端 Vue 3 + TS + Vite + Element Plus；桌面端 Electron。

它 README 上有一行字，放在本文语境里挺有意思：

Apache 2.0 --- free, no metered tokens, no seat billing.

（免费，不按 token 计量，不按坐席收费。）

一个巧合

写这篇的时候我才对上号：

白皮书条款	MateClaw 的实现
第 5 条 · 模型流动性	14 家厂商随时切换 + 主备熔断
第 10 条 · 模型无关	Purpose 路由，业务不认识厂商
第 15 条 · 拥有上下文飞轮	知识层 / 技能 / agent 定义独立落库
反对 token 抽成	Apache 2.0，自主部署

一个是华尔街的叙事，一个是能 git clone 下来跑的代码。这大概说明，这条路不是谁拍脑袋想出来的 ------ 做企业交付的人，最后都会走到这儿。

至于 太一企业版 ，干的就是这件事：把模型变成可替换的推理引擎，把租户隔离、审计回放、工作流和知识沉淀这些长期值钱的东西留在企业自己手里。它和 MateClaw 是同一份核心代码 ------ 装什么 starter、有没有 license，决定它是开源版还是企业版，丢 jar 即点亮，拔 jar 即降级。

bash 复制代码

# 先从开源跑通
git clone https://github.com/matevip/matecloud    # DDD 微服务底座
git clone https://github.com/matevip/mateclaw     # AI 中台五件套

十、总结与自检清单

回到开头那位 CIO 的问题：钱花了，留下了什么？

如果你只买了 API：一堆账单，和一年份免费送出去的业务语境
如果你建了中台：一套越用越准的知识层、一群带完整档案的数字员工、一批写进系统的老师傅方法、一条随时能换供应商的路

核心观点回顾

模型会变成可替换的基础设施 ------ 像数据库、像 CDN，别把地基建在别人的 API 上
价值沉淀在控制层和语境层 ------ 白皮书 15 条里 6 条在控制层，这个分布就是答案
企业需要自己的 AI 中台 ------ 算力、模型、智能体、技能、MCP 五件套自持
中台不是重建，是接管控制面 ------ 模型继续租，业务系统不动，只把控制权拿回来
先建控制层，再谈算力 ------ 反过来的顺序基本都躺了

七个自检问题

不谈战略，全是能当场验证的：

你的模型供应商明天涨价一倍，你多久能换掉？一周还是半年？
你能证明「我们的数据没被留存」吗？还是只能出示一份合同？
这一年 AI 用下来，公司沉淀了什么资产？说得出具体的名字吗？
你调了三个月的那个智能体，换个模型还在吗？
老师傅的方法论，进系统了吗？还是只在他脑子里？
审计问「这条结论怎么来的」，你能一条 SQL 答出来吗？
哪些场景绝对不能出门？这个清单，写下来了吗？

七个问题如果有一半答不上来，那不是 AI 用得不好，是你还没开始拥有它。

Karp 那句话说得对：Sovereignty is your alpha（主权就是你的 alpha）。只不过主权不是喊出来的，是一层一层建出来的。

参考资料

声明：本文架构图均为原创绘制。Karp 采访原话、白皮书条款、Palantir × NVIDIA 发布信息均经一手来源核实；公司与人物资料来自 Palantir 财报（市值与营收截至 2026 年 7 月）及公开报道；开源项目功能点取自各自 README。文中代码为说明架构范式的示意，非可直接运行的生产代码。文中判断为作者观点，不构成投资建议 ------ Palantir 的叙事对其自身商业模式有利，本文第四节已作说明。

如果这篇对你有用，欢迎点赞收藏。有具体架构问题也欢迎评论区交流。

从 prompt 直连反模式到企业 AI 中台：一次架构演进的完整拆解算力、模型、智能体、技能、MCP 五件套自持

目录

一、先说个真实的问题

二、事件回顾：Karp 到底说了什么

2.1 先交代下背景

2.2 他说了什么

三、白皮书的四层模型：一份意外好用的架构清单

3.1 ZDR：承诺是软的，结构是硬的

3.2 模型流动性：能换本身就是筹码

3.3 模型无关：把智能当模块

四、核心矛盾：你的 know-how 存在哪

也得说句公道话

五、企业 AI 中台：架构设计

5.1 分层

5.2 中台不是重建，是接管控制面

六、五件套的工程细节

6.1 自有算力：按保障等级选，不是按性价比选

6.2 自有模型：不是自己训，是随时能换

6.3 自有智能体：agent 定义必须落库

6.4 自有技能：把老师傅的方法论写进系统

6.5 自有 MCP 能力：让 AI 够得着业务系统

七、治理：贯穿五件套的那条线

7.1 双轴隔离

7.2 治理挂载点：Filter 链而不是 if

7.3 审计要能回答什么问题

八、落地路径：别一步到位

落地顺序：先建控制层，再谈算力

九、开源实现：MateCloud 与 MateClaw

MateCloud ------ AI 原生的 DDD 微服务底座

MateClaw ------ AI Agent 平台

一个巧合

十、总结与自检清单

核心观点回顾

七个自检问题

参考资料