一个可以做任何事情的马具 我思考了几年的问题是如何将大型语言模型（LLMs）从聊天窗格中解放出来。观察人们尝试过的各种方法，看到哪些有效（哪些无效），我形成了自己对正确方法的看法。这是我的想法，以及我最近在努力实现的内容。 什么是良好的马具 I. 对代理来说应该是自然直观的。 II. 一切都应该是透明的，以便代理能够自我发展或修复（或进行事后审核）。 III. 必须尽可能精简且灵活。 IV. 错误生存、更新生存，没有内存损坏或随时间退化。 随着大型语言模型智能的不断提升，马具最终会变得可靠。真正的问题是减少你给机器人施加的认知负担（以标记数来衡量）。 初步真理 我们多年来学到的最重要的事情。 尽可能保持确定性。 LLM 应该选择追求什么目标，但朝着这个目标的深思熟虑应该是明确的或至少是一系列明确的步骤。 核心提示应该尽可能小，然后 LLM 应该在运行时选择加载哪些技能。 LLM 在接近上下文限制时开始变得疯狂。 不要跟运气玩，跟机器人玩 良好的马具必须利用 LLM 的先验编码知识。 编码和系统管理在 LLM 的训练数据中占据了较大比例，因此给它一个它已经熟悉的环境；通过新的环境来调整它最终会浪费标记。同样，珍贵的上下文不应该浪费在文件发现、遍历等事情上——良好的马具使委托变得简单高效。 同时，一个马具应该让 LLM 感觉轻便，但实际上在后台做很多事情。这些事情包括日志记录、有效性检查、安全机制、数据净化等。 可审计性、日志记录和自我修复 一切都是脆弱的，所有代理最终都会失败。 代理的故障有两种类型： LLM 级别的马具 级别的故障 LLM 级别的故障无法直接修补，但可以通过马具来降低此类故障的风险。 马具级别的故障可以恢复，并应当因 LLM 的轮换性质而在运行时可修复。 为了解决缺陷，代理需要两样东西：良好的日志记录和清晰的错误信息。 一个可以做到这一切的统一数据层 大多数这些要求是古老的问题；只有措辞从用户变成了代理。因此，值得问问：我们能从过去的时代中学到什么，当人们真的在编写代码时？ 我的假设是：Unix/Linux环境是一个天然候选者，可以通过一些修改转变为一个具有代理特征的马具。 我并不是什么 Unix 或其衍生物的专家，但我在过去十年里学习了它的历史、设计选择和使用情况。 其中许多内容与我们的困境美好地映射；而且其中许多内容并不然。 将旧的概念映射到新的概念上，及 Unix 哲学 如果你忘记了，或者之前没有看到过，这里是我们祖先 Ritchie 和 Thompson 的信条： 编写做一件事并且做好它的程序。 要做一项新工作，重新构建而不是通过添加新“特性”来复杂化旧程序。 编写可以协同工作的程序。 期望每个程序的输出是另一个程序的输入。 编写处理文本流的程序，因为那是一个通用接口。 这些完美地概括了今天马具的问题：它们过于复杂，试图做很多事情，而我们期望代理采取的轨迹常常是不明确的。这些都是同一问题的症状：代理无法自己掌控自身。在今天的许多情况下，工具直接加载到上下文中，系统提示预先填充了开发人员的警告和具体规则及指南（这些最终会逐渐消失）。 我们可以由此衍生出我们自己的设计马具原则： 编写模块化、透明的工具，做一件事并做好它；确保它们响亮地失败。 编写可以协同工作的工具、技能和连接器。 技能决定工作流程，工具是执行它们的手段，连接器是代理操纵的数据。 文本流是一个通用接口，语言模型拥有主场优势。 一切都应该是一个简单的文本文件。 气氛：我对马具的看法 一切都是文件 你是否曾经手动处理过 JSON？那构建复杂的 curl 命令来查询一个端点呢？复杂的正则表达式呢？我没有，因为这太麻烦了。一种 LLM 处理这些问题可能比你容易，但可以放心的是，它们也更喜欢纯文本。因此，在处理外部数据源时，你的马具应该执行可能必要的任何操作以进行清理。