Unreal Agent

原文 ↗ Hacker News 讨论 ↗

一个新的基于 Go 的 AI 编码 harness，Unreal Agent，旨在通过异步运行工具、减少轮询开销，并相比 Codex 和 Pi 等流行方案降低 token 使用量，从而提升工具型代理的效率。评论者整体上对这种异步、类 actor 的编排模型持积极态度，并将其与其他 harness 和技术（例如程序化工具调用、决策模型和分形工具发现）进行比较，同时质疑它在真实世界中的速度与成本收益到底有多大。许多人也批评其品牌命名，指出这很可能与 Epic 的 Unreal Engine 发生商标冲突，并会给期待游戏相关工具的开发者带来困惑。

异步工具与 token/成本节省

  • 一些评论者很难理解异步工具调用如何能直接节省 token，因为模型在工具执行时并不会“运行”。
  • 解释主要集中在：
    • 减少某些 harness 中无谓的轮询循环（例如 Codex 反复检查任务状态）。
    • 避免长时间运行的工具执行期间缓存过期，因为这会迫使进行昂贵的上下文重载。
    • 在一次模型轮次中完成“更多工具工作”，从而减少缓存读取和总轮次。
  • 也有人指出，通过调整现有 harness 配置中的超时和等待行为，也能获得类似的 token 节省。

Harness 架构与异步/actor 模型

  • 大家强烈支持将代理视为异步进程/actor，而不是线性的聊天会话。
  • 提议的模型：在“actor”之间（文件系统、工具、其他代理）通过消息传递进行交互，用通知代替轮询，并支持跨设备路由。
  • 不少人认为这非常适合 Erlang/Elixir 风格的监督与故障处理，本质上就是一种“agent OS”。

与现有 harness 和技术的比较

  • 许多框架已经支持异步工具或相关理念：OpenAI 的异步工具调用、Claude Code、Crush、DSH 的“programmatic tool calling”，以及多个开源 harness。
  • 有人表示，Unreal 的做法与其他人自 2024 年初以来一直在做的事情很接近，不过更新的模型更适合异步模式。
  • 还有人称，像 Unreal 这样的技术可以与成本优化型 harness（例如 maki.sh）结合使用。

怀疑与开放问题

  • 对其真实收益存在怀疑，认为可能只是“看起来更快”，因为代理通常必须等待工具输出后才能继续。
  • 过去的经验中，代理会调用异步工具，但随后立刻以很长的超时去“等待”，导致变慢或挂起。
  • 有人担心，禁止子代理或坚持使用以 CLI 为中心的 SDK，可能会损害长周期或复杂任务的表现。

命名与商标问题

  • 许多读者起初以为这与 Unreal Engine 有关。
  • 普遍观点认为，“Unreal” 这个品牌名令人困惑，而且很可能会引来游戏引擎所有者的商标挑战。
  • 还有人担心，这种法律风险会影响该项目对严肃用户的可持续性。

可用性、文档与生态问题

  • 有人抱怨 README 缺少清晰的“入门”路径，不过也有人更喜欢简洁、高信噪比的文档。
  • 还有人询问对订阅、OAuth、GUI/TUI，以及与现有 subs（例如 Codex）的兼容性支持。
  • 更广泛的挫败感在于：在 API 定价下，试验新的 harness 想法成本很高，尽管存在明显的低垂果实，但创新仍受限制。