Semantica：智能体的开源Palantir

提示词、工具调用、令牌、延迟、追踪，甚至给定答案背后的检索块，都可以检查。

但六个月后，当有人问更难的问题"为什么代理会做出这个决策？"时，答案就是一个重建练习。

你搜索日志、重放提示词、检查向量存储命中，并希望底层数据自那时以来没有发生变化。

对于做出重要决策的AI系统来说，这是一个糟糕的架构。

这正是Semantica试图解决的问题，有趣的部分在于其数据模型。

Semantica将代理上下文（即事实、关系、决策、来源、规则和因果链接）转换成一个可以稍后查询的图。

决策成为一等公民。

这改变了你可以问的问题：

• 做出这个决策时有哪些事实可用？
• 哪个早期决策导致或影响了它？
• 这些事实来自哪里，它们后来是否发生了变化？
• 我们以前是否做过类似的决策？
• 哪些下游决策依赖于这个决策？
• 它是否通过了确定性策略检查？

对于代理来说，这是一个比记忆更有用的原语，因为它是一个决策图。

1、大多数代理栈中缺失的一层

典型的生产栈运行：用户事件 → 代理框架 → LLM → 工具和API → 向量数据库 → 日志和追踪。

它工作得很好，直到代理开始做出关键决策。

向量数据库或跟踪系统不是为回答以下问题而设计的：系统相信什么，它决定了什么，是什么导致了那个决策，以及因为那个决策发生了什么？

Semantica在栈中插入了一个图原生层：

数据源
  ↓  摄入 → 解析 → 标准化 → 分割 → 提取
  ↓  冲突检测 → 去重
  ↓  知识图谱
  ↓  本体 + 推理 + 来源 + 决策
  ↓  丰富的上下文图
  ↓  向量存储 / 图存储 / RDF存储
  ↓  REST / MCP / CLI / 资源管理器 / 你的代理

该仓库提供独立的模块，用于摄入、提取、图构建、推理、来源、决策智能、本体管理、向量搜索、时间查询、导出和可视化。

这个想法是将代理状态提升为结构化数据。

2、上下文图不是更好的RAG

很容易将Semantica归类为GraphRAG，但这低估了它。

核心抽象是上下文图，其中实体、关系、事实、决策、因果链接和时间状态都存在于一个可查询的结构中，旁边还有一个向量存储用于语义回忆。

你不再需要在嵌入和图之间做出选择。

每一层回答不同的问题：

• 向量检索："什么看起来相似？"
• 上下文图："什么是连接的？"
• 来源："这个来自哪里？"
• 决策智能："我们决定了什么，为什么？"
• 因果图："什么影响了什么？"
• 确定性规则："哪些策略暗示了这个结果？"
• 时间图："在那个时间点什么是真实的？"

Semantica使LLM周围的基础设施可检查和可重现。

编辑注： 如果你想深入了解本地LLM和代理栈，可以加入我们的Agent Foundry项目，获得实践深入培训。

3、设置和版本注意事项

pip install semantica
semantica doctor

# 所有内容，包括可选集成
pip install "semantica[all]"

一个注意事项：这个项目发展很快。

固定你验证过的版本，如果你需要未发布的行为，从源代码检出安装并固定提交。

4、快速开始：将决策转化为数据

from semantica.context import ContextGraph

ctx = ContextGraph(advanced_analytics=True)

decision_id = ctx.record_decision(
    category="vendor_selection",
    scenario="Choose a model provider for a regulated workflow",
    reasoning="Provider B supports required deployment controls and data residency",
    outcome="selected_provider_b",
    confidence=0.92,
)

chain = ctx.trace_decision_chain(decision_id)
precedents = ctx.find_similar_decisions("regulated model-provider selection", max_results=5)
impact = ctx.analyze_decision_impact(decision_id)

它看起来几乎太简单了。

重点是record_decision()在架构上的意义：你不再将自由形式的推理转储到日志行中，并希望你的可观测性后端永远保持规范记录。

你明确建模类别、场景、理由、结果、信心和与其他决策的链接。

一个警告： 不要使用reasoning字段来持久化隐藏的模型思维链，而是使用你的应用程序准备捍卫的理由：考虑的证据、应用的策略、超过的阈值、人类覆盖。

这在生产中更有用。

5、因果决策链

一个决策很有趣，但一个链是基础设施。

以一个代理采购工作流为例：安全代理对供应商进行评分，合规代理检查驻留，采购代理选择，财务代理批准合同。

大多数系统存储四个独立的追踪。

Semantica使关系显式化：

security_id = ctx.record_decision(
    category="security_review",
    scenario="Evaluate Vendor B for production AI workload",
    reasoning="SOC 2 controls verified; private networking available",
    outcome="security_approved",
    confidence=0.95,
)

selection_id = ctx.record_decision(
    category="vendor_selection",
    scenario="Choose provider after security and compliance review",
    reasoning="Vendor B passed required controls and residency constraints",
    outcome="selected_vendor_b",
    confidence=0.91,
)

contract_id = ctx.record_decision(
    category="contract_approval",
    scenario="Approve annual Vendor B platform agreement",
    reasoning="Selected vendor is approved; budget within threshold",
    outcome="contract_approved",
    confidence=0.97,
)

ctx.add_causal_relationship(security_id, selection_id, relationship_type="CAUSED")
ctx.add_causal_relationship(selection_id, contract_id, relationship_type="INFLUENCED")

why_contract = ctx.trace_decision_chain(contract_id)
blast_radius = ctx.analyze_decision_impact(selection_id)

该API目前支持三种关系类型：CAUSED（导致）、INFLUENCED（影响）和PRECEDENT_FOR（作为先例）。

现在想象一下供应商B在下个季度未通过安全审查。

你不再问"哪些追踪提到了供应商B？"，而是问：哪些后续决策受到了原始选择的影响？

这就是决策的爆炸半径分析，正是代理从副驾驶转变为自主批准、路由、购买、部署和拒绝系统所需的操作。

6、从真实数据构建图

当决策记录附加到真实的知识图谱而不是手写事实时，它们变得更有价值。

Semantica为文件、网页内容、数据库、流、Git仓库、电子邮件、Parquet、Snowflake和Databricks提供摄入器：

from semantica.ingest import FileIngestor
from semantica.kg import GraphBuilder

sources = FileIngestor().ingest_directory("./contracts/", recursive=True)
kg = GraphBuilder(merge_entities=True, enable_temporal=True).build(sources)

该管道标准化、分割、提取实体和关系、标记冲突事实、去重并构建图。

7、来源是why变得可辩护的地方

因果链告诉你决策B依赖于决策A，但你仍然需要知道什么证据支持了决策A。

Semantica的来源模块建立在W3C PROV-O之上，这是表示来源的标准本体：

from semantica.provenance import ProvenanceManager

prov = ProvenanceManager(storage_path="./provenance.db")

prov.track_entity(
    entity_id="vendor_b",
    source="security/vendor_b_assessment_2026.pdf",
    metadata={"page": 12, "extractor": "NamedEntityRecognizer", "confidence": 0.98},
)

lineage = prov.get_lineage("vendor_b")

因果关系解释依赖性，来源解释起源。

你需要两者来重构决策而不猜测。

来源条目现在是哈希链接的，每个条目都带有序列ID和到前一个条目的校验和链接，verify_chain()可以检测历史中的中断。

事实可以被无效化而不是硬删除：

integrity = prov.verify_chain()

prov.invalidate(
    "vendor_b",
    agent_id="human_security_reviewer",
    reason="Certificate expired; prior approval no longer valid",
)

一个可变的approved=false行告诉你当前的事实。

审计日志还告诉你批准曾经存在，谁撤销了它，以及为什么。

这是一个不同的要求，也是高风险代理状态的正确要求。

8、确定性推理：将策略保持在提示词之外

Semantica提供前向链接、Rete、Datalog和SPARQL引擎。

重点是：不要要求LLM即兴发挥你的系统已经知道的规则。

from semantica.reasoning import ReteEngine, Rule, Fact, RuleType

engine = ReteEngine()

engine.build_network([
    Rule(
        rule_id="manual_review",
        name="Escalate high-value restricted transactions",
        conditions=[
            {"field": "amount", "operator": ">", "value": 10000},
            {"field": "risk_tier", "operator": "in", "value": ["high", "critical"]},
        ],
        conclusion="require_manual_review",
        rule_type=RuleType.IMPLICATION,
    )
])

engine.add_fact(Fact("tx_001", "transaction", [{"amount": 25000, "risk_tier": "high"}]))
matches = engine.match_patterns()

如果策略决策来自确定性规则，你将规则ID记录在决策元数据中，以后可以重现结果。

LLM仍然提取事实并提出操作，策略门控不再是提示词形式的英语。

一个注意事项：Rete条件匹配器是故意简单的，你应该在将其连接到生产合规门之前，针对你的真实规则集验证match_patterns()。

不要在没有测试的情况下将演示规则引擎变成监管控制。

9、标准比框架更持久

Semantica依赖W3C PROV-O进行来源，RDF进行表示，SPARQL进行查询，SHACL进行图约束，OWL进行本体。

这在最新的代理SDK旁边看起来不时髦，这正是它有用的原因。

代理框架不断变化，但审计要求不会。

你的监管机构不关心哪个代理循环产生了决策。

开放标准使记录与模型提供者和当月框架解耦。

10、MCP将图转化为代理工具

Semantica通过模型上下文协议服务器暴露一切：

python -m semantica.mcp_server
# 或
semantica-mcp
{
  "mcpServers": {
    "semantica": {
      "command": "python",
      "args": ["-m", "semantica.mcp_server"]
    }
  }
}

该服务器公开实体和关系提取、决策记录和查询、先例搜索、因果链、图编辑、推理、分析和导出。

你的代理调用标准化工具来记录或检查状态。

11、它在你的栈中的位置

Semantica将自己定位在底层作为持久上下文和责任层：代理运行时在顶部，决策、因果链接、来源、推理和约束在中间，图和向量存储在底部。

虽然LLM保持概率性，但它周围的状态不再是短暂的。

12、可观测性是不够的

你仍然需要追踪、指标、评估和令牌核算，但可观测性是以执行为中心的：它告诉你软件在一次运行中做了什么。

决策图是以领域为中心的：它记录系统作为业务状态一部分所做出的决定。

考虑一个承保代理。

追踪显示模型调用了信用API并返回了approved。

决策图表示：

申请人
 ├── 收入 → $85k
 ├── DTI → 31%
 └── 信用历史 → clean_36_months

决策: proceed_to_underwriting
 ├── 基于 → 申请人事实
 ├── 来源 → 申请 + 信用报告
 └── 导致 → 承保决策

决策: approved
 ├── 受制于 → 贷款策略
 └── 影响 → 利率决策

你可以几个月后检查它，而无需重放原始模型对话。

企业已经将订单、交易、批准和会计事件视为持久的领域实体。

AI决策应该加入它们。

13、结束语

下一个问题是让代理随着时间的推移承担责任，而不仅仅是可解释。

作为架构的责任：决策 → 因果父级 → 证据 → 来源 → 策略评估 → 下游效应 → 后续修正。

Semantica是将这些原语打包到一层的更完整的开源尝试之一。

原文链接：Open Source Palantir for AI Agents

汇智网翻译整理，转载请标明出处