阿尔达塔斯奇

作者：袖梨 2026-07-16

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

什么才是好的安全带

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

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

初步真相

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

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

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

哈维·斯佩克特：我不玩概率参数，我玩的是人。

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

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

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

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

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

无所不能的统一数据层

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

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

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

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

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

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

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

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

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

一切都是文件

您曾经手动处理过 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 实例）来响应不同的事件。