恒美微站 Logo 恒美微站
  • 首页
  • 关于我们
  • 建站服务
  • 主题模板
  • 案例展示
  • 资讯中心
  • 联系我们

常识推理的奠基者:McCarthy情境演算与限定逻辑

  • 首页
  • 资讯中心
  • /
  • 常识推理的奠基者:McCarthy情境演算与限定逻辑

相关资讯

Codex + ChatGPT 实战:安装配置、批量任务与高频报错排查 2026/8/30 5:41:03
基于微信小程序的校园跑腿代办服务平台的设计与实现源码+文档 2026/8/30 5:41:03
Jalapeño:OpenAI重排算力价值链 2026/8/30 5:41:03

最新资讯

喷涂工艺SCADA上位机:Winform实现的生产级exe系统
设计稿转APP实操:理解连接器、MCP与Workbuddy工作流
能量引导跨模态缓存:加速音频驱动视频生成的新思路
技术债不是洪水猛兽:正确举债+科学偿债的企业技术迭代逻辑
边缘到云物联网方案深度解析:DigiX-ON架构、落地实践与避坑指南
DeepSeek接入Codex CLI:终端智能体配置、识图与排错实战

今日推荐

备战数据库管理工程师校招:索引、事务、备份恢复核心考点解析
数字电路时序基石:深入理解建立时间与保持时间
蓝桥杯国赛超声波测距机:从单片机原理到嵌入式系统实战

本周热门

备战数据库管理工程师校招:索引、事务、备份恢复核心考点解析
数字电路时序基石:深入理解建立时间与保持时间
蓝桥杯国赛超声波测距机:从单片机原理到嵌入式系统实战

本月精选

如何用DamaiHelper实现演唱会门票的智能自动化抢购:完整技术解决方案指南
第4篇:59 倍性能差距的索引瓶颈定位——一次教科书级的全表扫描调优
终极歌词批量下载神器:5分钟解决离线音乐库歌词同步难题

常识推理的奠基者:McCarthy情境演算与限定逻辑

发布时间:2026/8/30 5:41:03
常识推理的奠基者:McCarthy情境演算与限定逻辑 这次我们聊一个没有代码仓库、也不吃显卡的研究方向但它决定了今天 AI 领域的很多底层问题——John McCarthy 提出的“用逻辑形式化常识”这一整套思想。大模型能写诗、能写代码但遇到“鸡蛋掉到地上会怎样”这种简单常识问题时仍可能翻车McCarthy 从 20 世纪 50 年代末就盯上了这个问题并且给出了成体系的形式化工具。这里说的 logic是数理逻辑、非单调逻辑的 logic不是电子调试里抓时序波形的 Logic Analyzer先分清概念再往下看。这篇文章会把 McCarthy 的核心贡献整理成一张速览表再把情境演算、限定逻辑这两大工具拆开讲并给出可以在 SWI-Prolog 里直接跑通的示例代码最后讨论这些 70 年前的思考对今天的大模型、Agent 和知识图谱还有没有用。适合三类读者准备系统入门 AI 理论的开发者、做知识工程或符号推理的项目成员、以及想理解“模型为什么会在常识问题上犯错”的大模型应用开发者。1. McCarthy 核心贡献速览贡献要解决的问题对现代 AI 的对应物提出“Artificial Intelligence”术语给新研究领域一个名称明确目标今天的“AI”概念本身Advice Taker 程序设想让程序具备“接受建议、按常识行动”的能力智能体、LLM 插件知识注入情境演算Situation Calculus用逻辑表达动作、状态、变化PDDL 规划、机器人状态机限定逻辑Circumscription形式化“默认情况下……”的非单调推理异常处理、默认规则、策略引擎非单调推理新信息出现后允许撤销旧结论知识库增量更新、流式决策LISP 语言为符号计算和自动推理提供实现工具符号计算、元编程McCarthy 的总思想很清晰一个智能系统必须拥有大量常识知识这些常识知识应该用声明式逻辑语言显式表达推理过程是对逻辑公式的机械演算因此可以被检查、被验证、被增量修改。这个路线后来被称为“符号主义 AI”与现在主流的“连接主义”形成对照两者并不是对立而是互补。2. 为什么“形式化常识”那么难常识和“百科全书”不是一回事。百科全书是事实列表而常识是使用事实的规则物体被松手后会下落、人会因为疼痛而躲避、正常鸟会飞但企鹅不会。McCarthy 认为常识知识本质上是一种“可被逻辑表达、可在推理中使用”的知识但把它形式化异常困难。困难来自几个方面。第一异常与例外无处不在。“鸟会飞”是对的但企鹅、断了翅膀的鸟、被关在笼子里的鸟都不会飞。一个常识规则如果写成严格的全称命题立刻会被反例击穿如果写成概率统计又很难做精确推理。McCarthy 的选择是默认规则加上异常谓词让例外成为一等公民。第二不完全信息是常态。现实世界中我们很少知道所有前提。机器人不知道茶杯是否装满水人也不知道明天是否下雨。逻辑系统必须允许“未明确说明的默认成立”也就是在缺少反证时假定正常情况成立。第三框架问题。这是 McCarthy 与 Hayes 于 1969 年前后在论文中提出的经典难题在一个动作发生时哪些事实保持不变例如机器人把茶杯从 A 桌移动到 B 桌后房间墙壁的颜色肯定不变茶杯中的水温可能不变但“不变”这个事实数量是无限的。你不可能把所有不变量全部显式写入规则。第四常识的规模爆炸。即使是日常生活中的“倒水”这样的动作也涉及物体形状、重心、材质、摩擦力、液体流动、人的意图等一系列知识。要把全部常识都写成逻辑公式会得到一个极其庞大的理论体系。这也正是 McCarthy 提出“细化容忍度”概念的动机理论最好允许在原有基础上逐步增加新细节而不是每加一个事实就要推翻整个系统。3. McCarthy 的方法论声明式知识与逻辑推理McCarthy 很早就区分了两个层面的问题认识论问题epistemological和启发式问题heuristic。认识论问题关注“我们应该用什么语言来描述世界”启发式问题关注“给定描述后如何高效地计算得到结论”。在 McCarthy 看来先要解决认识论问题再谈计算效率。换句话说知识表示语言应该足够表达丰富的问题而不是一开始就为了某一类算法做过度简化。这个观点对今天仍然有启发意义。做知识图谱、做 Agent 状态管理时常见误区是一上来就用向量嵌入把所有事实压缩成低维向量。向量适合做相似度检索却很难做精确的三段论推理。McCarthy 坚持用一阶逻辑作为表示语言是因为逻辑具有明确的语义任何人都能根据公理检查推导是否正确也方便后续加入新规则。Advice Taker 就是这一方法论的代表。McCarthy 在 1959 年前后的论文《Programs with Common Sense》中设想程序内部保存一组用逻辑句子表示的常识知识外部用户可以通过逻辑句子对程序提出建议程序通过逻辑演算自动推导出应该执行的行动。这个程序并不强调它能从数据中学会什么而是强调它能“接受建议并据此推理”。这个设想在逻辑上等价于一个“可被逐步增删知识”的推理引擎可以说是现代知识库系统的雏形。4. 情境演算让逻辑描述动作和变化情境演算Situation Calculus是 McCarthy 和 Hayes 在 1969 年的论文中为“描述动态世界”而发展出来的形式体系。它的核心是把时间演化表达为“情境—动作—新情境”的链式结构。基本概念如下概念英文含义情境situation世界在某个动作序列之后的状态快照动作action把一个情境推进到下一个情境的离散事件流fluent随情境变化而变化的属性或关系结果函数result(a, s)在情境 s 中执行动作 a 后得到的新情境初始情境s0动作序列开始前的世界状态情境演算中最典型的推理是给定初始情境 s0连续执行动作 a1、a2、a3问某个属性在最终情境 result(a3, result(a2, result(a1, s0))) 中是否成立。下面是一个简化到可以运行的教学版本。假设一个机器人和一个杯子机器人一开始在 roomA杯子在 roomB。机器人可以执行 go(roomB) 这个动作动作结束后机器人的位置更新为 roomB。% 极简情境演算教学示例 % 保存为 situation_calculus.pl在 SWI-Prolog 中执行 % 初始情境 s0机器人在 roomA杯子在 roomB at(robot, roomA, s0). at(cup, roomB, s0). % 效果公理在任意情境 S 中执行 go(L) 后机器人出现在 L at(robot, L, result(go(L), S)) :- at(robot, _, S). % 这是初始位置不变量移动机器人后杯子的位置不变 at(cup, L, result(go(_), S)) :- at(cup, L, S).在 SWI-Prolog 中加载这个文件后查询?- at(robot, roomB, result(go(roomB), s0)). true. ?- at(cup, roomB, result(go(roomB), s0)). true.第一个查询表示机器人执行 go(roomB) 后确实到了 roomB第二个查询表示杯子位置没有变化。这个例子虽然很简单但它展示了情境演算的核心思想把“状态变化”变成“关于情境的逻辑推导”而不是写一段命令式程序去更新变量。需要注意的是这个极简版本省略了大量细节它没有处理动作的可执行条件、没有处理多个动作的序列、也没有处理“某些属性会变化、某些不变”的自动判定。真实的情境演算还需要引入动作前提条件、效果公理、框架公理等。对于初学者先把“情境—动作—新情境”的链条理解清楚就够了。5. 限定逻辑与非单调推理对付例外如果说情境演算是 McCarthy 关于“动态世界”的表示工具那限定逻辑就是 McCarthy 关于“默认推断”的表示工具。限定逻辑的目的当系统没有明确证据说明某个对象是异常的时候默认认为它是正常的当新信息出现后如果某对象被证明异常相关结论会被撤销。这种“可撤销结论”的推理在逻辑学中被称为非单调推理。经典一阶逻辑是单调的已知结论在加入新公理后仍然成立绝不会消失。但常识推理明显是非单调的知道“Tweety 是鸟”时你推断它会飞再知道“Tweety 是企鹅”时“会飞”这个结论应该被撤销。若坚持严格的一阶逻辑你必须为每条规则写出所有例外这是不可能完成的。McCarthy 的限定逻辑从模型选择的角度给出了解在满足所有已知公理的所有模型中优先选择“异常集合最小”的模型。也就是说系统默认没有异常除非公理中强制声明某对象异常。这给了“正常情况”一个精确的语义。下面是一个可以用 SWI-Prolog 运行的默认推理示例它能直观展示非单调推理的味道% 非单调推理演示鸟、企鹅与飞行 % 保存为 birds.pl在 SWI-Prolog 中执行 % 默认规则鸟一般会飞除非它被判为异常 flies(X) :- bird(X), \ abnormal(X). % 异常规则企鹅是异常个体 abnormal(X) :- penguin(X). % 事实 bird(tweety). bird(opus). penguin(opus).运行测试?- flies(tweety). true. ?- flies(opus). false. ?- bird(X), abnormal(X). X opus.在这个模型里Tweety 因为没有证据表明它异常所以默认会飞Opus 因为是企鹅被规则标记为 abnormal因此不会飞。如果后续再增加一条“麻雀是鸟且麻雀会飞”系统不需要修改已有规则就能推导出麻雀会飞。需要声明Prolog 的\是否定即失败negation as failure它在表现上接近但不等价于 McCarthy 的限定逻辑。限定逻辑本身是二阶逻辑公式上的极小化操作实际工程中往往用 Answer Set Programming 这类系统来近似实现。Prolog 示例的作用是帮助理解“默认规则 例外标记”的运行机制而不是完整实现 Circumscription。下面再用一段伪代码呈现限定逻辑的“极小化异常集合”思想# 伪代码说明限定逻辑的模型选择方向 # 假设所有满足公理的候选模型已知 models all_models(axioms) chosen min(models, keylambda m: len(m[abnormal]))这段代码的意思是在所有可行模型中挑选 abnormal 集合最小的那个。这就是“没有证据说明异常就认为正常”的模型论版本。6. 对今天的大模型与 Agent 有什么意义现在很多人有一个疑问McCarthy 的时代都过去半个世纪了还谈这些做什么答案在于今天的大模型恰恰在“常识推理”这个环节暴露了系统性问题。大模型本质上是概率式生成器它们训练于海量文本却缺少稳定的显式规则约束。你让模型回答“如果从 100 层楼上往下扔一块石头会发生什么”它能给出视觉化描述但如果你问到需要严格分情况讨论的常识推理比如“一个人开车到商店把车停在门口发现商店关门了他回到车里还是走回家”模型可能因为训练数据中类似故事的分布而给出看似合理、但细节矛盾的回答。问题在于大模型没有一个可验证的“世界模型”它不能保证推理链条每一步都保持一致。McCarthy 路线在这方面提供了补充方案把关键常识写成显式逻辑规则让推理过程可验证。比如机器人系统、智能体系统可以维护一个类似情境演算的状态模型用规则描述动作效果和异常条件。大模型负责把自然语言转换成结构化目标逻辑模块负责做精确状态更新和规划。这种混合架构正是当下神经符号 AINeuro-Symbolic AI的核心思路。对 Agent 工程而言情境演算的启发尤其明显。许多 Agent 框架目前只靠大模型上下文维持状态Token 一长模型就会“忘记”之前的动作结果。更稳的做法是设计一个外部状态数据库用结构化谓词记录位置、物品、目标与已完成动作每次工具调用后都更新状态再由规划模块决定下一步动作。这本质上就是在 Agent 内部建立一套“情境演算”。McCarthy 早年的设计今天变成了工程上的可执行方案。7. 常见误区与争议误解一逻辑 AI 已经失败了。实际不然。自动定理证明器在高风险场景中仍然可靠专家系统在医疗、故障诊断、工业控制等领域长期存在形式化方法被用于芯片验证和安全协议。逻辑 AI 没有统治消费级应用但它从来没有“死掉”只是退到了可靠性和安全性优先的领域。误解二常识数量太大逻辑不可能全部覆盖。这个批评有一定道理但注意 McCarthy 面对的不是“给全人类所有常识写公理”而是“为一个受限系统建立可扩展的知识表示框架”。情境演算不追求覆盖全部世界而是要求当新知识进来时系统能够用统一语言扩充。哪怕是“房间内物体移动”这个小范围常识形式化也能显著提高机器人决策的稳定性和可解释性。误解三机器学习与逻辑推理是替代关系。更合理的判断是互补关系。机器学习擅长从感知数据中发现分布规律的逻辑推理擅长在已知规则上做精确保守的推导。自动驾驶、医疗辅助、金融风控等系统都在尝试两者结合而不是二选一。误解四McCarthy 反对统计方法。这个说法并不准确。McCarthy 更强调整体架构系统要用逻辑语言表达知识但不排斥用统计模块处理底层感知。他批评的是“把所有智能都押在一个黑箱模块上”的做法。今天大模型遇到“幻觉”问题其实正说明需要外部验证模块来纠偏。另外还有一个容易混淆的点AI 语境中的 logic 与电子工程中的 Logic Analyzer 完全不是一回事。逻辑分析仪是抓取数字信号时序的硬件工具而 McCarthy 意义上的逻辑是形式推理的数学语言。不要把两者串台。8. 入门路线与工具建议如果你想把 McCarthy 的思想从“听说过”变成“能上手实验”建议按照下面的顺序推进。8.1 论文阅读顺序第一优先读 McCarthy 1959 年前后的《Programs with Common Sense》。这篇论文很短但已经包含了 Advice Taker、知识表示、常识推理等完整雏形。读完你会明白McCarthy 当时对大模型的不足早有预见。第二优先读 McCarthy 与 Hayes 合作的《Some Philosophical Problems from the Standpoint of Artificial Intelligence》这篇论文系统介绍了情境演算和框架问题是理解“动作变化”形式化的起点。第三优先读《Circumscription—A Form of Non-Monotonic Reasoning》这篇关于限定逻辑的论文相对更技术性适合进一步研究默认推理的数学细节。8.2 工具与实验环境理论内容需要在环境中跑一遍才直观。推荐以下最小实验环境安装 SWI-Prolog把本文第 4 节、第 5 节的代码直接载入并查询结果。安装 Answer Set Programming 求解器 Clingo官方也提供在线版体验非单调推理的现代实现。阅读《Knowledge Representation and Reasoning》中“非单调推理”章节整理默认逻辑和限定逻辑的关系。以 Clingo 为例一个对应“鸟会飞”的 ASP 程序可以写成% birds.lp % 这是一个 Clingo/ASP 示例需要先安装 clingo bird(tweety). bird(opus). penguin(opus). flies(X) :- bird(X), not abnormal(X). abnormal(X) :- penguin(X).在命令行执行clingo birds.lpClingo 会输出符合规则模型的结果运行后可以看到 Opus 被标记为 abnormal、不会飞而 Tweety 正常会飞。这个例子比手写 Prolog 更接近 McCarthy 限定逻辑的“极小模型”思想。8.3 从理论到实践的进阶路径理论示例只能让你理解思想真正落地还需要建立工程习惯。第一先用小规模场景验证。不要一上来就做“全人类常识库”选择某个封闭场景例如“单机器人物料搬运”“智能家居用电器管理”把场景中的实体、属性、动作、异常条件列举出来写成逻辑规则。第二把规则与感知模块连接。现实系统通常用神经网络做目标识别用逻辑模块做决策。可以设计一个三明治结构感知模块输出结构化谓词推理模块根据谓词做状态更新和规划执行模块把规划结果转化为实际动作。这比单纯让大模型端到端输出更可控。第三保留规则的可审查性。逻辑规则最大的优势是“可审查”。上线前请领域专家逐个检查规则找出矛盾或遗漏上线后可以通过日志追踪哪条规则被触发、哪个条件未满足。这是黑箱模型无法提供的供应链级可靠性。9. 总结与下一步McCarthy 这条技术路线真正值得记住的点是常识推理不能只靠模式匹配还需要一个可表达、可检查、可增量扩充的推理骨架。情境演算解决“动作与状态”的表达限定逻辑解决“默认与例外”的表达两者合起来构成了一个非常朴素的常识推理底座。如果你今天要为一个实际系统引入 McCarthy 的思想我建议从“在封闭场景里写一组逻辑规则”开始然后用 Prolog 或 Clingo 验证规则是否符合预期再逐步加入更多动作和异常条件。最先验证的功能应该是“默认规则是否按预期触发”最容易踩的坑则是“规则的异常标记无限膨胀”——一开始就要设计好异常谓词的命名和层级防止知识库变成一团乱麻。这篇内容不会直接教你把系统接到 API 上但它可以帮助你建立一个判断框架什么时候该用逻辑什么时候该用大模型什么时候两者配合。后续可以继续沿着神经符号推理、ASP 规则库设计、以及分布式知识库的方向深入。建议收藏备用。

关于恒美微站

恒美微站专注于为个体商户、工作室提供极简自助建站服务,让每个人都能轻松拥有专业网站。

快速链接

  • 关于我们
  • 建站服务
  • 主题模板
  • 案例展示
  • 资讯中心

服务项目

  • 可视化建站
  • 拖拽编辑
  • 主题定制
  • SEO 优化
  • 网站托管

联系方式

  • 📍 地址:北京市朝阳区建国路 88 号
  • 📞 电话:400-888-8888
  • ✉️ 邮箱:info@hmyw.cn
  • 🕐 时间:周一至周日 9:00-18:00

© 2024 恒美微站 hmyw.cn 版权所有 | 京 ICP 备 12345678 号