技术深度解析
当前AI能耗指标的核心问题在于其计量单位。每次推理成本（如$/1M tokens）是一个硬件层面的指标，它抽象掉了任务执行的复杂性。对于单轮问答，这尚可接受；但对于智能体系统，则完全不够。
一个智能体工作流，例如“预订下周一至周三去东京的商务旅行”，涉及一个复杂的非线性执行图：
1. 规划： 智能体将目标分解为子任务（航班搜索、酒店搜索、日历检查）。
2. 工具调用： 它向航班聚合器、酒店预订网站和日历服务发出API调用。
3. 推理与重新规划： 如果第一个航班选项不可用，智能体必须重新查询、重新排序并重新规划。
4. 错误恢复： 失败的API调用需要使用不同参数重试或回退到辅助服务。
5. 验证： 智能体必须验证预订的航班和酒店是否兼容（例如，到达时间与入住时间）。
每一步都涉及一次或多次模型推理。一个朴素的系统可能需要50次推理才能成功。一个优化良好的系统可能只需要10次。每次推理指标会惩罚第一个系统“浪费”，但如果第二个系统有40%的失败率（需要重新运行），其“成功目标能耗”（EPSG）反而可能更高。
EPSG框架
EPSG公式非常直接：
EPSG =（智能体系统消耗的总能量）/（成功完成的任务数）
这包括：
- 所有模型推理的能量（包括失败的尝试）。
- API调用和工具执行的能量。
- 记忆检索和状态管理的能量。
- 错误恢复和重试逻辑的能量。
这迫使关注点转向系统级效率而非组件级效率。一个关键的技术杠杆是智能体记忆。能够缓存成功子任务计划（例如，“这个航班搜索模式上次成功了”）的系统，可以大幅减少未来类似任务所需的推理次数。开源仓库MemGPT（现更名为Letta，约20k星标）正在通过为智能体提供跨会话持久化的虚拟上下文窗口来开创这一领域，使其能够从过去的成功和失败中学习。
另一个关键领域是工具编排。智能体调用外部API的方式是一个主要的能量消耗点。设计不佳的智能体可能使用过于宽泛的参数调用航班API，收到大量响应，然后使用另一次推理来过滤。更好的设计采用结构化工具调用方法（如OpenAI的function calling或Anthropic的tool use），模型直接输出一个JSON对象，用精确参数查询API。这既降低了推理成本，也降低了API数据传输成本。
EPSG基准测试
当前的基准测试如GAIA或WebArena衡量任务成功率，但不衡量能耗成本。我们需要新一代的基准测试。下表展示了两种智能体架构在同一任务上的假设性对比：
| 智能体架构 | 每任务平均推理次数 | 任务成功率 | 总能耗（估计焦耳） | EPSG（每成功焦耳数） |
|---|---|---|---|---|
| 朴素ReAct（无记忆） | 45 | 75% | 900 | 1200 |
| 优化ReAct（带记忆+结构化工具） | 12 | 95% | 240 | 252.6 |
数据要点： 优化架构每任务使用的推理次数减少了79%，但更重要的是，其EPSG降低了79%。朴素系统的低成功率放大了其能量浪费。这表明仅优化推理次数是不够的；成功率是能量效率的倍增器。
关键玩家与案例研究
已有数家公司和开源项目在有意或无意地采纳EPSG思维。
LangChain（LangChain Inc.）
LangChain的框架提供了`AgentExecutor`和`Toolkits`等抽象，这些抽象天然地追踪任务完成情况。他们最近对LangGraph（一个用于构建有状态、多参与者智能体的库）的关注，是对管理复杂多步骤工作流需求的直接回应。LangChain的`callbacks`系统允许开发者记录每一步，包括失败和重试，从而可以计算EPSG。他们还在推动基于轨迹的评估而非单一输出评估，这与EPSG理念一致。
AutoGPT（Significant Gravitas）
最初的AutoGPT项目展示了自主智能体的强大能力，也暴露了其能量低效。早期版本会陷入循环，进行数百次API调用却无法完成任务。社区向约束型智能体（使用`forks`和`pinned memories`）的演进，实际上默认了原始推理次数并非目标。最新版本的AutoGPT强调任务分解和进度追踪，这对EPSG优化至关重要。
CrewAI
CrewAI的多智能体框架