生产级 Agent 架构：从 Demo 到可治理系统

Agent 原型通常很快就能做出来：

• •一个模型
• •几个工具
• •一个循环
• •一个演示页面

但一旦准备放到真实业务里，问题会立刻变成另一种形态：

• •用户并发上来之后，状态怎么保存
• •工具失败时，任务怎么恢复
• •模型输出异常时，怎么追溯和回放
• •高风险动作怎么做权限控制
• •成本为什么突然飙升

所以生产级 Agent 架构的重点，不是“怎么把 Demo 部署出去”，而是“怎么把一个不确定性很强的执行系统放进可治理的工程体系里”。

一条典型的生产请求链路可以拆成下面几层：

用户请求
  -> 入口网关
  -> 任务编排层
  -> 模型决策层
  -> 工具执行层
  -> 状态与事件存储
  -> 观测与告警
  -> 最终结果 / 人工接管

把这几层分开看，会比直接讨论“用 Serverless 还是 Kubernetes”更有帮助，因为前者决定系统边界，后者只是部署方式。

Agent 系统的入口和普通问答接口不一样，因为它可能触发多步动作甚至外部副作用。

入口层至少要处理：

• •认证和权限
• •请求限流
• •幂等键
• •请求上下文注入
• •高风险任务识别

这里的核心不是性能优化，而是先判断“这个请求有没有资格进入 Agent 执行链路”。

例如，同样是“帮我处理告警”：

• •只读分析任务，可以直接进入编排
• •会创建工单或发送通知的任务，可能需要更高权限
• •会修改生产配置的任务，应该强制人工审批

如果入口层不做分类，后面再补权限控制会非常被动。

原型里经常把“LLM 决策、工具调用、状态更新”都写在一个循环里。这种方式能快速验证想法，但一旦进入生产，就会暴露出几个问题：

• •无法追踪任务跑到了哪一步
• •中途失败后很难恢复
• •难以做超时和重试
• •多个子任务并行时难以管理

更稳妥的做法是把任务编排独立出来。编排层负责：

• •任务状态迁移
• •步骤调度
• •超时和重试
• •失败补偿
• •人工接管分支

而模型只负责某个节点里的判断，不负责整个任务生命周期。

这一步一旦拆开，系统可维护性会明显提升。

生产环境里的工具不能只被看成函数调用，它更像一类“可控的外部动作”。

一个合格的工具执行层，通常需要这些能力：

• •参数校验
• •权限校验
• •超时控制
• •重试策略
• •审计日志
• •结果标准化

如果工具直接在模型循环里裸跑，常见后果包括：

• •相同任务重复触发副作用
• •外部接口抖动导致整个任务卡死
• •出问题后不知道是模型错了还是工具错了

所以从架构角度看，工具层最好独立成一个受控边界，而不是几个被模型随手调用的 Python 函数。

只要任务不是同步一次返回，状态就必须落盘。

生产 Agent 常见需要记录的状态包括：

• •任务 ID
• •当前步骤
• •历史消息
• •工具调用记录
• •中间产物
• •最终结果
• •失败原因

这里有个非常实际的判断标准：

如果服务重启以后你无法继续当前任务，那你的状态设计大概率还不够生产化。

对于简单系统，数据库表就够用；对于复杂编排，可以进一步加事件流或任务队列。但不管用什么技术，目标都一样：任务可以暂停、恢复、回放。

Agent 系统比普通 CRUD 服务更依赖观测，因为它的输出不完全可预测。

至少要能回答这些问题：

• •这次请求调用了哪些模型和工具
• •哪一步耗时最长
• •为什么失败
• •最终结论依赖了哪些中间结果
• •成本花在了哪里

建议至少保留三类观测数据：

• •请求级：用户、任务类型、总耗时、最终状态
• •步骤级：每一步输入摘要、输出摘要、耗时、异常
• •成本级：token 消耗、工具调用次数、外部 API 成本

只有把这些数据串起来，后面才能做真正的优化，而不是凭感觉调 prompt。

很多原型把“失败处理”当成补丁，但在生产环境里，它应该是主路径设计的一部分。

常见做法包括：

• •工具失败时按错误类型重试
• •模型输出不符合 schema 时做一次降级重试
• •超过最大步数时停止执行
• •命中高风险规则时转人工确认
• •任务中断后允许从最近状态恢复

这个思路非常重要：Agent 不是必须“自己搞定一切”，而是要在系统边界内把能自动化的部分做完，把不能稳定自动化的部分交还给人。

Agent 成本上升通常有三种原因：

• •上下文越来越长
• •工具调用过于频繁
• •为了追求成功率无节制地重试

所以控制成本不能只靠“换便宜模型”，还要在架构上提前约束：

• •限制最大步数
• •限制可用工具集合
• •把大任务拆成可缓存的小任务
• •根据任务难度路由不同模型
• •对检索结果和中间产物做复用

很多场景里，减少一次无效工具调用，比把模型从大模型换成小模型更有效。

API Gateway
  -> Auth / Rate Limit / Policy
  -> Task Orchestrator
      -> LLM Decision Worker
      -> Tool Executor
      -> State Store
      -> Event Log
  -> Review Queue / Human Handoff
  -> Monitoring / Alerting / Cost Dashboard

这个草图不是要你立刻把所有基础设施都搭出来，而是提醒一件事：

生产级 Agent 的核心不是“模型多先进”，而是每个不确定步骤都要有边界、有记录、有兜底。

如果系统还处在下面这些状态，最好先别直接对外：

• •没有可回放日志
• •没有明确权限模型
• •工具调用没有审计记录
• •失败后只能重跑整条链路
• •没有人工接管出口
• •还无法解释成本和延迟为什么波动

这些问题单独看都像“小事”，但叠在一起时，通常就是线上事故的起点。

生产级 Agent 架构不是比原型多几个组件，而是把不确定执行过程放进一套可以治理的系统里。真正决定能不能长期运行的，往往是这些基础能力：

• •入口边界
• •编排与状态
• •工具隔离
• •观测与回放
• •失败恢复
• •人工兜底

当这些层次都清楚以后，你再讨论具体用哪种部署方式、选哪个框架、接哪个模型，才是在做工程选择，而不是继续堆 Demo。