砍掉那个工作负载，而不是那个项目。
上个季度，接近半数的企业负责人因成本盖过价值而收缩了智能体部署，而那条发现的措辞——收缩、收窄、推迟或暂停——是同一件钝器作用于整个部署的四个名字。你该切的单位是任务类，因为在任何真实的部署内部，有些工作流的成本能把人工基线甩开 50 倍，另一些则每跑一次都在亏钱，而砍部署会把两者一起砍掉。
你反应的颗粒度，由你数据的颗粒度决定。
一个最细成本事实就是月度发票的团队，恰好只有一根杠杆，那就是整个部署。一个拥有按任务类拆分的"每完成任务成本"的团队有四根——其中三根能保住价值。选哪根杠杆不是判断力或胆识的问题；它在归因的下游，而再多的高层决心也替代不了它。
这话值得直说，因为收缩通常会被叙述成一种纪律。它更常是一种"没有别的选项"。当有人提议收缩时，该问的不是"这个判断对不对"，而是"我们本可以切的最小的东西是什么，为什么切不了？"后半句的答案才是真正的问题。
同一个部署内部，任务类之间相差数量级。
智能体部署从来不是一个经济对象。它是一个投资组合，而组合平均值把一切要紧的东西都藏了起来。一个处理三条工作流的客服部署，可能长这样：
# cost per COMPLETED task vs the human baseline it replaced ticket_triage $0.11 baseline $6.00 # 55x — expand this refund_processing $0.640 baseline $2.40 # 3.8x — healthy doc_reconciliation $4.10 baseline $1.80 # 0.44x — this is the loss # Blended: $1.62 vs $3.40 baseline. The deployment "works". # Cut doc_reconciliation alone: blended drops to $0.38.
那个混合后的数字说这个部署是赚钱的，这既属实又没用。全面收缩 30% 会砍掉三分之一的分诊量——组合里经济性最好的那一块——只为了压掉一笔完全长在另一条工作流里的亏损。只砍那一条工作流，亏损没了，收益一分不少。
让这一切显形的指标是"每完成任务成本"，而不是每次运行成本。一条 40% 会失败的工作流，为那些失败付了全价，然后为重试或人工善后再付一次，而只有"已完成任务"这个分母才把它老实地标了价。见智能体的单位经济。
在给这个类定罪之前，先把长尾切出去。
一个亏损的任务类往往并不是均匀地在亏。定罪之前先看分布：在多数部署里，一小部分运行——那些输入病态、数据缺失，或者循环压根没收敛的——吞掉了极不成比例的开销。每完成任务 $4.10 的单据核对，中位数可能是 $0.90，而 p99 是 $38。
- 把长尾路由出去，留下头部。一道前置检查，把最难的那 8% 直接送给人，常常能把一个亏损的类变成一个赚钱的类，而完全不动那已经跑得好好的 92%。
- 先封顶，再开刀。按任务的步数与 token 上限，把一条无界的长尾变成有界的。如果加了上限这个类就赚钱了，那问题从来就不是这条工作流。
- 看看失败在下游花了多少。一次便宜的运行如果给复核者制造了活儿，那它只是把成本挪走了、而不是消掉了；人工复核正是那条不会自己缩小的开销。
只有在长尾被封住之后这个类仍然在亏，它才真的是个亏损的类。在那之前给它定罪，定的是你自己步数上限的罪。
四种动作，按精细度排序——其中三种能保住价值。
当一个类确实不赚钱时，反应的阶梯从精确走向粗钝。取你有数据支撑的最高那一级。
- 重新调优这个类。缓存稳定前缀、在分类那一跳换上小模型、别再把整份文档塞回对话记录、给步数封顶。在多数系统里这些比任何换模型都更能撬动账单，而且不损失能力——见智能体成本控制。
- 收窄这个类。在它能跑赢基线的那个细分上保留这条工作流，其余路由回老路径。按输入类型、租户或复杂度分档来收窄，几乎总是可行，也几乎从没人试。
- 退役这个类。关掉一条工作流，保住部署，把腾出来的预算重新投到比值最好的那个类上。这正是调查数据显示几乎没人做的那个动作。
- 暂停整个部署。唯一一个不需要按类数据就够得着的级别，也是唯一一个不分青红皂白摧毁价值的级别。作为对失控的应对它是正当的——那正是急停开关的用途——而作为对经济性问题的应对，它很少是对的。
暂停不是中性的搁置，而它的账单是隐形的。
在表格上，暂停读起来像是开销归零而选择权仍然敞开。这里有三处不对。
- 基线死了。一旦人工流程恢复，你之后要用来论证重启的那个比较就得重建——而人们记得的那个版本，会是当初赢下争论的那一方所偏爱的版本。
- 重新启动不是免费的。提示词与已经改过的产品失了同步，可用的模型已经换代，评测集过期，而当初握着上下文的那些人已经在做别的事。重启的成本是最初搭建成本中相当可观的一部分，而没人为它做预算，因为暂停当初是以"可逆"的名义被框定的。
- 学习停了。生产信号是唯一能告诉你哪个类还有救的东西。一个暂停的部署不产生任何证据，于是半年后的重启决定，用的还是当初促成暂停的那批信息。
如果非暂停不可，请留一个任务类以低流量活着——留经济性最好的那个，不是留那个正被怀疑的。它花不了多少钱，却保住了基线与评测回路，也意味着重启是一次扩容而不是一次重建。
在下刀的同时，把恢复条件写下来。
每一次收缩都该连同它的逆操作一起交付：让这件事回来的那个具体、可核验的条件。没有它，这一刀默认就是永久的，因为没有触发器，没人会去重开一个已经了结的问题。
- 写一个数字，不是一种情绪。"当这个类的每完成任务成本连续四周低于 $1.80 的人工基线时复审"，而不是"等技术成熟了再看"。
- 写一个去核对它的日期，并放进某个人的日历。模型价格、缓存行为与上下文上限都在动；条件可能已经满足而无人察觉。
- 把你砍了什么、为什么砍记录下来，详细到足以让接手的人分辨出这是一次量过的退役还是一次预算面前的缩手。这两者半年后读起来一模一样，含义却相反。
在同意任何一刀切的削减之前，先花那两天，把开销按任务类拆开、并与任务结果连起来。在我们见过的每一个组合里，分布都失衡到这样一个程度：单单这一刀——退掉最差的类、扩张最好的类——在成本与价值两侧都胜过按比例削减。如果那两天确实挤不出来，那就砍掉已知"每完成任务成本"最高的那一条工作流，而不是砍掉所有东西的一个百分比：在正确颗粒度上的一次猜测，胜过在错误颗粒度上的精确。
相关：衡量智能体的 ROI——这一切所依赖的那个分母；经济性在哪里崩掉——制造亏损类的那些模式；以及何时该用智能体——那些本就不该进入范围的工作流。