迈向万能工具：设计直观、透明且精简的LLM控制框架

# arda tasci 来源：https://eardatasci.github.io/c/ambiance/index.html ## 迈向全能操控系统 数年来，我一直在思考如何让大语言模型脱离聊天面板的束缚。观察了各种尝试与成败，我对正确的方法形成了自己的见解。以下是我的想法以及我近期的工作。 ## 一个好的操控系统应具备哪些特质 - I. 对智能体而言应当自然直观。 - II. 一切应当透明，以便智能体能够自我开发或自我修复（或在事后进行审计）。 - III. 必须尽可能精简且灵活。 - IV. 能够承受错误与更新，不会随时间出现内存损坏或性能退化。 > 随着大语言模型智能性的提升，操控系统终将变得*可靠*。真正要解决的是如何减少你的机器人所需承担的认知负荷（以令牌计）。 ## 初步已知事实 多年来我们学到的最重要东西。 - 尽可能做到确定性。大语言模型应选择追求什么目标，但对目标的推演过程应当有明确定义，或者至少是一组明确定义的步骤。 - 核心提示应尽可能小，然后让大语言模型在运行时自行选择要加载到上下文中的技能。 - 当接近上下文限制时，大语言模型会开始出现混乱。 ## 不博弈概率，博弈机器人 哈维·斯佩克特：我不博弈概率，我博弈人心。 一个好的操控系统必须利用大语言模型先验的编码知识。编码和系统管理在大语言模型的训练数据中占比极高，因此给它一个已经熟悉的环境；通过一个新颖的环境来操控它最终只会浪费令牌。同样，宝贵的上下文不应浪费在文件发现、遍历等事情上——好的操控系统让委托变得*简单高效*。同时，操控系统对LLM来说应感觉轻量，但实际上在后台做了很多事情，包括日志记录、完整性检查、故障安全措施、清理等。 ## 可审计性、日志记录与自我修复 万物皆有脆弱之处，所有智能体最终都会失败。智能体失败有两种类型： - 大语言模型层级 - 操控系统层级 大语言模型层级的失败无法直接修补，但可以通过操控系统来降低此类失败的风险。操控系统层级的失败可以恢复，并且由于大语言模型的回合制特性，*应当*能够在运行时修复。 为了修复缺陷，智能体需要两样东西：良好的日志记录和清晰的错误消息。 ## 全能统一数据层 这些需求大多是老问题，只是措辞从“用户”转向了“智能体”。因此值得问一下：*我们能从“前时代”（人们还真正写代码的时候）学到什么？* ### 我的假设：Unix / Linux 环境是一个天然候选，只需稍加修改即可转变为智能体操控系统。 我绝不是Unix或其任何后代的专家，但过去十年我一直在学习它的历史、设计选择和使用方法。其中很多内容完美映射到我们的困境中；也有很多不适用。请将U/L视为一个激励性的比喻，而非直接比较。 ## 将旧概念映射到新概念，以及 Unix 哲学 如果你可能已经忘记或从未见过，以下是我们的先辈 Ritchie 和 Thompson 的信条： > 1. 编写只做一件事并把它做好的程序。要做新工作，重新构建，而不是通过添加新“特性”使旧程序复杂化。 2. 编写能协同工作的程序。预期每个程序的输出是另一个程序的输入。 3. 编写处理文本流的程序，因为那是通用接口。 这些完美地概括了当今操控系统的问题：过于复杂，试图做很多事情，而且我们期望智能体遵循的轨迹往往定义不清。这些都是同一个问题的症状：智能体无法掌握自己的自主权。在今天许多情况下，工具被直接加载到上下文中，系统提示被预先塞满开发者添加的警告、特定规则和指南（这些提示随着回合推移逐渐失效）。 由此，我们可以推导出自己的设计原则： > 1. 编写模块化、透明的工具，只做一件事并做好；确保它们失败时声音响亮。 2. 编写能够协同工作的工具、技能和连接器。技能规定工作流程，工具是执行工作流程的手段，连接器是智能体操作的数据。 3. 文本流是通用接口，语言模型拥有主场优势。一切*都应*是扁平的文本文件。 ## Ambiance：我对操控系统的看法 ## 万物皆文件 你曾经手动处理过 JSON 吗？或者构造复杂的 curl 命令来查询端点？写过复杂的正则表达式？我没有，因为它们太麻烦了。大语言模型可能比你更容易处理它们，但请放心，它们也更喜欢纯文本。因此，在处理外部数据源时，你的操控系统应在数据到达大语言模型之前执行必要的清理操作。 **你需要一个存储所有这些数据的地方**。通过将一切分类到目录中，你可以为你的智能体节省大量浪费的令牌。 ### 考虑文件系统层次结构标准（FHS） FHS 只是概述了一个全新 Linux 安装应有的样子。自然，大语言模型是导航 Linux 文件系统的专家，因此策略性地将我们的外部数据源放置并路由到虚拟文件系统中，会让智能体感到宾至如归（例如，日志放入 /var，配置文件放入 /etc，智能体工作区位于 /home，等等）。另一个好处是，你和智能体都可以通过`grep`、`find`、`which`甚至非 GNU 程序如`rg`和`fzf`轻松地进行审计、跟踪和搜索。 难点在于如何让混乱、拥挤的外部世界适应这个仿 VFS。 我一直在使用以下映射。注意，很多内容确实可以直接一一对应。 操控系统 | Unix 等价物 | FHS --- | --- | --- 智能体 | 用户 | /home/... 外部数据 | 驱动程序 | /sys/ 工具 | 二进制文件 | /bin/ 日志 | 日志 | /var/ 自我修复 | 系统二进制文件 | /sbin/ & /recovery 技能 | 文档 | /usr/share/doc ## “内核” 我们已经确定了文件系统应该是什么样子，现在来思考智能体如何与环境交互（或者更确切地说，*何时*交互）。始终在线的智能体的行业标准 OpenClaw 将事件驱动的消息处理与心跳结合起来：在每个固定间隔（默认为 30 分钟）进行一次完整的智能体回合，以检查是否需要关注任何事情。问题是，除了推送消息以外的一切（如文件变化或外部状态）只有在心跳粒度时才会被注意到。缩短间隔会导致每次空检查都消耗一个完整的 LLM 回合；拉长间隔则导致智能体落后于世界长达一小时。 因此，我决定围绕一个我错误地称为“内核”的事件总线来构建 Ambiance。它通过文本文件的游标监控我们的文件系统变化，然后相应地调用 LLM（并采用一些合并策略来处理高吞吐量）。这样你可以确保智能体不会错过任何一条通知。此外，你还可以将不同的“用户”（LLM 实例）连接到不同的事件响应。 ## 内核承担繁重工作 真正的内核是软件与硬件之间的中间层。Ambiance 内核则是 LLM 与外部世界之间的中间层。内核检查并确保 LLM 所做的每件事都是安全的，且无明显危害。 ## “用户” 我目前开发了三个默认用户： 1. `root`，处理所有系统级事务，特别是编写新的驱动、二进制文件以及修复旧的。 2. `pai`，面向人类的 LLM，实际上与外部世界交互。 3. `librarian`，记录 pai 擅长什么、不擅长什么以及系统当天做了什么。 三者通过事件总线和`send-message`二进制文件不断通信。 ## 试试看 Ambiance 背后的理念很简单：模型的先验知识是你最廉价的资源，因此一个用模型已经知道的东西（文件、用户、日志、文档）构建的操控系统，总是优于一个需要从零教起的系统。这里其他的一切都只是为了服务这一目标。 Ambiance 仍在开发中，但你可以今天就在 whitematterlabs.ai (https://whitematterlabs.ai/) 尝试，或者直接运行： ``` curl -fsSL https://raw.githubusercontent.com/whitematterlabs/ambiance/main/install.sh | sh ``` *附言：这类项目让你感兴趣吗？你自己也在做类似项目吗？那你绝对应该看看递归中心 (https://www.recurse.com/)，我就是在那里开始构建这个项目的！* ---