企业官网建设流程全解析

1. 50万AI Agent上线一周就关停，问题到底出在哪

“客户花 50 万搞了个 AI Agent，上线一周就关了”——这句话我第一次听到的时候，正在帮另一家客户做 AI Agent 的落地评估。当时会议室里安静了两秒，然后大家几乎同时笑了一下，不是幸灾乐祸，是那种“果然又来了”的苦笑。因为过去一年多，我见过太多类似的案例：预算从几十万到几百万不等，团队从外包到自建都有，但结局高度雷同——上线即巅峰，一周后无人问津，一个月后悄悄下线。

AI Agent 这个词现在太热了。热到很多企业老板在还没搞清楚它和传统自动化脚本、和 RPA、和普通聊天机器人的区别时，就已经批了预算。热到很多开发团队在还没想清楚业务闭环时，就已经开始选框架、搭环境、接大模型 API。热到“从0到1搭建 AI Agent”成了搜索热词，但真正跑通从1到100的人少之又少。

这篇文章不打算给你灌鸡汤，也不打算复述那些“AI Agent 是未来”的宏大叙事。我想做的是，把那个“50万上线一周就关”的项目当成一个解剖样本，从需求、选型、开发、部署、运营五个环节，一层层拆开看，到底是哪些决策导致了失败，以及如果你现在正准备做 AI Agent，怎么避免踩同样的坑。文章会涉及 AI Agent 开发、搭建、部署、应用开发、多智能体协作、企业级 Java AI Agent 应用平台等热词背后的真实工程问题，也会给出一套可以直接参考的落地检查清单。适合正在评估 AI Agent 的技术负责人、正在开发 AI Agent 的工程师，以及那些被老板问“我们能不能也搞一个”的产品经理。

先说结论：那个项目失败的核心原因，不是技术不行，而是把 AI Agent 当成了一个“功能”来交付，而不是一个“系统”来运营。50万里，大概有35万花在了模型调用和算力上，10万花在了外包开发，5万花在了各种中间件和工具订阅。但真正决定生死的，是上线后有没有人持续调优、有没有业务数据回流、有没有明确的成功指标。这些，在合同里一个字都没写。

2. 需求阶段的三个致命误判

2.1 把“能对话”当成“能干活”

很多客户对 AI Agent 的第一印象来自演示视频：一个对话框，你输入需求，它自动查资料、写代码、发邮件、订机票。看起来很智能。但演示环境和生产环境之间，隔着一条巨大的鸿沟。

那个50万的项目，需求文档我后来看过。核心场景是“自动处理客户咨询并生成工单”。听起来很合理，对吧？但拆开看，问题就来了。客户咨询的渠道有五个：网页表单、邮件、电话录音转写、微信消息、第三方平台消息。这五种渠道的输入格式、语言风格、信息完整度完全不同。演示的时候，用的是整理好的文本；上线后，邮件里夹杂着签名档和免责声明，微信消息全是短句和错别字，电话转写更是惨不忍睹。

AI Agent 在演示环境里“能对话”，是因为输入干净、意图明确。但在生产环境里，它首先要解决的是输入清洗和意图识别，而不是对话本身。这个项目的外包团队花了大量时间在对话逻辑上，却只用了不到一周处理输入预处理。结果就是，Agent 经常把“你们这个多少钱”识别成“投诉”，把“我要退款”识别成“咨询”。工单分类准确率上线第一周只有 43%，人工复核的工作量比原来还大。

注意：AI Agent 的“智能”高度依赖输入质量。如果你的业务输入是非结构化、多来源、高噪声的，那么输入预处理的工作量至少占整个项目的 40%。这个比例在需求评估阶段就必须明确，否则后期一定失控。

2.2 没有定义“成功”的量化标准

我问过那个项目的负责人：“上线成功的标准是什么？”他想了半天说：“能自动处理大部分咨询就行。”这个回答就是问题本身。“大部分”是多少？70%？90%？处理到什么程度算“处理”？是自动回复，还是自动生成工单，还是自动关闭工单？没有量化标准，就没有验收依据，也没有优化方向。

后来我们复盘时，我帮他重新定义了一套指标：

这张表一出来，所有人都沉默了。因为如果按这个标准，项目根本不该上线。但问题是，这些指标在合同里一个都没有。外包团队交付的是“功能”，不是“结果”。功能可以演示，结果需要运营。

2.3 忽略了业务方的真实工作流

最要命的一点是，这个 AI Agent 的设计完全没有考虑业务方现有的工作流。原来的客服团队有一套自己的分类规则、优先级判断逻辑、升级机制。AI Agent 上线后，这些规则全被推翻了，但新的规则又没有建立起来。客服人员不知道该怎么和 Agent 协作：是 Agent 先处理，人工复核？还是人工先看，Agent 辅助？还是完全交给 Agent，人工只处理异常？

这种模糊性导致了两败俱伤。Agent 觉得人工干预太多，人工觉得 Agent 添乱。上线第三天，客服主管直接找到老板说：“要么关掉它，要么我们集体请假。”一周后，项目关停。

实操心得：AI Agent 落地前，一定要做一次“工作流映射”。把现有业务流程的每一步画出来，标注哪些步骤 Agent 可以独立完成，哪些需要人工确认，哪些必须人工主导。这个映射图比任何技术架构图都重要。

3. 技术选型：为什么“最先进”不等于“最合适”

3.1 模型选型的误区

这个项目在模型选型上犯了一个典型错误：追求“最强模型”。外包团队选了一个当时榜单排名第一的大模型，参数规模最大，推理能力最强，当然，价格也最贵。50万预算里，有将近20万花在了模型调用上。

但实际业务场景需要的是什么？是处理客户咨询，生成工单。这个任务的核心是分类准确和信息抽取完整，而不是写诗、编程、做数学题。一个中等规模的模型，经过针对性微调，完全可以在分类任务上达到甚至超过大模型的效果，而成本只有十分之一。

我后来做了一个对比测试，用同一个数据集，分别测试大模型和中等模型在工单分类任务上的表现：

结果很明显：中等模型微调后，准确率反而更高，成本只有大模型的十五分之一，延迟只有四分之一。但外包团队没有做这个测试，因为他们按“调用量”收费，模型越贵，他们的利润空间越大。这里面的利益冲突，在选型阶段就必须警惕。

3.2 框架选型的陷阱

AI Agent 开发框架现在多如牛毛。从 LangChain 到 AutoGen，从 CrewAI 到各种企业级 Java AI Agent 应用平台，每个都宣称自己能“从0到1搭建 AI Agent”。但这个项目选了一个当时很火但生态还不成熟的框架，导致后期遇到问题时，社区找不到答案，官方支持又跟不上。

选框架的时候，我一般会看四个维度：

• 社区活跃度：GitHub 的 issue 响应速度、Stack Overflow 的讨论量、中文资料的丰富程度。
• 生产案例：有没有同行业、同规模的真实生产案例，而不是只有 demo。
• 可观测性：框架本身是否提供日志、追踪、指标采集能力。AI Agent 的调试比传统程序难十倍，没有可观测性就是盲人摸象。
• 退出成本：如果这个框架明天停止维护，你的代码能不能相对容易地迁移到另一个框架。

那个项目选的框架，四个维度里只有第一个勉强及格。上线后遇到一个并发问题，issue 提了两周没人理，最后只能自己改源码。改完发现，框架的抽象层太厚，改一处崩三处。

提示：如果你用的是 Java 技术栈，Spring AI 和 Spring Cloud 的组合目前在企业级场景下更稳妥。Spring AI 提供了模型调用的统一抽象，Spring Cloud 提供了服务治理能力，两者结合可以搭建出可观测、可扩展的 AI Agent 应用平台。但要注意，Spring AI 的版本迭代很快，锁定版本前一定要做充分的兼容性测试。

3.3 部署架构的过度设计

这个项目的部署架构图我看了，画了三层：接入层、Agent 编排层、模型服务层。每层都做了高可用、负载均衡、自动扩缩容。看起来很专业，但上线第一周的实际并发量是多少？峰值 12 QPS。平均 3 QPS。

为了支撑这个量级，他们部署了 8 个 Agent 实例、3 个模型服务节点、2 个消息队列集群。每个月的云资源成本超过 2 万。而如果按实际负载，一个中等配置的实例就足够了。

过度设计的代价不只是钱，还有复杂度。8 个实例之间的状态同步、消息队列的重复消费、模型服务的版本一致性，每一个都是潜在的故障点。上线第三天的一次故障，就是因为两个 Agent 实例的模型版本不一致，导致同一类咨询被分到了不同的工单队列。

实操心得：AI Agent 的部署架构应该从最小可行开始。先跑通单实例，再根据实际瓶颈逐步扩展。瓶颈可能在模型推理，可能在输入预处理，可能在外部 API 调用，但一定不在你预先假设的地方。

4. 开发与调试：那些文档里不会写的坑

4.1 Prompt 工程的“最后一公里”

Prompt 是 AI Agent 的灵魂，但很多团队把 Prompt 当成一次性工作。写一版，测试几个 case，觉得差不多就上线了。那个项目的 Prompt 我后来看过，大概有 2000 多字，包含了角色定义、任务描述、输出格式、示例、约束条件。看起来很完整，但问题出在“最后一公里”。

生产环境里的输入千奇百怪。有客户在咨询里夹杂了 emoji，有客户用了方言，有客户把多个问题混在一段话里。Prompt 里没有覆盖这些情况，Agent 就开始“自由发挥”。有一次，一个客户问“你们支持退货吗”，Agent 回复了一段关于公司愿景的话。原因是 Prompt 里写了“如果问题不明确，请引导客户了解公司服务”，Agent 把“退货”理解成了“不明确”。

Prompt 的调试需要建立一套回归测试集。把历史上真实的咨询样本整理出来，至少 500 条，覆盖各种边界情况。每次修改 Prompt，都跑一遍回归测试，看准确率是升了还是降了。这个工作很枯燥，但省不得。那个项目的外包团队没有做回归测试，每次改 Prompt 都是“感觉好点了”，结果就是按下葫芦浮起瓢。

4.2 工具调用的可靠性问题

AI Agent 和普通聊天机器人的最大区别是它能调用工具。查数据库、发邮件、调 API、生成文件。但工具调用的可靠性，在生产环境里是个大问题。

那个项目里，Agent 需要调用一个内部 API 来创建工单。这个 API 有速率限制，每分钟最多 60 次。演示的时候，请求量小，没问题。上线后，高峰期请求量上来了，API 开始返回 429。Agent 收到 429 后，按照 Prompt 里的指示“如果调用失败，请重试”，开始疯狂重试。结果就是，API 被彻底打挂，整个工单系统瘫痪了半小时。

正确的做法是，在工具调用层做限流、熔断、降级。限流控制请求速率，熔断在失败率过高时直接切断，降级在工具不可用时返回兜底结果。这些在传统后端开发里是常识，但在 AI Agent 开发里，很多人因为过度关注模型本身而忽略了。

4.3 多智能体协作的复杂度陷阱

这个项目后期尝试过引入多智能体架构：一个负责意图识别，一个负责信息抽取，一个负责工单生成，一个负责质量检查。听起来很合理，分工明确。但实际运行起来，问题一大堆。

首先是通信开销。四个 Agent 之间需要传递上下文，每次传递都要序列化和反序列化，延迟从单 Agent 的 1 秒变成了 4 秒。其次是错误传播。意图识别 Agent 如果分错了，后面的信息抽取和工单生成全错，而且错误很难追溯。最后是调试困难。单 Agent 出问题，看日志就行；多 Agent 出问题，你要在四个 Agent 的日志之间来回跳，还要理解它们之间的消息流转。

多智能体不是不能用，但要用在合适的场景。比如 coding 协助开发，一个 Agent 负责理解需求，一个负责生成代码，一个负责测试，这种场景下多智能体的分工是自然的。但如果是简单的工单分类，单 Agent 加工具调用就够了，强行上多智能体就是自找麻烦。

注意：多智能体架构的引入时机，应该是单 Agent 在某个环节遇到明显瓶颈，且这个瓶颈无法通过优化 Prompt 或增加工具来解决。不要为了“架构先进”而引入多智能体。

5. 上线后的运营：被忽视的生死环节

5.1 没有数据回流，就没有优化

那个项目上线后，Agent 处理的每一条咨询、生成的每一个工单，都没有被系统地记录下来。外包团队说“日志都打了”，但日志是给开发看的，不是给运营看的。运营需要的是：哪些咨询被分错了？分错的原因是什么？人工修正后的结果是什么？这些数据没有回流，Agent 就永远停留在上线第一天的水平。

我后来帮另一个客户设计了一套数据回流机制，核心是三张表：

• 原始输入表：记录每一条用户输入，包括渠道、时间、原始文本。
• Agent 决策表：记录 Agent 的意图分类、信息抽取结果、调用的工具、最终输出。
• 人工反馈表：记录人工复核的结果，包括是否修正、修正后的分类、修正原因。

这三张表通过一个唯一的会话 ID 关联。每天定时跑一个脚本，把人工修正过的样本抽取出来，加入回归测试集。每周做一次 Prompt 优化，每月做一次模型微调。这样，Agent 的准确率才能持续提升。

那个项目没有这套机制，所以上线一周后，Agent 的表现和第一天一模一样。业务方看不到进步，自然就失去了信心。

5.2 人工与 Agent 的协作界面

AI Agent 不是要取代人，而是要和人协作。但协作的前提是有一个清晰的界面。那个项目里，Agent 生成的工单直接进入工单系统，和人工创建的工单混在一起。客服人员不知道哪些是 Agent 生成的，哪些是自己创建的，也不知道 Agent 的置信度是多少。

正确的做法是，在工单系统里增加一个字段：来源和置信度。来源标记是 Agent 还是人工，置信度是 Agent 对自己判断的把握程度。客服人员可以优先处理低置信度的工单，高置信度的直接通过。这样，人工的工作量大幅降低，Agent 的价值也能被量化。

这套策略上线后，那个客户的客服团队从“抵制 Agent”变成了“依赖 Agent”。因为 Agent 帮他们过滤掉了大量简单重复的咨询，他们只需要处理真正复杂的 case。

5.3 成本监控与优化

50万里有20万是模型调用费，但上线第一周的实际调用量只有预估的 30%。也就是说，有大量预算被浪费在了“预留容量”上。AI Agent 的成本结构和小程序、APP 完全不同，它的成本是随调用量线性增长的。如果没有实时监控，很容易出现“预算花完了，业务还没跑起来”的情况。

我一般会建议客户在 Agent 编排层加一个成本拦截器。每次模型调用前，先估算这次调用的 token 消耗和费用，如果当日累计费用超过阈值，就自动降级到更便宜的模型，或者直接返回“系统繁忙，请稍后再试”。这个拦截器不需要很复杂，一个简单的计数器加规则引擎就够了。

实操心得：AI Agent 的成本优化，优先级最高的是“减少无效调用”。很多 Agent 会在用户输入很短、意图很明显的情况下，仍然调用大模型做完整推理。其实这种场景可以用规则引擎先过滤一遍，只有规则引擎无法处理的，才走模型。这一层过滤，通常能减少 30%-50% 的模型调用量。

6. 如果你现在要做 AI Agent，这份检查清单请收好

6.1 需求阶段的自检问题

在写第一行代码之前，先回答这几个问题。如果有一个答不上来，就不要启动开发。

• 这个 Agent 解决的具体业务问题是什么？请用一句话描述，不要超过 30 个字。
• 这个问题的现有解决方案是什么？人工处理？传统自动化？为什么现有方案不够好？
• Agent 的成功标准是什么？请给出至少三个可量化的指标，以及上线首周的目标值。
• 业务方的现有工作流是怎样的？Agent 介入后，哪些步骤会改变？业务方是否接受这些改变？
• 如果 Agent 的准确率只有 60%，业务方还能接受吗？如果不能，备选方案是什么？

6.2 技术选型的决策框架

技术选型没有绝对的对错，只有适不适合。我一般用下面这个框架来做决策：

那个50万的项目，在“业务匹配度”和“成本可控性”上得分很低，但因为外包团队推荐，客户还是选了。这就是典型的“技术决策被商务决策绑架”。

6.3 开发与部署的最小可行路径

如果你不想重蹈覆辙，我建议按这个路径来：

1. 第一周：只做输入预处理和意图识别。用规则引擎加小模型，先把输入清洗和分类跑通。不要碰大模型，不要碰多智能体。
2. 第二周：接入大模型，做信息抽取和工单生成。Prompt 要简单，只做一件事。建立回归测试集，至少 200 条。
3. 第三周：接入工具调用，做限流、熔断、降级。部署单实例，观察实际负载。
4. 第四周：上线试运行，只开放一个渠道，只处理一类咨询。建立数据回流机制，每天看数据。
5. 第五周及以后：根据数据逐步扩展渠道和场景，优化 Prompt，考虑模型微调。

这个路径看起来慢，但实际比“大干快上”快得多。因为每一步都有反馈，每一步都可以调整。那个50万的项目，如果按这个路径走，第一周就会发现意图识别准确率只有 43%，然后及时调整，而不是等到上线一周后才发现问题。

6.4 上线后的运营指标看板

上线不是终点，是起点。你需要一个看板，每天看这几个指标：

• 准确率：意图识别、信息抽取、工单生成的准确率，按渠道、按咨询类型拆分。
• 覆盖率：Agent 能独立处理的咨询占比，以及这个占比的变化趋势。
• 人工介入率：需要人工复核或修正的占比，以及介入的原因分布。
• 成本：每日模型调用费用、单次调用平均成本、成本与处理量的比值。
• 用户反馈：咨询者对 Agent 处理结果的评分，以及负面反馈的关键词聚类。

这个看板不需要很复杂，一个简单的 BI 工具加定时任务就够了。关键是每天看，而不是上线一个月后才想起来看。

7. 最后分享几个我踩过的坑

第一个坑：不要相信“开箱即用”的 AI Agent 平台。我试过好几个号称“零代码搭建 AI Agent”的平台，演示很漂亮，但一到生产环境就各种限制。要么不支持自定义工具，要么不支持私有化部署，要么按调用量收费贵得离谱。AI Agent 的落地，一定需要定制开发，只是定制的程度不同。

第二个坑：不要忽略冷启动问题。AI Agent 上线初期，没有历史数据，没有用户反馈，准确率一定不高。这时候如果直接全量开放，用户体验会很差。正确的做法是灰度发布，先开放 10% 的流量，观察一周，再逐步扩大。那个50万的项目就是全量上线，第一天就崩了。

第三个坑：不要用技术指标代替业务指标。模型准确率 90% 听起来很高，但如果业务方关心的是“工单处理时长”，而 Agent 把处理时长从 2 分钟变成了 4 分钟，那准确率再高也没用。技术指标是手段，业务指标才是目的。

第四个坑：不要忘了人的因素。AI Agent 上线后，最抵触的往往是原来做这件事的人。他们担心被取代，所以会放大 Agent 的缺点，忽略优点。这时候需要做两件事：一是明确 Agent 是辅助不是替代，二是把 Agent 节省下来的时间还给人工，让他们去做更有价值的事。那个项目的客服主管之所以强烈反对，就是因为 Agent 上线后，他们的工作量反而增加了，而且没有看到任何好处。

第五个坑：不要一次性投入太多。50万不是小数目，但如果拆成 5 个 10 万，分阶段投入，每个阶段验证一个假设，风险会小很多。第一阶段验证输入预处理，第二阶段验证意图识别，第三阶段验证工具调用，第四阶段验证业务闭环，第五阶段验证规模化。每个阶段都有明确的退出条件，不行就停，损失可控。

AI Agent 是个好东西，但它不是魔法。它需要清晰的业务定义、合理的技术选型、扎实的工程实现、持续的运营优化。缺了任何一环，都可能变成“上线一周就关”的案例。希望这篇文章能帮你少走一些弯路。如果你正在做 AI Agent，或者准备做，欢迎交流，我踩过的坑，你可以不用再踩一遍。