AI Agent 生产环境部署实战

先说个大实话：我见过太多 AI Agent 项目死在"从 demo 到生产"这一步。本地跑得飞快的 Agent，一上生产就超时、幻觉、上下文爆炸、工具调用错乱，运维同学半夜盯着告警面板怀疑人生。这类问题，我在过去大半年的 Agent 工程化落地里基本都踩过一遍，也总结出了一套相对可复用的部署和调优方案。

这篇文章不聊论文，也不讲概念。我直接按照自己实际做过的生产级 Agent 项目，把架构选型、模型服务部署、编排层设计、并发与稳定性、可观测性、发布与回滚这些环节逐一拆开，把关键参数、配置方式、踩坑教训全部写出来。内容会比较长，但每一步都是能直接抄作业的。

适合谁看？三种人：一是准备把 Agent 项目从开发环境推向生产的后端工程师，二是负责大模型应用落地的技术负责人，三是被"如何搭一个生产级 Agent"困扰的独立开发者。如果你只是想在笔记本上跑个 Demo，这篇文章部分内容对你来说偏重，但架构思路依然值得提前了解。

1. 先想清楚：生产环境的 Agent 和 Demo 差在哪

1.1 Demo 阶段的 Agent 为什么不能直接上线

我拆过的 Agent 项目里，90% 的 Demo 代码都是"单机自嗨"型：一个 Python 脚本或一个 FastAPI 服务，Agent 循环里直接调大模型 API，工具函数写死在代码里，上下文全部塞进一个列表，没有超时控制，没有重试，没有限流。这种代码在演示场景下表现不错，但一遇到真实流量就暴露问题：并发请求直接把模型服务的显存打满，单一请求的推理耗时过长导致网关超时，上下文越积越大最后超出模型窗口限制，工具调用偶发失败没有兜底，整个对话直接崩掉。

生产环境的本质区别在三个维度：稳定性、可观测性、可运维性。稳定性要求你对每一种失败模式都有预案——模型超时、工具异常、上下文溢出、并发排队，任何一个环节出问题都不能让整个服务挂掉。可观测性要求你能回答"这个 Agent 现在在处理什么、为什么这么慢、哪一步出错"这三个问题。可运维性要求你能在不中断服务的前提下更新 Agent 逻辑、调整模型参数、扩容缩容。

1.2 生产级 Agent 的分层架构

我最终沉淀下来的架构分四层：模型服务层、Agent 编排层、工具调度层、应用接入层。模型服务层负责大模型的推理，可以是 OpenAI 等云端 API，也可以是基于 vLLM 等框架自建的本地服务。Agent 编排层是核心，负责理解用户意图、规划执行步骤、管理对话状态、决定何时调用工具，这个角色通常由 LangGraph、Dify 这类编排框架或自研的状态机来承担。工具调度层将 Agent 的决策转化为真实的 API 调用或代码执行，需要处理鉴权、限流、超时、参数校验和结果解析。应用接入层就是对外暴露的接口和前端应用，负责对话管理、用户认证、业务逻辑串联。

分层的核心价值在于每层都能独立扩展和替换。我见过不少项目把模型调用、Agent 逻辑、工具调用全写在一个类里，看起来代码量不大，但一旦要换模型供应商、加一个新工具或调整编排策略，改动范围完全不可控。分层之后，每层都有清晰的边界和接口。比如模型服务层只需要暴露一个 OpenAI 兼容的接口，上层根本不用关心底层跑的是 DeepSeek、Qwen 还是 Llama；工具调度层只需要注册一组函数签名和调用方式，Agent 编排层按需调度。这样整个系统的可维护性和可扩展性会好很多，后续做 A/B 测试，只需要在接入层做简单的流量切分，完全不用改动核心链路。

2. 模型服务层部署：选择 API 还是自建推理服务

2.1 云端 API 和本地推理的取舍

模型服务层是所有 Agent 能力的底层基础，选型直接决定了成本、时延和可用性。我在多个项目里分别验证过两种方案：调用云端 API 和本地部署开源模型，各有各的适用场景。

调用云端 API 是上手最快的方式，OpenAI、DeepSeek、Claude 等都有成熟的接口。优势是模型能力最强、无需关注底层推理基础设施、按量付费没有闲置成本。缺点也明显：数据出域，对数据敏感的行业场景不适用；单次请求时延取决于供应商服务质量，高峰期不稳定；长期高频调用成本可能超过自建推理。

本地部署开源模型走的是另一条路，用 vLLM、Ollama 等推理框架把 Qwen、DeepSeek、Llama 这些开源模型跑在自己的服务器上。优势是数据完全在内网流转、时延可以通过显存优化压到最低、高频调用边际成本极低。劣势是前期投入大，对运维能力有要求，而且开源模型的综合能力与顶级商业模型仍有差距。

从实际项目的角度来看，模型选型关键在于应用场景而非技术偏好。如果 Agent 要处理复杂的逻辑推理和长文本理解，商业模型的能力优势能直接转换为用户体验优势；如果 Agent 的任务相对固定、数据敏感度高、调用频率大，本地部署开源模型反而是更安全、更省钱的选择。我个人偏好的方式是双轨并行：核心链路用云端旗舰模型保证效果，高频简单任务用本地小模型降低成本，通过一个统一网关做路由。

2.2 vLLM 部署的关键参数和显存调优

既然标题是生产环境部署，模型服务这层我就以自建推理为主来展开。vLLM 是目前生产环境用得最多的推理框架，吞吐量高、兼容 OpenAI 接口协议，部署成本相对可控。我在实际项目里见过用 vLLM 同时服务多个业务线的情况，但前提是显存规划要算清楚。

部署 vLLM 服务时，下面这几个参数必须吃透。--model 指定模型路径，可以是 HuggingFace 模型 ID 或本地权重路径；--served-model-name 是暴露给外部调用的模型名称，客户端通过这个名称访问模型；--tensor-parallel-size 是张量并行度，表示用几张 GPU 卡跑同一个模型，只有当单卡显存放不下模型权重时才需要开。--gpu-memory-utilization 是显存利用率上限，默认 0.9，显存充裕时才建议往高调，否则容易 OOM 或影响并发；--max-model-len 是模型支持的最大序列长度，决定单次请求能处理多少 token，设得越高并发能力越低；--enable-prefix-caching 开启前缀缓存，复用之前计算过的公共前缀，能明显降低多轮对话场景的推理延迟。

我举一个实际配置的例子。假设有一台 8 卡 A100 80G 的服务器，要部署一个 70B 参数的模型——这种规模的 Agent 基础模型对多数业务已经足够了。单个卡放不下完整权重，需要设置 --tensor-parallel-size 8，让 8 张卡一起跑。估算显存：70B 参数加载为 FP16 格式，模型权重约 140GB，每张卡分到约 17.5GB。KV Cache 大约占 30-40GB，每张卡的可用空间还剩 20GB 左右，所以 --gpu-memory-utilization 设在 0.85 比较稳。--max-model-len 结合 Agent 的实际需要：一个完整的多轮对话上下文，系统提示词加上工具定义、历史对话、工具返回结果，很容易到 1 万到 2 万 token。设为 16384 可以保证上下文深度，同时留下并发余量。Agent 场景模型输入输出长度都不小，留出充分的 KV Cache 远比极限压缩上下文更能保证服务稳定。

2.3 本地部署 DeepSeek 的实战要点

近半年 DeepSeek 系列模型热度蹿升很快，好多团队都想用它的开源模型替换商业 API。我在本地试过 DeepSeek-R1-Distill-Qwen-32B 这类蒸馏版模型，效果在代码生成和逻辑推理两个场景中表现相当不错，部署方式与 Qwen 类似，也是基于 vLLM 完成。

但蒸馏模型和原版模型有个重要差异：蒸馏版本质上是更小的学生模型，能力上限和原版 R1 模型不在一个层级，复杂任务上的推理深度明显弱一些。所以选模型时先想清楚任务需求。一个经验是：如果任务定位是普通文本理解和代码辅助，32B 蒸馏版足够；如果要做深度推理、复杂 Agent 规划，建议直接上更大的模型或调用商业 API。

DeepSeek 模型的系统提示词里需要带上"请逐步思考"类的引导，模型原生支持思维链。在 vLLM 部署时，建议把 --max-model-len 调大一些，思维链需要额外消耗 token，窗口设小了容易出现输出截断。同时把 --enable-prefix-caching 打开，因为相同系统提示词在多次请求中会重复出现，前缀缓存能显著减少重复计算，多轮对话场景下服务吞吐能力可以提升 30% 以上。我在上线后对比过开和不开前缀缓存的监控数据，开启后平均首 token 时延大约降了 20%，效果非常直观。

2.4 模型服务层必须前置的治理能力

模型服务层只解决"能推理"是不够的，"推得好、推得稳"才是生产需求。我在分层架构里把网关和治理能力也放在这一层：统一入口负责把云端 API 和本地推理服务封装成同一种接口，上层业务只配置一个 base_url 就行。网关层要支持多模型路由，比如普通对话走 Qwen、复杂推理走 DeepSeek、特定场景走商业 API，路由规则可以用请求参数或消息内容做判断。密钥管理也要收敛到这一层，业务方不需要接触任何模型供应商的 Key，数据库里的模型密钥也更安全。配额和限流同样在网关做，每个业务线或每个用户分配独立配额，超限直接返回明确错误码。

这部分属于"没它也能跑，但有它不会出乱子"的治理能力。我有一次没有在网关层做限流，结果测试同学压测时把本地推理服务的并发打到接近上限，后面所有真实用户请求全部排队。加上网关层的请求级限流和队列超时控制之后，任何一方流量异常都不会拖垮整套 Agent 服务。这个教训在部署 Agent 的时候特别值得重视，因为 LLM 请求耗时比普通 API 长得多，并发放大效应也更明显。

3. Agent 编排层设计与部署

3.1 选型：LangGraph、Dify 还是自研状态机

模型服务落地之后，核心就是 Agent 编排层。目前主流方案大致三条路：LangGraph、Dify 等开源平台、完全自研状态机。我在不同场景下都试过，最终结论是：没有银弹，但多数项目有最优解。

LangGraph 适合以代码为核心、需要精细控制 Agent 行为的团队。它把 Agent 流程建模成图结构，节点是各种操作（调用模型、执行工具、条件判断），边是流转关系，状态通过 Checkpointer 机制持久化，天然支持多轮对话和流程恢复。LangGraph 最让我喜欢的一点是它用代码定义流程图，所有逻辑都可以进 Git 做版本管理。Agent 生产部署最怕的就是黑盒流程，代码化之后每个节点都能被测试、被回滚、被追踪。

Dify 这条路适合以产品快速验证为核心、不想过多写代码的团队。Dify 提供了直观的工作流画布、内置了 RAG 管道、模型管理和工具插件，一个完整的 Agent 应用配置好之后可以直接发布为 API。研发成本确实低，但灵活性受限，复杂控制逻辑在平台上实现起来比较繁琐。我一般用它做两件事：快速给内部团队搭知识库问答机器人，或者做业务验证原型。一旦验证通过、需要深度定制时，再迁到代码型方案。

自研状态机是我最不推荐但偶尔必须的选择。只有在你需要和现行业务强耦合、或者框架不能满足特定需求时才考虑，比如状态流转必须完全贴合公司内部审批流规范。自研成本包含状态持久化、并发控制、节点重试、流程可视化一整套实现，没有独立人力投入很难维护。

3.2 LangGraph 生产部署的核心配置

如果选择 LangGraph 路线，生产部署时下面几个点务必处理到位。首先是 Checkpointer 的存储位置，默认内存实现在重启后状态全丢，必须换用 Redis 或 Postgres 这类外部存储。Checkpointer 负责保存对话状态和每一步的执行记录，多轮对话依赖它恢复现场，审计排查也依赖它还原问题过程。我在项目中用 Redis 存 Checkpointer，一个简单的对话状态的读写时延在 1ms 量级，对整体耗时影响可以忽略。但要注意给 Redis 设置合理的 TTL，比如 7 天，对话状态长期不清理会占大量内存。

其次是整个执行流程必须能被并行实例承载。LangGraph 的图定义是独立的，状态保存在 Redis，任何实例启动后拿到 state 就能继续执行，这就实现了横向扩容。Redis 的连接池要按实例数估算，别让连接耗尽变成新瓶颈。

再就是每个 Graph 节点都需要独立的超时和重试策略。模型节点的超时只覆盖模型调用本身，工具节点要单独设置调用外部 API 的超时。LangGraph 里可以在节点函数内部用 asyncio.wait_for 控制超时，配合 tenacity 库对瞬时故障做指数退避重试。我在工具节点上的标准配置是：连接超时 3 秒，读超时 15 秒，重试 2 次。连续超过一定次数的失败，直接让 Agent 对用户返回"当前工具不可用"而不是让用户无限等待，这在生产环境里特别重要。

3.3 状态管理：上下文窗口和会话隔离

Agent 多轮对话的核心难点是上下文管理。大模型窗口有限，Agent 步骤越多、工具结果越长，上下文膨胀越快。我把这个问题拆成三层解决：Token 预算控制、上下文压缩、长期记忆。

Token 预算控制是指每次请求给系统提示、工具定义、历史消息和当前输入分配合理的 Token 额度。我习惯用 tiktoken 这类分词器实时统计长度，并设置一个上限，比如总窗口的 70%。超过上限时触发裁剪策略：优先丢弃最早的历史消息，但保留系统提示和最新几轮对话；如果工具返回结果特别冗长，可以对工具结果做摘要，再将摘要放进上下文。

上下文压缩有两种手段。一种是在毫秒级路径上做滑动窗口，适合实时对话；另一种是异步做总结，当会话轮数超过阈值，就把之前的内容交给模型总结成几个要点，再作为下一轮对话的初始状态。LangGraph 里可以在图里专门设计一个节点做总结，判断条件是对话轮数或 Token 数量达到阈值。这里我踩过一个坑：把总结节点放在主链路上，导致每次对话变慢且多花一次模型调用。后来改成旁路异步总结，只在下一次对话开始时检查是否需要替换旧上下文，延迟和成本都明显下降。

会话隔离同样关键。多租户场景下，每个用户的对话状态必须严格隔离。LangGraph 的 checkpointer 支持用 thread_id 区分会话，Redis 的 key 设计为 agent_state:{thread_id}，不同用户之间天然隔离。同时还要在工具调用参数里注入用户身份信息，防止 Agent 在调用业务 API 时越权访问他人数据。这个属于安全底线，刚开始做 Agent 的人容易忽略。

3.4 Agent 工具层的生产级封装

工具层是 Agent 与外部世界交互的通道，也是最容易出错的环节。生产环境对工具的要求非常明确：能被模型稳定理解、能被系统稳定执行。我封装工具时总结出一套固定模板：函数名清晰表达意图，使用英文小写加下划线；参数名跟业务语言保持一致；每个参数提供详细描述，包括类型、取值范围、示例；返回值统一为 JSON 格式，即使成功也带状态码。模型能不能准确调用工具，很大程度取决于描述写得好不好。给模型的每条工具描述我都会花时间打磨，用一两句话说清楚"这个工具是做什么的、什么情况下调用、参数如何填"，效果远比简单罗列函数签名好。

执行层面的稳定性靠统一调度器来保证。工具调用前做参数校验和鉴权，调用中加超时控制和重试机制，调用后做结果格式化和错误归因，这些逻辑都集中在一个 Executor 里，而不是散落在各个工具函数中。还需要为工具加上语义白名单开关，不是所有工具对所有用户都开放，比如普通用户调用查询工具没问题，但写入和删除类工具必须走单独授权。

关于 MCP 协议，最近讨论度很高。MCP 把工具以标准协议暴露给 Agent，客户端通过统一的接口发现和调用工具，省去每个工具写一套接入代码的麻烦。如果你的团队维护多个 Agent 应用共用同一批内部系统工具，用 MCP 做工具层标准化是值得尝试的方向。但它不是银弹，工具数量少、调用链简单的项目，直接函数调用反而更省事。生产环境稳定性优先，不必为追新协议增加复杂度。

4. 生产环境基础设施与容器化部署

4.1 Docker Compose 编排一套 Agent 服务

Agent 服务本身通常拆成多个组件：API 网关、Agent 执行服务、Redis、模型推理服务（可选）、向量数据库（如果有 RAG）。用 Docker Compose 把这套东西编排起来，最直观也最便于维护。

下面是一个我在多个项目中沿用下来的基础编排模板，覆盖 Agent 服务加 Redis 两个核心组件：

yaml复制version: "3.8"

services:
  redis:
    image: redis:7-alpine
    command: >
      redis-server 
      --appendonly yes 
      --requirepass ${REDIS_PASSWORD} 
      --user default off 
      --user agent on >${REDIS_PASSWORD} ~* +@all
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  agent-api:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - REDIS_URL=redis://agent:${REDIS_PASSWORD}@redis:6379/0
      - MODEL_API_BASE=${MODEL_API_BASE}
      - MODEL_API_KEY=${MODEL_API_KEY}
      - AGENT_MAX_CONCURRENCY=${AGENT_MAX_CONCURRENCY}
    ports:
      - "8000:8000"
    depends_on:
      redis:
        condition: service_healthy
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: "2.0"
          memory: 4G
    restart: unless-stopped

volumes:
  redis-data:

这段编排里有几个细节值得展开说。Redis 7 默认开启了 ACL 功能，我在配置里用 --user default off 把默认用户禁用，再创建一个名为 agent 的用户，只允许通过密码访问，权限限制为全部命令。这样即便 Redis 端口被扫描到，没有有效账号密码也无法操作。appendonly yes 开启持久化，Redis 重启后对话状态不丢。健康检查用 redis-cli ping，API 服务通过 depends_on: condition: service_healthy 确保 Redis 就绪后才启动，避免启动初期连接报错。

这里补充一个我踩过的典型坑：Redis 密码中如果包含特殊字符，在 URL 连接串里需要做 URL 编码，否则解析就会出错。比如密码里的 @ 符号必须写成 %40。一开始我在这上面调试了半小时，一直报认证失败，排查下来才知道是连接串的问题。ACL 配置里账号密码用环境变量传入，而不是写死在配置文件里，这样不同环境之间的切换成本会低很多。

4.2 vLLM 容器化部署的显存规划

vLLM 服务同样可以用 Docker 方式部署，典型命令如下：

bash复制docker run --runtime nvidia --gpus all \
  -v /data/models:/models \
  -p 8001:8000 \
  --ipc=host \
  --env "HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}" \
  vllm/vllm-openai:latest \
  --model /models/Qwen2.5-72B-Instruct \
  --served-model-name agent-qwen \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 32768 \
  --enable-prefix-caching

--ipc=host 这个参数容易被忽略，但多进程推理时共享内存不足会导致模型加载阶段崩溃。--tensor-parallel-size 必须和 GPU 数量匹配，4 张卡就写 4，写错了模型加载直接报错或根本跑不动。我一般建议把模型权重放在宿主机目录再挂载进容器，不放在容器镜像里，这样模型更新时不需要重新构建镜像。

显存规划上有个简单的预估口诀：模型权重约占参数量的 2 倍（FP16 下每 10 亿参数约 2GB），KV Cache 至少预留 30% 的显存给长上下文。70B 模型用 4 卡 A100 部署，权重约 140GB，每卡约 35GB 用于权重；单卡 80GB 显存，剩余约 45GB 留给 KV Cache，gpu-memory-utilization 0.9 意味着 KV Cache 峰值可以用到约 36GB。如果任务上下文特别长，把 max-model-len 调大，KV Cache 占用也会随之上升，需要同步下调并发量。这些参数互相制约，部署时先做一轮基准压测再定最终值比较靠谱。

4.3 并发控制：Semaphore、队列与背压

Agent 服务的并发控制和普通 Web 服务不太一样。普通 Web 服务的每个请求处理时间通常在毫秒级，但 Agent 请求的端到端耗时可能是 10 秒甚至更久，而且内部还会多次调用模型服务。如果不做全局并发控制，上游一打流量，模型服务直接被大量推理请求打爆。

我常用的控制手段是信号量加队列。Agent 执行服务启动时初始化一个全局 asyncio.Semaphore，比如设置为 20，表示同时最多处理 20 个 Agent 任务。超过这个数量的请求进入等待队列，而不是直接拒绝。还需要设置队列最大长度和排队超时，比如队列超过 100 直接返回 503，排队超过 30 秒触发超时返回。这样即使用户请求量突然增加，服务也不会雪崩，而是有明确的降级表现。Agent 执行服务实例的副本数也参与并发上限计算，2 个副本乘单副本信号量 20，总并发约 40。模型服务侧的吞吐也要匹配，vLLM 可以通过 --max-num-seqs 限制并发序列数，如果 Agent 服务的信号量设置过大，模型服务会成为新的瓶颈。

还要注意区分同步和异步的并发模型。Agent 等待模型响应时是 IO 密集型的，进程不能阻塞在一个请求上，否则 CPU 和内存会被无效占用。FastAPI 里实现 Agent 调用要用异步接口配合异步 Redis 客户端和异步 HTTP 客户端，整体链路保持非阻塞，才能在高并发下维持较低的内存占用和较快的响应速度。

5. 可观测性：让 Agent 行为可追踪、可度量、可告警

5.1 日志规范：给每一次 Agent 运行建立完整时间线

Agent 的可观测性比传统应用复杂，因为你不仅要看服务日志，还要还原"模型收到了什么、Agent 为什么做出这个决策、工具调用结果是什么、最终输出是什么"。我使用结构化日志方案，每个任务分配一个 trace_id，每个节点执行时输出一条 JSON 日志，包含事件类型、节点名称、输入摘要、输出摘要、耗时、Token 消耗等字段。

日志事件至少覆盖以下几个关键节点：请求接收、Agent 启动与图入口进入、模型调用前（记录发送给模型的完整 prompt 摘要和 token 数）、模型调用后（记录模型响应、推理耗时和 token 消耗）、工具调用前（记录工具名称和参数）、工具调用后（记录结果摘要和耗时）、最终响应输出（记录完整返回和总耗时）。每一跳的耗时数据都记录下来，后续定位性能瓶颈全靠它。

生产环境里明文打印用户隐私数据是大忌。我的做法是对日志内容做脱敏处理，用户身份证、手机号、密钥等信息一律替换为哈希或掩码，只保留能定位问题的上下文摘要。排查需要完整数据时，通过专门的调试接口再拉取，并做好权限审计。

5.2 指标监控与链路追踪的部署方案

Agent 服务的关键指标我梳理成四类：流量类包括 QPS、请求成功率、用户并发数；性能类包括 P50/P95/P99 端到端延迟、模型推理延迟、工具调用延迟；资源类包括 CPU 使用率、内存使用率、GPU 利用率、显存占用；质量类包括模型 Token 消耗量、上下文裁剪次数、工具调用失败率、Agent 步数分布。

指标采集可以使用 Prometheus，通过 Prometheus Python Client 把指标暴露给抓取，再配 Grafana 做可视化看板。链路追踪方案我推荐 OpenTelemetry，Python 服务中引入 SDK 后，可以在 FastAPI 中间件层自动生成 span，再手动给 Agent 图节点创建子 span，最后将 traces 导出到 Jaeger 或 Tempo。链路追踪最直观的价值是：当用户反馈"Agent 回答变慢了"时，能一眼看出慢在模型调用还是工具调用，而不是逐行翻日志。

告警规则我的初始设定是：请求成功率低于 99% 持续 5 分钟触发 Critical；P95 延迟超过 15 秒持续 5 分钟触发 Warning；GPU 显存使用率超过 90% 持续 10 分钟触发 Warning；工具调用失败率超过 10% 持续 5 分钟触发 Warning。告警一定要配通知渠道，比如企业微信机器人或钉钉群，关键指标告警直接电话通知值班人。没有告警的可观测性等于白搭，我之前就犯过这个错：面板搭了一堆，但服务挂了半小时没人发现，直到用户投诉。

5.3 面向业务的效果指标采集

除了技术指标，Agent 生产环境还需要采集业务层面的效果指标。用户对回答的点赞点踩数据、追问率和自动终止率，都直接反映 Agent 的真实表现。技术指标只能告诉你"服务是否正常"，效果指标才能告诉你"Agent 回答是否让用户满意"。这两个维度需要同时监控。

做法很直接：把每次请求的用户反馈入口接到 Agent API 返回里，前端用户点"有用/无用"按钮后上报到服务端，落到独立的反馈表，关联 trace_id。这个数据积累一段时间后，可以用来评估调优方向：比如某个工具调用频繁失败被用户差评，就优先修那个工具；某个场景下 Agent 经常步数过多，就调整它的规划和总结策略。采集效果指标的成本不高，但对持续优化 Agent 至关重要，比盲目调 prompt 有依据得多。

6. 发布、回滚与压测：上线前的最后一道防线

6.1 Agent 服务的蓝绿部署与回滚策略

Agent 服务更新逻辑和传统应用不同，除了代码变更，prompt 变化、工具定义变化、模型参数变化都可能影响 Agent 行为，因此发布策略要更保守。

我推荐蓝绿部署：保持两套环境交替使用，新版本验证充分后再切流量。整套流程这样执行：先在绿环境部署新版本，跑一遍预置的回归用例集；再切 10% 流量到新版本观察；如果错误率、延迟、用户反馈都正常，逐步扩大到 50%，最终全量切换；一旦任何阶段指标异常，立刻把流量切回蓝环境。整个切换在一分钟内完成。旧版本环境保留至少 24 小时再销毁，防止切后发现新版本有问题需要快速回退。

回归用例集是 Agent 发布质量的关键。我会为每个核心场景准备测试用例，包括正常对话、边界输入、工具异常等，发布时自动跑一遍，比较新旧版本的输出质量。质量比较目前还没有完美的全自动方案，我是用人工加半自动方法：结构化场景自动比对工具调用参数是否正确，自由对话场景抽样人工评估。发布流程严格一点，线上才能安稳一点。

6.2 压测方法论：模拟真实 Agent 调用链压测

压测 Agent 服务和压测普通 Web API 不一样，因为 Agent 请求会真正触发模型推理，直接压测线上环境可能让模型服务过载。我的做法是搭一套影子环境，用同一个模型服务但隔离的 Agent 实例，或者直接对预发环境做压测。

压测脚本核心是模拟用户的多轮对话，而不是单轮请求轰炸，因为多轮对话才有状态恢复、上下文积累、工具调用的综合开销。用 Locust 可以方便地编写这类场景脚本：一个用户会话进程持续和 Agent 对话最多 5 轮，每轮间隔按真实用户思考时间分布去设置，比如 3 到 10 秒随机。压测时要同时观察 Agent 服务和模型服务的指标，重点看两个拐点：Agent 请求的成功率开始下降，以及 P95 延迟开始明显抬头。

我在一次压测中发现，并发到 30 时端到端延迟从 3 秒飙升到 25 秒，排查发现瓶颈不在模型服务，而在工具层某个内部 API 的限流策略。模型层反而有富余，因为 Agent 的步数在并发高时被限制了。这个案例的教训是：Agent 压测必须全链路一起压，单独压模型服务或单独压 API 都会忽略链路瓶颈。压测数据出来后再确定生产环境的并发上限和限流阈值，比如压测显示 30 并发延迟劣化明显，生产就把信号量设为 20，留 50% 的余量，宁可稍微排队也绝不雪崩。

6.3 上线初期需要盯住的核心指标

新 Agent 版本上线后的 24 到 48 小时是关键窗口期。我建议在这个阶段盯住几个核心指标：错误率是否接近压测时的基线，P95 延迟是否在可接受区间，Model 调用失败率是否正常的千分位水平，Token 消耗量是否出现异常激增——异常激增往往意味着上下文压缩失效或者工具返回没有及时裁剪。上下文裁剪次数也不能忽视，如果裁剪频繁，说明上下文预算规划不合理，用户侧的体验可能是"Agent 失忆"。

用户反馈数据从上线第一分钟就要开始关注，尤其是负面反馈。有用户标记"无用"的回答，当天就拉取 trace 复盘，判断是模型问题、工具问题还是 prompt 问题。上线初期的每一份反馈都是金矿，对快速收敛 Agent 质量问题很有价值。等指标稳定两三天后，再逐步把注意力转移到优化迭代上。

7. 踩坑实录：生产环境中遇到的高频问题

7.1 模型层常见问题速查

我整理了一份在 Agent 生产环境中出现频率最高的模型层问题清单，每一条都是从实际故障里提炼出来的。

7.2 Agent 行为异常排查思路

Agent 产出错误回答时，快速定位问题的路径非常重要。先看 trace 里 Agent 总共走了几步、每一步的耗时分布如何；再看关键节点上模型收到的 prompt 和输出，确认是理解问题还是上下文缺失问题；接着看工具输入输出是否匹配，定位 Agent 调用工具时传参是否正确；最后看最终回答是模型直接生成还是基于工具结果生成。这样走一遍，80% 的线上问题都能定位到具体环节。

有个案例我印象很深：一个 Agent 持续给用户推荐错误的库存信息，排查 trace 发现，Agent 调用库存 API 时把商品 ID 传错了，它从前一轮对话的上下文里错误抽取了另一个 ID。根因是 prompt 中工具参数来源说明不够明确，模型产生了混淆理解。修正方案是重新设计工具参数描述，并在工具调用前增加一步参数合法性校验。从那以后，所有高影响的工具调用都加了参数校验节点，效果立竿见影。这类问题说明 Agent 不是把请求发出去就行，工具调度层的质量把关同样直接决定最终回答的可靠性。

7.3 上下文管理不当的典型表现

上下文管理问题在线上最常见的表现是"Agent 越聊越笨"。刚开始几轮回答准确，聊到十轮以后开始答非所问，甚至遗忘用户前面说过的重要信息。这通常是因为历史对话已经积累了太多不重要的工具返回和中间推理过程，模型注意力被无关信息稀释了。

我的解决方案是设置清晰的上下文分层：系统提示词永远保留；用户核心诉求经过压缩保留；历史对话只保留最近 3 到 5 轮完整内容，更早的内容做摘要；工具结果为非必要时不放入上下文。这套机制在 LangGraph 里可以做成一个专门的 ContextManager 节点，每次模型调用前执行上下文整理。运行下来的效果是长会话的稳定性明显提升，Token 消耗也下降了不少，用户体感连续。

最后再分享一个实战心得

整套体系跑起来之后，我最大的感受是：Agent 生产环境部署没有一步到位的完美方案，只能在实际运行中不断调整。第一次上线不追求完美，但要把架构搭对、指标打通、回滚机制准备好；然后基于真实流量数据做迭代，每次只改一个变量，比如同一版本先只优化工具描述，下一次再优化上下文策略，避免多个变量同时变化导致无法归因。模型服务层的参数调整更要谨慎，每次改动都要对比压测数据再决定是否保留。

这套方法到现在已经帮我稳定支撑了好几个 AI Agent 项目的线上运行，包括知识问答和业务助手等不同形态。希望这篇文章能让你在部署自己的 Agent 时少踩几个坑。如果后续你在模型选型、编排层改造或压测调参上遇到具体问题，欢迎带着场景和数据来交流。