Leviath：单 Rust 二进制承载万级 LLM 智能体

开发者社区近期出现一款名为 Leviath 的 LLM 智能体运行时，主打「一个二进制文件描述智能体，一个进程跑一万个」。整个项目以单一 28 MB Rust 二进制分发，无需额外依赖，安装命令为 curl -fsSL https://leviath.dev/install.sh | sh。项目方在 Hacker News 的 Show HN 板块发布，并配套公开了基准测试代码与运行结果。

设计思路：按阶段而非按智能体分配资源

Leviath 把传统「一个智能体从头跑到尾」的范式改为「按阶段（stage）配置模型、工具与上下文预算」。一个智能体的完整行为由一份 .leviath 文件描述，运行时把该文件解析为一张图，用户既可在浏览器中的「The Lair」面板观察运行过程，也可用 lev dash 在终端查看。

项目方重点解决了长任务执行中常见的五类问题：

• 长任务遗忘开场约束，被文件输出和堆栈信息挤压出上下文窗口；
• 推理与列表文件等低成本操作共用同一模型，造成算力浪费；
• 进程崩溃后无日志可恢复，已写入文件、已执行的迁移或推送无法追溯；
• 每个智能体独占进程，机器资源迅速耗尽；
• 主智能体可被人工接管，但子智能体遇到问题只能猜测，无法上报。

核心机制

• Context regions（上下文区域）：把上下文按用途分为 task、plan、conversation 等区域，分别指定 pinned（常驻）或 sliding_window（滑动窗口）策略，并设置预算百分比，避免单一窗口无序膨胀。
• Run journal（运行日志）：每一步执行后立即落盘，进程被强杀后可以从断点续跑，无需重做已完成工作。
• Live steering（实时接管）：子智能体在需要人类判断时主动上交键盘，由用户回答后再继续。
• 单进程多智能体：一万个智能体共享同一进程与运行时，不再为每个实例分配独立内存。

内置的 coder 智能体示例展示了多阶段配置：plan 阶段使用 claude-sonnet-5（示例配置中标注的模型名），限定为只读工具与 ask_user_choice，最多 20 轮；implement 阶段切换到 claude-opus-5（同前），允许写文件与执行 bash，最多 50 轮；当迭代 20 次、运行 15 分钟或同一文件被编辑 5 次仍未推进时，自动触发 reassess 节点让模型退一步重评。Leviath 默认附带 7 个智能体，开发者无需从零编写即可上手。

自有基准结果

项目方使用同一组「超出上下文窗口的日志语料」任务，对比「单模型循环」与「分阶段结构化智能体」。

任务完成率（每组 10 次，输出包含 17 个精确数字的报告）：

• 32k 窗口：单循环 0 / 10，结构化智能体 10 / 10
• 64k 窗口：单循环 0 / 10，结构化智能体 10 / 10
• 128k 窗口：单循环 0 / 10，结构化智能体 10 / 10

编造数字比例（128k、10 次运行）：

• 无 verify 阶段：8 处编造
• 加上 verify 阶段：0 处编造

项目方同时给出免责声明：基准使用的是自家任务、专为压垮窗口而设计；结构化智能体在构建过程中经过两轮结构性改进；对照组单循环未做对应优化，因为单窗口范式内「无处安放」验证环节；完整运行树将在本轮冻结后公开。

定位与适用场景

Leviath 团队明确表示，结构化智能体并非「默认更优」的方案。如果任务、工具与对话能在一个窗口内放下，单循环成本更低、速度更快，实测效果也常常更好；只有当任务超出单窗口容量、或需要子智能体协作与中途接管时，分阶段结构化设计才是必要的「生存装备」。该项目把这一权衡直接交给 .leviath 配置文件的编写者决定。