Dify 与 Coze 工作流：低代码 Agent 的生产化面试指南
Dify、Coze 都能让团队很快做出“看起来已经可用”的 AI 应用。面试的分水岭不在会不会画流程，而在你能否讲清：平台替你解决了什么、没有替你解决什么，以及复杂业务为何要保留代码控制面。
一、先把平台定位说准确
Dify 是面向 LLM 应用构建的开源平台，文档把模型、提示编排、知识库、Agent 和低代码 Workflow 作为一体化能力；它特别适合企业内的应用验证、知识问答与业务团队参与维护。Coze 提供面向 Agent/应用构建与开放能力的产品化入口，适合快速组合模型、插件/工具、知识、工作流与发布渠道。两者共同点是“把若干 AI 原语可视化”，不是替代领域系统、权限系统和审计系统。
| 问题 | Dify / Coze 画布能加速 | 仍需要企业工程承担 |
|---|---|---|
| Prompt 与模型试验 | 节点配置、参数调整、可视化调试 | 版本、灰度、回归集、成本策略 |
| RAG 问答 | 知识接入、检索节点、引用生成 | 文档 ACL、数据分级、索引生命周期 |
| 工具调用 | HTTP/插件/工作流节点组合 | 身份、授权、幂等、审计、补偿 |
| 应用交付 | 预览、API、嵌入或渠道发布 | SLA、灾备、租户隔离、监控告警 |
| 业务流程 | 条件、循环、变量、人工协作 | 长事务、复杂状态机、强一致性 |
面试开场可以这样说：
我把 Dify/Coze 当作 AI 应用编排层和业务验证层。它们让 Prompt、知识库和轻量流程的迭代更快；但凡涉及身份、资金、订单、合同、权限或长期状态，我会经由后端 Tool Gateway 和代码化工作流执行，平台不能直接成为核心交易系统。
二、Dify 的面试回答要点
Chatflow、Workflow、知识库、工具如何分工
- Chatflow：适合多轮交互入口。关注会话、追问、流式体验与用户上下文，但不能把聊天记录误当作权威业务状态。
- Workflow：适合输入到输出的任务链，例如“上传合同 -> 提取字段 -> 检索模板 -> 草拟修改建议 -> 审批 -> 生成报告”。流程骨架应尽量确定，模型节点只处理不确定语义。
- Knowledge/RAG：解决“回答依据来自哪里”。企业生产必须将租户、部门、文档密级、有效期和删除状态带进检索过滤，而不是命中后再让模型不要泄露。
- Tool/插件/HTTP：把外部能力暴露给工作流。真正的工具执行要放到服务端网关，平台只拿最小权限的调用凭证和受控 schema。
Dify 画布的变量为什么经常出事故
画布变量很容易形成隐式耦合：上游 Prompt 改了字段名，下游条件分支默默拿到空值；模型偶尔输出数组、偶尔输出字符串，代码节点再临时修补；同一个变量同时表达“用户原文”“清洗结果”“最终业务 ID”。解决方法不是在每个节点加更多 Prompt，而是建立变量字典：
| 变量类别 | 例子 | 规则 |
|---|---|---|
| 原始输入 | raw_user_text | 不覆盖，保留溯源 |
| 结构化事实 | invoice.vendor_id | 经过 Schema 和业务校验 |
| 模型候选 | intent_candidate | 不能直接触发写操作 |
| 策略结果 | risk_level | 由规则/策略服务产出 |
| 副作用回执 | ticket_id | 必须含幂等键与外部版本 |
将变量、节点入出参和失败码形成“工作流接口文档”，再用典型输入跑回归。低代码项目也需要这种接口意识。
Dify 从 PoC 到生产的毕业路径
- 冻结验证资产：导出/记录画布版本、Prompt、知识切分与检索参数、工具定义、模型配置和高频用户问题。
- 采集真实 bad case：不是只留成功对话，还要收集越权请求、空检索、工具失败、长文档、模糊需求和人工纠正。
- 在平台外补控制面：统一身份、租户 ACL、模型网关、Tool Gateway、审计、评测、费用归因和告警。
- 拆出核心事务：把创建订单、合同提交、权限修改、支付等操作做成后端 API；低代码工作流只发起提案和读取结果。
- 按风险分层上线：先只读建议模式，再小流量半自动模式，最后在明确策略和审批下开放有限写操作。
这里的关键不是“迁走所有节点”。适合运营维护的知识问答、表单处理、内容草稿仍可留在 Dify；应该毕业的是状态复杂、风险高、需要严格测试和恢复的核心链路。
三、Coze 工作流的工程答法
Coze 的实战项目往往从“Bot + 工具 + 工作流”起步。回答时先讲清业务对象、工具契约和发布边界，再谈节点。可用下面这个抽象：
渠道/应用入口 -> 会话或任务上下文 -> Coze 工作流
|-> 语义分类/信息抽取
|-> 知识与只读工具
|-> 结构化提案
-> 企业 Tool Gateway -> 领域系统关键边界一：会话状态不等于业务事实
用户在对话里说“把上次报价再发一次”，会话记忆可帮助定位上下文，但最终动作必须到 CRM/报价服务重新查询客户、报价版本、发件权限和审批状态。模型记忆和平台变量只能提供线索，业务系统记录才是事实源。
关键边界二：插件/工具不应拥有过大权限
工具定义需要至少包含：用途、动作类型、输入 Schema、输出 Schema、数据范围、需要的授权、是否可重试、是否幂等、风险等级。将“搜索客户”和“修改客户等级”拆成两个工具；后者要求审批令牌。不要用一个万能 execute_sql 或 call_internal_api 给 Agent 自由发挥。
关键边界三：发布渠道不等于安全边界
无论应用被嵌到 Web、IM、客服入口还是 API，最终都应由企业后端鉴别真实用户、租户和会话。渠道传来的用户标识需要映射为内部 principal；工具调用只能使用这个 principal 派生的短期授权，不能使用平台管理员的永久密钥。
四、Dify 与 Coze 的选型面试题
Q：二者怎么选？
不要用“谁更强”回答。按以下五维给出约束：
| 维度 | 更应关注的问题 |
|---|---|
| 交付形态 | 内部应用、自部署、开放平台、渠道触达，哪个是首要目标？ |
| 数据边界 | 文档、日志、凭证是否需要留在受控网络？ |
| 业务可维护性 | 谁改 Prompt、谁维护知识、谁审核发布？ |
| 工程复杂度 | 是否有长任务、复杂状态、跨系统事务、严格 SLA？ |
| 退出成本 | 工作流、工具契约、评测资产能否迁移或复用？ |
好的回答是：“我们先按数据合规、渠道与团队角色筛选，再用同一组场景做 PoC；不把业务逻辑锁在某个平台私有变量中，领域动作统一走 Tool Gateway，因此可以保留迁移能力。”
Q：低代码平台里如何做版本管理？
至少有四种版本：应用/工作流定义、Prompt 模板、知识库索引、工具与模型配置。发布创建不可变 release_id，每次 run 记录它；生产编辑走草稿、评审、测试、灰度、回滚，而不是直接点保存。能够导出的工作流定义应进入 Git；不能完整导出的配置也要通过变更单、截图/快照和接口清单补齐证据。
Q：如何防止业务人员误改线上流程？
角色最小化：业务方可编辑草稿和知识内容，发布权限与凭证权限交给不同角色；环境隔离：开发/测试/生产使用不同模型 Key、知识库和第三方沙箱；发布门禁：结构检查、黄金集、权限测试、成本上限检查；关键写操作永远不因画布编辑而自动放开。
五、企业知识库工作流案例
场景
员工问“差旅标准是多少，能否报销机场停车费？”系统需要按所在公司、职级、出差城市、制度生效日期给出引用答案；若用户要提交报销单，只能创建草稿，最终提交走审批系统。
可靠流程
- SSO 网关把用户身份、部门、职级与数据域写入请求上下文。
- 工作流抽取问题中的地点、费用类别、日期；抽取结果必须通过枚举和日期校验。
- RAG 检索加入
tenant、policy_scope、effective_at过滤，返回文档片段、版本与页码。 - LLM 只基于检索证据生成回答；无证据时明确追问或拒答，不能补全政策。
- 若用户要求创建草稿，平台调用只读的“报价/政策校验”工具，得到结构化建议。
- 创建草稿由 Tool Gateway 调报销服务，带用户主体、审批前状态和幂等键；工作流只展示回执。
- 全链路记录命中文档、答案引用、模型版本、工具回执和用户反馈，进入评测集。
面试亮点
这不是“RAG + 一个 API”而已。你要明确指出：权限过滤发生在检索前，制度有效期是检索条件，写动作只能创建草稿，最终业务提交由审批系统把关，平台不持有报销系统的管理员凭证。
六、常见失败模式与修复
| 症状 | 根因 | 修复 |
|---|---|---|
| 改了 Prompt 后下游全乱 | 隐式变量与无 Schema 输出 | 定义变量契约、结构化输出、契约回归 |
| 同一请求重复建单 | 超时后整条流程重跑 | 外部动作使用幂等键并查询回执 |
| 用户看到了其他部门制度 | 先全库检索再靠 Prompt 保密 | ACL/元数据过滤前置到检索层 |
| 平台日志里有敏感数据 | 默认记录完整输入输出 | 脱敏、分级、加密、引用化存储 |
| 画布越来越难改 | 一个流程混合了业务规则、模型、写操作 | 模块化子流程，关键动作迁入领域服务 |
| 输出偶发不合法 | 只要求“请返回 JSON” | Schema/解析器/重试/人工兜底 |
七、项目讲法模板
我们先用 Dify/Coze 完成制度问答与工单草稿的 PoC，让业务团队能迭代 Prompt、知识与轻量路由。随后发现核心风险不是模型回答，而是多租户知识隔离、第三方凭证和重复建单。因此我们把 SSO、ACL 检索、工具鉴权、幂等、审批和审计下沉到后端网关；平台只拿到最小化的工具接口。每个发布版本与模型、Prompt、知识索引、工具 Schema 形成快照，用真实 bad case 做回归。这样既保留了低代码的迭代效率，也让关键业务动作满足可追溯和可恢复要求。
八、高频追问速答
Q：平台能否直接访问数据库？ 不建议。应经由只读查询服务或受控 Tool Gateway，服务端完成租户过滤、查询白名单、行数限制、审计和脱敏；写库必须更严格地经过领域 API 与审批。
Q：如何度量 Dify/Coze 项目价值？ 业务上看任务完成率、人工节省、响应时延和满意度；工程上看引用正确率、Schema 合法率、工具成功率、人工接管率、权限拒绝率、重复副作用为零与单位任务成本。
Q：是否应该把所有流程迁到 LangGraph？ 不应该。稳定轻量的运营流程留在低代码平台更高效；只有复杂状态、长任务、强测试/高风险交易、严格 SLO 的路径需要代码化运行时。选型按风险和维护成本，而非技术信仰。