先把时间拨回到一次不算复杂的调试现场。
我在本地部署了一个带 Agent 能力的问答应用，模型用的是开源的中小型大模型。用户问了一个非常生活化的问题：“我今天下午想去图书馆还书，图书馆会开门吗？”模型给出的回复是一大段结构完整的说明，里面有“系统正在处理您的请求，请稍后查看”这类话术，还有一段听起来很合理的开放时间描述。问题在于，模型根本不掌握本地图书馆的真实开放时间，它也没有去查知识库，它只是“看起来像在回答”。
当时我最大的感受不是模型能力不够，而是它缺少一样很基础的东西：它不知道“回答不知道”这件事本身是一种常识。它更不知道，当信息不足时，正确的做法是先补充必要的信息，而不是先写一段漂亮话。
这个场景，恰好让我重新想起一位老前辈。John McCarthy，人工智能这个名词的提出者之一，也是逻辑和形式化常识研究路线的奠基人。他在上世纪中叶就提出过一个问题：机器如何拥有常识？如何把人类默认不说、但对推理至关重要的那部分知识，转换成程序可以使用的形式？
几十年过去，这个问题非但没有过时，反而因为大模型的流行变得更加尖锐。大模型擅长用自然语言生成“像常识的话”，但它未必通过逻辑推理获得这些答案。重新看 McCarthy 的那套思路，对今天做 AI 应用、做 Agent 开发、做大模型工程化的人来说，不是怀旧，而是补课。
这篇博客，我想把“AI、逻辑与常识形式化”这件事拆开来讲。不打算写成哲学讲义，而是想回到工程视角：John McCarthy 当年到底为了解决什么难题提出了这条路线？它为什么难？它和大模型时代有什么关系？我们今天能不能用它的思路，解决实际开发中的“模型一本正经胡说八道”问题？
1. 重新看 John McCarthy 这道题：它不是哲学课，而是 AI 系统的地基问题
1.1 人工智能的诞生，绕不开“常识”这个关键词
提到 John McCarthy，绕不开两个标志性事件。第一个是 1956 年的达特茅斯会议，按照计算机史上的通行说法，“Artificial Intelligence”这个术语在这次会议上被正式使用，McCarthy 是发起人之一。第二个是他在 1959 年前后写作并发表的论文，题目是 “Programs with Common Sense”，核心思想是讨论如何让程序具备常识推理能力。
这里需要澄清一个常见误解。McCarthy 做“常识形式化”，不是在课堂里讨论“普通人如何思考”，而是在回答一个具体的工程问题：机器能不能根据目标，自主选择要做的运算，而不是每一步都由程序员硬编码？
当年主流的 AI 路线是“启发式搜索”。程序通过搜索组合爆炸式的可能性，选出看起来最优的策略。Chess 程序、下棋程序、走迷宫程序，都是这种思路的产物。但 McCarthy 认为，这条路走不远。原因很简单：光靠搜索，程序不知道自己为什么要搜索。它缺少一种把“当前目标、可用知识、可选行动、预期结果”组织起来的框架。
于是他在论文里提出一个著名的设想：“咨询者”。这个程序内部有一条知识库，里面有关于外部世界的陈述，比如“船可以过河”“渡船通常运行时间有限制”。程序不做程序员的奴隶，而是能接受人类用自然语言或逻辑语言给出的建议，再根据目标自行推导。
用今天的眼光看，这就是一个“常识底座 + 推理引擎 + 行为执行”的雏形。放在上世纪五十年代，这个设想非常超前，超前到当时连足够大的内存和足够快的推理速度都不存在。但 McCarthty 想解决的根本问题，和大模型时代我们遇到的问题是同一个：机器不能只会模仿行为，还要能对行为做出可解释的判断。
1.2 McCarthy 真正想做的事，不是“逻辑万能”，而是“知识可被机器检查”
很多人提起 McCarthy，就以为他主张“一切智能都可以用逻辑表达”。这是不准确的。如果你真的读过关于他思想的文献，会发现他更关心的是如何让程序“接受建议”，而不是让逻辑替程序做所有决定。
在接受建议这个需求下，逻辑变成了一个基础设施。因为一个建议要能被程序接受，就必须要形式化。形式化意味着程序可以对其进行一致性检查、推理、查询、修正。这和今天我们做业务系统的思路是一样的：你希望 AI 能读取数据库、调用接口、根据规则做决策，那你就需要一套能让机器理解和操作的知识表示方式，而不是让自然语言漂浮在模型上下文中。
McCarthy 的核心判断，我理解成一句话：真正的智能系统，必须能把“默认不说的常识”转成“可以被检查和修正的知识”。
这句话在今天依然成立。甚至可以说，大模型时代最缺的就是这个。模型内部有千亿参数，有海量语料统计规律，但当模型说“图书馆开门”时，你无法检查它是从哪条知识里推导出来的，也无法在不重新训练的情况下修正它的错误。因为知识没有被显式形式化，它只是参数的一部分。
这就是 McCarthy 这条路线真正的价值所在：它提醒我们，人工智能不只有“行为层面”的智能，还有“机制层面”的知识表示与推理。没有一个可检查的知识层，智能系统就永远是黑盒。
2. 形式化常识为什么难：逻辑不是缺严谨性，而是缺“默认值”
2.1 逻辑擅长演绎，但不擅长处理“通常”和“例外”
McCarthy 很清楚，把常识写进逻辑并不容易。难点不在逻辑本身，而在常识的特殊性质。
常识和数学公理完全不同。数学公理是尽可能少的、无例外的、长期不变的规则。常识呢？常识是高度依赖语境的、有例外的、甚至相互冲突的。
一句话：逻辑是演绎的，常识是概率性的；逻辑偏爱“永远成立”，常识偏爱“通常成立，但有例外”。
比如“鸟会飞”。这是一个非常典型的常识判断。但“鸟”这个类别里有企鹅、鸵鸟、几维鸟，它们不会飞。如果你把“鸟会飞”写成一条严格的一阶逻辑规则，那一旦遇到企鹅，整个推理系统就崩溃了。因为你推出“企鹅会飞”，这与现实矛盾。
McCarthy 面临的问题就是：如何让逻辑系统能够表达“除非有例外，否则默认鸟会飞”？
2.2 默认逻辑：让规则可以被推翻，但只有确实出现反例时才推翻
为了解决这个问题，McCarthy 在 1980 年前后提出了“默认逻辑”。它的核心想法很简单但影响深远：允许规则带有一个默认条件，默认条件在没看到反例时可以成立，一旦出现反例，就撤销这条默认结论。
用一句通俗的话说：默认逻辑让系统学会了“在没有特殊说明的情况下，先按常识走，但保留修正可能”。
这个设计在工程上非常重要。因为它允许 AI 系统在信息不完整的情况下做出初步判断，同时允许在获得新证据时自动纠正结论。这不就是现实世界里人类处理信息的方式吗？你约了朋友吃午饭，默认朋友会准时到，但如果你收到“路上堵车”的消息，就会更新预期。
默认逻辑只是一个开端。McCarthy 还研究过“时间演算”，用来处理事情发生的前后顺序和因果影响；研究过“耐心理论”，用来表达“知识”“信念”“意图”这类心理状态。这些东西听起来偏哲学，但放到今天的 Agent 系统里，就是状态机、事件驱动、意图识别和上下文管理的思想源头。
2.3 心智状态的表达：常识还涉及“知道”和“不知道”
真正让情况变复杂的，是常识中关于认知状态的部分。
人类常识里有大量命题是关于“知道”的。比如你知道自己的生日，知道开门前需要插钥匙，知道不知道某个答案时可以说“我不知道”。这些知识不是关于外部世界的，而是关于“自己知道什么，别人知道什么，信息是否充分”的。
McCarthy 在相关研究里明确指出，AI 系统如果要和人协作，就必须能表达这类心智状态。否则系统既不知道自己在哪些领域知识充足，不知道什么时候该向用户反问，也不知道如何描述自己的不确定性。
放在今天的大模型应用里，这个点格外扎眼。你问一个大模型“你确定这个回答是对的吗？”，它通常会回答“是的，根据我的理解”，哪怕这个回答完全是编造出来的。因为模型没有一种机制来判断自己“是否知道”。这不是模型的道德问题，而是架构缺陷：它没有一个显式的、可检查的知识边界。
一个能形式化心智状态的系统，至少可以表达这样一条规则：
- 如果“用户问的问题不在我的知识库覆盖范围内”，那么我应该输出“信息不足，无法确认”，而不是凭空生成答案。
就是这么一条简单的公理，大多数大模型应用实现不了。原因不是工程难度，而是因为早期架构里没有这个概念。
3. 技术史的下一站：从 Advice Taker 到知识图谱、本体与大模型护栏
3.1 知识图谱和本体工程：把常识装进结构，而不是参数
McCarthy 的路线在二十世纪后半叶演变成了几个分支，其中最有名的工程产物是知识图谱和本体工程。
知识图谱的逻辑是：把世界的实体、概念、属性和关系组织成一张图，用节点和边表示。比如“北京”是“中国”的首都，“中国”是“中华人民共和国”的简称，“长城”位于“北京”地区。这样机器可以通过图谱查询关系，进行简单推理。
本体工程则更进一步，它试图定义某一领域的概念层次、属性、约束和规则。在医疗、法律、金融这些需要严谨逻辑的行业里，本体系统至今仍在发挥作用。比如医院的电子病历系统，会用本体定义“患者”“诊断”“药物”“过敏反应”之间的关系；当医生开出一种与过敏史冲突的药物时，系统就会报警。
这条路和 McCarthy 的关系非常直接：他们都认为，知识必须先被表示成机器可以操作的结构，才谈得上推理和判断。区别在于，McCarthy 希望找到一个通用框架，而知识图谱和本体工程落地时往往是面向特定领域的。
3.2 大模型的幻觉问题，让逻辑层重新变得必要
大模型出现后，很多人一度认为“不再需要人工写规则了，模型自己就能学会一切”。但随着实际业务落地，越来越多团队发现了问题。
模型的生成过程本质上是“基于上下文预测最可能的下一段文字”。它不像知识图谱那样有明确的查询机制，也不像规则引擎那样有可检查的推理链路。所以当模型遇到知识盲区时，它并不会像人一样说“我不知道”，而是会用已有语料中相似话题的统计规律，拼出一段看起来合理但实际上可能是错误的内容。这就是常说的“幻觉”。
幻觉为什么难以消灭？因为模型没有“常识一致性检查”模块。你可以在提示词里写“请只在确定时回答”，但模型本质上不会执行这条指令，它只是在生成文本时更谨慎一点。真正的解决方案，必须从架构层面引入一个“逻辑校验层”。
这个逻辑校验层，就是在重拾 McCarthy 当年的想法：把常识问题拆成知识表示和推理两部分。对大模型来说，生成文本是能力的一部分；对业务应用来说，还要加一层判断：这段文本是否和已知知识一致？是否违背了必要前提？是否超出了知识覆盖范围？
3.3 Agent 与工具调用：推理外壳就是形式化常识的现代版
最近一年做 Agent 应用的人越来越多。所谓 Agent，通常指一个可以自主规划任务、调用工具、观察结果、迭代执行的系统。它们不像传统程序那样按固定流程走，而是根据目标动态选择工具和路径。
这种动态决策，恰恰需要大量的“常识”。比如 Agent 不知道当前时间是几点，就无法判断是否应该提醒用户“你有一个日程安排在 10 分钟之后”。比如 Agent 没有业务规则约束，就可能输出“可以取消订单”这种错误建议。
所以在实际工程里，成熟的 Agent 框架都会加一层“推理外壳”。这层外壳可能是提示词模板，可能是状态机，可能是决策树，也可能是一组硬性约束规则。它的作用就是确保 Agent 的每一步行动都符合必要的常识，而不是完全依赖模型的自由发挥。
如果你把状态机里的先决条件、Action 前置检查、上下文校验这些机制拿出来看，会发现它们本质上是 McCarthy "把常识形式化" 这个命题的工程化变体。只是换了一套语言，换了一种部署方式，问题内核并没有变。
4. 最简工程路径：给 AI 应用加一个“常识判断层”
4.1 不要一上来就搭复杂的本体系统，先定义“不满足输入”
很多人读完 McCarthy 的“常识形式化”概念，第一反应是：那我是不是应该先建一个庞大的知识图谱，把世界上的常识全部装进去？
我的建议是：千万不要。
知识图谱和本体系统成本很高，维护复杂，而且容易僵化。对于大多数中小团队和普通业务场景，你根本不需要“全世界的常识”，只需要“你这个业务场景里最基础的那几十条规则”。
最稳妥的做法，是先定义“不满足输入”的规则集。也就是：在什么情况下，程序必须拒绝处理，或者返回“信息不足”。
举个例子。如果你在做一个日程安排助手，你需要定义的基础规则可能包括：
- 用户必须提供“开始时间”，如果没有，就不能创建日程。
- 如果用户只说了“明天下午”，而没有说明具体的小时数，就属于信息不完整。
- 如果用户提到“明天”，但当前时间已经是今晚 23 点以后，那就需要提醒“明天其实只有一小时，你确定吗”。
- 如果用户要邀请的会议室已经存在冲突，就必须返回冲突提示，而不是硬生成一个预约成功。
这些都是常识，都不难写，但它们就是程序能不能正常使用的关键。
4.2 用约束规则和兜底策略，守住模型的生成结果
我一般会把“常识判断层”放在模型前后两端，做成两道闸门。
第一道是输入校验闸门。在把用户问题交给大模型之前，先检查必要字段。字段缺失就触发反问流程，不让模型自行补全。这样做的好处是，防止模型一本正经地把“今天下午有空”这种模糊表述理解成“今天下午 15 点”。
第二道是输出校验闸门。模型生成结果后，用一组规则检查输出是否合法。比如结果里是否包含虚构的订单号、是否包含现实中不存在的商品、是否和用户提供的上下文冲突。如果冲突，就触发兜底策略，比如返回“这个问题我暂时无法确认，建议人工客服介入”。
以 Python 为例，一个最小的实现框架大概长这样：
class CommonSenseGate: def __init__(self, rules, fallback_text): self.rules = rules self.fallback_text = fallback_text def check(self, text, context): for rule, reason in self.rules: if not rule(text, context): return False, reason return True, text def respond(self, text, context): ok, result = self.check(text, context) if not ok: return self.fallback_text.format(reason=result) return result规则本身很简单，可以是一个函数列表：
def require_has_datetime(text, context): has_time_fragment = any(k in text for k in ["上午", "下午", "点", ":"]) has_date_fragment = any(k in text for k in ["今天", "明天", "周", "月", "日"]) return has_time_fragment and has_date_fragment这段代码不复杂，但它起到了一个非常关键的作用：确保基本信息必须由用户显式提供，而不是让模型猜。这就是“常识”落到代码里的样子。
4.3 日志、回滚、人工复核：常识层真正进入生产的最后三块拼图
如果你只是想写一个 demo，上面两段代码就够了。但如果你要把常识判断层放进生产环境，我建议再补三样东西。
第一是日志。每一条被拦截的问题，都要记录“为什么被拦截”“命中了哪条规则”。日志不仅能帮你发现规则是否过于激进，还能为后续补充规则提供数据依据。
第二是人工复核。无论规则写得多完善，都可能出现误伤。用户可能确实想表达一种非常规的请求，比如“今天下午我没有具体时间，你可以帮我推荐一个时间吗？”这种请求在规则引擎里会被拦截，但人不应该被拒之门外。所以要在拦截后给出兜底入口，让人工客服或更高层级的模型介入。
第三是规则版本管理。常识会变化。上班时间、节假日、店休信息、权限范围都会变化。如果你的规则是硬编码在代码里的，那每一次修改都需要发布。建议把规则做成配置，比如 JSON 或 YAML 文件，定期更新，这样常识判断层才不会变成一个新的僵化系统。
4.4 一个分类判断表：哪些场景适合用规则层，哪些适合用模型
不是所有问题都需要常识判断层。我习惯用下面这个表格来做初步决策：
| 场景类型 | 是否适合加规则/逻辑层 | 原因 | 典型示例 |
|---|---|---|---|
| 高风险金融操作 | 是，必须加 | 错误判断代价极高，必须可解释、可审计 | 转账、交易、订单取消 |
| 日程/预约类 | 是，建议加 | 需要处理时间、地点、冲突，规则明确 | 会议室预订、出行安排 |
| 内容生成类 | 否，轻量即可 | 目标是多样性和创造力，规则过多会限制表达 | 文案生成、故事续写 |
| 知识问答类 | 视知识库完整性而定 | 知识库完备时可做一致性校验，否则容易误判 | 政策问答、产品问答 |
| 闲聊陪伴类 | 否，不建议加 | 用户意图开放，规则层会破坏顺畅感 | 情感陪伴、开放式聊天 |
这个表的核心原则是：规则层的价值不在于“显得聪明”，而在于减少不可控的失败。凡是失败代价高或逻辑强约束的，都应该加；凡是自由度高或失败代价低的，可以减少干预。
注意：不要一上来就把批量数、并发数和规则数拉满。先用一条样例确认输入、输出和日志都正常，再逐步扩大覆盖面。
4.5 一个最简单的排查链路
如果你已经加了一层常识判断规则，但效果不理想，我建议按下面的顺序排查：
- 先看现象：是误拦截太多，还是该拦截的没拦住。
- 再看输入：检查请求字段是否完整，上下文是否传到了判断层。
- 再看规则顺序：有些规则应该优先判断，比如“空字符串”应该最先拦截，而不是放在最后。
- 再看兜底文案：兜底文本是否让用户清楚下一步该做什么，而不是简单粗暴地拒绝。
- 最后看日志：统计命中的规则分布，排查是否出现因正则表达式或关键词覆盖不全导致的漏判。
5. 真正的边界：形式化常识为什么不会取代统计学习，也不会全盘退场
5.1 知识获取成本太高，开放世界依然难写
我必须诚实地说，McCarthy 的路线有一个天然短板：知识获取太贵了。
你把一百条常识规则写进去，可能要花好几天；但大模型通过预训练，可能已经隐式地掌握了几万种常见表述方式。要维护一个覆盖真实世界全部常识的知识库，成本几乎无限高。这也是为什么纯符号主义在二十世纪八十年代后期进入低谷，统计学习方法开始占领主流。
这个教训今天依然有效。如果你在做一个小型业务，想用一个完备的本体系统给用户提供全量常识，那大概率会失败。因为维护不完、更新跟不上、覆盖不到长尾场景。这不是逻辑的问题，而是工程成本的问题。
5.2 统计模型擅长模式匹配，逻辑模型擅长一致性保证
所以我的实际立场是：形式化常识和统计学习不是替代关系，而是互补关系。
统计模型的长处，在于从海量数据里捕捉模糊的模式。它能写文案、会翻译、能识别意图，这非常强大。但它的短处也很明确：它无法保证输出和已知事实一致，无法在每一步都给你一个可验证的推理依据。
逻辑模型的长处，恰好相反。它擅长保证一致性、可解释性、可修正性。一旦把规则写对，它就会稳定执行。但它的短处是覆盖范围有限，维护成本高。
聪明的工程就是各取所长。用统计模型做生成和内容理解，用逻辑模型做约束和校验，用人做最终决策。这个组合的稳定性，远高于只用其中之一。
5.3 一个务实的组合策略：统计生成 + 逻辑校验 + 人工兜底
如果你的团队今年要做 AI 应用，我建议把它当成默认架构：
- 第一步，用大模型完成自然语言理解和内容生成。
- 第二步，加一个规则层，负责处理“非黑即白”的强约束问题，比如时间、金额、权限、禁售词、敏感信息。
- 第三步，对规则层无法判断的模糊地带，转人工或转上级模型处理。
这个架构的好处是，它不会把所有希望押在模型的知识边界上。模型可以犯错，但规则层会兜底；规则层会误伤，但人工兜底会修正。这就形成了一条“从不可控到可控，再到可解释”的链路。
McCarthy 如果在现场，看到这个架构，我猜他不会觉得违和。他当年做 Advice Taker，核心目标也不是让机器取代人类，而是让机器拥有一个能不断接收新建议、新知识、新常识的框架。今天我们用规则层约束大模型输出，本质上就是在给智能系统打补丁，让它多懂一点“常识”。
这个补丁并不会让系统变得万无一失。但它会带来一个非常实际的价值：当系统犯错的时候，至少你有一个地方可以查看逻辑链路，知道是规则覆盖不足，还是模型生成跑偏，还是用户输入不完整。这种“可定位、可修正、可复盘”的能力，是纯黑盒的大模型系统给不了的。
[\lim_{x\to\infty} \frac{\text{常识的形式化}}{\text{模型的统计生成}} = \text{一个可解释的角落}]
