商业产业 Hacker News AI 2026-08-09T00:13 正文 ok 1708 words

Show HN:Tura——构建 Token 用量减少 80%、效果更好的 Agent

英文标题:🔶 Show HN: Tura – Build agent that uses 80% less token and delivers better results

Tura 是一个开源 Agent 运行时框架,主张通过减少重复上下文和模型往返调用,在长程软件工程任务中以更少 Token 获得更好的结果。其公布的 DeepSWE 对比显示,Tura Direct 相较 Codex CLI 总 Token 用量低 77.5%,验证器成功率为 65.0%;Tura Balanced 的成功率达到 80.0%,比 Codex CLI 高 16.7 个百分点,同时 Token 用量低 31.1%。核心机制包括将多步骤操作封装为 `command_run` 宏工具,以及基于任务状态的上下文与提示词管理。项目同时承认,当前结果不能证明所有模型提供商和运行环境下均有同等表现,Claude、Gemini、OpenAI 兼容服务、本地模型及跨操作系统测试仍在路线图中。
打开原文相关 3 · 机会 1
media1.1 KB media578 B media588 B media1.1 KB media8.1 KB media26.0 KB media20.4 KB media54.8 KB

中文

Tura 图标

网站 基准测试:8,243 轮 npm 软件包

英文 | 简体中文

Tura:性能提升 16.7%,Token 减少 77.5%

Tura 是一个开源 Agent 运行时框架,能够以更少的 Token 获得更好的结果。

在 20 个 DeepSWE v1.1 任务中,每个 Agent 均运行三次,Tura 通过减少重复上下文和模型往返调用,创造了显著的 Token 预算优势。你可以通过两种方式使用这一优势。Direct 将大部分优势直接转化为更低成本:总 Token 用量比 Codex CLI 少 77.5%,同时验证器成功率相近,为 65.0%,而 Codex CLI 为 63.3%。Balanced 则将更多节省下来的预算投入推理、调查和验证,成功率达到 80.0%:比 Codex CLI 高 16.7 个百分点,同时 Token 用量仍少 31.1%。12

长程任务基准测试是一种超越精心打磨的孤立提示词、观察 Agent 如何处理真实工作的方式。已发布的比较采用基于运行时框架的开发任务,包含归档提示词、每轮工具调用、Token 使用量、补丁和验证器结果。

已发布的工件比较了指定的 Tura Balanced、Tura Direct 和 Codex CLI 配置,覆盖 20 个 DeepSWE 任务、5 个重写任务以及 2 个单独审查的设计任务。1. 当前测试集记录。3

已发布结果并不意味着每一个已配置的提供商都能达到同等质量或性能。更广泛的 Anthropic/Claude、Google/Gemini、OpenAI 兼容服务、本地提供商、UI 延迟、运行时/会话解析以及跨操作系统测量,仍属于已记录的路线图和已知证据缺口的一部分。

完整基准测试报告

DeepSWE 调试与重写仓库基准比较

涵盖 25 个高难度任务、6 种 Agent 与模型配置、270 个会话的运行时框架成功率和总 Token 使用量。来源及计算说明见下方链接。

Tura GUI

支持多会话并发工作和 HTML 富文本的 GUI 页面。

Tura TUI

支持多会话并发工作和 HTML 富文本的 TUI 页面。

以下结果来自已发布的基准测试工件,而非没有引用来源的汇总数据。其中三个系统承担了大部分工作:

大多数编程 Agent 仍依赖重复的工具调用循环:检查、等待、打补丁、等待、构建、等待、测试、等待。

工具调用型编程 Agent:

Turn 1 : inspect environment

rg -n "TODO|command_run|handler" crates/ rg --files crates/runtime/src crates/tools/src

Turn 2 : apply patch

*** Begin Patch *** Update File: crates/tools/src/command_run/handler.rs @@

  • // old command handler logic
  • // patched command handler logic *** End Patch

Turn 3 : build

cargo build -p runtime

Turn 4 : run tests

cargo test -p runtime --lib

Turn 5 : run lint validation

cargo clippy -p runtime --all-targets

Tura 采用不同路径。它不向模型暴露数十个小型工具,而是暴露一个宏工具:command_run。随后,Agent 可以构建一个多步骤执行树,并在一次 LLM 调用中执行相关操作。

在下例中,两个 Agent 执行相同命令。普通工具调用 Agent 需要五次 LLM 调用;Tura 则将该序列作为一次结构化宏工作流处理。节省的是对话开销,而不是工程纪律。

Tura 宏 CLI 命令:

{ "name": "command_run", "arguments": { "commands": [ { "step": 1, "command_type": "shell_command", "command_line": "rg -n "TODO|command_run|handler" crates/" }, { "step": 1, "command_type": "shell_command", "command_line": "rg --files crates/runtime/src crates/tools/src" }, { "step": 2, "command_type": "apply_patch", "command_line": "*** Begin Patch\n*** Update File: crates/tools/src/command_run/handler.rs\n@@\n- // old command handler logic\n+ // patched command handler logic\n*** End Patch" }, { "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" }, { "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" }, { "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" } ] } }

没有消融测试证明仅由 command_run 导致了 Tura 更低的调用轮次和 Token 用量。不过,在完整 DeepSWE 比较中,Balanced 的调用轮次比 Codex CLI 少 35.8%,Token 用量少 31.1%;Direct 的调用轮次少 69.1%,Token 用量少 77.5%。12

无论 LLM 看起来多么令人印象深刻,LLM 的核心仍然是基于文本 Token 概率的统计归纳模型。

例如,要求 LLM 在石头、剪刀和布之间做选择,并不能保证产生均匀随机的结果。如果真正的三分之一概率分布很重要,那么选择需要外部随机数来源,而不能基于未经验证的模型输出概率假设。

在编程任务中,这往往是致命的。

Agent 更可能执行和生成在统计上更常见的代码与逻辑。但常见的代码和逻辑往往平庸,且缺少充分考量。

Tura 使用不同策略。

在推理过程中,普通 Agent 会从当前状态向提示词目标推理。在这种情况下,$s_1$ 是当前状态,$s_n$ 是用户提示词给出的目标。

$$ s_1 \rightarrow s_2 \rightarrow s_3 \rightarrow \cdots \rightarrow s_n $$

相反,Tura 引导 LLM 先对 $s_{n-1}$ 进行统计估计,然后从 $s_{n-1}$ 的状态反向推理至 $s_{n-2}$。

在下面的示例中,LLM 可以正确推导出玩石头剪刀布的最优策略。

为使石头剪刀布保持公平且具有挑战性, 我们需要无偏的出招。 每一步都必须有真正三分之一的概率。 LLM 无法仅从文本概率中保证这一点。 使用随机数生成器脚本生成 randint(1, 3) 然后将石头、剪刀或布映射到该数字。

在编程任务中,这意味着当 Agent 看到修复前端 Bug 这样的目标时,它会被引导先梳理完整执行路径、重建失败状态并识别根本原因,然后才编写代码。在已发布的 DeepSWE 对比中,Tura Balanced 比 Codex CLI 多通过了 60 个二元任务验证器中的 10 个。

在同一 20 任务子集中,DeepSWE 官方 mini-swe-agent 结果显示,GPT-5.6 SOL High 与 Medium 推理之间存在 8% 的差距,而 Tura Balanced 领先 Codex CLI 16.7%。这表明,仅靠更高的推理投入并不能解释 Tura 的优势。24

运行时上下文与提示词管理器

Skills 往往只是被加载到上下文中的较弱提示词。

在许多 Agent 框架中,长期运行的会话会不断累积 skill 文件、工具输出和过期任务历史。当上下文变得过大时,Agent 会进入单独的压缩轮次,但这种压缩通常只保留一份浓缩摘要。重要执行细节可能变得模糊或丢失。

Tura 将上下文视为运行时状态机的一部分。

Tura 不依赖用户手动重置会话,也不允许 Markdown skills 不断堆积,而是使用 task_status、运行时提示词和递归执行手册,将活跃上下文限定在当前任务范围内。

传统的基于 skill 的 Agent 通常会持续运行一个会话,直到用户启动另一个会话;将广泛的 Markdown skills 加载到该会话中,并让其持续生效,直至重置或压缩。Tura 则将运行时提示词与显式任务状态绑定:会话可被自动重命名、刷新和管理;任务专属手册及 CLI 命令通过递归任务树加载;无关上下文可从 CLI 中移除、替换或压缩。检查点可以保留代码位置、补丁、测试和任务状态,而不只是松散的摘要。实际上,这意味着更少的过期上下文、更低的任务范围 Token 成本,以及旧 skill 或模糊摘要干扰当前工作的更低概率。

由于压缩是 CLI 操作,Tura 可以在 task_status.compact_context 中保留精确执行状态。在已发布的基准测试会话中,Tura 在压缩后平均经过 2.6 轮便从只读检查转入继续执行,而 Codex 的估计值为 5.4 轮。56789

Tura 的 2.6 轮结果根据其归档轮次契约中明确的 compact_context 事件计算得出。Codex 不暴露等效的压缩事件,因此其 5.4 轮结果是根据输入 Token 使用量显著下降的位置估算得出,并排除了可识别的媒体读取边界。

Mac 和 Linux:

Windows:

npm install -g tura-ai tura

同一主软件包也以 @tura-ai/tura 的形式发布到 GitHub Packages。请为 @tura-ai 作用域配置 https://npm.pkg.github.com,使用拥有 read:packages 权限的 Token 进行身份验证,然后安装 @tura-ai/tura。npm 上不带作用域的 tura-ai 软件包仍是最简单的公开安装方式。

Tura 不捆绑提供商凭据。首次启动时,请配置一个 LLM 提供商,并在发送提示词前选择其模型。CLI、TUI 和 GUI 流程请参阅提供商设置。

Windows PowerShell:

git clone https://github.com/Tura-AI/tura.git cd tura .\scripts\install.ps1 tura

macOS 或 Linux shell:

git clone https://github.com/Tura-AI/tura.git cd tura ./scripts/install.sh tura

源代码安装程序会执行完整的环境设置、发布版本构建以及用户 PATH 注册流程。仅当你有意只进行依赖设置而不构建或注册 Tura 时,才在 PowerShell 中传入 -EnvironmentOnly,或在 macOS/Linux 中传入 --environment-only。

入口 用途
tura 交互式终端 UI。
tura "prompt" 使用初始提示词打开 TUI。
tura exec "prompt" 直接 Rust CLI 提示词运行器。
tura run "prompt" 由 Gateway 支持、具备流式输出和历史记录的提示词。
tura bash, tura zsh, tura shel 使用选定的 command-run shell 界面执行提示词。
tura_gateway 本地 HTTP/SSE Gateway,以及可选的 Web GUI 服务。
tura_gui 桌面 GUI 工作区客户端。

有关操作系统特定的 PATH 要求、执行器安装,以及当可执行文件不在 PATH 中时如何注册 CLI,请阅读如何启动。有关命令标志和模式,请阅读CLI 参数。

GitBook 风格的文档索引位于 docs/SUMMARY.md。完整导航页面位于 docs/start/navigation.md。

贡献与项目治理

贡献应当规模小、便于审查,并在负责受影响行为的测试层提供证据支持。请选择与之匹配的 Issue 和 Pull Request 类型,而非对每项变更套用同一份清单。

  • 贡献指南 - 从这里开始了解贡献类型、开发设置、测试选择和 Pull Request 步骤。
  • 贡献说明 - 测试责任归属、受影响矩阵、性能证据和工件脱敏规则。
  • 路线图 - 当前 0.1.x 稳定化优先事项,以及计划中的 0.2 任务规划工作区。
  • 已知问题与证据缺口 - 尚待完成的架构、提供商、基准测试、性能和跨操作系统工作。
  • 行为准则 - 社区标准和开放 Agent 运行时框架原则。
  • 安全策略 - 支持的版本和私有漏洞

English / 原文

Tura icon

Website Benchmark: 8,243 turns npm package

English | 简体中文

Tura: 16.7% better performance, 77.5% fewer tokens.

Tura is an open-source agent runtime harness that delivers better results with fewer tokens.

Across 20 DeepSWE v1.1 tasks, each run three times per agent, Tura creates a substantial token-budget advantage by reducing repeated context and model round trips. You can spend that advantage in two ways. Direct turns most of it into lower cost: 77.5% fewer aggregate tokens than Codex CLI, with a comparable verifier success rate of 65.0% versus 63.3%. Balanced puts more of the saved budget back into reasoning, investigation, and verification. It reached an 80.0% success rate: 16.7 percentage points higher than Codex CLI: while still using 31.1% fewer tokens.12

Long-horizon task benchmarks are one way to look past a polished isolated prompt and see how an agent handles real work. The published comparison uses harness-based development tasks with archived prompts, per-round tool calls, token usage, patches, and verifier results.

The published artifacts compare the named Tura Balanced, Tura Direct, and Codex CLI configurations on 20 DeepSWE tasks, 5 rewrite tasks, and 2 separately reviewed design tasks. 1. current test-set record. 3

The published results do not establish equivalent quality or performance for every configured provider. Broader Anthropic/Claude, Google/Gemini, OpenAI-compatible, local-provider, UI-latency, runtime/session parsing, and cross-OS measurements remain part of the documented roadmap and known evidence gaps.

FULL BENCHMARK REPORT

DeepSWE Debug and Rewrite Repo benchmark comparison

Harness success and aggregate token usage across 25 high-difficulty tasks, 6 agent-and-model configurations, and 270 sessions. Source and calculation notes are linked below.

Tura GUI

GUI page with multi-session concurrent work and HTML rich text support.

Tura TUI

TUI page with multi-session concurrent work and HTML rich text support.

The results below come from published benchmark artifacts, not an uncited aggregate. Three systems do most of the work:

Most coding agents still depend on repetitive tool-calling loops: inspect, wait, patch, wait, build, wait, test, wait.

Tool-calling coding agent:

# Turn 1 :  inspect environment

rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src


# Turn 2 :  apply patch

*** Begin Patch
*** Update File: crates/tools/src/command_run/handler.rs
@@
-    // old command handler logic
+    // patched command handler logic
*** End Patch


# Turn 3 :  build

cargo build -p runtime


# Turn 4 :  run tests

cargo test -p runtime --lib


# Turn 5 :  run lint validation

cargo clippy -p runtime --all-targets

Tura takes a different route. Instead of exposing dozens of small tools to the model, it exposes one macro tool: command_run. The agent can then build a multi-step execution tree and run related actions in one LLM turn.

In the example below, both agents run the same commands. A normal tool-calling agent needs five LLM turns; Tura handles the sequence as one structured macro workflow. The saved work is conversational overhead, not engineering discipline.

Tura macro CLI command:

{
  "name": "command_run",
  "arguments": {
    "commands": [
      {
        "step": 1,
        "command_type": "shell_command",
        "command_line": "rg -n \"TODO|command_run|handler\" crates/"
      },
      {
        "step": 1,
        "command_type": "shell_command",
        "command_line": "rg --files crates/runtime/src crates/tools/src"
      },
      {
        "step": 2,
        "command_type": "apply_patch",
        "command_line": "*** Begin Patch\n*** Update File: crates/tools/src/command_run/handler.rs\n@@\n-    // old command handler logic\n+    // patched command handler logic\n*** End Patch"
      },
      {
        "step": 3,
        "command_type": "shell_command",
        "command_line": "cargo build -p runtime"
      },
      {
        "step": 4,
        "command_type": "shell_command",
        "command_line": "cargo test -p runtime --lib"
      },
      {
        "step": 4,
        "command_type": "shell_command",
        "command_line": "cargo clippy -p runtime --all-targets"
      }
    ]
  }
}

There is no ablation test proving that command_run alone causes Tura's lower turn and token usage. Across the full DeepSWE comparison, however, Balanced used 35.8% fewer turns and 31.1% fewer tokens than Codex CLI, while Direct used 69.1% fewer turns and 77.5% fewer tokens.12

However impressive LLMs can be, an LLM is still, at its core, a statistical induction model over text-token probabilities.

For example, asking an LLM to choose among rock, paper, and scissors does not guarantee a uniform random result. If a true one-in-three distribution matters, the choice needs an external random-number source rather than an uncited assumption about model output probabilities.

In coding tasks, this is often fatal.

An agent is more likely to execute and generate code and logic that are statistically more common. But common code and common logic are often mediocre and under-considered.

Tura uses a different strategy.

During reasoning, a common agent reasons from the current state to the prompt goal. In that case, $s_1$ is the current state, and $s_n$ is the goal given by the user prompt.

$$ s_1 \rightarrow s_2 \rightarrow s_3 \rightarrow \cdots \rightarrow s_n $$

Instead, Tura guides the LLM to statistically estimate $s_{n-1}$ first, then reason backward from the state of $s_{n-1}$ to $s_{n-2}$.

In the example below, the LLM can derive the optimal strategy for playing rock-paper-scissors correctly.

> To keep rock-paper-scissors fair and challenging,
> We need unbiased play.
> Each move must have a true one-in-three chance.
> An LLM cannot guarantee that from text probabilities alone.
> Use a random-number generator script to generate randint(1, 3)
> Then map rock, paper, or scissors to the number.

In programming tasks, this means that when an agent sees a goal like fixing a frontend bug, it is guided to reason through the full execution path, reconstruct the failure state, and identify the root cause before writing code. In the published DeepSWE comparison, Tura Balanced passed 10 more of 60 binary task verifiers than Codex CLI.

On the same 20-task subset, DeepSWE’s official mini-swe-agent results show an 8% gap between GPT-5.6 SOL High and Medium reasoning, while Tura Balanced leads Codex CLI by 16.7%. This indicates that higher reasoning effort alone does not explain Tura’s advantage.24

Runtime Context and Prompt Manager

Skills are often just weaker prompts loaded into context.

In many agent frameworks, a long-lived session keeps accumulating skill files, tool outputs, and stale task history. When the context becomes too large, the agent enters a separate compaction turn, but that compaction usually preserves only a compressed summary. Important execution details can become vague or lost.

Tura treats context as part of the runtime state machine.

Instead of relying on users to manually reset sessions or letting Markdown skills pile up, Tura uses task_status, runtime prompts, and recursive execution manuals to keep the active context scoped to the current task.

Traditional skill-based agents usually keep one session running until the user starts another, load broad Markdown skills into that session, and leave them active until a reset or compaction. Tura instead ties runtime prompts to explicit task state: sessions can be renamed, refreshed, and managed automatically; task-specific manuals and CLI commands are loaded through a recursive task tree; and irrelevant context can be removed, replaced, or compacted from the CLI. The checkpoint can retain code locations, patches, tests, and task status rather than only a loose summary. In practice, that means less stale context, lower task-scoped token cost, and fewer chances for an old skill or vague summary to steer the current job.

Because compaction is a CLI operation, Tura can preserve exact execution state in task_status.compact_context. In the published benchmark sessions, Tura moved beyond read-only inspection and resumed execution an average of 2.6 rounds after compaction, compared with an estimated 5.4 rounds for Codex.56789

Tura's 2.6-round result is calculated from explicit compact_context events in its archived round contracts. Codex does not expose equivalent compaction events, so its 5.4-round result is estimated from points where input-token usage drops sharply, excluding identifiable media-reading boundaries.

Mac and Linux:

Windows:

npm install -g tura-ai
tura

The same main package is also published to GitHub Packages as @tura-ai/tura. Configure the @tura-ai scope for https://npm.pkg.github.com, authenticate with a token that has read:packages, then install @tura-ai/tura. The unscoped tura-ai package on npm remains the simplest public installation.

Tura does not bundle provider credentials. On first launch, configure an LLM provider and select one of its models before sending a prompt. See Provider setup for the CLI, TUI, and GUI flows.

Windows PowerShell:

git clone https://github.com/Tura-AI/tura.git
cd tura
.\scripts\install.ps1
tura

macOS or Linux shell:

git clone https://github.com/Tura-AI/tura.git
cd tura
./scripts/install.sh
tura

The source installer performs the complete environment setup, release build, and user PATH registration flow. Pass -EnvironmentOnly on PowerShell or --environment-only on macOS/Linux only when you intentionally want dependency setup without building or registering Tura.

Entry Use it for
tura Interactive terminal UI.
tura "prompt" Open the TUI with an initial prompt.
tura exec "prompt" Direct Rust CLI prompt runner.
tura run "prompt" Gateway-backed prompt with streaming/history.
tura bash, tura zsh, tura shel Prompt with a selected command-run shell surface.
tura_gateway Local HTTP/SSE gateway and optional web GUI serving.
tura_gui Desktop GUI workspace client.

For OS-specific PATH requirements, executor installation, and how to register the CLI when the executable is not on PATH, read How to start. For command flags and modes, read CLI parameters.

The GitBook-style documentation index is docs/SUMMARY.md. The full navigation page is docs/start/navigation.md.

Contributing and project governance

Contributions should be small, reviewable, and supported by evidence at the test layer that owns the affected behavior. Choose the matching issue and pull request type rather than applying one checklist to every change.

  • Contributing - start here for contribution types, development setup, test selection, and pull-request steps.
  • Contribution guide - test ownership, affected matrices, performance evidence, and artifact-sanitization rules.
  • Roadmap - current 0.1.x stabilization priorities and the planned 0.2 task-planning workspace.
  • Known issues and evidence gaps - open architecture, provider, benchmark, performance, and cross-OS work.
  • Code of Conduct - community standards and the open agent-harness principle.
  • Security policy - supported versions and private vulnerability reporting.
  • Support - where to report bugs, request features, or ask setup and usage questions.

Tura is licensed under AGPL-3.0-or-later. See LICENSE.

Benchmark notes and sources