成本优化

我们如何用 Insights 改进 Insights 背后的 agent

Datadog 的工程师用自家产品 Insights 来观察和优化他们自己的 AI agent。Insights 会分析 agent 的运行记录，找出它在哪些地方花了过多 token、工具调用失败或任务没完成，并解释原因、估算影响、给出有依据的修复建议。例如它发现搜索工具一次返回太多内容，导致后续请求被重复计费；还发现请求顺序不对，使提示缓存无法复用，估算每月可省约 2734 美元。工程师随后把建议交给编程 agent 改代码，并通过重放原任务验证修复后 token 是否更少、回答是否仍然正确。这是 Datadog 的自用案例，节省数字为估算、尚未实测。

Ripple HUD：为 Claude Code 更低成本模型注入前沿模型工作方式的插件

Dallenlol/ripple-hud · Benchmarked Claude Code plugin that makes cheaper Claude models (Haiku, Sonnet, Opus) match Fable 5's output at a fraction of the token cost — auto-routed reasoning levels, verification discipline, closed-loop habit correction, statusline HUD with usage meters, and a portable AGENTS.md export for any AI coding agent.

Ripple HUD（前身 fable-mode）是一个 Claude Code 插件，通过约 1500 token 的行为层让 Haiku、Sonnet、Opus 等较便宜模型采用类似前沿模型的工作方式：自动分流任务强度（lite/full/deep）、先理解再执行、执行后验证、保持输出精简、控制 token 消耗。它还提供终端状态栏 HUD（显示上下文窗口与用量限额）、基于本地会话记录的习惯纠正闭环、用项目状态文件替代长对话历史，并可将 AGENTS.md 导出到 Cursor、Codex、Zed 等工具。仓库附带的 A/B 评测显示 Sonnet 加装插件后在 6 项评分任务上与对照模型持平，成本更低；插件本身是行为层，不能增加模型原生能力。

AI Agent 默认先用无服务器，让生产数据决定何时迁移

Datadog 的几位工程师建议，AI Agent 的工作负载应优先考虑无服务器（按请求分配算力、空闲缩到零）而不是常开服务器。他们分析了超过 3.5 万次生产环境编程 Agent 会话，发现中位数会话只有 20% 的时间在真正调用模型或工具，其余时间都在等待，但沙箱资源一直占着，常开算力等于为闲置时间付费。做法是先给工作负载建一份「执行画像」，记录峰值并发、单次运行的实际计算时长与总耗时之比等，再据此判断用按需算力还是专用节点；长任务可以拆成可恢复的无服务器工作流，等待时释放算力、下一步就绪再继续。读者可以据此避免过早购买常开算力，并用上线后的真实数据再决定是否迁移，文中还提到可用 Datadog 的 Agent 可观测性、APM 和无服务器监控来测量这些指标。

model-ladder：为 Claude Code 与 Codex 插件按任务难度分级路由模型并验证结果

neilyonglu/model-ladder · Run each coding task on the cheapest model and effort likely to succeed, verify it with your tests, and escalate only when an attempt fails.

model-ladder 是 Claude Code 和 Codex 的插件，通过 Router、Worker、Verifier 三个环节工作：先由路由器为每个编码任务挑选成本与能力匹配的模型及 effort 等级，再由 Worker 在隔离的 Git worktree 中执行，失败时按阶梯升级到更强模型或更高 effort，最后由 Verifier 用项目测试命令校验，通过后才交付结果。它还提供用量守卫与交接文档、任务状态面板、并发运行冲突检测、可配置的 worker/verifier 技能指令等能力。安装需 Git 与 Node.js 20+，并在 Git 仓库中运行，具体模型与测试条件需自行配置。

多云 FinOps：跨云成本优化的工程框架

作者 Vivek Arora 写了一篇关于多云架构成本优化的文章。多云用起来灵活，但服务放在哪个云、服务之间怎么通信，会产生不少隐蔽的“出网费”（数据跨云传输要付的钱）。文章给出一个工程做法：用 FOCUS 标准把各云的费用统一看清楚，再考虑负载怎么摆放、数据怎么同步，并把成本检查加进 CI/CD 流程。作者还做了对照实验，发现改架构比单纯谈折扣省得多。读者可以据此判断：光砍单价不如先动架构。具体实验规模、FOCUS 版本和 CI/CD 集成细节原文未说明。

Kubernetes DRA 如何提升 GPU 利用率并降低成本

Datadog 的产品经理 Kathy Lin 和技术作者 David Lentz 写了一篇文章，讲 Kubernetes 的旧设备插件模型怎么限制 GPU 使用效率。旧模型里，团队必须提前把 GPU 切好固定的分区，请求只能写数量、看不出显存大小和连接方式，结果经常是花钱买的 GPU 容量白白闲着，或者任务排队等资源。新的动态资源分配（DRA）让 Kubernetes 按每个任务的具体需求灵活挑选和分配 GPU，还能让多个任务共用同一块 GPU，把闲置容量利用起来。读者可以了解 DRA 相比旧模型好在哪，以及用 Datadog 怎么跟踪这些改进和省下的成本。文章目前是博文介绍，没有给出具体性能数字，也没有说明 DRA 功能是否已普遍可用。

LegalOn 将 Codex 成本减半，同时保持开发速度

LegalOn 把每天使用 Codex 的估算成本降低了 65%，但开发速度没有变慢。做法是根据任务难度，把 Astra、Sol 和 Luna 这三种情况分别匹配到合适的用法上，并提前规划好预算。对读者来说，这说明大模型编程工具的费用并非只能一路走高，通过合理分配任务和管好预算就能明显省钱。

判断而非生成：在 Jev 上重建 AI API 分类器

安全平台 Harness 的 AppSec 团队用自研决策模型 Jev 替换了原来生成式大模型做的「是/否判断」环节，用来识别客户 API 里哪些在和 LLM 通信。原来这条流水线要先用两次 LLM 摘要、再做分类，成本高、延迟大，而且模型自报的置信度几乎不能用来判断对错。换成 Jev 后，系统不再让模型写文字，只输出一个概率：每条 API 的判断成本比原流水线降约 1200 倍，比单次 LLM 方案降约 150 倍；出错的样本都落在 0.3–0.8 的不确定区间，只占 3.4%。对读者来说，这提供了一种思路：把流水线中重复的「判断」和「生成」拆开，用专门的决策模型替代，能大幅降本，同时保留可回滚的接口。

演讲：在 DoorDash 构建生成式 AI 平台

DoorDash 的两位工程师 Swaroop Chitlur 和 Sidd Kodwani 分享了公司内部搭建生成式 AI 平台的过程。最初他们主要依赖外部厂商的模型，后来逐步转向开源权重模型，并搭建了统一的 LLM 和 Agent 网关来管理调用。平台要同时兼顾准确度、响应速度和成本，目前服务超过 5000 名内部用户。对读者来说，这是一个大型公司如何把生成式 AI 落地到内部、并控制成本和性能的真实案例。

如何在 Harness 中构建模型路由器

LangChain 为开源编码 Agent Open SWE 加了一个「模型路由器」，先判断每个请求有多难，再决定用贵模型还是便宜模型。原来所有任务都交给顶级前沿模型处理，很多简单任务白白多花钱；路由器放在 Agent 的 harness 里，因为这里本来就有任务和领域上下文，通用网关没有。结果是每个编码任务的成本中位数降了 64%，质量没有可测量的下降。对读者的用处是：这篇教程告诉你如何理解任务、挑选模型档位，并在自己的 Agent 里也做类似的省钱路由。

OrchestralFlow：面向 Claude Code 的多智能体编排模式框架

Sakshxm1/hermes-agency-orchestrator · Claude Code Agent Workflows Guide 2026: Skills vs Teams vs Cost Analysis

OrchestralFlow 是一个以「管弦乐总谱」为隐喻的 Claude Code 智能体编排框架，把 /goal 声明解析成动态总谱，按技能、子代理与代理团队拆分任务，并通过成本阶梯（Tutti / Soloist / Conductor 三档代理）做成本感知的任务路由。它宣称包含 UltraCode 提示压缩层、多语言意图支持、运行中代理热替换与安全检查点等机制，用于单代理向多代理协作的规模化扩展。仓库自述其为概念性编排模式与文档集合，并非独立可执行的软件包，成本阶梯机制为模拟模型。

Featherless：送披萨不必开坦克，轻量分类模型就够了

Featherless 是一家提供无服务器推理服务的公司，它发布了一个叫 Simple Jev 的开源库，能把开源 AI 模型变成高速的“零样本分类引擎”。原来的问题是，很多开发者用超大的前沿模型去干分类这种简单活，比如判断一张图片或一段文字属于哪一类，既慢又贵，就像开坦克送披萨。Simple Jev 不让模型写长篇回答，而是直接读出它对各个选项的打分并给出概率，因此更快、更省算力。开发者可以用免费公共接口试玩（限制 2000 词上下文、每秒 2 次请求），生产环境起步价每百万输入 token 0.03 美元，输出免费；目前视觉分类仅支持 Gemma 或 Qwen 模型。

Verdict：面向 LLM 调用的故障关闭路由与可验证回执编排

mrnicholasbcarter-code/verdict-core · Fail-closed LLM routing: cheapest qualified model, named drop reasons, receipts.

Verdict 是一个 Python 编写的 LLM 编排与控制平面：输入一个目标和 git 仓库，先由规划模型把目标拆成小型 DAG 工作节点，再从实时网关证据（模型清单、账号、健康状态、冷却和配额）中构建准入模型集合，为每个节点分配最便宜且合格的路由，在配额、限流、超时或空回答等故障发生时进行同节点故障转移与冷却，并在节点验证、集成校验和独立评审后写入带 SHA-256 摘要的运行回执。它强调封闭失败：没有任何合格候选或重试超过上限时以命名原因 FAIL_CLOSED 并结束为 BLOCKED；被丢弃的候选都有具名理由，不透明的 auto/* 引用不作为候选，付费路由在仍有更便宜合格候选时不会被选中。执行层依赖外部工具 OmniRoute（本地 OpenAI 兼容网关）和 Prime Agent（无头编码 Agent CLI），评审使用 ocr CLI。

教一个 9B 模型调查生产告警

Datadog 的工程师把 Qwen3.5-9B 微调成一个专门做“变更归因”的小模型：告警响了以后，它能推断最近哪次部署、功能开关或配置改动最可能是元凶。原本用规则筛选又快又便宜，但遇到复杂故障就不准；用 GLM-5.3 这类前沿大模型做多轮智能体调查则准得多，可每次调用 API 约 0.06 美元，全量告警跑不起。他们用 GLM-5.3 生成的 348 起内部事故调查轨迹来训练小模型，结果小模型达到 GLM-5.3 召回率的 87%，自托管每次调查成本约 0.003 美元，约为原来的二十分之一，一张 40GB A100 每周能支撑约 10 万次调查。目前这还只覆盖客户每周数百万个监控项中的一小部分，团队称会继续优化以扩大适用范围。

Ringg 的 AI 智能体用 OpenAI 解决了最多 65% 的客户来电

客服中心常要接大量电话，Ringg 做了能自动接待的 AI 智能体，用语音、聊天、WhatsApp 和网页跟客户交流。原来用 GPT-4.1 成本高，现在换成 GPT-5.6，能处理多语言的客户咨询，最多能自己解决 65% 的来电，花费比原来少九成。对客服团队来说，这意味着更多常见问题能自动应答，人工只处理剩下的部分，省时又省钱。

Kubernetes 能跑 AI 推理，但算得清真实成本吗？

本周 Kubernetes 生态有不少进展。KubeCon 北美 2026 新增了“AI 推理与智能体”专题，说明越来越多团队把训练好的模型放到生产环境用 Kubernetes 提供服务。招商银行用 Kubernetes 加 Kueue、KEDA、HAMi、Fluid 等开源项目，把近一万张异构加速卡中 99% 的 AI 算力统一管理，平均利用率从 35% 提升到 60% 以上，处理一百万 token 的成本降低 60%。不过 WEKA 首席 AI 官提出质疑：Kubernetes 原本的资源模型管不了请求组合、KV 缓存占用、预填充与解码比例这些决定 token 成本的状态，若不加改进，可能反而成为推理经济的负担。

AI 时代的平台工程

InfoQ 举办了一场线上讨论，请来 Harness、DKB、Shine 的工程负责人聊平台工程在 AI 时代怎么变。起因是一个调查数据：94% 的工程负责人说，他们最想看的 AI 指标根本拿不到。讨论主要围绕两件事：一是哪些 AI 编程工具该由平台统一提供、哪些让团队自己选；二是过去给人类用的开发者门户，现在 AI 智能体也要直接调用，接口和权限护栏都还没有现成答案。对读者的用处是：它提醒平台团队要开始追踪 AI 花的钱和实际产出的代码，并重新设计面向人和智能体两套用户的开发体验。

AI 成本可见性：为什么有了政策仍挡不住意外账单

很多公司现在都写了 AI 花钱的规矩，比如预算上限是多少，但根本看不到钱实际花在哪儿。结果就是账单来了才发现超支，调查原因可能要好几天甚至一周。有调查显示，73% 的组织有 AI 成本政策，却只有 13% 能看清自己的 AI 开销，72% 在过去一年里被意外账单吓到过。光有政策不够，还得有能实时看到花费的手段，这样才可能提前发现哪个团队用了太贵的模型、或者重试循环把账单翻倍。

Perplexity 的 AI 智能体参与构建数据库，却无权运行它

Perplexity 公司觉得用亚马逊 DynamoDB 太贵、读性能不可控，于是让两名工程师带着数百个 AI 编程智能体，花两个月写了一个约四万行的 Rust 键值数据库 CobbleDB，现在已承担部分线上搜索流量。读取延迟从 DynamoDB 的中位 31.4 毫秒降到 5.6 毫秒，p99 从 123 毫秒降到 24.2 毫秒，预计成本至少省 20%，未来计划开源。不过 AI 智能体只帮忙写代码、查问题和跑测试，架构和生产系统仍由两名工程师掌控，没有让智能体直接碰生产数据。对读者来说，这说明 AI 辅助开发让小型团队自建基础设施变得更可行，但长期维护这套自定义数据库的成本和工程投入尚未计入，延迟对比也非同时同流量的严格基准测试。

2026 年 Kubernetes 成本管理工具对比：Kubecost、OpenCost 与 CloudZero

文章对比了 2026 年主流 Kubernetes 成本管理工具（如 Kubecost、OpenCost、CloudZero），从成本分摊粒度、多集群多云的覆盖范围、showback/chargeback 支持及定价模式等维度展开分析，并指出云厂商原生账单工具无法反映 pod 与命名空间级别的花费，建议团队按自身成熟度选型。