阿尔达塔斯奇

几年来我一直在思考如何将大语言模型从聊天面板中解放出来。观察人们的尝试，看看哪些有效（哪些无效），我对正确的方法形成了自己的看法。这是我的想法，以及我最近一直在做的事情。

什么才是好的安全带

• I. 对智能体来说应该是自然直观的。
• 二.一切都应该是透明的，以便智能体能够自我发展或治愈（或事后审计）。
• 三．必须尽可能精简和灵活。
• 四．错误生存、更新生存、内存不会随着时间的推移而损坏或退化。

随着大语言模型智力的不断进步，安全带最终将变得可靠。眼前真正的问题是减少你给机器人施加的认知负荷（以代币衡量）。

初步真相

这些年来我们学到的最重要的事情。

• 尽可能的决定论。大语言模型应该选择要追求的目标，但实现该目标的深思熟虑应该是明确定义的，或者至少是一系列明确定义的步骤。
• 核心提示应该尽可能小，然后大语言模型应该选择在运行时加载到上下文中的技能。
• 当你接近背景限制时，大语言模型开始变得疯狂。

不要玩概率参数，玩机器人

一个好的工具必须利用大语言模型的先验编码知识。编码和系统管理在大语言模型的培训数据中所占比例过高，因此请为其提供一个已经舒适的环境；通过一本小说来争论它最终会浪费代币。同样，宝贵的上下文不应该浪费在文件发现、遍历等事情上——良好的工具使委派变得简单而高效。同时，对于大语言模型来说，harness 应该很轻松，但实际上在后台做了很多事情。其中包括日志记录、健全性检查、故障安全、清理等。

可审核性、日志记录和自我修复

一切都是脆弱的，所有的智能体最终都会失败。 Agent 失败有两种类型：

LLM 级别的故障无法直接修补，但可以通过安全措施减轻此类故障的风险。由于 LLM 的回合制性质，线束级故障可以在运行时恢复，并且应该可以修复。

为了修复缺陷，智能体需要两件事：良好的日志记录和清晰的错误消息。

无所不能的统一数据层

这些要求大部分都是老生常谈的问题。只是措辞从“用户”转移到“智能体”。因此值得问的是：当人们实际编写代码时，我们可以从以前的时代学到什么？

我的假设：Unix / Linux 环境是一个自然的候选者，并且可以通过一些修改变成 Agentic 工具。

我绝不是 Unix 或其任何后代的专家，但在过去的十年里我一直在了解它的历史、设计选择和用法。其中很多都完美地映射了我们的困境；很多都没有。将 U/L 视为一种激励类比，而不是直接比较。

新旧概念的映射以及 Unix 哲学

如果您可能忘记了，或者以前没有见过，这是我们的祖先里奇和汤普森的信条：

1. 编写只做一件事并把它做好的程序。要完成一项新工作，请重新构建，而不是通过添加新的“功能”来使旧程序复杂化。
2. 编写程序以协同工作。期望每个程序的输出都是另一个程序的输入。
3. 编写程序来处理文本流，因为这是一个通用接口。

这些完美地概括了当今安全带的问题：它们过于复杂，试图做很多事情，并且我们的智能体预期采取的轨迹通常是不明确的。这些是同一问题的症状：智能体无法对其自身保持智能体权。如今，在许多情况下，工具会直接加载到上下文中，系统提示会预先充满警告以及开发人员拥有的特定规则和指南（最终会逐渐消失）。

然后我们可以得出我们自己的一套设计安全带的原则：

1. 编写模块化、透明的工具，只做一件事，并且把它做好；确保他们大声失败。
2. 编写协同工作的工具、技能和连接器。技能决定工作流程，工具是执行工作流程的手段，连接器是智能体操作的数据。
3. 文本流是通用接口，语言模型具有主场优势。一切都应该是平面文本文件。

一切都是文件

您曾经手动处理过 JSON 问题吗？构建大量的curl命令来查询端点怎么样？复杂的正则表达式？我没有，因为他们很痛苦。大语言模型可能比您更容易与他们相处，但请放心，他们也更喜欢纯文本。因此，每当处理外部数据源时，您的工具都应该执行任何可能需要的操作，以在其到达您的大语言模型之前对其进行清理。

您需要一个地方来存储所有这些数据。通过将所有内容分类到目录中，您可以为智能体节省大量浪费的令牌。

考虑文件系统层次结构标准 (FHS)

FHS 只是概述了全新的 Linux 安装应该是什么样子。当然，大语言模型是 Linux FS 导航方面的专家，因此战略性地植入我们的外部数据源并路由到 VFS 将使智能体有宾至如归的感觉（例如，您的日志进入 /var，配置文件进入 /etc，智能体工作区位于 /home 等）。另一个好处是，您和智能体都可以通过 grep 、 find 、which 甚至非 GNU 程序（例如 rg 和 fzf ）轻松审核、跟踪和搜索内容。

繁重的工作在于让杂乱无章的外部世界融入到人造 VFS 中。

我一直在使用以下映射。请注意，很多事情都可以直接进行 1:1 转换。

“内核”

现在我们已经确定了文件系统应该是什么样子，让我们考虑智能体将如何与环境交互（或者更确切地说，何时）。始终在线智能体的行业标准 OpenClaw 将事件驱动的消息处理与心跳配对：完整智能体以固定间隔（默认为 30 分钟）打开以检查是否有任何事情需要注意。问题在于，所有不是推送消息的内容（例如文件更改或外部状态）只能在心跳粒度上被注意到。缩短时间间隔，你就会在每张空支票上烧掉一个完整的大语言模型；松开它，智能体就会比世界落后一个小时。

因此，我决定围绕事件总线构建 Ambiance，我错误地将其称为“内核”。它通过文本文件上的光标来监视我们的 FS 的更改，然后相应地调用 LLM（使用一些合并策略来处理高吞吐量）。这样您就可以确保智能体不会错过任何一个通知。此外，您还可以连接不同的“用户”（LLM 实例）来响应不同的事件。

内核承担繁重的工作

真正的内核充当软件和硬件之间的中间层。 Ambiance Kernel 充当大语言模型与外界之间的中间层。内核检查并确保大语言模型所做的一切都是安全的并且没有明显的危害。

“用户”

到目前为止我已经开发了三个默认用户：

1. root ，它处理所有系统级的东西，特别是编码新驱动程序、二进制文件和修复旧驱动程序。
2. pai ，这是一个面向人类的LLM，实际上与外界互动
3. librarian ，它记录了 pai 擅长什么、不擅长什么以及系统当天做了什么。

所有三个都通过事件总线和发送消息二进制文件不断地相互通信。

Ambiance 背后的想法很简单：模型的先验是您拥有的最便宜的资源，因此用模型已知的东西（文件、用户、日志、文档）构建的工具总是会击败它必须学习的工具。这里的其他一切都是为此服务的。

Ambiance 是一项正在进行中的工作，但您今天就可以在whitematterlabs.ai 上尝试一下，或者直接跳到：

PS：这样的项目你感兴趣吗？您自己也在从事这样的项目吗？你应该彻底检查一下递归中心，这是我开始构建这个的地方！