只用一个平台能交付哪些 AI 应用？Dify 单独落地的场景与边界

📖 摘要：不是每个 AI 项目都要接外部 Agent。大量真实交付里，Dify 一个平台就够——知识库问答直连、确定性工作流、平台内 Agent、标注与知识运营，四类场景可以完全在平台内交付。本文讲清纯 Dify（不接外部执行体）能交付什么、每类场景长什么样、做不了什么（碰真实系统、跨系统自主长任务、执行体侧技能沉淀三类边界），以及什么时候该在平台外加执行体。给「我们就用 Dify，能做到什么程度」一个基于实测的答案。适合用 Dify 做交付的团队、正在选平台的甲方技术负责人。

一、开场：被问住的问题

「我们就用 Dify，能做到什么程度？」

这半年来被问得越来越多。问的人有两类：一类是技术负责人——内部已经上了 Dify，想知道它到底能扛多少业务，还值不值得再投入；另一类是交付同行——客户说「平台我们有了，你们在这个平台上能给我们做什么」。

这问题以前不太好答。市面上讲 Dify 的内容，要么单点教程（某个节点怎么配、某个坑怎么排），要么反过来讲「Dify 不够，要接外部 Agent」——中间缺一张地图：纯 Dify 到底能交付哪些类型的应用？边界画在哪？

本文补上这张地图。所有结论来自实测——我们在 Dify 平台内交付过的工作流、知识库应用、Agent 应用、标注运营，门户里都有完整记录可查。先给结论：有四大类场景可以纯平台内交付，完全不需要外部执行体；同时有三条明确的边界，跨过去才需要接外部 Agent。

二、能力版图：平台内能扛的四类场景

把纯 Dify 交付过的应用按「解决什么问题」归类，是四类：

四类的共同点：都在平台内闭环——用户从平台页面/嵌入/API 进来，流程在平台内跑完，输出在平台内交付。不需要平台外有一个「会拆任务、会操作服务器」的执行体。

下面逐个展开，每类讲清：长什么样、适合谁、实测口径。

三、能交付什么：四类场景逐个讲

① 知识库问答：平台内最成熟的一类

把手册、规范、FAQ 变成可检索可回答的知识库，用户在 Dify 应用页面（或嵌入到自己的网页/聊天窗口）直接问，平台内完成检索、重排、组织答案、带出处返回。这是纯 Dify 交付最多的一类，也是「知识放哪」问题在平台内的标准答案。

平台内知识库问答能做的深度，超出很多人预期：多库分册 + 按问题类型路由、混合检索 + rerank、分数阈值（低于阈值宁缺毋滥，避免拿无关段落硬答）、分段模式选择（通用/父子/Q&A 各有适用）、元数据过滤（检索前先按元数据砍掉无关范围——实测把检索噪声从 75 降到 0）。这些不是概念，都是我们在平台内实测并写下完整记录的。

回答质量的上限，七成在知识库建设（清洗、分段、入库、调优），平台内都有对应设施；还有一成靠标注运营——见第④类。

适合谁：知识资产要多人高频查询、答案必须带出处的场景——设备手册、产品 FAQ、制度规范、故障知识库。平台内直接交付，不需要额外组件。

一个正在运行的例子：我们自己的门户问答（访客在 fishsun.cn 网页上直接问「你们能做什么、怎么做」），就是纯平台内知识库问答——没有外部执行体参与：访客从网页进来，检索答案，页面返回带出处的回答。当初选型时明确比较过「平台内答」和「把执行体侧能力搬上云端答」两条路，结论是展示面要稳定、可验收、可运营，平台内最合适——完整决策记录在门户机器人选型文章里。这个例子说明：平台内知识库问答不是「将就」，是很多场景下的主动选择。

② 确定性工作流：输入乱、流程定的活

这一类是纯 Dify 交付的另一个大头：输入五花八门、处理流程固定、输出要结构化——典型的「LLM 做理解、流程做规矩」的应用。

实测做过的：供应商报价单格式五花八门（几十家供应商各一套表头），让 AI 识别「哪列是单价」再统一抽取——平台内工作流解决；意图分类节点从 33% 失败率到兜底不崩（平台内加确定性兜底）；定时触发工作流到点自动跑（定时节点 + 后续处理）；文档/数据清洗流水线（批量处理、格式统一）。

这一类有个特点：流程是确定性骨架，LLM 只在关键节点做理解——输入解析、分类、改写、抽取。骨架越确定，交付越稳。平台的工作流可视化在这里是真优势：业务方看得懂流程、改得动分支，交付后维护成本低。

举个交付画面：供应商报价单解析——几十家供应商的报价表各有一套表头（有的叫「单价」有的叫「价格」有的拆成「含税/不含税」），人工录入一天。平台内工作流的做法：上传 → 解析节点把表格转成统一结构 → LLM 按语义识别「哪列是单价」（不是靠表头关键词硬匹配，是靠列内容语义判断）→ 校验抽取结果 → 输出标准表。流程节点全部可视化，供应商新来一家格式不一样，改的是解析节点里的规则，业务方看得懂改得动。

适合谁：内部数据处理自动化、表单类应用、需要「流程可见可改」的场景——小到周报整理，大到多步骤业务流水线。

③ 平台内 Agent：1.17 起能打的一类

Dify 1.17 起，平台内的 Agent 能力（Agent 节点 + 技能包）从「Beta 玩具」变成了能交付的形态：Agent 节点可以自主调用平台内注册的工具、检索知识库、按需规划执行步骤——闭环在平台内完成。

实测口径（Dify 1.17 升级实测系列完整记录）：Agent 节点能稳定调用工具集完成多步骤任务；循环内人工审批节点支持人在环上的确认；图片直传、技能包（预置技能）都跑通了。适合「要一点自主性、但工具都在平台内」的场景——比如「根据库存和订单生成补货建议并走审批」。

一个能说明「平台内 Agent 到哪一步」的例子：让 Agent 节点自己规划「先查知识库里的处理规范 → 再调工具取订单数据 → 生成补货建议 → 送人工审批」——四步任务它能自己串起来，中间工具调用失败会自己重试换路，不用人工编排每一步。这在 1.16 及以前做不到（那时要人把每一步画成节点），1.17 的 Agent 节点把「小范围自主」从框架层面变成了可交付能力。注意「小范围」三个字：它的工具集边界在平台内注册过的那些——平台外的世界，还是边界二那条线。

要诚实说边界：平台内 Agent 的自主性上限是平台内注册的工具集——它能调的工具，得先在平台里定义好。跨出平台、去操作系统/外部服务，是第 ② 类和第 ③ 类共享的一条界（见第四节）。

④ 标注与知识运营：质量是养出来的

容易被忽略但决定长期质量的一类。知识库/客服应用上线只是开始，回答质量要靠运营持续养：标注回复闭环（人工纠正过的答案让 AI 记住——下次同类问题直接给正确答法）、元数据打标体系、命中测试（固定问题集回归，更新后检索没跑偏）、知识版本更新流程。

这类「活」纯平台内就能干——标注、元数据、知识管理都是平台内设施，不依赖外部执行体。上线三个月后的质量，取决于这套运营机制有没有跑起来，而不是当初的搭建水平。

四、做不了什么：三条边界，划清楚

平台内能扛的说完，说边界——这些场景纯 Dify 交付不了，或者硬做的代价远高于接外部执行体。三条，都是实测确认的：

边界一：碰真实系统的活。 知识库能答「这个告警怎么处理」，但「登上去查这台服务器现在的状态」「执行发布前巡检并回写结果」——要 AI 接触真实系统、真的执行命令，平台内的 AI 默认不接触真实系统，需要外部执行通道。这条边界的对照实验证据（同款模型有通道 vs 无通道的差异），在《给 AI 接上一双真干活的手》里有完整记录——本文不展开。

边界二：跨系统、要自主拆解的长期任务。 平台内流程是确定性的：节点定好、分支画好，LLM 在节点里做理解。如果任务是「自己判断要查哪些系统、按什么顺序、中间结果异常自己决定重试还是换路」——这种需要执行体侧自主拆解与临场决策的活，确定性流程框不住，那是独立执行体的领域。

边界三：执行体侧技能沉淀的活。 一类反复出现、需要「越干越熟练」的活（值守规则、巡检套路、专属处理技能），技能沉淀在执行体侧、一次交付下次复用——这属于执行体自己的资产，平台内没有对应的「技能资产」机制。

三条边界的共同判断标准一句话：需求里有没有「平台外的世界」——要碰平台外的系统、要在平台外自主行动、要在平台外积累手艺——有，就该考虑接外部执行体；没有，平台内交付就够了。

再直说硬在平台内做这三类需求的代价——都是见过翻车的形态：

第一种，拿知识库当执行器用。用户问「现在哪台设备快满了」，知识库只能答手册里写了什么——硬答的结果就是编，模型没通道时自己都承认「如果生成报告，数值都是编的」。需求是实时状态，形态是知识问答——位置错了，上线那天就会被问倒。

第二种，用几十个节点模拟自主。任务路径每次都不同（「根据现场情况决定先查什么」），确定性流程框不住——画五十个分支模拟自主性，改一次现场情况改一次流程，改到崩溃。自主任务的正确形态是执行体临场决策，不是流程图穷举。

第三种，把执行体侧的手艺硬塞平台。一类反复出现的活要靠技能沉淀越干越熟练——平台内没有对应的技能资产机制，硬做的结果是每次从零、交付一次贵一次。

三种翻车的共同点：把「平台外的需求」硬塞进「平台内的形态」。位置放错的代价，比选错工具大得多——这也是为什么判断路径要先问「需求在不在平台外」。

五、判断路径：什么时候平台内直接做，什么时候加执行体

给一张实用的判断路径——不用纠结，按场景对号入座：

一个常见的演进路径：平台内起步 → 验证价值 → 需要碰外部世界时再接执行体。先别一上来就架构大铺开——用平台内应用把场景价值验证了（快、便宜、流程可见），确认值得投入，再决定要不要给平台接上执行通道。反过来，如果需求一开始就明确要碰真实系统，那就直接走「编排 + 执行体」的形态，不要在平台内硬凹。

这条路径我们走过不止一次，说一个真实的：先在一个客户场景里用平台内工作流把「告警分类 + 知识库处理建议」跑通了（纯平台内，一周上线）——业务验证价值成立后，客户才提出「能不能直接让 AI 把处理建议执行了」——这时才加执行通道，平台内已有的分类工作流原样保留，新增的「执行」需求走执行服务，两端各干各的。平台内先行验证、执行体后置接入，比一开始就搭大架构稳妥得多——花小钱验证，值得了再投。

平台内应用和执行体不是竞争关系，是互补的两档。我们自己的门户就是双标准的例子：访客在网页上问问题（展示面），用的是平台内知识库问答——要稳定、可验收、答案带出处，平台内最合适；而团队内部盯服务器、跑巡检这类要真动手的活，走的是执行体路径（《给 AI 接上一双真干活的手》）。同一个团队，对外展示用平台内，对内干活用执行体——两套标准并存，各用各的强项。这也是门户机器人当初选型时的完整决策记录（为什么用平台答、不把执行体侧技能搬上云）。

六、补上「落地版图」缺的一格

最后把位置摆清楚：本文和已有的《AI 落地三形态》体系是什么关系？

那套体系讲了三条「执行体参与的路径」——轻量独立（执行体单独）、知识问答（执行体 + 平台知识库）、编排真执行（平台编排 + 执行体执行）。本文补的是第四种组合：平台单独——执行体不参与、纯平台内交付。两个维度一摆，完整版图就出来了：

平台单独这一格，是很多人 AI 落地的第一站——也是被「三形态叙事」漏掉的一站。补齐之后，选型的完整逻辑是：先问需求在不在平台外（要不要碰真实系统/要不要平台外自主/要不要平台外沉淀手艺）——不在，平台内交付；在，再按执行体的参与方式从三条路径里选。

四个格不是竞品，是从轻到重的位置：平台单独（流程确定、成本最低）→ 轻量独立（单点自主）→ 知识问答/编排真执行（平台与执行体各司其职）。客户从哪格起步都行，关键是别把需求放错格——放错格的代价，比选错工具大得多。这张版图的每一格我们都实测跑过、都写了完整记录——对号入座之后，再决定要不要跨格。

常见问题

纯 Dify 和「低代码平台」有什么区别？

Dify 本身也是低代码平台——可视化画布、拖拽配置，和通用低代码平台一样主打「少写代码」。真正的区别在品类：通用低代码平台（表单+流程+数据表那类）编排的是确定性的业务数据流，输入输出可预期、可复现；Dify 编排的是概率性的模型输出——同样的问题，LLM 每次回答不保证一致。所以 Dify 的治理设施是通用低代码没有的：检索怎么接、提示怎么管、输出怎么约束、质量怎么运营——通用低代码根本不处理「输出不稳定」这个问题。纯 Dify 交付的价值不在「少写代码」（这一点所有低代码平台都卖），而在「把概率性输出工程化」：工作流骨架、契约输出、兜底设计、标注闭环——平台内都有对应设施，这是 LLM 品类区别于通用业务低代码的护城河。

平台内知识库能装多大的知识量？

实测口径：数百份文档、数千页手册、多库分册检索，平台内扛得住（我们做过 4277 页手册的完整入库实战）。真正的瓶颈不是「装得下装不下」，是知识库运营——清洗质量、分段策略、命中测试有没有跟上。知识量再大，决定质量的是运营机制而不是存储容量。

什么时候必须接外部执行体？

三条边界对应三个信号：需求要 AI 碰真实系统（服务器/服务/外部 API 的真实操作）；要跨多个系统的自主长任务（自己拆解、临场决策）；要在执行体侧沉淀可复用的手艺。三个信号有一个「是」，就该考虑平台外接执行体——平台内硬凹的代价远高于加一层执行通道。

平台内 Agent 和外部执行体，都叫 Agent，区别在哪？

平台内 Agent 的自主性边界是「平台内注册的工具集」——它能调的工具先在平台里定义好，闭环在平台内。外部执行体是平台外的独立执行者——自带终端/文件/网络通道，能操作平台外的真实世界，平台通过执行服务向它投递任务、收回结果。一句话：平台内 Agent 管平台里的活，外部执行体管平台外的活。

先上平台内应用，以后再接执行体，迁移成本高吗？

路径比想象顺。平台内起步验证价值后接执行体，通常是「加一层」而不是「推翻」：平台内已有的知识库、工作流继续用，新增的「要碰外部世界」的需求走执行服务通道，两端各干各的强项。真正要提前想清楚的不是现在用不用执行体，是需求未来会不会长出「平台外」的部分——会，架构上给执行通道留好位置。

相关文章：不搭平台也能交付 AI：轻量独立形态（值守/文档/内部工具）（轻量独立形态）｜知识放哪、执行放哪、流程放哪：AI 落地三形态选型总览（三形态选型）

本文基于 Dify 1.17.0 社区版实测。平台内四类场景的完整单点记录见博客既有系列：知识库问答（知识库分段/元数据过滤实战）、确定性工作流（报价单解析/意图分类/定时触发实战）、平台内 Agent（Dify 1.17 升级实测）、门户机器人选型（我们的门户机器人——为什么用平台答）。执行体路径见《给 AI 接上一双真干活的手》（编排真执行）与《AI 落地三形态》系列。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。