n8n 官方 README 上写着 1500+ 集成、9000+ 工作流模板——但我第一次打开编辑器，画布上一个节点都连不起来。后来才想明白，AI Agent 工作流搭建入门真正的坎不在选工具，而在把「一次手工活」翻译成「触发—取数—加工—输出」这几步可复现的动作。我前后翻了三次车，才把一条流程跑到能交付给别人用。
起因：为什么不再堆单点工具
最早我们的做法是「一个需求一个脚本」。查抖音指数写一个，导微信指数再写一个，写完就扔在文件夹里，下次要用还得翻出来改参数。零散脚本的问题是：换个人接手就断，报错没人知道，跑没跑全靠记性。
真正让我下决心换路子的是一笔账。做投放那阵，光是盲目出价浪费的预算就超过 8000 元/月；后来把批量采集的工具授权费加上代理 IP 费用，每月约 2200 元，顺带把出价策略也跑成了自动的（微信指数深夜暴增时的降本增效复盘）。省下的不是那几次点击，是决策滞后。
所以目标定得很具体：不是「搭一个 AI 平台」，而是把每周重复的那几件事，变成一条别人接得住的流程。我判断一个工作流算不算搭成的标准也只有一条——它能不能离了我也跑。
过程：三个开源项目，我按什么顺序试的
下面三个都来自公开仓库，命令与参数以各自仓库最新说明为准，我写的是核对文档时的口径。
先画出来：n8n
仓库 github.com/n8n-io/n8n，文档 docs.n8n.io。官方给了两种启动方式：装了 Node.js 可以直接 npx n8n；用 Docker 则是先 docker volume create n8n_data，再 docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n，起完访问 http://localhost:5678。它的定位是「可视化画布 + 代码」，画布上拉节点，节点里能写 JavaScript 或 Python，需要接没有现成节点的服务就上 HTTP Request。
和 AI 相关的能力在仓库里是独立包：packages/@n8n/nodes-langchain、packages/@n8n/agents，还有 packages/@n8n/mcp-browser 走 MCP。授权这块要提前看：它是 fair-code，源码可见、可自托管，但许可是 Sustainable Use License 加 n8n Enterprise License，不是常见 MIT/Apache 那种，商用前自己读一遍条款。
再做成服务：Dify
仓库 github.com/langgenius/dify，文档 docs.dify.ai。官方 Docker Compose 部署页写的最低要求是 CPU ≥ 2 核、内存 ≥ 4 GiB，并且 Docker Compose 要在 2.24.0 以上；流程是进 dify/docker 目录，cp .env.example .env，然后 docker compose up -d，最后访问 /install 建管理员账号。它拉起来是 7 个核心服务（api、worker、web、plugin_daemon 等）加 8 个依赖组件（Postgres、Redis、Nginx、Sandbox 等），官方文档特意说明 init_permissions 这个一次性任务跑完就是 Exited，属于正常，别以为挂了。许可证官方原话是「Dify Open Source License，本质上是 Apache 2.0 加了一些额外限制」。
最后收口：LangGraph
仓库 github.com/langchain-ai/langgraph，MIT。它给写 Python 的人用，pip install -U langgraph，官方示例里 create_react_agent 传一个模型名加工具列表就能起一个 agent。它对「工作流」的定义更硬：状态图、节点、边、检查点，官方说灵感来自 Pregel 和 Apache Beam，接口风格参考 NetworkX。官方文档列的四个卖点里，我最看重两个：durable execution（跑崩了能从断点续）和 human-in-the-loop（能在任意一步插进来改状态）。
我的顺序是：先用 n8n 把逻辑画出来跑通，等它稳定了，再把最需要可靠性的那一段用 LangGraph 重写成能断点续跑的版本。反过来一开始就上底层框架，很容易在还没想清楚步骤的时候，先被状态设计绊住。
踩坑：三个让我返工的地方
一是把「一次问答」当成了工作流。最早我做的东西本质是个聊天框，输入一句话出一段结果。它没法复用，因为每次的输入格式都不一样。后来我把它拆成参数卡：哪些字段由人填、哪些字段自动取、输出落到哪。这个改法我们在内容流程里也用过，改成四步走、第一步让运营填参数卡之后，才第一次有了可交接的东西。
二是没算 token 和调用成本就往里灌数据。流程一跑起来，成本是乘出来的，不是加出来的。账单超预算是小事，更恶心的是上下文超限，接口直接报错，前面白跑一遍。这类开销建议在节点里先估一下，我们站内有个本地 token 数与调用成本估算器，跑之前先量一下比事后对账省事。
三是凭据随手放。工作流要连外部服务，API key 必然落在配置里。我吃过亏，后来养成的习惯跟用剪贴板工具是一个道理：不用的时候把凭据关掉，或者用完立刻清掉缓存，别让它一直躺在可访问的地方（剪贴板历史暂存板那篇里提过同样的做法）。
解法：把四步骨架固定下来
我后来给自己定了个模板，任何新流程都先按这四步搭，再谈加 AI：
- 触发：定时还是事件？定时的好处是可预测，事件的好处是不空跑。周更类的东西一律定时。
- 取数：明确接口、字段、失败重试。这里最容易偷懒，也最容易出问题。
- 加工：清洗、聚合、格式化，能不用模型就不用模型，规则能解决的部分别花钱。
- 输出：落到文件、表格还是消息？谁来看？看不懂的输出等于没输出。
模型节点只放在「加工」里规则搞不定的那一小段，比如摘要、归类、改写。这样即使模型抽风，流程也只是那一段质量下降，不会整条崩掉。AI 视频配音字幕工作台就是按这个思路拆的四步，它之所以能交付，是因为每一步的中间产物都能单独检查。
我原本以为「容错」是可选项，后来才发现，流程能不能交付，取决于出错时它是什么表现。要么明确重试、要么明确告警、要么明确留证，三样都没有的话，跑挂了连日志都找不到。
验证：拿什么判断它算搭成了
我最开始用「能不能跑通」当标准，这个标准太松了——跑通一次和能长期用是两回事。后来换了三个硬指标：
- 交付时间：内容流程自动化之后，我们单篇生产时间从 4 小时压到 1.8 小时，这个数字是用 AI 做竞品内容拆解那次实测出来的。压缩比不到 60%，但它是可复现的，每周都成立。
- 能否换人：把流程交给没参与搭建的同事，看他能不能独立跑完并处理第一次报错。跑不完就是没搭成。
- 异常是否有痕迹：故意断一次网、填一个错参数，看系统是静默失败还是留下可查的记录。
有一点要说清楚：上面这些数字只在我们自己的场景里成立，词量、频次、团队规模一变就不适用了。别拿别人的压缩比当自己立项的依据。
相关工具与项目出处
- n8n：
github.com/n8n-io/n8n／ 文档docs.n8n.io（fair-code，Sustainable Use License） - Dify：
github.com/langgenius/dify／ 文档docs.dify.ai（Apache 2.0 衍生 + 额外限制） - LangGraph：
github.com/langchain-ai/langgraph（MIT） - 本地 token 与成本估算：文本 Token 数估算器
- 四步式内容流水线：AI 视频配音字幕工作台
常见问题
Q：完全不会写代码，能从哪个开始？
A：从 n8n 这类可视化工具开始，先把「触发—取数—加工—输出」跑通，代码节点等需要时再补。别一上来装 Dify，它拉起来是十几个容器，光排查启动就够劝退。
Q：这些项目都能商用吗？
A：不一定，差别还不小。LangGraph 是 MIT，Dify 是 Apache 2.0 加额外限制，n8n 是 fair-code 的 Sustainable Use License。要对外服务，务必按仓库 LICENSE 原文逐条核对，别信二手测评的结论。
Q：一定要自托管吗？
A：看数据。数据不出内网的诉求一旦成立，自托管基本是唯一解。若都是公开数据、量也不大，先用云版本验证流程有没有价值，比先解决部署划算。
Q：本机没有 Docker 能学吗？
A：能。n8n 的 npx n8n 和 LangGraph 的 pip 安装都不依赖 Docker，可以先在本地把逻辑跑通，部署放后面。本文容器命令均来自官方文档，参数以仓库最新说明为准。
