Theo 的 AI 代理工作流：并行调查、审查循环与更安全的合并

经营公司和 YouTube 频道让我写代码的时间变少了。我喜欢其他工作，但也想念解决难题、改进自己每天使用的软件。最近我找到了一套工作流，让我在处理生活中其他事务的同时继续贡献代码。

我的 T3 Code 图表显示，每周合并的 PR 从一到三个上升到 23、37、41，最后达到 52。图表统计的是提交数，但我们使用 squash merge，因此我把它当作 PR 数量。合并 52 个 PR 的那一周还包括去 DEF CON 的旅行。这是我的个人经验，并非受控的生产力研究，我也不认为工作流的每个细节都适合所有人。

好的代理工具有帮助，但我也改造了 T3 Code，让它支持我的工作方式。一位观众指出，只能手动调用的 skill 可以通过开头的斜杠命令使用，却不能通过美元符号选择器调用。我自己没遇到过这个问题，于是开始调查。

我新建一个线程，选择远程 Linux 机器运行任务，而不是让笔记本负责这项工作。那台机器有我的代码库、T3 Code 服务器和代理运行环境，我使用 worktree 隔离任务。Worktree 不完美，但对于并行任务来说已经足够实用。

我的提示词先给代理背景：这个问题影响真实用户，我希望修复方案实现简单、用户也容易理解。我提出自己的看法，即输入框中的美元符号 skill 应该在任何位置都能生效，但把它表述为意见，好让代理可以反驳。我也说明自己不了解 Claude Code 行为的哪些部分。

具体请求是审查 Claude Code 和我们的实现。如果找到简单方案，就停止并报告可信的解决路径，而不是无休止地探索。我还说明要的是解决路径，不一定要写代码。交代优先级、未知之处和停止条件，有助于代理返回我能用的信息。

然后我不再盯着线程。看着长期运行的代理似乎很有生产力，却不会让它更快完成。先去做其他事情，等有结果再回来。麻烦在于，我启动的线程太多，有时会跟丢，因此我也做了一些管理队列的工具。

一位贡献者提交了用量限额显示功能的 PR，但我的 CLI 代理设置让我不容易测试正常认证。我不想费时重建环境后才发现明显缺陷，于是先让代理审查。我的目的是减少令人沮丧、可能打断专注的时刻。

审查提示词给出 PR 链接，并询问 API 轮询频率、潜在限流、显示数字的准确性，以及与 CodexBar 等其他开源实现的区别。我要求它找出现在合并可能影响用户的问题，而不只是笼统地说好或不好。语音转写的格式不必完美，模型也能理解目标。

审查运行期间，我展示了远程 Linux 主机的资源使用情况。我曾同时运行几十个代理而没有耗尽资源，但不受限制的 Rust 编译等繁重构建仍可能消耗大量内存。我的体验是 Linux 更适合自己的并行工作流；不同硬件、任务和环境可能有不同结果。

我还请一个较便宜的模型盘点未处理的 PR：哪些可以合并，哪些可能应该关闭，哪些需要再检查？我让它优先列出容易处理的事项，并用子代理分工。我也用另一个模型运行相同请求，以便比较建议，而不是自动接受第一份清单。

T3 Code 把 PR 和代理线程关联起来。关联的 PR 合并后，线程可以自动移出活动侧边栏，进入已处理状态；之后仍可恢复。我把侧边栏当成仍需关注的工作收件箱，重要但暂时不需要处理的线程则延后提醒。

Skill 审查返回了三个疑似缺陷：发现机制忽略相关 skill 设置；美元符号语法未经转换就发给 Claude；斜杠命令只在消息开头展开，菜单却在任何位置都提供它。这些背景很有用，但我很难理解它提出的修复方案。

我没有放弃，而是请代理用更简单的语言解释方案，并把每项修复和对应的问题联系起来。它重新解释时，我可以安心处理另一个已完成的线程。我还发现远程连接中断，以及一个线程没有正确标记完成，于是另开调查。

用量仪表盘审查建议暂缓合并，即使 CI 已通过。它指出缺少限流响应处理、轮询频繁、显示了 API 未报告的无限窗口，以及忽视本地数据源。模型还找到社区关于用量请求失败的报告；建议的轮询间隔来自这次调查，并非官方保证。

报告很详细，于是我请它起草一条评论，向贡献者解释重要问题。我明确要求先给我看草稿，经我批准后才能发布。Skill 问题的简化解释也回来了：选择器可能提供已禁用的 skill，而发送字面的美元符号引用不一定会调用 Claude skill。

我继续询问如何向用户说明斜杠命令限制，以及能否让体验更接近 Codex。对于 PR 评论，我根据自己知道的情况修正草稿：应该包含 Fable 的每周限额，而且如果同一账户在别处使用，本地缓存的 Codex 用量可能过期。我想要的是准确数据，而不仅仅是减少请求。

确认修改方向后，我授权代理代表我发布评论。贡献者也在观看直播。我可以把已有 PR 关联到这个线程，并将线程延后到贡献者预计更新的时间，让对话在有用时再出现，而不是一直占据我的注意力。

我的 babysitting skill 自动处理重复的审查循环。代理提交 PR 后，它会关注自动审查评论，判断是否值得处理，推送适当修复，并继续观察，直到审查循环稳定下来。我不必手动把每一轮评论复制回编码线程，而是在循环结束时回来查看。

两份 PR 排序结果也需要人的判断。其中一份建议合并设备数量限制修改，但由于基础设施方面的顾虑，我暂时不想合并；它还推荐了一项原生 iOS 修改，而这项工作比模型认为的更复杂。我认为这份清单对我不够可靠，便弃用了它；另一个模型的审查仍在运行。代理建议不等于合并决定。

回到 skill 问题，代理解释说，转换层可以把美元符号 skill 调用移到 Claude 期望的位置，而原始斜杠命令仍有自己的位置限制。它随后测试 SDK 能否叠加多个斜杠 skill，并报告说在所测版本中无法实现，尽管它理解文档支持这一行为。

我让它先搜索已有报告，而不是立刻设计复杂的变通方案。它找到了一个问题，我说团队成员已经确认这是 bug。针对这个特定情况，我允许模型发布评论，并标明代理代表我行事。然后我把线程延后到下周。

我尽量保持活动列表简短，把长期任务置顶。T3 Code 的 SwiftUI 版本大部分是在一个长期远程线程中完成的；因为还在等待另一人的批准，它尚未合并。让任务保持可见并不意味着它已经可以合并。

合并之前必须容易测试。针对远程机器上的文件上传修改，我请代理运行我们的 Tailscale share-dev 命令，并返回包含配对码的 URL。我们改进过打包，因为旧开发服务器在缓慢的酒店 Wi-Fi 上需要 20 至 30 分钟才能加载。

通过远程预览，我拖入一个非图片文件，检查代理能否读取保存的附件。接着我粘贴截图，验证图片路径：运行环境直接呈现像素，同时也保存文件。这些实验提高了我对特定行为的信心，不过另一项审查建议进一步拆分修改，因此我没有立即合并。

对于 iOS，我用 Swim 提供远程构建链接，再在手机上打开。它不需要 VPN，很方便，但不等同于完整签名的构建：某些分享和 AirDrop 权限受到限制。它适合外出时快速检查，并不能覆盖所有移动端行为。

只影响桌面端的修改也需要测试。我以前过度依赖网页端行为，后来发现有些认证重定向只在桌面应用中出错。我增加了 preview:mac PR 标签，触发 macOS DMG 构建并提供下载链接，方便在另一台机器测试。

我在一台基本干净的 MacBook 上测试，发现最初下载产物需要 GitHub 认证。随后另一项修改让这一用途下的预览无需登录即可下载。之后对构建签名的优化将总构建时间缩短约一分半钟；画面中 81% 的下降指的是签名调用次数，并非总构建时间。

反复出现的模式是：找到阻碍你审查、测试或合并的摩擦，再改进周边工具。这些投入让我旅行时更容易验证工作。PR 数量不能完整衡量软件质量，但降低测试所需的精力，能给我更多机会做出有依据的决定。

错误仍然会发生，尤其是我们不再逐行阅读所有代码时。T3 Code 使用一张安全网：尽管叫 nightly，构建实际上大约每三小时发布一次，供几千名主动选择该通道的用户使用。他们知道功能可能损坏，并会在稳定版发布前报告问题。这适合我们的特定用户群；它并不完美，也不适合所有项目。

其他团队可以分阶段发布，先观察一小部分用户并在出现问题时回滚，也可以设立正式 QA 团队。共同要求是在故障影响所有人之前发现并控制它。我的说法是“安全网，而不是护栏”，但我并非反对测试：我们有很多测试，也在不断增加。

降低合并风险有两个方面。审查之前，利用调查和自动反馈提高对修改值得人类关注的信心；随后让人容易亲自测试行为，并准备好在发布后发现和修复回归。这不是盲目合并，而是同时降低检查的摩擦和检查遗漏后的后果。

收件箱式的线程列表、自动审查循环、预览构建、人工检查和恢复手段共同帮助了我的团队。这些是遇到问题后改进工具的例子，不是要求每个人照搬我的配置。我预计六个月后，我工作流的某些部分会显得很傻；我也想继续学习和改变。