当团队里有人说「我想要一个能读表格、按规则出结论的小助手」，直接写代码往往是杀鸡用牛刀。Dify 这类开源编排平台的价值，就是把模型调用、知识库、条件分支、人工节点拖成一张图，产品经理也能看懂。在 Manus 这类通用 Agent 越来越强的同时，垂直小场景反而更适合用「可控的工作流」而非「自由的 Agent」。
最短部署路径
官方仓库自带 docker-compose。在一台有 8GB 内存以上的机器上：
git clone https://github.com/langgenius/dify.git，进入docker目录；- 复制
.env.example为.env，按需改对外端口与密钥； docker compose up -d，等所有容器起来后访问http://localhost/install初始化管理员账号。
接模型与跑通第一个流
进控制台后，在「模型供应商」里填 OpenAI 兼容接口的 base_url 与 key——DeepSeek、智谱、自建网关都能接。然后建一个「工作流」：
- 开始节点收一个文本输入（待审批的报销描述）；
- 接一个 LLM 节点，提示词让它按「金额／事由／是否超标」三栏输出；
- 再接一个条件分支，金额超阈值走「转人工」，否则走「通过」。
Dify 会自动把这个流暴露成一个 API 端点，内网系统直接 POST 调用。
什么时候该用，什么时候别用
工作流适合路径确定、要求可复现的场景：审批摘要、合同初筛、客服分流。它不适合开放式任务——那种要让模型自己决定下一步做什么的，交给 Agent 框架。把 Dify 当「可控的自动化管道」，而不是「万能机器人」，它才会好用。
补一个团队协作的细节：Dify 的应用可以一键发布成网页或 API，产品同学在网页上自己调提示词和知识库，工程师只负责接后端接口。这种分工比「所有改动都要开发提 PR」快得多。上线前记得打开它的调用日志，看每个节点的耗时，慢的那一步往往是被忽略的外部接口，而不是模型本身。
把 Dify 用成团队的「自动化管道车间」，而不是一个人玩的玩具，它的价值才真正释放出来，产品和工程各就其位。