Agent 的最后一道现实约束，不是智能，而是经济学。
很多架构在理论上很好，在小规模演示里也很好，但一进入真实流量就开始暴露问题：
- 成本过高
- 延迟过长
- 并发太差
- 调试太贵
- 失败重试成本巨大
这说明一个现实：
Agent 的设计，最终一定要回到运行经济学。一个成熟系统必须同时平衡：
- 智能质量
- 响应速度
- 成本开销
- 稳定性
- 可恢复性
这会带来很多非常不浪漫、但极其关键的设计选择：
- 要不要分层模型
- 要不要缓存
- 要不要预计算
- 哪些步骤同步，哪些异步
- 哪些动作可自动重试，哪些必须停下来
- 哪些错误可以容忍，哪些必须立刻中断
但如果只把这些问题理解成“上线之后再优化一下”，还是太轻了。
第 30 章真正想说的是：对 Agent 来说，运行经济学不是后期优化题，而是架构前提。
因为 Agent 的成本结构，和传统接口型软件并不一样。
一个普通服务的单次成本，大多由固定计算和存储决定；Agent 的单次成本，却往往由很多不稳定项组成：
- token 消耗
- 长上下文读入
- 多次模型调用
- 工具调用费用
- 外部 API 成本
- 审批等待时间
- 失败重试次数
- trace、日志与回放开销
也就是说，Agent 的单次任务成本不是一个常数，而是一条分布。
这会带来一个非常关键的变化：
Agent 架构的优劣，不能只看“平均能不能做成”，还要看“在真实流量下，每完成一个任务要花多少钱、等多久、失败后多难恢复”。所以，第 30 章第一条结论应该是：
Agent 的生产可行性，本质上不是能力上限问题，而是单位任务经济性问题。一旦进入这个视角，很多团队在 demo 阶段忽视的问题，就会全部浮出来。
先看成本。
很多 Agent 在小规模试用时看起来并不贵，因为样本量小、上下文短、失败少、人类还在旁边盯着。 但只要任务复杂度上来，成本会迅速呈非线性增长：上下文变长，规划链变长，工具调用变多，失败重试开始出现，审计和观测也必须打开。此时真正昂贵的，往往不只是模型本身，而是“为了让这次任务成功，系统沿途消耗掉了多少无效步骤”。
因此，成本优化不是简单地换便宜模型，而是压缩无效推理、减少无效调用、减少不必要长上下文、减少不必要重试，以及把高成本模型只放在真正需要的步骤上。
再看延迟。
Agent 的延迟和普通问答延迟也不一样。
普通问答大多只有一次前向生成；Agent 的延迟往往是多段串联的：读上下文、推理、选工具、等工具返回、再推理、再写状态、再确认、再继续。单步都不慢，不代表整条链不慢。尤其在真实环境里，用户感知的不是平均延迟，而是尾延迟。只要有几步偶尔拖慢，整条任务链的等待时间就会迅速放大。
这就是为什么 Tail Latency 对 Agent 特别重要。
一个 8 步流程里，只要其中两步进入长尾，整体体验就会恶化得非常明显。于是，系统设计必须开始做 timeout budget、step budget、并行化、前置预取、异步拆分和快速失败，而不能只盯着单次模型响应速度。
然后看并发。
很多 Agent 架构在单任务演示里非常优雅，一旦并发上来就暴露脆弱性。原因很简单：Agent 不是只占一次算力，它会占一段会话、一串工具、一组状态对象、若干外部 API 配额，以及一条可能持续很久的执行链。并发一上来，排队、配额争抢、锁竞争、外部依赖抖动、共享缓存击穿都会一起出现。
因此，并发问题不只是“多开几台机器”。
真正的关键在于：
- 哪些步骤可以并行
- 哪些步骤必须串行
- 哪些会话必须独占资源
- 哪些结果可以缓存和复用
- 哪些请求应当被限流、排队或直接拒绝
如果这些问题没有被系统地想清楚，Agent 很容易在高峰流量下从“聪明”变成“堵塞”。
再看容错。
容错在 Agent 系统里最容易被误解成“失败了就再试一次”。 这在很多情况下恰恰是灾难来源。
因为 Agent 失败并不总是暂时性失败。它可能失败于错误前提、错误工具、错误状态、错误权限，甚至失败于本不该自动继续的场景。此时盲目重试，只会把错误成本再付一遍，甚至把问题越滚越大。
所以，成熟的容错不是无限重试，而是区分失败类型：
- 可重试的瞬时错误
- 需要回滚的状态错误
- 需要降级的成本错误
- 需要升级到人的治理错误
- 必须立即熔断的系统性错误
只有做了这种区分，重试、fallback、circuit breaker、graceful degradation 和 kill switch 才真正有意义。
因此，第 30 章第二条结论应该是：
Agent 的容错，不是把失败藏起来，而是把失败分型，并用最便宜、最安全、最可恢复的方式处理它。到了这里，运行经济学的真正含义就清楚了。
它不是一个财务部门的后验报表，而是一套会直接反向塑造架构的现实约束。它会逼迫系统回答：
- 这一步值不值得再调用一次大模型
- 这段上下文值不值得完整重放
- 这个工具要不要提前缓存结果
- 这类任务能否先用小模型分流
- 这个流程应该同步返回，还是异步交付
- 这类异常应该自动恢复，还是立刻中止
换句话说，运行经济学会把“最聪明的系统”改造成“最划算且最稳的系统”。
这也是为什么真正成熟的 Agent 产品，最后都会逐渐长成相似的样子：分层模型、预算控制、缓存、批处理、异步拆分、观察面板、限流、重试上限、审批门槛、回放与复盘。它们看上去不如 demo 浪漫，但恰恰决定了系统能否被持续运营。
所以，本章最后要落下的判断是：
一个真正走向生产的 Agent，最后一定会从“展示智能”转向“经营智能”；而经营智能，本质上就是经营成本、延迟、并发和失败。