围绕 AI Coding，业界早期的关注点集中在“模型能否写代码”这一问题。目前，该问题已有明确答案。本文主要介绍两个问题：能不能规模化，以及能不能低成本地规模化。
在 Agent 研发过程中，我们重点关注两项核心指标：其一是质量，即能否完成预设目标；其二是效率，即完成该目标所需消耗的 token 规模。据此，本文将系统介绍如何借助智能体观测与优化平台 AgentLoop，在不牺牲质量的前提下，对 AI Coding 的 token 成本进行科学、系统的优化。
Agent 进入落地之年
在讨论降本之前，有必要先梳理整体技术趋势，明确当前技术所处的阶段，再讨论其与业务结合的路径。
回溯来看：2022 年 ChatGPT 兴起之后，行业产品形态长期停留在“Chat”层面，即一问一答。彼时企业内的典型应用以 RAG 类为主——将企业语料构建为知识库，支撑问答场景；更复杂的任务则依赖预先编排的 Workflow。这是此前两年的主流技术形态。
自去年起，技术进入快速迭代期，去年也因此被称为“Agent 元年”：Claude Code、Manus 等典型 Agent 的质量持续提升；头部模型厂商显著增强了模型的指令遵循能力，模型在调用工具时能够准确识别目标工具与参数。此前即便编写大量 prompt，模型也常常不予遵循；指令遵循能力的突破，构成了 Agent 应用落地的临界点。
其中有两个分水岭值得记录：一是 Manus 的发布，激活了市场对 Agent 的整体预期；二是今年元旦前后，一款被用户昵称为“小龙虾”的个人 Agent 产品迅速走红，其 star 曲线于 1 月 22 日前后陡增，标志着 Agent 开发在市场层面的普及。
进入今年，模型质量步入平台期：新一代模型之间的差距收窄，不再保持去年那样陡峭的提升曲线，行业趋势趋于平缓与成熟。据此判断：今年是 Agent 在企业内的落地之年。单条指令之下，Agent 已可执行数十乃至上百步操作，完成高度复杂的任务。尽管仍有新的长期技术在探索之中，但就当前而言，Agent 已能支撑大量实际业务。
在众多 Agent 场景中，AI Coding 尤为特殊：代码，是最早跑通“理解—行动—反馈—纠错”闭环的通用 Agent 场景。Chat 范式依靠 SFT + 人类偏好对齐，使模型“会理解、会说”；AI Coding 则依靠可验证奖励 + 强化学习 + Agent Loop，使模型“会行动、会纠错”——调用工具、修改与测试代码、长周期探索、反思并自动修复。因此，AI Coding 的突破不仅在于模型更擅长编写代码，更在于第一次将 Agent 的行动闭环规模化跑通。企业 AI 也正由预先编排的 Workflow，逐步走向目标驱动的 Agentic System。
对当前市场，可作如下划分：
- 通用 AI Coding 场景：头部基模厂商已将该类场景训练得较为成熟，质量到达帕累托曲线的平缓区，进一步提升的边际难度很高，但现有水平已足以支撑企业内使用。该类场景的核心关注点应转向效率，即降低单位产出的成本；
- 企业私域业务场景：模型对企业私域领域知识的掌握尚不充分，质量仍需持续调优，效率同样需要优化。
降本需求并非 coding 场景独有，业务场景同样普遍存在。
新瓶颈：一组反直觉的数字
首先看质量侧的行业数据：SWE-bench 解决率由去年的 15% 提升至 70% 以上，代码生成采纳率由 20% 提升至 65%，单次 Edit 成功率同比翻倍。模型已从“代码补全”走向“仓库级任务执行”，使用意愿与任务范围同步扩大。质量已跨过可用阈值。
但效率治理未能同步跟进。内部统计数据显示：单一部门每周即消耗数千亿 token、数百万次模型调用。对这些数据进一步分析，可以发现显著的浪费：
- “思考税”占比 64.6%：输出小于 500 token 的短决策步骤占近三分之二；
- 零产出 Session 占 12.4%：无任何产出，平均仍空转 112 步；
- 模型 Output 仅占总 token 的 0.35%。
最后一项数据尤为反直觉：大量 token 并未消耗在模型产出上，主要成本在于上下文携带、工具输出与决策路径。
第二个反直觉的发现与 Cache 相关。推理侧通常追求较高的 KV cache 命中率以降低时延；但在真实场景中，过高的 cache 命中率，往往意味着上下文长期携带着庞大的内容，并不经济。应追求的不是极高的 cache，而是合理的 cache。以一个 Codex 会话为例：若持续追问、上下文不断堆叠，其中相当一部分内容已不再需要，此时应在上下文达到合理区间后主动执行一次 compact，精简冗余内容。
对此阶段可概括为一句话：质量提升决定 AI Coding 能不能用；观测和降本决定其能不能规模化。
数据飞轮：一条可验证的降本路径
为系统性提升效率，AgentLoop 构建了一条数据飞轮：采集 → 观测 → 评估 → 归因 → 调优 → 实验发布。各环节环环相扣，每一轮优化均留存证据，并回到新的 Trace 中加以验证。
- 采集：全量收集 Trace、Token 与工具调用数据；
- 观测：提供指标、异常与主题层面的可见性；
- 评估：基于评估能力定义规则，判断每条轨迹的质量，例如用户问题是否需要调用最强模型；
- 归因：定位问题根因与优化对象；
- 调优：涵盖网关路由、经验注入与规范沉淀；
- 实验发布：以实验完成闭环验证，支持 A/B 对比、Benchmark 回归与回滚。
在调优范式上，AgentLoop 归纳出三种：
1. MANUAL 手动挡：部分输入须由人类专家提供，包括业务领域知识与回答好坏的判定标准。由人类专家定义 Rubric 与 Skill，沉淀高质量数据集，并通过实验完成调优；
2. COPILOT 半自动挡：由 AgentLoop 辅助挖掘 bad case，识别与业务无关的通用优化项，生成诊断报告，经人类专家审批后发布；
3. AUTOPILOT 自动挡：由 AgentLoop 自动挖掘经验库并注入 Agent 运行，使历史运行中沉淀的经验直接赋能后续执行。
三者并非互斥，而是从人工诊断逐步走向自动发现、自动注入与自动验证的演进路径。需要强调一条核心纪律：所有动作均须绑定验证指标——质量不降，单位任务 Token 持续下降。
观测第一步：把任意 Agent 变成统一轨迹
降本的前提是可见。AgentLoop 的采集能力基于 OpenTelemetry 标准协议构建，兼容 OTel 标准化数据协作协议，提供四种接入方式：
1. 通用 Agent，一键对接：针对常见 Coding Agent 提供专业化埋点，改造成本低。探针已覆盖市场主流 Coding Agent(包括 Claude Code、Codex 等)，新发布的产品亦可在发布初期即完成通用观测协议接入；
2. Agent 框架 SDK 集成：基于 AgentScope 等框架开发的 Agent，可直接集成探针 SDK，事件与状态采集更为完整；
3. 自定义高代码，注解埋点：完全自定义的高代码场景(如自行编写的 while loop，循环调用工具、沙箱与模型)，可引用探针 SDK，在关键路径添加注解，声明所需采集的数据；
4. eBPF 无侵入采集：针对沙箱内运行、不便埋点的场景，采用内核级 eBPF 探针直接采集模型输入输出与工具调用，由服务端还原为轨迹数据。
多种接入方式最终汇聚为统一链路：以 Trace 数据上传，通过 Trace ID 将模型调用、工具调用与沙箱调用串联为整体，再转换为统一的轨迹数据。具体包含五步：基于 OTel 探针接入；Trace ID 全量串联；以上下文依赖形成 Trace 拓扑；还原完整的思考与执行轨迹；字段统一为 user / assistant / tool / token / model。目前已覆盖 16+ Coding Agent。
需要指出：采集并非终点，必须能够串成“动作—观察—结果”的完整轨迹，才能判断 Token 是否真正被浪费。
观测第二步：宏观指标先回答“Token 花在哪里”
数据采集完成后，进入效率评估阶段。由于关注的是产出效率，核心衡量标准为：每单位产出所需消耗的 token 规模。据此定义四类宏观指标：
单位产出的定义可依场景而定：可以是 output 的 token 数量，可以是 edit 的代码量；若业务场景为编辑 Excel 文件，则以单个文件的编辑为一次产出。同时给出真实成本的构成：真实成本 = Input + Output + Cache Read × 折扣系数 + Tool / Observation 上下文。
在指标之外，结合 Trace 内的证据，可归纳出五类结构性浪费，每一类均对应可执行的动作与明确的责任方：
1. 未做任务分流(Platform)：简单的格式化 / 路由步骤长期使用高能力模型，应按复杂度路由，对简单步骤降级或批处理。当前 Agent 普遍存在的问题是单一模型处理全部任务，经济性不足——例如仅查找一个文件，无需动用最强模型。对此，云原生 AI 网关提供了智能路由模式：设置 auto 模式，后端挂载多个不同能力层级的模型，依据问题复杂度自动路由；
2. 重复获取已有信息(Agent)：重复读取同一文件，部分 Agent 在执行数百步后仍重复读取早期文件。应先定位再读取，复用已知事实与缓存；
3. 工具输出过大(Platform)：文件读取或工具调用的输出未经精简即进入上下文。应统一提供 head / tail、时间窗与字段过滤，采用懒加载，按需将输出载入上下文；
4. 无差异重试(Agent)：对同一错误原样重复 edit-run-fail，关键变量未改变。应先解释错误机制，再做最小 delta 修复；
5. 长会话膨胀(User + Platform)：input 持续增长、任务切换不拆分、历史全量携带。应按任务边界结束、压缩或新开 Session。
结构性浪费无法通过“减少输出”解决，主战场在于任务路由、上下文、工具输出与失败后的决策路径。
评估：24 维 Rubric，把浪费变得可见
前述分析停留在指标层面——input token、output token、文件编辑量均可量化。更进一步，需深入 Prompt 与 Session 层面分析整体效率，例如判断用户问题是否值得调用最强模型。此时需要引入评估能力。
评估的思路是：首先明确所关注的黄金指标——此处为效率；随后将其拆解为四个方向：效率机制、决策质量、产出质量、用户行为。
在拆解基础上，可定义一套24 维 Rubric。Rubric 是 Agent 与模型评估领域的常用方法，核心在于明确“何种情况下为该轨迹评定何分数”。每个子项均配有 1–5 分的打分细则与相应权重，权重反映各方向的重要程度。最终的权重分布为：效率机制 8 项、权重 13.0、占比 40%，为最大权重项；决策质量 6 项(20%)、产出质量 6 项(23%)、用户行为 4 项(17%)。权重确定后，24 个子项加权聚合为单一指标，反映整体质量。
Rubric 的定义遵循三条原则：
- 证据闭环：仅使用本 Trace 的字段，低分必须回连证据；
- 责任分离：Agent 14 项 / Platform 4 项 / User 6 项，字段缺失时不误判；
- 统一标尺：3 分 = 可接受，4 分 = 明确高效，5 分 ≈ 近乎最优；N/A 不入分母。
Rubric 的目的并非打分排名，而是将浪费转化为：可见 → 可归因 → 可验证地改掉。
评估器的输出不是单一分数，而是一条完整的改进链。以一条真实报告为例：Trace #17，综合得分 78.5/100，首要问题为 Session 膨胀(input 增长 6.2 倍、任务切换未拆分)，归因 User / Platform，预计节省 18%，行动建议为“新开 Session + 摘要交接，上限熔断”，优先级 P1，48 小时内验证。即：可见——定位哪一步、哪类 Token 异常；可归因——明确修复责任方；可行动——给出动作、优先级与预计收益；可验证——以同样本实验与回归结果佐证。
该方法同样适用于业务场景：评估自有 Agent 质量时，同样遵循“定义黄金指标 → 拆解 → 定义 Rubric → 配置权重 → 加权计分”的路径。
归因：先判断影响范围，再决定谁来改
评估用于发现 bad case；发现之后，下一步是归因——问题究竟源于个体使用方式，还是基础设施缺失，抑或知识库缺位。
方法是先界定问题的影响范围，再确定修复责任方，即Scope × Owner 矩阵：
- Scope(影响范围)：S1 个体(单人 / 单任务)→ S2 群体(团队 / 同一 Agent)→ S3 全员(平台 / 全公司)；
- Owner(修复责任)：O1 使用者、O2 Agent、O3 接入方、O4 平台、O5 组织机制。
核心规则为：Scope 升级，Owner 必须上移。个体行为，应优化使用者(制定规范与 Skill，指明解决路径与规避方式)并优化 Agent；若多人同时遇到同类问题，例如调用同一工具均告失败并反复重试，则应由团队或平台层面优化工具；若为全员普遍遇到的问题，例如缺少某知识库、模型在同一问题上反复产生幻觉，则应由公司层面补齐知识库。另有两条纪律：S3 的全员问题不记入个人；技术修复不能替代组织层面的 ownership。
两个真实案例具有代表性：SearchReplace 工具失败率高达 36%，且 100% 集中于 qoder 的接入实现——应归因接入方，而非培训用户；某处 cache 命中率连续三周为 0，技术问题清晰可见却无人修复——缺失的是 ownership、SLA 与升级机制。因此，根因须分三层审视：技术性(缓存、路由、工具参数)、行为性(规划、复用、Session 边界)、管理性(Owner、SLA、运营机制)。
在成本方向上，AgentLoop 提供了一套半自动化方案，通过算法挖掘轨迹中的可优化项，流程分为三步：
- 第一步，看全局：评估整体 token 用量，判断是否值得优化——总消耗多少，其中浪费占多少；
- 第二步，找对象：对 token 进行拆解——按主题聚类的分布，以及工具、上下文、历史模型、用户输入等各维度的构成，定位消耗所在；
- 第三步，看证据并行动：在大量轨迹中检索相似错误与相似轨迹，定位异常后给出最优行动建议，并评估其影响面——影响面越大，即为越优先的可优化项。行动建议包含原因、影响 Token、预计节省与执行方法。
其中一项底层算法能力值得说明：实际轨迹中，单条长 prompt 往往混杂 memory、工具、RAG 等多类信息。算法可对长上下文进行逐对象拆解——区分工具相关与 RAG 相关的上下文——拆解之后方能精准归因。
以一个示例窗口为例：总 Token 6.0M、100 条轨迹、36 个异常，预计节省 1.20M，约占总 Token 的 20%(算法估算)。其中输入 Token 5.6M——工具上下文占 37%、历史模型占 28%、用户输入占 20%、系统指令占 15%；输出 Token 0.4M，以回答为主。
同时需注意读数边界：预计节省为算法估算；高 Token 或高携带并不等同于浪费，必须结合异常证据判断。读数顺序为：先看影响 → 再看证据 → 最后执行。
该功能已于近日发布，可在 AgentLoop 的页面查看成本和效率标签页下开启。
经验自进化：给 Agent 开“天眼”
飞轮中最具想象力的一环是经验自进化。经验与记忆相似，但更进一步：传统记忆面向聊天应用中用户级的偏好记录；而在 Agent 领域，思考轨迹漫长、执行状态不确定且伴随错误，可从大量历史轨迹中提炼公共 pattern，识别相似性与错误点，将其沉淀为类似 Skill 的经验实体，直接注入 Agent 运行，完成闭环优化。
需要先明确一个判断：Agent 开发看似容易，上线后往往暴露出大量 bad case，真实效果必须依靠 Benchmark 衡量。据此，将经验库在完整的 Benchmark 上进行了验证：
质量提升 5/5，Token 下降 3/5。其中两组结果尤为值得关注：
- 在 OpenClaw 上，质量提升 6.14 个百分点，token 消耗节省 50% 以上。这表明对优化程度较低、相对粗放的 Agent，经验的优化空间更大；
- 在 SWE-bench Verified 上，注入经验后成功率由 67.2% 提升至 74.4%。在 coding 领域，每提升一个百分点均十分困难；而彼时该榜单上最强模型(Opus 4.6)的水平约为 75–76%。这意味着，借助经验，可使稍弱的模型逼近最强模型的水平。
对上述结果的解读是：经验稳定解决“做对”的问题，但 Token 提效还需要网关路由、上下文管理与验证策略的联合优化。这也是坚持构建飞轮、而非依赖单点招式的原因。
经验的生成遵循完整的生命周期：事实解析(问·做·验·答)→ 稳定模式(从大量轨迹中提取稳定模式、有效做法与常见问题)→ 质量 Gate(证据、反例、适用场景)→ 版本发布(来源、状态、版本)→ 任务匹配(任务 + 关键节点)→ 效果回写(更新 / 降权 / 停用)。每条经验均须有来源、有边界、有版本；不匹配则不使用，效果变差则停用。
经验库核心解决五类问题：任务怎么做、工具怎么用、出错怎么办、结果可靠吗、什么场景适用。具体而言：
- 任务怎么做：针对具体的垂直任务(如制作一份 PPT)，定义完整的 workflow——应遵循何种流程、从何处获取知识库、最终调用何种工具；
- 工具怎么用：例如某 CLI 未明确定义参数时，模型需先探索其参数构成与取值范围；探索结果可沉淀为经验，供后续直接复用；
- 出错怎么办、结果可靠吗、什么场景适用：分别对应修复与避坑方法、证据与资源、适用的角色与环境。
经验赋予 Agent 的，本质上是一种“天眼”视角：使其能够参考历史上发生的全部事件，从而找到最佳路径——原本庞大的探索空间被显著压缩，决策方差随之降低。
实验：不可验证的优化不发布
Agent 领域的所有优化，最终都须通过实验验证效果。这一点与工程领域存在显著差异：工程优化目标可精确计算(如 IOPS 提升幅度、CPU 降幅)，而 Agent 领域无法预先计算——模型存在极大的不确定性。
因此，无论方案多少，最终都须通过实验验证其有效性，即运行真实的 Benchmark。具体做法是：采集评估发现的 bad case，构建黄金数据集，持续进行实验回测——每修改一个版本即回测一次，检验效果；若效果不达预期，则予以回滚。
实验能力的核心是同样本 A/B 验证：
实验能力的核心是同样本 A/B 验证：
- 定义变量：方案 A / 方案 B；
- 同样本运行：同模型、同环境、同数据，完整执行数据集中的任务；
- 多指标评估：质量、Token、工具输出、时延；
- 对比与决策：发布 / 观察 / 回滚。
实验公平性由四个“同”保证：同样本(完全相同的任务集合)、同模型(模型与采样参数一致)、同环境(代码、工具、权限一致)、同评估(同一 Judge / Rubric / 阈值)。
一组同样本 A/B 实测结果显示：注入经验后，质量评分 8.7 持平，Token 下降 23.4%，工具输出下降 43.9%——同样好的结论，更少的 Token。决策规则明确：质量 ≥ 基线且 Token ↓ → 发布；质量 ↑ 但 Token ↑ → 观察、分场景处理；质量 ↓ → 回滚。
不可验证的优化不入库；不能回归的优化不发布。
结语：让平台每一轮都证明自己变好
综上，完整的闭环为：看见 → 归因 → 固化 → 注入 → 新 Trace → 验证下降。平台侧修复 cache、路由、截断与熔断；运行时侧实施经验注入、持续挖掘与 Guardrail；团队与个人侧提供清晰指令、做好规划、守住 Session 边界。终局目标只有一条：在质量不降的前提下，让单位任务 Token 持续下降。
最后以一句话作结：
Token 消耗的本质，是信息交换的代价——优化不是“少说话”，而是问对问题、给对上下文、走对路径，并把走通的路径固化下来。
本文作者@阿里云云原生。原文链接：https://mp.weixin.qq.com/s/JGiZxD9U3vaPQZde8ofp6Q