与其说 Agent 工具调用已经全面进入“多模型投票”阶段，不如说部分复杂系统开始用多个模型做规划、复核和选择。真正影响成本的，也不是接了几个模型，而是谁拿到了工具执行权。
2025 年 3 月 27 日发布的《工具生态逐步完善，通用Agent曙光已现》将“调用工具完成复杂任务”列为 Agent 的核心能力，并判断工具生态正在逐步完善。这个趋势判断并不等于调用越多越好。一旦加入规划模型、投票模型和复核模型，计费单位就不再是一条回答，而是一整条任务链。
先弄清楚，模型究竟在投什么票
多模型协作大致可以发生在三个位置：
- 方案层：多个模型分别给出执行计划，再选出一个方案。
- 参数层：模型对工具名称、参数和调用顺序进行复核。
- 结果层：工具已经执行，多个模型只判断结果是否可信、是否需要补充。
最容易失控的是让每个参与投票的模型都直接调用工具。查询类工具会因此产生重复请求；发消息、写数据库、修改文件等带副作用的工具，则可能被重复执行。
更稳妥的结构是：多个模型只提交结构化方案，由编排层完成选择，最后交给唯一的执行器调用工具。如果模型无法达成一致，系统可以暂停、降级或请求用户确认，而不是继续增加模型和调用轮次。
一次任务，至少要拆成四本账
只记录主模型的输入和输出，通常无法解释 Agent 的真实成本。开发者可以按下面四个环节拆账：
| 环节 | 可能产生的消耗 | 建议记录 |
|---|---|---|
| 模型推理 | 规划、候选答案、投票、复核、最终生成 | 模型名称、输入输出用量、请求标识、耗时 |
| 工具调用 | 搜索、数据库查询、外部 API、代码执行 | 工具名称、调用状态、请求次数、外部计费状态 |
| 编排过程 | 超时重试、重新规划、模型降级、结果补全 | 触发原因、尝试次数、上下游步骤 |
| 副作用处理 | 写入、撤销、回滚、人工审核 | 幂等标识、审计记录、执行结果 |
不同模型和工具的计费规则并不统一。失败请求、超时、缓存命中和工具侧 API 是否收费，都应以实际服务商规则为准。系统不能默认“没有拿到结果就不会计费”，也不能把重试产生的调用藏在最终成功记录后面。
阿里云开发者社区关于 Agent 规划调用工具的文章提到，结构化的思考与规划工具可以改善多工具任务的效率和效果。但规划本身也是调用链的一部分。它是否值得加入，要看它减少的误调用和返工，能否覆盖新增的推理开销。
工具边界不能交给模型自觉
一篇关于 Agent 系统设计的文章给出的分工很直接：模型负责理解意图和生成计划，系统负责权限、参数校验、幂等、审计与回滚。对生产环境而言，这比继续优化提示词更重要。
可以先把以下约束放进编排层：
- 每个任务只开放必要的工具，采用白名单而不是默认全量授权。
- 工具参数必须通过固定的数据结构和类型校验。
- 带副作用的操作使用幂等标识，重试时沿用同一个业务标识。
- 为单次任务设置模型调用、工具调用、执行时间和预算上限。
- 达到上限后立即停止，并保留失败原因，不让 Agent 自行无限补救。
- 高风险操作在执行前增加确定性规则，必要时再进入人工确认。
飞书文档关于避免 Agent 不必要工具使用的资料也提到，可以通过正则表达式和人工规则处理自动生成代码，移除邮箱、IP 地址和密码密钥等敏感信息，并过滤无法编译的代码。这些做法有一个共同点：把可以确定的约束交给程序，而不是等待模型临场判断。
成本监控要能追到每一步
成本看板不能只有按天汇总的总金额。一次 Agent 任务为什么变贵，必须能追溯到具体模型、具体工具和具体重试。
一条基础调用记录至少可以包含：
task_id
step_id
decision_role
model
tool_name
provider_request_id
usage
estimated_cost
billed_cost
pricing_version
retry_reason
idempotency_key
status
其中，实时估算成本与最终账单应分开保存。估算用于任务限额和异常告警，最终账单用于核对供应商实际计费；pricing_version 则用于解释同类请求在不同计费配置下为何出现差异。
监控时不要只看单次调用价格，还要同时看每个任务的模型调用次数、工具调用次数、重试原因、投票分歧和最终完成状态。否则，某个模型看起来单价不高，也可能因为反复规划和复核推高整条链路的成本。
火山引擎开发者社区整理的 Cohere 实践文章将可靠性、性能和外部工具交互列为 Agent 从 Demo 走向真实场景时需要处理的问题。成本控制与这些问题并不是两套工作：失控的重试既影响性能和可靠性，也会直接增加调用费用。
多模型不必成为默认选项
多模型投票更适合需要额外复核的关键节点，而不是覆盖所有任务。简单查询可以由单模型完成，再交给确定性规则校验；意图模糊或风险较高时，再启动复核模型；涉及写入和外部操作时，无论有多少模型参与判断，都只保留一个执行入口。
上线前可以检查几个问题：
- 每个投票模型是否都能直接调用工具？
- 相同业务操作能否被幂等拦截？
- 超时和失败重试是否有明确上限？
- 模型意见不一致时，系统会停止还是继续加票？
- 每笔费用能否追溯到任务、步骤和供应商请求？
- 估算成本与最终账单是否定期核对？
- 计费规则变化后，历史记录能否按配置版本解释？
真正可控的 Agent，不是让更多模型轮流发表意见，而是让多个模型可以参与判断，同时只保留一个执行器、一组明确上限和一份能够核账的调用记录。
