★ FEATURED ARTICLE 「比 Codex 省 40% token」刷屏 GitHubUnreal Agent 性能零损耗是真香还是 PPT【免费下载链接】unreal-agentAsync-first agent harness项目地址: https://gitcode.com/gh_mirrors/un/unreal-agent九月底一个名为 Unreal Agent 的 Go 开源项目以async-first agent harness的身份冲上 GitHub 热榜社区同步出现了一批密集的技术解读异步工具调用、System Preamble 设计、Harbor 0.22.0 评测适配器、八组件架构全景……其中最抓眼球的一句宣传是相比 Codex 省 40% token、Pi 省 20%且性能零损耗。省 token 意味着直接省钱——在大模型 API 按 token 计费的时代这几乎是每个 Agent 使用者最敏感的痛点。但省 40%这种数字一旦进入传播链路就很容易被折叠成一句口号。它到底是怎么算出来的是架构层面的真实红利还是营销口径的精心裁剪本文回到源码本身把异步工具调用的实现机制、40% 的换算口径与适用边界、以及 Harbor 基准里的中立验证路径逐一拆开来看。官方宣称的数字是怎么来的异步工具调用 vs 空等要理解省 40%的机理先要看懂传统 Agent 循环里被浪费的 token 藏在哪。经典的 ReAct 式 Agent 是一个严格串行的空等循环模型输出一个工具调用 → Agent 执行工具并阻塞等待 → 把工具结果拼进对话历史 → 把整段历史重新发给模型 → 模型输出下一个动作。这个循环有两个显性成本其一每一步工具执行期间模型处于空等状态GPU 算力和上下文窗口都在闲着其二每一步都要把不断膨胀的完整历史重复传输一遍输入 token 随轮次线性叠加。Unreal Agent 的核心做法是把工具调用与模型回合彻底解耦让工具在后台异步执行。看协调器主循环的实现这个架构的骨架一目了然。在 harness/coordinator/loop.go 的Run中协调器同时监听四个事件源收件箱输入inboxOutput、操作执行更新operationUpdates、心跳heartbeat和模型响应modelResponses而模型请求本身在requestModelResponse里被放进独立的 goroutine 异步发起返回后通过 channel 投递。也就是说一次LLM turn发出后协调器并不阻塞在等待模型回复上工具执行的完成事件随时可以插入处理——这正是async-first在事件循环层面的落地。但异步执行本身只是并发手段真正省 token 的是它对模型如何被引导着使用这种异步性的编排。System Preamble 是这套引导的入口见 harness/contextbuilder/prompts/preamble.md原文直接要求模型当后续命令彼此不依赖输出时检查多个文件、同时跑构建和测试、并行验证两个假设应在同一回合内分别发起多个工具调用而不是一个个串行等待。并明确告知模型工具调用是异步的你发出的那一刻它就开始执行并驻留后台发出调用永远不会阻塞你。与之配套的是上下文中运行中工具调用的占位符机制。在 harness/contextbuilder/builder.go 中ToolCallRunningPayload的文案是工具调用仍在运行其结果将在后续回合到达请继续处理独立工作或结束本回合等待它。当一次工具调用尚未完成时它的结果位置就放这一段固定占位文本Running: true后续回合会以新结果替换旧占位。这段占位符token数量极小且长度恒定避免了一个大输出反复占满上下文。把这几层机制串起来省 token 的账就清楚了省下的不是工具的输出而是空等期间反复重发历史的输入 token。传统循环中一次发命令→等结果要消耗两轮完整历史的输入而异步模式下多个工具结果可以攒在同一回合内一次交付给模型results that land together arrive in the same turn原本需要 N 次重发的历史被压缩成更少的轮次。上下文里的历史是按append-only累积的见 README 的 Session 定义每少一次重发就少一次全量输入计费。同时这套设计天然对 prompt cache 友好历史被切成稳定的已提交前缀committedPrefix加暂存后缀stagedSuffix不变的头部可以被 provider 侧缓存命中。在 harness/llm/messagesapi/adapter.go 中请求会携带CacheControl: ephemeral缓存标注并支持5m/1h两档 TTLbenchmarks/harbor/README.md 还写明 OpenRouter 适配器会携带 session-id 请求头让 Anthropic 等显式断点服务商把整个会话保持在同一上游上持续缓存。多轮异步回合 前缀缓存叠加才是省 40%的完整计算来源。省 40% 的换算口径与适用场景边界理解了机制就能看出 40% 这个数字的换算口径里藏着哪些前提。第一它必然是对同模型、同任务、同推理强度下的对比而不是跨模型对比——把 GPT-5.6 和某个配置更激进的模型比 token没有意义第二它省的是输入侧的重发与等待成本输出 token 一个都不会少甚至因为同一回合塞进了更多工具调用推理输出还可能略增。所谓性能零损耗严格说是任务成功率不因异步化而退化的宣称而不是token 全面下降。更关键的边界在任务形态上。异步省 token 的前提是存在足够的并行度——多个工具调用互不依赖、可以同时执行。对于检查三个文件、同时跑测试、并行验证两个假设这类探查型任务收益最大但对于强串行流水线每步结果决定下一步命令模型发完一个调用后没有别的独立工作可做异步机制退化为提前结束回合等待省 token 的空间骤减。这也是为什么 Preamble 里特别强调更宽地使用工具调用——这套优化的收益曲线完全取决于模型是否被有效引导去利用并行窗口。此外40%是官方对外口径仓库本身并没有附一份可直接复现的基准报告。翻遍 README.md 和 CONTRIBUTING.md能看到的是我们将持续评估 token 用量与对 Agent 行为的影响这类工程承诺以及 Harbor 评测适配器这样的验证基础设施但没有内置的对比测试结果表。这意味着 40% 这个数字目前停留在官方宣称层级任何人要验证都需要自己搭基准跑一遍——这正是下一节的内容。中立验证Harbor 基准与社区实测能撑起这个结论吗Harbor 是目前 Agent 评测圈事实标准的基础设施Unreal Agent 为其提供了官方适配器整个适配器就放在仓库的 benchmarks/harbor/ 目录下。它是当前唯一一条用第三方基准而非自家脚本验证 token 结论的路径。从 benchmarks/harbor/README.md 看验证流程是完整可操作的先用make -C benchmarks/harbor sync与make -C benchmarks/harbor build REVISIONHEAD把当前提交编译成带 revision 和 sha256 校验的 bundle再用harbor run -a harness_harbor.agent:UnrealAgent -m openai/gpt-5.4跑任务输出agent/trajectory.json——一份符合 ATIF-v1.7 规范的轨迹文件。适配器还支持 Terminal-Bench 4.0Modal 环境等标准集thinking_level从low到max五档可调保证对比时能锁定推理强度变量。真正有价值的是轨迹数据的粒度。看 benchmarks/harbor/src/harness_harbor/trajectory.py转换器把 runner 的 JSONL 日志逐条映射为 ATIF 轨迹每个模型回合都记录prompt_tokens、completion_tokens、cached_tokens、reasoning_tokens、cache_write_tokens五项指标最终聚合为total_prompt_tokens、total_completion_tokens、total_cached_tokens等总量。同时每条工具观察都带sequence、timestamp和available_before_turn元数据——这正是异步时序的审计留痕一个回合发出的多个工具调用其结果分散在哪些回合到达、又在哪个回合之前对模型可见都能从轨迹里逐帧还原。要验证异步是否真的省了重发轮次把 Unreal Agent 的轨迹和基线 Agent如同模型的串行实现逐回合对比 prompt token 累计曲线即可。但这条验证路径有两个必须坦承的约束。其一适配器在 benchmarks/harbor/src/harness_harbor/agent.py 中明确把cost_usd置为None轨迹注释也写明成本未知runner 用量只含 token不含账单金额——Harbor 给的是 token 量纲的证据美元成本需按各自 provider 计价另行换算。其二40% 的宣称对象是与 Codex 对比而 Codex 是闭源产品其内部上下文管理策略不可见社区在同任务、同模型、同难度约束下做一次严格 A/B 需要额外的基准任务集与多轮样本量。仓库里的 benchmarks/harbor/tests/ 目前只有 smoke 级别的任务写文件、跑命令、看图更多是验证适配器链路正确性而非产出性能结论。结论真香需要条件PPT 风险在于口径回到标题的问题Unreal Agent 的省 40%是真香还是 PPT从源码层面看异步工具调用的机制是扎实的、可审计的事件循环的并发模型、运行中调用的占位符替换、前缀缓存的会话级命中每一环都有代码支撑Harbor 轨迹把异步时序完整留痕任何人都能复现验证。这套设计对并行探查型任务的输入 token 压缩是结构性的、真实的红利在同模型对比下省 20%40%并非天方夜谭。但把它当作普适结论则是另一回事省 token 的前提是任务并行度足够、模型被 Preamble 有效引导、provider 的缓存策略配合尤其是一小时级会话缓存输出 token 不减、强串行任务收益有限而 40% 作为官方口径目前仓库内没有一份公开可复现的对比基准报告其换算的对照组、任务集、样本量均未随仓库发布。换言之——机制是真香数字待验证。理性的做法是把它当作一条值得在自己任务集上跑 Harbor A/B 的优化假设而不是一张可以直接写进成本预算表的承诺。异步优先这个方向本身才是这次刷屏背后最有价值的东西。【免费下载链接】unreal-agentAsync-first agent harness项目地址: https://gitcode.com/gh_mirrors/un/unreal-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
