2026 年 8 月 18 日,Unblocked 团队把工程博客《What We Learned Moving Our Agent Loops from Anthropic to GLM》发到 Hacker News,18 分不算顶流但讨论质量极高。Unblocked 是给企业 AI Agent 提供"组织级上下文理解"的中间层,过去两年几乎所有 agent 流量都跑在 Claude Opus
2026 年 8 月 18 日,Unblocked 团队把工程博客《What We Learned Moving Our Agent Loops from Anthropic to GLM》发到 Hacker News,18 分不算顶流但讨论质量极高。Unblocked 是给企业 AI Agent 提供"组织级上下文理解"的中间层,过去两年几乎所有 agent 流量都跑在 Claude Opus 上,2026 年夏天把主流 agent 流量切到了 GLM 5.2。这件事的工程价值在于它把所有"把 Anthropic 切到 GLM"会撞到的具体问题——成本核算、协议兼容、serving provider 池化、prompt 复用、loop budget 重写、fallback 设计——一次性铺到了真实生产环境上,提供了一份完整的可复用样本。再叠加 8 月 23 日 GLM-5.3 发布并以 1/5 价格"宣称"超越 Anthropic/OpenAI 模型在 Ed-O-Meter 上的成绩(240 分),以及 gertlabs.com/rankings 把 GLM 5.3 排在 #6 的独立验证,这三件事合起来刚好可以回答一个企业落地最关心的问题——Coding Agent 厂商切换到底要付出什么代价、保留什么底线、能拿到什么真实收益。
一、Per-token 定价是骗自己的,Per-task 才是真账
Unblocked 团队在博客里第一条经验就足够反直觉:per-token 数学告诉你能省 95%,per-task 生产实账告诉你只省 68%。差距 27 个百分点,从哪儿来?核心是 GLM 跑同一个任务的 token 消耗量比 Opus 大。
博客给出具体数字:Fireworks dashboard 上 GLM 服务了 23.5 亿 token,成本大约是 Opus 同量级的 5%,也就是 95% 的价差。但同一段代码评审任务、同一个 commit、同一个 PR、同一个 prompt,Opus 跑一次的费用对比 GLM 跑一次的真实节约是 68%,不是 95%。差异的核心来自 GLM 的行为特征——它做更多工具调用、更激进地探索,有时是好事有时是浪费;它更多犯错,而犯错消耗 turn(每多一次工具往返都花钱);它吞下更大的工具返回结果,花更多 token 在它上面思考;它整体话更多。
Unblocked 给出的搜索流量 token 数变化印证了这一点:平均每通调用 token 从 18500 涨到 24700,涨三分之一,而 GLM 那时候只跑了 45% 的调用。如果 GLM 全量上线,这个开销会被线性放大。换句话说,per-token 价差是模型供应商卖给客户的"乐观账",per-task 实账才是企业 IT 真正要交的账单。
这条经验对企业落地的直接启示是,任何模型切换评估都必须跑端到端、跑真实工作负载、对比账单,不是对比 rate card。Rate card 上的省钱数字永远比真实账单乐观 10 到 30 个百分点,因为它不计算模型在 prompt 工程、tool 调用、retries 上的额外消耗。这种乐观账在 demo 阶段无害,在生产阶段危险——按 95% 砍预算,实际只省 68%,财务会追过来解释为什么"亏空 30% 预算"。
二、协议兼容不是标准,是光谱
博客里最有工程价值的一段是讲"OpenAI-compatible"这三个字在水下的真实含义。每家开源模型 serving provider 都声称 OpenAI-compatible,但兼容度在边界上崩得稀碎。
第一,推理内容的 wire format 没有标准。Fireworks 把思考输出放在 reasoning 字段,Together 放在 reasoning_content,OpenAI 第一方在 chat completions 里根本不返回推理。如果跑多轮 tool-calling loop,推理内容需要回放到之前的 assistant turn 上,而每个 host 对回放的格式都有自己的预期,拼错就断。Unblocked 团队在这上面花了大量时间写适配层,这件事在文档里几乎找不到,只能逐个 provider 试。
第二,reasoning effort 映射可能悄悄花光预算。GLM 的 chat template 把任何非字面字符串 "low" 的 effort 值都当成 maximum effort,Unblocked 团队之前以为自己在用 minimal effort,实际每次调用都在付 maximum 推理的账单,直到审计才发现。这条坑对生产环境是致命级——表面上模型工作正常,API 返回正常,业务侧没投诉,但月度账单可能在某天突然翻倍,而且没有报错日志指向原因。
第三,prompt caching 的键值策略各家不同。第一方 OpenAI 用专门的 cache-key 字段,Fireworks 和 Together 完全忽略这个字段,直接拿 prompt 字段做 cache key。Unblocked 在迁移初期多轮会话每次都 miss cache,但响应成功、输出正确、没有报错——成本漂移在沉默中发生。日常看到的"成本波动"背后,可能是几十万个调用的 cache 命中率从 95% 掉到 0。
第四,usage accounting 不一致。有的 OpenAI-compatible API 把 cached tokens 包在 prompt_tokens 里,有的分开报。如果 cost pipeline 假设这两类是分开的,就会重复计费,所有下游 dashboard 跟着错。第五,structured output 支持各家不同——response_format: json_schema 有的支持有的直接拒,Unblocked 团队 7 天里 336 次结构化调用 0 成功,流量默默被 pin 到某一家的 provider。第六,流式 usage stats 报告方式不同,Baseten 在每个流式 chunk 上报累计 token 数,如果天真聚合就会把用量按 chunk 数放大几倍;Fireworks 干脆在该请求时直接返 400。
这套坑对企业意味着,任何一次"接 GLM / 接 DeepSeek / 接 Qwen"的协议对接,工程预算必须留 2 到 4 周专门做兼容性适配,而不能像 OpenAI 一家供应商那样直接用官方 SDK。一句话总结:你买的不是模型,是 serving stack。
三、Serving Stack 要当 Pool 来做
把 Anthropic 切到 GLM 之后,Unblocked 团队学到的第二个核心教训是,serving provider 必须按池化处理,而不是单一供应商。GLM 5.2 同样的权重在 Fireworks、Together、Basenet 三家服务上的延迟、稳定性、特性支持都不同。
博客描述他们最终的工程方案——多个独立 serving provider 背后一个路由层,每个 provider 包一个 circuit breaker。当某个 provider 降级,breaker 打开,流量切到健康的支腿;breaker 状态在 fleet 内同步,每个节点同时响应。最初在 Fireworks 和 Together 之间做 round-robin,后来加 Baseten 作为合规友好型静态基础设施支腿,最终因为 Together 不稳定而把它下掉。即使是剩下的 Fireworks 和 Baseten 之间,静态轮询也不对——Baseten 在 rate card 每条线上都比 Fireworks 便宜约 20%,所以手挑优先级仍然不是动态答案。最终他们走到自适应路由:持续在生产环境对每个 provider 的成本、可靠性、速度做采样,根据实时数据自动调度流量。
这套机制带来的最大价值不只是 uptime,是诊断能力。8 月 11 日 GLM 代码评审当天抛了 500 多次失败,房间里的第一反应是把整个负载挪回 Claude。但实际原因不是模型,是 pool 中某条支腿 429 突发导致短时间欠载,circuit breaker 把流量转到别的支腿后整个服务自动恢复。如果没有 pool 机制,这种时候要么用户感知故障,要么工程团队手动切流量,无论哪种都要付出 10 倍以上的处置成本。
Anthropic 在整个体系里始终保留为深度 fallback——如果整个 GLM pool 耗尽,流量转到 Claude pool 而不是失败。这条原则对企业非常关键——任何多供应商架构都必须有 fallback,而且 fallback 必须是真实可用的、真实可承接全部流量的,而非名义上挂在那儿。Unblocked 还保留 Claude 作为合规约束客户的唯一可选项——有数据处理协议或合约供应商限制的组织,路由层在请求时把 GLM-targeted 请求改写到 Claude pool,根本不让它碰到 GLM provider。这是把合规约束从应用层抽到路由层的设计。
四、Loop Budget 是模型的脾气,不是参数
Unblocked 团队在切换两周后遇到了一次回归——延迟和质量指标双双下跌。乍看是模型切换的锅,但实际诊断发现,这次回归是同时上线两件事的混淆结果——模型切换 + loop turn budget 调高。把两件事拆开才能看清楚真相。
根因是 GLM 比 Opus 探索更多、犯错更多、消耗 turn 更多,而 turn budget 调高允许了这种行为,而不是它引发。模型本身的探索倾向没变,但允许它探索到更深的预算,实际上把质量问题放大了。博客把这五件事列得很清楚:"答案变差"这个症状其实包含五个独立失败模式——模型推理差、模型工具用法不同、loop 给了这种行为太多空间、serving provider 慢或不兼容、成本和延迟埋点错了。任何单一信号都会指向错误根源,要正确归因必须把模型输出、工具行为、provider 健康、延迟、成本五件信号一起测。
这条经验对企业 Agent 平台设计者极关键。Loop budget(turn 数、tool call 数、超时阈值、retries 数)从来不是固定参数,而是模型行为的镜像。换模型不重新调 loop budget,几乎一定踩回归。这件事反过来说明,任何 agent 平台的 loop 配置必须以"模型"为维度存——同一个 task 在 Opus 上是 turn 8,在 GLM 上可能是 turn 12,平台必须能感知、自动调整、或至少在 dashboard 里给出告警。
更进一步,Unblocked 在迁移过程中意识到 turn budget 不如 tool-call budget——一个允许多个并行 tool call 的 budget 比单纯的 turn 限制更适配 GLM 这种"探索更多"的模型,因为并行调用在算 turn 时还是 1,但实际工作量大很多。这条优化点是把 budget 从"模型调用次数"升级到"模型实际行为量",值得企业 Agent 平台照搬。
五、GLM-5.3 的独立验证,以及 1/5 价格的真相
8 月 23 日 GLM-5.3 发布并放 Hugging Face,HN 上 8 月 28 日放出 zai-org/GLM-5.3 开源权重帖(806 分)。reinvently.co.uk 上的 Ed-O-Meter 用 28 个任务评测,给出 GLM-5.3 优于 Anthropic/OpenAI 同价位模型的成绩,8 月 23 日 HN 帖 240 分。但评论里立刻被挑战——gertlabs 在自己 multi-agent coding evaluations 上把 GLM 5.3 排在 #6,而且 Pareto 角度稍弱于 Grok 4.6(同价位更快)和 Sol 5.6(同结果少 thinking tokens)。gertlabs 的结论是 GLM 类中国模型擅长在 harness 里迭代,但第一答案、基础流体智能低于美国前沿模型。
这条独立验证对企业的直接含义是,1/5 价格不等于 1/5 能力。GLM-5.3 实际可能在 90% 的任务上接近 Opus 性能,但在剩下的 10% 高难度任务上仍明显落后。这种分布意味着企业的最佳策略不是全切,而是分任务切——高流量、可验证、好定义的任务放 GLM,核心路径、要精确、要 instruction-following 的任务留 Opus。
Unblocked 团队最终走的就是这条路——代码评审和 Q&A 默认 GLM 5.2(高流量、可定义),核心决策路径和合规约束客户保留 Opus。模型选择变成 per-task policy,而不是 application 设置。
六、Coding Agent 厂商切换的工程清单
把 Unblocked 的工程经验和 GLM-5.3 的独立验证合起来,可以总结出一份 Coding Agent 厂商切换的工程清单。
第一条,先做 cost per task 评测,而不是 cost per token 评测。Per-token 价差在 demo 阶段无害,生产账单至少再加 10 到 30 个百分点的隐藏消耗,只有端到端、真实工作负载、对比账单才能给出真实数字。
第二条,工程预算必须给 OpenAI-compatible 适配留 2 到 4 周。协议兼容不是标准是光谱——reasoning format、cache key、effort mapping、structured output、usage accounting、流式 stats 六件事每件都要逐 provider 写适配,这件事没捷径。
第三条,serving provider 必须池化。从 day one 起就要有 circuit breaker、自适应路由、deep fallback 三件套。Pool 不只是 uptime 工具,也是诊断工具——故障归因时能精确到 provider 而不是模型。
第四条,fallback 必须是真实可用的,不是名义上的。任何多供应商架构都要有一个能承接全量流量的 fallback,而且要定期演练真实切换,不能在故障当天才发现 fallback 接不住。
第五条,loop budget 必须按模型调。换模型后 turn 数、tool call 数、retry 数全部要重写,这件事不能省。
第六条,模型选择是 per-task policy,不是 application setting。高流量定义清晰的任务用便宜模型,核心路径、合规约束、高精度任务保留前沿模型。
第七条,持续评测要变基础设施。Unblocked 把 blind sentiment pipeline 当成永久设施,持续把候选模型放进来跑真实工作流,这一点比 benchmark 决定模型选型更可信。基准图谱只能做初筛,真实生产判断只有真实生产信号才能给。
合起来看,2026 年 8 月这两件事——Unblocked 工程团队的实测报告加 GLM-5.3 开源权重——把"中国开源模型能不能在企业 Coding Agent 里顶替美国前沿模型"这个问题从争论推进到了可执行路径。结论是:能,但不是全切、是分任务切、是分 provider 切、是按 loop budget 切、是按工程适配预算切。把这件事想清楚的企业 Coding Agent 团队,才能在接下来一年的模型市场快速变动中既不被任何一家的宣传话术带跑,也不错过任何一个真实可用的成本优化窗口。
