PYTHON SDK / CONTEXT GRAPH / DECISION INTELLIGENCE

“开源 Palantir”：一个 Python SDK 如何让 AI 决策可追溯？

一次推荐、一次审批、一次策略执行，Agent 往往几秒就完成了。可当业务追问“它凭什么这么做”时，许多系统只剩下聊天记录、向量检索片段和一段难以复现的模型输出。

图源：Semantica 官网。产品将自己定位为 AI 的 Context Graph 与 Decision Intelligence 基础设施。

这正是开源项目 Semantica 想解决的问题。先给结论：它本质上是一个面向 Agent 知识图谱、上下文与决策溯源的 Python SDK，不是替代业务系统的低代码建模平台。它尝试在 LLM、向量库和 Agent 框架之下，补上一层可结构化查询、可推理、可追溯的上下文与决策记录。

“开源 Palantir”是一个有传播力的定位口号。它想传递的不是“已经等同于 Palantir”，而是把数据、知识图谱、规则、决策和证据追溯收拢为一层可操作的智能基础设施。是否能达到企业级平台的工程深度，仍应以具体场景、数据规模、治理能力和运行验证为准。

SDK 是主入口，REST、CLI、MCP 是接入面。开发者在 Python 代码中创建图、写入实体和决策；需要给其他系统或 Agent 使用时，再通过 REST API、命令行或 MCP Server 暴露这套能力。

“Agent 的价值不只在于给出答案，还在于能否把答案放回事实、规则、时间与责任的关系网中。”

先看效果：从一次输出，到一条可回溯的决策链

官网展示的核心思路是把“决策”从日志里的普通文本，提升为图谱中的一等对象。一次贷款审核、药物相互作用提示或供应商选择，可以保存其场景、理由、结果、置信度，以及与前因和后果的关系。

这样，系统不只会检索“与问题相似的材料”，还可以沿图回答：这项建议依据了哪些证据？它受哪条规则影响？它又影响了哪些后续动作？在受监管的场景里，这比一个相似度分数更接近可审计的解释。

痛点不在“记不住”，而在“记了也说不清”

向量数据库擅长找到语义相近的文本，聊天历史擅长保留短期上下文，但两者都不天然表达实体之间的业务关系、事实的有效时间，或结论的因果来路。数据发生冲突时，系统也可能只保留最后写入的一条，而没有留下分歧本身。

Semantica 的产品切入点是 Context Graph：把实体、关系、来源和决策统一放进图中，并提供时间快照、实体去重、冲突标记、图分析与混合检索。官网还强调，推理、图构建和溯源链路可以采用确定性机制，而不要求每一步都依赖 LLM。

• 传统 RAG：
  “这段资料和问题很像。”
• Context Graph：
  “这个结论关联哪些事实、谁在何时提供、它与哪些决策互相影响？”
• Decision Intelligence：
  “这次行动是否满足规则？出了问题应回看哪段因果链？”

如何使用：MCP 不是本体，Python SDK 才是主入口

Semantica 的确提供 MCP 服务，Agent 可以调用实体抽取、关系抽取、写入决策、查询先例、获取因果链、执行规则推理和导出图谱等能力。但 MCP 只是接入面，背后连接的是持续保存的图、规则和溯源记录。

对开发团队，更常见的方式是把它嵌进既有 Python 应用。最小链路是：创建 ContextGraph，写入业务实体与关系，再把每个重要决策存成图节点。官网给出的入门路径也是从 SDK 开始：

from semantica.context import ContextGraph  graph = ContextGraph(advanced_analytics=True) decision_id = graph.record_decision(     category="vendor_selection",     scenario="为受监管工作负载选择云服务商",     reasoning="满足合规要求，并符合既有团队能力",     outcome="selected_provider",     confidence=0.93, )  chain = graph.trace_decision_chain(decision_id)

然后再把它接到 LangGraph、CrewAI、LlamaIndex 或自研 Agent：模型负责理解和生成，Semantica 负责承载结构化上下文、显式关系、规则与证据。官网称核心库以 MIT 协议开源，支持自托管，并可按需连接 RDF、LPG 和向量存储后端。

本体怎么定义？实例又如何进入运行时？

这是理解该项目边界最重要的一层。Semantica 的“本体”首先是 Python 中的 ontology dict：包含 URI、类别、属性、层级、domain/range 和元数据。它可以从实体关系数据自动归纳，也可以从文本生成，或者导入现有的 OWL、RDF、Turtle、JSON-LD 文件。

运行时实例则进入另一张图：ContextGraph。一个泵、订单、病历或策略动作，都是带 id + type + content + properties 的节点；状态、隶属、因果关系等以边表达，并可带有效时间。

graph.add_node(     "pump-101", node_type="Pump", content="1号循环泵",     location="A区", valid_from="2026-08-10T09:00:00" ) graph.add_node("running", node_type="OperationalState") graph.add_edge("pump-101", "running", edge_type="hasState")

一个容易误解的事实：node_type="Pump" 默认只是运行时节点类型，并不会因为 ontology 中定义了 Pump 而被自动强校验。直接调用 add_node()、REST 或 MCP 写入，默认属于相对宽松的图写入。

要获得工程级的本体约束，需要显式建立准入门：先从 ontology dict 派生 SHACL shapes，再把待写入实例映射为 RDF data graph，调用 validate_graph()；只有校验通过才提交到运行时图或后端存储。

同样需要注意：当前 OWL/RDF 导入器主要提取类和属性等 schema，不会把外部 RDF 里的 individual 自动变成 ContextGraph 实例；实例数据仍需走独立的摄取或图写入路径。内置 ontology validator 以结构检查为主，真正强约束应以可选的 pySHACL 校验为准。

真正适合谁？先从一个可验收的闭环开始

它最适合那些“回答对不对还不够”的场景：信贷或风控审批、医疗辅助决策、合同与证据分析、网络安全事件处置，以及需要跨多个 Agent 共享同一事实基础的企业工作流。

但也不必一开始就部署完整平台。一个更稳妥的试点是：选一个高价值决策，把输入证据、业务实体、SHACL 规则校验、最终动作和后续结果连成闭环；要求系统能导出一条可读的因果与来源链。跑通后，再扩展到多数据源、本体治理或 MCP 接入。

边界要清楚：图谱与溯源能让“依据和过程”更可检查，但不能自动证明 LLM 的自然语言推理绝对正确。高风险业务仍需要明确的数据治理、规则验证、人类复核和运行时评估。

写在最后：把上下文从“提示词材料”变成“可治理资产”

大模型把信息变成语言很快；真正困难的是让语言背后的事实、关系、时间和责任不丢失。Semantica 给出的答案，是把这些内容沉淀为一张可演化的 Context Graph，并让每个重要决策都有迹可循。

这不意味着它能替代业务建模、数据质量治理或模型评估。它更像一层可组合的 SDK 基础设施：让 Agent 从“记住一些文本”，走向“能基于可追溯知识采取行动”。对于希望把 AI 从演示带入严肃业务流程的团队，这正是值得验证的价值。

资料来源
1. Semantica 官方网站（产品定位、框架集成、许可与 FAQ）
2. Semantica GitHub 仓库（模块、示例与开源实现）
3. Semantica 官方文档（安装与使用入口）
4. ContextGraph 源码（运行时节点与边写入）
5. OntologyEngine 源码（本体生成、SHACL 派生与数据图校验）
6. OntologyIngestor 源码（外部 OWL/RDF 本体导入）