文章摘要
作者探讨了如何将大语言模型从聊天界面中解放出来，提出构建高效、透明、灵活的“工具架”。核心原则包括：尽可能确定化、核心提示词最小化、避免接近上下文限制，并强调减少对模型的认知负荷。
文章总结
好的，这是根据您的要求，对原文进行的中文重述：
标题：迈向一个“万能”的智能体框架
作者多年来一直在思考如何将大型语言模型（LLM）从聊天界面中解放出来。通过观察各种尝试，他形成了自己的观点，并分享了近期的工作成果。
一个好的智能体框架应具备以下特质：
- 对智能体而言，操作应自然直观。
- 所有过程透明，便于智能体自我优化、修复或事后审查。
- 尽可能精简且灵活。
- 能应对错误和更新，且不会随时间推移出现记忆损坏或性能下降。
作者认为，随着LLM智能的提升，框架最终会变得可靠。当前的核心问题在于如何降低智能体的“认知负荷”（以Token衡量）。
一些基本事实：
- 应尽可能追求确定性。LLM可以决定追求什么目标，但实现该目标的步骤应清晰明确。
- 核心提示词应尽可能简短，让LLM在运行时自行选择加载哪些技能。
- LLM在接近上下文限制时，表现会变得不稳定。
不要赌概率，要“玩转”智能体
一个好的框架必须充分利用LLM在编程和系统管理方面的先验知识，因为这些内容在训练数据中占比很高。应给予LLM一个它熟悉的环境，而不是浪费Token去适应一个全新的环境。同样，宝贵的上下文不应浪费在文件发现、遍历等琐事上。好的框架能让“委派任务”变得简单高效。同时，框架对LLM而言应感觉轻量，但在后台实际完成大量工作，如日志记录、健全性检查、故障安全防护和数据清理。
可审计性、日志记录与自我修复
所有系统都有弱点，智能体最终都会失败。失败分为LLM层面和框架层面。LLM层面的失败无法直接修补，但可通过框架降低风险。框架层面的失败可以恢复，并且由于LLM的回合制特性，理论上可以在运行时修复。要修复缺陷，智能体需要两样东西：完善的日志记录和清晰的错误信息。
一个统一的数据层
作者认为，许多需求是古老问题的翻版，只是主体从“用户”变成了“智能体”。因此，值得从过去人们真正编写代码的时代汲取经验。
作者的假设： Unix/Linux环境是一个天然的候选，只需稍加修改即可转变为智能体框架。作者并非Unix专家，但过去十年对其历史、设计和用法有所研究。他认为，Unix的许多理念能很好地映射到当前的问题上，但并非全部。应将其视为一个启发性的类比，而非直接比较。
从旧概念到新概念，以及Unix哲学
作者引用Unix的创造者Ritchie和Thompson的信条： 1. 程序只做一件事，并把它做好。 2. 程序要能协同工作，一个程序的输出是另一个程序的输入。 3. 程序应处理文本流，因为这是通用接口。
作者认为，这完美地概括了当前框架的问题：过于复杂，试图做太多事，且智能体的行动路径常常定义不清。其根本原因在于，智能体无法掌握自身的“主动权”。许多情况下，工具被直接加载到上下文中，系统提示词被开发者预设的规则和指南塞满，而这些规则会随着回合更迭而逐渐失效。
由此，作者推导出设计框架的原则： 1. 编写模块化、透明的工具，只做一件事并做好，且确保失败时能发出明确信号。 2. 编写能协同工作的工具、技能和连接器。技能定义工作流程，工具是执行手段，连接器是智能体操作的数据。 3. 文本流是通用接口，语言模型对此有天然优势。一切事物都应表现为纯文本文件。
Ambiance：作者的框架实践
一切皆文件
作者认为，无论是手动处理JSON、构建复杂的curl命令还是编写复杂的正则表达式，对LLM和人类来说都是麻烦的。LLM虽然可能比人类更擅长，但它们同样偏爱纯文本。因此，在处理外部数据源时，框架应在数据到达LLM之前进行必要的清理和转换。
需要一个地方来存储所有数据。通过将数据分类到不同目录，可以为智能体节省大量Token。
参考文件系统层次结构标准（FHS）
FHS定义了Linux安装的标准目录结构。LLM非常熟悉Linux文件系统，因此将外部数据源战略性地放置并路由到虚拟文件系统（VFS）中，能让智能体感到“宾至如归”。例如，日志放入/var，配置文件放入/etc，智能体工作区放在/home。这样做的好处是，人类和智能体都可以通过grep、find等工具轻松审计、追踪和搜索。
作者使用了以下映射关系（部分是一一对应的）：
| 框架组件 | Unix 对应物 | FHS 位置 | | :--- | :--- | :--- | | 智能体 | 用户 | /home/... | | 外部数据 | 驱动程序 | /sys/ | | 工具 | 二进制文件 | /bin/ | | 日志 | 日志 | /var/ | | 自我修复 | 系统二进制文件 | /sbin/ & /recovery | | 技能 | 文档 | /usr/share/doc |
“内核”
在定义了文件系统后，需要考虑智能体如何与环境交互。行业标准方案（如OpenClaw）采用事件驱动消息处理与心跳机制（固定间隔检查）。其问题在于，非推送消息（如文件变更）只能在心跳周期内被注意到。缩短间隔会浪费LLM的回合，延长间隔则会导致智能体反应滞后。
因此，作者围绕一个事件总线（他称之为“内核”）构建了Ambiance。该“内核”通过文本文件上的游标监控文件系统变化，并据此调用LLM（采用一些合并策略处理高吞吐量）。这确保了智能体不会错过任何通知。此外，还可以将不同的“用户”（LLM实例）连接到不同的事件上。
“内核”承担繁重工作
真正的内核是软件和硬件之间的中间层。Ambiance的“内核”则是LLM与外部世界之间的中间层，负责检查并确保LLM的所有操作都是安全且无害的。
“用户”
作者目前开发了三个默认“用户”：
1. root：处理所有系统级事务，特别是编写新的驱动、二进制文件和修复旧的。
2. pai：面向人类的LLM，负责与外部世界交互。
3. librarian：记录pai擅长和不擅长的事情，以及系统每天的工作情况。
这三个“用户”通过事件总线和send-message二进制文件持续通信。
尝试使用
Ambiance的核心思想很简单：模型已有的先验知识是最廉价的资源。因此，一个由模型已经熟悉的概念（如文件、用户、日志、文档）构建的框架，总是优于一个需要从头教给它的框架。其他所有设计都服务于这一目标。
Ambiance仍在开发中，但可以尝试使用。
评论总结
根据评论内容，总结主要观点如下：
1. 对“通用型Harness”的质疑与支持 - 支持者认为Unix哲学（简洁、透明、可审计）是构建Harness的正确方向（评论11："Lean, transparent, and auditability-first is exactly the direction harness' should continue in"）。 - 质疑者指出“能做任何事的Harness”过于空泛，实际效果有限（评论12："This post is chock-full of soft ideas... doesn't achieve a concrete goal"）。
2. 领域特定Harness vs 通用Harness - 多数评论倾向领域特定方案更有效（评论8："domain specific harnesses are already surpassing generic harnesses"）。 - 软件开发被视为一个独立领域，需要定制化Harness（评论8："software development is its own domain"）。
3. 对Unix哲学映射的认可与保留 - 认可将Agent概念映射到Unix原语（评论2："I really like this idea and the way you mapped the concepts to unix primitives"）。 - 但对具体实现（如FHS文件系统）持保留态度（评论10："I get off the train at adopting the FHS, which is an ancient relic"）。
4. 对“文件”作为LLM交互隐喻的批评 - 认为文件系统抽象不适合LLM（评论13："file is a good metaphor for LLM... Files have seek and byte streams, which is just an unneeded abstraction"）。 - 建议使用向量数据库或键值存储替代（评论13："Why force the LLM to use files over vector database or key-value stores"）。
5. 对Harness必要性的肯定 - 强调Harness对控制LLM行为的关键作用（评论8："Running Claude without an engineering harness is like driving a car without brakes"）。 - 但存在对过度依赖Harness的调侃（评论9："Just one more harness bro... one more harness and we will have solved AGI"）。
6. 对后训练数据与通用性的关注 - 提出关键问题：Harness的输入输出是否被用于后训练（评论6："How much do the labs post-train on the harness inputs & outputs?"）。
7. 对确定性Agent的偏好 - 主张Agent应尽可能确定，LLM仅用于边缘决策（评论4："an agent should be as deterministic as possible - the more code, the better"）。
8. 对现有工具的替代性疑问 - 质疑为何不直接使用Claude Code等现有工具（评论3："Why are we not just using Claude Code or Codex on our machine?"）。