AI Agent智能体如何部署

本地跑通的 Agent，一上线就出事：接口偶发超时把整条链拖死、并发一高就撞限流、没人知道一次调用到底花在哪。这篇不谈协议兼容也不谈客户端配置，只讲部署这层要做哪些动作、按什么顺序做。

本地脚本里跑通的 Agent，一挂到线上就变样：接口偶发超时把整条链拖死、并发一上来就撞限流、出了问题没人说得清一次调用到底卡在哪。这些几乎都不是模型本身的问题，而是部署这一层没定规矩。

这篇只讲部署动作：服务形态怎么挑、超时重试并发怎么配、降级和日志什么时候定死、上线前拿什么验。协议兼容和客户端怎么接不在这里展开，那是另一件事。

先定服务形态：Agent 到底跑在哪一层

挑形态别看架构图好不好看，就看三条：单次任务耗时量级、是否需要跨请求保留状态、失败后要不要自动重投。这三条里占了两条偏「长、有状态、要重投」，就别硬做成同步 HTTP 接口，否则第一个超时就教你做人。

• 状态放哪要在写代码之前定：会话上下文存在进程内存里，就只能单实例跑，一扩副本立刻串话
• 多副本必须把会话上下文外置到 Redis 或数据库，并且约定好键的过期策略，否则状态会越堆越多
• 如果只是个人本地脚本、没有并发也没有重试需求，进程内直调最省事，上服务反而是给自己加负担

超时、重试、并发三件套怎么配

超时别只设一个总数。连接超时管握手，读取超时按这个任务最长可能走多少步来估，整体超时兜住全流程，三者要能嵌套。只设一个总超时的后果是：你只知道它超了，不知道超在连不上还是卡在某一步工具调用。

1. 分层设超时连接、单次读取、整体各一个值，且整体大于单次之和；验证办法是人为掐断上游，看日志里是哪一层先报出来
2. 重试只给幂等动作读操作可以退避重试；会写数据的工具调用（下单、发消息、改状态）重试前必须带幂等键，否则重试等于重复执行
3. 并发按额度留余量上游给的额度不要打满，超出的部分排队而不是硬打；队列要有长度上限和等待超时，别让请求堆在内存里
4. 流式单独一套口径流式长连接不适合按普通读取超时处理，要另设首包超时和心跳间隔，否则正常的长回答会被误杀

降级路径和日志字段，上线前就定死

降级不是「出错了随便返回点东西」，而是一条固定顺序的链：主模型失败转备用模型，模型整体不可用转规则或模板兜底，兜底也不通就明确报错并把任务保留下来。最怕的是静默失败——调用方以为成功，实际什么都没做。

生效路径

每次响应或日志里标明这次走的是主模型、备用还是兜底，排查时不用靠猜

成本

这次调用一共花了多少，按调用累计而不只是单次模型费用

耗时分布

慢在模型推理、工具调用还是排队等待，分段记

工具链

用了哪个模型、调了哪些工具、各自的返回状态

再给 Agent 的循环加两个硬闸：最大步数和单任务成本上限。到线就中断并记录原因，别指望提示词能拦住跑飞的循环。一次的额度浪费不算什么，一批任务同时跑飞才是事故。

上线前的评测与灰度怎么做

• 先攒一批固定用例，覆盖正常路径、工具报错、模型返回格式不合规、超时这四类，改提示词或换模型后跑同一批做对比
• 指标别只看答得对不对，同时看单次调用成本、平均步数、失败率这三项工程指标
• 灰度先放小流量，观察一段时间再放量，重点盯失败率和成本有没有偏离预期
• 一次性内部工具、没有真实用户在用，可以跳过灰度，但固定用例必须留，否则换模型时完全没有参照

想知道当前各家模型和接口的报价区间、以及常见中转线路的可用性表现，不要凭印象定预算，直接去站内的价格追踪和测速页面核对当时的数字，再决定主力与备用怎么搭。