思考的快与慢：用 Prolog 给 LLM 装上理性大脑，然后引入知识图谱，做结构化知识双向同步，这个 agent 能力有点炸裂...

你可能会问，当 GPT 能写诗、能画画、能聊天，我们为什么还需要 Prolog？

那是我觉得，因为直觉会犯错，而逻辑不会。我最近着手在研究这一块，已经有了一个初步的系统，第一个版本已经在我的小群中开源。

我先说一个尴尬的事实

你问 ChatGPT："苏格拉底是人，人都会死，苏格拉底会死吗？"

它当然能答对。但如果你追问："你是怎么推导的？请给出形式化证明。"——它开始含糊其辞。再进一步："如果我已经告诉你 A 蕴含 B，B 蕴含 C，现在有人声称非 C，这和 A 矛盾吗？"——大模型可能对，也可能错，而且你永远无法确定它下一次是否还能对。

这就是 LLM 的根本局限：它靠统计直觉回答问题，不靠逻辑推理。 它是 Daniel Kahneman 笔下的 System 1——快，但不可靠。

我们做了一件事：给 LLM 接上一个 Prolog 引擎，让它真正"会推理"。

Prolog-World：System 1 + System 2 的工程实现

Prolog-World 是我研究的一个 Neuro-Symbolic AI Agent，核心架构可以用一张图说清楚：

┌─────────────────────────────────────────────────┐
│                    用户输入                       │
│                      │                           │
│                      ▼                           │
│              ┌──────────────┐                    │
│              │   LLM (S1)   │  自然语言理解       │
│              │  工具编排决策  │  何时调用哪个工具    │
│              └──────┬───────┘                    │
│                     │                            │
│          ┌──────────┼──────────┐                 │
│          ▼          ▼          ▼                 │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│   │  Prolog  │ │   KG     │ │ Planner  │        │
│   │  (S2)    │ │  (S2)    │ │  (S2)    │        │
│   │ 确定性推理│ │ 结构化知识│ │ HTN规划  │        │
│   └──────────┘ └──────────┘ └──────────┘        │
│          │          │          │                 │
│          └──────────┼──────────┘                 │
│                     ▼                            │
│              ┌──────────────┐                    │
│              │   Memory     │  向量记忆           │
│              │  (桥梁)      │  语义检索           │
│              └──────────────┘                    │
│                                                  │
│   ┌──────────────────────────────────────┐       │
│   │        外部世界感知 (新增)            │       │
│   │  文件读写 · 命令执行 · 网络搜索       │       │
│   └──────────────────────────────────────┘       │
└─────────────────────────────────────────────────┘

LLM 是 System 1（快思考）：负责理解用户意图、决定调用哪些工具、组织自然语言回复。

Prolog + 知识图谱 + 规划器 是 System 2（慢思考）：负责确定性逻辑推理、结构化知识存储、约束满足规划。

Memory 是桥梁：向量语义检索弥合了精确查询和模糊回忆之间的鸿沟。

这不是一个聊天机器人。这是一个可验证推理引擎。

五大核心引擎

1. Prolog 推理引擎——确定性，可验证

我们通过 swipl-wasm 在 Node.js 中运行完整的 SWI-Prolog 实例。不是玩具，是工业级 Prolog：

% 传递性推理
transitive_closure(Rel, X, Z) :-
    call(Rel, X, Z).
transitive_closure(Rel, X, Z) :-
    call(Rel, X, Y),
    transitive_closure(Rel, Y, Z).

% 分类推理
instance_of(X, Category) :-
    direct_instance(X, Intermediate),
    subclass(Intermediate, Category).

当用户说"记住：苏格拉底是人"，agent 会调用 prolog_consult 加载事实 mortal(socrates) <- human(socrates)。当用户问"苏格拉底会死吗？"，agent 调用 prolog_query，Prolog 引擎给出确定性的推理结果——不是概率，不是猜测，是证明。

2. 知识图谱——结构化知识，双向同步

基于 N3.js 的 RDF 三元组存储，每个事实以 (Subject, Predicate, Object) 形式存储：

socrates  --is_a-->  human
human     --mortal--> true
eu_cbam   --covers--> carbon_emissions

关键设计：知识图谱与 Prolog 双向同步。每次 graph_add 添加三元组时，自动执行 assertz(kg_triple(S, P, O)) 将事实同步到 Prolog。Prolog 侧的 graph_bridge.pl 提供了更高阶的查询谓词——传递闭包、对称关系、路径查找、分类推理——全部在 Prolog 中确定性执行。

这意味着：你在知识图谱中存入的事实，自动成为 Prolog 推理的前提。 两个系统共享同一份知识，但各自用最擅长的方式处理。

3. HTN 规划器——带约束的任务分解

这不是简单的步骤排序。我们实现了带 CLP(FD) 约束的 HTN（层次任务网络）规划器：

% 每个步骤有持续时间和资源需求
method(plan_travel, [
    step(set_budget,          1, [money]),
    step(research_destination,2, [internet]),
    step(find_transport,      2, [internet, money]),
    step(book_ticket,         1, [money]),
    ...
]).

% 依赖关系
depends_on(plan_travel, book_ticket, find_transport).
depends_on(plan_travel, find_transport, check_weather).

% CLP(FD) 约束求解，最小化总耗时
labeling([min(Makespan)], Starts)

CLP(FD) 是什么？它是约束逻辑编程——Prolog 不只是搜索解，而是搜索最优解。labeling([min(Makespan)], Starts) 意味着：在所有满足依赖约束的调度方案中，找到总耗时最短的那个。

这比 LLM 的"规划"强在哪？确定性 + 最优性。LLM 规划靠直觉，可能遗漏依赖、可能次优；CLP(FD) 规划保证满足所有约束，且数学上最优。

4. 向量记忆——语义检索，优雅降级

基于 hnswlib-node 的向量索引，使用本地 Ollama 的 nomic-embed-text 模型生成 768 维嵌入。支持语义相似度检索——"气候变化"能召回"全球变暖"相关的记忆。

但这里有一个工程上的巧思：优雅降级。如果 Ollama 不可用（没装、没启动），系统自动切换到关键词检索模式，不会崩溃，不会报错，只是检索精度降低。用户通过 /status 命令可以看到当前运行模式。

5. 外部世界感知——从"闭眼"到"睁眼"

8 个工具让 agent 从只能操作内部知识系统，变成了能感知和操作外部世界的系统：

file_edit 的安全设计值得一提：它要求 old_string 在文件中唯一，找到 0 次报错"未找到"，找到多次报错"不唯一"——防止误替换。这不是花哨的功能，是工程素养。

一个完整的推理场景

让我们看一个真实的交互流程，感受 System 1 + System 2 的协作：

用户：记住，欧盟碳边境调节机制（CBAM）覆盖钢铁、铝、水泥、化肥、
      电力和氢气行业，这些行业都是高碳排放行业。

Agent：
  🔧 graph_add(socrates, is_a, human)        → 知识图谱存储
  🔧 graph_add(eu_cbam, covers, steel)        → 知识图谱存储
  🔧 graph_add(steel, is_a, high_carbon)      → 知识图谱存储
  ...（6 个行业逐一存储）
  🔧 prolog_consult("high_carbon(X) :- ...")  → Prolog 加载规则
  🔧 memory_store("EU CBAM covers ...")       → 向量记忆存储

  已记住。欧盟 CBAM 覆盖 6 个高碳排放行业。

用户：那么，如果一家企业生产铝材，它需要关注 CBAM 吗？

Agent：
  🔧 memory_search("铝 CBAM")                 → 语义检索相关记忆
  🔧 graph_lookup(aluminum, _, _)             → 知识图谱查找关系
  🔧 prolog_query("covers(eu_cbam, aluminum)") → Prolog 确定性推理
  → Yes（1 个解）

  是的。根据已存储的知识：
  1. CBAM 覆盖铝行业（graph_lookup 确认）
  2. Prolog 推理验证：covers(eu_cbam, aluminum) 成立
  因此，生产铝材的企业需要关注 CBAM 合规要求。

注意最后一步：Prolog 给出的是确定性答案，不是概率。covers(eu_cbam, aluminum) 要么成立，要么不成立，没有"大概可能也许"。

为什么不用纯 LLM？

有人会问：这些推理 GPT-5 也能做啊，为什么要搞这么复杂？

三个原因：

第一，可靠性。 LLM 的推理是概率性的。同一个逻辑问题，问 10 次可能得到 9 次正确答案和 1 次幻觉。Prolog 的推理是确定性的——同样的前提，永远得到同样的结论。在法律合规、医疗诊断、金融风控这些领域，99% 的正确率不够，你需要 100%。

第二，可验证性。 LLM 说"因为 A 所以 B"，你无法验证它的推理链是否正确。Prolog 说"因为 A 所以 B"，你可以检查每一步推理规则，可以 trace 推理路径，可以证明结论的正确性。在需要审计的场景中，这至关重要。

第三，可组合性。 知识是累积的。你告诉 agent 10 个事实，它能在知识图谱中存储、在 Prolog 中推理、在记忆中检索。第 11 个问题可能需要组合前 10 个事实才能回答——LLM 的上下文窗口会耗尽，但 Prolog 的知识库不会。

我这么做技术选型，这里也有我的思考

每一个选择都不是"最好"的，是的，他是"最合适"的——在轻量、可嵌入、零外部依赖之间取得平衡。整个系统 npm install 后即可运行，不需要安装 Prolog 编译器，不需要部署向量数据库，不需要申请搜索 API。

我给Prolog-World agent 做了 18 个工具

Prolog-World 的 agent 拥有 18 个工具，覆盖从内部推理到外部感知的完整能力谱：

符号推理（System 2 核心）

• • prolog_query — 查询 Prolog 引擎
• • prolog_consult — 加载 Prolog 规则
• • prolog_list_rules — 列出已加载规则

结构化知识

• • graph_add — 添加三元组（自动同步 Prolog）
• • graph_lookup — 查询三元组
• • graph_remove — 删除三元组

语义记忆

• • memory_store — 存储记忆
• • memory_search — 语义检索
• • memory_list — 列出记忆

任务规划

• • plan_create — HTN 规划 + CLP(FD) 调度

文件系统

• • file_read / file_write / file_edit / file_glob / file_grep

命令与网络

• • bash / web_search / web_fetch

LLM 的角色是编排者——它决定何时用哪个工具、如何组合工具的输出。但它不做推理本身。推理交给 Prolog，知识交给 KG，规划交给 Planner。

在动手之初，我就思考了下谁需要这样的系统？

合规与风控分析师：需要从法规条文中提取逻辑规则，验证企业行为是否合规。推理链必须可审计、可追溯。

知识工程师：需要构建和维护领域知识库，要求知识可查询、可推理、可验证，而不是埋在 LLM 的权重里。

研究与教育工作者：需要演示逻辑推理过程，让学生看到从前提 到结论的每一步推导。

复杂任务规划者：需要带约束的任务分解和调度，不是"大概这样安排"，而是数学上最优的方案。

任何需要"确定性答案"的人：当"可能对"不够的时候，当你需要"一定对"的时候。

从这里出发，但不是结束，接下来，应该需要一个清晰的GUI 来承载我的故事

Prolog-World 是一个起点，不是一个终点。它证明了一件事：LLM + 符号推理不是学术幻想，而是可以工程化落地的架构。

System 1 负责理解世界，System 2 负责验证推理。Memory 负责连接两者。这不是一个新想法——Kahneman 在 2011 年就写在了《思考，快与慢》里。但把这本书变成可运行的代码，让"快思考"和"慢思考"真正协作，这是我们做的事。

代码在本地运行，知识在本地存储，推理在本地执行。没有云依赖，没有黑箱，没有"相信我就好"。

因为推理不需要信仰，需要的是证明。