返回资讯中心
外部精选
软件工程
#开发者实时流

DevLoops 开源 unified-brain:用 SQLite 记忆层和 System One 模型替代回合制 LLM 代理

来源标题:Show HN: Replacing Turn-Based LLM Agents with SQLite and System One Models

DevLoops 发布开源框架 unified-brain,用 SQLite 中间记忆层配合 System One 判定模型 Jev 完成检索与判断,在九题 74 分 xz 基准上得分 93.2%,与 Claude Fable 5.1 代理持平,成本仅为后者的 1/8 至 1/20,速度快 2.4–3.5 倍。该框架是感知层而非执行框架,可通过 MCP 接入 Cursor、OpenCode、Claude Code 等工具。

Hacker News 最新Alexandros842026/11/3 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

DevLoops 打造的 System One 编码智能体持久记忆方案。

2026 年 10 月 24 日,我将一个名为 unified-brain 的框架以开源形式发布:它的证据收集过程快速、廉价,准确度却足以媲美前沿编码智能体。在同一个九题、满分 74 分的 xz 基准测试(evals/questions/xz.md)上,它得分 93.2%——与 Claude Fable 5.1 智能体持平,略低于 Claude Opus 5.5 智能体的 94.6%——而成本仅为后两者的 1/8 和 1/20(开启 prompt 缓存的情况下),速度快 2.4 至 3.5 倍。10 月 29 日时它的得分还是 86.5%;补齐差距的四项检索改动,每一笔都记录在 evals/results/ 中。收集工作由 Jev 完成——它是一个前沿决策评判模型,而非前沿大模型本身。

真正的秘诀在于一个中介式的操作系统(SQLITE)记忆层,它借助一个 System One 模型(也就是 Jev)来完成检索、过滤和评判。

由 unified-brain 派生出的智能体通过 MCP 在 Cursor、OpenCode 或 Claude Code 等环境中运行,让你可以在自己惯用的 harness 里使用它。

所以这里要说清楚:unified-brain 不是 harness,而是任何 harness 都能接入的感知层!

在两个大型操作系统代码库(本仓库 evals/ 目录下的 xz 和 open62541)上的评测结果与前沿智能体足够接近,成本却只是其零头,因此我相信这正是让 AI 更可靠所缺失的一环。

之所以这么说,是因为制约 AI 的瓶颈在于:

LLM 的轮次推理会引入不确定性和概率性结果。 但……unified-brain 的 System One 发现引擎会把任务拆成数百个是/否判断调用,因此搜索过程本身不以自然语言推理,也就不可能凭空捏造出一条路径。在五次分级的 xz 运行中,答案每次最多包含一处错误论断,且总是出现在最长答案中的同一处——是撰写模块误引了一个常量,而其证据中其实是正确值;从未出现检索错误。跨运行的可复现性尚未得到确凿测量。

长时间运行的编码任务会消耗海量 token,导致智能体忘记早期指令,或搞不清大规模架构。 但……得益于其所依赖的 SQLITE 持久化上下文层,unified-brain 不需要缓存记忆。它只是在需要时即时检索所需内容:撰写模块平均每个问题读取 80k token(范围 2k 至 166k),而前沿智能体每个问题计费 1.1 至 2.2M token,且问题之间不会累积任何东西。每个问题彼此独立,因为 git diff 和 commit 会自动从项目记忆层中吸收(最后这部分仍在开发中)。

不过,这一拟议转变(从既有的轮次式探索转向 System One 证据收集)最令人兴奋之处,或许在于:避免不必要的自回归调查,可以减少重复的权重与注意力状态内存访问。通过使用持久化检索和非自回归判断来完成发现,unified-brain 拥有一个可信的机制来降低每个被正确回答问题所消耗的能量——即便传统智能体使用了 prompt 缓存。

若干架构因素支撑这一乐观判断:

更少的中间解码步骤——即便有缓存也是如此。在传统的全注意力智能体中,每个生成的推理 token 或工具选择 token 都要通过其 KV 缓存关注累积的上下文。缓存避免了对早先 token 状态的重算,但并未消除后续生成所需的注意力计算和内存访问。通过用有界的非自回归判断替代大量中间生成 token,unified-brain 可以在发现阶段避免这些重复访问。

降低 KV 缓存压力。把调查状态保持在生成模型之外,可以减少那些必须存储、访问或重算注意力状态的中间 token。

减少对探索历史的注意力。撰写模块可以只接收筛选后的证据,而无需反复关注失败的搜索、冗余的工具结果和此前的调查讨论。

减少缓存未命中时的重复 prefill 工作。将发现与综合分离,减少了因 prompt 增长或变化而触发冗余计算的机会。

可复用的仓库预处理。持久化的符号与历史索引让解析和组织证据的成本分摊到众多问题上。

独立判断的高效执行。非自回归决策可以批处理或并发执行,从而在无需生成中间自然语言的情况下创造更好的硬件利用机会。

降低对前沿模型执行的依赖。将生成模型主要保留用于综合,可以减少其总推理工作量,从而可能降低固定任务量所需的 serving 容量。

可能更高的 serving 容量。减少生成式调查,可以让现有基础设施通过释放模型执行时间和 KV 缓存容量,每分钟服务更多被正确回答的问题。收益大小取决于 serving 瓶颈以及 Jev、检索和最终综合所需的资源。

可能更少的纠错尝试。如果结构化发现提升了证据的完整性和准确性,就能减少代价高昂的后续调查和答案重新生成。

所有节能效果均未测量。已测量的量是 token、美元和秒,记录在 evals/ 中。

我邀请你 fork 这个项目,亲自看一看!我坚信,记忆中间结构结合 System One 模型,很快会把 AI 能力提升到下一个层次。

这项事业背后的理念是:通过架构上的优雅,而非主要依赖暴力式扩展,来解决当代软件工程(SWE)中的推理问题。

flowchart TD classDef step fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff; classDef process fill:#2b6cb0,stroke:#3182ce,stroke-width:2px,color:#fff; Code["1. Raw Git Repository"] Entities["2. Syntax-Isolated Entities Functions, Types, Macros"]:::step VectorDB["3. Structural Vector DB"]:::step

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →