[Agent 考古] 陈述句革命:告诉AI事实,让它自己想该做什么

Blog

系列名称[Agent 考古] 符号单体时代:第一组织形式的确立与反叛

篇号:第 5 篇 / 共 13 篇 主题分类:历史记述 前置阅读Logic Theorist 1956 阅读时间:约 10 分钟


在所有人都在用代码指挥机器的时候,McCarthy 说:不如告诉机器事实,让它自己想该做什么。

1958 年,符号 AI 的世界正沉浸在 Logic Theorist 带来的震撼中。Newell 和 Simon 用 IPL 语言写出了第一个能证明定理的程序,启发式搜索的范式被确立下来。然而,同在达特茅斯会议上的 McCarthy 却看到了一个更深层的问题:Logic Theorist 的所有启发式都被硬编码在程序里,机器只会执行程序员写好的步骤。如果换一个问题,就得重写一遍代码。

McCarthy 在《Programs with Common Sense》中提出了一个激进的设想:不要用祈使句(命令代码)指挥机器,而要用陈述句(事实与规则)告知机器。机器接收到的不是”做这个、做那个”的指令序列,而是关于世界的描述——”我在桌前”、”车在家里”、”步行可达则可以走去”。机器自己通过演绎推理,从这些陈述句中推出该执行什么动作。

这不是接口形式的小改动,而是一场范式级别的革命。它意味着人与机器的关系从”指挥者-执行者”转变为”告知者-推理者”。意图的生成权从人手中部分转移到了机器手中——人只需要说”我想要什么”,机器自己推导出”该怎么做”。

McCarthy 的设计宣言

“The intelligence, if any, of the advice taker will not be embodied in the immediate deduction routine. This intelligence will be embodied in the procedures which choose the lists of premises to which the immediate deduction routine is to be applied.”

智能不在演绎引擎中,而在选择前提的过程中。

这句话在 65 年后读来仍然振聋发聩。它预言了现代 LLM Agent 体系中一个核心分工:LLM 本身只是”演绎引擎”——它的注意力机制做模式匹配和推理,但不含领域选择的智能;真正的智能体现在 harness 中——system prompt、RAG 检索、skill 选择,这些”选择前提列表的过程”才是 Agent 能力的真正来源。


一个从未实现的设想:Advice Taker 的历史定位

在进入技术细节之前,有一个重要的事实需要先澄清:Advice Taker 在 1958 年提出时从未被实现。McCarthy 在原文中明确将其定义为”a proposed program”(一个设想中的程序),并说”我们希望在编程系统之前先在另一篇论文中形式化这些启发式”。

这篇论文发表于 1959 年的《Mechanisation of Thought Processes》论文集,撰写于 1958 年。论文只有短短 8 页,但它勾勒的蓝图——用陈述句表示知识、通过演绎推出行动、循环执行观察-推理-行动——直到 LLM 时代才真正得到兑现。从这个意义上说,McCarthy 1958 不是一个已经完成的工程成果,而是一份预言书。

理解这一点很重要。Advice Taker 的价值不在于它跑通了多少实验,而在于它提出了一整套关于”智能机器应该如何组织”的概念框架。这些概念在随后的 65 年间被符号 AI 各条路线反复验证和修正,最终在 LLM Agent 体系中以截然不同的技术形态重新出现。


陈述句如何表示世界:表达式与知识编码

McCarthy 设计的第一个问题是:陈述句在机器中应该长什么样?他的答案是列表结构(list structure)——这直接借鉴了 Newell 和 Simon 在 IPL 语言中开发的列表处理技术。用嵌套列表表示逻辑表达式,原子是字符串,变量用特殊标记区分。

在 Python 复现中,这对应着用 tuple 来模拟列表结构。expressions.py 模块定义了最基本的表示原语:

# expressions.py —— 用 Python tuple 模拟 McCarthy 的 list structure
# 原子(term):字符串,如 "I", "desk", "home"
# 变量:以 "?" 开头的字符串,如 "?x", "?y"
# 复合表达式:tuple,如 ("at", "I", "desk") 表示 at(I, desk)

def expr(head: str, *args) -> tuple:
   """构造一个复合表达式"""
   return (head, *args)

def implies(premise, conclusion) -> tuple:
   """构造一个蕴含式 P -> C"""
   return ("implies", premise, conclusion)

def implies_many(premises: list, conclusion) -> tuple:
   """构造多前提蕴含式 P1, P2, ..., Pn -> C"""
   if len(premises) == 0:
       return conclusion
   if len(premises) == 1:
       return ("implies", premises[0], conclusion)
   return ("implies", premises[0], implies_many(premises[1:], conclusion))

# 示例:
expr("at", "I", "desk")          # at(I, desk) —— 我在桌前
expr("want", expr("at", "I", "airport"))  # want(at(I, airport)) —— 我想去机场

这种表示方式看起来朴素,但蕴含着一个关键设计:所有知识都是同一种数据结构。事实、规则、目标、动作效果,全部用嵌套元组表示。这意味着推理引擎不需要区分”这是什么类型的知识”——它只需要处理一种数据格式。

在这个基础上,McCarthy 将 17 条前提编码为陈述句。premises.py 完整复现了原文的机场例程前提:

# premises.py —— 机场例程的 17 条前提(全部为陈述句)

# 事实类前提(信念)
p01 = expr("at", "I", "desk")            # (1) 我在桌前
p02 = expr("at", "desk", "home")         # (2) 桌子在家
p03 = expr("at", "car", "home")          # (3) 车在家里
p11 = expr("walkable", "home")           # (11) 家可步行
p12 = expr("drivable", "county")         # (12) 县内可驾车

# 规则类前提(信念)
p06 = implies_many(
  [expr("at", x, y), expr("at", y, z)],
   expr("at", x, z),
)  # (6) at 的传递性

p09 = implies_many(
  [expr("walkable", x), expr("at", y, x),
    expr("at", z, x), expr("at", "I", y)],
   expr("can", expr("go", y, z, "walking")),
)  # (9) 步行可行性规则

# 目标类前提(愿望)——唯一一条人下发的目标
p14 = expr("want", expr("at", "I", "airport"))

# 行动触发规则(信念→意图)
p17 = implies_many(
  [x, expr("canachult", x, expr("prog", y, z), w), expr("want", w)],
   expr("do", y),
)  # (17) 当前态 + 行动计划 + 愿望 → 执行第一步

17 条前提中,只有第 14 条 want(at(I, airport)) 是”愿望”——人下发的目标。其余 16 条全是”信念”——关于世界是什么样的陈述句。没有任何一条是”执行某动作”的祈使句。祈使句将由机器自己推出来。

这就是陈述句革命的核心:人只描述世界和目标,机器自己发现路径。


演绎引擎如何工作:统一、取式与条件化

有了陈述句表示的知识,接下来的问题是:机器如何从这些前提中推出新结论?McCarthy 的答案简洁得出奇——只有一条推理规则:统一加取式(unification + modus ponens)。

取式推理的逻辑很简单:如果知道 P → C(P 蕴含 C),并且知道 P 成立,那么可以推出 C 成立。统一则是找到变量绑定使两个表达式匹配的过程。两者结合起来就是:找到一条规则 P → C,将 P 与已知事实统一得到变量绑定,代换到 C 中得到新结论。

deduction.py 中的统一算法是整个演绎引擎的核心:

# deduction.py —— 统一算法:McCarthy 所说的
# "substitution for variables with modus ponens" 的组合

def unify(pattern, actual, binding=None):
   """找到变量绑定使 pattern 与 actual 匹配"""
   if binding is None:
       binding = {}

   # 变量与任意项统一:记录绑定
   if is_var(pattern):
       if pattern in binding:
           # 变量已有绑定,递归验证一致性
           return unify(binding[pattern], actual, binding)
       b2 = dict(binding)
       b2[pattern] = actual
       return b2

   if is_var(actual):
       return unify(actual, pattern, binding)

   # 原子与原子统一:必须相等
   if is_atom(pattern) and is_atom(actual):
       return binding if pattern == actual else None

   # 复合表达式统一:逐元素递归
   if isinstance(pattern, tuple) and isinstance(actual, tuple):
       if len(pattern) != len(actual):
           return None
       for p, a in zip(pattern, actual):
           binding = unify(p, a, binding)
           if binding is None:
               return None
       return binding

   return None

统一算法本身是机械的——给定模式和事实,它要么找到一组变量绑定,要么返回失败。这正是 McCarthy 所说的”即时演绎例程”:它不含领域知识,不做启发式选择,只是忠实地执行模式匹配。

但 8 步推演之所以能链式展开,靠的不仅仅是完全匹配。一个更精妙的机制是条件化(conditionalization):规则的 N 个前提中,如果只有 N-1 个能匹配事实,剩下的 1 个作为条件留下,生成残余蕴含式。例如步行规则有 4 个前提,其中 3 个(步行可达性、起点位置、终点位置)匹配了已知事实,第 4 个 at(I, ?y) 作为条件留下,生成:

at(I, desk) → can(go(desk, car, walking))

这个残余蕴含式本身也是知识库中的一等公民——它可以被其他规则的前提模式匹配。规则 (15) 的前提 (x → can(y)) 就是一条蕴含式模式,它能精确匹配这样的条件化结果。没有条件化机制,8 步推演的链条就无法启动。


机场例程:从 17 条陈述句到第一步行动

让我们跟随 McCarthy 的经典例子,看机器如何从 17 条陈述句前提中推出第一步行动。场景很简单:我坐在家里的桌前,想去机场。车也在家里。解决方案是步行到车旁,然后开车去机场。

八步推演的链式展开

整个推导过程分 8 步,每一步都只做一件事,最终在第 8 步触发行动。

步骤 1-2:条件化生成行动可行性条件式。 规则 (9)(步行)和规则 (10)(驾车)分别做条件化,匹配已知的地理事实,留下”我在哪里”作为条件。步骤 1 推出 at(I, desk) → can(go(desk, car, walking)),步骤 2 推出 at(I, car) → can(go(home, airport, driving))

步骤 3-4:动作效果实例化。 规则 (13) 描述了 go 动作的效果——执行后到达目的地。分别对步行和驾车做实例化,得到 did(go(desk, car, walking)) → at(I, car)did(go(home, airport, driving)) → at(I, airport)

步骤 5-6:用 canachult 链接条件与效果。 规则 (15) 是一个二阶规则——它的前提本身就是蕴含式。它将步骤 1 的”可行性条件式”和步骤 3 的”动作效果式”拼接起来,得到 canachult(at(I, desk), go(desk, car, walking), at(I, car))——意思是”在我在桌前的条件下,步行去车旁这个动作最终能让我到达车旁”。步骤 6 同理得到驾车段的 canachult。

步骤 7:动作复合。 规则 (16) 将两段 canachult 串联成一个行动计划:canachult(at(I, desk), prog(go(desk, car, walking), go(home, airport, driving)), at(I, airport))。步行和驾车被组合成一个程序序列。

步骤 8:愿望触发行动。 规则 (17) 是最终的行动触发器。它汇合三个要素:当前状态 at(I, desk)(前提 1)、行动计划 canachult(步骤 7)、愿望 want(at(I, airport))(前提 14)。三者匹配后,推出祈使句 do(go(desk, car, walking))——机器自己决定第一步应该走到车旁。

Python 复现实验完整验证了这 8 步推导。agent.py 中的 AdviceTaker 类按序执行每一步,最终输出与 McCarthy 原文完全一致的结果。

步骤 8: do(go(desk, car, walking))  —— 祈使句!行动触发!
  规则: 规则 (17):x=at(I,desk), canachult=步骤7, want=前提(14)
  前提: at(I, desk) (1), 步骤 7, want(at(I, airport)) (14)
  结论: do(go(desk, car, walking))

17 条全部是陈述句的前提,机器自行推出了祈使句。这验证了 McCarthy 的核心论点——陈述句告知足以驱动行动。

三个关键技术机制

8 步推演之所以成立,依赖三个环环相扣的技术机制。

条件化是启动器。它让规则不必匹配全部前提就能产出有用的中间结果——不是”匹配全部前提得到地面结论”,而是”匹配部分前提得到条件结论”。没有条件化,规则 (9) 和 (10) 都会因为缺少 at(I, ?y) 这个前提而完全沉默。

蕴含式作为一等事实是连接器。规则 (15) 的前提 (x → can(y)) 是蕴含式模式,它匹配的不是地面事实,而是步骤 1 生成的条件式。这意味着推出的结论可以反过来成为更高阶规则的输入,推理链条因此得以逐层上升。

愿望触发行动是出口。愿望 want(at(I, airport)) 本身不是祈使句——它是一个陈述句,描述”我想要什么”。祈使句 do(go(desk, car, walking)) 是机器通过规则 (17) 自己推出来的。人不给行动指令,只给目标描述。


第一次暴击:Bar-Hillel 的当头棒喝

McCarthy 的论文在研讨会上宣读后,立刻遭到了哲学家、语言学家 Bar-Hillel 的尖锐批评。这场交锋不是学术礼仪上的客套,而是直指核心的正面冲撞。Bar-Hillel 的两条反对意见,在 65 年后的今天读来仍然锋利。

at 的传递性不成立

Bar-Hillel 的第一个批评很具体:如果 at 表示”在……的紧邻空间附近”,那么传递性不成立。否则沿着 at(I, desk) → at(desk, home) → at(home, county) → at(county, Earth) 一路传下去,一切都在一切的紧邻附近——这显然荒谬。

McCarthy 的回答坦诚而重要:

“‘at’ merely was intended to serve as a convenient mnemonic for the relation between a place and a sub-place. … I was not proposing a practical problem for the program to solve but rather an example intended to allow us to think about the kinds of reasoning involved.”

at 只是一个方便的助记符,代表”地点与子地点”的关系,而非日常语言中的”紧邻附近”。McCarthy 承认他举的不是实际问题,而是一个让我们思考推理类型的例子。

这一批评触及了形式系统与自然语言之间的永恒张力。形式系统要求谓词有精确的定义边界,而自然语言的谓词充满了模糊性和语境依赖。LLM 通过统计分布隐式处理这种模糊性,是优势也是代价——精确性和可审计性让位于可用性和泛化能力。

前提选择比演绎难 10^10 个数量级

Bar-Hillel 的第二个批评要致命得多。他说:

“I do not think there could possibly exist a programme which would, given any problem, divide all facts in the universe into those which are and those which are not relevant for that problem. Developing such a programme seems to me by 10^10 orders of magnitude more difficult than, say, the Newell-Simon problem of developing a heuristic for deduction in the propositional calculus.”

翻译成今天的语言就是:把宇宙中所有事实分成”与当前问题相关”和”不相关”的程序,比 Newell-Simon 的命题演算演绎启发式难 10^10 个数量级。演绎本身是容易的,难的是从无限的知识中选出当前需要用的那几条前提

这正是现代 Agent 面临的核心困境——上下文窗口选择问题。LLM 通过注意力机制做软选择,RAG 通过向量检索做硬选择,harness 通过 skill 选择做人工选择。但 Bar-Hillel 的质疑依然有效:谁能保证选出的恰好是相关的?遗漏了关键前提会失败,混入了无关前提会干扰。组合爆炸不是工程失误,而是形式系统在开放世界中的本质困难。

McCarthy 的回答承认了这一困难,但坚持”概念层面的困难在当前复杂度就已出现,解决它们将使我们能轻松增加复杂度”。这一赌注在 LLM 时代得到了部分验证——LLM 的统计能力确实让”前提选择”变得可行,虽然不完美。


复现实验中的组合爆炸:Bar-Hillel 预言的精确验证

在 Python 复现实验中,我们三次尝试构建自动演绎引擎,前两次均因组合爆炸而失败。这不是代码写得不好——而是 Bar-Hillel 批评的精确验证。在只有 17 条前提的玩具系统中,自动演绎就已经挂死了。

三次尝试的爆炸轨迹

尝试 1:完全部分匹配。 我们最初的设想是:对每条规则的 N 个前提,尝试匹配任意子集(包括跳过任意组合),看能推出什么。规则 (9) 有 4 个前提、知识库有 15 条事实。部分匹配意味着对 4 个前提中的每一个,可以选择”匹配某个事实”或”跳过”。仅这一条规则就产生约 2^4 × 15^4 ≈ 810,000 种组合。15 条规则一起跑,程序直接挂死。

尝试 2:受控部分匹配。 我们收紧了约束:只允许”匹配 N-1 个前提、跳过 1 个”(恰好留 1 个条件)。但规则 (10) 有 5 个前提、知识库膨胀到 22 条事实。对 5 个位置中的每个做跳过,其余 4 个各尝试 22 条事实:5 × 22^4 ≈ 2,325,680 种组合。程序仍然挂死。

尝试 3:条件化(最终成功方案)。 我们改变了思路:先用完全匹配生成地面结论,再对每个已成功的匹配做条件化(对每个前提 i 生成 premise_i → conclusion)。复杂度从”尝试所有可能的部分匹配”降为”对已完成的匹配做 N 次条件化”。规则 (9) 的完全匹配约 15^4 ≈ 50,625 次尝试,成功后条件化只需再做 4 次。整个 8 步推导顺利完成。

下面这张图直观展示了三次尝试的爆炸规模对比:

深层教训:演绎与前提选择必须分离

三次尝试形成了一个完整的论证链。

当演绎引擎试图同时做前提选择时(尝试 1-2),即使在仅 17 条前提的玩具系统中也会组合爆炸。这直接验证了 Bar-Hillel 的断言——前提选择的难度是组合爆炸级别的。

解决方案是把演绎和前提选择分离(尝试 3):演绎引擎只对给定的前提列表做完全匹配,前提选择由外部过程完成。在我们的复现中,这个外部过程就是 8 步受控推导的编排逻辑——人工决定每一步用哪条规则、匹配哪些事实。

这恰好回到了 McCarthy 原文的设计宣言——智能不在演绎引擎中,而在选择前提的过程中。演绎引擎不做前提选择,它只是忠实执行匹配的机械装置。真正的智能,在于谁来决定”当前应该用哪些前提”。


与 Logic Theorist 的对照:从启发式固化到陈述句告知

Advice Taker 与 Logic Theorist 之间的关系不是简单的先后继承,而是同一范式内部的一次深刻转向。McCarthy 在原文中直接引用了 Newell-Simon 1957 的列表结构工作——在技术底层,Advice Taker 继承了 Logic Theorist 的基础设施。但在更高的设计层面,Advice Taker 是对 Logic Theorist 范式的批评与改良。

维度Logic Theorist (1956)Advice Taker (1958)转向的本质
知识载体启发式固化在 IPL 代码中知识编码为陈述句(数据)启发式从代码变为数据
推理方法四种异质方法轮流尝试 + 手段-目的分析单一规则:统一 + 取式从多策略启发式到单一演绎机制
智能位置智能在推理程序中(启发式的设计)智能在前提选择中(选哪些前提交给演绎引擎)智能从引擎转移到编排
行动触发目标驱动的逆向搜索(证明定理)愿望触发的正向演绎(推出动作)从定理证明到行动生成
人机接口程序员写问题规格 + 证明过程人告知事实 + 目标,机器推出行动从命令式到陈述式

两者最根本的差异在于启发式的载体。Logic Theorist 的启发式被写死在程序里——替换法、分离法、前向链、逆向链,每一种都是一段精心编写的代码。换一个问题领域,就要重写启发式。

McCarthy 的批评正是从这里切入:如果启发式本身也能用陈述句描述呢?那样机器就可以像处理其他知识一样处理启发式——选择、组合、甚至学习新的启发式。这就是为什么 Advice Taker 的演绎引擎如此简单(只有统一+取式一条规则),而把所有的”智能”都放在了”选择前提列表的过程”中。

从这个角度看,Advice Taker 不是 Logic Theorist 的替代者,而是它的继承者——它继承了符号演绎的内核,但将启发式的载体从代码转移到了数据。


祈使句指挥与陈述句告知的范式对照

两种范式的差异可以用下面这张流程图直观展示。左侧是传统的祈使句指挥模式——人写代码,机器逐条执行。右侧是 McCarthy 提出的陈述句告知模式——人提供事实和目标,机器自己推理出行动。

Advice Taker 的系统架构可以拆解为三个核心部件:知识库存储所有陈述句事实与规则,演绎引擎负责机械的统一和取式推理,前提选择器决定当前应该选取哪些前提交给演绎引擎。

McCarthy 的核心洞见在于:中间那个”前提选择器”才是智能的真正位置。演绎引擎只是忠实的执行者——它越机械、越透明越好。真正决定系统能力的,是选择哪些前提、按什么顺序提交给演绎引擎的那个过程。


BDI 坐标对照:从 17 条前提到千亿参数

如果用 BDI(信念-愿望-意图)坐标来衡量,McCarthy 1958 与现代 LLM Agent 在结构上是同构的,但在实现方式上已经发生了天翻地覆的变化。

更详细的对照可以用下表呈现:

BDI 要素McCarthy 1958现代 LLM Agent变化本质
愿望 (Desire)want(at(I, airport))——一条陈述句用户输入的 prompt / system prompt 中的任务描述形态从形式语言变为自然语言,但本质不变:人下发的”想要什么”
信念 (Belief)16 条陈述句前提(事实+规则),全部人手工编写多源混合体系(见下表)从单一来源变为多源融合
意图 (Intent)机器推出的祈使句 do(go(desk,car,walking))LLM 生成的 tool call / function call生成机制从逻辑演绎变为统计推理

现代 Agent 的信念来源已经从单一的人工编写演化为复杂的多源体系:

信念来源对应 McCarthy 1958 的什么在 Agent 中的角色
LLM 训练参数McCarthy 设想中”机器应有的人类级常识”等效于属性表中预存的通用知识,但规模从 17 条变为千亿参数
System PromptMcCarthy 的”standing orders list”——常设规则表harness 在启动时注入,提供行为框架
用户命令want(at(I, airport))——愿望每次对话由用户下发,提供具体目标
RAG / 用户上传文件通过陈述句告知的直接注入检索后注入上下文窗口,等效于追加新事实
Skill 描述属性表——按抽象层级组织的规则harness 根据 task 选择并注入,等效于选取相关规则

信念的绝对数量在参数中(训练时内化),但能否激活取决于 system prompt + 用户命令 + RAG + skill 描述。这正好对应 McCarthy 的设计:智能不在演绎引擎中,而在选择前提的过程中。在现代 Agent 中,”即时演绎例程”对应 LLM 的注意力机制,”选择前提的过程”对应 harness 的 prompt 工程 + skill 选择 + RAG 检索,”智能体现在前提选择中”对应智能体现在 harness 设计中,不在 LLM 权重本身。


陈述句革命的遗产

McCarthy 1958 不是现代 Agent 的技术前身——从 Advice Taker 到 LLM Agent 之间没有连续的工程传承。但它是概念上的最早蓝图。陈述句告知对应 System Prompt,演绎并服从例程对应 ReAct 循环,属性表层级上溯对应 Skill 选择与 RAG 检索,want(...) 对应用户 prompt,do(...) 对应 Tool call。

信念来源的复杂化是现代体系与 McCarthy 设想的主要差异。McCarthy 的信念来源单一(人手工编写 17 条),现代 Agent 的信念来源多元(参数 + prompt + RAG + skill + 用户输入)。但结构是同构的:训练时预存通用知识,运行时选择激活相关子集。

Advice Taker 真正的遗产不是某个具体的算法或架构,而是一个根本性的问题意识——人与机器的关系应该是告知与推理的关系,而非指挥与执行的关系。这个命题在 1958 年是一个遥远的设想,在符号 AI 时代经历了工程化的成功与失败,在 LLM 时代以全新的技术形态重新成为现实。

Bar-Hillel 的批评也同样穿越了时间。前提选择的困难没有被解决,只是被统计近似和人工编排暂时绕过了。组合爆炸不是工程问题,而是形式系统在开放世界中的本质困难——这个困难从 McCarthy 的 17 条前提,到专家系统的 600 条规则,再到今天的千亿参数模型,始终存在,只是换了面孔。


系列文章

Agent 考古 符号单体时代 系列文章关键词
导读:符号单体时代:第一组织形式的确立与反叛
Logic Theorist:符号搜索的第一台证明机器手段-目的分析、状态空间搜索、定理证明
McCarthy Advice Taker:陈述句革命的最早蓝图陈述句告知、推理-行动闭环、属性表装配
STRIPS:状态空间规划的成熟与框架问题算子三元组、世界模型增量、帧问题解法
ELIZA:最小智能体的基线与错觉正则模式匹配、聊天机器人、智能判定陷阱
MYCIN:规则范式的顶峰与边界置信度推理、专家系统、规则脆性
导读:三条反叛伏线汇论:语言接口·社会涌现·具身学习
Minsky 心智社会:单体结构的内部否定单动因谬误、机构协作、K 线记忆、审查器
Brooks 包容架构:感知-行动耦合的工程反叛分层包容、抑制/禁止仲裁、无中央模型
Brooks 无表征智能:物理接地假设的哲学宣言无表征智能、四关键概念、学习四分类
回顾:Bar-Hillel 式批评:意义、翻译与框架问题翻译全自动悖论、意义消解、框架问题跨代回响
终章:自知、自觉、自止——终章定论历史辩证法、组织演化层积观、回到当下

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注