MCP 自助路径

要本体,不要驻场账单。

Palantir 证明了一件事:AI 要懂业务,先要有本体。但它把这条路和 FDE 驻场模式捆在一起卖。Syntheka 拆开这两件事——同款类型化本体,加一个 MCP server 出口。你的 Agent 直连操作平台,不请驻场工程师。

25 万+美元/年:商业版 Foundry/AIP 合同起点(第三方数据)
0名驻场工程师:Syntheka 路径的要求
5个 MCP 工具现已可用,目录持续扩充
100%写动作走审批 DAG 与审计链
本体方法论

AI 懂业务,靠的是类型化模型,不是提示词。

先给 Palantir 应得的承认。Foundry Ontology 分三层,官方把它定位为「运营层」——让人与 AI Agent 协作。这个方法论是对的。

语义层

对象与关系

客户、订单、工厂、审批人——业务实体建模成带类型的对象和关系,而不是散落在十几张裸表里。AI 读到的不是列名,是业务含义。

动作层

动作与函数

「退款」「改排产」「审批通过」是带前置条件、带权限、带审计的动作类型。AI 不是生成一段 SQL 去碰数据库,而是调用受治理的动作。

动态层

模型与模拟

预测、模拟、what-if 跑在本体之上。模型输出落回同一套对象,决策链路可回放。这是 Foundry 真正的护城河,我们认。

一句话:本体让 AI 拿到业务的类型化模型。这一步值得学。下一步——交付方式——值得改。

隐含成本

Palantir 路径的价签上,写着的其实是 FDE。

买 Foundry/AIP,你买的不只是软件,还有一套交付模式。第三方(BD Emerson)给出的市场锚点:商业版合同约 25 万美元/年起——单一窄场景;企业级部署达数百万美元。为什么这么贵?因为本体建模、管道搭建、动作配置,靠的是 Forward Deployed Engineer(FDE)驻场。

驻场数月

工程师住进你的项目

FDE 模式意味着供应商工程师驻场数月,替你建模、替你搭管道。他们的日历决定你的上线时间,供应商的价目表决定你的场景取舍。

交付排队

你的路线图不是你的

第二个场景要等第一个场景收尾。加一个动作类型,走的是需求排期,不是你团队的一次提交。AI 落地的节奏被外包了。

门槛效应

中小企业直接出局

说句公道话:复杂行业里,FDE 模式有价值——高 stakes、强合规、预算充足的大型客户确实需要。但 25 万美元起步的合同,把大多数中小企业挡在门外。本体方法论不该是奢侈品。

自助路径

同款本体,MCP 出口。你的 Agent 直连。

Syntheka 保留方法论,换掉交付模式:类型化本体(语义层、动作层)加一个 MCP server 出口。你的 Agent 用标准 MCP 协议直连平台——不写集成代码,不排队等供应商。

工具目录

现已可用的五个工具

kernel_policy_explain——解释规则决策:为什么这条规则触发、依据是什么。aggregate_objects——按业务维度分组聚合对象。dataset_stats——数据集统计画像。stage_action——提议一个动作,以提案形式暂存,走审批 DAG。echo——连通性探针。目录持续扩充,以平台手册为准。

认证闸

token 认证,撤销即时生效

每个 MCP binding 走 token:服务端只存 sha256 摘要,原文不落盘。撤销即时生效。每次调用记入只增不改(append-only)的审计链——谁、用什么 Agent、调了什么、结果如何。

治理闭环

Agent 能提议,不能越过审批

读侧工具直接响应。写侧动作一律走 stage_action:提案暂存、规则评估、多节点审批 DAG、职责分离。Agent 提速,人保留否决权。这才叫在治理之下动手。

配套平台手册教会你的 Agent:每个工具的输入输出、调用时机、边界条件,都写成 Agent 可读的契约。不需要 FDE 替你翻译。

工具清单

团队在用什么 Agent,就连什么 Agent。

MCP 是开放协议。中文生态里团队已在用的通用 Agent 工具,只要支持 MCP 客户端,就能直连 Syntheka:

WorkBuddy

办公助手接上业务本体

把日常办公 Agent 接上类型化本体:查订单聚合、解释规则决策、提议动作待审批。办公场景与业务系统在同一个治理闭环里。

豆包

对话入口,治理出口

豆包作为对话前端,Syntheka 的 MCP 工具作为业务后端。用户在聊天里提问,Agent 调本体答;要动真格的写操作,走 stage_action 进审批。

千问 / Kimi / 智谱清言

任意 MCP 客户端均可

千问、Kimi、智谱清言等支持 MCP 客户端的工具都能接。不锁定某一家模型,不锁定某一家 Agent。你选前端,我们守后端。

诚实边界

这条路径也不是万能的。

三个说清楚的前提:

建模是你的活

本体要你自己定义

自助意味着自建模。你的业务对象、关系、规则,由你的团队定义进本体。我们提供工具和手册,不派人驻场。没有免费午餐,只有可负担的午餐。

目录在长

五个工具不是终点

当前五个 MCP 工具覆盖解释、聚合、统计、提议。更细粒度的工具在扩充中——以平台手册为准,我们不做超出目录的承诺。

复杂行业

重驻场需求依然存在

高 stakes、强合规的大型部署,驻场交付模式依然有它的位置。我们不做的是把它当成唯一入口、把所有人按企业价收费。

FAQ

关于 MCP 路径的常见问题。

为什么不照搬 Palantir 的路径?

本体方法论有价值,我们保留;FDE 交付模式请不起,我们换掉。Foundry/AIP 商业合同约 25 万美元/年起(第三方数据),中小企业被价格挡在门外。Syntheka 用同一套类型化本体加 MCP server,让你自己的 Agent 干活。

Syntheka 的 MCP 路径怎么让 Agent 干活?

你的 Agent 通过标准 MCP 协议直连平台:解释规则决策、聚合对象、查数据集统计、提议动作。写侧动作以提案形式暂存,走多节点审批 DAG,全部记入只增不改的审计链。

现在能用的 MCP 工具有哪些?

kernel_policy_explain(规则决策解释)、aggregate_objects(对象分组聚合)、dataset_stats(数据集统计)、stage_action(提议动作走审批 DAG)、echo(连通性探针)。目录持续扩充,以平台手册为准。

MCP 接入怎么控制权限?

每个 MCP binding 走 token 认证:服务端只存 sha256 摘要,撤销即时生效,每次调用记入审计链。你决定哪个 Agent、能碰哪些工具、留什么痕迹。

哪些 Agent 工具可以连?

任何支持 MCP 客户端的工具:WorkBuddy、豆包、千问、Kimi、智谱清言等。不换掉团队已在用的 Agent,不写集成代码,不请驻场工程师。

先连上试试,再谈转型。

早期接入从你技术栈上的自托管试点开始:你的 Postgres、你的模型端点、你的 Agent 通过 MCP 连进类型化本体。别停在聊天。让 Agent 动手——在治理之下。