先说个真实场景——你在Notebook里跑通了一个Agent，能查数据库、调API、写代码，测试几条Case看着挺聪明。然后你把QPS调到50，用户量上来之后：

• 工具调用开始各种超时

• LLM返回的JSON偶尔解析失败，整个链路直接崩

• Prompt几轮对话后越来越长，上下文直接溢出

• 最要命的是，你根本不知道哪个环节出了问题——因为什么监控都没有

Demo关注的是"能不能跑"，生产关注的是"挂了能不能自己爬起来"。

这中间的差距，就是工业级Agent真正要解决的问题。

我们踩出来的四层架构

做了几个项目反复迭代之后，我们现在落地基本就用四层结构，不复杂但够用：

接入层就干三件事：鉴权、限流、SSE流式推送。看着简单，但这层不能省。线上流量一起来，前置限流能救你一命。

编排层Agent的大脑。三个关键模块：

• Planner负责拆任务。复杂意图先拆成子步骤再执行，比直接一步到位稳得多。这个我们反复验证过——先拆后做的成功率比端到端高至少20个点。

• Memory分三层管：短期用对话窗口、长期走向量库、工作状态用外部状态机。千万别什么都往Prompt里塞，省Token是小事，关键是断了能恢复。

• Tool Router做语义匹配选工具，比写死if-else灵活太多了——后面加新工具基本零改动。

执行层所有工具调用必须加超时熔断。真实环境里第三方API挂掉是常态，一个工具调用失败不应该拖垮整个Agent。我们线上跑了半年，这一层的容错逻辑至少挡过七八次全链路雪崩。

基础设施层模型网关做多Provider的统一调度和降级（OpenAI挂了自动切Claude，再挂切本地模型），再加一套全链路Trace/Metric/Log。这层没有的话，出了问题真的只能靠猜。

三个血的教训

1. 状态别放Prompt里

早期我们也是把所有对话历史、工具结果、中间状态全往Prompt里塞。省事是真的省事，但Token哗哗地烧，而且一旦对话断了就得从头再来。

后来改成外部状态机管理，Prompt只带当前决策需要的最小上下文。不仅省了大半Token，关键是任一环节断了都能接着跑。

2.Agent不是"信得过单位"

代码执行必须沙箱隔离，工具调用要有权限校验，数据库查询上SQL防火墙。还有一条：永远不要把密钥写在Prompt里。说起来像常识但真有人这么干。

3. 不能"感觉差不多"就上线

我们现在强制跑三层评估才允许上线：工具调用准确率、端到端任务完成率、用户反馈打分。每次改Prompt或换模型都自动化跑一遍。不然上线就是开盲盒，这个亏我们吃过。

几个省钱技巧，实测有效

• 相似问题的规划结果做缓存，别每次都让LLM重新想一遍，命中率能做到30%+

• 简单分类用小模型（Haiku完全够用），复杂推理再上大模型——成本直接砍半

• 离线任务全走批处理，别占实时链路的配额

说到底

搞了这么久，最大的感受其实就一句——工业级Agent最难的从来不是模型能力不够，而是怎么给一个"不太靠谱"的智能体加上一层层靠谱的工程护栏。

从Demo到生产，搭架构、做容错、建监控、跑评估，每一步都是在给Agent补齐不确定性。这条路我们自己走了一遍，现在也还在继续走。

如果你也在折腾Agent落地，或者正在头疼怎么把Demo推到生产环境，欢迎在评论区聊聊你碰到的坑。说不定刚好是我踩过的，一起交流总比自己闷头搞强