如何在 Tau 项目的基础上加入mini-swe-agent 项目中的 Harness 工程化思想（或者还有其他优点）？

群友 2818，我先按 huggingface/tau 来说。可以借鉴，但不建议把 mini-swe-agent 整套塞进去：保留 Tau 的交互与分层，借 mini 的思路把“执行环境、运行轨迹、任务退出、批量评测”做扎实。 我查了两个项目当前的文档。Tau 已经有 AgentHarness、事件流、持久化会话和上下文压缩，不是一个等待补上 Harness 的空壳。mini 更值得学的是：核心循环保持简单，外围让一次任务变得可控、可检查、可重复运行。 下面是改造建议，不代表你现在的 Tau 分支已经有这些接口。 一、沿用 Tau 的三层，不再套第二个 Agent 循环 Tau 当前的分工是： tau_ai：对接模型，统一模型输出。 tau_agent：消息、工具、事件、Agent 循环和 Harness。 tau_coding：文件与命令执行、项目指令、会话、终端界面。 因此，借鉴 mini 时可以这样落位： 模型适配继续留在 tau_ai。 通用预算、停止原因等控制放在 tau_agent。 执行环境、任务工作区放在 tau_coding 一侧。 批量跑任务的入口放在外围，调用同一套核心。 交互界面和批处理应当是同一个 Agent 的两个入口，而不是各自维护一套循环。 不建议让 Tau Agent 把 mini Agent 当作工具，再让 mini 独立处理同一个任务。这样会出现两份上下文、两套预算和两种完成状态，反而难排查。 二、优先借鉴 mini 的执行环境边界 可以把它理解为：Agent 决定做什么，环境负责在哪里、以什么限制执行。 mini 把动作交给 Environment，支持本地和容器等后端。Tau 可以借这个边界，把工具背后的执行位置变成可替换能力。 例如，同样是“修改文件、运行测试”，交互开发时用本地工作区，批量修 issue 时用独立容器；Agent 的循环和上层工具协议不必跟着变。 这里有两个容易漏的细节。 第一，文件工具也要进入同一个环境。不能 bash 在容器里执行，read、edit 却仍然操作宿主机，否则 Agent 看到的代码和测试实际运行的代码不是一份。 第二，mini 的独立命令执行不等于整个任务没有状态。每次命令可以使用新 shell，但文件修改仍然保留；上一条命令中的 cd、export 等 shell 状态通常不会自动延续。 所以，每次执行都应明确工作目录、必要环境变量和超时，返回退出码、输出及异常信息。长输出可以给模型截断版，完整输出另存，供后续查询。 容器也不自动等于安全沙箱，还需要限制挂载、网络、权限和资源。worktree 可以隔离代码改动，但不是安全隔离。 三、把“聊天记录”升级为“任务证据” mini 的线性历史很有价值：可以沿着轨迹看清模型收到什么、调用了什么、执行结果是什么。 但 Tau 已经有追加式 JSONL 会话，不需要再平行造一个聊天记录系统。更有价值的是补齐每次任务的关联信息： 任务描述和代码起始版本。 模型、提示词、工具定义及运行配置。 实际送给模型的上下文。 工具调用、执行结果和文件改动。 最终补丁、退出原因、耗时与费用。 尤其注意 Tau 有上下文压缩：完整历史不等于某一轮模型实际看到的上下文。 如果后来加入历史召回，也应记录这一轮选中了哪些片段、来源是什么。否则你只能看到“它答错了”，却不知道是没召回到证据、压缩丢了限制，还是模型看见了但没遵守。 可以保存请求快照，或者保存足以重建该请求的记录。涉及凭据的内容要脱敏，日志也应有访问控制。 另外，能查看轨迹不等于能原样恢复执行。恢复还涉及工作区、依赖和外部状态；重新调用模型也不保证得到相同输出。 四、借鉴 mini 的明确退出机制，而不只是抄一个 while 循环 mini 当前实现里有步数、费用、总时长和连续格式错误等限制，也会记录退出状态。 迁到 Tau 时，关键不是配置项叫什么，而是程序必须能区分： 模型主动提交结果。 用户取消。 预算或时间耗尽。 工具执行失败。 模型调用失败。 验收通过或失败。 其中，“模型说完成了”和“任务验收通过”必须分开。 比如模型修完分页 bug，回复“已解决”，这只能触发提交；是否成功，要看测试、补丁检查等外部结果，不能直接把这句回复当作成功标记。 错误也不能一律自动重试。测试失败可以作为反馈交给模型继续修；参数格式错误可以有限纠正；有副作用的操作如果执行结果不确定，应该先核查状态，不能直接重放。 这些控制应在核心运行路径生效，而不是依赖终端界面提醒。这样无人值守执行时才仍然有效。 五、把批量运行和验收接上同一套 Harness 这是 mini 对 Tau 很值得补充的一个方向。 mini 提供 SWE-bench 的单任务调试和批量运行入口。借到 Tau 上，就是让每次运行都有明确的输入和产物： 输入是任务、代码起点、执行环境和预算。 产物是补丁、轨迹、退出状态和验收结果。 以“修复分页漏数据”为例，一次完整运行可以是： 外围任务入口准备指定版本的独立工作区。 Tau 读取任务，照常读代码、编辑、运行命令。 模型提交后，导出补丁。 独立验收流程在受控环境应用补丁并跑测试。 最后把结果和轨迹关联保存。 验收依据不能由 Agent 随便改掉，否则它可能通过修改测试获得假成功。 这样你以后换模型、改提示词、加 Skill 或接入上下文召回，就能在同一批任务上比较通过率、耗时、费用和失败原因，而不是凭“这次看起来挺聪明”判断效果。 六、mini 的极简工具思路可以借，但不用全部照搬 mini 的重要优点是减少专用工具和复杂控制逻辑，让模型利用 shell 完成任务。这降低了维护负担，也适合作为实验基线。 但这不意味着 Tau 应该删掉 read、write、edit。专用工具仍然可以提供更清楚的结果、编辑校验和权限边界。 更合理的是保留两种可选择的工具配置：日常交互使用 Tau 的文件工具加 bash；实验时提供 bash-only 配置，在相同模型和预算下比较差异。 顺便提醒一个版本细节：mini 的部分介绍仍强调“不依赖原生 tool calling”，但当前 v2 迁移文档明确说默认已使用原生工具调用。不要为了模仿旧教程，把 Tau 现有的结构化工具调用退回正则解析。 总结一下：Tau 值得保留的是清楚的分层、事件流和交互能力；mini 值得吸收的是简单循环、可替换环境、透明轨迹和批量实验能力。工程化不是不断往 Agent 脑子里加逻辑，而是让它每次执行都能被约束、检查和比较。 对应资料： Tau 架构：https://twotimespi.dev/internals/architecture/ mini 控制流：https://mini-swe-agent.com/latest/advanced/control_flow/ mini 批量任务：https://mini-swe-agent.com/latest/usage/swebench/ mini v2 变化：https://mini-swe-agent.com/latest/advanced/v2_migration/