Appearance
Q64 · Coze / Dify 这类平台和 LangChain / LangGraph 的关系怎么理解？
产品经理要做一个耳机售后助手：用户输入订单号，系统查订单和现行政策；如果条件不满足自动处理规则，转给人工确认，再把结论回复给用户。团队可以打开可视化画布，把“查订单 → 查政策 → 人工确认 → 回复”连起来；也可以用代码写模型调用、工具函数和处理分支。业务目标相同，所选工具的抽象层次不同。
Coze / Dify 是面向应用构建与运营的可视化平台：除了编排模型步骤，还提供工作区、知识与工具接入、调试和发布等一组产品能力。LangChain 是代码中的模型、工具、Agent 等抽象与集成；LangGraph 是代码中的有状态编排框架和运行时，便于显式管理步骤、分支、恢复与人工参与。它们有重叠的“编排”能力，但不在同一产品层面，不能简单说“平台只是框架的 GUI”，更不能推断 Coze 或 Dify 内部一定用了 LangChain / LangGraph。Coze 官方能力概览、Dify 官方介绍、LangChain 官方概览、LangGraph 官方概览
本文依据 2026 年 9 月 26 日可查到的上述官方资料说明“层次与选型”。平台的云端版、自部署版、地区和工作区配置可能不同；本文不把某个页面上的节点数量、套餐限制或现成集成当成永久保证。示例中的订单、日期和政策是教学假设，不是任何商家的真实政策。
术语与符号
| 术语或符号 | 零基础解释 | 本例中的对应物 |
|---|---|---|
| AI 应用平台 | 除了编排逻辑，还提供构建、调试、发布和日常管理入口的产品 | Coze 或 Dify 里的售后应用 |
| 可视化画布 / 节点 | 在界面里用图形表示步骤；一个节点通常做一件事 | “查订单”“查政策”两个节点 |
| Workflow（工作流） | 按预设步骤与分支执行的业务流程 | 先查订单，再判断是否要人工确认 |
| Agent（智能体） | 围绕目标可用模型选择行动和工具的程序 | 面向用户的售后助手；不等于每一步都由模型决定 |
| LangChain | 用代码连接模型、工具和 Agent 的框架及集成 | 调用模型、包装订单查询工具 |
| LangGraph | 用代码定义状态、节点和边，并运行有状态流程的框架 | 保存订单事实、按条件走人工确认分支 |
| 状态（State） | 流程进行到当前时已知的结构化事实 | A123 签收日、是否拆封、人工结论 |
| 分支 | 根据明确条件选择下一步 | 已拆封时转人工，而非直接判自动退款 |
| 人工确认 | 人在关键步骤审查并给出决定 | 售后专员核实其他售后途径 |
| 工具 / 插件 | 应用可调用的外部能力；不同产品的命名和接入方式可能不同 | 按订单号查订单系统 |
| 知识库 / 检索 | 保存政策等资料，并按问题找出相关片段 | 取回退款政策 v3 |
order_id | 订单查询输入字段 | A123 |
signed_at / opened | 签收日期 / 是否已拆封，均来自订单系统 | 2026-09-20 / true |
policy_version | 本次采用哪版政策，防止答复混用旧规则 | v3 |
review_status | 人工确认的状态或结论 | “已审查：不符合自动退款，可申请质检” |
| 发布 / API | 把应用提供给用户，或给其他程序调用的入口；API 是程序间接口 | 网页售后助手或业务系统调用它 |
| 回归测试 | 用固定案例检查改动有没有破坏旧行为 | 每次改画布或代码后重测 A123 |
同一条业务流程，可以从不同入口实现
图的上下两条路不是上下游依赖：上面表示在平台画布中配置节点，下面表示在代码里定义相同的处理步骤，右边是同一个业务结果。图只表现“实现入口不同，业务流可以相同”，没有画登录、权限、监控、知识库清洗等产品或工程细节；这些环节恰恰会影响真实选型。Coze 官方文档展示了在画布上连接节点、配置输入输出、测试并发布 Workflow；Dify 官方文档也展示了类似的应用编排、测试和发布过程。Coze Workflow 文档、Dify 快速入门
四个名字分别位于哪一层
Coze / Dify：先交付一款可用应用
以 Dify 的官方定位为例，它可创建 Agent、工作流和聊天应用，接入自己的数据，再发布成 Web 应用或用 API 集成到别的产品。Coze 的官方资料也介绍了模型、Prompt、插件、可视化 Workflow、知识库、调试与发布入口。对非开发同事，画布和配置界面降低了首次搭建门槛；对开发者，它把一部分应用管理工作放在平台内。Dify 官方介绍、Coze 能力概览
这不表示“平台完全不用代码”。例如复杂业务接口仍要由团队实现或接入，权限和数据治理也不能靠拖拽自动完成。Coze Studio 的开源说明明确有可视化构建，也包含代码和插件扩展；具体 Coze 云端服务与 Coze Studio 开源版不能默认功能完全一致。同样，Dify 提供云端与自部署路径，团队仍要核对其所用部署方式与当前版本。Coze Studio 官方仓库、Dify 官方介绍
LangChain：让开发者用代码组合模型与工具
LangChain 当前官方文档把 create_agent 描述为可配置的 Agent 构造入口：开发者提供模型、工具、提示词，再根据需要加入中间件等行为。中间件可以理解为插在调用过程中的可复用处理逻辑，例如记录、重试或规则检查。对本例，开发者可以把“按 order_id 查询订单”包装成工具，决定模型何时使用它，再把政策材料送入模型。LangChain 主要给你代码组件与运行逻辑，不会因为安装一个包就自动出现售后业务界面、企业账号和已批准的订单权限。LangChain 官方概览
官方文档也说明，当前 LangChain 的 Agent 建在 LangGraph 之上。这是一条明确的框架关系；它不等于 Coze / Dify 建在 LangGraph 之上。若普通 Agent 抽象足以表达问题，未必需要直接编写 LangGraph 节点。LangChain 官方概览
LangGraph：让状态和控制流更明确
LangGraph 官方将自己定位为偏底层的编排框架与运行时：开发者可以显式定义节点之间怎么走、状态如何更新、何时暂停让人审查、失败后如何恢复。它可与 LangChain 组件搭配，也可独立使用。在本例里，“已拆封 → 进入人工确认”“订单查询失败 → 停止并提示不可判断”都可以写成明确的分支，避免让模型凭一句笼统提示词自行猜流程。LangGraph 的这些能力还需要具体业务代码、存储、权限与部署配置才能形成完整产品。LangGraph 官方概览
四者的关系因此更像应用产品层与开发框架层，并非严格的替代链。若团队已在平台中建售后助手，仍可能在外围系统里用代码实现订单服务；若核心逻辑用 LangGraph 写，仍可能由其他产品界面提供运营和发布能力。图形界面与代码也不是能力高低的绝对分界：平台可有代码节点和 API，代码系统也可配可视化调试工具。具体能力应按所选版本与部署方式核实。Coze Workflow 文档、Dify 官方介绍、LangGraph 官方概览
把 A123 走完，才看得出差别
假设今天是 2026 年 9 月 25 日。订单工具经授权返回：A123 的耳机于 9 月 20 日签收、opened=true；政策 v3 的教学规则是“签收后 7 天内且未拆封，才可自动退款；已拆封需要人工核实其他售后方案”。人工专员最终确认：“不符合自动退款条件；可申请质量检测，故障与退款结果以检测为准。”不要把“签收日”偷换成“下单日”，也不要把“可申请检测”说成“已批准退款”。
| 步骤 | 在可视化平台中可能怎样搭 | 在代码框架中可能怎样写 | 两边都必须核对的事 |
|---|---|---|---|
| 接受输入 | 表单或对话节点取得 order_id=A123 | API 或页面把 order_id 交给程序 | 用户身份与订单查看权限 |
| 查订单 | HTTP / 插件 / 工具节点取回 signed_at、opened | LangChain 工具或普通业务函数查询订单系统 | 服务端再校验权限；失败不能编造订单状态 |
| 查政策 | 知识库检索节点或受控资料节点取 v3 | 检索组件或直接读取受控政策服务 | 版本、生效时间、引用来源 |
| 判断分支 | 条件节点检查 opened=true | LangGraph 条件边或普通 if 转入人工步骤 | 自动规则应明确，不能让模型改写 |
| 人工确认 | 人工处理节点或平台外的工单系统 | LangGraph 暂停/恢复，或外部审核服务 | 人工有权审查、留痕、超时处理 |
| 回复用户 | 模型节点组织措辞并发布结果 | 模型组件生成答复，应用 API 返回 | “可申请检测”与“退款结果待定”表述一致 |
这张表说明一个重要点：业务责任不会随构建工具改变。订单接口必须返回真实状态，人工审查必须由有权限的人完成，政策必须可追溯。平台能把节点连起来；框架能把控制流写清楚；两者都不能凭空提供可信订单、现行政策或合规的人工审批。Coze Workflow 文档、Dify 快速入门、LangGraph 官方概览
失败路径也要有明确结果
如果订单接口超时，平台的工具节点和代码里的函数都会拿不到 opened。正确的流程应停止自动判断，告诉用户“订单状态暂未核实，无法确认资格”，并允许稍后重试或转人工；不能因为政策写着“7 天”就假设耳机未拆封。若政策检索只找到了旧版 v2，也不能继续用它回答。若人工确认等待过久，则保存当前订单事实和待审状态，并给用户一个可查询的处理进度。平台是否内置相应节点、代码侧如何持久化，属于具体实现选择，不能用“用上某产品”代替对失败路径的设计。LangGraph 持久化与人工参与说明、Dify 快速入门的测试与发布流程
选型看业务约束，不看“拖拽”和“写代码”谁更高级
| 需要优先解决的事 | 倾向的起点 | 判断理由和需要验证的限制 |
|---|---|---|
| 两周内让业务同事试用售后流程，需求还在频繁改 | Coze / Dify 等平台 | 画布、测试、发布入口可加快反馈；先确认所需订单接口、权限和部署条件能接进去 |
| 已有大量后端代码与自动化测试，流程需细粒度版本控制 | LangChain / LangGraph 等代码方案 | 工具和分支可进入现有代码评审、测试与发布流程；团队要自行做好应用管理和界面 |
| 有复杂循环、可恢复长任务、人工暂停后精确续跑 | 评估 LangGraph 等显式编排能力 | 状态与分支可写得更细；也要检查平台当前版本是否已足够，不能先入为主判定它做不到 |
| 多人配置应用，但核心风控规则必须由后端统一执行 | 平台 + 受控业务 API 的组合 | 运营改措辞与资料，风控判断保留在可测试、可审计的服务里 |
实际可以先做一个小范围验证：用同一批 20 条售后案例分别跑候选方案，记录正确率、无法回答时是否停住、每次处理耗时、模型调用成本、人工接管是否顺畅。平台与框架都要经过这组业务测试；“能跑通一条演示”远不等于适合上线。成本还包含平台管理、部署、值班、代码维护和团队培训，不能只比较模型账单。
从平台搬到代码，迁移的是什么
假设售后流程先在平台验证成功，后来为了接入公司统一权限和审计系统，打算迁到代码。不要把迁移理解成“把画布导出，再自动变成 LangGraph”。需要逐项盘点：
- 输入输出契约：用户传什么字段，回复什么结构；
order_id的校验、错误消息与会话 ID 怎样保持兼容。 - 节点语义与分支条件：画布中的“已拆封”分支、人工确认的等待与超时，代码实现后是否逐条等价。
- 模型与提示词配置：所用模型、参数、系统指令、模板变量、工具描述和版本；同一段文字迁走后行为仍可能变化。
- 知识与数据：政策
v3的来源、清洗切片、检索条件和权限。只搬提示词，不搬可靠资料与检索规则，会让结果失真。 - 工具与凭据：平台插件如何调用订单 API，代码侧如何取得凭据、设置超时、记录审计；密钥不能随配置文件泄漏。
- 运行与发布：平台原有的测试、日志、权限、Web/API 发布入口，迁出后要由新系统或外围服务接上。
这是一份工程迁移检查清单，不是在说某平台永远不能导出配置。即便平台提供流程导出，导出的也是该产品的配置表示；目标框架的状态、错误语义和权限接口仍需映射并重测。应保留一批固定回归案例：A123 已拆封、另一笔未拆封订单、订单接口超时、政策缺失、人工拒绝、重复提交。用新旧结果并排比较，确认差异是有意调整还是迁移引入的错误。Dify 官方介绍、Coze Workflow 文档、LangGraph 官方概览
面试时怎么回答
Coze、Dify 更接近应用构建平台：用可视化编排把模型、工具、知识和发布管理放在一起。LangChain 是代码层的模型、工具与 Agent 抽象；LangGraph 是更底层的有状态编排运行时，适合把分支、恢复和人工参与写清楚。它们在“编排流程”上有重叠，但平台与代码框架不在同一层，也不能推断平台内部一定依赖 LangGraph。选型要看谁维护流程、上线速度、复杂控制流、权限、部署和测试要求。用耳机售后举例，两条路都能做查订单、查政策、人工确认；无论选哪个，都必须保证订单权限、政策版本和失败回退。若从平台迁到代码，要迁输入输出、分支、提示词、知识检索、工具凭据与发布运维，并用同一组案例回归验证。
若追问“现在平台能写代码、框架也能看图，界限还有意义吗？”，可以回答：界限不是“有没有图形界面”，而是谁提供完整应用管理与发布外壳、团队主要在哪一层维护业务规则。功能会重叠，具体产品能力应按当前版本实测；选型时评估总交付成本和控制权更有意义。