Agent 多供应商治理的工程现实 过去一年,企业内部 Coding Agent 部署从单一厂商走向多家并行的趋势越来越明显。单一厂商的 Agent 在某些任务上强、在另一些任务上弱,工程团队为了不被任何一家厂商的能力边界卡死,逐步把 Anthropic、OpenAI、GLM、Kimi、DeepSeek、Qwen、本地 Ollama 等多家厂商引入到生产链表中。这条转型路径在工程上带来一组清晰的新
Agent 多供应商治理的工程现实
过去一年,企业内部 Coding Agent 部署从单一厂商走向多家并行的趋势越来越明显。单一厂商的 Agent 在某些任务上强、在另一些任务上弱,工程团队为了不被任何一家厂商的能力边界卡死,逐步把 Anthropic、OpenAI、GLM、Kimi、DeepSeek、Qwen、本地 Ollama 等多家厂商引入到生产链表中。这条转型路径在工程上带来一组清晰的新问题——成本怎么控、效果怎么比、出问题怎么追责——这些问题的答案,不能由任何一家厂商提供,必须由工程团队自己建立。
两条独立工程实践在同一时段给出了高度一致的工程结论:第一条实践是 2026 年 4 月公开的"38k AWS Bedrock 账单事故"——一家工程团队用 Droid + LiteLLM + AWS Bedrock + Claude Opus 跑了本地编码 Agent 工作流,因为 prompt caching 链路在多层抽象中部分失效,产生了一笔 37901.73 美元的 Opus 账单;第二条实践是 2026 年 4 月公开的 RepoGauge——一个开源工具,允许工程团队在自己的代码库上对比多家模型(包括 Sonnet、Opus、Kimi K2.5、GLM-1),用真实任务而不是公开基准回答"换到 OSS 模型能省多少、性能差多少"的具体问题。两条实践分别从"成本治理"和"效果评估"两个角度,共同指向同一条工程新基线——Agent 多供应商治理必须有独立于厂商的治理层。
成本治理的工程现实
"38k 账单"事故在工程上指向一个被反复忽视的事实——主流云厂商对 Agent 类工作流几乎没有硬性预算拦截。这条事故复盘里,作者明确列出了几类"假装是安全护栏、实际是软信号"的能力:prompt caching 是支持的、预算告警是配置的、credits 是应用的,这些能力在文档里看起来都齐了,但都没有"超支就停止服务"这条硬护栏。结果是,Agent 在周末自动跑了 6.47B uncached input tokens,产生了 35600 美元的输入成本,作者周一才看到账单。
这条事故在工程上指向一个具体的工程基线:Agent 接入云厂商的 API 时,必须有一层"硬性预算拦截"——超过预算就立即停止服务,而不是发邮件通知。这条硬性拦截不能依赖云厂商的 budgets 功能(那个只是告警),也不能依赖模型厂商的 rate limits(那个是速率,不是金额),必须由工程团队自己实现。具体落地形式可以是反向代理 + token 计量 + 硬性熔断,或者 API 网关 + 配额管理 + 自动熔断。
这条事故还指向另一个工程现实——多层抽象链路让"假设成立但实际失效"成为可能。作者的链路是 Droid → OpenAI-compatible API → LiteLLM → AWS Bedrock → Claude Opus 4.6,每一层都说"我支持 prompt caching",但最终 6470M tokens 里只有 1670M 真正被缓存,缓存命中率远低于预期。这意味着任何一层抽象的"假设"都不能直接信任,必须独立验证——Agent 链路上的每一跳都需要独立的可观测性,任何一环失效都要被立刻检测到。
效果评估的工程现实
RepoGauge 这条实践在工程上指向另一个被反复忽视的事实——公开基准对"我自己的代码库"几乎没有指导意义。多数工程团队评估 Coding Agent 的方式是看 SWE-Bench、HumanEval、MBPP 这类公开基准,但这些基准用的是通用任务、通用代码库;工程团队实际生产里的任务是高度专域的,可能是某个老旧的内部系统、某种特殊的依赖组合、某种团队约定的代码风格。基准上 Sonnet 表现优于 GLM-1,不代表在"我的代码库"里 Sonnet 也表现优于 GLM-1。
RepoGauge 给出的解法是"私有评估"——让工程团队基于自己真实的代码库、自己真实的任务、自己真实的测试集,跑一遍多模型对比,得出在该团队具体场景下的实际最优模型。这种评估比公开基准更贴近工程现实,但代价是必须由工程团队自己投入时间建设评估流水线。具体到工作流:用 Coding Agent 跑通一个 pipeline,该 pipeline 在指定的代码库上对每个候选模型执行同样的任务集,用相同的方式打分(测试通过、lint 通过、风格匹配),最终给出每个模型在该团队具体场景下的实际得分。
RepoGauge 的作者明确指出一个工程现实——多模型对比必须包含 token 成本维度,不能只看效果。这条工程现实指向一个具体的工程基线:多模型评估的报告必须同时输出"准确率"和"token 消耗",二者一起做加权排序。如果只比准确率,企业会被引导到最贵但最准的模型;如果只比 token 消耗,会被引导到最便宜但最不准的模型;只有二者一起做加权排序,才能得出"在工程团队的预算约束下,效果最好的模型"这条工程上真正有意义的结论。
从单供应商到多供应商的工程治理基线
把两条独立实践的经验合并,可以画出 Agent 多供应商治理的工程新基线。这条基线由五条构成,缺一不可。
第一条,硬性预算拦截必须独立于厂商。任何 Agent 接入云厂商 API 的链路,都必须有独立于厂商的"硬性预算拦截"层——超过预算立即停止服务,而不是发邮件通知。预算拦截不能在 AWS Bedrock budgets 这种"软信号"功能里实现,不能在 Anthropic rate limits 这种"速率"功能里实现,必须在工程团队自己拥有的反向代理或 API 网关里实现。这条基线把"Agent 跑了一晚上产生 38k 美元账单"这种事故作为最低要求,任何不满足这条的工程部署都属于"事故未发生但概率极高"。
第二条,多跳链路每一跳都必须独立可观测。任何 Agent 接入云厂商 API 的链路(典型为"Agent → 适配器 → 代理层 → 云厂商 API"),每一跳都必须有独立的可观测性指标——缓存命中率、token 消耗、请求时延、错误率。任何一环的指标异常必须在分钟级被检测到,而不是依赖"链路整体能跑就当没问题"的乐观假设。这条基线把"假设缓存生效但实际失效"作为典型的多跳链路事故模式,任何不满足这条的工程部署都属于"事故未发生但概率极高"。
第三条,多模型评估必须基于私有代码库。任何 Coding Agent 选型决策都必须基于"工程团队自己的代码库 + 任务集 + 评估流水线",而不是基于公开基准。这条基线把"我的代码库"作为评估的唯一 ground truth,公开基准只能作为初筛。这条基线把"在公开基准上最优的模型"作为弱信号,把"在我的代码库上最优的模型"作为强信号。
第四条,多模型评估必须同时输出准确率和 token 消耗。任何 Coding Agent 多模型对比报告都必须同时包含"准确率"和"token 消耗"两个维度,二者一起做加权排序。这条基线不允许"只看准确率"或"只看消耗"作为决策依据。这条基线对应工程团队的真正目标——"在预算约束下最大化效果",而不是"最大化效果"或"最小化消耗"。
第五条,模型迁移必须有完整的能力对照。基线评估在迁移前必须包含:准确率、token 消耗、prompt caching 行为、tool calling 兼容性、长上下文支持、推理行为(thinking tokens)、限流行为、安全行为、错误处理、上下文溢出处理、并发行为。这十条里任何一条在迁移后表现不同,都会导致工程事故。这条基线对应"看上去能跑"和"生产能跑"之间的巨大差距——迁移前必须把差距识别出来,迁移后必须验证差距确实被覆盖。
从 Coding Agent 多供应商推到所有企业 Agent
把视野拉宽到企业 Agent 全景,以上五条基线具有普遍意义。任何企业内部被授予"调用云厂商 API、长会话、自主决策"能力的 Agent——不只是 Coding Agent,也包括销售 Agent、客服 Agent、财务 Agent、运维 Agent——都会面对同一组多供应商治理问题:成本怎么控、效果怎么比、出问题怎么追责。
企业 Agent 治理负责人现在应当把 Coding Agent 多供应商治理的工程新基线作为整个企业 Agent 工具链多供应商治理的样板工程。具体来说,"硬性预算拦截、多跳链路独立可观测、私有代码库评估、同时输出准确率和消耗、迁移前完整能力对照"这五条规则应当通用化,覆盖企业内部所有 Agent 的所有多供应商场景。每一条规则对应一个独立的工程组件——可以是反向代理 + 计量模块、可以是分布式 tracing、可以是私有评估流水线、可以是评估报告模板、可以是迁移对照表——实现形式各异但原则一致。
企业 Agent 治理负责人现在必须回答的三个问题
面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 Agent 接入云厂商 API 时,有没有独立于厂商的硬性预算拦截?如果没有,Agent 在长会话里失控产生高额账单就是常态,不是偶发。
第二个问题:你企业内部 Agent 接入链路有多少跳?每一跳有没有独立的可观测性指标?如果有多跳但没有独立观测,链路中任何一环失效都无法被及时检测。
第三个问题:你企业内部 Agent 选型决策是基于公开基准还是基于私有代码库评估?如果只是基于公开基准,迁移到 OSS 模型时实际效果可能与公开基准完全不同,事故会发生在迁移后的第一周而不是迁移前的决策阶段。
结语
Agent 多供应商治理在过去一年被显著推前,从"单家厂商绑定"演化到"多家厂商并行"。每推前一步,工程侧的治理基线就必须同步推前一步。把"云厂商的预算告警就够了"作为主要假设的部署,在 38k 账单事故里被反复证伪。把"硬性预算拦截、多跳链路独立可观测、私有代码库评估、同时输出准确率和消耗、迁移前完整能力对照"作为基线,重新设计 Agent 多供应商治理方案,是当下能落地的工程基线。
任何企业 Agent 项目,只要涉及多家模型供应商并行、长会话高 token 消耗、生产级 SLA 要求,工程基线就必须做到这五条——硬性预算拦截、多跳链路独立可观测、私有代码库评估、同时输出准确率和消耗、迁移前完整能力对照——否则,今天不是某次失控账单事故的主角,也会是下一次效果退化事故的主角。