知识编译最佳工程实践

Tue, 03 Nov 2026 00:00:00 +0000

前阵子给工作助理 Muse 算账的时候，我发现一个很尴尬的数字：它每天写一篇工作日记，最早的做法是让模型带着工具自己去翻素材，一次要烧掉约 83 万 token，因为同一份上下文被来回重发了 9 次左右。改成「代码先把素材采齐、模型只调用一次」之后，降到约 6 万 token，耗时几乎不变。

省钱只是表面。更让我在意的是，第一种做法里模型每次都在 重新理解同一批原始消息：谁是谁、哪句话是承诺、哪件事已经关掉了。理解了一遍又扔掉，下次再来一遍，而且每次理解的结果还不完全一样。

这件事让我对知识编译（Knowledge Compilation）形成了一个明确的判断：

目前实现知识编译最合适的工程范式，是 Harness Engineering + Models。模型负责理解和推理，Harness 负责把理解和推理变成一个可靠、可持续运行、可评估、可迭代的工程系统。

这个边界很重要。只有模型，你得到的是一次次聪明但不可复现的理解；只有 Harness，你得到的是一套规则写死、碰到自然语言就失效的 ETL。两者分开各管一摊，知识编译才能成为一个工程系统。

我在从程序编译器到企业上下文编译器里讲了「企业上下文编译器」是什么：词法分析、符号表、IR、链接、增量编译怎么一一对上。这篇不重复那个类比，回答的是下一个问题：用什么工程范式把它造出来，以及怎样把它抽象成一套通用的知识编译架构。

Ai-Ready-Data on All about Raspberry Pi