今晚被同事的 AI 分享上了一课：先跑起来，比想得大更重要

今晚公司做了一场 AI 应用分享。

听完以后，我心里只有一个感觉：我好像没赶上趟。

不是因为同事讲了多复杂的模型，也不是因为他们用了什么我没听过的新技术。恰恰相反，他们做的事情很具体：在公司内网部署 Dify，接入内部工单系统、Confluence 空间和自建向量库，让 AI 先回答一部分重复咨询。

效果已经跑出来了。

需要人工介入的次数越来越少，处理过的问题又会沉淀回知识库，下一次回答得更准。它不只是一个聊天机器人，而是开始形成一个持续变好的业务闭环。

这件事真正刺激到我的地方是：一个月前，我也在构想类似的东西。

我的构想更大，也因此走得更慢

我当时想做的是一个面向企业项目实施和运维场景的 AI Agent。

用户不需要记命令，也不需要先判断该查哪个服务。只要用自然语言描述目标或故障现象，Agent 就能读取会话上下文，检索离线知识库，调用只读巡检工具，再根据真实集群证据给出判断。

我甚至已经做出了一个 MVP：

支持会话记忆；
支持离线知识库检索；
可以通过 SSH 检查集群资源、端口和日志；
可以让大模型基于证据进行诊断；
涉及重启、改配置、清数据等操作时，必须由人工确认。

方向并不差。

但我一开始想的就是“自然语言完成项目实施”，范围太大了。它会碰到权限、安全、网络、知识准确性、工具编排和操作回滚等一连串问题。

再加上现实环境并不方便：虚拟机资源不够，连接公司服务器还需要挂 VPN，Agent 很难稳定地待在目标环境里持续工作。

于是，这个构想一直没有真正进入日常使用。

我做了一个看起来更像 Agent 的东西，但同事做出了一个已经在解决问题的东西。

他们真正做对的是闭环

同事的方案并不神秘。

Dify 本身提供知识库、RAG 检索和 Agent 工具调用能力，也支持连接外部知识库。把内部文档、FAQ 和标准处理流程变成可检索的知识，再接入聊天应用，本来就是它最合适的场景之一。

但平台只是工具。

真正有价值的是他们选中了一个足够具体的问题：减少重复工单咨询。

这个场景有几个天然优势：

问题真实存在，而且每天都在发生；
工单和 Confluence 中已经积累了大量可用知识；
AI 回答不好时，可以立刻转人工；
人工处理结果又能继续补充知识库；
效果很容易衡量：人工介入次数有没有下降。

整个系统因此形成了一条清晰的路径：

用户提问 → 检索内部知识 → AI 回答 → 必要时人工介入 → 结果沉淀回知识库

每处理一次问题，系统就多一份可以复用的经验。

这比一开始就追求“全自动 Agent”更务实，也更容易产生价值。

我不是输在想法，而是输在切入点

回头看，我和同事想做的事情其实并不冲突。

他们从知识问答和工单分流开始，我想继续往集群诊断、工具调用和项目实施推进。前者更像入口，后者更像执行层。

真正的问题是，我试图直接从后半段开始。

我先考虑 Agent 能不能理解复杂目标、调用哪些工具、怎样控制高风险操作，却没有先回答一个更简单的问题：

它今天能替同事少处理哪一种重复工作？

如果最初只选择一个场景，比如：

根据历史工单回答常见安装问题；
根据错误日志推荐排查文档；
自动整理巡检结果并生成报告；
对无法回答的问题创建待补充知识条目；

那么这个 Agent 可能早就进入实际使用了。

AI 项目最危险的地方，不是技术做不出来，而是构想太完整，导致第一个可用版本永远没有出现。

知识库不是资料仓库，而是组织反馈回路

今晚分享里最让我羡慕的，不是他们把 Dify 搭起来了。

真正让我觉得“效果真好”的，是知识库在持续完善。

很多公司做知识库，最后只是把一堆文档搬到另一个地方。文档越来越多，但没人知道哪些内容有用、哪些内容过时，也不知道用户究竟在问什么。

而工单问答天然提供了反馈：

哪些问题被频繁提问；
哪些回答没有命中；
哪些场景必须转人工；
人工最后是怎样解决的。

这些数据会反过来告诉团队，知识库下一步应该补什么。

所以真正有效的 AI 知识库，不是一次性导入文档，而是把“回答失败”也变成知识生产过程。

接下来，我应该把 Agent 做小

今晚这场分享对我最大的提醒，不是赶紧再搭一套 Dify，也不是推翻原来的 AI-agent。

原来的技术方向仍然有价值：知识检索负责提供背景，工具负责采集真实证据，大模型负责归因和排序，高风险动作交给人工审批。

但接下来应该换一种推进方式：

先选一个高频、低风险、可衡量的场景；
先把知识检索和人工兜底跑通；
记录回答失败和人工处理结果；
再逐步加入只读巡检与工具调用；
最后才考虑自动执行项目操作。

不是先做一个“什么都能干”的 Agent，再去寻找它的用途。

而是先让它稳定地解决一个问题，再给它下一项能力。

今晚真正学到的一课

以前我容易把 AI 应用理解成模型能力和 Agent 架构。

今晚我更清楚地看到，企业里的 AI 应用首先是一个业务闭环：它从哪里获得知识，怎样进入现有流程，回答失败后谁来接手，人工经验又如何回到系统里。

想法大并不是坏事。

但在 AI 应用这件事上，先跑起来的窄场景，往往比停留在设计里的宏大 Agent 更有价值。

今晚被同事惊到之后，我不准备继续懊恼。

该做的是把原来的构想砍小，选一个真实问题，让它先开始工作。