Dify、Coze、n8n 与耐久 Agent 工作流：高频面试题库
这页面向 LLM 应用开发、Agent 工程、AI 平台、Java AI 工程和解决方案岗位。题目不考你能否背出节点名称，而是检验你是否能将大模型的不确定性嵌进可靠的业务流程。
一、30 秒总答法
当面试官问“你做过 AI 工作流吗”，不要从平台名称开始。先给出这个结构：
我先按任务是否可预先编排来决定 Workflow 还是 Agent。确定路径由状态机和规则控制，LLM 只做分类、抽取、检索归纳或受限规划；所有工具经过 Schema、权限、幂等和审计网关。低代码平台用于 PoC、业务配置和连接器编排，长任务/高风险动作放到代码化耐久工作流。运行时记录版本、证据、成本和审批，发布前用坏例回归，线上按任务成功率、人工接管、工具失败和副作用正确性观测。
这段回答同时覆盖选型、架构、治理与指标，远胜于“我会用 Dify 和 n8n”。
二、基础概念高频题
Q1：Workflow 与 Agent 的本质区别？
标准回答： Workflow 的控制路径由开发者预先定义，模型在固定节点完成受限任务；Agent 则让模型根据工具结果和环境反馈决定下一步。区别不是有没有 LLM，而是控制流的自主性。生产里二者常组合：Workflow 控主干、权限、预算和副作用，Agent 只处理开放式子任务。
追问：为什么“能用 Workflow 就别用 Agent”？ 固定流程更可测试、成本可预算、异常更易定位。Agent 的灵活性带来死循环、越权调用、上下文膨胀和行为不可预测。只有步骤无法预先确定时，才值得支付自治成本。
Q2：AI 工作流与传统 BPM/自动化有什么不同？
传统流程的每一步通常有确定输入输出；AI 工作流在部分节点引入概率性的语义理解和生成。因此它需要传统系统的幂等、重试、权限、审计，也需要 LLM 特有的 Prompt 版本、模型路由、结构化输出、RAG 证据、评测与成本控制。把其中任何一类忽略都会造成上线事故。
Q3：什么是工作流状态？为什么不能只保存聊天记录？
状态包含运行 ID、当前节点、业务对象版本、输入/输出引用、错误尝试、预算、审批、工具回执以及版本快照。聊天记录只是一种上下文，既可能不完整也不可信。恢复和审计必须依赖结构化状态与领域系统事实。
Q4：为什么要给模型输出做 Schema？
“请输出 JSON”只是提示，不是保证。Schema 将可接受的类型、枚举、字段、长度、嵌套和默认值明确化；解析失败可重试、修复、降级或转人工。更重要的是，Schema 后还需要业务校验，例如客户 ID 是否属于当前租户、金额是否在阈值内，不能因 JSON 合法就直接写库。
Q5：工作流中的 gate 是什么？
Gate 是程序化关口。输入 gate 验证身份、文件和参数；中间 gate 验证 Schema、引用、权限和风险；输出 gate 审核敏感内容和动作；执行 gate 检查审批、预算、幂等和策略。一个好的 AI 系统不是“Prompt 很厉害”，而是每个不确定输出后都有合适的 gate。
三、Dify / Coze 面试题
Q6：Dify 适合什么场景？不适合什么场景？
适合： 企业知识问答、客服 FAQ、运营内容生成、表单处理、轻量 RAG 与工具调用、业务团队共同维护的 PoC。 不宜直接承担： 资金、订单、权限变更等强合规写操作，复杂跨系统事务，严格低延迟/高并发核心链路，依赖复杂状态恢复的长期任务。
关键表述：Dify 不是“不能生产”，而是生产前必须补齐版本、权限、评测、观测、成本、灰度与迁移边界。
Q7：Dify 的 Chatflow 和 Workflow 怎么区分？
Chatflow 更接近多轮对话入口，关注上下文、追问和流式交互；Workflow 更接近任务编排，适合明确输入、多个处理节点和结构化输出。两者都可接模型、知识和工具。无论哪一种，真实业务状态仍在领域服务中，不能只靠会话变量保存。
Q8：如何把 Dify/Coze PoC 迁移为生产服务？
- 冻结并导出 Prompt、流程、工具定义、知识检索参数和模型配置。
- 从日志收集高频问题、失败输入、越权请求与人工修正，形成评测集。
- 将身份、ACL、工具执行、审计、计费和告警下沉到后端控制面。
- 把核心状态机、长任务、审批和写操作迁到 LangGraph、Spring AI 或自研服务。
- 低代码平台保留在业务配置、知识运营、非关键自动化和试验环境。
这叫“毕业路径”，不是简单重写。真正有价值的是沉淀下来的 Prompt、坏例、工具契约和业务规则。
Q9：Coze/Dify 的工具调用如何做安全治理？
工具须由服务端网关执行，而非把管理员 Key 放进平台变量。每个工具定义用途、输入/输出 Schema、只读或写入、权限范围、重试/幂等性和风险等级。用户主体从 SSO/渠道网关进入，网关按主体派生最小权限；高风险动作需审批令牌；日志记录工具版本、参数摘要、策略决定与回执。
Q10：低代码平台如何版本化？
版本对象至少包括工作流定义、Prompt、模型参数、知识索引、工具 Schema 和策略。发布生成不可变 release_id，每次运行存快照。编辑走草稿、评审、测试、灰度与回滚；可导出的定义进入 Git，无法导出的配置也要有快照、变更单和接口清单。特别要考虑“等待中的旧 run”：它不能在恢复时突然套用新逻辑。
Q11：业务人员改 Prompt 可能导致什么事故？
字段格式变化造成下游解析失败；检索约束变弱导致无证据回答；工具调用条件被误放宽；token 增加导致成本飙升；语言风格变化触发合规风险。治理不是禁止编辑，而是提供沙箱、角色分离、模板变量契约、自动回归、审批和灰度。
四、n8n 面试题
Q12：n8n 与 Dify、LangGraph 怎么选？
| 主要难题 | 优先考虑 |
|---|---|
| 业务系统事件、SaaS 连接器、通知、批处理 | n8n |
| Prompt、知识库、业务应用快速验证 | Dify / Coze |
| Agent 的显式状态、工具循环、人审、checkpoint | LangGraph |
| 长事务、定时、跨服务补偿与严格生命周期 | Temporal/耐久工作流 |
在真实项目里常常分层组合，而不是二选一。例如 n8n 收到 CRM 事件并调后端任务，LangGraph 完成研究/归纳，结果再由 n8n 回写通知；高风险动作始终走统一网关。
Q13：n8n 的 Webhook 如何防重放和伪造？
验证发送方签名和时间戳，拒绝过期请求；将 event ID 持久化做去重；限流和限制正文/附件大小；按来源建立密钥与权限；原始事件可靠落库或队列化，之后异步处理。不能只依赖一个难猜 URL。
Q14：n8n Queue mode 解决什么，不解决什么？
它将任务调度与执行扩展到 worker，提高吞吐与隔离能力。它不解决业务幂等、顺序、外部 API 恰好一次、凭证最小化、数据保留或下游限流。设计时还要检查 Redis/数据库高可用、worker 健康、执行保留、死信与对账。
Q15：同一自动化超时后重试，如何避免重复发邮件/建单？
对外动作携带稳定幂等键；超时恢复前用该键或业务对象查询外部系统是否已成功；将写入与纯计算分节点；成功回执持久化；无法确认时转人工而不是盲重试。邮件可使用草稿/出站记录，工单可使用来源事件 ID，订单可使用业务请求号。
Q16：n8n 中如何处理敏感凭证与数据？
凭证放平台凭证库/Secret Manager，工作流只引用；按环境、租户、服务和权限范围拆分；敏感输出在日志中脱敏；附件和执行正文设置保留期；高风险系统不直连，统一走 Tool Gateway。不要在 Code 节点打印 token 或完整客户数据。
Q17：如何给 n8n 的 AI 线索工作流做评测？
离线集覆盖正常线索、重复线索、缺字段、多语言、恶意注入和边界行业。指标包括字段抽取准确率、枚举合法率、分级混淆矩阵、重复识别率、人工修正率、工具成功率、写入幂等正确率、单 run 成本。上线后与销售采纳/转化等业务指标关联，不能只看模型分数。
五、LangGraph / Temporal / 耐久执行题
Q18：为什么 Agent 需要 checkpoint？
Agent 可能多轮调用工具、等待人审、遇到限流或进程重启。checkpoint 保存状态和进度，让运行可暂停、恢复、检查和回放。它也支持追踪“为什么这次任务走到此处”。但它不是业务事务，外部副作用还要幂等与回执。
Q19：LangGraph interrupt 有什么陷阱？
Interrupt 暂停后，恢复会从所在节点开头重新运行。因此 interrupt 前的写操作可能重复；应使其幂等，或更好地把写操作移到恢复后的独立节点。不要用宽泛 try/catch 吞掉 interrupt；多个 interrupt 的顺序要确定；传递 JSON 可序列化的小对象；恢复要用同一个 thread/run 身份。
Q20：什么状态应该放 checkpoint，什么不该放？
放控制状态、业务对象版本、证据/工具结果引用、预算、审批、错误和版本快照。大型文档、图片、完整原始 trace 放对象存储或日志系统，状态只存引用；密钥不放；无限聊天历史要摘要/分层。领域事实最终以业务服务为准。
Q21：LangGraph 和 Temporal 的边界？
LangGraph 适合显式 Agent 图、工具循环、上下文状态与人机协作；Temporal 更适合长事务、可靠计时、活动重试、跨服务协调与工作流版本演进。可组合：外层 Temporal 统一案件/订单生命周期，内层 LangGraph 生成研究或提案。必须避免两个系统同时对同一外部动作自动重试。
Q22：如何设计跨系统补偿？
先定义每步的业务效果、回执、幂等键与反向动作。例如冻结额度 -> 创建草稿 -> 审批 -> 扣款 -> 发通知，失败则释放额度/取消草稿。补偿也可能失败，应有状态、重试与人工队列。不要说“失败就数据库回滚”，第三方 API 并不在同一事务里。
Q23：长任务如何取消？
取消首先停止后续计划与新的工具调用，再查询正在执行的外部操作；必要时发撤销/补偿；状态标为 cancelling，完成确认后才是 cancelled。若外部动作不可撤销，任务应标为“取消请求已受理但存在已完成副作用”，通知人工处理，不能假装什么都没发生。
Q24：如何处理工作流版本升级？
每个 run 固定版本快照；新版本只接新 run；旧 run 由旧处理器完成或显式迁移；Tool Schema 保持兼容或加适配层；审批恢复前重新校验对象和策略版本。跨日任务最容易在这里出问题，不能把生产变更等同于新任务的发布。
六、模型、工具与权限题
Q25：Function Calling 后模型返回了合法参数，是否可以直接执行？
不可以。合法 Schema 只说明形状正确，不说明请求被授权、对象存在、金额合理或动作安全。执行器还要做身份、租户、资源、策略、速率、幂等、审批、数据分级与审计检查。
Q26：如何避免 Prompt Injection 让工作流越权？
把用户内容、检索文档、网页、工具返回都视为不可信数据，不让它们改变系统指令、工具策略或授权。模型能看到的工具是白名单；工具网关独立进行权限判断；输出必须经过 Schema 和 policy gate；高风险动作需要人工确认；保留来源与传播链方便审计。
Q27：Agent 可以访问生产数据库吗？
应通过面向任务的只读服务，不应给通用数据库管理员权限。查询服务做租户过滤、列/行白名单、参数化、数量上限、脱敏和审计。写入使用领域 API；即使是 SQL Agent，也只允许经过审批的只读查询模板，永远不要让模型拼接任意 DDL/DML。
Q28：如何做模型与成本路由？
先用规则按风险、时延、语言、长度、是否需要工具/RAG 分流；简单分类和抽取可用小模型，复杂推理才使用高能力模型；对每个 run 限 token、轮数、时间和工具次数；记录单节点成本；达到预算就缩短上下文、降级、异步或转人工。路由本身也要评测，不能只按价格选模型。
七、系统设计题一：企业采购审批 Copilot
题目
供应商提交报价和合同，系统抽取字段、对比历史价格、检索制度、给采购人员建议；金额超过阈值或涉及敏感条款时必须审批；不能泄露其他事业部数据，也不能重复创建采购单。
高分答案结构
- 入口与身份：上传入口接 SSO、租户、部门与文件病毒扫描；文件对象存储、元数据入库。
- 解析与抽取：OCR/解析节点生成结构化候选，Schema 与金额/币种/供应商 ID 业务校验；原件与抽取结果都可溯源。
- 检索与比价：RAG 和历史订单查询均携带事业部、密级、有效期过滤；模型只给证据归纳，不自行编造价格。
- 策略：规则引擎计算金额阈值、敏感条款、供应商风险；产生审批需求而非由模型决定是否放行。
- 提案与审批：生成采购单草稿、差异、证据；审批人确认特定对象版本，审批过期或对象变更须重审。
- 写入与恢复：Tool Gateway 调采购域 API，幂等键是申请单 + 版本 + 动作；超时先查回执；失败进补偿/人工队列。
- 观测与评测：记录抽取准确率、证据覆盖、审批拒绝原因、重复写入为零、端到端时延和成本。
加分追问：为什么不能让 Dify/Coze 直接调采购库？
因为平台变量与模型输出不是企业权限控制面。采购库写入必须基于 SSO 身份、部门/金额策略、对象版本、审计与幂等；这些应由领域 API/网关负责。低代码平台可以编排提案和体验，但不持有高权限数据库凭证。
八、系统设计题二：跨日 Deep Research 工作流
题目
用户发起行业研究，Agent 搜索公开资料、读取授权报告、调用行情数据并生成报告；过程中可等待分析师反馈，任务重启后要继续，报告只能发给有权限的人。
答案要点
- 外层耐久工作流创建案件、授权快照、预算和截止时间；内层 Agent 图处理动态检索与证据归纳。
- 每条证据记录来源、时间、许可域、哈希、摘要和引用位置；数据出境/外部模型调用前执行分级 gate。
- Agent 只能调用精细工具：公开搜索、授权文档检索、行情查询、报告草稿，不允许任意浏览器/数据库写入。
- 人工反馈以 interrupt/signal 形式进入，携带审批人和版本；恢复重新校验。
- 报告发布是单独幂等动作，依赖不可变报告版本与授权；通知失败可重试但不应重复发布。
- 评测覆盖事实引用、证据覆盖、无授权泄露、恢复成功、人工修改、时延与预算。
九、项目表达：三种岗位版本
LLM 应用开发岗
我负责把业务流程拆成确定节点和模型节点。确定部分用规则、Schema 与工具网关保证可控，模型只做抽取、检索归纳和草稿生成。我们维护坏例集，发布前比较结构合法率、引用正确率和任务成功率，线上通过 trace 看每个节点的 token、延迟、错误和人工接管。
Agent 工程岗
对动态任务我用显式状态图而不是无限 ReAct。State 保存事实、证据、预算、工具回执和审批；每个节点单一职责，关键写入有幂等键。人审通过 interrupt 暂停与恢复，长任务按 checkpoint 继续。我们区分模型重试、工具重试、工作流路由和业务补偿，避免重放造成外部副作用重复。
Java AI / 平台工程岗
平台层提供统一模型网关、Tool Gateway、鉴权、策略、审计、限流、成本归因和评测门禁；Dify/Coze/n8n 只是上层编排与运营入口。高风险领域动作由 Spring 服务处理，低代码画布不保存管理员密钥。这样既给业务快速试错，也保持核心系统的合规与可运维性。
十、面试反模式
| 低分说法 | 为什么不够 | 高分替换 |
|---|---|---|
| “模型会判断是否执行” | 把授权交给概率输出 | “模型产出候选，策略与网关授权执行” |
| “失败就重试” | 会重复副作用 | “按错误分类重试，写操作用幂等键和回执” |
| “上 checkpoint 就能恢复” | 忽略外部世界 | “checkpoint + 幂等 + 对账 + 补偿” |
| “低代码方便，直接上线” | 缺版本/权限/评测 | “PoC 快，生产补控制面并分层毕业” |
| “Agent 能调用所有工具” | 极易越权和注入 | “小工具契约、最小权限、审批与审计” |
| “Queue mode 就高可用” | 只覆盖一部分扩展 | “还要业务幂等、状态库、限流、备份与演练” |
十一、最后速记
- Workflow 是开发者确定骨架，Agent 是模型动态选路；强业务主干优先 Workflow。
- Dify/Coze 适合 AI 应用验证与业务可维护，不能替代身份、权限、领域事务和审计。
- n8n 擅长事件、连接器和自动化；扩容后仍需要业务幂等和外部回执。
- LangGraph 解决显式 Agent 状态、checkpoint 与人审；Temporal 类运行时解决长期业务协调；两者可组合。
- Checkpoint 不保证恰好一次，外部副作用要幂等、对账、补偿。
- 2026 的工作流面试重点是耐久、人审、工具治理、版本、评测与成本，而不只是“会不会拖节点”。