企业级AI Agent上线即关停？90%败在工程化最后一公里

1. 那个被关掉的 Agent，问题从来不在模型上

“客户花 50 万搞了个 AI Agent，上线一周就关了。”

这句话我第一次听到的时候，第一反应不是“模型不行”，而是“又来了”。过去一年多，我参与过、旁观过、也救火过不少企业级 AI Agent 项目，从客服工单自动分派、合同条款比对、到内部知识问答、再到跟 PLC 设备日志打交道的工业场景，几乎每一个“上线即关停”的案例，复盘到最后，根因都不在模型能力上，而在工程化落地的那几层被忽略的脏活。

50 万这个数字，在 AI Agent 项目里其实不算多。它大概能覆盖：一个 3 到 5 人的小团队干两三个月、买一些 API 额度、租几台服务器、再留一点预算做集成。听起来挺完整，但真正烧钱的地方——数据清洗、权限打通、评测体系、灰度机制、运维监控——往往在立项时被一句“先跑起来看看”给带过去了。结果就是 Demo 惊艳，上线崩盘。

这篇内容我想聊的不是“AI Agent 有多强”，而是为什么大量企业级 Agent 项目会在上线后迅速死亡，以及一个真正能活下来的 Agent 从 0 到 1 到底要补哪些课。适合正在评估 Agent 项目的技术负责人、准备从 0 到 1 搭建 Agent 的开发者、以及被“AI 转型”KPI 推着走但心里没底的一线工程师。我会尽量把踩过的坑、算过的账、写过的代码结构都摊开讲，不灌鸡汤。

先说结论：Agent 的死亡，90% 死在“最后一公里”的工程细节上，而不是死在“第一公里”的模型选型上。下面我按真实项目的推进顺序，一层层拆。

2. 50 万预算到底花在哪了：一笔被算错的账

很多老板对 AI Agent 的预算认知，停留在“调 API 很便宜”这个层面。我见过一份立项书，50 万的构成大概是：模型 API 调用 8 万、服务器 6 万、外包开发 30 万、剩下 6 万做“其他”。这个结构本身就埋了雷。

2.1 被严重低估的三块成本

第一块是数据准备。企业里的知识不是干净的 Markdown，而是散在 Confluence、飞书文档、PDF 扫描件、Excel 台账、甚至老员工的聊天记录里。要把这些喂给 Agent，得做解析、分块、去重、脱敏、打标。我做过一个内部知识库 Agent，光是把 2000 多份 PDF 里的表格正确抽出来，就花了两个人近三周。这块在预算里经常是零。

第二块是集成与权限。Agent 要真正干活，就得连内部系统：工单系统、CRM、ERP、数据库。每个系统的鉴权方式不一样，有的只有内网访问，有的接口文档还是三年前的。更麻烦的是权限——Agent 以谁的身份操作？能不能看到 HR 的薪资数据？这些不解决，Agent 就只能当个“聊天玩具”。

第三块是评测与运维。上线不是终点。你需要一套机制持续回答：今天回答准确率掉了没有？哪个意图识别错了？用户投诉集中在哪？没有这套东西，Agent 就是个黑盒，出了问题只能干瞪眼。

2.2 一个更接近真实的预算分配

这张表不是精确科学，但它反映一个事实：把 60% 的钱砸在“写 Agent 逻辑”上，是典型的资源错配。逻辑本身，用现在的框架，一个熟练工程师一两周就能搭出能跑的版本。难的是让它稳定、安全、可观测地跑在真实业务里。

提示：如果你正在写立项书，把“数据准备”和“评测运维”单独列成预算项，哪怕只是象征性地留 10%，也能在后期救你一命。这两项一旦缺钱，项目大概率烂尾。

3. 从 Demo 到上线，Agent 死在哪几个具体环节

我复盘过几个关停项目，死亡路径惊人地相似。下面按时间线拆，每一步都对应一个具体的工程缺口。

3.1 意图路由：用户根本不按你设想的问

Demo 阶段，测试用例都是精心设计的：“帮我查一下上个月的销售额”。上线后真实用户会问：“那个……就是之前那个数，你懂的，帮我看看”。或者一句话里塞三个意图：“查下库存，顺便把缺货的生成采购单，再通知老王”。

单一 Agent 处理不了这种，于是你需要意图路由层。常见做法是先做一层分类，把请求分派给不同的子 Agent 或工具链。但分类器本身也会错，错了之后用户看到的就是答非所问。我见过一个项目，路由准确率 85% 听起来不错，但意味着每 7 次对话就有 1 次跑偏，用户耐心很快耗尽。

3.2 工具调用的“幻觉参数”

Agent 调用工具时，模型会生成参数。问题在于，模型经常编造不存在的参数值。比如查订单，它可能生成一个格式正确但根本不存在的订单号。工具返回空，Agent 又不会正确处理，就开始胡编。

解决办法不是换更强的模型，而是在工具层做严格校验 + 给模型明确的失败反馈。工具返回“订单号不存在，请向用户确认”，比返回一个空对象有用得多。这个细节，很多 Demo 里根本没写。

3.3 多轮对话里的状态丢失

真实业务很少一问一答就结束。用户会说“就那个”“刚才说的那个再改一下”。如果 Agent 没有可靠的会话状态管理，第三轮就失忆了。更麻烦的是，企业场景经常需要跨会话记住上下文，比如“我上周提的那个需求”。

状态管理听起来简单，做起来要考虑：存哪、存多久、怎么清理、并发怎么办。用内存存，重启就没了；用数据库存，又涉及隐私和成本。这块在 Demo 里通常被忽略，上线后集中爆发。

3.4 上线一周就关的直接导火索

回到标题那个案例。我了解到的版本是：Agent 上线后，第一周处理了大约 2000 次请求，其中约 15% 触发了人工兜底，8% 产生了错误操作（比如错误地修改了工单状态），还有几次把内部敏感信息答给了没有权限的人。业务方一看，这比人工还麻烦，直接叫停。

注意，这里没有一条是“模型不够聪明”导致的。全是工程问题：权限没做细、操作没做二次确认、错误没做兜底、敏感信息没做过滤。50 万买了个会说话的 Demo，但没买到一个能担责的系统。

4. 一个能活下来的 Agent，架构上必须补哪些层

如果你现在要从 0 到 1 搭一个企业级 Agent，我建议别一上来就纠结用哪个框架。先把下面这几层想清楚，框架只是实现手段。

4.1 接入层：把“入口”和“身份”绑死

Agent 的每一次请求，都必须携带明确的身份和权限上下文。不要指望在 Prompt 里写“你是管理员所以可以……”，那是自欺欺人。正确做法是在接入层就完成鉴权，把用户身份、角色、可访问的数据范围作为结构化参数传给后续流程。

# 伪代码：接入层注入身份上下文 def handle_request(user_token, query): user = auth.verify(user_token) context = { "user_id": user.id, "roles": user.roles, "data_scope": user.allowed_scope, # 例如 ["sales", "inventory"] "session_id": generate_session_id() } return agent_router.dispatch(query, context)

这样后面无论 Agent 怎么绕，工具层都能基于data_scope做过滤。权限不是 Prompt 的事，是代码的事。

4.2 编排层：别让一个 Agent 干所有事

我强烈建议按业务域拆分子 Agent，而不是搞一个万能 Agent。原因很实际：一个 Agent 的工具列表越长，模型选错工具的概率越高。拆开之后，每个子 Agent 的工具集小、职责清晰，路由层负责分派。

编排层还要负责：超时控制、重试策略、降级方案。比如某个工具挂了，是重试、换工具、还是直接告诉用户“暂时不可用”？这些策略要在编排层写死，不能靠模型临场发挥。

4.3 工具层：把“能做什么”和“不能做什么”写进代码

工具是 Agent 的手。手要有边界。每个工具都应该有：

• 输入校验：参数类型、范围、格式，不合法直接拒绝。
• 权限检查：基于接入层传来的data_scope判断能不能执行。
• 幂等设计：同一个请求重复调用，结果一致，避免重复下单之类的事故。
• 审计日志：谁、什么时候、调了什么、结果如何，全部留痕。

# 伪代码：带权限和审计的工具 def update_ticket_status(ticket_id, new_status, context): if "ticket_write" not in context["roles"]: return {"error": "无权限"} if new_status not in VALID_STATUS: return {"error": "非法状态"} log_audit(context["user_id"], "update_ticket", ticket_id, new_status) return ticket_service.update(ticket_id, new_status)

这些代码不性感，但它们是 Agent 能上生产的前提。

4.4 记忆层：分清“会话记忆”和“长期知识”

会话记忆解决“刚才说的那个”，长期知识解决“公司规定是什么”。两者存储方式、生命周期、检索方式都不同。会话记忆可以放 Redis，设 TTL；长期知识放向量库，定期更新。

一个常见错误是把所有东西都塞进向量库，结果检索出一堆过期的会话记录，污染了知识问答。分开存，分开检索，是基本纪律。

4.5 评测与观测层：没有它，你就是在盲飞

这一层是关停项目的最大缺失。你需要：

• 离线评测集：几百条真实问题 + 标准答案，每次改动跑一遍，看准确率有没有掉。
• 在线指标：响应时间、工具调用成功率、人工兜底率、用户负反馈率。
• Trace 追踪：每一次请求的完整链路，包括路由、工具调用、模型输入输出，出问题能回放。

没有 Trace，用户说“它答错了”，你连它当时看到了什么都不知道，根本没法修。

5. 那些没人写进文档的实操细节

上面讲的是架构，下面讲几个我在真实项目里踩出来的细节。这些在官方文档里基本找不到，但每一个都能决定项目生死。

5.1 Prompt 里的“不要”比“要”更重要

新手写 Prompt 喜欢列一堆“你要做什么”。但企业场景里，明确禁止行为往往更关键。比如“不要编造订单号”“不要在无权限时透露数据”“不要执行删除操作”。把这些写成硬约束，配合工具层的校验，双保险。

我习惯在系统 Prompt 里放一个“红线清单”，并且用工具层的代码兜底。Prompt 是软约束，代码是硬约束，两者都要有。

5.2 给模型“不知道”的权利

很多 Agent 被逼着必须回答，结果就是胡编。要在 Prompt 里明确告诉它：不确定就说不知道，缺信息就反问。同时，在评测里把“正确地说不知道”也算作正确。否则模型会学会“蒙一个总比不答好”，这在企业场景是灾难。

5.3 灰度发布不是可选项

Agent 上线千万别全量。先放 5% 流量，观察一周。看错误率、看人工兜底率、看用户反馈。没问题再逐步放量。我见过直接全量的项目，出问题时已经影响了几千个用户，业务方直接失去信任。

5.4 人工兜底通道必须顺畅

再好的 Agent 也会有搞不定的时候。关键是搞不定时，能不能平滑转人工，并且把上下文带过去。如果用户还得重新描述一遍问题，体验就崩了。兜底通道的设计，优先级不低于 Agent 本身。

5.5 成本要实时监控

Agent 的 token 消耗可能失控。一个死循环的工具调用，或者一个超长的上下文，能把预算烧穿。要在编排层设 token 上限和调用次数上限，超了就中断并告警。我见过一个项目因为没设上限，一天烧掉了一个月的 API 预算。

6. 如果重来一次，我会怎么排这个项目的优先级

假设现在又给我一个 50 万的 Agent 项目，我会这样排：

第一优先级：把数据和权限打通。没有干净的数据和明确的权限，后面全是空中楼阁。这块我会花掉近一半的时间和预算。

第二优先级：搭评测和观测。在写业务逻辑之前，先把评测集和 Trace 搭起来。这样每写一行代码，都能知道有没有变好。

第三优先级：做最小可用的工具集。不要贪多，先做 3 到 5 个最核心的工具，跑通闭环。

第四优先级：才轮到 Agent 编排和 Prompt 调优。这部分反而可以快速迭代，因为有评测兜底。

最后：灰度、兜底、监控。上线不是终点，是运维的起点。

这个顺序和很多团队的直觉相反。大家习惯先写 Agent 逻辑，最后才补工程。但恰恰是这个顺序，导致了大量项目上线即关停。

7. 关于框架选型，说几句实在话

现在 Agent 框架很多，Java 生态有 Spring AI、Spring Cloud 整合方案，Python 生态有 LangChain、LlamaIndex 等。选哪个，我的建议是：

• 看团队技术栈。Java 团队硬上 Python 框架，维护成本很高。Spring AI 这两年成熟度上来了，企业级 Java Agent 平台用它是合理选择。
• 看是否需要复杂编排。如果只是简单的问答 + 工具调用，别上重框架，自己写几百行可能更可控。
• 看可观测性支持。框架自带 Trace 和评测能力的，优先考虑。这块自己造轮子很费劲。
• 别被“多智能体”概念带偏。多 Agent 协作听起来酷，但调试难度指数级上升。大部分企业场景，单 Agent + 清晰工具边界就够了。

框架是工具，不是目的。我见过用最朴素的方式（直接调 API + 自己写路由）搭出来的 Agent，稳定跑了半年；也见过用最时髦框架搭的，两周就崩。差别不在框架，在工程纪律。

8. 面试里问 Agent，我真正想听到什么

顺带说下招聘。现在 AI Agent 相关岗位面试，很多人上来就聊模型、聊 Prompt 技巧。但我作为面试官，更想听到的是：

• 你怎么做权限隔离？
• 工具调用失败了怎么处理？
• 怎么评测一个 Agent 好不好？
• 上线后怎么发现它变差了？
• 成本怎么控制？

能把这些讲清楚的人，才是真正做过生产级 Agent 的人。只会调 API 写 Demo 的，一上真实业务就露馅。这也是为什么很多公司招了“AI 工程师”，项目却推不动——缺的不是会调模型的人，是懂工程的人。

9. 最后分享一个我自己的检查清单

每次 Agent 准备上线前，我会过一遍这个清单。分享出来，你可以直接拿去用：

这十条，每一条都对应一个我见过或踩过的坑。50 万的项目关停，往往不是败在某一项，而是败在同时缺了好几项。

Agent 这个方向本身没问题，企业级需求也真实存在。问题在于，太多团队把它当成一个“模型问题”来做，而它本质上是一个系统工程问题。模型只是其中一环，而且是相对成熟的一环。真正决定生死的，是那些不性感、不上台面、但必须有人做的工程活。

我在实际项目里的体会是：把 Agent 当成一个需要长期运维的线上服务来设计，而不是当成一个一次性交付的 Demo 来开发，项目活下来的概率会高很多。那些上线一周就关掉的，几乎都是在用做 Demo 的心态做生产系统。这个教训，50 万买一次，不算便宜，但也不算最贵的。