tinyhumansai/openhuman

如果你正被大量 agent 实例的内存和 token 成本卡住，并且会写 Rust 或愿意先用桌面版，OpenHuman 值得花时间评估。但它的性能数字目前是项目方自己的基准，先按你的任务复现一遍再决定。

解决什么问题

假设你想做一个“每个客户一个 agent”的产品，或者内部要同时跑几百个 agent。常见做法是每个 agent 一个重进程，每次调用都重发一大段 prompt，内存和 token 开销随 agent 数量一起涨。OpenHuman 想解决的就是这一步：用一个 Rust 运行时承载数百个 agent，每个 agent 有自己的模型、工具、记忆和沙箱，并声称 500 个 agent 能塞进一台 $10 VPS。真正变化的是 harness 对上下文压缩、工具选择和功能加载的处理方式，项目称这能压低每个 agent 的成本。

有什么不同

它的核心是一个库优先的 harness：加进 Rust 项目后像调用函数一样调用 agent，不需要额外的 sidecar 或守护进程。同一个运行时可以托管大量相互隔离的 agent，这是面向“agent 集群”场景的关键点。README 把省下来的开销归因于六个设计思路，其中包括“RLM token 压缩”，并链接到独立的冷启动和基准页面。项目公开了 SWE-bench Verified 的结果，在十个编码任务上、使用相同模型和容器与另外六个 harness 对比，另外还有一张功能对比表。

代价是这些数字来自项目方自己的基准运行，任务范围也限于编码类；它们只能说明作者测到了什么，不能保证你的 prompt 和工具也能获得同样效果。功能面上，MCP、skills、自带模型、对文件和仓库的记忆等，让它和已有的编码 agent 处在同一赛道，切换成本真实存在：你在采用一套新的运行时和它的约定。每轮对话前带引用地召回记忆是个值得注意的设计，但这也意味着召回质量会直接变成 agent 行为的一部分。

谁值得试

适合：正在用 Rust 做产品、需要“一用户一 agent”又不想上进程级集群的团队；或者想评估 harness 开销、愿意拿自己的任务做对照实验的人。桌面应用和终端/无头模式让不写 Rust 的人也能先用上同一套 harness，个人用户可以走图形界面。不适合：已经深度绑定其他 agent 框架插件生态的团队，或者现在就需要成熟稳定 API 的人。README 自己标了 early beta，如果你打算基于库 API 做产品而不只是试用应用，这一点很关键。

使用条件与边界

你需要自备模型服务；示例用的是 OpenAI 兼容端点加 API key，所以模型访问和 token 费用仍然由你承担。走 Rust 库路线意味着要有 Rust 工具链和构建步骤；走桌面路线则要下载对应平台安装包（.dmg、.msi/.exe、.deb/.AppImage），或运行安装脚本，脚本会校验 checksum，但本质仍是执行远程代码。agent 沙箱和访问控制（例如只读访问）是按 agent 配置的，隔离效果取决于你是否配置正确，不能假设有默认保障。

长期维护是更大的问题：early beta 加上快速变化的 API，意味着你需要锁定版本，并持续用真实任务复核基准。性能结论绑定在特定的一次基准运行上，在决定按集群规模规划之前，先在自己的硬件上重新验证冷启动和每 agent 内存占用。

HotRepo 点评

HotRepo 目前只有 2026-10-25 这一个观测日：42,323 stars，当天 +43，日榜出现 1 天。只有一个记录日期，无法判断趋势能否持续，这个快照也说明不了关注度是否长期存在。考虑到 early beta 标签和自发布基准，采用前最值得核实的是基准方法和库的 agent 隔离模型是否满足你的多租户要求。

项目源码与说明