GitHub Copilot 为什么为智能体工作流程改变计费方式

Copilot 起初是自动补全工具，后来发展成智能体编程产品。GitHub 宣布从高级请求次数转向按使用量计算的 AI Credits，一些用户对此感到愤怒。我想解释：当智能体能持续工作数小时，一条消息的经济账为什么会改变。

我获得过大量 Azure 额度和免费的 Copilot Pro+ 订阅，因此我与 Microsoft 的关系是理解这段讨论时需要考虑的背景。我之前测试过 Azure 推理延迟，并表示团队回应后改善了问题。这些结果和我的账户用量只是我个人环境中的例子，不是通用性能基准。

录制时，我的 Pro+ 套餐有每月高级请求额度。我说自己用了不到 5%，却估算出价值数百美元的等效推理用量。该估算依赖公开 API 价格和缓存方面的假设，不能证明 Microsoft 的实际内部成本，也不是我需要支付的账单。

推理计费有多种方式。一种是带时间窗口限制的订阅：用户支付固定费用，服务限制一个会话或一周内能完成的工作量。具体额度可能难以换算成 token，也可能随供应商政策改变。

这种不确定性让变更难以理解。即使看不到底层成本，客户也会习惯某种工作方式和用量。供应商改变限额后，同一任务可能占用不同比例的额度，用户希望了解原因是合理的。

第二种方式是提供固定消息额度的订阅。T3 Chat 曾为便宜模型提供更多消息次数，为高级模型提供更少次数。另一种方式则显示以美元计的使用额度，允许额外付费；每种方式都需要权衡可预测性、透明度和成本控制。

API 计费则不同：价格通常按每百万输入和输出 token 报出，有时还会单独列出缓存输入价格。包含大文档的请求可能比简短问题昂贵得多。作为 T3 Chat 的提供方，即使客户看到的是消息额度，我也要支付推理成本。

第四种视角是专用算力。公司可以为推理工作负载预留容量，而不是按公开的每 token 价格购买每次请求；模型许可和基础设施条款各不相同。模型实验室需要管理自有或租用的容量，并决定如何分配给客户。

计费变更也会改变客户的预期。习惯固定请求次数的人，在新计量方式下可能获得更少用量，另一些人则可能获得更多。理解供应商的成本问题，并不妨碍我们承认突然变更会让客户感到沮丧。

T3 Chat 刚推出时，便宜模型让慷慨的消息额度看起来可行。后来我们加入了更贵的模型，虽然流量占比较小，成本却大幅上升。我们将普通和高级消息额度分开，并允许购买额外高级额度，作为最初的补救。

这没有解决根本问题。简短请求可能成本很低，携带大量上下文或使用工具的长请求则可能贵得多。我见过按 API 价格计算超过 10 美元的单次请求。消息是交互单位，不是固定的算力单位。

少数高用量用户的高级消息成本可能远超订阅费。如果为了覆盖最昂贵的情况而降低所有人的额度，就会影响普通短请求。我对上传大型代码库的不满反映了我作为小型服务运营者的立场；用户也可能合理地认为，公开套餐允许这种用法。

我们调整了 T3 Chat 的计费，有些客户不满，收入也因此下降。在我看来，编程智能体的成本差异更大。这里比较的不只是两个模型，而是单次回复与收到一条提示后可能多次调用模型的工作流程。

一个简单回答可能只需要调用一次模型。如果模型请求搜索，应用会执行工具、把结果加入对话，再调用模型。每次继续运行都可能增加输入和输出用量。T3 Chat 限制搜索次数，但其他智能体流程可能执行更多步骤。

这使得每条用户消息的固定价格难以代表智能体的工作量。一条提示可能很快完成，另一条则可能花数小时读取文件、运行工具和推理。实际限额与计费规则因服务而异，不能假定任何地方都允许无限长运行。

我展示了一次约 16 小时的密码谜题运行，并报告整个运行累计约 1.11 亿输入 token 和 160 万输出 token。这些是多次调用的累计数量，不是单个上下文窗口。我用假定的缓存输入价格计算，估计约为 62 美元。

提示词缓存可以复用重复前缀之前计算的状态，避免每次都按未缓存费率处理全部内容。能否命中缓存、命中率和价格都各不相同。我的估计是按 API 价格换算的等效金额，不是供应商边际成本的测量；将它推算到全部额度也只是一个假设。

长时间运行来自一个密码谜题。我喜欢让人解读线索的谜题，而不是入侵系统。我设计了一个题目并悬赏 1,000 美元，一位社区成员不到十分钟就解出了答案。我也用 AI 模型尝试这个挑战，观察它们会工作多久。

第一道谜题的第二行解码后是一条线索，指向我 Dogecoin 模拟器中的 Git 提交。我修改了一条分支的历史，放入解码第一行所需的种子。模型最终解开了谜题，但如果它能看到 gist 或知道我的 GitHub 账户，就更容易建立联系。

我还特意使用了一个不常规的 base-23 字母表作为 T3 线索。一位研究密码学的朋友不喜欢这种随意约定，这让我想到编码依赖大家约定的字母表。熟悉的字符集可能提示某种编码，但不能保证使用的映射相同。

第二道谜题中，我移除了 GitHub 线索，让下一步不那么明显地指向 JSON，并修改了编码。社区花了约十小时并需要提示；我的智能体需要更多帮助。有些提交的答案是幻觉，说明看似合理的智能体回答仍需验证。

线索指向我最早的 YouTube 视频，而看似熟悉的编码文本使用了反转的 Base64 字母表。即使解码，下一段内容也不像前一道题那样明显呈现 JSON。这是谜题设计技巧，并不是说反转编码就构成了强密码学。

随后我用谜题测试单次 Copilot 请求能触发多少工作。模型和推理设置会影响用量，而旧套餐按模型设置了不同的请求倍数。我展示的具体倍数是历史套餐规则，不应视为现行费率。

我对刻意改动过的谜题运行了许多会话，试图让它们持续工作较长时间。各次运行的输出差异很大；我报告的美元总额是依据标价和缓存假设得出的估算。它不能证明 Microsoft 实际支付了多少，也不能保证其他人能重复同样结果。

GitHub 宣布，月付套餐将转向 AI Credits，根据输入、输出和缓存 token 的消耗计量，付费套餐可以购买额外用量。最初公告为年付用户描述了不同的过渡安排。实际现行条款应查看 GitHub 后续更新和文档。

我的观点是，长时间、多步骤的智能体运行已不适合按固定请求次数计费。GitHub 自己也表示，增长的推理需求让原有模式不可持续。但我对 Microsoft 具体拥有多少容量、原本能把容量卖给谁的推断，并非经过核实的财务信息。

我强烈支持改变计量方式，但如果用户依赖的价值发生变化，或者过渡沟通不充分，客户仍有合理的反对理由。订阅价格、包含的用量、缓存折扣和服务限额都是具体产品条款，并不存在 40 美元订阅必须恰好提供 40 美元推理的普遍规则。

更广泛的教训是：比较订阅时，应看它能支持的实际工作负载，而不只是标价或消息次数。智能体让单次交互的成本变化更大。供应商需要可持续的限额和清晰沟通，用户则需要足够的信息预测对自己工作的影响。