Agent 工作流的碳计算：Token 预算现已成为 ESG 披露

无状态的聊天补全（Stateless chat completion）耗电量极低。一次中等规模的 Gemini 文本提示耗电约为 0.24 Wh；一次简短的 GPT-4o 查询约为 0.3–0.4 Wh。这些数字微乎其微，甚至没人会把它们放进董事会演示文稿里。

智能体任务（Agent task）并非普通的聊天补全。一个典型的“研究该客户并起草回复”的工作流可以扇出（Fan out）到 30 多个工具调用、10–15 次模型调用，且上下文窗口随着每一步不断增长。能源成本随调用图（Call graph）呈复合增长。当智能体返回结果时，你消耗的不是一个推理单元，而是五十到两百个。突然之间，每个任务的碳足迹便与视频流达到了同一数量级。

这种算术题很快就会在工程部门之外产生影响。欧盟的 CSRD 使范围 3（Scope 3）排放披露成为受规制公司的强制要求，并要求从 2026 年起提交机器可读的 iXBRL 报告。尽管 SEC 在其最终规则中删除了范围 3，但任何在欧盟有业务的跨国公司仍然必须回答这个问题。采购团队已经开始在供应商调查问卷中加入“你的 AI 功能每个用户任务的碳足迹是多少？”这类问题。大多数工程团队无法回答，因为从来没有人测量（Instrumented）过它。

为什么智能体工作流打破了单次查询的思维模型

媒体报道中引用的能源估算值——0.24 Wh、0.3 Wh、0.34 Wh——是来自公共聊天助手的单次查询数据。它们描述的是单次预填充（Prefill）加上简短解码（Decode），带有简短的系统提示且没有使用工具的情况。它们并不能描述你的智能体在做什么。

在这些基准之上，还有三个叠加的倍增器：

扇出（Fan-out）。 分发子任务的并行智能体各自独立累积成本。一个生成六个研究员的规划器（Planner），如果每个研究员进行四次工具调用并生成最终摘要，那么对于曾经的一个用户请求，现在已经执行了七次模型调用和二十四次检索。

上下文增长（Context growth）。 每个工具的结果都会被追加到下一次调用的上下文中。到第十步时，你正在为一个提示词支付预填充费用，而这个提示词的大小可能是初始时的 50–100 倍。预填充成本大致随输入 Token 线性增长，因此“相同的模型，相同的任务”的能源成本会在整个轨迹中不断爬升。

推理模型（Reasoning models）。 在长提示词下，推理模型与小模型之间的成本差距是巨大的。最近的基准测试测量出 o3 和 DeepSeek-R1 在长提示词下的耗电量超过 33 Wh——是相同输入下 GPT-4.1 nano 消耗量的 70 倍以上。如果你的智能体在每一步都使用长时思考模型，而不是仅在真正需要的步骤中使用，那么在工具选择之前，你就已经在碳排放争议中败下阵来。

综合这些因素，一个完整的智能体任务很可能消耗 15–60 Wh。从绝对数值来看这仍然很小，但这是一个会随流量波动的数字。如果每月有一百万个任务，你谈论的就是中型办公楼的年耗电量，这些电力来自碳强度各异的电网：从魁北克或法国的低于 50 gCO₂e/kWh，到美国南部部分地区的超过 600 gCO₂e/kWh。

报告压力已经到来

关于 SEC 范围 3 披露的政治辩论掩盖了实际交付的内容。SEC 的最终规则不要求范围 3 报告，但欧盟的 CSRD 要求这样做，而且欧盟在 2025 年底的综合修订案中并未删除范围 3 的要求——它们只是缩小了适用公司的范围，并将部分申报者的截止日期推迟到 2028 年，同时保留了实质内容。

对于数字产品，AI 推理对客户而言属于范围 3 类别 1（已购买的商品和服务），对模型供应商而言属于范围 2。这在实践中意味着两件事。首先，你的买方的合规团队将会向你索要每个用户任务的排放估算值，即使你自己的法律团队尚未标记这一点。其次，模型供应商不会为你完成你所需的细粒度到每个任务的工作。例如，Anthropic 已公开承诺实现净零抵消并吸收纳税人的电价上涨，但在最近的供应商风险披露中，尚未发布单次调用的范围 1/2/3 细分数据。OpenAI 同样含糊其辞。

这种模式对于任何在共享云账户上运行 Kubernetes 集群的人来说都很熟悉：唯一能将成本归因于特定用户任务的实体就是你。账单来自平台；归因则由你来计算。

单次调用归因：你已拥有的遥测数据

好消息是，碳排放归因所需的测量手段与成本归因所需的手段几乎完全重合。如果你已经采用了 OpenTelemetry GenAI 语义约定——gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.system——那么你已经拥有了大部分所需的数据。碳排放计算只是同一个 Span 上的又一个属性。

模型很简单：对于每次模型调用，将 Token 数乘以每 Token 能源系数，再将该能源消耗乘以数据中心所在电网的边际碳强度，并将结果附加到追踪（Trace）中。难点在于选择有据可依的系数。

对于每 Token 的能源消耗，公开基准测试显示，在生产批次大小下，现代前沿模型每输出 Token 约为 0.3–1.0 J，输入 Token 约为该值的 30–50%（预填充比解码效率更高）。较小的模型（Haiku 级、Nano 级）处于该范围的底端；而推理模型在进行长时思考时，其能耗要高出两个数量级。

对于电网碳强度，正确的输入是你推理实际运行地区的地域边际排放量（按小时采样）。云供应商的可持续性仪表板会公开这些信息；ElectricityMaps 和英国碳强度 API 以更细的粒度提供同样的信号。避免使用单一的年度平均值——它会掩盖使路由决策具有辩护价值的波动性。

你希望从流水线中输出的不是一个公司层面的足迹数字，而是一个基于每个追踪、每个用户任务的能源和碳排放估算值，该值可通过功能标记（Feature flag）、客户群体和模型等级进行查询。这能让你诚实地回答调查问卷，更重要的是，它能让你看到哪些功能正在高能耗运行。

碳预算强制带来的路由决策

一旦每个任务的碳排放数据摆在你面前，优化的语境就发生了变化。那些通常被视为成本优化的架构调整，同样也是碳排放优化，而且碳排放的视角往往能揭示出那些被悄悄冷落的优化手段。

根据任务重要性而非默认值对模型进行分层。 分层架构——即 Haiku 级别用于路由和分类，中端模型用于大部分生成，尖端推理模型则用于真正需要的场景——与将所有任务都交给尖端模型相比，通常能降低 60–70% 的总 Token 成本。碳排放的账目比成本账目更可观，因为从单 Token 的角度来看，最小的模型热效率也最高。在大多数 Agent 管线中，基于碳排放的分层路由是杠杆率最高的决策，也是大多数团队会跳过的步骤，因为他们的第一个原型通常是“万事皆用 Sonnet”。

明确限制深度思考。 推理模式的模型调用主导了任何使用它们的 Agent 的能源消耗画像。应将启用深度思考的决策视为调用付费第三方 API 一样对待：必须明确、有记录，并与置信度或任务重要性信号挂钩。“始终思考”在碳排放上等同于程序中的忙等待。

在延迟允许的情况下，对工具分发进行批量处理。 热批处理（Warm batches）比串行调用能更有效地摊销单 Token 开销。如果你的 Agent 有一个步骤需要触发 N 个独立的检索，那么一个批量的 Embedding 或重排序（Rerank）请求在成本和焦耳消耗上都比 N 个独立的请求高效得多。架构上的转变是转向“先规划，后调度”模式，而非“循环并调用”模式。

在延迟 SLO 范围内根据电网碳强度选择区域。 这是最具争议的建议，因为它听起来像是为了环保秀而进行的过度优化。但数据并不支持这种看法。即使是在你已经接受的延迟预算内，对推理负载进行适度的空间迁移，也能显著减少排放。其奏效的原因在于，不同地区的电网碳强度差异可达一个数量级，而路由到相邻区域的延迟成本通常并不会激增。在生产环境中行之有效的模式是：根据用户地理位置锁定区域（为了合规），同时在可选范围内结合碳强度感知进行选择。

积极缓存，尤其是跨会话缓存。 缓存的 Prompt 和 Embedding 不仅仅是延迟上的胜利，它们还能消除推理开销。缓存命中的边际能源成本仅为查找本身，与它所取代的预填充（Prefill）开销相比，几乎可以忽略不计。大多数 Agent 代码库中都有一两个在每个会话中都会发送且很少更改的 Prompt。这些是纯粹的碳节省，但它们通常是不可见的，因为没有人追踪那些“规避掉的成本”。

架构层面的论证

这件事现在之所以重要，并不是因为监管明天就会强制执行。而是因为在监管到来之前，可持续性约束就会影响 AI 基础设施的决策，而率先进行插桩测量的团队将掌握定义这场对话的话语权。

三种力量正在向这个方向汇聚。采购端的声音最响亮，因为财富 500 强的买家已经开始在 AI 供应商调查问卷中加入碳排放问题，与安全和隐私问题并列，而“我们不测量它”是一个会导致交易流产的负面回答。投资者紧随其后，因为带有 ESG 标签的基金需要其投资组合公司提供可归因的“范围 3”（Scope 3）排放数据，而“AI 在范围内但未测量”会被视为模型风险。内部产品策略是最安静但影响最深远的：当你能展示每个功能的碳排放数据时，关于哪些功能值得保留的讨论就会发生质变。

插桩的成本很小。属性归因需要单次调用的遥测数据，而大多数团队为了追踪成本已经在收集这些数据了。能源系数是公开的，并且随着 TokenPowerBench 等基准测试的成熟而变得更加准确。电网碳信号已经由每个主要的云厂商公开。大多数 Agent 代码库中缺失的是连接代码——即那部分将 Token 数量与能源系数、区域碳强度联系起来，并将结果写回追踪记录的代码。

率先构建这种连接器的团队赢的不是可持续发展奖。他们赢得的是当被问及（这种情况正越来越多地发生在掌握合同签署权的决策者身上）相关问题时能够给出答案的能力。他们还获得了一个促使 Token 效率与成本效率趋同的强制函数，这意味着这项工作甚至在第一份 ESG 报告出炉前就能体现其价值。

Token 预算曾经是一个财务问题。它正在变成一项披露项。工程界的反应应与之前对待成本、延迟和可靠性时一致：对调用图进行插桩，将消耗归因于用户任务，并将数据放在产品决策者能看到的地方。剩下的自然会水到渠成。