Theo 的并行编程代理实践指南

点击视频时，你已经有多少个代理任务在运行？我认为许多开发者错过了同时处理多个问题的机会。我的方法刻意追求高强度，这些例子是为了展示我的思路，并不是要所有人照搬的公式。

我和朋友使用许多账号，我遇到的封禁是暂时的。这只是我的经历，不能保证其他账号也如此。后面我会明确承认，这套配置可能违反服务条款，也可能导致封号。

内容安排很简单：获取和使用 token，合理利用它们，尝试一些看似不那么高效的任务，以及在睡觉时让工作继续。比起我具体用了多少任务或账号，更重要的是这些实际例子。

我预计有人会质疑，这只适合业余项目，或者成本太高。我认为大公司的员工也在使用其中一些方法，但这些例子和数字来自我的个人经验，并非独立调查。

先比较订阅和直接购买 API 用量。按我的估算，200 美元的 Claude 订阅可以获得按 API 价格计算约值 8000 美元的用量；按照我描述的限制，其中约一半属于 Fable 类别。这是按 API 价格换算的估计值，不是现金余额，也不是保证额度。

对我的使用方式来说，100 美元套餐的短周期限制更严格，所以吸引力较低。我还估计，200 美元的 Codex 订阅大约相当于 12000 美元的 API 推理费用。实际价值取决于用量、模型、限制和当时适用的条款。

我推测了模型价格和服务商利润率，包括引用外部估计粗算出约 95% 的利润率。这些只是对成本和定价策略的猜测，不是经证实的财务结果。我的观点是，价差让订阅对开发工作有吸引力。

我还提到过去 Codex 的用量重置，认为它增加了自己账号的实际可用容量。重置政策和订阅供应会变化；不能把过去的重置频率当作承诺。

我建议检查个人账号的数据控制设置。我还声称，关闭模型训练后个人套餐和团队套餐的条款实际上相同。但仅凭这个设置不能得出这一结论：协议、数据保留等保障可能不同，仍需另行查阅当前条款。

我区分了个人开发和面向公众用户提供服务，并认为后者应使用 API，而非供个人使用的订阅。接着我讨论购买更多订阅，同时在后面承认自己的部分配置可能违反规则。

机器和账号多了以后，我发现手动切换认证很麻烦。我介绍了一个集中管理访问并显示用量的代理，以及为什么自己选择通过家庭网络连接其他机器。这些只是我的配置细节，不能证明服务商允许这种用法或不会采取措施。

后面补充的一点很重要：这样做可能导致封号，也可能违反服务条款。我自己账号的经历不能证明别人也安全；特定网络地址或代理都不能保证结果。

我还比较了模型服务商直接提供的订阅和其他产品的套餐。我对这些公司拿到多少折扣的估计属于推测。价格和供应情况会随时间变化，比较结果也取决于具体模型和使用量。

在原始讨论之后录制的补充中，我说 Claude Opus 5.5 改变了我的工作方式：许多人用一个订阅就可能完成足够多的工作，也许根本不需要多个账号或代理。理解后面的演示时，这一点很重要。

面板展示了用量窗口和重置日期。我讨论如何根据限制何时重置来选择账号，以及如何追踪用量。这些机制描述的是录制时可见的产品和账号状态，不是永久不变的时间表。

会话亲和性会影响效率：任务继续使用同一个账号时，原有提示缓存可能可以复用。切换账号可能需要重新写入缓存，因此我建议观察缓存读写量，不要假定切换路由没有成本。

我的机器通过私有 Tailscale 网络访问代理。我说自己的配置依赖网络边界，而没有使用 API key。网络访问控制并不能普遍替代认证，也不能保证隔离；部署的安全性取决于具体配置和设备。

我维护一个机器管理仓库，记录每台机器需要的工具和设置。添加新机器时，我让代理按照这些说明完成配置。更大的思路是让环境配置可重复，同时仍需审查访问权限和审批决定。

至少在演示中的例子里，我使用的服务对重置的处理方式也不相同。我解释即时重置或储存的重置机会如何影响下一次每周额度恢复，以及临近正常重置时额外重置为何会改变我的使用安排。

我把重置时未用完的容量称为损失的钱。这是一种激励自己的比喻，并非真的损失了现金，也不是可以提取的余额。更多用量是否有价值，取决于工作本身是否值得做；服务商也可能调整限制。

手部受伤改变了我使用电脑的方式：打字和切换应用不再像以前那么容易，我也不想坐着盯代理逐字生成。我会问自己，代理能多早开始帮忙，以及它能工作多久才需要我再次查看。

想想合并按钮的两侧。合并前，给代理足够的工具和时间去测试、审查并修复问题。我估计自己用于验证的 token 远多于写代码，因为我希望变更准备充分，便于人做出有意义的决定。

合并后，要让故障容易发现，让回滚成本足够低。我建议，如果团队无法迅速撤销错误变更，就应在加快节奏前改善这套系统。自动检查能降低风险，但不能证明变更安全；出问题时仍需要可靠的恢复手段。

合并之前还有一个阶段：弄清楚自己想要什么。以前我会先想完整个方案，再找代理帮忙。现在我尝试在刚遇到问题时就让它参与，看看能否一起找到我忽略的简单方法。

我不是说不要思考，而是说要决定注意力该放在哪里。过早把自己的方案交给代理，它可能忠实地实现一个错误想法；先交代问题，有时能避免这段弯路。

一个具体例子是有人发截图报告 T3 Code 的 bug。我可以先提供截图并要求修复，而不是立即规定修改步骤。如果结果失败或没有解决真正的问题，我就知道需要更深入地调查和引导。

这让我想到做管理时学到的事：把有意思的问题交给团队，当最初的答案暴露出困难或新情况时再介入。我希望代理从收到问题开始，一直参与到形成可审查的拉取请求；我则继续与用户沟通并处理运维问题。

我把这叫作扩展思考，而不是外包思考。代理可以调查、测试并等待审查，我则开始处理另一个任务。工作准备好后，我再回来评估，不必全程盯着长任务。

这带来了协调问题：怎样同时跟踪这么多任务？我演示了自己参与开发的 T3 Code，并主张把任务看作待办事项，而不是每条都要不断回看的历史记录。

在演示中，处理完的任务可以标记为 settle，从活动侧边栏中移走，形成类似收件箱的视图。它没有消除上下文切换的成本，但能让完成或等待决策的任务更容易被看到。

演示一个新功能时，我描述了简单的消息队列：消息可以等待发送，也可以选择立即引导代理。我附上示例，并选择一台在我合上笔记本后仍能运行的机器。只要 Git 的 origin 相同，界面就会把不同机器上的仓库归在一起。

另一个例子从设备连接页面的截图开始。我解释断开连接的含义不够清楚，而移除设备应明确标为永久操作。代理拿到的是问题和可能的方向，而不是一份固定的实现步骤。

我还告诉它遇到不确定性时怎么办：如果方案足够简单，就直接实现并返回截图；否则做几个 HTML 原型，让我们一起选择。这样既给它继续工作的空间，也保留了人工决策的机会。

后台发送快捷键让我启动一个任务后留在原处，继续发起下一个。我通常等到任务完成或需要输入时才查看。演示中，T3 Code 还提供在已连接机器之间自动分配任务的功能。

代理可以并行工作，但我自己的注意力有限。设计任务时要考虑：如何提供足够完整的信息，让它不必每一步都打断我，同时在准备好后呈现我需要的信息。

对于按段落流式输出的功能，我先问实现是否困难。答案看起来可行后，我让代理实现、提交拉取请求，并启动一个供我试用的环境。把这些步骤一次交代清楚，可以减少反复回来要求下一步的次数。

接着我让代理监控拉取请求。我希望下次打开时，代码、可用的预览和检查结果都已准备好。我也提到满足条件后自动合并，但这只适用于明确的条件、权限和审查要求确实允许的情况。

并行修改可能互相冲突。T3 Code 默认给新任务创建独立的 Git worktree，有助于隔离工作目录。但它并不完美：例如，Git 通常不允许两个 worktree 同时检出同一分支，所以第二个审查任务可能需要另一个分支或克隆。

对于想以后再看的任务，我会暂时搁置；对于不再需要的工作，我会标记完成或归档。侧边栏淡化运行中的任务，让已完成和等待输入的任务更醒目。这样做是为了减少注意力竞争，并不意味着上下文切换消失了。

我更喜欢等代理完成后再检查结果，而不是一直盯着它。如果失败，我可以查看推理过程或询问原因。我也否定了一位观众对恶意软件的担忧，但代理的输出和工具操作确实可能引入安全风险，仍需要适当审查。

接下来是更开放的用途：让代理解释难读的拉取请求、总结队友的工作，或找出被遗忘但值得关注的事项。这些方法可以帮助探索和梳理，结果仍然需要用户判断。

我还提到让助手搜索邮件、收集我自己的医疗记录，同时运行其他任务。这些例子依赖用户授予代理的访问权限，也涉及敏感信息；实际选择工具和权限时需要认真考虑。

我希望一个侧边栏能展示不同机器上的工作，并区分进行中和已完成的任务。在演示中，任务运行于多台电脑，却显示在同一界面和我的手机上。我介绍的是当时 T3 Code 的连接方式。

我展示如何连接另一台机器，并表示这个项目免费且开源。我还建议让代理帮助准备新服务器。这个例子说明了可重复配置的价值，但远程访问和代理凭据仍需要适当控制。

试着提出一些看似有点傻的问题。有剩余额度时，我曾让代理检查我的 GitHub 项目和本机未完成的工作，找出现在可能值得重启的想法，并建议优先事项。它给出了几个供我考虑的候选项目。

决定如何处理结果后，我可以归档任务，也可以提出后续要求。另一个任务中，我要求汇报状态、提交拉取请求并持续监控；对于一个旧任务，我则问拉取请求做了什么，以及为什么值得合并。

有一天晚上，我同时运行了十几个任务。第二天我逐一查看，决定是合并、继续跟进还是丢弃结果。我把这个过程看作处理收件箱，但实际决定仍由我来做。

有些任务只需几分钟，有些则长得多。我建议用剩余容量尝试探索性工作，例如梳理旧拉取请求，因为结果可能找回我已经忘记的东西。消耗更多额度本身并不能证明工作创造了价值。

最后一个话题是离开时让工作继续。如果代理运行在一台常开的机器上，开会时合上笔记本或晚上睡觉都不必让任务停止。我倾向于使用一台其他设备可以访问的小型远程电脑。

为了降低起步成本，我建议找一台大约有四个核心和 8 GB 内存的旧笔记本或台式机。这只是一个起点，并非通用要求：合适的机器取决于构建、测试、并发进程数和其他资源需求。

我强烈主张购买小机器而非租服务器，并用特定月租和硬件价格举例。但经济性取决于具体情况：租用和购买价格、电费、管理成本以及工作负载都会影响比较。我关于云服务器 IP 导致封号的说法也不能视为保证。

在自己的服务器上，我展示了多个任务运行时的资源监视器，并指出那一刻 CPU 利用率很低。模型推理在远端进行，所以本机是在协调工作，而不是执行推理。单次快照不能代表所有开发任务的资源需求。

我更喜欢用 Linux 处理并行工作，也谈到自己在 macOS 上遇到的问题。实际体验可能因硬件、文件系统、操作系统和项目而异。如果多个代理同时启动昂贵的本地构建，小机器仍可能达到资源上限。

对于 Rust 构建等资源密集型任务，我建议把 CI 移到其他地方，或排队执行，避免多个编译同时耗尽一台机器。最佳安排取决于瓶颈；一位同事把 CI 移出本机后，内存压力就减轻了。

我知道有些工程师觉得这种方式令人沮丧：代理会犯错，盯着它工作可能感觉比自己写代码还慢。我也依然会遇到失败。我的变化是让任务运行时去做别的事，等有结果后再回来评估。

我喜欢的是工作周围出现的新工程问题：安排 CI、理解机器资源，以及在不逐刻监督的情况下协调多个任务。我希望这些例子能帮助大家找到自己觉得有用、也有乐趣的代理工作方式。

一位同事告诉我，远程运行任务也让她更享受这种工作方式。最后我鼓励大家做实验，并表示以后可以另谈长期经济问题。这些例子只是我当时工作方式的快照，并非预测当前价格或限制会一直持续。