企业官网建设流程全解析

2024年最魔幻的甲方故事，大概就是这一条：客户掏了 50 万找我们做企业级 AI Agent，结果上线不到一周，自己主动要求关停。

这个项目是我去年经手的，当时团队内外一片看好，客户方的 IT 总监甚至在公司内部立了军令状，说要做出集团第一个"能真正干活的 AI 员工"。结果呢？正式上线的第七天，客户主动找我们开会，语气委婉但态度坚决——"先停了吧，我们用回原来的系统。"

很多人听到这个结局，第一反应是：这 AI Agent 肯定做得稀烂，或者供应商纯纯割韭菜。我要是局外人，我大概率也会这么想。但作为从需求调研、技术选型、开发到上线的亲历者，我可以负责任地讲：这个项目不是烂活，而是从一开始就埋了雷的"伪需求"。50 万的投入，一周的存活期，背后涉及的远不只是技术问题，是一个组织对 AI Agent 这四字概念集体误读的缩影。

这篇文章不吹技术神剧，也不贩卖焦虑，我想把这 50 万买来的教训系统性复盘一遍。从需求拆解到技术选型，从 RAG 到工具调用，从验收标准到上线节奏，每一处都是拿真金白银换来的经验。看完你至少能明白：什么样的人才适合自建 AI Agent，什么样的团队上来就做 Agent 大概率翻车，以及如果你已经踩在坑边上，怎么把自己拽回来。

1. 项目背景与需求拆解：从一开始就迷之自信

1.1 客户到底想要什么：一个"什么都能干"的 AI 员工

先还原一下客户最初提需求时的原话。对方商业运营部的负责人说："我们要做一个企业级的 AI Agent，它能够处理员工日常的报销、请假、合同审批、知识查询，还要能自动生成一些常规的运营报告。"

这句话听着是不是特别正常？正常的让人根本挑不出毛病。但实际上它就是整个失败最大的源头——这是一个没有边界感的需求。什么叫"处理报销"？是自动填表、自动审批、自动对接财务系统、还是自动判断发票真伪？"处理合同审批"是要帮人起草合同，还是要审核条款，还是只是把合同文件做归类流转？

我当时带着咨询顾问专门上门挖了两个下午的需求，最后挖出来的真相是：客户自己对 AI Agent 的理解，停留在"一个特别聪明的对话框"上——就像把 ChatGPT 绑上了公司内网权限，有什么问题就问它，它什么都能答，什么都能办。

这不是个别现象。2024 年到 2025 年 AI Agent 概念被炒得火热，大量企业主把"智能体"和"万能助手"画了等号。他们不会去想 Agent 背后由模型、工作流、知识库、工具 API、权限体系、调参、评测、监控一整套基础设施支撑，只会认为：AI 嘛，不就是投喂数据然后问它问题吗？

这个认知差，是项目走向失败的第一个致命起点。

1.2 需求边界不清，项目范围注定失控

按照标准的项目方法论，需求不清晰是要先梳理清楚再动手的。但这里有一个现实压力：客户的 50 万预算是走年度 IT 创新专项批下来的，钱必须在指定时间节点前花完、出成果，否则下一年预算就没了。于是整个项目从一开始就被倒逼着往前走，需求越不清晰，合同就越要赶紧签。

最后我们在合同技术附件里写了一大堆模糊描述："智能应答"、"数据分析"、"自动办公流程处理"、"24 小时在线"。每一个词拿出来看都像模像样，但每一个词拆开看都是要单独做一个系统的工程量。

单价 50 万，听起来似乎不少，但如果你把它拆成需求调研、模型 API 调用、一套私有化部署环境、前端后台、知识库构建、三位开发两个月的工时，实际上连成本都未必覆盖得周全。更不要说客户还要求接入内部 OA、ERP 和即时通讯工具。

这个项目从一开始就是被预算倒推出来的畸形产物——不是需求值 50 万，而是客户刚好有 50 万预算想投 AI，于是就用 AI Agent 这个筐把 50 万的期望全装了进去。但装进去归装进去，真正上线时用户并不会因为"你花了 50 万"就降低期待。

2. 技术方案选型与架构设计：理性上正确，认知上超前

2.1 Agent 技术栈的选择：我们确实没糊弄

说句公道话，这个项目在技术选型上，我们内部讨论了很久，方案至少在 2024 年那个时间节点算是主流且合理的。

推理底座我们用的是当时可私有化部署的大参数模型，整体架构走了LLM + 工作流 + RAG + 工具调用的标准 Agent 路子：

• 意图识别模块：负责听懂用户"我要报销"到底想干什么；
• 对话管理模块：负责多轮对话下的信息收集，比如日期、金额、发票号；
• RAG 引擎：从企业知识库中检索报销制度、差旅标准、合同模板；
• 工具调用层：对接内部系统 API，尝试打通 OA 审批流、ERP 数据查询。

为了让模型在特定业务上表现稳定，我们当时用了不少提示词工程的技巧，复杂的系统提示词写了足足 2000 多行，把各种业务场景、对话流程、兜底话术都做了约束。同时为了控制幻觉，所有生成结果都加了知识库溯源引用，回复中会附上来源文档编号。

这套方案，放在技术社区里拿出来说，没人能挑出大毛病。问题在哪？问题在于我们低估了把"企业内部流程"变成工具调用接口这件事的恐怖复杂度。

2.2 RAG 不准确，recall 这件事远比想象中难

当时客户提供的知识库文件有 2000 多份，Word、PDF、Excel、扫描件全都有。其中一半以上是历史制度文档，版本混乱，有些已经被废止的规定在旧文件里根本没标"已废止"。

我们花了大量精力做文档清洗、分块、向量化和元数据标注。但上线后真实用户问的是什么呢？"我出差超标住宿能报销吗？"——这个问题在制度文件里对应的不是一句现成的话，而是"一二线城市不超过 500 元每晚，特殊地区上浮 30%，且需提前审批"这种散落在不同段落、不同附录里的信息。底层的向量数据库检索语法上能召回，但召回的内容经常是零散的、相互割裂的片段。

用户看到 Agent 给出的答案里带着原文编号，但这种答案如果逻辑链条对不对？要问财务核实过，但财务反馈"答案说得不算错，但是不够完整"——这句话翻译过来就是：在真实法律效力的企业内部制度面前，AI 的"大致正确"就是"不可用"。

2.3 工具调用与系统集成的现实落差

再来说说"自动完成报销审批"这件事。

当时我们和客户的技术团队对接，发现 OA 系统虽然有 API，但接口能力非常弱：只能提交单据，不能查流程进度，不能感知审批人变更，单据状态的回调经常延迟半小时以上。而我们设想的 Agent"主动跟进、多轮确认、闭环执行"，在接口层面就全被堵死了。

更深层的问题是：企业系统之间的数据打通，远不只是接口开发的问题，还涉及数据权限、组织权限、敏感信息脱敏等一大堆风控合规的东西。IT 部门答应开放接口，但业务部门不放心把核心财务数据直接交给一个 Agent 去调。

于是我们做了一个权宜设计：Agent 不直接提交单据，而是帮用户先把报销单填好、附件整理好，最后需要人点一下确认按钮再推到 OA。这就是业内常说的Human-in-the-Loop（人在回环）方案。

这个方案从工程上说是成熟的、稳妥的，但从用户体验上说是灾难的——用户发现 AI 并没有真正"帮我办事"，只是帮我填了张表，那这 50 万花的有什么意义？

3. 实操落地与上线过程：从技术演示到真实场景的溃败

3.1 POC 阶段疯狂打满分，副作用开始累积

整个项目的 POC（概念验证）阶段，演示效果非常出色。我们在精心挑选的 20 个测试问题上，Agent 的回答几乎全对，特别是"报销标准""年假计算""合同模板查找"这类结构化、确定性的问题，表现堪称完美。

但 POC 的问题在于，它是我们陪着客户工作人员一起做的。测试人员坐在旁边，一个一个地输入问题，AI 回答正确，大家鼓掌。这种氛围下永远只会测那 20 个"标准答案"问题，大量真实世界的"刁钻问题"被下意识地跳过了——比如用户口音重、描述凌乱、问法变种、多句话里带情绪，这些都是 POC 里不会出现的。

我在复盘时经常说一句话：POC 验证的不是系统能力，而是演员的剧本水平。只要测试问题是你挑的，答案是你预设的，那这个 Agent 在 POC 阶段永远获胜。

3.2 上线第一天：用户的问题就给了我们当头一棒

正式上线第一天，上午 9 点到 11 点，Agent 收到了 400 多个真实问题。我们原以为用户会在线提问各种业务制度类问题，结果大概 60% 的问题完全超出了我们预先设计的"业务边界"：

"你帮我查一下我们部门上个月团建经费花了多少" "帮我写一封给客户道歉的邮件" "系统能不能把大家的考勤异常自动汇总成 Excel 发我" "我的电脑连不上打印机了"

这些问题，任意一个对我们 Agent 的知识库和工具权限来说，都是望尘莫及的。但用户不管这些，在他们眼里"这和微信里那个 AI 有啥区别？"——这才是最伤的。

不只是超出边界，在边界内的问题暴露得也很明显。我们之前实现的"多轮对话管理"，只要用户连续追问超过三轮，尤其是在中间插入了一个新话题再跳回来，Agent 经常上下文就乱了。典型场景：

"我要报销，打的费可以吗？" "可以。" "那是所有城市都一样吗？" "是的，按照票面金额实报实销。" "哦，那高铁呢？" "高铁二等座可以。" "好吧，那你帮我把刚才报销申请单生成一下吧。"

只要用户对刚才某一轮的对话内容做修正——"我说错了，不是高铁，是飞机"——Agent 就会懵。它要么忽略修正，要么把新需求和旧需求混在一起，生成一份完全不合规的报销单。

这个体验下来，所有的用户反馈集中成一句话："这玩意儿比我预想的笨多了。"

3.3 幻觉问题：无法被原谅的那最后 3%

上线后做了一次随机效果抽检，专业评测人员人工标注了 100 个问答对。统计结果：回答准确率大概在 91% 左右，有 6% 属于不完整，还有 3% 属于明确的错误信息——也就是幻觉。

这 3% 说什么我也得解释清楚。比如有一个用户问："我入职第一年有几天年假？"Agent 回答"5 天"，但实际情况是该公司制度规定第一年按比例折算，只有 3 天。这个错误触发的根本原因，是一份旧版的制度文档没有被正确标注为"废弃"，被 RAG 召回了。

站在技术角度，3% 的错误率似乎可以接受，很多 AI 产品的幻觉率比这还高呢。但在企业级场景里，一个报销制度相关的错误回复，一旦用户照做了，提交了错误的单据，被财务驳回，用户只会大骂"AI 傻 X"，不会觉得是"模型幻觉概率 3%"的统计学问题。

对用户个体而言，错误率不重要，错误的绝对次数才致命。每天 500 次问答，3% 就意味着每天有 15 次错误，一周就是 100 多次错误，每次错误都直接消耗用户对 Agent 的信任——这是任何技术团队的"准确率指标"都无法消化的信任透支。

3.4 上线第七天：用户主动要求关停

上线第七天下午，客户方的运营负责人和 IT 总监一起找我们开视频会。没有吵架，就是那种中年人疲惫的平静："我们内部调研了一圈，员工普遍觉得用这个东西还没自己翻制度快；财务那边也反映 AI 帮忙填的单子错误率高，部门负责人不想用了。我们想先把系统停掉，后面看看怎么调整。"

那一刻我反而有一种松一口气的感觉，因为我知道再硬撑下去，双方都会更难看。50 万的单子，赚是赚了，但交付后一周就下线的口碑损失，远比这 50 万本身更昂贵。

4. 复盘与避坑：这 50 万到底买到了什么教训

4.1 最大的问题：我们用"技术合理性"掩盖了"业务伪需求"

如果把这次失败归因到某个单一原因，上面写这么多细节都会被压扁成一句话：客户想要的不是一个 AI Agent，而是一个信息系统的"统管员"，但 AI Agent 根本不是这回事。

Agent 擅长的是相对边界清晰的定向任务，比如"把这份合同摘要提取出来""查一下这个客户在 CRM 里的跟进记录""根据本周销售数据生成三类报表"。它不适合"既要又要还要"的开放式企业中枢大脑。

这个认知差不是靠技术能补的。哪怕我们的模型换成 10 倍参数量的新版本，哪怕 RAG 再优化一轮，哪怕工作流编排再精细，如果需求和预期没有对齐，最后体验都是灾难。AI 的能力边界在演进，但组织对 AI 的预期管理几乎总是落后于能力两三年。

4.2 预算决定论 vs 能力决定论

现在很多企业内部有个荒谬的立项逻辑：先看今年还剩多少预算，再决定搞什么 AI 项目。当"花掉 50 万"成为目标，"解决什么问题"反而沦为附属品，这种项目九死一生。

正确逻辑应该是：先锁定一个足够具体的痛点场景，评估这个场景的 ROI，再倒推需要多少预算。如果痛点是"企查查人工查询太慢"，那两万块做一个 API 工具就结案了，根本不值得上复杂 Agent。

4.3 自建 Agent 的准入标准：三个条件缺一不可

结合这个案例和后来我参与的其他项目，我现在判断一个企业适不适合自建 Agent，通常就看三点：

1. 核心场景是否足够收敛：不是"帮员工处理工作"，而是"自动读取供应商发票 PDF 并提取金额校验"。场景越垂直，成功概率越高。
2. 数据与系统接口是否具备条件：知识库是不是清过、结构化过？关键系统 API 是不是开放且稳定？如果接口能力弱，再牛的 Agent 也没法闭环。
3. 是否有能容忍 AI 犯错的机制：在 Agent 判断的场景里，错误成本是否可控？比如"生成草稿人工确认"成本低，而"自动审批付款"一旦错误就是事故。上线路径必须设计成"先辅助、后自动"的渐进节奏。

5. 常见问题与排查技巧实录：企业内部 AI 项目的坑位地图

5.1 问题一："Agent 回答经常是错的，该从哪里开始查？"

按我实操的经验，排错顺序应该是：知识库召回 → 提示词再约束 → 工作流逻辑 → 模型选型参数。90% 的情况是知识库的问题，不是模型不够聪明。优先检查是不是文档版本混了、分块切碎了关键句、召回 TopK 设置太小或太大。可以先手动把用户的问题拿到底层检索接口里跑一遍，看看召回的前三块内容是啥，基本能定位八成问题。

5.2 问题二："用户不满意，是继续调模型还是重做需求？"

记住：需求错了，调模型没用。每次收到负面反馈，先分辨这是"答错了"还是"答非所问"。如果是用户问的东西根本没在系统能力范围内，那这是范围和预期管理问题，不是技术 bug。一定先划定边界，再谈体验优化，顺序不能乱。

5.3 问题三："上线节奏有没有什么讲究？"

有，而且这个坑我踩得最狠。正确做法是选择 5% 的种子用户封闭试用，而不是全员开放。种子用户的特点：愿意配合、能容忍 bug、愿意把问题反馈完整。先在种子用户群体里把流程跑顺，再逐步扩大到全公司。我们当年直接全员开放，等于把半成品暴露给了一群毫无耐心的真实用户，口碑瞬间崩盘，再也救不回来。

5.4 实用技巧：所有 AI 项目都要配好"行为基线"

最后分享一个我们现在内部强制执行的铁律：上线前必须建立"规则兜底"和"人工回流"机制。简单说，就是明确列出 Agent 哪些情况下直接回答"这个我不确定，请转人工"，哪些情况下必须在输出里附带"以上内容仅供参考，请以正式文件为准"的免责声明。

别小看这些像保险条款一样的东西，它们在用户预期管理上比任何技术优化都重要得多。很多时候用户恨的不是 AI 答错，而是 AI 明明错了，却表现得信心满满。

6. 写在最后的一点个人体会

这个项目下线之后，客户那边情绪低落，我们团队也低落了一阵子。有个年轻开发问我："舟哥，我们是不是真的不适合做 Agent 项目？"

我说恰恰相反，这个项目最大的价值就是让所有人看清了：AI Agent 不是企业数字化转型的银弹，它更像一把非常锋利的刀。刀能切菜，能剁骨，但你让一个醉汉闭着眼睛拿它乱挥，最后只会伤到自己。

我在实际操盘后续 AI 项目时，已经把"50 万换一周"这个教训刻进了项目流程的最前端：需求调研里多问三遍"你到底想解决什么"，技术选型里先看接口和数据的底子，上线计划里永远留一条人工步道的后路。

如果你现在正打算给自家企业搞一个 AI Agent，或者你是一个正在接单的乙方开发者，我真诚的建议只有一句：先别急着聊大模型有多强，先把用户手里那叠真实的报销单、合同、Excel 表拿过来，你亲手跑一遍人工流程，你才知道 Agent 要替你扛的到底是什么。

最后再分享一个小技巧：以后做类似项目，第一周别让任何真实用户用，先在内部做一轮"魔鬼测试员"演练——找几个最挑剔、最不懂技术的同事，给他们每个人一份"故意找茬"任务清单，让他们往死里问、往偏了问。他们问出来的每一个离谱问题，都是正式上线前你需要提前想好"兜底方案"的信号。我们所有后来的 AI 项目，都因为这个环节，存活期远远超过了七天。