Prolog-World：当 LLM 装上理性大脑，快思考与慢思考的工程化实现

> 项目：Prolog-World > 作者：coder-brzhang（小张） > 开源：https://github.com/coder-brzhang/prolog-world

---

一个尴尬的事实

你问 ChatGPT：苏格拉底是人，人都会死，苏格拉底会死吗？它当然能答对。

但追问一句：你是怎么推导的？请给出形式化证明。它开始含糊其辞。

再问：如果我已经告诉你 A 蕴含 B，B 蕴含 C，现在有人声称非 C，这和 A 矛盾吗？大模型可能对，也可能错，而且你永远无法确定它下一次是否还能对。

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

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

---

系统架构：System 1 + System 2 的工程实现

整个系统的分工非常清晰：

模块	角色	能力
LLM	System 1（快思考）	自然语言理解、工具编排决策、何时调用哪个工具
Prolog 引擎	System 2（慢思考）	确定性逻辑推理
知识图谱 (KG)	System 2（慢思考）	结构化知识存储与查询
HTN 规划器	System 2（慢思考）	带 CLP(FD) 约束的任务分解与最优调度
向量记忆	桥梁	语义检索，弥合精确查询和模糊回忆之间的鸿沟
外部世界感知	扩展	文件读写、命令执行、网络搜索

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

---

五大核心引擎

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 不可用（没装、没启动），系统自动切换到关键词检索模式，不会崩溃，不会报错，只是检索精度降低。

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

8 个工具让 agent 能感知和操作外部世界：

类别	工具	能力
文件系统	file_read / file_write / file_edit / file_glob / file_grep	读写、查找、正则搜索
命令执行	bash	执行 shell 命令
网络访问	web_search / web_fetch	DuckDuckGo 搜索、网页抓取

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

---

一个完整的推理场景

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

Agent：

graph_add(socrates, is_a, human) → 知识图谱存储
graph_add(eu_cbam, covers, steel) → 知识图谱存储
graph_add(steel, is_a, high_carbon) → 知识图谱存储
prolog_consult("high_carbon(X) :- ...") → Prolog 加载规则
memory_store("EU CBAM covers ...") → 向量记忆存储

用户：那么，如果一家企业生产铝材，它需要关注 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) 成立

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

---

为什么不用纯 LLM？

三个原因：

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

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

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

---

技术选型：每一个都是"最合适"的

技术	选择	原因
SWI-Prolog WASM	工业级 Prolog 实现	WASM 运行在 Node.js 中，无需外部进程
N3.js	RDF 语义网标准	支持命名空间、Turtle 导入导出、SPARQL 风格查询
hnswlib-node	C++ 库的 Node 绑定	百万级向量毫秒级检索
CLP(FD)	Prolog 原生约束求解	比外部 OR-Tools 更轻量，与推理引擎无缝集成
DuckDuckGo	HTML 搜索	无需 API Key，Cheerio 解析即可
Zod + JSON Schema	工具参数验证	自动生成 OpenAI function calling 格式

整个系统 npm install 后即可运行，不需要安装 Prolog 编译器，不需要部署向量数据库，不需要申请搜索 API。

---

18 个工具：完整能力谱

类别	工具	用途
符号推理	prolog_query / prolog_consult / prolog_list_rules	确定性推理
结构化知识	graph_add / 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	外部世界感知

---

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

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

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

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

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

---

参考

开源地址：https://github.com/coder-brzhang/prolog-world
Kahneman, D. (2011). *Thinking, Fast and Slow*. Farrar, Straus and Giroux.
SWI-Prolog: https://www.swi-prolog.org/
N3.js: https://github.com/rdfjs/N3.js
hnswlib: https://github.com/nmslib/hnswlib

#NeuroSymbolicAI #Prolog #LLM #System1System2 #KnowledgeGraph #推理引擎 #HTN #知识图谱 #小凯