Agent做完了，员工又回去翻文档了

过去一年，我在企业现场看到的大部分AI项目，都会遇到同一类问题：

PoC搭得很顺利，给领导演示时，对方也觉得挺有价值的。但系统一交到业务手里，就没人用了。

有的人嫌结果不准，有的人觉得限制太多，结果就是试过几次，又回去翻文档、找同事，或者用别的AI工具去了。

看起来原因五花八门，但背后暴露出来的，是任何企业AI落地都会遇到的，三类共性问题。

前几天，我在HICOOL 2026全球创业者峰会做了一场分享。站上台，我先问了现场两个问题。

有多少企业已经做过Agent、知识库，或者其他AI应用？

这些已经做出来的应用里，又有多少变成员工每天工作的一部分？

我想问的，其实是这两个问题之间的距离。

01

一个能问答的Agent，业务说用不了

这次大会上，我分享了3个自己实际参与过的真实案例。第一个案例，来自一家大型企业的综合材料部门。

这个部门过去积累了不少领导的历史讲话、专题报告和调研材料，希望做一个知识查询和智能写作助手。

最开始，我们觉得需求很简单：用户提问➡️知识库检索➡️AI生成答案，再加一个编辑器，让用户能基于检索结果继续写材料。

系统做出来以后，能查资料、回答问题，也能给出来源。从功能上看，没什么特别明显的毛病。

但业务负责人用过以后，给了我们一句很直接的评价。

"这东西，我们用不了。"

我当时还挺懵的，直到把业务人员问过的问题一条条翻出来看，才发现之前想的太简单了。

实际上，他们在写一份新材料之前，要先找一找过去领导有没有讲过类似的问题、核对哪次讲话属于正式口径，再比较不同年份的表达有没有变化，还要看看以前有没有成熟材料可以复用。资料找完后还要重新组织语言，最后才轮到写。

他们实际完成的，是一条更长的工作链：

找 核 比 用 写

找资料→核口径→比变化→用成稿→写新材料

我们做出来的产品，承接了问答，却漏掉了前后那条完整的工作链。

Demo能跑，和业务能用，中间隔着一整条工作链。

这次反馈，改变了我看需求访谈的方式。业务人员说的"做一个知识查询助手"，其实离产品定义还差很远。他描述的，往往是此刻想到的功能。FDE还要继续去挖掘他完成这项工作需要经历哪些步骤，他如何做判断的，再去看AI适合承接哪个环节。

一句需求可以听懂，一项工作则要延展去深究。

我把这类问题叫作任务断点。

后面的圆桌里我也谈到，企业AI从0到1，经常先卡在人身上。业务同事没太多时间陪项目组整理资料、修改文档、反复测试。因此需要FDE判断哪些节点一定要让业务参与，找到能判断结果的人，把他们有限的时间用在关键事项上。

这个环节没做好，你的需求，最后一定会和真实工作错开。

02

十几万份文档，离可用上下文有多远

第二个案例，是服务一家头部在线旅游企业。

对方告诉我，他们过去积累了十几万份内部文档，包括：项目复盘、最佳实践、经验总结等等。团队考虑把这些资料塞进一个大知识库，通过问答把过去的组织经验利用起来。

技术上看这需求不复杂，但当我们继续聊到该怎么用这些资料时，会发现他们的问题，根本不是查某篇复盘写了什么。

他们更关心的是：哪些项目以前遇到过类似的问题？哪些方法在相似场景下取得了好结果？公司里又有哪些人做过这类项目？

这里要找的是人、项目、方法、场景和结果之间的关系。

我们可以让AI去读十几万份文档，但AI却不会自动把里面的关系整理出来。

即使文档已经被切片、向量化，AI在执行某个具体任务时，也未必能拿到当时所需的信息。

我把这类问题叫作上下文断点。

知识库当然重要——我自己做得最多的也是企业知识库项目。但到了企业真实场景里，得先判断当前任务依赖什么。有些问题适合从文档中检索，有些需要结构化数据，有些则要补充元数据和明确的分类体系，还有一些要把对象之间的关系建出来，再考虑知识图谱或Ontology。

这些技术路线没有固定的先后顺序。取决于你准备让AI完成哪项任务，以及完成任务时到底要让它看到什么。

FDE最重要的能力，是判断一个场景应该先治理文档、整理数据、建立关系，还是先收窄范围，拿一批真实问题去验证。

03

Agent上线了，谁保证它明天还能用

第三个场景来自一家大型工程技术企业。

这个项目要处理几百份流程制度和标准规范文档，其中混杂了大量扫描版PDF、复杂表格和PPT。刚开始，我们花了大量精力在解析、切片、参数配置和检索测试这些技术问题上。

但项目越往下走，越发现更麻烦的问题在后面。我们要反复和客户去确认：

新知识来了，谁负责入库？

旧制度作废了，谁负责下线？

解析质量谁检查？业务答案谁确认？

AI答错以后，谁记录问题、推动修改，再验证它是否变好了？

这些问题没回答，系统即使上线了，也很难长期稳定地用下去。

所以在这个项目里，我把更多时间，花在了写知识管理员手册、文档解析与切片指南，整理入库台账和评测表上，又专门组织了几场知识管理员的培训赋能会。

这次经验让我意识到，想让知识库项目稳定运行，至少要三张表：

第一张 · 记录资料能不能入库

第二张 · 写上线前的评测问题

第三张 · 跟踪上线后的使用反馈

这三张表，决定了新知识怎么进来，错误怎么被发现，反馈交给谁，修完以后又由谁确认。

系统能跑，只证明技术链路可行。它能不能长期用，还取决于有没有人把责任链和反馈回路打通。

我把这类问题叫作运营断点。

企业AI项目落地要解决的，一定会从模型问题，演变成工程问题，再往后走向组织和管理问题。

04

三个断点背后，都绕不开业务人员

HICOOL圆桌上，主持人问我们：企业AI从0到1最难解决的问题是什么。

我的回答是——先解决人的问题。

任务断点需要实际做这项工作的人帮助还原流程。上下文断点需要业务专家判断哪些资料有效、哪些口径权威、哪些关系值得建立。而面对运营断点，知识更新、答案确认和失败复盘都要落到明确的责任人身上。

真实项目里，业务人员往往最忙，没法长期陪着技术团队试错。因此需要FDE提前把协作方式设计好。疑难问题找专家，IT卡点可以先推进，没收到正式材料前可以考虑让AI设计虚拟样本做测试，合理安排好项目组自测和找业务人员复测的时间。

业务专家的时间，应该花在那些只有他能判断的地方。

如果始终没有业务人员参与，AI很容易在错误的任务和材料上越做越远。而参与环节过多，项目又会被高昂的协作成本拖住。

企业需要一套能持续运行的协作方式。FDE要把这套方式搭出来。

05

从一个Agent，走向企业AI生产系统

把这三个断点抽象一层向上看，我在HICOOL展示了一张图，给它起了个名字：企业AI生产系统

第一步，定义任务。把一项业务拆成AI能够承接的任务。

第二步，定义上下文。把完成任务需要的知识、数据和规则，整理成正确的上下文。

第三步，选模型、调参数、加工具、配数据，完成Agent开发。

第四步，建测试集，展开评测，并针对badcase进行优化。

第五步，把AI接回原来的业务流程，明确责任人和反馈机制，持续产生可确认的业务结果。

这套系统里，Agent是最显眼的一环，人们很容易先看到它。但前面的任务定义一旦出现偏差，或者后面的评测、运营没接上，Agent做得再漂亮，也就只是个Demo。

FDE贯穿其中，主要工作是完成三次翻译。

第一次翻译 ·把业务语言翻译成任务：明确AI应承接员工哪一部分工作。

第二次翻译 ·把企业的文档、数据和经验翻译成上下文：让AI在执行当前任务时看到正确的信息。

第三次翻译 ·把AI能力翻译成运营机制：明确谁负责、怎么评、如何收集失败案例，又怎样持续迭代。

企业要的，是一段可被AI稳定承接的业务。

06

三个问题，查查你的项目卡在哪

如果你的企业已经做了Agent、知识库或数字员工，却一直进不了真实业务，我建议先检查下面三个问题。

Q1：有没有搞清楚AI要承接哪一段工作？

→ 没有答案，项目卡在任务断点

Q2：AI执行这段工作时，能否拿到正确的知识、数据和规则？

→ 没有答案，项目卡在上下文断点

Q3：谁来判断它做得好不好，并持续让它变得更好？

→ 没有答案，项目卡在运营断点

任何一个问题一直没答案，项目就可能卡在对应的断点上。

企业AI的交付单位，应该是一段可执行、可评价、可持续的任务，它要能产生可确认的结果。这也是我在HICOOL 2026现场最想留下的判断。

我把这次分享的PPT做了脱敏，也分享给大家，在公众号后台发送关键词：HICOOL，即可领取。

如果你的AI项目落地也卡在这些问题上，可以找我做一次三断点诊断。我会为你把任务、上下文和运营机制逐项拆开，判断当前该补什么、先验证什么，以及下一步该如何推进。

我是申悦，企业AI顾问，解决方案型FDE。提供企业AI培训、AI落地方案咨询、AI智能体设计和运营陪跑服务。服务过东风集团、海亮集团等世界500强企业。如果你的公司正在AI转型、知识库建设和智能体落地，点击文末左下“阅读原文”查看合作方式，加V详聊：s2dongman