摘要

GitLab 在 Duo Agent Platform 中推出面向 agentic 开发的成本治理能力。官方指出，agentic 开发的成本随每个任务倍增：每个任务消耗 token 与 credit，当 agent 在团队与自动化中铺开后，消耗增速可能快于实际用量增速。平台新增托管开放权重模型 GLM 5.3、Kimi K3、MiniMax M3；官方内部基准显示，GLM 5.3 以约五分之一成本达到 Claude Opus 5 的任务完成度，Kimi K3 以三分之一成本达到 Claude Fable 5.1，MiniMax M3 以八分之一成本达到 GPT-5.5。配套能力包括 GitLab Orbit（为 agent 提供生命周期上下文以减少重试）、Duo Agent Platform Impact Analytics（按用户/团队/任务/模型拆解支出）、以及订阅/群组/用户三级的 credit 上限与 50%、80%、100% 告警。官方举例称，一个 40 人开发团队曾因 agent 反复重试而多花 23 倍支出；引入 Orbit 后，Claude Code 中同一任务重试次数最多减少 45 倍，首次获取正确上下文所用 token 减少 4.5 倍。上述均为 GitLab 自述数据。

正文（译文）

让每一分 AI credit 都花得值：看见、设限、降低 agent 支出

agentic 开发的成本随着你交出的每一个任务而成倍增长。挑选合适的模型，用 GitLab Orbit 减少 agent 重试，并通过实时分析控制支出。

成本随着你交给 agent 的每个任务而成倍增长。每个任务都会消耗 token 与 credit，而随着 agent 在你的团队和自动化流程中铺开，消耗的增长速度可能快于实际用量的增长速度。如果你负责运营这个平台，你就得为这种增长负责——包括哪些团队和工作流在驱动它，以及这些用量是否真的交付了成果。

这就要谈到我们面向 agentic 软件工程的架构，以及 GitLab Duo Agent Platform 中让这种增长变得可控的新能力。

GitLab 托管的开放权重模型在 GitLab 的基准测试中，以极低的成本达到了前沿模型的任务完成度，因此你可以让模型与任务相匹配，从而提升团队的成本效率。

GitLab Orbit 为 agent 提供生命周期上下文，让它们减少重试。

Duo Agent Platform Impact Analytics 与 credit 及用量控制，显示 credit 的去向并为其设定上限。

在受治理的软件工厂中控制成本

一个用量总数只能告诉你消耗了多少，却回答不了那些棘手的问题：有多少常规工作跑在昂贵的模型上，有多少次 agent 运行是浪费掉的重试，又是哪些用户和团队把 credit 烧掉的。当仪表盘只显示 token 时，平台负责人和工程负责人最终会为一个双方都无法背书的数字争论不休。如果你无法归因用量、设定上限、砍掉浪费，你就既无法优化也无法证明这笔支出的合理性。

打破这一困局要从架构入手。受治理的软件工厂是分层构建的，而成本恰恰在这些层与层之间未打通的地方增长。其中两层对成本影响最大。第一层是 agent 编排，开放权重模型在这里把常规工作放到低成本模型上。第二层是数据与上下文，Orbit、Duo Agent Platform Impact Analytics 以及 credit 与用量控制在这一层为人类和 agent 提供上下文，以尽可能低的成本产出高质量结果。

这个问题在「影子软件工厂」中看得很清楚：每个阶段都有自己的工具，彼此之间没有共享策略或上下文。agent 耗费 token 在一批从未为互通而设计的系统之间搜寻上下文。受治理的软件工厂则为 agent 提供共享上下文、共享策略，以及一个统一衡量其成本的地方。当每一分 AI credit 都要计算时，你可以做到：

用更少的 credit 完成同样的工作： 用开放权重模型让模型与手头任务相匹配，并用 GitLab Orbit 把 agent 锚定在生命周期上下文中，使其减少重试。 在 Duo Agent Platform Impact Analytics 与 GitLab Credits 仪表盘中按用户、团队、任务和模型查看 credit，从而明确指出是什么驱动了增长。

在下一次峰值到来前设好天花板： 通过 credit 上限按用户限制用量，并在需要时设置例外，让 agent 循环始终运行在你设定的限额之内。

agent 成本始于每次模型调用的价格。

你可以为每个功能锁定一个默认模型，并控制团队可以使用哪些模型：你自己的模型（自建或来自你的供应商）、GitLab 托管的前沿模型，或者 GitLab 托管的开放权重模型。

以下 GitLab 托管的开放权重模型现已托管于 GitLab Duo Agent Platform：GLM 5.3、Kimi K3 和 MiniMax M3。在 GitLab 使用 Duo agent 进行的内部基准测试中，GLM 5.3 以约五分之一的成本达到了 Claude Opus 5 的任务完成度，Kimi K3 以三分之一的成本达到了 Claude Fable 5.1 的任务完成度，MiniMax M3 以八分之一的成本达到了 GPT-5.5 的任务完成度。模型选择是一项管理员设置。在你顶层群组的 GitLab Duo 设置中打开相应页面，为每个功能锁定一个模型。例如，把 Kimi K3 固定给 Agentic Chat，把 MiniMax M3 固定给 agents 与 flows，这样常规工作就不会默认走前沿模型。群组所有者还可以选择其团队可以使用哪些模型。

用正确的上下文减少重试

模型选择决定了每次调用的价格，而重试会成倍放大调用次数。

我们发现，一个 40 人的开发团队因为在缺乏正确规则和上下文的情况下 agent 反复重试，在 AI 上的支出高出了 23 倍。agent 在缺乏上下文时就会重试。在一个单体仓库或多个仓库中，agent 最初的一段时间都花在爬文件、搞清楚什么和什么相关联上，而每一次重试都会重新发送完整的上下文窗口。

GitLab Orbit 把你的代码、工作项、合并请求、流水线、部署和安全发现映射为一张统一的图，并随着团队交付保持实时更新。GitLab Duo Agent Platform 中的 agent 可以原生查询它。Claude Code、Codex 等外部 agent 通过模型上下文协议（MCP）接入，自定义工具则通过 REST API 接入。每个 agent 看到的内容，与它的用户在 GitLab 中能看到的内容完全一致。

有了这层上下文，agent 向这张图提问，就能更快、更高效地得到精确答案。在一项测试中，借助 Orbit，Claude Code 中同一任务所需的重试次数最多减少了 45 倍；另外，首次获取正确上下文所用的 token 也减少了 4.5 倍。Orbit 今天已在 GitLab.com 上开放免费公测，并将于下个月在所有部署方式中正式可用。

模型与上下文降低了每个任务的成本。Impact 数据则说明它是否真的奏效。

Duo Agent Platform Impact Analytics 回答平台负责人最常问的两个问题：我们花了多少，这些支出集中在哪。它按你选定的团队和日期范围，从多个维度拆解支出，并展示某个开放权重模型与你当前的模型组合相比表现如何，让你用数据比较而不是靠猜。GitLab Credits 仪表盘则在团队层级之下提供更细的信息，把用量追溯到具体的用户和会话。

可见性要与限额配合。没有限额，剩下的唯一办法就是呼吁大家少用一点。Credit 与用量控制在订阅、群组或用户层级设定上限，并在支出达到 50%、80% 和 100% 时发出告警，一旦用量触及上限即自动暂停。统一的每用户上限（例如每用户每月 1,000 credits）适用于每位团队成员；而个别例外（例如追加 500 credits）则给正在探索的工程师留出试错空间，无需再来申请。每用户上限在用户用完其包含的 credit 后生效，且只有被限额的用户会失去使用 credit 消耗型功能的权限，直到下一个计费周期或管理员上调上限为止。

Duo Agent Platform Impact Analytics 将 credit 消耗与进入生产环境的成果并列展示，因此你可以看到用量是否转化为了实际交付的工作。

从模型开始你的 agent 成本控制之旅。GitLab 托管的开放权重模型已正式可用。在顶层群组中，把 GLM 5.3、Kimi K3 或 MiniMax M3 固定到某个常规工作负载上，例如一个在每次合并请求时运行的 flow。Orbit 今天已在 GitLab.com 开放免费公测，为你运行 agent 会话最多的那个群组开启它。Orbit 将于下个月在所有部署方式中正式可用。启用 Duo Agent Platform Impact Analytics，你就能按团队、任务和模型查看支出。Credit 与用量控制已正式可用，可设置相应上限。