编码智能体的生产化元年：从演示到公司级部署的全景工程

团队普遍面临三大痛点：一是能力上限不可见——模型在公开基准上表现优异，但在真实仓库中的可行性无法预估；二是推理成本居高不下——每一次会话都可能消耗数十万 token，导致预算飙升；三是组织流程没人接手——缺少专门岗位来管理模型路由、评测与回滚。正是这三堵墙把“从演示到实际交付”拆分成四条主线：评测程序、路由与并行、成本控制、组织形态。

以下表格展示了四条主线及其主要产物：

User Pain Points:

• A/B 测试阶段出现功能通过但无法合并的问题,导致代码审核周期延长。
• AWS / Azure 上运行时出现token 费用暴涨且难以预测,项目经理担忧预算超支。
缺少专职 FDE 岗位导致现场适配无序和错误率上升。怎么说呢，

从评测程序来看。如何界定能力上限，为什么 Frontier Code 成为关键基准？按理说，

评测一直是 AI 编码领域最薄弱环节之一。传统基准如 SWE‑Bench 已被头部模型刷至高分区间。而 Frontier Code 则进一步引入可合并性双层评分，让评测更贴近真实业务需求。以下表格对比两种基准：

使用者痛点汇总：

• SWE‑Bench 的单通道评分容易被调整导致“通过率”失真，却忽略了 Mergeability 阶段问题。
• Frontier Code 的双层评分提高了可合并性的准确率，但构造题库耗时且难以

• 前沿模型按 token 计价成本结构——长任务场景下为何会产生指数放大？

  在长任务中，每一次 LLM 调用不仅要消耗输入 prompt。还要跑检索片段、工具调用、推理轨迹还有后续 evaluator 子代理，再加上多轮迭代，每轮都需要将之前所有上下文重新 prefill，导致 token 成本呈指数增长。如下面所示，一个 “改一个函数” 的典型任务若采用 Sonnet 级别模型。其 token 消耗约为 200k–300k，而切换到 GPT‑4 系列则可能翻倍甚至更多。

  ---

  推理芯片部署对延迟与成本的影响：从 per‑token 到 per‑wafer-hour 的转变？不过，

  'Cerebras 等 wafer-scale 推理芯片把整个 LLM 放在单一硅片上。使首 token 延迟降至亚秒级，从而显著降低长循环会话中的 TTFT。怎么说呢，这代表着相同预算内，可以完成更多回合。从而在总 token 成本方面获得更优折扣。例如在云端 API 按 token 收费时一次会话若包含 N 次迭代，每次都会产生额外前缀 cost。而在 microVM 或 Cerebras 上可以共享同一前缀，只产生一次 cost。'" style='font-weight:bold;'"> 路由与并行：让任务去找合适模型而不是让所有任务跑顶层模型？如何设计 router 与 Sidekick 并发执行？传统模式往往“一刀切”，所有请求都走 Claude Opus 或 GPT‑4 等顶层模型；但实际情况是大部分 PR 是小规模修改，只需轻量 LLM 就可以完成。在这一思路指导下我们提出了 Router + Sidekick 并发模式。并使用 microVM 隔离 + Sidekick Agent 并行尝试不同方案，接下来由路由器挑选 Mergeability 最佳结果。这种模式既降低了 token 成本，又减少了人工干预次数。

  模型档位	典型用途	决策密度	单位成本
  SWE‑Bench 对齐后训练模型	= 高频循环、私有工具调用	= 中等 | 小型项目 | 高效低价	= $0.002–$0.005