你可能会问，当 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–> humanhuman –mortal–> trueeu_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_read` | 读取文件内容，支持行范围 |
| | `file_write` | 写入文件，自动创建目录 |
| | `file_edit` | 精确替换（要求 old_string 唯一） |
| | `file_glob` | 按模式查找文件 |
| | `file_grep` | 正则搜索文件内容 |
| 命令执行 | `bash` | 执行 shell 命令 |
| 网络访问 | `web_search` | DuckDuckGo 搜索（无需 API Key） |
| | `web_fetch` | 抓取网页并提取正文 |
`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 的知识库不会。
### 我这么做技术选型，这里也有我的思考
| 选择 | 为什么 |
| — | — |
| 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。
### 我给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 年就写在了《思考，快与慢》里。但把这本书变成可运行的代码，让”快思考”和”慢思考”真正协作，这是我们做的事。
代码在本地运行，知识在本地存储，推理在本地执行。没有云依赖，没有黑箱，没有”相信我就好”。
**因为推理不需要信仰，需要的是证明。**
