Tura
开源 Agent 运行时框架：用运行时管理的命令图替代重复的 ReAct 循环，减少约 80% 的 token 消耗并提升任务成功率。
证据显示该代理通过 command_run 宏工具执行任意 shell 命令和 apply_patch 写操作，权限范围极大；GUI fixture 中有 permission {allow,deny} 结构暗示存在权限模型，但提供的文件中没有沙箱、审批流程或最小权限的文档或代码。未见到写入前用户确认机制的任何说明，也未说明提示词和文件内容如何流向 LLM 提供商。积极面：README 明确不捆绑提供商凭据、使用环境变量令牌，CI 集成 cargo-audit/cargo-deny。检查点（checkpoint）保留执行状态的描述存在，但没有回滚保证或撤销机制的证据。作者署名（Tura）与仓库/许可证元数据一致，但发布者未经注册表验证，署名仅得中等分。
仓库结构自洽：workspace crate 划分清晰、依赖经 lockfile 与固定版本管理、optionalDependencies 按平台分包，CI 对每个 crate 做 clippy+测试并有安装脚本三平台测试。CI 脚本展示结构化错误捕获与日志上传，暗示失败信息处理较认真，但静态审查无法确认用户端错误消息质量，故不给满分。
README/文档索引面向 CLI、TUI、GUI 三种入口，覆盖 macOS/Linux/Windows，安装脚本与 CI 三平台矩阵证明环境适配扎实。对受众（开发者）和场景（编码任务）有明确说明；KNOWN_ISSUES 与 ROADMAP 诚实列出提供商、跨 OS、基准覆盖的能力边界。触发/入口语义（tura、exec、run、bash/zsh）有文档表，但部分入口拼写可疑（`tura shel`），扣一分。
信息架构非常完整：docs/SUMMARY.md 索引、各 crate ARCHITECTURE.md、贡献指南、行为准则、安全政策、支持文件齐备。安装说明详细（npm、源码、PATH 注册、提供商配置），并明确说明无 postinstall 脚本。LICENSE 为完整 AGPL-3.0 文本且与 Cargo/package 元数据一致。已知问题单独成文。扣分点：CHANGELOG.md 仅出现在打包清单中未提供内容，workspace 版本 0.1.0 与 npm 0.1.37 存在不一致；无 FAQ；命名如 `tura shel` 疑似笔误。
README 给出量化成本/收益主张（77.5% fewer tokens、65.0% vs 63.3% 验证成功率），并在脚注中链接方法学与工件，承认缺少 ablation 实验，成本收益论证较诚实充分。输出可用性与边际价值只能从静态描述与截图说明推断，未见独立复现，给中等分。
几乎每条性能主张都带脚注并指向 benchmark 仓库的 manifest/round contract，事实与推断分离较好（明确标注 Codex 5.4 轮为估计值、承认无 ablation）。扣分：所有佐证来自同一作者自建的 benchmark 仓库，属自我证实，无独立第三方复现，跨源佐证薄弱；静态审查无法打开链接核验，置信度只能为 low。
- command_run 宏工具允许模型一次执行多条 shell 命令和补丁写入，请仅在受控/隔离环境中使用，并核实是否存在写入前确认机制。
- 性能数据（77.5% fewer tokens 等）全部来自项目方自建基准，无独立第三方复现，不应直接作为采购依据。
- 发布者未经企业注册表验证；npm 安装前请核对包完整性与 provenance。
- 仓库版本号（0.1.0 vs 0.1.37）不一致，文档中出现疑似笔误的入口（tura shel），使用前请以实际 CLI 帮助为准。
- 提示词与代码内容会发送给所配置的 LLM 提供商，敏感仓库使用前请评估数据外发风险。
这个 Agent 能做什么，适合哪些场景？
Tura（GitHub 仓库 Tura-AI/tura）是一个开源 Agent 运行时框架，核心思路是把传统编码 Agent 中反复进入模型的工具调用循环改写为单次运行时管理的命令图。它不向模型暴露几十个小工具，而是暴露一个宏工具 command_run，让 Agent 在一次 LLM 回合内构建并执行多步操作树。在基于 20 个 DeepSWE v1.1 任务的公开基准中，Tura Direct 比 Codex CLI 少用 77.5% 的聚合 token 且验证成功率相当（65.0% vs 63.3%），Tura Balanced 则以少 31.1% 的 token 达到 80.0% 成功率，比 Codex CLI 高 16.7 个百分点。Tura 还引入 backward reasoning（先估算倒数第二状态再反向推理）和运行时上下文管理：task_status、运行时提示和递归任务手册让活跃上下文始终限定在当前任务，compaction 是 CLI 操作，可精确保留代码位置、补丁、测试与任务状态，官方会话记录显示 compaction 后平均 2.6 轮即可恢复执行。产品提供 CLI（tura exec / tura run）、TUI、桌面 GUI（tura_gui）和本地 HTTP/SSE 网关（tura_gateway），通过 npm 包 tura-ai 全平台分发，许可为 AGPL-3.0-or-later。需要主要的是，其基准优势来自特定配置（GPT-5.6 SOL 等），README 明确说明结果不代表所有 provider 配置下的同等表现。
Tura 读取用户提示后，让 LLM 生成一个结构化的 command_run 调用，其中 commands 数组按 step 编排 shell_command 与 apply_patch 等操作，由 Rust 运行时确定性执行，无需每步都回到模型。推理阶段采用 backward reasoning：先统计性估算目标前一状态 s_{n-1}，再反向推导执行路径、重建故障状态、定位根因后才写代码。上下文作为运行时状态机的一部分管理：task_status 跟踪任务状态，task_status.compact_context 在 CLI 侧做压缩并保留代码位置、补丁、测试结果；会话可重命名、刷新、自动管理；任务手册和 CLI 命令通过递归任务树按需加载。输出层面支持 HTML 富文本，GUI/TUI 均支持多会话并发工作。入口包括 tura（交互式 TUI）、tura "prompt"、tura exec（直接 Rust CLI 运行）、tura run（带流式和历史的网关运行）、tura bash/zsh/shel（选择命令执行 shell）、tura_gateway（本地 HTTP/SSE 网关与可选 Web GUI）和 tura_gui（桌面客户端）。
- 需要在本地终端批量执行「搜索—打补丁—构建—测试—lint」类多步编码工作流、希望把多轮模型往返压缩为单回合以省 token 的开发者
- 长期运行大型重构或调试任务、担心上下文被过期 skill 文件和旧摘要污染、需要任务级上下文压缩并恢复执行的工程师
- 对成本敏感、愿意用 Direct 模式以 77.5% 更少 token 完成同等成功率任务的团队
- 追求更高验证通过率、愿意把节省的 token 预算投入推理与验证（Balanced 模式 80.0% 成功率）的团队
- 偏好桌面 GUI 或 TUI 中多会话并行工作并查看 HTML 富文本输出的用户
- 想通过 tura_gateway 在本地搭建带流式输出和会话历史的 HTTP/SSE 服务并接入 Web 界面的使用者
这个 Agent 有哪些优点和局限？
- 有可审计的公开基准证据：25 个高难度任务、6 种 agent-模型配置、270 个会话，结果发布在 Tura-AI/benchmark 仓库，含轮次契约、token 用量和补丁工件
- 宏工具 command_run 将多步工作流压入单次 LLM 回合，Balanced 配置比 Codex CLI 少 35.8% 回合、31.1% token，Direct 配置少 69.1% 回合、77.5% token
- compaction 是保留精确执行状态（代码位置、补丁、测试、任务状态）的 CLI 操作，存档会话显示压缩后平均 2.6 轮即恢复执行
- 上下文按任务状态管理，避免长期会话中 skill 文件和压缩摘要无限堆积
- 同时提供 CLI、TUI、GUI 和本地网关多种入口，GUI/TUI 支持多会话并发
- 基准优势绑定特定配置（DeepSWE 任务、GPT-5.6 SOL），README 明确声明结果不能推广到所有 provider；Anthropic/Claude、Google/Gemini、OpenAI 兼容、本地 provider 等仍属路线图和已知证据缺口
- README 自述没有消融实验证明 command_run 单独导致了更低的回合与 token 用量
- Codex 的 compaction 恢复轮数（5.4 轮）是基于输入 token 骤降点的估算值，而 Tura 是显式事件，二者口径不完全对等
- 首次使用必须自行配置 LLM provider，产品不捆绑任何凭证
- AGPL-3.0-or-later 许可对希望在闭源产品中集成其代码的团队构成合规约束
如何安装或部署这个 Agent？
npm 全局安装（macOS / Linux / Windows）：npm install -g tura-ai，然后运行 tura。本地项目安装：npm install tura-ai，再 npx --no-install tura。npm 包不运行 postinstall 脚本，wrapper 直接解析并启动对应平台包；同一主包也发布在 GitHub Packages 上，名称为 @tura-ai/tura（需配置 @tura-ai scope 指向 https://npm.pkg.github.com 并使用具有 read:packages 权限的 token）。从源码安装：克隆 https://github.com/Tura-AI/tura.git 后，Windows PowerShell 运行 .\scripts\install.ps1，macOS/Linux 运行 ./scripts/install.sh，安装脚本完成环境配置、release 构建和 PATH 注册；如只需依赖环境不构建，可加 -EnvironmentOnly / --environment-only。
如何使用这个 Agent？
首次启动时必须先配置 LLM provider 并选择模型（Tura 不内置任何 provider 凭证），CLI、TUI、GUI 均有对应配置流程（见 docs/start/providers.md）。之后可使用：tura 进入交互式终端 UI；tura "prompt" 携带初始提示打开 TUI；tura exec "prompt" 直接用 Rust CLI 运行提示；tura run "prompt" 通过网关运行并带流式输出与历史；tura bash / tura zsh / tura shel 选择命令执行的 shell 表面；tura_gateway 启动本地 HTTP/SSE 网关（可选 Web GUI）；tura_gui 打开桌面工作区客户端。核心工作方式是让模型生成 command_run 宏调用，在 commands 数组中以 step 编排 shell_command 与 apply_patch，由运行时在单回合内确定性执行整棵命令树。
这个 Agent 与同类方案有什么区别？
README 直接与 Codex CLI 对比：在 20 个 DeepSWE v1.1 任务上，Tura Direct 聚合 token 少 77.5% 且验证成功率 65.0% vs 63.3%；Tura Balanced 成功率 80.0%（高 16.7 个百分点）且 token 少 31.1%、回合少 35.8%。同一子集上 DeepSWE 官方 mini-swe-agent 的 GPT-5.6 SOL High 与 Medium 推理差距仅 8%，而 Tura Balanced 领先 Codex CLI 16.7%，说明优势不能仅归因于更高推理强度。