跳到主要内容

多Agent成本与复杂度陷阱

1. 定义与边界​

多 Agent 成本不仅是 token 花费，还包括延迟、工具费用、缓存和存储、评测、日志、人工审核、故障排查、权限管理和团队协作成本。复杂度陷阱是指系统拆成多个 Agent 后，表面职责更清楚，实际端到端可靠性、可观测性和可维护性下降。

这个文件的核心判断：多 Agent 应该被当作有成本的架构选择，而不是默认最佳实践。

2. 为什么重要​

成本陷阱在上线后才明显：

  • 每个子 Agent 都调用大模型，成本乘法增长。
  • 多轮 debate 或 handoff 拉高 P95/P99 延迟。
  • Trace 记录大量上下文，存储和脱敏成本上升。
  • 调试需要跨 Agent、工具、状态和外部服务排查。
  • 一个 Agent 的小改动影响另一个 Agent 的输入分布。
  • 安全和审批点增多，产品体验变慢。

3. 核心机制​

成本来源：

成本项说明控制手段
模型 token多 Agent 重复读上下文和生成摘要上下文引用、摘要缓存、小模型分层
调用次数Supervisor、worker、reviewer 多次调用固定计划、批处理、早停
工具费用搜索、数据库、第三方 API工具预算、缓存、去重
延迟串行 handoff 和重试并行化、timeout、降级
观测trace、日志、artifact 存储采样、脱敏、冷热分层
评测回归集、红队样本、人工验收分层评测、关键路径优先
组织多团队边界和排障owner、SLO、接口契约

单位成功成本比单次成本更重要：

单位成功成本 = 总运行成本 / 成功完成任务数

一个更贵但成功率高很多的多 Agent 方案可能值得；一个成本高 3 倍但成功率只高 2% 的方案通常不值得。

4. 架构/流程​

成本控制应内建在编排层，而不是事后看账单。

5. 工程实现​

预算配置：

budget:
  per_task:
    max_total_cost_usd: 0.50
    max_total_tokens: 50000
    max_wall_time_ms: 60000
    max_handoffs: 5
    max_tool_calls: 12
  per_agent:
    planner:
      max_tokens: 6000
      max_calls: 2
    researcher:
      max_tokens: 16000
      max_tool_calls: 6
    reviewer:
      max_tokens: 8000
      max_calls: 1
  fallback:
    on_budget_exceeded: "single_agent_summary"
    on_timeout: "partial_result_with_uncertainty"

成本拦截伪代码：

def before_agent_call(state, agent, estimated_cost):
    if state.cost + estimated_cost > state.budget.max_total_cost:
        raise BudgetExceeded("task budget exceeded")
    if state.agent_calls[agent.name] >= agent.max_calls:
        raise BudgetExceeded("agent call budget exceeded")
    if state.handoffs > state.budget.max_handoffs:
        raise LoopRisk("too many handoffs")

Trace 事件应记录成本：

{
  "span_type": "model_call",
  "agent": "reviewer",
  "input_tokens": 4210,
  "output_tokens": 690,
  "estimated_cost_usd": 0.018,
  "latency_ms": 2400,
  "cache_hit": false
}

6. 生产实践​

  • 用小模型做路由、分类和格式修复，把大模型留给关键推理。
  • 对共享上下文使用 artifact 引用，避免每个 Agent 重读全文。
  • 对 Researcher 结果、工具结果和中间摘要做缓存。
  • 设置每任务硬预算和软预算；软预算触发降级，硬预算直接停止。
  • 对高成本模式如 debate 默认关闭，只在高风险任务开启。
  • 报表中按 Agent 展示成本、成功率和失败率。
  • P95/P99 延迟超标时优先减少串行 handoff。

7. 常见反模式​

反模式后果修正
每个角色都用最强模型成本过高分层模型策略
让 Agent 自由反思到满意无上限循环最大轮数和早停
每轮传完整上下文token 爆炸摘要和 artifact 引用
不设工具预算第三方费用失控per-tool quota
只看平均延迟长尾体验差P95/P99 和 timeout
trace 全量存敏感内容合规风险脱敏和访问控制

8. 评测方法​

成本评测必须和质量绑定：

指标说明
Cost per Task每个任务平均成本
Cost per Success每个成功任务成本
Token per Agent每个 Agent token 占比
Tool Cost per Task第三方工具成本
P95/P99 Latency用户体验长尾
Retry Cost Ratio重试成本占比
Wasted Call Ratio无贡献调用占比

无贡献调用可以定义为：没有改变状态、没有产生 artifact、没有提升最终评分、没有触发必要安全阻断的调用。

9. 安全与治理​

成本控制也是安全控制：

  • 无限制循环可被恶意输入触发，形成资源消耗攻击。
  • 高权限工具的重复调用可能造成重复副作用。
  • Trace 和 artifact 存储成本可能诱导团队关闭日志，降低审计能力。
  • 为降成本使用更弱模型处理安全审查可能提高漏报率。

治理建议：

  • 对外部用户设置 rate limit 和 per-user budget。
  • 对高风险工具设置幂等键和人工审批。
  • 安全 Agent 不应因普通预算耗尽而被跳过；应进入安全降级或拒绝。
  • 成本报表纳入上线验收，而不是财务事后统计。

10. 工程手册补充​

10.1 成本模型​

多 Agent 成本要按“单位成功成本”看，而不是按单次调用看。

total_cost =
  model_tokens
  + tool_cost
  + storage_and_trace
  + human_review
  + retry_cost
  + failure_repair_cost

cost_per_success = total_cost / successful_tasks
成本陷阱观测信号控制手段
fan-out 过宽每个请求触发大量 Agent先路由，再按需并行
handoff 过多延迟高但 artifact 少合并角色或改 workflow
重复检索多个 Agent 查同一资料共享只读 artifact cache
debate 空转轮次增加但结论不变设置最大轮次和收敛条件
失败归因难修复时间长标准错误码和 trace

上线清单：

  • 每个 Agent 有单次预算和 run 级总预算。
  • 并行任务有 join timeout 和部分结果策略。
  • 缓存可复用 artifact，但缓存命中要记录来源和失效条件。
  • A/B 报告必须包含成功率、P95 延迟、单位成功成本、安全失败率。

11. 权威资料​