Agent 预算调度：会拆任务之前，先会算成本

一、Agent 不是越勤快越好，预算先得管住

Agent 系统一旦接入计划器、工具调用和多轮反思，调用次数会很快膨胀。一个用户问题，本来一次模型调用能回答，计划器拆成五步，工具调用三次，评审器再跑两轮，账单和延迟都跟着上来。工程落地不能只问"能不能完成任务"，还要问"值不值得这么完成"。

预算调度要放在 Agent 执行链路前面。每个任务先估算模型调用、工具调用、检索、重排和生成成本。高价值任务可以给更大预算，低价值任务要走轻量策略。别等月底账单来了，再回头说 Agent 太贵。

我第一次看到 Agent 账单的时候，某个内部数据分析 Agent 的单次调用平均 token 消耗是普通问答的 18 倍。分解后发现：计划器一次（2000 token）、工具调用五次（平均每次 800 token）、评审器两次（每次 1500 token）、最终生成（1000 token），加起来超过 12000 token。而其中三次工具调用是冗余的——Agent 查了同一个数据库三次，每次只是换了一个过滤条件。如果有预算调度，第二次冗余调用就会被拦下。

二、把预算拆成 Token、时间和工具三类

Agent 预算不是一个数字。Token 控制模型成本，时间控制用户体验，工具次数控制下游压力。三者都要有上限。

flowchart TD
  A[用户任务] --> B[任务分级]
  B --> C[Token 预算]
  B --> D[时间预算]
  B --> E[工具调用预算]
  C --> F[计划器]
  D --> F
  E --> F
  F --> G{预算是否耗尽}
  G -->|否| H[继续执行]
  G -->|是| I[降级或停止]

预算要在每一步扣减，而不是最后统计。计划器如果不知道剩余预算，就会继续开支票，执行器在后面擦屁股。

扣减要实时。不要等模型调用结束才从返回结果里读 token 用量——那时预算已经花出去了。可以在调用前做估算（提示词长度 + max_tokens 上限），预留预算。实际消耗比预估值少时再退回。这样即使模型超量输出，也不会超出你允许的上限。

三、用上下文对象传递预算

下面示例把预算建模为可扣减对象。实际项目里可以挂在请求上下文里。

type AgentBudget struct {
	TokenLeft int
	ToolLeft  int
	Deadline  time.Time
}

func (b *AgentBudget) ConsumeTool() error {
	if b.ToolLeft <= 0 {
		return fmt.Errorf("tool budget exhausted")
	}
	if time.Now().After(b.Deadline) {
		return fmt.Errorf("agent deadline exceeded")
	}
	b.ToolLeft--
	return nil
}

这个逻辑简单，但能把"还能不能继续调用工具"变成硬判断。预算耗尽后，系统应该返回当前已验证结果，或者明确说明需要缩小任务范围。

预算对象还应该支持"预留"和"确认"两步操作。计划器在生成步骤时可以 Reserve 预算，执行器实际消费时再 Consume。预留失败的步骤就不应该执行，避免"步骤 A 执行完了发现步骤 B 没预算"的尴尬。

四、预算策略要跟业务价值挂钩

同样是 Agent 任务，内部运营分析、客户实时问答、后台批处理的预算不该一样。实时问答重视延迟，后台批处理可以慢一点但要稳定，运营分析可以给更多检索和引用。

还要给失败路径预算。工具失败后是否重试，评审器是否再跑一轮，都要消耗预算。无限反思听起来聪明，生产里就是无限花钱。

我建议给预算设定"硬上限"和"软上限"。软上限是正常任务预算，在这个范围内系统全力执行；硬上限是最大允许值，达到后强制降级。软上限留给系统优化空间，硬上限保护成本不被击穿。两者之间的差值就是安全缓冲区。

预算还要支持中途改计划。Agent 执行到一半发现工具返回的信息不足，可以申请追加预算，但追加必须有理由和上限。系统可以让评审器判断是否值得继续，而不是让计划器自己给自己批钱。这个设计听起来有点麻烦，但能防止"越失败越多花"的坏循环。

还要区分探索预算和交付预算。探索阶段可以允许多查几次，交付阶段要收敛到可验证结论。很多 Agent 任务失败，不是因为不会做，而是一直在探索，没有进入交付。

预算策略上线前要跑回放。拿历史任务重放一遍，看新预算会在哪一步停止、答案质量是否下降、成本能省多少。别直接在线上砍预算，用户会立刻感受到系统变笨。

预算消耗还要在用户侧有感知。如果 Agent 花了很长时间和很多"努力"却给出了一个不确定的答案，用户应该知道系统尽力了。可以在最终回答里标注"此问题涉及多源数据交叉分析，响应时间可能较长"，让用户理解延迟和代价的来源。

五、总结

Agent 预算调度要在计划执行前就开始。Token、时间和工具调用都要有上限，并在执行过程中持续扣减。预算策略要按业务价值分层，失败和重试也要计费。Agent 能完成任务只是第一步，能用合理成本完成任务，才算能上线。会拆任务之前，先会算成本。