Theo 谈智能体工作流、用量限额与更多创造

我大量使用 Fable，以至于影响了睡眠和视频更新计划。录制时，我预计某些 Claude 订阅中的访问即将结束，因此想在窗口关闭前试试模型能做什么。这里讨论的可用性和套餐条款都属于当时的情况。

我估计，最近在笔记本和 Mac mini 上使用的推理，按测算价格计算价值数千美元。这是用量价值估算，不等于我实际省下的钱，也不代表其他人的套餐。我这次讨论的是探索宽裕的限额，而不是最大化每个 token 的有效产出。

我介绍自己账号当时看到的五小时会话窗口和单独的每周限额。我尝试提前启动会话窗口，并定时发送小请求，让它尽早重置。这只是我自己设置的快照；限额、产品行为和允许的使用方式都可能变化。

我在 Mac mini 上用 Hermes Agent 执行定时任务，也谈到在两个 Claude 账号之间切换。我提醒说，桌面应用的会话历史没有像我预期的那样随账号切换保留。我的切换经历不能保证工作流总能恢复，也不能说明所有使用方式都获允许。

一个更有用的例子是 Lakebed 的文件存储方案。35、37 和 39 三个 PR 用不同方式实现类似功能。我让智能体比较前两个实现并综合出第三个，但在决定合并什么之前，仍希望进行更充分的独立审查。

我要求工作流安排独立评审审查每个 PR、比较方案，并找出值得保留的部分。生成的流程包括审计、评判、验证、提取和综合。这是一种为决策收集证据的方式，并不能证明选出的实现正确。

并行会很快消耗用量。在我的演示中，八个智能体同时运行，工作流很快累积了几十万个 token。这也说明大型工作流不能顺利恢复时，触及限额可能带来中断。

我在一个账号上观察到五小时限额和每周限额之间的大致关系，但这只是个人的简单测试，并非官方保证。我当时想在短暂窗口内使用剩余额度；这种策略对其他人未必经济或有用。

我维护多个仓库，T3 Code 收到的 issue 和 PR 多到我难以逐一阅读。我让智能体生成一个排序队列，突出有价值、阻力较小的变更并说明下一步。一位队友看到列表后，很快合并了其中一个小修复。

我托管智能体生成的 HTML 计划，让团队和我可以在浏览器或手机上阅读。我也可以把审查链接交给另一个智能体，让它落实有用的反馈并解释不同意见。可读的产物让人与智能体之间传递上下文更容易。

现有技能可以提出审查和改进项目的方法。我会记录以后想处理的任务和提示，但技能的指令与来源仍需要评估。自动审查可以提出问题；建议变成变更前仍应核实。

这也有个人代价：等待智能体的下一个结果，可能让我在桌前待得比计划久得多。我不敢说自己解决了这个问题。把工作放在另一台 Mac mini 上，可以让我合上笔记本而不中断长任务，但这不会自动消除不断查看的冲动。

我通过 SSH、Tailscale 和 macOS 屏幕共享访问远程机器，也展示了 T3 Code 的远程访问。不同工具和配置可以达到类似效果。对我来说，好处是可以让探索任务继续运行，而不必让笔记本一直打开。

智能体可以互相审查工作、关注 PR 反馈，或者使用浏览器测试变更。我提到 Peter Steinberger 的例子：协调器定期唤醒并将工作分配到不同会话。这些交接可以减少手动工作，但结果仍需要适当的人类判断和验证。

我鼓励更大胆的实验：让智能体验证计划、探索较大的实现、调试问题或使用浏览器。当强模型协调多个子智能体时，为合适的子任务选择较便宜的模型可以减少用量。仅仅消耗更多 token 不会让答案自动变好。

我认为开发者可以借助这些工具生成更多代码，但我也承认，他们未必能验证所有代码是否足够好、是否值得发布。目标应该是解决更多问题，而不是写出更多代码，或因为担心失业而使用工具。

当我带着好奇心使用智能体时，我构建了定制云平台、有用的包，以及按自己需求调整的软件。这些是我的个人经历，并不能保证每个人都会得到相同结果。我希望大家降低尝试想法的门槛，并更大胆地推进它们。

如果智能体遇到困难，可以检查历史和工具调用、询问出了什么问题，并在有帮助时增加指导或验证。继续实验，但不要过度依赖某一个模型或工具。安排好工作后，我打算补觉。