控制工程：为何人工智能智能体成本不断飙升

两年来，各类新闻报道都在强调同一个观点：工程师成本高昂，而人工智能助手成本较低；那些永不休息、从不抱怨且仅需极低薪资的数字员工会让人力替代成为必然趋势。然而最近，在一些极具技术前瞻性的公司的规划会议上，相关数据却开始反驳这一观点。

两家公司，两次警醒

2025年底，微软向内部工程团队开放了Claude Code。该工具深度融入了日常工作流程，开发人员也对其十分满意。但到2026年中，微软开始收回这些许可证，转而推荐成本更低的内部解决方案，比如GitHub Copilot CLI。

Uber的情况更为严峻。2026年4月，其首席技术官承认，原本为AI编程工具准备的2026年全部预算在仅四个月内就已耗尽。84%的工程师开始使用这些工具，使用情况甚至演变成全公司的竞赛游戏，还有位工程主管在短短两小时的演示中就消耗了1,200美元的代币。

这些AI系统从未停止运行，只是成本高得难以持续。对于那些正在构建智能体系统的人来说，这一情况意味着很容易达到一个上限：一个自主数字员工的计算成本可能会超过它本应替代的人的薪资。

解决之道是一种即将成为强制要求的规范，即“约束工程”。

为何智能体的成本远高于聊天功能

聊天提示词与自主智能体是完全不同的概念。向标准语言模型提问时，整个过程只需一步：你提问，它回答，交易即完成。

而智能体则需要实现开放式目标。当被要求修复漏洞时，它会读取文件、制定计划、编写修改代码、运行测试并评估结果。如果测试失败，它会重新开始循环，再次思考、重写代码并测试。每一个步骤都会产生费用。

实际的软件开发工作使得这成为一项重大的财务风险。SWE-bench是一种基于真实生产代码中的漏洞设计的行业标准测试，目前最优秀的智能体也只能解决其中不到一半的任务。因此，对于超过一半的漏洞，智能体只能尝试、失败、重试、再次失败，最终放弃。

想象一下这样的水管工：每次掉下扳手就要按全时费率收费，每次走到货车旁都要计费，而且管道还在漏水时他就离开。在企业规模下，出故障的智能体任务就如同这样的水管工——掉下的扳手对应的费用仍需全额支付。

与聊天窗口相比，Token消耗量并非仅仅翻倍。通常情况下，智能体的Token消耗量会是普通情况的5到30倍，而在复杂调试场景中，失控的智能体其Token消耗量甚至可能超过普通查询的1,000倍。

两条分道扬镳的成本曲线

人类经济与人工智能经济遵循不同的发展曲线。初级开发人员能力提升时，其产出会增加，但薪资大致保持不变——他们只是变得更快、更高效而已。

面对复杂问题的智能体需要更多的推理步骤、重试次数以及上下文窗口的使用，因此token费用会急剧上升。问题越复杂，成本就越高。

硬件性能的提升无法解决这一问题，因为软件需求增长的速度超过了成本节省的幅度。微软目前在其数据中心使用的Maia 200芯片，每美元产生的token数量明显优于旧硬件。然而，叠加在上面的智能体任务会立刻耗尽所有这些节省的成本。更便宜的token只意味着智能体会以指数级的方式要求更多token。

因此，将智能体放到整个企业代码库中让其自行运行的想法已经不可行，因为从数学角度来说行不通。不过智能体本身并非毫无用处，围绕它们的架构必须尽快做出改变。

限制机制设计

对于任何开发人工智能应用的人来说，提示工程已不再是唯一需要处理的任务。现在更关键的是“约束工程”：为模型设置严格的边界、状态限制以及财务触发机制，确保机器在产生高额费用之前展现出其价值。

这种担忧是有现实依据的。想象一下基于 Next.js 16、TypeScript 和 Azure OpenAI 构建的库存管理系统，与担心自主智能体陷入推理循环并在一夜之间耗尽云服务额度相比，延迟和幻觉问题几乎可以忽略不计。在 Modal 平台上处理数千条 ClinVar 参考序列的基因组分析任务也是如此，一旦达到两小时的执行时间限制，就会触发中断。那种情况只是按秒计费的普通计算任务；而处于相同场景下的递归智能体若按每个标记计费，将会产生巨额费用。

有四种方法能让约束工程得以有效实施。

1. 按难度路由请求

最常见的错误是将所有 API 调用都指向 GPT-5 或 Claude 4.5 Opus 这类顶级模型。这种做法属于暴力尝试，会迅速耗尽资源。实际上，路由层应该位于系统架构的最前端。路由器是一种轻量级且成本极低的模型，它能够检查每个传入的任务，并判断哪款大语言模型真正具备处理该任务的能力。

[ Incoming User Request ]
           |
      [ Router ]
      /        \
[ Simple ]  [ Complex ]
      |          |
[ Llama 3 ] [ Flagship LLM ]

简单的数据提取或基础格式化任务可以交给开源的8B模型或经过调优的微型模型来完成；而需要复杂逻辑的工作则需使用成本更高的旗舰级模型。这一改变就能将API使用成本降低多达80%，同时不会影响应用程序的质量。

2. 绝不允许无限制的重试循环

允许编写代码、进行测试并在失败后重试的智能体需要设置硬编码的重试次数上限。不过单纯的整数限制并不够，因为每次尝试都会增加上下文信息。第三次尝试的成本会明显高于第一次，因为提示词中已包含了前两次失败的记录。

应设置成本预警机制。在智能体开始下一个递归步骤之前，中间件函数会估算即将处理的请求所需的令牌成本。如果当前会话的累计成本超过预先设定的严格限制，系统会立即终止该进程，并标记出来供人工开发者检查。

3. 剪枝上下文

在尝试失败后，智能体通常会将原始错误日志附加到之前的提示中再重新尝试。这就是成本呈指数级上升的原因。上下文剪枝机制可以解决这一问题——它不会将完整的冗长错误历史传递给主模型，而是让成本较低的路由模型对故障状态进行简化处理。

通过类似“用两句话简要说明此次故障的确切技术原因”的指令，将庞大的错误日志输入到成本较低的模型中。只有这两句话会被传回主智能体用于下一次尝试。通过刻意剪枝上下文窗口，令令牌数量呈线性增长而非指数级上升。

4. 保留人类作为最终控制手段

长期以来，让人类介入流程一直被视为一种临时的安全措施，但现在却已成为一项严格的财务要求。开发人员的职责变成了监控智能系统，一旦其陷入高成本的故障状态就要立即干预：检查输出结果、确认技术方向，并在进程失控导致冲刺计划预算耗尽之前将其终止。

这一转变的意义

Duolingo最近放宽了其对人工智能取代人工这一问题的公开立场。与微软和优步一样，它也意识到一个基本事实：人类是目前最便宜的思考工具。开发人员凭借灵活的思维，仅需一份三明治和充足的睡眠就能工作，而且绝不会为了停下来思考而向公司收取高额费用。

一个普通的电子表格就打破了那些无限且廉价的智能体的幻想。对于刚进入这个行业的开发者来说，这是个好消息，因为尽管日常职责在变化，相关岗位依然稳定存在。工作方式正从手动编写每一行代码，转变为设计和构建能够自动编写代码的系统。

实用的建议很简单：在人工智能架构中设置严格的路由机制，对智能体采取严格的管控措施，并像对待内存堆一样谨慎管理令牌预算。软件工程的未来属于那些能够掌控机器、控制其成本，并在它出问题时及时停止使用它的人。