知识放哪、执行放哪、流程放哪：AI 落地三形态选型总览

📖 摘要：做 AI 应用交付这半年，最常被客户问的不是「用哪个模型」，而是「这套东西怎么落地」。本文把 AI 项目拆成三个位置——知识放哪、执行放哪、流程放哪——三个位置的不同组合，就是三种真实跑过的落地形态：纯 AI 执行体独立交付、AI 执行体调度 Dify 知识问答应用、Dify 确定性编排加执行体真执行。三种形态不是谁替代谁，是从轻到重的拼图。文章逐一展开每种形态的适用场景、实测证据与真实边界，最后给一条可照抄的选型判断路径。AI 应用交付从业者、正在选型的甲方技术负责人适用。

一、先立认知：AI 项目选型，选的是三个位置

先讲一个反复出现的场面。客户带着需求来，聊到一半通常会问一句：「你们是用哪个 AI 方案做的？是那种……很厉害的 agent 吗？」

问得多了我们发现，客户真正想知道的不是工具名，而是三件事：

第一，知识放哪。 客户有一批真金白银积累的文档——设备手册、故障记录、业务流程、历史方案。这些资料放在哪里让 AI 读取？是塞给 AI 让它自己翻，还是放进一套能管理、能检索、能调优的知识库？

第二，执行放哪。 客户要的是「AI 说」还是「AI 做」？说，就是回答问题、给建议、出方案；做，就是真的去操作服务器、跑脚本、改配置、盯系统。这决定了要不要给 AI 接上「手」。

第三，流程放哪。 业务的规矩——审批、分支、异常处理、谁批准谁执行——是用确定性的流程画出来（每一步都是固定的、可预期的），还是把裁量权全部交给 AI 现场发挥？

这三个位置看起来抽象，但它们的答案直接决定了项目的形态、周期和成本。我们把这半年做过的 AI 应用交付项目摊开看，绝大多数落进三种形态：

这三句话先立住，下面每一节都会把它们拆开讲透。写这篇文章的原因也很直接：三种形态我们都在真实场景里跑通过，各自的甜区、边界和坑都是踩出来的——与其让读者拿着「哪个 AI 方案好」的错误问题去搜索，不如把「你的需求属于哪个位置」的正确问题摆出来。

二、同题三跑：运维收到一条告警之后

为了不抽象，用我们最熟的场景——IT 运维——把三种形态摆在一起。一个运维团队收到了告警：「某车间网络设备接口异常」。同一个团队，同一天，三种不同诉求，三种形态各接哪一棒。

诉求一：「这种告警以前怎么处理？手册上怎么说？」——形态二（知识问答链）

团队把几百页设备手册做进了知识库，值班的同事在聊天工具里直接问：

员工：「OSPF 邻居反复震荡，可能是什么原因？」

聊天工具里的机器人（形态二）给出的是带出处、带风险提示的五段式回答：

【结论】OSPF 邻居震荡常见于接口参数不匹配或链路质量问题，需按链路逐段排查。 【置信度】中 【依据】《网络设备配置指导》第 6 章：[1] 两端接口 MTU 不一致 [2] 光模块收发功率异常 [3] 报文认证配置错误 【修复建议】1. 核对两端 MTU 与封装参数…… 2. 检查光功率是否在阈值内…… 3. 核对认证配置…… 【风险提示】修改接口参数会造成短暂业务中断，建议在维护窗口执行。 【图】OSPF 故障诊断流程图

这条链路在生产环境跑着：同事问一句，答案带着手册页码和示意图回来——翻几百页 PDF 的动作变成了聊天里的一句话。

诉求二：「告警别等我们发现，AI 能不能盯着，有问题主动说？」——形态一（轻量独立）

值班人的精力是有限的，凌晨三点的告警不可能每次都第一时间看到。形态一就是一个独立的 AI 执行体在跑值守：定时盯告警源和指标、对照预设规则、异常了往聊天工具推消息、附上初步判断的上下文：

[值守监控] 09:14 WAN1 接口流量突增，超出基线 3.2 倍 关联信息：昨日同时间段无异常；设备近 1 小时无重启记录 初步判断：疑似批量下载或异常外联，建议先看会话列表再查链路——完整排查清单见附件

它不需要知识库、不需要流程引擎——一个执行体加一份规则，就是全部交付。

诉求三：「别只告诉我怎么做，审批过了直接帮我做。」——形态三（编排真执行）

发布前巡检要真登服务器敲命令的场景。形态三里，Dify 跑确定性流程，执行体真在目标服务器上干活：

运维在表单提交「发布前巡检」工单（工单号、服务器角色、紧急度）→ 审批通过 → AI 执行体在目标服务器真实运行巡检脚本（内存/磁盘/服务状态/版本号）→ 约 10 秒 → 巡检报告经独立收口流程整理后送达审批人 → 审批人看到的是能与真实系统逐项对账的数据

同一个团队、同一批文档和服务器，三种诉求落在三种形态上，各干各擅长的一棒。这就是本文想立的第一个判断：选型的第一步不是比较工具的强弱，而是认清自己的诉求属于哪一类——是要一个会答话的知识库，还是要一个会盯梢的值班员，还是要一双审批之后真动手的手。

下面三节，三种形态逐一展开：它是什么、能干什么、不能干什么、交付要花多少代价——全部用我们实测跑过的场景说话。

三、形态一：AI 执行体独立交付（轻量独立）

业务故事：深夜的告警，第二天才被发现

先讲一个真实的痛点画面。某团队的网络设备夜里出了状况，告警在凌晨两点发出，值班的人设了静默，第二天早上九点才发现——业务已经受了影响，但谁也说不上来故障是几点开始的、中间发生了什么。事后他们想：要是有一个「不用睡觉的值班员」盯着就好了。

这就是形态一的典型起点。没有知识库要建、没有流程要画——要的是一个能自主干活的 AI 执行体，替人盯住某件事。

形态是什么

一个能自主执行任务的 AI 执行体，直接交付使用。它自带技能（怎么拆任务、调什么工具、按什么规矩输出），知识与经验随执行体沉淀。交付物往往很简单：执行体 + 一份规则/技能配置 + 验收。不需要额外部署 Dify 这类平台。

认知主体就是执行体自己——它决定怎么拆、怎么干、什么时候汇报。客户得到的不是一套系统，而是一个「会干活的 AI」。

交付物长什么样（真实样例）

值守场景的交付物是规则清单 + 推送格式约定。比如盯告警，规则要回答：盯哪些源、什么算异常（阈值/基线）、异常了推给谁、消息里带什么上下文。上面第二节的「值守监控」消息就是真实格式——人早上看到一条消息，就知道昨夜发生了什么、初步判断是什么、下一步查什么。

文档处理场景的交付物更简单：把一批格式杂乱的文档丢给它，约定输出格式（结构化表格、指定字段），它跑完交活。

典型场景（实测过的四类）

1. 值守监控：盯告警源、网页、文档变化，按规则比对，异常推送——交付体 + 规则清单
2. 文档与数据处理：清洗、转换、提取、生成结构化产物——单次或周期任务
3. 内部工具/技能型交付：一类活沉淀成一个技能助手（巡检检查、报告整理、物料生成）
4. 轻量小单：预算与需求都在轻量档，不搭平台直接交付，周期最短

成本与交付复杂度

三者中最低。交付清单 = 执行体 + 技能/规则 + 验收，无需平台部署与运维。客户侧准备一台能跑执行体的机器即可（或走远程部署标准流程）。演示级交付一到两天是常态。

适用与不适合（实测边界）

适合：

• 单点任务、值守类、内部工具——不需要平台重资产
• 知识量小、靠执行体自身技能和经验够用
• 客户要的是「能干活的 AI」而不是「一套系统」

不适合：

• 知识要规模化管理的场景——几百页文档变成几万页、要版本管理、要检索调优时，执行体自带的记忆和技能扛不住，知识会「乱」
• 业务流程要业务方自己可视化修改——纯执行体给不了「流程图」，业务规则变了只能找交付方改
• 多人在线、要门户/工单体系的服务——那是平台层的活

真实坑：误报与边界

形态一看着轻，坑在「规则怎么定才不吵人」。值守场景第一次上线时，阈值定松了漏报（异常没推）、定紧了误报（一天推几十条，人直接免疫）。最后是靠「基线 + 倍数」而不是固定阈值，加上推送消息里带「初步判断」，人收到消息先有上下文再决定看不看——误报率从「吵到想关掉」调到「每天几条可读的消息」。

文档处理也有边界：格式千奇百怪的输入（扫描件、老表格、嵌套表格）不是 AI 一次就能啃干净的——实测经验是「先清洗再处理」，预处理环节省不得，这部分我们沉淀成了专门的清洗方法论。

代表实盘

值守类交付已经在跑（规则清单 + 推送格式那套）；文档处理与技能型交付是轻量单的主力形态——详见同主题的实操系列文章（AI 值守系列）。

四、形态二：AI 执行体 + Dify 知识问答（知识问答链）

业务故事：值班的不翻手册了

再讲一个画面：企业的网络设备手册有几百页，故障处理的知识散在七八个分册里。以前值班的同事处理告警，靠的是「记得手册在哪一章」和「问老师傅」。老师傅会退休，手册会更新——知识没有变成可检索的资产。

后来团队把手册做成了知识库，在聊天工具里接了一个机器人。现在的画面是：值班的同事遇到告警，在聊天工具里问一句，机器人给出带手册页码、带示意图、带风险提示的回答。老师傅的经验还在，但「查手册」这一步被机器人替掉了。

形态是什么

执行体做入口与调度，Dify 承载知识库与问答应用。执行体接住聊天工具里的消息，识别意图后调用 Dify 应用；Dify 应用在知识库里检索、组织答案、按契约格式输出；执行体把成品答案带回聊天工具。

认知主体在 Dify 应用——检索逻辑、回答约束、输出格式全部固化在应用里，可调试、可调优、可验收。执行体是调度员，不抢戏。

为什么知识要放 Dify，不放执行体自己带

这是形态二最关键的设计决策，我们做过实测定论（18 条固定用例双跑对比）：知识问答场景下，知识放 Dify 应用（形态二）明显优于让执行体直连检索库。

• 输出契约稳定：应用里锁死了五段式格式（结论/置信度/依据/修复建议/风险提示），读者收到的答案永远长一个样，可预期、可验收；执行体自由组织时，格式会漂移——同一批问题今天带出处明天不带
• 图回传可靠：手册里的流程图、组网图能跟着答案回来（【图】清单机制），这是把「图文并茂的手册」变成「图文并茂的答案」的关键；执行体自由发挥时，图时有时无
• 回答聚焦：应用内约束「只依据检索片段回答、覆盖不到就明说」，不会东拉西扯；没有约束时，检索命中段的无关内容会被夹带进答案

另一个原因更实在：知识管理是重资产——文档清洗、分段策略、混合检索、rerank 调优、命中测试、版本更新，这套设施在 Dify 里是成熟的；放执行体侧等于自造轮子，还要自己维护。知识问答的交付质量，七成在知识库建设，这事应该交给专门的设施。

链路解剖：一句话的问题怎么变成五段式答案

端到端链路是这样走的（省略号处是我们调过的关键取舍）：

聊天工具提问

   → 执行体路由（识别意图：这是知识问答，不是闲聊）

   → 调用 Dify 问答应用

   → 应用内：改写查询 → 多库检索（混合检索）→ rerank 重排

   → LLM 按五段式契约组织答案（只依据片段，带来源标注）

   → 图清单回传（命中段落里的流程图/组网图）

   → 执行体带回聊天工具

这条链路里每一个环节都踩过坑、做过取舍，举两个最有代表性的（详见后文「真实坑」）：查询改写会「改写丢关键词」导致检索跑偏，要靠规则闸门兜底；检索配置会在版本迁移时悄悄丢失，导致「突然没图了」——这些坑不排掉，链路在 demo 时好看、上线三个月后变味。

典型场景与适用边界

适合：

• 手册/文档问答：设备手册、产品文档、制度文件——「问知识、要出处」
• 故障处理支持：值班现场查手册变聊天问
• 方案咨询/客户服务：任何知识密集、答案要有依据的咨询链

不适合：

• 要 AI 真操作系统的诉求——形态二只回答不执行，真动手要形态三接上
• 知识很少、问几句就完的轻诉求——为两个问题建一个知识库不划算（形态一更省）

交付与运维成本

知识库建设是主要工作量：清洗（格式千奇百怪的原始文档）、分段（粒度决定检索质量）、入库、检索调优（rerank/阈值/多库策略）。我们做过三百多份文档、三个知识库的实战——清洗与建库的工时远超应用编排本身。上线后还有检索质量运维：命中测试、库级配置核对、知识更新。

真实坑（去内部化表述，都是排过的）

1. 「突然没图了」的假故障：某次排查发现应用「图回传失效」，翻遍代码没找到问题，最后是知识库的检索配置在迁移中悄悄丢了——库级配置回退成默认参数，检索命中的段落恰好都不含图。教训：遇到「应用突然无图/检索变差」，先查库级检索配置是否还在，别先怀疑应用逻辑。
2. LLM 偶发空输出：模型偶尔把答案全写进思考过程、正文返回空——节点状态显示成功，实际输出是空的。靠「确定性兜底文案」节点兜住：正文过短就走固定文案，绝不把空回答给用户。
3. 查询改写丢关键词：改写模型把「OSPF 典型配置举例，请带上组网图」改成「OSPF典型配置组网图」——「举例」被吞，检索跑偏。解法是规则闸门：改写后若丢了原文里的关键词，回退用原文检索。

这些坑的共性是：AI 链路里的单点不稳定源（改写模型、检索配置、LLM 输出），都要有确定性闸门兜底——这是形态二从「demo 好看」到「生产可靠」的分水岭。

代表实盘

企业网络设备知识助手（生产运行）：几百页手册进知识库、聊天工具入口、五段式带图回答——就是本文第二节「诉求一」那条链路。

五、形态三：Dify 编排 + 执行体真执行（编排真执行）

业务故事：发布前巡检，为什么要人登服务器

回到文章开头的运维团队。版本发布前有一道绕不开的工序：确认目标服务器健康——资源够不够、关键服务还活着、版本号对不对。这道工序过去长这样：提交发布申请 → 审批通过 → 工程师登服务器 → 敲一串命令看内存、看磁盘、看服务、看版本 → 把结果贴回工单 → 审批人点头 → 发布。

命令不难——free -m、df -h 谁都会敲。难的是每次都要人：发版窗口要有人守着；巡检结果贴在工单里，没人复核它是不是刚从服务器上拷下来的。更关键的是：AI 早就被问过「你能不能帮我巡检」，而当时的 AI 只能回答——它没有通向服务器的通道。

形态三要解决的就是这最后一公里：AI 不仅能说，审批之后真的能干。

形态是什么

Dify 跑确定性业务流程（表单、审批、分支、收口），执行体在真实系统上执行任务。这是「做」的链——不是「说」的链。

认知主体分两层：Dify 管「要不要做、做完怎么办」——确定性、可预期、业务方可视化；执行体管「怎么做」——自主拆解、调用工具、处理异常。

为什么执行要外置，不让流程里的 AI 长手

严格讲，Dify 不是不能给流程里的 AI 配执行工具——自研插件能把命令通道做成工具塞进平台，这条路我们验证过可行。但实测后我们选择把执行外置给独立执行体，三个理由：

1. 安全边界：执行体的权限、审批、审计独立管理，不混进编排平台——「谁能执行什么」有独立的控制面
2. 复用：一个执行体可以同时服务多个 Dify 流程，不用每个流程各自接一套工具
3. 自主性：巡检这类任务不是一问一答——要看中间结果、判断异常、决定下一步。独立执行体天生干这个；平台内工具节点做的是单次调用

于是中间出现了一个轻量的「执行服务」——它承接 Dify 的确定性指令、转给执行体自主执行、再把结果送回确定性流程。五个职责：投递接收（秒回任务 ID，流程不阻塞）、任务状态机、结果回写、失败兜底、安全闸门。

敢不敢交付的分水岭：兜底与闸门

形态三和其他形态最不一样的地方，是它必须回答两个问题：执行体出错了怎么办？它会不会乱操作？

失败兜底，我们实测过三类故障注入：执行体服务停摆、执行中的任务被中断、任务超时。修好之前，裸行为是：Dify 表单显示「已提交」，实际上任务永远悬空——失败信号根本回不到流程。修好之后是「双态回写」：任何失败都回调流程（带失败原因），流程的收口分支区分成功/失败，失败出口直接生成人工兜底指引（任务 ID、失败原因、处置选项）。三类故障注入全部验证走通。

这里还要补一个后来才发现的失败类型（2026-09 实测）：执行完成不等于任务成功——执行体遇到错误（比如脚本不存在）时常以「如实汇报错误」完成（不编造是本分），任务的 run 状态是「完成」，但目标其实没达成。这类失败光靠状态回写拦不住——必须由收口流程做「结果语义体检」：在结果文本里识别失败信号（文件不存在/命令未找到/退出码非零/报错等），命中就输出「任务执行异常」报告而不是「任务完成」——否则客户会收到一份标题写着成功、内容全是报错的报告。所以失败兜底是两层：执行挂掉（状态层兜底）+ 执行完但结果不对（结果层质检）。

安全闸门，管的是「高危动作」：删除文件、清库、重启服务这类破坏性操作。实测发现执行体自己的原生审批在无人值守链路上并不拦（官方行为待核），所以闸门放在执行服务层：内置高危模式库，高危任务默认拒绝，要放行必须由流程显式授权（人工审批环节置位）。这里如实说一个边界：关键词模式会误伤正常业务描述（任务里提到「覆盖」配置可能被拦），所以生产形态改成了任务包显式声明高危动作 + 审批授权——机器判断粗筛、人工授权终审。

实测链路数据

以发布前巡检为演示场景的端到端实测（数据可与真实系统逐项对账）：

适用与不适合

适合：

• 审批 + 真实系统操作的流程：发布前巡检、变更检查、状态收集
• 长耗时/深度任务：分钟级执行不影响用户（异步投递）
• 要可追溯自主执行的企业：任务 ID 贯穿、失败有兜底、高危被拦

不适合：

• 纯知识问答（形态二主场）
• 不碰系统的轻诉求（形态一更省）
• 危险命令的原生防护目前不兜底——安全必须靠执行服务层的闸门，这是硬要求不是可选

真实坑（挑读者会遇到的三个）

1. 任务包里的 JSON 死在半路：Dify 把任务描述传给执行体时，变量值含引号的 JSON 会被模板截断——执行体收到残缺任务包。解法是请求体裸引用变量、任务包原文直发
2. 失败信号传不回来：见上文「兜底」——不做双态回写，失败就是悬空任务，用户永远等不到结果
3. 高危误伤与漏拦：关键词模式不是万能的——过宽误伤正常业务，过窄漏掉变体写法；所以生产形态用显式高危声明而非纯关键词

代表实盘与指路

形态三的完整端到端实证（链路图、模块设计、故障注入验收、对照组差异）见已发布的《给 AI 接上一双真干活的手》——本文第五节是它的压缩版，细节在那里。

2026-09 起，形态三从「一条链路」深化为一套执行体系（本系列的后续主线）：

• 断点式编排：发起流程投递完即办结（Dify 的 run 是一次性的）、执行完成后由独立的收口流程承接整理——两个流程靠任务 ID 关联，结果从这里回到 Dify 正式体系（可审计、可接业务下游）
• 独立安全闸门：高危默认拒绝、显式授权才放行——咽喉放在平台外（执行服务层），不混进编排平台，安全边界才清晰
• 执行服务（调度中枢）：收单（秒回任务 ID）/ 盯进度（状态机）/ 派活 / 双态回写 / 兜底与放行——约 160 行的小服务，不执行业务动作，但承担全部调度职责——它是这套架构里「平台结构上给不了」的那层（跨流程生命周期的状态持有 + 独立咽喉位置）
• 失败两分：见上文——执行挂掉（状态层兜底）+ 执行完结果不对（结果层质检）

体系论证与组件拆解见《敢让 AI 碰真实系统——执行体系的三根柱子》和《AI 执行服务怎么搭：任务调度中枢拆解》（本系列后续文章/完整版见文末博客）。

六、对比总表

把三种形态摊在一张表里看（全部维度来自上文实测）：

「主要坑」一行看不懂？ 一句话解释：JSON 截断 = Dify 节点把任务包传给执行体时内容被引号截断（定位后改为裸传 JSON 原文）；失败悬空 = 执行体失败信号回不到 Dify，任务永远挂着（解法是双态回写，失败也回调）；高危漏拦 = Agent 原生审批不拦无人值守链路的危险命令（解法是执行服务层高危模式拦截 + 显式授权）；检索配置丢失 = 知识库迁移后检索参数悄悄回退默认，表现为「突然没图/答不准」；空输出 = LLM 偶发把答案写进思考过程、正文返回空（加固定兜底文案）；改写跑偏 = 查询改写环节丢关键词导致检索不到；规则误报 = 值守阈值定松漏报、定紧吵人（换基线+倍数判断）；文档格式 = 乱格式文档直接处理输出也乱（先清洗再处理）。每个坑的现象→根因→修法在对应形态小节里有完整闭环。

关于「认知主体」这一行，值得多说两句——它决定系统的行为特征。 认知主体是谁，谁就对「输出长什么样、出错了听谁的、能不能被业务方直接改」负责：形态一认知在执行体，输出风格灵活、改起来找交付方；形态二认知固化在应用里，输出契约稳定、可验收、检索调优有专门设施；形态三认知分两层——Dify 管流程确定性（业务方可视化修改），执行体管执行自主性（任务内自主决策）。选型时问一句「这个系统的认知该固化在哪一层」，往往比纠结工具更早得到答案——三种形态不是技术路线的差别，是认知放哪儿的差别。

七、选型判断路径：三个问题，一张图

选型不需要纠结，按顺序回答三个问题：

三个问题各自的判断要点：

问题一「要不要接触真实系统」怎么问出来：问客户两个递进的问题——「这个 AI 是回答问题就行，还是要它真的去操作服务器/系统？」「如果它操作了，结果需要有人审批吗？」客户说要真操作且要审批（有流程/留痕/多人协作需求），直接落形态三；说只要真操作、单点任务不用审批（比如定期跑一次巡检、执行一个固定脚本），落形态一——执行体配好执行授权直接干，不需要 Dify 流程壳；说只要回答，进问题二。

问题二「知识算不算大规模」怎么判断：不是看文档页数，看三个信号——① 文档要不要版本管理（手册会更新）② 答案要不要带出处（员工要依据）③ 多人高频问同一批资料。三个信号中两个为「是」，就值得上知识库（形态二）；只是零星问几句，形态一自带的知识够用。

补一档常被漏掉的选择：三个问题都「否」或平台内就能闭环的，走平台单独格。 知识问答这条路上，入口决定要不要执行体：用户从聊天工具进来、要多入口调度——配执行体入口（形态二）；用户直接开页面/嵌入网页问——平台内知识库直连就够，不需要外部执行体。同理，不碰真实系统、知识不大、但流程要可视化、要业务方自己改的——平台内工作流比执行体合适。这档叫「平台内应用」：知识库问答直连、确定性工作流、平台内 Agent，纯平台闭环交付（完整版图与边界见《只用一个平台能交付哪些 AI 应用？》）。三形态是执行体参与的路径，这档是执行体不参与的路径——选型先问需求在不在平台外，再决定要不要执行体。

没提模型选型？ 三形态的差别在执行通道与知识设施，不在模型——同一条链路换不同模型，形态结论不变。实际交付中模型选择（成本与稳定性权衡）是另一个维度，有独立的实测方法论，不在本文展开。

再给一张「客户原话信号」对照表——谈需求时听到这些话，直接对号入座：

八、组合与真实案例：三形态不是单选题

最容易误解的一点：三形态不是互斥选项，同一个客户可以同时用两三种。

真实案例：我们自己的门户机器人就是现成的例子。网站访客问「你们能做什么、怎么收费」这类问题，用的是 Dify 应用答——知识放在库里、答案带出处、展示面要的是确定性和一致性；而盯网站状态、巡检这类要真动手的活，交给独立的 AI 执行体干。同一个团队，两套选型标准，一句话概括：展示面要确定性（Dify 答），执行面要自主性（执行体干）——这不是偷懒，是每种活都要用最合适的形态。

更完整的组合模式是「问走二、做走三、轻走一」：

• 知识问答链（形态二）跑客户日常的「问」——手册、制度、FAQ，答案有出处
• 编排真执行（形态三）接「要动手」的流程——审批后的巡检、变更、状态收集
• 轻量独立（形态一）处理零散自动化——值守盯梢、文档处理，不惊动平台

客户从轻到重的成长路径也顺理成章：先用形态一跑通一个点（比如先把告警盯起来）→ 知识积累多了升级形态二（手册进知识库，问答机器人上线）→ 业务要真操作了再加形态三（审批流接执行体）。每一步都在前一步的资产上长，不用推倒重来——三种形态共享同一个 AI 执行体底座，差异只在「知识库和流程有没有放 Dify」。

九、边界诚实声明：每形态还没做实的部分

写到这里，把三种形态各自还没做实的部分也如实交代——不摆全知全能的姿态：

• 形态一：值守和文档处理是跑熟的，但「执行体单机」的可靠性运维（机器挂了怎么办、规则怎么版本管理）还在沉淀——目前按交付运维的方式人工兜
• 形态二：知识库的持续运营是大头投入——文档更新要重新清洗入库、检索质量要定期命中测试，这套「知识库运维」机制还在完善（企业知识助手的知识迭代流程仍在打磨）
• 形态三：目前是实验验证形态 + 演示资产，生产化还有三件事：执行服务任务台账落盘（现在是内存态，重启丢记录）、高危授权从关键词改成任务包显式声明（防误伤）、执行服务加鉴权与多租户隔离——这三件做完才从「能演示」变「能交付」

另外两点通用边界：三种形态的模型 key 都由使用方自备（我们不代采模型）；本文所有结论基于 Dify 1.17.0 社区版 + Hermes Agent v0.21.0 实测，版本演进后参数与行为可能有变化。

三篇形态文章与本文的关系，一句话收尾：先有会答话的知识库（形态二）、会盯梢的值班员（形态一）、审批后真动手的手（形态三），才有这篇选型问答——形态选对了，AI 项目的坑少一半。

常见问题

三种形态能混用吗？会不会维护不过来？

能混用，而且是推荐做法：同一个客户「问」的诉求走知识问答链、「做」的诉求走编排真执行、零散自动化走轻量独立。维护成本按形态递增——形态一一个执行体即可；形态二多了知识库运维（文档更新/检索调优）；形态三多了流程与执行服务。交付时的默认建议：先按主诉求定一个形态跑起来，验证价值后再加第二形态，不要一上来就上全套。

形态一和形态二有什么区别？不都是 AI 在干活吗？

区别在知识管理。形态一的执行体可以带技能和经验干活，但企业级知识（手册会更新、答案要带出处、检索要调优）需要 Dify 那套知识库设施——分段、索引、混合检索、rerank、命中测试。我们做过 18 条用例双跑实测：知识问答场景下，应用承载的输出契约（五段式带置信度/依据/风险）比执行体自由组织稳定得多。一句话：知识少靠执行体自带，知识多上知识库。

形态三安全吗？AI 真操作服务器，出问题怎么办？

三层防护：高危任务默认拒绝（删除/格式化/清库等破坏性动作需流程显式授权）、执行全程任务 ID 可追溯（工单到执行全链可查）、失败必回写（三类故障注入实测——执行体停摆/中断/超时都会回到流程出人工兜底指引，不会无声悬空）。「能真干活」和「敢不敢让它干活」是两件事——后者靠闸门、审计、兜底这套机制解决，这正是形态三交付验收的重点。

三种形态各要花多少钱、多长时间？

按交付复杂度递增：形态一最轻（执行体 + 技能 + 验收，演示级一到两天）；形态二中等（知识库建设是主要工作量，取决于文档量与清洗调优）；形态三最重（流程 + 执行服务 + 正常路径/故障注入/闸门三面验收）。生产化（台账落盘/鉴权/多租户）另计。模型 key 由使用方自备。

选错了形态能迁移吗？

能，迁移成本可控——三种形态共享同一个 AI 执行体底座，差异只在知识库和流程放没放 Dify。最常见的迁移是从形态一升形态二（知识多了要管理）：执行体侧的入口逻辑不变，新增 Dify 知识库与应用，把问答路由过去即可；形态一升形态三同理加流程层。反过来砍层也简单。建议先按本文判断路径选，跑起来用真实使用量验证，再决定要不要加层。

本文基于 Dify 1.17.0 社区版 + Hermes Agent v0.21.0 实测。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。