AI Agent 实战教程 19：部署、限流与成本优化

AI Agent 从 Demo 走向生产时，最先暴露的问题往往不是模型不会回答，而是系统跑不稳、响应太慢、成本过高、外部工具偶发失败。一个本地 Demo 可以忽略并发、队列、超时和限流，但线上 Agent 面对的是真实用户、真实数据和真实费用。

因此，部署 Agent 时不能只考虑“模型能不能调用成功”，还要把它当成一个长期运行的任务系统来设计。这个系统需要能排队、能恢复、能限流、能降级，也要能追踪每一次模型调用和工具执行的成本。

同步 API 与异步任务

最简单的部署方式是同步 API。用户发起请求，服务端调用模型和工具，最终返回结果。这种方式适合短任务，例如简单问答、格式转换、单次查询。

但 Agent 经常执行多步骤任务，例如检索资料、创建文章、上传图片、等待用户确认、绑定教程、验证结果。这样的任务可能持续几十秒甚至几分钟。如果仍然使用同步请求，用户体验会很差，也容易遇到超时。

更稳的方式是异步任务。用户提交目标后，系统返回 taskId，后台执行 Agent 流程。前端可以轮询任务状态，也可以通过 WebSocket 或事件推送更新进度。这样用户能看到任务处于 running、waiting_approval、failed、completed 哪个阶段。

队列与并发控制

Agent 任务通常会调用模型和外部工具，这些资源都不是无限的。没有队列控制时，短时间大量请求可能导致模型 API 限流、数据库连接耗尽、工具服务超时。

可以按任务类型建立队列。例如普通问答走轻量队列，内容生成走长任务队列，批量写入走低并发队列。对于写操作，还可以按资源加锁，避免两个 Agent 同时修改同一个教程或同一篇文章。

并发控制不是为了降低性能，而是为了保证系统在压力下仍然可预测。

限流策略

限流可以按用户、组织、模型、工具和风险等级设计。

例如普通用户每分钟最多触发一定次数任务；高成本模型每天有配额；上传、发布、删除等写操作限制并发；同一个资源在同一时间只能被一个任务修改。

限流策略最好返回明确错误，让 Agent 能解释原因，而不是简单报“请求失败”。比如提示“当前任务过多，请稍后重试”或“今日高成本模型额度已用完”。

成本来源与优化

Agent 成本不只来自模型单价。一次任务可能包含多次模型调用、多轮检索、多次工具执行和大量上下文传输。

常见成本来源包括 Planner 调用强模型、每个步骤都带完整历史、工具返回内容过长、检索结果未压缩、失败后无限重试、多 Agent 讨论过多轮。

优化策略包括：简单任务使用小模型，复杂规划使用强模型；工具结果先摘要再进入上下文；重复检索做缓存；失败任务限制重试次数；长任务拆成可恢复步骤，只重试失败部分。

超时和降级

每个工具都应该有超时设置。搜索、上传、数据库查询、浏览器自动化都可能卡住。超时后要返回明确错误类型，供 Agent 决定下一步。

降级策略也很重要。强模型不可用时可以切换备用模型；实时搜索失败时可以先使用已有知识库；图片上传失败时可以先创建草稿并标记待补图；非核心步骤失败时可以让主流程继续。

小结

部署 Agent 的关键，是把它当成可观测、可限流、可恢复的任务系统。模型能力决定上限，工程治理决定它能否稳定服务真实用户。真正可上线的 Agent，不仅要会思考，还要能在成本、并发、失败和权限边界内稳定运行。

实战案例：内容生成任务的成本控制

以批量生成 20 篇教程为例，如果每篇都使用强模型完整生成、再多轮自检，成本会快速上升。更合理的做法是先生成统一大纲，再分篇扩写；通用结构可以复用，具体内容再使用强模型补充。

工具调用也要控制成本。比如验证文章是否创建成功，可以读取必要字段，而不是拉取完整内容。这样既减少网络传输，也减少后续模型上下文消耗。