三款编程Agent工具实测自动交付

把 GitHub issue 交给多个编程 Agent，自动开 PR、处理冲突、合并，再部署网站，这条流水线已经能跑通。作者用 Herdr、T3 Code 和 Amp 各做了一次实验：三套工具都在免费方案下，让第一批五个任务在八分钟内上线，期间无需人工介入。

但「一次跑完」离「持续无人值守」还有距离。实验更有价值的部分，是它暴露了三件事：工具管理的是不同层次，Agent 的完成状态未必代表任务完成，而自动发现新需求往往需要另一套触发机制。

先分清：你买的是 Agent，还是管理 Agent 的界面

Herdr 和 T3 Code 主要管理你已经拥有的 Agent；Amp 自己就是编程 Agent，同时提供管理能力。把它们放在一起比较，可以看调度体验，却不能当成三个同类模型产品的能力排名。

Herdr 是用 Rust 编写的终端工作区管理器。它保留了类似 tmux 的分屏、前缀键和断线后仍保留的会话，还能知道每个窗格里的 Agent 正在工作、被阻塞还是已经完成。普通终端只能展示输出，它多了一层可供调度使用的状态。

T3 Code 来自 Theo Browne 和 Ping.gg，提供桌面、Web 和移动端界面，调用本机已有的 Claude Code、Codex 等 Agent，并沿用现有订阅。每个线程关联独立 git worktree、状态和 PR，也可以通过 t3 命令编排。作者测试的是自称「非常早期」的 0.1.5 版本。

Amp 则提供自己的线程、云机器 orbs，以及管理 Agent Puck。也能把本机注册为 runner，让线程在自己的电脑上执行。Puck 只管理 Amp，而且作者使用的免费 Hobby 方案无法运行 Puck。

因此，后面的实验并没有验证 Puck：Amp 那边负责分发任务的，也是一个普通 Amp 线程。

八分钟交付成立，因为任务和验收都被收窄了

作者在 2026 年 10 月 30 日依次测试三款工具，避免争抢同一订阅额度。所有 Agent 都通过同一 Claude 订阅使用 Claude Opus 5.5。这里的「免费」指工具方案，不代表模型使用没有成本。

项目 Cape Trails 是一个纯 HTML、CSS、JavaScript 的徒步网站。初始只有三张路线卡片，另有一个故意放错的链接和一处页脚拼写错误。

第一批五个 issue 包括新增 Lion's Head 页面、难度筛选、暗色模式、修复 Kasteelspoort 链接，以及「让首页好看一点」。筛选、暗色模式和首页美化都会修改 CSS，能顺便观察并行开发的冲突处理。

每个仓库采用相同的 AGENTS.md：一个 issue 一个分支，PR 写 Closes #N，等待检查后 squash-merge，冲突时 rebase，并且只能操作自己的测试仓库。PR 检查运行链接检查器，推送 main 后部署 GitHub Pages。计时取自 GitHub 的 issue、PR、合并和部署记录。

worktree 隔离的是工作目录，不能消除合并时的代码冲突。

Herdr 把创建 worktree、启动 Agent、发送任务和等待结果都做成命令，调度 Agent 可以直接调用：

herdr worktree create --cwd "$PWD" --branch issue-1-lions-head-trail --base origin/main --label issue-1 --no-focus
herdr agent start issue1 --kind claude --pane w2:p1 -- --model claude-opus-5-5 --dangerously-skip-permissions
herdr agent prompt issue1 "Resolve GitHub issue #1 in hashkader47/factory-herdr. Follow AGENTS.md."
herdr agent wait issue1

留意第二行的 --dangerously-skip-permissions。作者用它对齐 Amp 和 T3 Code 默认全访问的执行方式，实验没有包含人工逐项审批的耗时。

Herdr 首次集成 Claude Code 时，会向全局 ~/.claude/settings.json 添加四个 hooks，直接接收状态。作者测试后用 herdr integration uninstall claude 移除了集成。

T3 Code 则用一条命令同时启动线程、创建 worktree 和分支：

~/.t3/bin/t3 thread start . "Resolve GitHub issue #1 in hashkader47/factory-t3. Follow AGENTS.md." \
  --provider claudeAgent --model claude-opus-5-5 --worktree main --branch issue-1-agent

关键是最后一行的 --worktree 和 --branch，它们让每个任务拥有独立检出目录。

Amp 的准备更手动：先运行 amp --no-tui --runner-id ritza-mac，用 git worktree add 创建目录，再通过 amp runner dirs add 注册，最后用 amp -m claude-code --executor runner:ritza-mac -x "<prompt>" 启动工作线程。

真正拉开差距的是状态、冲突和新任务入口

Herdr 的仓库初始化和上线确认用了 51 秒，调度后 30 秒内启动五个 Agent。作者认为，它最容易看清多个 Agent 的实时状态。一次 Pages 部署被后续合并取消，调度 Agent 也检查了后续部署，确认改动最终上线。

T3 Code 初始化用了 59 秒，每个任务都最早开出 PR，第一批任务也最早完成。但它出现了一次状态误判：工作线程等待 CI 时结束当前回合，并请求检查完成后唤醒；调度线程看到「completed」却还有未合并 PR，便用 t3 thread send 催促继续。

其中两个工作线程收到消息时已经合并了。

这暴露的是「回合结束」与「交付完成」之间的语义差异。暗色模式线程还额外开了一个后续 PR，为先合入的筛选按钮补颜色；Amp 的 Agent 则通过 rebase，在原 PR 内完成了类似适配。一次实验不足以证明哪种行为更稳定。

Amp 完成后检查了线上文件是否与 main 一致，清理了 worktree 和 runner 目录，但明确说明没有在浏览器里查看网站。Herdr 留下了七个工作区和 worktree，等待后续清理。

第二批任务才测到了持续运行的边界。作者新建 About 页面和页脚纠错两个 issue，静候十分钟，三款工具都没有主动接单。手动提醒后，Amp 两分钟内合并、四分半钟内上线；Herdr 两分钟内关闭两个 issue，其中页脚错误早被第一批美化任务顺手修掉，因此只需核对提交后关闭。T3 Code 的第二批则因 GitHub 账号被暂停而未完成。

Amp 的 orbs 支持定时、外部事件，以及插件注册的 webhook，也原生支持 Linear issue。但文中的 webhook 文档面向 Amp 管理的 orbs；Hobby 下按量收费，起价为每小时 $0.08。免费本机 runner 并没有在这次实验中自动接单。

我的判断

这篇最有说服力的结论是：三款工具的命令行都足够让一个 Agent 调度其他 Agent，完成从 issue 到部署的短流水线。至于速度排名，作者自己也承认，每款只跑一次，单次 Claude 执行时间和冲突出现顺序就能左右结果。

它验证了小型静态站的自动交付，没有验证一般业务项目的持续自治。

测试没有覆盖复杂依赖、数据库迁移或更完整的验收；链接检查通过，也不能证明暗色模式、布局和交互都正确。那个模糊的美化需求得到三种答案，所有 Agent 还都擅自添加了按难度区分的卡片彩边。对演示站是发挥空间，对需求严格的项目可能就是越界。

选型上，终端用户可以优先看 Herdr；希望把线程、worktree、PR 放在图形界面里的团队，可以看 T3 Code。已有单会话需求时，tmux 或 Claude Code 自带 subagents 也可能够用；要让多个独立会话各自提交 PR，才更需要这类管理工具或自写 worktree 脚本。

Herdr 原生支持 herdr agent start --kind amp。T3 Code 只能通过 Agent Client Protocol（ACP）注册表里的社区 Amp 适配器间接接入。作者没有安装，也没确认它会使用 Claude 订阅还是 Amp credits，不能把「注册表里能找到」当成已经验证兼容。

另一个结果需要谨慎归因：13:31 UTC，首次建库约一小时后，GitHub 暂停了作者账号。当时已有三个公开仓库、21 个 issue、19 个 Agent 合并的 PR，以及约 40 次 Actions 运行。作者怀疑活动像机器人，但 GitHub 尚未给出原因，不能断言是并发 Agent 导致封号。

能拿来做什么

• 先用独立测试仓库验证前端流水线，把 issue 写成明确的页面改动、交互行为和验收条件，再让每个 Agent 使用独立 worktree 与分支。
• 调度脚本应分别核对 CI、PR 合并和部署结果，不要仅凭线程显示「completed」就判断交付完成。
• 同时修改全局 CSS 的任务，要预留 rebase 和合并后检查；暗色模式尤其需要覆盖其他 Agent 新增的组件，链接检查器无法代替这一步。
• 如果要新 issue 出现后自动开工，就单独设计 GitHub Action、定时脚本或付费 orbs 的触发入口。先用小批量任务验证，再逐步增加自动化活动。