本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。
这两年我接触过不少企业 AI 项目。大家最先想到的，通常都是搭一个知识库机器人：上传几份文档，让员工或者客户直接提问。
这种应用做起来不难，演示效果也很直观，但真正上线后经常会卡在同一个地方
它能告诉你“故障报修需要提供地址和电话”，却不能接着把地址和电话收集完整；
它能解释某个套餐，却不会根据用户的实际需求做比较，更不会继续生成一张可以交给后续人员处理的工单。
企业愿意长期使用的，不只是一个会回答问题的聊天框，而是一个能理解任务、查找知识、补齐信息，最后把事情往前推进的数字员工。
所以这次我没有再做一个普通的 RAG Demo，而是用腾讯云 ADP 4.0 搭了一个运营商客服数字员工。当然，套餐、地址、电话和工单全部使用虚构演示数据，不代表任何真实运营商，也没有连接真实 CRM。
我想验证的事情其实很具体：
- 能不能直接用自然语言把应用搭起来；
- 它能不能从回答套餐问题，继续推进到故障报修；
- 应用发布以后，企业还能不能看到它的调用和运行情况。
先把需求像交代给同事一样说清楚
过去搭客服应用，我会先画流程，再逐个配置节点。这次我换了一种方式：直接在 ADP 智能工作台里描述业务需求。
首先前往官方首页，我选择的是国际站。
ADP 4.0 给新用户提供 1 个月免费套餐，包含 10,000 credits + 1GB 知识库容量——够你搭 2-3 个 Demo 拿去给客户演示。想复现的兄弟也可以使用体验链接：https://adp.tencentcloud.com/?utm_source=bozhou&utm_medium=X&utm_campaign=4.0
注册后进智能工作台，用 adp-engineer skill 输入需求。
我告诉它，这个客服需要识别套餐查询、故障报修、服务反馈、宽带安装、转人工和其他咨询六类意图。其中套餐查询要使用企业知识库，故障报修则要通过多轮对话，依次确认故障类型、地点和联系电话。
接下来，智能工作台调用 adp-app-manager，完成应用创建、系统提示词、欢迎语、开场问题和知识问答工具的配置，最后把已经完成的内容和仍需处理的事项一起列了出来。
这里我没有选择生成一条固定工作流，而是选择使用 Claw 模式。两种模式没有谁一定更好，只是适合的任务不同：固定工作流适合步骤非常明确的流程，而 Claw 更像是给 Agent 一个目标，让它结合当前对话判断接下来该查知识、追问信息，还是调用工具。
客服对话本身就不太规整。有人一上来只说“没信号”，有人会在第一句话里把地点和联系电话全部说完。相比要求所有用户按照表单顺序输入，Claw 模式反而更适合这次测试。
进入应用配置页后，模型、提示词、Skills 和知识问答工具都集中在同一个页面里。我保留了六类客服规则，并挂载了 KnowledgeRetrievalAnswer，负责后面的套餐查询。
应用框架有了，但这时还不能说明它真的能用。客服回答是否可靠，首先取决于它能不能找到正确的企业知识。
RAG 仍然重要，只是它不再是整篇文章的主角
Claw 可以自主推进任务，但“自主”不等于可以让模型自由发挥。通用大模型知道公开世界，却不知道一家企业此刻正在执行的套餐、制度和服务规则，而且这些内容随时可能更新。如果客服直接凭模型记忆回答，很容易把旧政策、其他公司的规则，或者一个听起来合理的数字混进结果。
RAG 做的事情，是先从企业自己的知识中找依据，再让模型基于这些依据回答。对客服来说，能否说清楚答案来自哪份文档，以及资料里没有答案时能否停下来，往往比语气是否流畅更重要。没有这层知识约束，Agent 后面的动作越自动，出错时造成的影响反而越大。
不过，普通 RAG 和 Agentic RAG 处理问题的方式并不完全一样。像“89 元套餐包含什么”这种事实题，检索一次通常就够了；但如果用户问“每月用 120GB 流量、不需要宽带，哪款套餐更划算”，Agent 就要先拆出流量、通话、宽带和价格等条件，再寻找候选套餐、比较成本，并检查结论是否真的满足需求。ADP 4.0 提供极速、规划、规划＋反思三阶 Agentic RAG。我这次没有继续展开切块、BM25 和重排序这些底层细节，而是准备了一道简单题和一道复杂题，直接看最终效果。
当然，检索能力再强，也救不了一份混乱的知识库。企业文档如果版本不统一、缺少章节，或者关键经验根本没有沉淀下来，Agent 只能基于残缺信息工作。这个 Demo 使用了一份按个人套餐、家庭套餐、5G 套餐和变更规则分章的虚构说明文档，既方便检索，也方便在回答中标注来源。
先从最简单的问题开始：
89 元的星海畅享套餐包含多少流量、通话时间和短信？请注明信息来自哪个文档和章节。
应用回答了 40GB 国内流量、500 分钟国内通话和 200 条短信，同时标出了演示文档和对应章节。数据和原文一致，来源也能追溯。
接着我把问题换得更接近真实咨询：
我每月大约使用 120GB 流量，通话不超过 300 分钟，不需要家庭宽带。哪款套餐更合适？
这次它没有只返回一段相似内容，而是列出了两个可行方案。129 元套餐本身只有 80GB，需要额外购买 40GB 流量包，算下来大约 189 元；199 元的 5G 套餐自带 150GB，可以直接覆盖需求。综合比较后，它推荐了后者，并把计算过程和知识来源一起给了出来。
我还故意问了一个资料中不存在的问题：199 元套餐在日本使用时，海外漫游费是多少。应用没有顺着问题编一个价格，而是明确告诉我，当前演示文档没有相关信息。
到这一步，RAG 部分已经完成了它的任务：让 Agent 知道应该依据什么回答，也知道什么时候不该回答。但它目前仍然只是一个比较可靠的知识助手。要证明“数字员工”成立，还要看它能不能把对话继续推进下去。
回答完问题之后，它能不能接着办事
我重新开了一轮对话，只说了一句：
我家里没信号，帮我报修。
应用先从这句话里识别出故障类型是“无信号”，然后询问故障地点。拿到地点以后，它没有再重复前面的问题，而是继续询问联系电话。
为了看看它会不会只顾着把流程往下跑，我先输入了一个明显错误的号码 138123。应用停了下来，指出号码格式不正确，并要求重新输入 11 位手机号码。这时它没有生成工单
换成演示号码 13800001234 后，它才返回一张结构化 Demo 工单，其中包含工单编号、故障类型、地点、脱敏后的电话、提交时间和“已受理”状态。
这段对话看起来不复杂，却刚好体现了知识库机器人和数字员工的区别。
前者告诉你“报修需要地址和电话”，回答到这里就结束了；后者会记住你已经说过什么，判断还缺什么，发现参数不对时停下来，信息完整后再给出一个可以继续处理的结果。
不过，这里必须把能力边界说清楚：本次生成的是结构化 Demo 工单，没有写入任何真实运营商或 CRM 系统。它证明的是 Agent 已经可以把自然语言整理成业务结果，而不是证明我已经打通了运营商后台。
如果真的进入生产环境，下一步还要通过 Connector、MCP 或企业 API 连接工单系统，同时补上身份验证、权限控制和操作审计。这些工作不会因为 Agent 会对话就自动消失。
发布以后，管理工作才刚刚开始
在开发页面里跑通 Demo，只能说明功能基本成立。企业真正使用时，还要考虑如何发布，以及上线之后谁来观察它的运行情况。
完成测试后，我通过智能工作台提交了发布，平台返回应用发布成功。
随后我打开应用运营页面，筛选了当天产生的真实测试数据。看板显示，这个应用一共调用 9 次，成功率 100%；其中知识库调用 4 次，连接器与工具调用 4 次，“总 tokens 平均耗时”为 10.67 秒。
9 次调用当然不能说明它已经达到生产级稳定性，但这个页面至少回答了一个很实际的问题：应用发布之后，管理员仍然能看到调用次数、成功率、组件使用和性能趋势。
企业里同时跑几十个 Agent 时，最怕的不是某一次回答不够漂亮，而是不知道哪些应用在被使用、哪些工具经常失败、延迟到底出在哪里。Agent 要进企业，开发和发布只是前半程，后面的运营和治理同样重要。
这次素材里没有单独显示 Token 数量和成本金额，所以我不会把它写成“已经完成精确成本核算”。目前能确认的是，应用的真实调用与性能数据已经进入统一运营页面。
为什么这次我没有把 ADP 当成一个 RAG 工具
如果需求只是上传几份 PDF，再做一个简单问答机器人，市面上能完成这件事的工具很多，没必要仅仅因为功能列表更长就更换平台。
ADP 4.0 在这次实测里让我感受到的价值，是把原本分散的几件事接到了一起：先在智能工作台里用自然语言创建Agent，再挂载企业知识和工具；Claw 根据对话决定下一步动作；测试完成后继续发布，并在运营页面观察实际调用。
沿着这条链路回头看，RAG 只是数字员工的一部分。它负责回答“应该依据什么”，多轮上下文和工具负责解决“接下来做什么”，而发布、权限和运营能力决定这个 Agent 能不能真正进入企业。
这也是为什么我更愿意把 ADP 4.0 理解成一套 AgentOps 平台，而不是一个更复杂的知识库产品。当 Agent 需要查知识、接系统、完成长任务，并且还要被企业持续管理时，这种一体化才开始体现价值。
这次实测跑通了什么，又没跑通什么
这次跑通的是一条最小但完整的链路：
自然语言配置应用 → 查询企业知识 → 比较套餐 → 多轮收集报修信息 → 校验电话号码 → 生成 Demo 工单 → 发布应用 → 查看运营数据
它还不能直接等同于一套生产级客服系统。
首先，工单没有进入真实 CRM，目前只能证明 Agent 可以产出结构化结果。其次，我没有拿到完整的执行轨迹画面，因此不对具体代码节点或内部调用链作结论。最后，9 次测试全部成功只是一个小样本，看板里的平均耗时也还有继续优化的空间。
换句话说，我不会因为一次 Demo 跑通，就说 ADP 已经可以替代所有客服系统。但如果一家企业正准备从“会回答问题的机器人”继续往前走，希望 Agent 能理解任务、补齐信息、调用知识并产出结果，那么 ADP 4.0 已经提供了一条比较完整的落地路径。
客服、IT 服务、行政问答和销售支持这类高频场景，都适合先选一条任务做 PoC，再逐步接入真实系统。如果只是个人自动化或简单知识问答，选择更轻量的工具可能反而更直接。
演示视频如下
最后，别急着做一个“全能员工”
企业第一次尝试数字员工，最容易犯的错误是把目标定得太大。与其一开始就要求它处理所有问题，不如先挑一件输入和结果都清楚的工作。
准备一份脱敏后的企业知识，定义一个明确的输出，例如工单、报告或结构化记录，再用知识边界、缺失参数和错误参数去测试它。只有这条小链路稳定了，才值得继续连接真实系统，补上权限、安全和运营规则。
腾讯云 ADP 当前活动页面为新用户提供 1 个月免费体验，包含 10,000 credits 和 1GB 知识库容量，足够先搭一个小型 Demo。具体活动内容以页面实时信息为准。
体验入口：腾讯云 ADP 4.0
知识库回答得再漂亮，也只是第一步。真正值得验证的是：交给 Agent 的那件事，它最后有没有办完。
