# 从 AM 到 LLM：符号 AI 启发式发现机制的演进与工程传承 > 分析 Douglas Lenat 的 Automated Mathematician 源码，探讨 1980 年代符号 AI 的启发式发现机制与当代 LLM 的工程化差异。 ## 元数据 - 路径: /posts/2026/03/30/automated-mathematician-heuristic-discovery/ - 发布时间: 2026-03-30T19:25:44+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在人工智能的历史长河中，Douglas Lenat 于 1970 年代末开发的 Automated Mathematician（AM）是一个里程碑式的存在。这位来自斯坦福人工智能实验室的研究者试图让机器“学会”发现数学概念，其核心思想是通过大量精心设计的启发式规则引导程序生成和修改 Lisp 代码，从而自主“涌现”出数学知识。AM 的源码如今保存在 GitHub 仓库 white-flame/am 中，来自 SAILDART 档案，可追溯至 1977 年左右。运行在 PDP-10（SUMEX）计算机上的 AM 使用 Interlisp 语言编写，整个系统占据约 140k 内存，却实现了当时令人惊叹的自主发现能力。 AM 的架构可以概括为三个核心组件的协同运作：概念网络、启发式规则库和议程驱动的控制流。概念（Concepts）是 AM 的基本数据结构，每个概念本质上是一个简短的 Lisp 程序，用于测试或生成特定的数学对象。例如，一个测试两个列表长度是否相等的程序被解释为“数值相等”的概念；而一个输出长度为两个输入列表长度乘积的程序则代表“乘法”概念。这种将程序直接等同于概念的做法，是 AM 最具开创性也最具争议的设计决策。系统维护着数百个这样的概念，并通过一条总议程（Agenda）来管理待执行的任务。控制结构极其简洁：AM 反复从议程顶部选取任务并执行，然后更新议程的优先级。这种“选择—执行—更新”的循环构成了系统的全部控制逻辑。 启发式规则是 AM 的灵魂，也是其与当代人工智能最根本的区别所在。Lenat 为系统设计了数百条启发式规则，每条规则本质上是一条条件-动作对：当某个条件满足时，系统执行特定的操作。著名的例子包括 Rule 218：“如果两个表达式在结构上相似，则”，以及 Rule 129：“用其他（非常相似的）值替换获得的值”。这些规则的设计灵感来源于真实数学家的问题解决策略，意图让程序模仿人类数学家的思维模式。关键在于，这些启发式并非一成不变——在后续的 Eurisko 系统中，Lenat 进一步实现了让系统自主生成和修改启发式规则的能力，尝试突破固定规则集的限制。 将 AM 与当代大语言模型进行对比，可以清晰地看到两种工程范式的本质差异。AM 属于典型的符号人工智能，其知识表示是显式的、离散的、可解释的：概念是 Lisp 程序，规则是条件-动作对，整个系统的推理过程可以被追溯和检查。而 LLM 则基于连接主义的深度学习架构，其知识以神经网络权重中的分布式表示存储，推理过程是一个高维空间中的数值计算过程，难以直接解释。从工程角度看，AM 的系统行为可以通过调节启发式规则的阈值、修改议程优先级的计算公式来精细控制；而 LLM 的行为控制则依赖于提示工程、RLHF 或者对基础模型进行微调。两种方法在可控性、可解释性和 Scaling 特性上呈现出截然不同的 trade-off。 AM 的工程实践为当代 AI 系统提供了一些值得反思的启示。首先是“显式知识 vs. 隐式知识”的取舍问题：AM 通过人工编码的数百条启发式规则实现了有限的发现能力，但这种方法在扩展到更广阔领域时遭遇了瓶颈；LLM 则通过在海量数据上预训练隐式捕获了广泛的知识，但这种知识的精确控制和调用仍然困难。其次是“领域特异性 vs. 通用性”的权衡：AM 专注于数学概念发现，系统设计紧密结合了数学对象的结构特性；LLM 追求通用智能，但在特定任务上往往需要额外的微调或提示设计。最后是“可控性 vs. 涌现性”的张力：AM 的每一步推理都可以追溯到某条具体的启发式规则，但这种可控性限制了系统发现意料之外新知识的潜力；LLM 展现出的涌现能力令人惊喜，但其行为边界难以精确预测。 尽管 AM 在 1980 年代后期逐渐淡出主流研究视野，其核心思想仍然在多个方向上产生了深远影响。自动程序生成、神经符号系统、基于搜索的 AI 等领域都可以追溯到 Lenat 早期工作的启发。今天，当工程师们尝试在 LLM 基础上构建可靠的 AI 代理时，重新审视 AM 的启发式机制设计或许能提供有价值的工程参照：在追求模型规模的同时，如何保留或重建某种形式的显式推理能力，以实现更可控、更可预测的智能系统。 资料来源：GitHub 仓库 white-flame/am 包含 AM 的原始源码；Wikipedia Automated Mathematician 词条提供了系统的历史背景与技术概述。 ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。