前面几篇我们把 Palantir 的几层地基铺开了：Ontology 是那层语义契约，Foundry 负责把数据算出来、把流程跑起来，Apollo 把这一切部署到哪怕最严苛的隔离环境里。这一篇讲压在最上面的那一 intelligent 层，AIP（Artificial Intelligence Platform）。
我的看法很直接：AIP 不是"给 Palantir 接个大模型"这么简单。它的真正命题只有一个，怎么让一个本质上会胡说、会幻觉、会编造接口名的概率模型，变成一个能在生产环境里可靠地看数据、做决定、改状态的组件。如果你把 AIP 理解成"ChatGPT 套个企业壳"，那你漏掉的是它最值钱的那部分设计。
这一篇就把 AIP 内部怎么把 LLM 和 Ontology 拧成一个可控的推理---行动闭环讲透。四个核心构件：Model Gateway 把模型入口收口，AIP Logic 把推理流程用 Ontology 对象与动作来编排，retrieve→reason→act 形成循环，Ontology Action 把"能做什么"用白名单和强类型锁死，最后人在环与审计兜住后果。读下来你会明白，可靠的 AI 落地靠的不是把模型调得更聪明，而是把模型框得更死。
先说清楚问题：为什么裸接大模型一定翻车
在讲 AIP 怎么设计之前，得先把"裸接"为什么不行讲明白。不然你读后面那些设计会觉得是过度工程。
大模型本质上是一个无状态的 token 预测器。它不知道你公司里"航班延误"具体指哪张表，不知道"客户"主键是啥，更不知道"给这个客户降额"在法律上需要什么审批。它只会根据训练时见过的统计规律，吐出"看起来像那么回事"的文字。把它直接接进企业系统，会撞上三道墙。
第一道墙是幻觉外溢到写入 。RAG 能解决"读"的问题，把相关文档塞进上下文，让模型少编点。但 RAG 止步于"读"。模型读完了，输出还是一段自由文本。从"模型建议把订单 X 升级"到"订单 X 真的在系统里被改成升级状态"，中间还隔着一道受控的桥。裸接方案里这道桥往往是模型自己生成的 SQL 或 API 调用，字段名是模型编的，表名是模型猜的，参数边界是模型随手填的。一次成功的幻觉就足够把测试环境搅成生产事故。
第二道墙是模型本身不稳定。同一个 prompt，换一个模型版本、换一个供应商，行为就漂移。今天 GPT 能稳定走完流程，明天某个小模型在第三步就开始胡言乱语。如果你的业务逻辑直接耦合在某个具体模型上，你就没有灰度、没有回滚、没有 A/B。模型是 AI 应用里变动最频繁、最不可控的那一环，把它焊死在业务代码里是自找麻烦。
第三道墙是合规与数据驻留。金融、政府、医疗的客户，数据根本不允许出门。你没法把包含 PII 的工单发给第三方 SaaS 模型。但同一套业务里，又有一些任务用云端大模型更划算。这就需要一个能在"哪个数据能进哪个模型"上做策略控制的层，而不是靠每个写 prompt 的工程师自觉。
AIP 的全部设计，就是在这三道墙上分别砌了砖。我下面逐个拆。
Model Gateway：把模型入口收回到平台
Model Gateway 是 AIP 最底层、也最容易被忽视的一个构件。它做的事情听起来平淡：提供一张统一的接口面，把所有模型供应商和自托管模型收口。AIP Logic、AIP Assist、Agent Service 这些上层组件，调模型时只面对一个统一 API，完全不关心背后是 OpenAI、Anthropic、Cohere，还是跑在你自己 VPC 里的 Llama、Qwen 或者自训模型。
我之所以说它关键，是因为它把"用哪个模型、数据怎么过、怎么计费、怎么兜底"从每一个 Agent 开发者手里，收回到了平台手里。这几点展开讲。
统一鉴权与租户隔离 。一个企业里几十个团队都在用模型，Gateway 负责 token 计量、配额、租户隔离。每个 Logic function、每个 Agent 的调用都归到具体主体，后面做成本核算和异常检测才有据可查。
模型注册与版本管理 。在 Gateway 眼里，模型是"可被引用的实体"，有版本、有别名。Logic 里引用的不是模糊的"GPT-4"，而是类似 gpt-4o@2024-08 这种带版本的指针。模型供应商发新版本时，平台可以灰度切流，而不是所有业务在同一秒被 silently 换 model。这一条直接回应了前面说的"模型不稳定"那道墙。
路由与回退对上层透明 。主模型返回 429 或者超时，Gateway 自动切备用模型，上层编排逻辑完全无感。你的推理流程不会因为某一个供应商抖动就整体崩掉。多模型策略由此成为可能：简单分类用便宜小模型，复杂推理用强模型，敏感数据走私有模型，而这一切对上层是同一套调用语义。
策略化的数据治理 。这是我最想强调的一点。Gateway 上能配策略，规定哪些 Ontology 数据可以送进哪个模型。比如"含客户 PII 的对象禁止发给任何第三方模型，只能走本地私有模型"。把"能不能把数据发给外部"从prompt 里的一个叮嘱，变成网关层的硬策略。叮嘱会被忘，策略不会。
协议归一化 。不同厂商的 function calling、流式输出格式各不相同，Gateway 把这些差异抹平，让上层永远用统一的函数调用语义去表达"我要模型调这个工具"。上层写一次，底层换模型不重写。
这里有个容易混的点要拎出来：Model Gateway 不是简单的一层 API 反向代理 。普通网关只做转发和限流，不管"语义"。Model Gateway 的独到之处在于它理解"本次调用要带什么 Ontology 上下文出去"。它能在请求出库之前，就按策略决定是否脱敏、是否禁止某些字段离开私有域、是否强制走本地模型。换句话说，它把数据驻留和合规，从"每个应用自己操心"上提到了"平台统一强制"的层面。这也解释了为什么 Palantir 能拿下那些连数据脱敏都要逐字段审计的客户------闸在 Gateway，不在业务代码里。
一句话收住：Model Gateway 是 AIP 可控性的第一道闸，它让"模型"从业务代码里的一个硬编码依赖，变成平台托管的、可替换的、可计量的资源。
AIP Logic：别用裸 prompt，用 Ontology 对象编排推理
有了 Gateway，模型能稳定被调用了。下一个问题是，怎么组织"调模型"这件事本身。这就是 AIP Logic 的地盘。
AIP Logic 是一个给工程师和建模分析师用的 LLM 函数编排环境。它的核心思想和裸 prompt 工程 有本质区别：你不是在一段长 prompt 里写满指令让模型自由发挥，而是把推理流程拆成有类型的步骤，每一步操作的对象都是 Ontology 里的真实实体。
一个 AIP Logic function，输入是 Ontology 对象或参数，中间可以挂多个 step：检索一批对象、把这批对象送进模型推理、对模型输出做结构化转换、调用一个 Ontology Action。最后输出可以是一个新对象、一个建议、或者一个 Action 的调用提案。整条链路是声明式、可版本化、可测试的。
这里最关键的一点，模型被框进了 Ontology 给的"词汇表"里。它读到的上下文是结构化的对象（属性、链接都摆好），它吐出的"意图"被解析成有限的、预定义的动作候选 ，再交给 Ontology 去执行与校验。模型不是在一个无限大的自由空间里写代码，而是在一个有边界的语义空间里做选择。
我拿裸 LangChain 做个对比你就懂了。LangChain 里 tool 是你自己写的 Python 函数，模型可以编出不存在的参数名，可以无限递归调用，可以拿着 tool 的返回再胡拼一个 SQL 。AIP Logic 里的"工具"不是你随手写的 Python，而是来自 Ontology Action ，是被类型化、被校验、被权限约束的。模型能选的工具集合，就是 Ontology 暴露给它的那几个 Action，多一个都没有。这是 RAG 之外、决定"能不能安全写回"的本质分野。
而且 Logic function 本身成了平台的一等公民。它可以版本化、可以用 AIP Evaluations 跑回归测试、可以被别的 Logic 调用、也可以被一个普通 Web 应用或者一个 Agent 复用。它从"一段脚本"变成了"一个平台资产"，全公司能审、能改、能复用。
retrieve → reason → act：闭环才是重点
讲到这里，AIP 真正的灵魂才出现。前面都是零件，retrieve→reason→act 是它们咬合的方式，而且它不是一个一次性的问答，是一个能自转的循环。
retrieve（检索） 。AIP Logic 第一步不是让模型瞎想，而是先用 Ontology 检索，拿到和当前任务相关的对象集合（ObjectSet），连同它们的属性、链接关系一起取出来。比如一个排查故障的 Logic，一上来先按"机型 + 最近 24 小时"从 Ontology 拉出一批设备对象，再顺着链接把它们的维修记录、遥测、所属风场一并带出来。这一步还能叠加向量检索，把语义相似的对象也拉进来。重要的是，模型锚定的是"真实的、此刻的数据"，不是它训练记忆里模糊的印象。retrieve 走的就是 Ontology 这一层，模型在开门那一刻就被告知：你只能基于这些对象说话。它在检索阶段就已经被喂了"该看什么"，而不是被放任去想象世界长什么样。
reason（推理） 。把结构化上下文加上用户意图，组装成模型能消费的 prompt 或 tool 上下文，通过 Model Gateway 送进模型。模型在这一步干的事很纯粹：基于给定事实做推理，或者生成一个结构化的计划。举例，"这趟航班延误了，排查根因"，模型拿到的是这趟航班对象、它的地服记录、天气、前序航班状态，而不是凭空编一个"可能是天气原因"。"从这 200 个客户里挑 30 个最该挽留的"，模型拿到的是这 200 个对象的真实属性，而不是它想象中的客户。
act（行动） 。模型的输出不直接碰数据库，而是被映射成一个或多个 Ontology Action 的调用提案。比如"把订单 X 状态改成 escalated""为客户 Y 创建一个 follow-up task"。这些提案不会自己偷偷执行，它们进入 Ontology 的 Action 执行闸门（下面一节细讲），经过校验、权限、可能的人工审批，才真正落下去。
闭环自转 。Action 改变对象状态后，Ontology 的物化层把新状态实时反映出来，下一轮 retrieve 看到的就是更新后的世界。于是流程可以循环：再检索、再推理、再根据新状态决定下一步动作，直到任务完成。这才是"AI Agent"在企业里该有的样子，不是跑一次就结束的聊天，而是能多步推进、且每一步都踩在真实数据上的推理---行动循环。
我特别想点出，这个循环里模型的"读"走 Ontology，"写"走 Action，它从头到尾没有脱离 Ontology 给的边界。这正是它比裸 RAG + 自由 SQL 可靠的根本原因：模型的活动范围被预先划定了。
Action 约束：让大模型根本没法乱写
前面反复说 Action 是"写"的闸门。这一节把它打开，讲为什么它能把"幻觉乱写 "从概率问题变成"不可能发生"的架构问题。
裸接大模型最危险的不是它编文字，是它编"该调哪个接口、该传什么参数"。一段看起来完全合理的 JSON，字段名差一个字，写到生产库就是事故。Ontology Action 的解法是白名单加强类型：模型不是在自由空间里生成代码，而是在一个有限动作集合里"选一个、填参数"。
参数类型与范围强约束 。每个 Action 声明的参数都是强类型的，金额、主键、枚举，各有各的形状。模型填错类型、填越界的值，Ontology 直接拒绝这个提案，不会含糊地"尽量执行"。也就是说，最坏情况下模型得到一个明确的报错，而不是一次悄无声息的错误写入。
校验逻辑前置 。Action 自带业务校验，比如"只能改自己 region 的订单""退款金额不能超过授权额度"。这套校验由平台保证一定在执行的"前一刻"跑，不是靠调用方记得检查。即使模型想绕过，也绕不过平台那道硬编码的校验。
权限同权于人类 。这是很多人忽略的杀手锏。AI 调 Action，走的是和人类用户完全相同的权限模型，角色级、甚至对象属性级。某个 Action 对当前 AI 身份不可见，它从根本上就不在模型的"可选动作"清单里。看不到，就调不了。权限不是事后审查，是事前就删掉了选项。
还要补一句底层机制，否则容易误解。那些暴露给模型的"工具"，不是工程师手敲 JSON schema 喂给模型的，而是通过 Tool Factory 直接从 Ontology Action 的定义自动生成的。Action 怎么声明参数、怎么约束类型、有哪些可选值，这份 schema 就是模型的工具描述。由于模型看到的工具集本就是 Ontology 的真实投影，它从根上就没有"发明一个新接口"的可能。你让裸接大模型的系统保证这点，只能靠 prompt 里苦苦哀求，而 AIP 是在类型系统层面把它焊死的。
审批流兜底 。对高后果动作，可以在 Action 上设"需人工批准"。模型产生的提案先挂起，在界面里把提案内容、依据、将影响的对象清清楚楚摆出来，等人点头，write-back 才真正发生。这一步把"错误自动扩散"挡在了门外。
把这些合起来看，Action 约束干的是一件很彻底的事：它把模型能犯的错，从"它可能编"收死成"它根本没选项 "。模型再聪明也只能在框里聪明，框外的世界它碰不到。这就是 AIP 敢让大模型去碰生产数据的原因，不是它信任模型，是它不让模型有越界的机会。
AIP Logic 编排与人在环：后果要有人兜
有了 Gateway、Logic、Action 约束，系统已经能自动化跑了。但 AIP 的设计哲学里，人在环 不是事后补丁，是原生设计原语。这一段把"编排"和"人在环"合在一起讲，因为在实际界面里它们就是一体的。
在 AIP 的 Scenario 和 AIP Assist 这类应用里，AI 跑完一圈推理，产出的不是"已经发生的改变"，而是一个"提案（proposal） "。界面把提案内容、决策依据、将影响的对象一目了然地铺开，人确认后才 enact。这个设计背后的判断很清醒：LLM 不可解释、不可保证正确，在高后果场景（放款、调度、医疗处置）上不能全自动。让人确认一下，增加的延迟微乎其微，但把"错误自动扩散"彻底挡住。
而且人在环不是单向的"人批准机器"。人在环产生的是一个高质量的、带标注的数据飞轮。每一次人修改了 AI 的提案、或者驳回了某个动作，都是一条训练信号，可以反哺 AIP Evaluations 去持续测 Logic function 的质量。模型升级前先跑一遍这套评估回归，行为漂移能提前抓住。
审计是另一个不能绕过的点。AIP 里每一次经 Model Gateway 的模型调用、每一次 Action 提案与执行，都落进统一的轨迹 。你能回答"为什么系统今天给这个客户降了额"------因为能完整回溯到那次模型调用、那段送进去的上下文、那个被采纳的提案、那次人的确认。对金融和医疗的合规而言，这不是锦上添花，是硬要求。而且 Action History 让错误操作可追溯、可反向，Agent 的行为不再是黑盒，而是可观测、可回滚的。
收束：可靠的 AI 落地靠框死，不靠调聪明
把这几块拼起来，AIP 的全貌就清晰了。它压在 Foundry 的计算能力、Ontology 的语义契约、Apollo 的部署底座之上，做一件事：把大模型这颗不可控的概率引擎 ，变成 Ontology 推理---行动闭环里的一个受控组件。
Model Gateway 管住入口，让模型可替换、可计量、可策略化；AIP Logic 管住编排，让推理用 Ontology 的真对象而非裸 prompt；Ontology Action 管住出口，让"能做什么"被白名单和强类型 锁死；人在环与审计管住后果，让每一次 AI 决策可追溯、可确认。四者合力，LLM 从一个"会聊天的玩具"，变成一个"能改生产数据的可靠执行器"。
我的看法是，这一整套设计的精髓，从来不是"怎么让模型更懂业务"，而是"怎么让模型没机会不懂装懂 "。RAG 解决记忆，微调解决风格，但真正让企业敢把 AI 接到核心系统的，是这种把不确定性框进可控边界的工程。这也是为什么我说，看懂了 AIP，你才看懂 Palantir 讲的"AI 落地到决策"到底靠什么撑着。
到这一篇，Palantir 的架构主线就收束了。Ontology 是契约，Foundry 是肌肉，Apollo 是神经，AIP 是大脑。四条线拧在一起，才是那个能在生产环境里既智能又可靠的系统。