HERO

HARNESS EVERYTHING ROUTING ORCHESTRATOR

为什么做 HERO

编码 agent 已经能跑很长的任务，但操作它们的方式还绑在一个终端窗口上。

起点是一个很具体的麻烦

跑一次大重构或全量测试要二十分钟。这二十分钟里你不能走开——不是因为要盯着输出，而是因为它随时可能停下来问你一个权限，而那个提示只出现在那台机器的那个终端里。任务是异步的，操作它的方式却是同步的。

HERO 只解决这一件事：把这层交互搬到浏览器里。会话还在原来的机器上，还是官方 CLI 在干活，变的只是你从哪里看它、从哪里回它一句话。

我们没有重写 agent 循环，也不打算重写。Claude Code 和 Codex 的循环由官方维护，跟着模型一起演进；重写一遍意味着永远落后一个版本。HERO 驱动它们照常运行，只补上界面、远程访问和会话管理这三样它们没有的东西。

同一个逻辑推到多台机器，就是控制面：一支队伍的机器各自出站连上来，你在一块面板上看到全部会话。

几个刻意的取舍

依赖越少越好

服务端几乎只用 Go 标准库，直接依赖三个包。前端是纯 JS，没有构建步骤、没有 npm。可审计的依赖链是明确的设计目标——你要在自己的机器上跑它，就该能读懂它带进来的东西。

渲染对话，不浏览机器

HERO 渲染 CLI 已经写下的对话，不提供文件读取、目录列举或 diff 接口。这不是还没做，是不做：一个能读任意文件的远程面板，安全模型完全是另一回事。

边界写下来，而不是含糊过去

自行部署与托管的数据边界不一样。我们把不同写在页面上，而不是用一句好听的话盖住两边。定价页上的额度目前是合同约定而非技术强制，我们也照实写了。

上游

HERO 从 nexustar 的 usher 分叉而来，git 历史直接承自 usher，每一个 HERO commit 都坐在那份工作之上。usher 使用 MIT 许可，因此 nexustar 的版权声明保留在我们的 LICENSE 中。感谢这份基础。