谁来承担 AI 软件工厂的成本？

更低的智能体账单可能意味着几件事。团队可能为任务找到了更好的模型，修复了反复重试的工作流，或者停止了运行耗时过长的检查。仅看账单，这些变化看起来同样有益。

对于工程负责人来说，难点在于知道钱买到了什么。我们想降低交付成本，但我们也有一堆从未被排到足够高优先级的维护积压。其中一些工作现在可能变得负担得起。管理工厂意味着决定在哪里多花钱、在哪里削减，并在月度账单到来之前有足够的信息做出这些决定。

我会将七个方面纳入工厂的运作方式：

可见性与归属：为团队提供成本数据并赋予其据此行动的权力。
准入：在开始工作前评估可能的收益。
路由：基于完成任务的全部成本选择模型。
确定性：尽可能用检查替代重复的模型决策。
边界：设定预算并停止无产出的循环。
价值：将否则会被搁置的维护工作纳入考量。
问责：在预算紧张时保持“完成”的定义不变。

1. 为团队提供成本数据和控制权

每一次模型调用、工具操作和工作流都应报告其相对于引发它的任务的成本。将估算与实际费用区分开，并在可衡量的情况下纳入基础设施、重试、审查和返工。失败的尝试也应计入计算。如果十个可比任务消耗了预算而只有六个成功，仅报告成功六个的成本会让流程看起来比实际更便宜。

FinOps 为我们提供了一种有用的组织方式。工程团队管理其工作流预算并决定如何改进使用。平台和 FinOps 团队提供计量、分配、仪表盘和预算执行。领导层、产品和财务部门就投入多少以及预期结果达成一致。团队需要空间自行更改路由或停止浪费的工作流，并在工作值得时通过清晰的流程申请更多预算。

将成本信息放在团队已经工作的地方：工作流结果旁边、拉取请求摘要中，或团队的交付审查中。显示支出、剩余预算和完成状态。如果依赖更新反复遇到同一个损坏的构建环境，团队可以修复该环境，而不是为每次更新的又一轮调查付费。当有人能根据仪表盘显示的内容采取行动时，仪表盘才有用。

2. 在开始前评估工作

在准入阶段，确定工作的价值以及如果搁置会发生什么。紧急的生产修复和探索性功能会有不同的支出额度。分别记录预期收益、估算成本和授权预算。随着智能体了解更多，估算可能会变化；这不应自动增加其支出权限。

我们已经在估算不熟悉的工程工作方面苦苦挣扎。将估算委托给智能体并不能消除不确定性。一个小修复可能揭示缺失的测试环境或依赖迁移。以可比的已完成任务为起点，解释比较在何处失效，并在精确数字只是猜测时使用范围。

对于不确定的工作，先为调研预留预算。智能体可以检查失败原因、识别可能的改动，并在开始实施前返回修订后的估算。如果任务已经演变成迁移，团队应当明确做出这一决定。否则，一笔适度的调研预算可能变成没人打算做出的无期限承诺。

3. 根据完成任务的成本选择模型

常规分类和困难调研默认不需要相同的模型。尝试满足要求的最低成本方案，但要考虑它失败时会发生什么。一次更便宜的调用，随后反复纠正并升级，可能比从一开始就使用能力更强的模型成本更高。用完成的工作及其所需的审查工作量来比较各条路线。

还要看模型被要求读取的内容。完整的构建日志、大型工具响应和未使用的工具定义都会增加输入。在需要时加载工具，并在发回结果前进行过滤。对于失败的构建，相关错误和足够的上下文可能比再复制一份完整日志更有用。

缓存对稳定的上下文有帮助，前提是工作流确实复用了它。检查提示词或工具定义的变更是否破坏了这种复用。在代表性任务上测试这些变更后再推广，并同时关注质量和纠正工作量与账单。节省成本却给审查者带来更多工作，可能仍是一笔糟糕的交易。

4. 将重复性决策转化为检查

有些重复的模型调用最终应当消失。检查必填字段、执行既定的依赖策略或验证生成的文件，通常可以由代码处理。智能体可以帮助制定规则并编写检查。一旦团队验证通过，就没有理由让模型在每次运行时都做同样的决策。

例如，处理依赖更新的智能体可能发现一个反复导致失败的兼容性要求。团队可以将其转化为未来更新的检查，让智能体去调查例外情况。该检查需要测试和负责人，就像构建系统的其他部分一样。在一次成功运行中生成的脚本还不是一个受维护的组件。

进行这种转换是有成本的，所以从频繁调用和不太可能改变的规则开始。使用工作流记录来发现重复的调研和验证。随着时间推移，工厂应当传承团队所学到的东西，而不是每次都花钱重新发现。

5. 设定预算并停止无成效的循环

智能体可能不断重新运行测试或重写补丁，却丝毫没有接近解决方案。在执行系统中对重试次数、经过时间和花费设定限制。明确每个限制触发时会发生什么。阻止一个工具可能让智能体自由使用另一个工具，而限制调用次数并不能说明这些调用可能有多昂贵。

预算必须包含委派的工作。不应允许多个智能体各自花费相同的剩余余额。在工作启动时预留资金，并在之后与实际使用情况对账。在增加智能体之前，考虑任务是否能被有效拆分。独立的调研可能受益于并行工作；对共享代码的更改可能需要足够的协调，从而消耗掉预期的节省。

在再次尝试之前，先检查发生了什么变化，使这次尝试有更大的成功机会。当预算耗尽时，保存部分工作并说明哪些问题仍未解决。团队随后可以决定是继续、改变方法，还是放弃该任务。在满足验收标准之前，保持状态为未完成。

6. 考虑那些从未被完成的工作

设想一个积压清单，里面是过时的文档、被忽视的测试和依赖项升级。如果智能体开始处理这些工作，支出可能会上升。声称相对于这些任务本可能耗费的人工工时实现了节省，前提是假设有人本来会投入那些工时。在许多团队中，这些工作只会一直留在积压清单里。

对于团队已经定期开展的工作，比较达到同等结果所需的成本，包括仍然需要的人工审查和纠正。对于新承担的维护工作，报告现在覆盖了什么以及维持它需要多少成本。更新依赖项或为之前未测试的组件补充测试，可以证明支出是合理的，而无需将其换算成假设节省的工时。

要明确哪些收益已经观察到，哪些仍是预期。填补已知的维护缺口是可衡量的；将现金节省归因于可能永远不会发生的事件则难以站得住脚。领导层可以决定，更广泛的维护覆盖值得更大的预算。这应该是一个可见的投资决策，并有人负责检查它是否带来回报。

7. 保持“完成”的定义不变

要求最小化成本的指令留下了太多未明确之处。智能体还需要商定的范围、验收标准、必需的检查和预算。在工作流中强制执行这些检查，并预留足够的预算来运行它们。如果实现在验证之前就用完了额度，结果就是一个未经验证的变更。团队需要看到该状态，而不是在审查期间或部署之后才发现它。

将成本与完成率、返工和质量一并审查。当工作流变得更便宜时，检查发生了什么变化。它可能消除了不必要的调用、将工作转移给了审查者，或者省略了任务所需的某些内容。即使它们带来相同的模型支出减少，这些情况的后果也各不相同。团队需要细节和权限来纠正问题，而无需等待财务审查。

这些选择的责任仍由工程领导层承担。给团队他们可以管理的预算，让他们在收益明确时在维护上花更多钱，并要求提供工作已完成的证据。在接受成本降低之前，要求团队展示他们改变了什么，以及哪些工作仍然会完成。

如果今天的节省变成明天的事故或别人的积压，你并没有降低成本。你只是改变了由谁来承担代价。