按人类节奏定价的订阅，遇上不按人类节奏干活的 agent

8 月 11 日，Capy 的联合创始人 Justin Sun 在 X 上宣布了 V2。Capy 是 YC 2024 年秋季批次的公司，六个人，在旧金山，做的是编码 agent。官网首页的说法是「Orchestrate a fleet of cloud coding agents in all of the apps your team already lives in」，在团队已经在用的那些应用里，调度一队跑在云端的编码 agent。官网称有 7 万名工程师在用，这是公司口径，没有第三方数据。 现在的 Capy 接在 Slack、GitHub 和 Linear 上。agent 可以由事件自动启动，可以把一个需求拆给几个子 agent 并行去做，PR 开出来以后还可以交给 review agent 审，每个 agent 有自己的云端机器。 Capy 的定价页上，Pro 和 Max 档写着「Use ChatGPT, Copilot, and SuperGrok subscriptions」，用户可以把自己已经付费的订阅接进来，用订阅的额度跑这些 agent。这几份订阅按人按月收费，价格对应的是一个人一个月的用量。Capy 的 agent 什么时候开工、同时开几个，很大程度上取决于代码库里发生了哪些事件。 现有工具的用法 Claude Code、Codex、Cursor 这一代编码工具，最常见的用法是开一个 session，人提需求，工具改代码，人再检查。它们也在往云端和异步走，任务可以在人离开之后接着跑，但一个任务通常由人发起，工具负责的主要是写代码这一步。 一个问题从出现到解决，前面要有人报告，可能是 Linear 上的一条 issue、Sentry 的一条告警，或者 Slack 里的一句话，再有人判断是什么问题、该谁处理、有多急；后面要有人开 PR、review、跑测试、合并。每次交接要等下一个人接手。写代码变快以后，从报告问题到合并的总时长里，等待所占的比例会更大。 速度测不准 AI 编码工具提升了多少效率，目前主要靠使用者自己的感觉回答。METR 2025 年 7 月发布的随机对照实验里，16 名有经验的开源开发者做了 246 个真实任务，允许用 AI 的那组实际慢了 19%，他们事后自估快了 20%。实验规模不大，结论未必适用于所有场景。这个实验我在写工程度量的那篇里讨论过。 GitHub 和 Linear 会记下 issue 的创建和认领时间、PR 的打开时间和第一条 review 的时间，每一段等了多久可以直接算出来。Capy 的主要功能作用在这几段时间上。 任务改由事件发起