更低的智能体账单可能意味着多种情况。团队也许为任务找到了更好的模型，修复了反复重试的工作流，或者停止了耗时过长的检查。仅看账单，这些变化看起来同样有利。
对于工程负责人来说，难点在于弄清这笔钱买到了什么。我们希望降低交付成本，但我们也积压了一批从未被排到足够高优先级的维护工作。其中一些工作现在也许负担得起了。管理这座工厂意味着既要决定在哪里多花钱，也要决定在哪里削减开支，并且要在月度账单到来之前掌握足够的信息来做出这些决定。
我会把七个方面纳入工厂的运作方式：
- 可见性与归属： 为团队提供成本数据，并赋予其据此采取行动的权限。
- 任务准入： 在开始工作前评估可能的收益。
- 路由： 根据完成任务的完整成本选择模型。
- 确定性： 尽可能用检查替代重复性的模型决策。
- 边界： 设定预算并停止无产出的循环。
- 价值： 把否则会被搁置的维护工作纳入核算。
- 问责： 在预算紧张时保持“完成”的定义不变。
1. 为团队提供成本数据和控制权
每一次模型调用、工具操作和工作流都应报告其成本，并归到触发它的任务上。要把估算值与实际费用区分开，并在可以衡量的情况下计入基础设施、重试、审查和返工。失败的尝试也应计入计算。如果十个同类任务消耗了一份预算而只有六个成功，只报告成功六个的成本会让流程看起来比实际更便宜。
FinOps 为我们提供了一种有用的组织方式。工程团队管理工作流预算，并决定如何改进其使用情况。平台和 FinOps 团队提供计量、分摊、仪表盘和预算执行。领导层、产品和财务部门就投入多少以及预期结果达成一致。团队需要有余地自行更改路由或停止浪费的工作流，并在工作确实需要时有一个明确的申请更多预算的流程。
把成本信息放在团队已经在工作的地方：工作流结果旁边、拉取请求摘要中，或团队的交付审查中。显示支出、剩余预算和完成状态。如果依赖更新反复撞上同一个损坏的构建环境，团队可以修复该环境，而不是为每次更新再付一轮排查的费用。只有当有人能根据仪表盘显示的内容采取行动时，它才有用。
2. 在开始工作前评估任务
在任务准入阶段，确定这项工作的价值以及如果它一直不被完成会怎样。紧急的生产修复和探索性功能会有不同的支出额度。分别记录预期收益、估算成本和授权预算。随着智能体了解更多，估算可能会变化；但这不应自动增加它的支出权限。
我们本来就很难估算不熟悉的工程工作。把估算委托给智能体并不能消除不确定性。一个小修复可能暴露出缺失的测试环境或依赖迁移。以可比的已完成任务为起点，说明比较在何处失效，并在精确数字只能靠猜测时使用区间。
对于不确定的工作，先为调查编列预算。智能体可以检查故障、识别可能的更改，并在实施开始前带着修订后的估算返回。如果任务已经变成了一次迁移，团队应明确做出这一决定。否则，一笔适度的调查预算可能变成没人打算做出的无期限承诺。
3. 按完成任务的成本选择模型
常规分类和困难调查默认不需要相同的模型。尝试满足要求的最便宜方法，但要考虑它失败时会发生什么。一次更便宜的调用随后伴随反复纠正和升级，可能比从一开始就使用能力更强的模型花费更多。使用已完成的工作及其所需的审查工作量来比较各条路由。
也要看模型被要求读取的内容。完整的构建日志、大型工具响应和未使用的工具定义都会增加输入。在需要时加载工具，并在把结果发回之前进行过滤。对于失败的构建，相关错误和足够的上下文可能比再复制一份完整日志更有用。
缓存有助于处理稳定的上下文，前提是工作流确实复用了它。检查对提示或工具定义的更改是否破坏了这种复用。在代表性任务上测试这些更改后再推广，并同时关注质量和纠正工作量以及账单。节省了成本却给审查者带来更多工作，可能仍是一笔糟糕的交易。
4. 把重复性决策变成检查
一些重复性的模型调用最终应该消失。检查必填字段、执行既定的依赖策略或验证生成的文件，通常可以由代码处理。智能体可以帮助制定规则并编写检查。一旦团队验证了它，就没有什么理由再让模型在每次运行时做出相同的决策。
例如，处理依赖更新的智能体可能会发现一个不断导致失败的兼容性要求。团队可以把它变成针对未来更新的检查，让智能体去调查例外情况。该检查需要测试和负责人，就像构建系统的任何其他部分一样。在一次成功运行中生成的脚本还不是一个受维护的组件。
进行这种转换是有成本的，所以从频繁调用和不太可能改变的规则开始。使用工作流记录来找出重复的调查和验证。随着时间的推移，工厂应该传承团队已经学到的东西，而不是每次都花钱重新发现它。
5. 设定预算并停止无成效的循环
智能体可能会不断重新运行测试或重写补丁，却始终无法更接近解决方案。在执行系统中为重试次数、经过时间和花费设定限制。要明确每个限制触发时会发生什么。阻止一个工具可能会让智能体转而使用另一个工具，而限制调用次数并不能说明这些调用可能有多昂贵。
预算必须包含委派出去的工作。不应允许多个智能体各自花费相同的剩余余额。在工作启动时预留资金，并在之后与实际使用情况对账。在增加智能体之前，考虑任务能否被有效地拆分。相互独立的调查可能受益于并行工作；对共享代码的更改可能需要足够的协调，以至于抵消预期的节省。
在再次尝试之前，检查发生了什么变化，使这次尝试有更大的成功机会。当预算耗尽时，保存部分工作并说明哪些问题仍未解决。团队随后可以决定是继续、改变方法，还是放弃该任务。在满足验收标准之前，状态应保持为未完成。
6. 考虑那些从未被完成的工作
设想一个积压清单，里面有过时的文档、被忽视的测试和依赖项升级。如果智能体开始处理这些工作，支出可能会上升。声称相对于这些任务本可能占用的人工工时实现了节省，前提是有人本来会投入这些工时。在许多团队中，这些工作只会一直留在积压清单里。
对于团队已经定期完成的工作，比较达到同等结果所需的成本，包括仍然需要的人工审查和纠正。对于新开展的维护工作，报告现在覆盖了什么以及维持它需要多少成本。更新依赖项或为先前未测试的组件添加测试，可以证明支出是合理的，而无需将其换算成假设节省的工时。
要清楚哪些收益已经观察到，哪些仍是预期。填补已知的维护缺口是可衡量的；将现金节省归因于可能永远不会发生的事件则要难辩护得多。领导层可能会认为更广泛的维护覆盖值得更大的预算。这应该是一个可见的投资决策，并由某人负责检查它是否带来回报。
7. 保持“完成”的定义不变
要求尽量降低成本的指令留下了太多未明确之处。智能体还需要商定的范围、验收标准、必需的检查以及预算。在工作流中强制执行这些检查，并预留足够的预算来运行它们。如果实现在验证之前就用完了额度，结果就是一个未经验证的更改。团队需要看到这种状态，而不是在审查期间或部署之后才发现。
将成本与完成率、返工和质量一并审查。当工作流变得更便宜时，检查发生了什么变化。它可能消除了不必要的调用、把工作转移给了审查者，或者省略了任务所需的某些内容。即使它们在模型支出上产生了相同的减少，其后果也各不相同。团队需要细节和权限，以便无需等待财务审查就能纠正问题。
这些选择的责任仍由工程领导层承担。给团队他们能够管理的预算，让他们在收益明确时在维护上花更多钱，并要求提供工作已完成的证据。在接受成本降低之前，要求团队展示他们改变了什么，以及哪些工作仍然会完成。
如果今天的节省变成明天的事故或别人的积压，你并没有降低成本。你只是改变了由谁来承担代价。