Claude Code 深度功能评测与实战指南

Claude Code Unleashed

在开发 Terragon 的过程中，过去两个月我一直在痴迷地自测背景 agent。这迅速演变成了一次让 Claude Code 摆脱本地开发约束的实验。

这个突破不仅仅是用 AI 来更快地写代码。而是意识到了当你能够做到以下几点时会发生什么：

轻松启动新的 agent

让这些 agent 脱离你的本地机器运行

同时运行无限数量的 agent

我采用了混合的方法，想分享和记录我学到的东西。我确信这会随着时间的推移而不断演变和改进。

Claude Code & Claude Max

如果你还没有试过 Claude Code，那你可就错过了。几乎每次关于 Claude Code 的讨论都是在说它有多好或者有多贵。

据我所知，仅仅对 Claude Code 说"Hello"就要花 $0.30！

一旦你深入了解 Claude Code 的成本，你就不可避免地会听说"Claude Max"——这是 Anthropic 的订阅服务，你按月支付一定金额来换取使用额度。如果你支付 $200/月的套餐，你实际上获得了无限使用权。仍然有速率限制，但非常宽松。

在我没有 Claude Max 订阅的情况下，一个典型的日子里我本来要花近 $100。所以从某种奇怪的角度来说，Claude Max 其实很便宜！（这恰好也是人们对 Claude Code 的另一个常见话题。）

我强烈推荐获得 Claude Max 订阅。不用担心速率限制、单次使用成本、是该用 Sonnet 还是 Opus，这真的改变了游戏规则。有了 Max，我停止了以"这是一个适合 Claude Code 的任务吗？这是 Sonnet 还是 Opus 的任务？"这样的方式思考。取而代之的是"我怎样才能把更多的工作转移给 Claude Code？"仅仅这个思维转变就值回票价。

我怎样才能同时运行多个 agent？

一旦你开始拥抱 Claude Code，你会很快想要同时运行多个 agent。Claude Code 之所以这么棒的部分原因在于它花时间理解代码库和手头任务的背景。如果你真的在看着它编码，这会很令人沮丧且耗时。

按照官方文档的建议，我开始使用多个 git worktree 来并行化 agent。这对于快速更改很不错，但一旦你尝试并行运行超过两个 agent，管理开销就变得非常痛苦。

你无法避免地感到自己在不断地玩杂耍：

我在哪个分支上？

这个标签页是什么来着？

这个改动的背景是什么？

哪个 IDE 窗口对应这个 worktree？

与其感到更有效率，你开始感到自己在同时做太多事情，什么都做得不好。

大多数项目也共享像 Docker 容器这样的全局资源，所以在多个 worktree 中同时运行测试/开发环境会很痛苦，或者需要更多的设置。

随着我使用 Claude Code 越来越多，我也开始在非 --dangerously-skip-permissions 模式下感到烦恼。我明白你的意图。你可能不想让 agent 无脑地在你本地机器上运行 rm -rf，但很多时候，我会以为 agent 在工作，结果发现它在等我批准一个简单的 find 命令。是的，请运行 find 命令，别再问我了。

Terragon 是我们正在构建的产品，它解决了在不让人发疯的情况下管理多个 Claude Code agent 的问题。它在云中运行 Claude Code。你给它一个任务，它处理它，然后创建一个 PR。它可以在你睡觉时、出门时或者你给它分配更多任务时执行。

对于每个任务，Terry 都会启动一个全新的环境，克隆仓库，创建一个分支，然后开始工作。部分魔力在于任务创建变得如此便宜和无缝，你可以简单地专注于手头的任务。

一个难以复现的 bug？让 Terry 去调查它

一个新的功能想法？让 Terry 去原型化它

代码清理的想法？让 Terry 去做

我目前的工作流是本地 agent 和 Terragon 上背景 agent 的组合。在过去的一周里，我平均每天在 Terragon 上运行约 30 个任务。本地上，我经常在测试和完成由背景 agent 启动的任务。

Terragon 上发生的事

几乎每个任务都从这里开始

审查改动，测试，对现有 PR 的小调整

完成和测试由背景 agent 完成的工作

为背景 agent 启动脚手架（我会创建一些 TODO，推送它们，然后要求一个 agent 完成它）

不适合背景 agent 处理的任务（例如，需要大量来回互动，我发现 agent 不太擅长的事情）

我发现背景 agent 在以下任务和用例中表现突出：

探索任务："原型化这个方法，这样我可以快速看一下。"有时我从不合并这些。我只是像读工程提案一样读它们，来为我的下一个提示/思考如何处理这个更大的任务提供信息。

一次性任务：简单的清理工作。例如，删除特性标记、修复小 bug、添加测试覆盖、改变测试过的行为。

样板代码繁重的任务：要么在我创建的脚手架基础上构建，要么遵循代码库中建立的模式。例如，agent 非常擅长创建内部页面。

背景复杂的调试："你能调查这个 bug 报告吗，其中用户遇到了...？"背景 agent 在这里表现出色，因为调查涉及阅读大量代码，但修复通常只需要几行。

一旦你采用了背景 agent 密集的工作流，你会注意到花在任务间切换上的时间要多得多。与其一次做一件事，你在同时做多件事。如果你不小心或没有建立一个良好的系统，你实际上最终会做更差的工作并完成更少的事情。

我发现成功的关键在于有一个好的系统来管理你的任务。当然，如前所述，你需要在如何花费时间上有纪律和判断力。仅仅因为你可以为 agent 发出 100 个任务，并不意味着这是时间的最佳利用。

我通过为一整天发出一堆任务来开始我的早晨。有时我在我的通勤中用我的手机用语音来记录任务。这是一天中最重要的部分，因为我有效地在决定我将如何花费一整天的时间。

整个白天，我花了大部分时间"清理"这些任务和审查 agent 的工作。在 Terragon 上，我们有一个 Terry CLI，可以轻松拉下远程环境和对话，以继续在本地测试和审查改动。

在一天结束时，我经常会有"收件箱零"任务。早上和全天创建的大多数任务都会被合并或关闭。Terragon 仪表板是我如何跟踪一天剩余工作的方式。

一些有趣的例子

痴迷地自测 Terragon 真的很有趣！这里有一些给我留下深刻印象的事情：

我们在 Terragon 中有一个竞态条件，其中错误消息会意外出现。Terragon 是一个分布式系统，所以这是那种烦人的 bug，很难诊断，问题也不明确。没有期待太多，我给 Terry 一个 bug 的描述，它一次性识别了问题并修复了它。大部分工作是识别 bug，这需要阅读大量代码——正好是 agent 擅长的。

大约一半的时候，用户 bug 报告由 Terry 立即获得"第一次通过"。即使实现不是我们会合并或完美的，它通常也会显著推动事情发展。例如，它的思考过程让你更深入地了解问题和解决方案。

我一直在使用 Terragon 以递增的方式原型化新功能和想法。对于有分量的功能，我经常会要求 Terry 以增加的具体性原型化任务，从一个我想要构建的内容的模糊描述开始。对于每次尝试，我阅读它的输出，以更多地了解我想要解决的问题和我想要实现的解决方案。大多数这些任务从不合并，但它们是一个很好的方式来了解某事如何工作或在我实际开始构建它之前可能出现的问题。

我到目前为止学到的东西

以下是我到目前为止通过采用这个工作流学到的一些东西：

了解模型。 它擅长什么？它不擅长什么？这需要时间和实验。agent 既聪慧又愚蠢。

学会放弃。 如果一个 agent 走错了路，最好是放弃任务并用不同的指令重试，而不是一直说"那是错的"或试图纠正。

管理多个 agent 需要大量的背景切换。 这不是正常的！你突然在追踪 10 多个并发工作流，而不是 1-2 个。但你在更短的时间内做了更多的事情。

你不需要为每个任务都使用 agent。 有时最好是自己做。这回到了"了解模型"的想法。你会开始理解 agent 擅长什么和不擅长什么。

我真的对背景 agent 如何演变感到兴奋和内在好奇。老实说现在判断事情会如何发展还为时过早，但我相信我们未来会看到更多的背景 agent。

使用 Terragon 从根本上改变了我对如何分解工作的思考方式。我在创建更小、更 agent 友好的任务。我更愿意探索想法，因为成本这么低。我在花费更多的时间在开发的实际需要人类判断的部分。我无法想象回到纯本地的设置。在保持专注的本地环境的同时跨多个 agent 并行化工作的能力已经改变了一切。

---