你可以把五百个 Agent 想成五百名兼职助理。真正烧钱的，不只是请它们思考，还包括给每个人准备独立办公室、反复递上整本档案，以及每次开工都重新布置桌面。OpenHuman 想压低的正是这些附加成本：让大量 Agent 共用一台廉价服务器，同时减少启动、调度和上下文读取的开销。
这里的 Agent harness，是承载 Agent 的运行脚手架，负责会话、工具调用、任务状态和错误处理，本身不是底层大模型。OpenHuman 是一个开源 harness，同时提供普通用户可用的桌面应用和开发者可嵌入的 Rust 库。项目方声称，一台 10 美元的 VPS——从物理服务器划分出来的廉价虚拟主机——可以容纳五百多个 Agent。本文所有性能数字均来自项目仓库，尚无第三方测评交叉验证。
五百个，究竟省在什么地方？
常见做法是每个 Agent 启动一个较重的进程，并在每轮调用中把大量提示词和历史内容重新发给模型。一个 Agent 时问题不大，数量上百后，内存、启动时间和模型账单都会累积。
OpenHuman 把整个核心编译成单个 Rust 进程。项目方报告，其编码任务中的峰值内存为 68 MB，冷启动约 0.1 秒。功能也不会一次全部加载：搜索、文档或语音等能力接入同一条内部“总线”，需要时才启动；某项功能卡住时，其余部分仍可继续工作。
另一个重点是少让模型读无关文字。OpenHuman 基于 Recursive Language Models 处理大型工具返回结果：普通大结果先压缩，特别大的结果则变成可搜索的“句柄”，Agent 需要哪一段再查哪一段。它还会在每轮对话前，从记忆中挑出与当前任务有关的内容，并限制在给定的 token 预算内。token 可以粗略理解为模型计费和处理文本时使用的基本单位。
工具选择也由一个名为 Jev 的小模型负责。面对 1,215 个工具，项目方称正确工具出现在其候选前列的比例为 86.8%，关键词搜索则为 70.5%。思路很直接：先让便宜的小模型缩小范围，再把更短的提示词交给主模型。
跑得快，是因为每一步做得少
项目方在相同 SWE-bench 任务、模型、API key 和容器下测试了七款 Agent 工具。SWE-bench 是一组让模型处理真实软件问题的基准任务。其最新一轮包含十项任务。
按仓库公布的结果，OpenHuman 每个已解决任务的中位耗时为 19.8 秒，其他六款工具的中位数为 46.5 秒；峰值内存为 68 MB，对方中位数为 523 MB；CPU 时间为 1.3 秒，对方为 10.4 秒。它发送的系统提示词约 4,600 tokens，也是七款中最短。项目方据此宣称，它使用的 tokens 约少 2.6 倍，内存和 CPU 约低 8 倍。
仓库还展示了一次与 Hermes 的单任务对比：在相同提示词、模型和推理设置下，OpenHuman 用时 20 秒、消耗 15,000 tokens、花费 0.0054 美元；Hermes 用时 9 分 40 秒、消耗 37,000 tokens、花费 0.0082 美元。这能说明“少传文本、少做调用”可能带来明显差异，但一次案例不能代表总体性能。
为什么值得关注？
大量 Agent 的“并发”并不意味着五百个模型同时满负荷计算。它更像五百项工作在同一时段推进：有些等待模型回复，有些等待网络或磁盘，服务器趁空轮流处理。OpenHuman 的价值主张，是把这些等待中的 Agent 保持得足够轻，从而让小服务器也能管理大规模任务队列。
这也解释了为什么“十美元养五百个 Agent”值得拆解。它讨论的不是模型突然变便宜了，而是 Agent 外围的软件能否少占内存、少重复阅读、少启动进程。若这些优化成立，开发者扩充 Agent 数量时，成本增长可能不必完全跟实例数同步。
OpenHuman 的亮相颇具挑战意味。据 Repo Dispatch 根据公开记录还原，创作者 Steven Enamakel 在 2026 年 4 月 20 日以“We are killing OpenClaw”开场。项目方还称，OpenHuman 发布一周内登上 GitHub trending repository 第一，并连续保持九天。不过榜单范围和统计口径没有交代。
局限与未知
- “五百多个”更接近可容纳的实例数，不等于五百个 Agent 能持续满负荷工作。仓库没有说明这台 VPS 的 CPU、内存、并发活跃度和模型调用负载。
- 全部基准结论均来自项目方。“typical agent tool”的比较口径不够透明，相同提示词、模型和推理也不等于功能完成度与运行环境完全等价。
- OpenHuman 仍处于 early beta，并在积极开发。项目方也提醒用户预期会遇到粗糙之处，因此当前稳定性和性能数字都可能快速变化。