企业官网建设流程全解析

1. 演示惊艳、上线就崩：这个现象到底卡在哪

做过企业智能体项目的人，大概率都经历过这个场景：POC 阶段演示行云流水，老板点头、业务方鼓掌，项目顺利立项。结果一上生产环境，用户问三个问题就开始胡言乱语，响应时间从 2 秒飙到 20 秒，知识库更新一次要停服半天，权限控制形同虚设。最后项目组被拉去复盘，第一反应往往是“模型不行，换个更大的”。

我前后参与过四个企业级智能体从立项到上线的完整周期，踩过的坑足够写一本错题集。可以很负责任地说：企业智能体落地失败的项目里，八成以上的根因不在大模型本身。模型能力在过去两年进步飞快，但企业场景的复杂度并没有因为模型变强而降低。真正卡住项目的是模型之外的那一整套工程体系——知识怎么组织、工具怎么调用、上下文怎么管理、权限怎么隔离、效果怎么评估。

这篇文章面向正在做或准备做企业智能体的技术负责人、架构师和一线开发。我会把“演示惊艳、上线就崩”这个现象拆开，从知识层、工具层、上下文层、评估层四个维度讲清楚瓶颈在哪、怎么排查、怎么补。涉及 RAG、知识图谱、Function-Calling、Agentic RAG 这些热词的地方，我会结合真实项目里的取舍来讲，不堆概念。

先给一个结论性的判断：企业智能体的核心竞争力，正在从“模型选型”转移到“知识工程 + 上下文工程 + 工具编排”这三件事上。谁先把这三件事做扎实，谁的项目就能从 Demo 走到生产。

2. 为什么大模型不是瓶颈：三个反直觉的观察

2.1 模型能力过剩与场景能力不足的错位

现在主流开源模型在通用问答、代码生成、文本摘要上的表现，已经能满足绝大多数企业场景的基线要求。你拿一个 7B 到 14B 级别的模型做本地部署，配合好的提示词和知识检索，回答质量完全可以超过两年前用最大闭源模型的效果。但为什么上线还是崩？

因为企业场景要的不是“通用能力”，而是“在特定约束下的稳定输出”。用户问“我们公司差旅报销标准是多少”，模型需要的是：准确检索到最新版制度文档、识别提问者所在部门和职级、套用对应的报销档位、用合规的话术输出。这四步里，模型只负责最后一步的语言组织，前三步全是工程问题。模型再强，检索到的是过期文档，输出就是错的。

我见过一个项目，团队花了两周对比五个模型的 benchmark 分数，最后选了一个综合分最高的。上线后发现，用户最常问的二十个问题里，有十四个的答案依赖一份三个月前更新的产品手册，而这份手册在向量库里的切片方式是按固定 512 token 切的，把一张关键参数表切成了三段，检索时只召回其中一段，模型拿着残缺的表格硬编，答案自然离谱。这个问题换任何模型都解决不了。

2.2 演示环境的“幸存者偏差”

Demo 为什么总是惊艳？因为演示的问题是被精心挑选过的。演示者知道知识库里有什么、知道哪个问题能触发最好的检索结果、知道怎么措辞能让模型输出漂亮答案。这本质上是一种“人肉兜底”。

生产环境没有这种兜底。真实用户的提问方式千奇百怪，有错别字、有口语、有指代不明、有跨文档的复合问题。更关键的是，生产环境的知识库是动态的——今天新增一份合同、明天修改一条政策、后天删除一个过时页面。Demo 阶段那个静态的、被反复调试过的知识库，和生产环境根本不是一个东西。

提示：判断一个智能体项目能不能上线，不要看它答对了多少演示问题，要看它在“知识库刚更新完”“用户提问带错别字”“问题涉及三份以上文档”这三种情况下的表现。

2.3 被低估的“最后一公里”工程

从“能回答”到“敢让业务用”，中间隔着权限、审计、降级、兜底、反馈闭环这一整套东西。这些工作不产生演示效果，但决定了项目能不能真正跑起来。

举个具体的：Function-Calling。演示时调用一个查询天气的接口很丝滑，生产环境里要调的是企业内部的 ERP、CRM、工单系统。这些接口有鉴权、有频率限制、有超时、有各种边界情况。模型生成的参数格式稍微不对，接口就报错；接口报错后模型如果不会优雅降级，用户看到的就是一句“系统繁忙”。这一公里的工程量，往往比调模型大得多。

3. 知识层：RAG 不是万能药，知识组织才是

3.1 朴素 RAG 的天花板在哪

很多人对 RAG 的理解还停留在“文档切片 → 向量化 → 相似度检索 → 塞进提示词”这个四步流程。这套朴素 RAG 在单文档、事实型问答上够用，但一碰到企业场景就露怯。

问题出在“相似度”不等于“相关性”。用户问“A 产品的退款政策”，向量检索可能召回一段讲“B 产品退款流程”的文本，因为两段话用词高度相似。更麻烦的是多跳问题——“去年签约的客户里，哪些符合今年新政策的续约优惠条件”，这需要先查客户名单、再查签约时间、再比对政策条款，单次向量检索根本做不到。

我实测过一个中等规模的知识库，大概两千份文档。用朴素 RAG，Top-5 召回的准确率在简单问题上能到 80% 左右，但一旦问题涉及两个以上实体或需要时间推理，准确率直接掉到 40% 以下。这个数字在 Demo 里看不出来，因为 Demo 不会问这种问题。

3.2 从 RAG 到 Agentic RAG 的演进路径

Agentic RAG 的核心思路是：不让检索一步到位，而是让智能体自己决定“要不要检索、检索什么、检索几次、结果够不够”。这更接近人类查资料的方式——先查一轮，发现信息不够，换个关键词再查，或者去查另一个数据源。

具体实现上，常见的有几种模式。一种是查询改写，用户问“这个怎么弄”，智能体先结合对话历史把它改写成“XX 功能的配置步骤是什么”，再去检索。另一种是迭代检索，第一轮召回后让模型判断信息是否充分，不充分就生成新的查询再检一轮。还有一种是路由检索，根据问题类型决定去向量库、去图数据库还是去调 API。

这里要泼一盆冷水：Agentic RAG 不是免费午餐。每多一轮检索和判断，就多一次模型调用，延迟和成本都会上升。我的经验是，只在确实需要的场景用 Agentic 模式，简单事实型问题走快速通道。判断逻辑可以基于问题长度、是否包含多个实体、是否包含时间词等特征做一个轻量分类器，没必要所有问题都上重型流程。

3.3 知识图谱什么时候值得上

知识图谱在企业智能体里的价值，主要体现在处理“关系型”和“推理型”问题上。比如组织架构查询、产品依赖关系、合同条款的层级引用，这些用图结构表达比用文本切片自然得多。

但知识图谱的构建和维护成本很高。你需要定义本体、抽取实体和关系、做实体对齐、持续更新。我见过团队花三个月搭了一个漂亮的知识图谱，结果业务方改了一次组织架构，图谱就大面积失效，因为关系是硬编码的。

我的建议是：先用 RAG 跑起来，当发现某类关系型问题反复出错、且这类问题占比超过 15% 时，再考虑为这部分单独建图谱。图谱不要追求大而全，聚焦在最高频、最刚需的那几个关系上。Neo4j 这类图数据库配合本体建模工具，做局部知识的结构化是划算的，但别一上来就搞全量知识图谱。

3.4 知识切片的实操细节

切片这件事，看起来简单，实际上决定了检索质量的上限。固定长度切片是最省事的，但也是最容易出问题的。我的做法是分层切片：

• 第一层按文档结构切，章节、小节、段落，保留标题作为上下文
• 第二层对长段落做语义切分，用句子边界而不是字符数
• 第三层给每个切片打上元数据标签：来源文档、更新时间、所属部门、密级

元数据标签在检索时可以做过滤，这是提升准确率最有效的手段之一。用户问“技术部的报销标准”，检索时先按“所属部门=技术部”过滤，再算相似度，召回质量立刻不一样。这个改动成本很低，但效果立竿见影。

注意：切片时一定要保留足够的上下文。一个切片如果脱离了它所在的章节标题，语义会严重失真。我习惯在每个切片的开头拼接上它的父级标题路径，比如“员工手册 > 差旅管理 > 报销标准 > 国内出差”。

4. 工具层：Function-Calling 的工程化才是深水区

4.1 工具描述写得好，调用成功率翻倍

Function-Calling 的效果，很大程度上取决于工具描述的质量。模型是根据你给的函数名、参数说明、描述来决定调不调、怎么调的。描述写得含糊，模型就乱调。

我总结了一个工具描述的模板，实测下来调用准确率比随手写的描述高不少：

• 函数名用动词开头，明确动作，比如query_employee_leave_balance而不是leave_info
• 描述里写清楚“什么时候用这个工具”，而不只是“这个工具做什么”
• 每个参数都写清楚类型、取值范围、是否必填、默认值
• 给出一个调用示例，模型会模仿示例的格式

还有一个容易被忽略的点：工具数量不要太多。一次性给模型塞二三十个工具，它的选择准确率会明显下降。我的做法是按场景分组，每组不超过八个工具，根据对话上下文动态加载相关的那一组。

4.2 参数校验与错误处理

模型生成的参数不可全信。数字可能超出范围、日期格式可能不对、枚举值可能拼错。所以工具调用的第一道防线是参数校验，校验不通过就返回明确的错误信息让模型重试，而不是直接把错误抛给用户。

错误信息的设计也有讲究。不要返回“参数错误”这种笼统的话，要返回“参数 start_date 格式应为 YYYY-MM-DD，你提供的是 2024/1/1”。模型看到具体错误，下一轮修正的概率高很多。

超时和重试策略同样重要。企业内部接口响应慢是常态，设置合理的超时时间，超时后要么降级到缓存结果，要么明确告诉用户“查询超时，请稍后重试”。最怕的是接口卡住，整个对话挂在那里。

4.3 工具编排与依赖管理

复杂任务往往需要多个工具按顺序调用，前一个的输出是后一个的输入。这种编排如果全靠模型自己决定，稳定性很差。更可靠的做法是把常见的多步流程封装成一个“复合工具”，内部用代码控制调用顺序，模型只需要触发这个复合工具。

比如“查询某员工上个月的加班时长并折算调休”，这背后是查考勤、查加班规则、做计算三步。与其让模型依次调三个工具，不如封装一个calculate_overtime_compensation工具，内部把三步串起来。模型只需要提取员工 ID 和时间范围两个参数。

这样做的好处是：调用链可控、错误处理集中、性能可优化。代价是灵活性降低，但对于高频固定流程，这个取舍是值得的。

5. 上下文层：提示词工程之外，还有上下文工程

5.1 上下文窗口不是越大越好

现在模型上下文动辄 128K、200K，很多人就觉得可以把所有东西都塞进去。实测下来，上下文越长，模型对中间部分的注意力越弱，关键信息如果落在中间，反而容易被忽略。这就是所谓的“lost in the middle”现象。

我的做法是严格控制每次请求的上下文预算。系统提示词控制在 500 token 以内，检索到的知识切片总量控制在 2000 token 以内，对话历史只保留最近三轮，更早的做摘要压缩。这样总上下文控制在 4000 token 左右，模型注意力集中，响应也快。

5.2 对话历史的管理策略

多轮对话里，历史怎么管理直接影响效果。全量保留会撑爆上下文，全部丢弃又会导致指代消解失败。我的策略是分层处理：

• 最近两轮对话保留原文
• 第三到第六轮做要点摘要
• 更早的只保留关键实体和结论

摘要用一个小模型来做，成本低。关键实体包括用户提到的产品名、订单号、时间等，这些在后续对话里可能被指代。

5.3 系统提示词的结构化写法

系统提示词不要写成一大段散文，要结构化。我通常分成几个区块：角色定义、能力边界、输出格式要求、安全约束、工具使用规范。每个区块用明确的分隔符隔开，模型更容易遵守。

输出格式要求这块，如果业务需要结构化数据，直接在提示词里给出 JSON schema，比事后解析自然语言靠谱得多。安全约束要写清楚哪些话题不回答、哪些操作需要二次确认。

6. 评估层：没有评估体系，优化就是盲人摸象

6.1 建立场景化的评估集

评估集不能随便找几个问题凑数。要覆盖真实用户的提问分布：高频问题、长尾问题、边界问题、对抗性问题。我一般会从生产日志里采样，加上业务专家补充的典型场景，凑够 200 到 500 条。

每条评估数据要标注：期望答案、期望调用的工具、期望检索到的文档。这样评估时不仅能看最终答案对不对，还能定位是检索错了、工具调错了还是生成错了。

6.2 关键指标与监控

上线后要持续监控几个核心指标：检索命中率、工具调用成功率、端到端响应时间、用户追问率、人工转接率。追问率高说明第一轮回答没解决问题，转接率高说明智能体搞不定。

这些指标要按场景、按用户群、按时间段拆开看。整体指标好看不代表没问题，可能只是高频简单问题拉高了平均分，掩盖了复杂场景的糟糕表现。

6.3 反馈闭环的搭建

用户反馈是最宝贵的优化信号。要设计低摩擦的反馈入口，比如回答下方的“有用/没用”按钮，以及一个可选的文字反馈框。收集到的负反馈要定期分析，归类到检索问题、工具问题还是生成问题，然后针对性优化。

我习惯每周做一次 bad case 复盘，把负反馈里最典型的十条拿出来，逐条分析根因。坚持做三个月，效果提升比换模型明显得多。

7. 上线前的自查清单与避坑经验

7.1 上线前必须验证的七件事

1. 知识库更新流程是否自动化，更新后检索是否即时生效
2. 工具接口的鉴权、限流、超时、降级是否都配置到位
3. 权限控制是否做到文档级和字段级，越权访问是否有拦截
4. 上下文长度是否有硬上限，超长时是否有截断策略
5. 评估集是否覆盖主要场景，基线指标是否达标
6. 日志是否完整记录检索结果、工具调用、模型输入输出
7. 是否有兜底话术和人工转接通道

7.2 几个血泪教训

第一个教训：别在周五上线。智能体上线后的问题往往在真实流量下才暴露，周五上线意味着你要带着问题过周末。我吃过这个亏，周六凌晨被叫起来处理检索服务内存泄漏。

第二个教训：知识库更新要有灰度。直接全量替换向量库，万一新切片有问题，回滚都来不及。正确做法是新旧两套索引并存，切一小部分流量到新索引，观察指标没问题再全量切换。

第三个教训：工具调用要有熔断。某个下游接口挂了，不能让整个智能体跟着挂。熔断后返回缓存结果或友好提示，比让用户等三十秒然后报错强得多。

7.3 常见问题速查表

8. 我个人的一些实操体会

做企业智能体这两年，最大的感受是：这个领域的门槛不在算法，在工程。模型能力会持续进步，但知识组织、工具编排、上下文管理、评估监控这些工程能力，是需要一个项目一个项目积累的。换模型解决不了知识库切片不合理的问题，加参数解决不了工具接口超时的问题。

如果让我给正在做这类项目的团队一个建议，我会说：把 70% 的精力放在模型之外。花时间研究业务的知识结构，花时间打磨工具接口的健壮性，花时间建立评估和监控体系。模型选一个中等偏上的、支持 Function-Calling 的就行，剩下的功夫下在工程上。

还有一点：不要追求一步到位。先做一个能跑通最小闭环的版本，哪怕只支持十个高频问题、只调三个工具。上线收集真实反馈，然后迭代。我见过太多团队想憋一个大而全的版本，结果做了半年还没上线，业务方失去耐心，项目被砍。小步快跑，在这个领域同样适用。

最后分享一个我常用的调试技巧：把每次请求的完整链路——用户输入、改写后的查询、检索到的切片、工具调用参数和结果、最终提示词、模型输出——全部落库。出问题时按请求 ID 一查，问题出在哪一环一目了然。这个日志体系建起来之后，排查效率至少提升三倍。