企业官网建设流程全解析

一年前我们把“企业 AI Agent”正式立项时，团队最焦虑的问题是模型选型。市面上旗舰模型、轻量模型、开源权重模型挨个比，评测集做了好几版，从合同问答到工单摘要到报表解读，来回测了小半年。但真正跑完这一年，我发现一件很反直觉的事：模型根本不是我该焦虑的重点。把大量精力花在模型对比上，其实是在逃避三个更脏更累的问题——企业数据怎么喂进来、Agent进入业务流程后边界怎么定、上线之后拿什么机制持续评估和运营。这三件事每一件单独拿出来都比想象中复杂，叠在一起才是企业级Agent落地真正的深水区。

如果你正准备在企业里推Agent项目，或者已经做完PoC但迟迟走不进生产环境，这篇文章应该对你有用。我把这一年的真实复盘整理成下面五个部分，尽量说人话，少讲术语，多讲我们是怎么踩坑、怎么调整的。

1. 先放下模型焦虑：一年里真正卡住我们的地方

1.1 选型阶段的假问题

立项第一天，所有人都问我“能不能用最强的模型”。我的态度是：先别急。因为Agent项目的效果好坏，远不是模型一个变量决定的。

我们当时建了一个评测集，里面放了上百个真实业务问题，用不同模型跑过一轮。结论很直接：模型之间确实存在能力差距，但差距远没有厂商宣传和媒体渲染的那么大。真正拉大效果差距的，是另外三个变量：喂给模型的数据干不干净、业务方有没有把任务边界定义清楚、出问题后有没有人能在几小时之内判断责任方。这三个变量任何一个塌了，模型再强也救不回来。

举一个我们自己的例子。某个合同问答场景，用户反馈Agent答非所问，第一反应是模型不行。排查之后发现，合同原始文件是扫描件，OCR解析完之后表格结构全乱，模型读到的是错位内容。这能怪模型吗？模型只是在一个烂数据源上做了最好的发挥。类似的情况这一年里出现无数次：“模型不够好”往往只是数据、权限、流程这些更基础问题的替罪羊。

1.2 “模型背锅”的三个真实场景

我整理一下这一年来最常见的三类“模型背锅”现场：

第一类是知识过期。企业知识库里的制度文档经常改版，但旧版本没有被标记失效。员工问新政策，Agent从库里检索到了旧政策，答得自信满满，其实内容是错的。这不是模型能力问题，是知识治理问题。

第二类是权限缺失。同一个文档在不同部门眼里内容不同，Agent用一套统一向量索引去检索，结果把不该透露的数据答出去了。这也不是模型的问题，从一开始就不该把所有数据放进同一个索引桶里。

第三类是行为边界不清。模型把“可以推荐方案”理解成“可以自动执行操作”，用户还没确认，它就去改了状态。问题是任务设计和执行纪律不到位。

所以我做了个决定：从第二个月开始，团队不再为模型争论，把精力切到数据、边界、运营这三条线。后面的内容就是这三条线各自发生了什么。

2. 第一件难事：企业知识库不是文档，是一片“数据沼泽”

2.1 为什么RAG在Demo里惊艳，一接真实数据就崩

RAG是Agent落地最常用的技术路线，几乎每个Demo都靠它出效果。但Demo和真实业务之间隔着一整片数据沼泽。

先说数据规模。Demo里用的是整理好的几十篇文档，目录清晰、格式统一。真实企业是几百个系统、几千万条记录、各种年代久远的文件格式堆在一起。你根本不知道答案在哪张表里，也不知道哪份文档是最新版。

再说权限模型。很多企业知识库里的文件本身没有精细的权限标注，同一个知识域下混着对不同角色可见和不可见的内容。Agent如果只按语义相似度去检索，就会把不该检索出来的内容送进上下文。我们在权限这一块吃过亏，后来不得不给所有接入Agent的内容做“可见性标签”。

还有一个被低估的问题是解析质量。PDF里的表格、流程图、扫描件，PPT里嵌套的文本框，甚至聊天记录截图，每一样都可能在解析环节丢失信息。向量检索再强，喂进去的是错位文本，出来就是错位答案。

我把RAG效果的几个影响因素按经验估了个比例：

这个表不是精确统计数据，但方向是准的：绝大多数项目把精力放在最后10%-20%的模型比较上，却忽略了前面占比最高的数据质量。这是我看过很多PoC死在沙滩上最核心的原因。

2.2 我们如何先把一个业务域的数据“捋”干净

我们在数据治理上踩过一轮弯路，最后总结出一套可复制的操作流程。核心原则只有一句话：不要试图一开始就治理全公司的数据，先圈出一个业务域把它做透。

第一步，圈定最小闭环业务域。我们选了一个业务方痛点最明确、数据相对好拿的场景。这个选择很重要，痛点明确才能让业务方愿意投入，数据相对好拿才不会让项目死在数据对接上。

第二步，盘点数据资产。列出这个业务域涉及哪些系统、每张表谁维护、更新频率多高、有没有明确的负责人。这一步会暴露很多“无主数据”，需要提前和业务方对齐责任归属。

第三步，统一实体与权限。同一个客户在不同系统里的ID不一致，同一个订单在报表里和工单系统里的状态字段不一样。先把主数据ID对齐，再给每条内容打上可见性标签。权限打标是后来排查问题时最值得的一笔投入，不要省。

第四步，搭建解析与索引管线。文档解析、表格还原、OCR、图片转文字，每一步都要验证输出质量，尤其要校验表格结构。索引阶段建议做“关键词 + 向量”的混合检索，比单纯向量检索稳定得多。

第五步，用业务样例验收。从业务方手里收集100个真实高频问题，让业务方逐条打标正确答案，做成这个业务域的测试集。每次改动数据管线，都拿这份测试集跑一遍，保证召回质量不后退。

这套流程里，前两步最容易被跳过去。很多团队一上来就建知识库、接模型、搭RAG，等发现问题已经晚了。我们把复盘会开成“数据盘点周”，虽然前两周很痛苦，但后面所有环节都因为前两步做得扎实而少返工。

2.3 数据治理不是搞平台，是“用业务问题倒逼数据变干净”

最开始我们犯过一个方向性错误：想先做一个统一数据平台，把所有数据源接进来做标准化。想法很正统，推进极其困难，因为各部门没有动力配合你改数据。

后来换了个思路：挑几个业务方最痛的问题，先做Agent原型，再把原型暴露出的数据问题列成整改清单，由业务方牵头改源数据。为什么业务方愿意动了？因为Agent好不好用，直接关系到他们的日常效率和考核指标。数据烂，他们的Agent就不好用，他们比你还急。

这个思路可以复刻给所有正在做企业内部数据治理的人：不要把数据治理当成IT项目单独立项，那样大概率变成PPT项目。把数据治理嵌进Agent落地过程，用真实业务问题作为验收标准，数据自然会被推着变干净。

3. 第二件难事：Agent进入业务流程，边界比AI能力更复杂

3.1 从“会聊天”到“会办事”的质变

问答型Agent好做，因为它是只读的，答错了影响有限。但企业Agent真正的价值在“能办事”：查订单、改状态、发通知、触发审批。一旦开始写操作，问题立刻变得复杂。

你可以把Agent想象成一个没有工牌的新员工。它不掌握权限规则，不清楚什么操作需要审批，也不知道什么时候该停下问人。如果没有清晰的边界纪律，它就是一个能快速犯错、且犯错成本极高的自动执行器。

我们定义了一条原则：能读的不碰写，能建议的不自动执行，能小范围试的不全量铺开。这条原则写进了所有Agent开发规范里，不是靠模型提示词约束，而是靠工程手段强制。

3.2 我给Agent定的“三段式”执行纪律

每一个会触发写操作的Agent任务，我们都套用一个三段式结构：前置校验、人工确认、执行与回滚。用一段逻辑示意：

def handle_task(intent, payload): # 第一段：前置校验 if not check_permission(intent): return block("当前身份无权执行该操作") # 第二段：人工确认 if needs_confirmation(intent): request_user_approval(payload) return waiting_approval() # 第三段：执行与回滚 result = call_business_api(payload) if result.status != "ok": rollback() notify_admin() return failure(result.reason) trace_log.append(intent, payload, result) return success(result)

第一段解决身份和权限问题，Agent必须按最小权限原则运行。第二段是兜底，凡是涉及钱、对外承诺、权限变更、批量操作的任务，一律停在“建议模式”，等真人确认再继续。第三段必须考虑失败回滚，因为调用外部系统一定会遇到超时、重复提交、部分成功，这些都需要提前设计。

这个三段式看起来简单，但它是我们这一年里最有效的一条工程经验。回头看，凡是严格遵守这个纪律的场景，上线后出问题的比例都很低；凡是贪快跳过确认环节的场景，基本都在一两个月内爆出过操作事故。

3.3 权限、审批和旧系统：三块绕不开的硬骨头

先说权限。Agent一定要有独立的服务账号，绝不能复用某个员工账号去调接口。独立账号好审计，出了事能追责，也方便做最小化授权。能读的模块只给读权限，能写的模块严格限定范围，跨域访问默认禁止。

再说审批流。企业里本来就有一堆审批系统，Agent发起操作申请时，应该复用它现有的流程，而不是自己再造一套。我们采用“建议→审批→执行→回执”四段流程：Agent先提出建议，审批人在既有系统里点同意，Agent再执行，最后把执行结果回报给审批人。这样业务方的使用习惯不用改，合规审计也有迹可循。

最后说旧系统。很多企业内部系统没有API，只有老旧界面甚至半手工流程。我们的策略是：有API就直连，没API先用RPA兜底，但要求每一步操作都截图留痕，宁可慢一点也不能盲目执行。这块是本年度最耗工程师精力的地方，一定要在立项时预留出足够的人力。

这三块硬骨头最难的不是技术，而是共识。需要在立项阶段就和业务方明确一个问题：Agent能碰哪些数据、能执行哪些操作、哪些必须有人确认。谈清楚再开发，比开发完再补边界容易十倍。

4. 第三件难事：上线不是终点，评估与运营才是长期战场

4.1 上线后重点盯的六个指标

Agent上线后，很多团队就把注意力挪走了，等用户投诉再来救火。我们的经验是：上线只是开始，评估和运营体系如果没搭好，Agent会以肉眼可见的速度变“傻”。

我们线上每天重点盯六个指标：

盯这六个指标给了我们很多次提前预警。比如某段时间任务完成率从81%掉到70%，排查下来不是模型问题，而是上游某个系统更新了接口字段，Agent没有感知。这类问题如果没有线上指标，只靠用户投诉，通常要滞后两周才发现。

4.2 幻觉治理靠三层防线，不靠提示词

关于幻觉治理，我的一句话经验是：不要指望靠提示词解决幻觉，幻觉治理是流程工程。

我们搭了三层防线。第一层是知识召回：检索不到相关内容就明确拒答，不允许模型凭空编造。给Agent设置一个最低相关度阈值，分数不够直接回答“这个信息我这边暂时查不到”。第二层是答案校验：涉及事实和数据的内容，必须从结构化字段或数据源里带出出处，用户在界面上能看到来源编号和链接，能做到“答案可追溯”。第三层是人工复盘：每周抽检10%左右的会话，把“模型自信但实际答错”的案例单独拉出来开会，分析是知识缺失、反馈误判还是边界规则有问题。

这套三层防线真正跑起来之后，我们对线上效果的失控感明显减少。与其追求模型永远不犯错，不如把错误控制在一个可以快速发现、快速修复的流程里。

4.3 成本与模型路由的运营细节

一个容易在立项时被忽略的问题：Agent上线后，模型成本会随着调用量翻倍增长。不是所有请求都需要用旗舰模型，而是应该维护一张“意图→模型”的路由表。

routes: - pattern: "greeting|password_reset|leave_query" model: cheap_model - pattern: "contract_analysis|risk_eval|compliance_question" model: strong_model - default: cheap_model

简单的FAQ、状态查询、企业制度问答，用轻量模型完全够，成本能降一个数量级。复杂的合同分析、风险问答、长文本综合判断，才需要上较强的模型。路由表要和评测集联动：上线前跑离线评测，上线后每周根据badcase调整。

缓存也会显著降低成本。同一类常见问题，在一段时间内可以直接命中缓存结果，不需要每次都调用模型。运营团队每周复盘失败类型，把高频失败案例送回数据侧做优化，而不是天天改提示词——这是我这一年来反复强调的：提示词能优化的事情很少，数据和流程能优化的事情很多。

4.4 团队配置建议：别把运营工作扔给开发

很多Agent项目上线后，运营工作落到了原本的研发团队身上，结果两边都做不好。研发要写代码，没空逐条看会话日志；业务方又不知道怎么看技术指标。

一个可行的配置是：一个“Agent业务运营”兼职角色，最好来自业务部门，每天花一两个小时看会话记录、处理人工介入、整理badcase；再加一个数据工程师和一个后端工程师，分别负责召回质量和接口稳定性。这个组合不用很大，但必须固定下来。业务运营负责发现问题，工程负责下手修复，形成闭环。

5. 复盘这一年，我对企业Agent项目节奏的新认知

5.1 先做“难而窄”的闭环，再做“广而浅”的平台

我们走过一段弯路：一开始想做一个覆盖全公司的统一Agent平台，连接所有系统，支持所有问答场景。想法很大，推进很慢，半年过去还在搭底座。后来收窄到一个具体业务场景，两个月就看到效果。我的感受是：一个能解决真实痛点的窄场景，远好过一个什么都能聊、但什么都不精的平台。从窄场景里沉淀出数据治理方法、执行纪律和运营机制，再去复制到第二个场景，成功率会高很多。

5.2 团队构成决定落地上限

这一年我最大的体会之一是：Agent项目的边界不是由模型划定的，而是由团队构成划定的。有没有一个业务接口人愿意持续整理badcase，决定了Agent能不能持续变好用；有没有一个后端工程师愿意去啃老旧系统API，决定了Agent能不能真正接进业务流程。我建议在立项时就把这两个角色的时间明确预约下来，否则Agent上线后会很快被差评淹没。

5.3 模型可以换，数据、边界、运营换不掉

一年来我们换过两次模型方案，每次切换都只涉及配置调整和回归测试，真正的工程量并不大。但数据管线、权限标签、执行纪律、运营例会这些底层建设，始终没变，也最难变。这让我看清了一件事：当初立项时焦虑的模型选型，其实把注意力放错了地方。把这“三件事”——数据治理、边界设计、评估运营——做好，模型层面的差距很快能补回来；这三件事不做，换最强的模型也救不了场。