迈向万能约束工具：探索大语言模型的高效管控之道

阿尔达·塔斯吉

[内容] [关于] [联系我]

迈向万能的约束工具

几年来一直在思考如何将大语言模型（LLM）从聊天界面中解放出来。观察人们尝试并了解方法有效性后，形成了解决问题的看法。以下是想法及最近工作内容。

优秀约束工具的特质

1. 对智能体而言应自然直观
2. 一切都应透明化，以便智能体能够自我发展、自我修复（或在事后进行审计）
3. 必须尽可能精简且灵活
4. 具备错误恢复能力、更新兼容性，不会随时间出现内存损坏或性能下降的问题

随着大语言模型智能水平的提升，约束工具最终将变得 “可靠”。当下真正的问题在于，减少施加在聊天机器人上的认知负担（以令牌数衡量）。

基本认知

• 尽可能保证确定性。大语言模型应自主选择要追求的目标，但朝着该目标进行的决策过程应明确界定，或者至少包含一系列明确定义的步骤。
• 核心提示应尽可能简洁，大语言模型应在运行时自主选择要加载到上下文的技能。
• 当接近上下文限制时，大语言模型会开始出现异常。

别碰运气，要掌控模型

一个优秀的约束工具必须充分利用大语言模型的先验编码知识。编码和系统管理在大语言模型的训练数据中占比极高，因此要为它提供一个熟悉的环境；让它适应全新的环境最终会浪费令牌资源。同样，宝贵的上下文不应浪费在文件查找、遍历等操作上——优秀的约束工具应使任务委派变得 “轻松高效”。同时，约束工具对大语言模型而言应感觉轻便，但实际上能在后台完成大量工作，包括日志记录、完整性检查、故障保护、数据清理等。

可审计性、日志记录与自我修复

一切都存在漏洞，所有智能体最终都会出现故障。智能体故障主要分为两类：

• 大语言模型层面
• 约束工具层面

大语言模型层面的故障无法直接修复，但约束工具可以降低此类故障发生的风险。约束工具层面的故障可以恢复，并且由于大语言模型的回合制特性，这些故障 “应该” 能够在运行时修复。为了修复缺陷，智能体需要两样东西：完善的日志记录和清晰的错误信息。

全能的统一数据层

这些需求大多是由来已久的问题，只是表述从针对用户转变为针对智能体。因此值得思考：“我们能从过去人们实际编写代码的经验中学到什么？”

假设：Unix/Linux 环境是一个天然的选择，只需进行一些修改，就能将其转变为智能体约束工具。虽非 Unix 或其衍生系统的专家，但过去十年一直在研究它的历史、设计理念和使用方法。它的很多特性与面临的问题完美契合，但也有一些并不适用。可以将 Unix/Linux 视为一个具有启发性的类比，而非直接对比。

新旧概念映射与 Unix 哲学

先驱里奇和汤普森的信条：

1. 编写专注于单一任务且能出色完成的程序。若要执行新任务，应重新编写程序，而非通过添加新 “功能” 来复杂化旧程序。
2. 编写能够协同工作的程序。要期望每个程序的输出都能成为另一个程序的输入。
3. 编写处理文本流的程序，因为文本流是一种通用接口。

这些信条概括了当前约束工具存在的问题：它们过于复杂，试图承担过多任务，而且期望智能体遵循的路径往往不够明确。这些问题都源于同一个根源：智能体无法自主掌控自身。如今在很多情况下，工具会直接加载到上下文中，系统提示会预先填充开发者设定的警告、特定规则和指南（这些内容会随着回合的推进逐渐失效）。由此可推导出设计约束工具的原则：

1. 编写模块化、透明的工具，使其专注于单一任务并出色完成；确保工具在出现故障时能明确发出提示。
2. 编写能够协同工作的工具、技能和连接器。技能决定工作流程，工具是执行流程的手段，连接器则是智能体操作的数据。
3. 文本流是通用接口，语言模型在这方面具有优势。一切 “应该” 以纯文本文件的形式呈现。

氛围（Ambiance）：对约束工具的理解

一切皆文件

手动处理 JSON 数据、编写复杂的 `curl` 命令查询端点、使用复杂的正则表达式都很麻烦，大语言模型或许更擅长处理这些，但也更喜欢纯文本。因此，在处理外部数据源时，约束工具应在数据到达大语言模型之前进行必要的清理和处理。需要一个地方来存储所有这些数据。通过将所有数据分类存储到不同的目录中，可以为智能体节省大量的令牌资源。

参考文件系统层次结构标准（FHS），FHS 定义了全新安装的 Linux 系统的文件结构。大语言模型擅长在 Linux 文件系统中导航，因此将外部数据源和路由策略合理地整合到虚拟文件系统（VFS）中，能让智能体感觉像在自己的 “家” 里一样（例如，将日志存储在 `/var` 目录下，配置文件存储在 `/etc` 目录下，智能体工作区设置在 `/home` 目录下等）。这样做的另一个好处是，可以通过 `grep`、`find`、`which` 以及非 GNU 程序（如 `rg` 和 `fzf`）轻松地进行审计、跟踪和搜索操作。难点在于如何将杂乱无章的外部世界整合到虚拟文件系统中。采用了以下映射关系，很多内容可以直接进行一对一的映射：

约束工具	Unix 等效项	FHS
智能体	用户	/home/...
外部数据	驱动程序	/sys/
工具	二进制文件	/bin/
日志	日志文件	/var/
自我修复	系统二进制文件	/sbin/ & /recovery
技能	文档	/usr/share/doc

“内核”

明确了文件系统的结构后，思考智能体如何（或者说 “何时”）与环境进行交互。对于始终在线的智能体，行业标准的 OpenClaw 采用事件驱动的消息处理机制，并结合心跳机制：每隔固定时间（默认 30 分钟）进行一次完整的智能体回合，以检查是否有需要处理的事项。问题在于，除了推送消息之外的其他事件，如文件更改或外部状态变化，只能在心跳检查时被发现。如果缩短检查间隔，每次空检查都会消耗大语言模型的一个完整回合；如果延长间隔，智能体可能会滞后于实际情况长达一小时。因此，决定围绕一个误称为 “内核” 的事件总线来构建氛围（Ambiance）。它通过文本文件的游标监视文件系统的变化，并相应地调用大语言模型（同时采用了一些合并策略来处理高吞吐量）。这样可以确保智能体不会错过任何一个通知。此外，还可以将不同的 “用户”（大语言模型实例）配置为响应不同的事件。

内核承担繁重任务

真正的内核是软件和硬件之间的中间层。氛围（Ambiance）的内核则是大语言模型和外部世界之间的中间层。内核会检查并确保大语言模型的所有操作都是安全的，不会造成明显的危害。

“用户”

已开发了三个默认用户：

1. `root`：负责处理所有系统级任务，特别是编写新的驱动程序、二进制文件以及修复旧的程序。
2. `pai`：面向人类的大语言模型，实际与外部世界进行交互。
3. `librarian`：记录 `pai` 的优势和劣势，以及系统每天的运行情况。

这三个用户通过事件总线和 `send-message` 二进制文件不断进行通信。

立即试用

氛围（Ambiance）的理念很简单：模型的先验知识是最廉价的资源，因此基于模型已经熟悉的元素（文件、用户、日志、文档）构建的约束工具，总是优于需要重新教导模型的工具。这里的其他内容都是为了实现这一目标而服务的。氛围（Ambiance）仍在开发中，但现在就可以试用。附言：对这类项目感兴趣吗？自己是否也在从事类似的项目呢？可以了解一下 [递归中心]。

目录

• 优秀约束工具的特质
• 基本认知
• 别碰运气，要掌控模型
• 可审计性、日志记录与自我修复
• 统一数据层
• Unix 哲学
• 一切皆文件
• 无滴答时钟与“心跳”机制
• 内核承担繁重任务
• “用户”
• 立即试用