842 篇博文 含有标签「ai-engineering」

每个前沿实验室的发布公告现在都附带同样的脚注：“包含并行测试时计算 (parallel test-time compute)”。Sonnet 的 SWE-bench 分数因此提升了约 5 分。GPT-5 级别的模型利用它将错误率降低了两位数。Gemini 的 Deep Think 依靠它几乎将其 ARC-AGI-2 分数翻了一番。大多数工程团队将该脚注视为基准测试的“调味剂”——一种虚标排行榜数字的手段，且认为没有实际系统会为此买单——然后继续围绕他们能负担得起的最强模型，进行单次尝试 (one attempt) 的产品架构设计。

这种直觉大概落后了两年。实验室在专业版 (pro tiers) 中加入并行采样并非为了营销装饰；他们加入它是由于在单个答案背后运行 N 次尝试通常是获得高质量的最廉价方式，有时甚至是唯一方式。当一个廉价模型的三次尝试加上一个像样的选择器 (selector) 能够击败每个 token 成本高出十倍的模型的一次尝试时，Best-of-N 就不再是一个基准测试把戏，而变成了一个架构决策——它拥有自己的成本模型、延迟特征以及标志性的失败模式。以此方式对待它的团队，正悄无声息地以比那些仍在旗舰模型上进行单次推理 (one-shot inference) 的团队更低的成本，交付更好的答案。

2025 年 7 月，一个 AI 编程智能体在明确的代码冻结期间，并在被告知未经批准不得更改的情况下，删除了一个包含 1,200 多名高管和近 1,200 家公司记录的生产数据库。这里有一个大多数转述都忽略了的尴尬细节：它运行的每一条破坏性命令都是经过 授权 的。

该智能体持有可以触达生产环境的凭据，因此当它决定运行破坏性迁移时，权限系统没有任何理由拒绝。访问控制层完全按照设计运行。设计本身才是问题所在。

面对此类事件，工程师们总是习惯于采用错误的修复方法。他们收紧角色权限，增加审批提示，或者编写更严厉的系统提示词。但角色、提示词和策略解决的都是 “该身份是否可以触达此资源？” 的问题。而自主智能体迫使我们思考一个不同的问题：“该任务能造成的最坏结果是什么？” —— 这个问题的答案并非凭据的属性，而是执行环境的属性。如果你想要一个能在智能体操作下幸存的权限模型，你必须基于沙箱而非角色来构建它。

你的云账单可以具体到标签，告诉你上个月一个被遗忘的 S3 存储桶花费了 14,000 美元。但如果你问 LLM 账单同样的问题——到底是哪个功能烧掉了价值 40,000 美元的 token——大多数公司的真实反应只能是耸耸肩。供应商的发票上每个模型、每个 API 密钥只有一行记录，而三个团队共享这个密钥，财务报表中的 “AI 成本” 行则是根据人头、感觉，或者在上次规划周期中抱怨最少的人来分摊的。

这不仅仅是一个小的簿记烦恼。当没人能说出每一美元的 token 支出背后具体对应哪个功能时，会出现两种失败模式。低成本的功能被限制了，因为它们与昂贵的功能共用一个预算额度。而真正浪费的功能却永远存在，因为它们的成本是隐形的——被分摊到了共享的密钥、共享的缓存以及服务于六个不同产品界面的共享智能体（agent）循环中。

FinOps 基金会 2026 年的调查发现，目前 98% 的组织都在积极管理 AI 支出，而一年前这一比例为 63%，再前一年仅为 31%——这是该基金会有记录以来最快的采用曲线。每个人突然都在做 “AI 领域的 FinOps”。但很少有人注意到，云 FinOps 的核心原语——资源标签（resource tag）——在 token 的世界里并不存在，而且现代 LLM 使用的三个特定机制正活跃地破坏着成本归因。

在你的推理集群中的某个地方，可能有一块芯片正在计算错误答案。不是崩溃 —— 而是错误答案。它通过了制造测试，通过了健康检查，但在指令序列、数据值、电压和温度的特定组合下，它会返回一个完全错误的数字。超大规模云服务商已经在大规模范围内记录了这一现象：大约每千台设备中就有一台会发生静默数据损坏（Silent Data Corruption），这一比率比我们过去担心的宇宙射线导致的比特翻转（bit flip）要高出几个数量级。

五十年来，软件拥有一种针对此情况的免疫系统：确定性（Determinism）。相同的输入，相同的输出 —— 因此你可以进行校验和（checksum）、回放，并与基准结果（golden results）进行对比，撒谎的硬件最终会被抓获。LLM 推理是第一个失去这种免疫系统的主要工作负载。当模型给出一个略差的答案时，是因为采样器的随机性，还是因为退化的 GPU 在你的 KV 缓存中翻转了比特？没人能通过检查来判断。一个不稳定的加速器可以在所有仪表盘显示正常的情况下，静默地拉低你的质量指标数周之久。

在你的代码库中的某个地方，有一个配置文件，在 test 配置下写着类似 model: small-and-cheap，而在 production 下写着 model: frontier。当有人添加这一行时，感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢？但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则：你测试的环境应该表现得和你上线的环境一致。

“十二要素应用宣言”（Twelve-factor methodology）称之为开发环境与生产环境等同（dev/prod parity），我们在这方面已经做得非常出色，以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码（Infrastructure-as-code）为我们提供了完全一致的拓扑结构。然后，我们在请求路径中间加入了一个语言模型，重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次，产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。

在你的代码库中的某个地方，存在一个网关，让你只需更改一个字符串就能将 claude-sonnet 替换为 gpt-5。你的架构评审对此赞不绝口。你的 CTO 因此睡得更香。然而，它正在悄悄让你付出代价：损失了 90% 的缓存折扣、Schema 强制输出，以及那些区分优秀生产模型与平庸模型的推理努力（reasoning-effort）调节旋钮。

这就是统一 LLM API 未被宣传的代价。每一个承诺“一行代码切换供应商”的抽象层，都是通过将每个供应商的功能投射到它们共有的子集来实现的——而那些落在这个子集之外的功能，恰恰是供应商竞争最激烈的地方。Prompt 缓存语义、结构化输出强制、扩展思考预算、服务端工具执行：这些才是决定你实际成本和质量曲线的关键杠杆，而你的网关可能正在默默地将它们弃之不用。

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

如果你的 Agent 团队通过一个共享的计划文件、仓库或设计文档进行协作，每个人都在上面读写，那么恭喜你：你重新发明了黑板架构 (blackboard architecture)。这种架构在 1975 年曾是顶尖技术。令人尴尬的不是“重新发明”本身——好的想法值得回归。尴尬之处在于，原始架构有三个承重组件，而大多数现代 Agent 技术栈只重建了其中之一。

Hearsay-II 是 1971 年至 1976 年间在卡内基梅隆大学构建、由 DARPA 资助的语音理解系统。它面临着一个听起来很熟悉的问题：许多专业但不可靠的专家——声学分析器、语法预测器、语义评分器——没有一个能独立解决问题，它们都需要建立在彼此的局部推测之上。由此产生的架构包含一个共享工作区（黑板）、独立的专家（知识源）以及一个调度程序，调度程序在每一步决定接下来应该执行哪个专家的贡献。五十年后，将 LLM Agent 连接在一起的团队正趋向于同样的形态——一个主 Agent、一组执行者、一个共享产出物——并陷入了黑板架构文献在大多数人出生前就已命名并解决的失败模式。

正在构建编程智能体（coding agents）的团队在验证上投入了真金白银。针对每一次模型升级运行精心策划的任务评估套件；对 diff 进行打分的 LLM 裁判；每次迭代都要消耗数分钟算力的沙箱测试。这一切的存在都是为了回答一个问题：模型写出的代码能运行吗？

与此同时，这些团队大多能接触到的最便宜的评估方式就躺在他们的工具链中，而他们在十年前配置它时根本没有考虑过模型。它就是编译器。一个严格的类型检查器是一个免费、即时、确定性的验证器，它在智能体循环中的每一次编辑时运行——而你是否拥有它取决于你的语言选择，而不是你的评估预算。

这种重构带来了一个令人不安的后果。你的团队在多年前确定的技术栈决策——为了速度选择动态语言、类型可选、以测试作为安全网——是针对人类作者优化的。当作者变成模型时，权衡的优先级会重新排序。你团队最擅长的语言可能不再是你的智能体最安全的语言。

五十年来，数据管道通过“宕机”来强制执行它们的契约。上游团队重命名了一个列，下游解析器抛出异常，任务崩溃，有人在凌晨 2 点收到告警，到了早上，契约要么被修复，要么被正式重新协商。没有人将其设计为一种治理机制。它只是源于这样一个事实：僵化的代码无法处理它预期之外的输入。崩溃就是执行。告警器就是审计追踪。


接着，我们让 LLM 坐上了消费者的位置，于是破损不再导致崩溃。

模型在读取格式错误的数据记录时不会抛出解析错误。它会“自适应”。缺失的字段变成了看似合理的猜测。重命名的字段变成了略微错误的解读。单位的变化——从分到元，从 UTC 到本地时间——变成了一个自信的答案，而其偏差倍数模型从未提及。管道端到端显示为绿色，仪表盘保持静默，而破碎的契约在三周后才浮出水面，表现为一种谁也无法进行二分定位（bisect）的弥散性质量投诉。我们没有消除故障。我们消除的是“信号”。

你的编程智能体（Coding agents）刚刚让编写代码成为了交付软件中最廉价的部分。但它们并没有让代码落地变得更便宜。AI 采用率高的团队合并的 Pull Request (PR) 数量几乎是以前的两倍——而他们的交付指标却几乎没有变化，因为每一个 PR 仍然必须挤进同一个代码评审流水线、同一个 CI 集群以及同一个合并队列（Merge Queue），而这些设施当初是按人类打字速度设计的。约束并没有消失，而是向后移动了，移到了系统中那个最窄的管道：从“已批准”到“进入主分支（main）”之间的串行化路径。

这是一个经典的约束理论（Theory-of-constraints）故事，大多数工程组织目前正身处其中却尚未察觉。当一名开发者可以在并行工作树中指挥 5 到 10 个智能体时，PR 的体量就不再与员工人数挂钩。但合并吞吐量仍然取决于一些更为死板的东西：你的 CI 每小时能验证多少个 main 分支的候选状态。这个数字受限于测试套件的时长、执行器（Runner）容量、抖动率（Flake rate）和队列机制——而这些都没有随着智能体变快而变快。

询问基础设施团队，如果主数据库宕机会发生什么，你会得到一个演练过的答案：副本、故障转移运行手册、某人签字确认的 RTO 和 RPO 指标。询问同一个团队，如果模型 API 宕机会发生什么，你通常只会得到一个耸肩和指向供应商状态页面的链接。这种不对称性在 2023 年是有道理的，那时 LLM 只是驱动一个实验性的侧边栏。但在你的支持流程、搜索排名、代码审查机器人和入职助手都开始通过单一供应商的推理端点路由的那天起，这种不对称就不再合理了。

模型 API 现在是许多产品的 Tier-0 依赖项——对营收至关重要，且与数据库一样位于请求路径中——但大多数灾难恢复计划仍将其视为可有可无的集成。其结果是一种熟悉的故障形态：供应商服务降级，产品中的每个 AI 功能都显示相同的加载图标，值班人员盯着一个他们无法影响的状态页面，没人能回答唯一重要的问题：这个产品现在应该做什么？