
前面的文章中我们聊到了:企业智能体,第一关是选对业务场景——不是“做知识助手”,而是“解决哪个具体业务问题”;第二关是嵌入流程节点——不是“有个聊天入口”,而是“在工单分派、合同审核、经营分析等具体动作里接住输入、输出结果、有人确认”。
这两关过了,项目才算真正起步。
但接下来,一线项目经理常问一句:“智能体进流程了,可业务部门还是不敢用——它生成的建议,业务上的可信度有多高?”
问题不在AI有没有输出。而在它输出的时候,依据清不清楚。
这才是知识与数据层真正的战场——它不是建知识库、接数据源的技术活,而是给智能体在业务流程中每一步动作,配上“可信脚手架”。
一、企业不怕AI无输出,怕的是输出的决策没依据

我们陪跑过一个制造企业的合同智能体项目:功能很全——能识别合同类型、抽取条款、比对风险、生成修改建议。Demo时法务点头:“这比人工快80%。”
上线三个月后,法务反馈:“它提示的风险,我得自己再核一遍; 生成的合同,我得去核实依赖哪些模版;修改意见,还得确认是否有价值。”
问题出在哪?不是模型不行,是依据断层:
· 风险提示没关联企业最新《合同审批规则V3.2》;
· 条款比对用的是2023年旧版模板,而2025年已更新“供应商责任豁免”条款;
· 生成的修改建议未标注“依据来源”,法务无法快速判断该采纳还是驳回。
结果?智能体成了“高级草稿机”——它动了,但动得没依据;它快了,但快得不敢用
企业要的从来不是“AI多能干”,而是“它干的每一步,我都能说清凭什么”。
二、知识与数据层,本质是三层依据体系

别被“知识库”“向量检索”这些技术词带偏。真正要理清的,就三层:
1. 知识依据:哪些内容能当“正式口径”用?

不是“有没有知识”,而是“哪些能直接支撑业务决策动作”。比如客服智能体推荐回复话术:
· 可参考优秀销售的沟通经验(参考材料);
· 但涉及补偿政策、服务承诺、升级规则,必须引用《2025客户服务手册》第5章(正式依据)。
我们见过太多项目:把历史会议纪要、内部讨论稿、离职员工笔记全塞进知识库。AI一检索,给出“看似合理”的建议——结果业务一用,发现输出的内容会有多个版本,而其依据也是多种来源。
关键问题:这份知识,谁签发?何时生效?适用哪些客户/产品/区域?冲突时以谁为准?
2. 数据依据:哪些数据能当“判断基础”用?

数据接入≠数据可用.某零售企业经营分析智能体曾出过问题:它标记“Q2客户流失率异常上升”,并建议“加强客户回访”。但业务一查:流失率用的是CRM里的“注册客户数”,而实际考核用的是“付费活跃客户数”——口径差了37%。
数据依据的核心就两点:
· 主数据源是谁?(CRM?ERP?还是周报?)
· 口径是否被业务确认?(财务认的收入,和销售报的“签约额”,能混用吗?)
智能体不怕数据少,怕的是数据“看起来是那样,细究下来就存在诸多矛盾”。
3. 规则与上下文依据:同一条知识,在不同场景里用法不同

这才是最容易被忽略的“隐性依据”。
比如“客户延期付款”:
· 销售看到的是客户关系与跟进节奏;
· 财务看到的是账期与坏账风险;
· 法务看到的是合同违约条款;
· 管理者看到的是现金流预警。
如果智能体不识别当前角色、流程节点、业务对象,它可能把法务该处理的风险,直接推给销售去“安抚客户”——动作没错,依据错位。
真正的依据体系,必须回答:此刻是谁在用?在哪个流程步骤?要达成什么业务结果?哪些动作可自动,哪些必须人工确认?
三、依据不清的后果:不是“没效果”,是“有反效果”

我们总结过三类典型风险,都源于依据模糊:
· 客服场景:依据过期政策生成承诺→ 客户拿截图维权,企业被动赔偿;
· 合同场景:未识别“必须法务终审”规则 → 业务擅自采纳AI建议,导致条款漏洞;
· 经营分析场景:用暂估数据生成结论→ 管理层据此调整策略,实际执行时发现数据未确认。
这些不是AI能力问题。是依据的治理与业务脱节,甚至是缺乏治理。
企业愿意为“慢但稳”的智能体买单,但不会为“快但悬”的智能体担责。
四、第一个项目,别想建大平台,先打牢一个动作的依据

很多团队一上来就想搞“企业级知识中枢”。我们建议:先选一个高频、低风险、有明确输入输出的流程节点,把依据打透。
比如:
· 客服工单的“首次响应建议”环节:只管3件事——服务政策(最新版)、客户等级规则(CRM)、高频问题库(已审核);
· 合同发起的“材料完整性检查”环节:只核对——客户信息(CRM主数据)、项目编号(ERP)、金额阈值(财务确认口径);
· 经营月报的“异常指标初筛”环节:只用——确认收入(财务系统)、客户数(主数据)、目标达成率(已签OKR)。
小范围打透,比大而全却漏洞百出,更能让业务敢用、愿用、持续用。
五、自查清单:8个问题,5分钟过一遍你的依据层

如果你正在推进智能体项目,不妨用这8个问题快速诊断知识与数据层:
动作环节 | 依据问题 | 风险信号 |
1. 智能体参与的业务动作 | 该动作依赖哪些知识/数据/规则? | 说不清具体依据来源 |
2. 知识使用 | 哪些是正式口径?哪些是参考材料?版本是否最新? | 混用历史文档与现行制度 |
3. 数据调用 | 主数据源是哪个系统?指标口径是否业务确认? | 用周报数据替代系统确认数 |
4. 规则执行 | 业务规则(如升级阈值、审批路径)是否接入? | AI建议与实际流程冲突 |
5. 权限控制 | 不同角色看到的内容/数据是否有差异? | 普通员工可查敏感合同条款 |
6. 不确定性处理 | 依据不足时,AI是继续生成,还是提示人工? | 无“依据不足”兜底机制 |
7. 错误反馈 | 用户发现错误后,谁负责修正知识/数据? | 无闭环维护机制 |
8. 结果追溯 | 输出能否关联依据来源?是否留痕? | 无法复核AI建议的出处 |
答不出3条以上,建议暂停功能开发,先做业务知识梳理。技术可以迭代,知识依据错了,重做成本更高。
结语:智能体的可信度,藏在它“停手”的勇气里
最后说句实在话:企业不拒绝AI,但拒绝“依据模糊的AI动作”。
一个成熟的智能体,不该是永远往前冲的“永动机”。它应该知道——哪些动作有依据,就全力推进;哪些依据不清晰,就主动停手,把问题交还给人。
知识与数据层的价值,不是让智能体更“能干”,而是让它在业务流程里,动得清楚、停得坦然、结果可溯。
下来可做的1件小事:挑一个你正在推进的智能体流程节点,可以用上面8个问题过一遍。不用考虑大改系统,至少先理清“它这一步,核心的依据什么”。
这才是企业智能体,从Demo走向生产的真正起点。

本文为“企业AI智能体五层架构”系列第三篇。前两篇:《第一层:为什么必须先看业务场景》《第二层:任务切开后,还要放回流程里》如需PDF自查清单模板,欢迎留言“依据清单”,我发你一版可直接用的表格。
夜雨聆风