AI 编程工具 × 编排工具：实测数据 / 选型矩阵 / Token 计算器 / 的工作流模板。-NodeByte

知乎那篇是”讲清楚为什么”，这篇是”拿走就能用”。
五份干货打包：工具对比表、能力矩阵、选型决策树、Token 计算器、可 fork 的工作流模板。
数据截至 2026 年 8 月初，工具有大版本更新会同步刷新。有勘误直接在帖下评论。

〇、怎么用这篇帖子

五份资源对应五个不同的决策时刻：

正在选编程工具 → 看 ① 和 ④
正在选编排工具 → 看 ② 和 ③
已经选完要动手 → 看 ⑤
预算审批要做估算 → 看 ④

知乎版里每个章节末尾的”完整数据在 NodeByte 社区”指向的就是这篇。所有数据和知乎版 V3 完全一致，不会出现两边说法打架的情况。如果哪天某条数据对不上，以这篇为准——因为它会先更新。

① 六款 AI 编程工具实测对比表

1.1 版本与定价一览

工具	当前版本（2026-08）	版本关键变化	计费方式	价格档位	国内可用性
Cursor	Cursor 3（2026-04-02）	从”AI 原生 IDE”重构为”agent 管理工作台”；Agent Mode 成主线，Composer 降为精修辅助；8 月新增 Google Workspace 读写	usage-based（2025-06 起改）	Hobby 免费 / Pro $20 / Pro+ $60 / Ultra $200 / Teams $40 一人 / Enterprise	官方支持，需自备网络
Claude Code	Claude Code 2.0（2025-09-29）	checkpoints 检查点回滚、subagents 子代理、Agent SDK 全面重写；2025 全年 ship 176 次更新；主题线”Context Engineering”	Max plan 固定费率 / API 按 token	Max $100/月（性价比最高）；API 按 token 计价	官方不支持国内——OAuth/API/CLI/VS Code 扩展全拦截；需第三方网关中转（Crazyrouter、teamorouter、qcode.cc 等，部分支持支付宝）
GitHub Copilot	Agent Mode（2025-05-13 全量开放）	Workspace 已于 2025-05-30 sunset，Agent Mode 并入 VS Code 17.14+ 和 Visual Studio；Copilot for Azure GA 引入 Agent Mode Orchestration	$10/月包月（含 Agent）+ 消耗性计费附加项	Copilot Pro $10 / Pro+ $39 / Business $19 / Enterprise $39	可用，但有”账单震撼”问题
Windsurf（已更名 Devin Desktop）	Devin Desktop（2026-06-02 更名）	2025-12 Cognition AI（Devin 母公司）以约 $2.5 亿收购；2026-06 编辑器更名；Agent Manager 面板是亮点；Cascade 多文件编辑仍是核心；底层绑定 Gemini	usage allowance（2026-03 取消 credit 制，按日/周刷新）	Free / Pro $15 / Teams / Enterprise	官方支持
Cline	VS Code 扩展，持续迭代	前身 Claude Dev，改名避免商标问题；BYOK 自带 Key；Plan/Act 模式分离；MCP Marketplace；全球 800 万+ 开发者；Roo Code 已关停合并回 Cline，分叉链现为 Cline → Kilo Code	开源免费，模型费自付	取决于底层模型	可用，国产模型友好
TRAE	TRAE CN（2026 年初 2.0）	字节系产品，2025-01 正式发布；产品矩阵扩展 TraeWork/TraeCode/TraeDesign；接入 Doubao/DeepSeek/Kimi K2；截至 2025 年底总注册超 600 万、月活 160 万	2026-07 前完全免费，现设每日限额	免费策略（限量）	国内开箱即用，无需 VPN

1.2 能力维度对比

工具	主驾驶位	上下文管理	并行 agent	MCP 支持	失败回滚	SWE-Bench Verified
Cursor	你写代码，AI 辅助	仓库级索引 + Google Workspace 扩展	最多 8 个并行（2.0+）	全面，生态默认适配对象	Composer diff review；Cursor 3 弱化人审	51.7%
Claude Code	AI 写代码，你当副驾	整仓库根目录认知；subagents 上下文隔离	subagents 支持子任务拆分	Agent SDK 原生支持	checkpoints 检查点回滚	未公开直接对比
Copilot	你写代码，AI 辅助	IDE 范式约束	Agent Mode Orchestration	逐步接入	代码迭代自修复	56%
Devin Desktop	你写代码，AI 辅助	仓库级，Cascade 多 session	Agent Manager 面板最出色	部分支持	Cascade diff review	未公开
Cline	你写代码，AI 辅助	仓库级	多任务支持	MCP 生态最活跃，可自创工具扩展	Plan/Act 模式分离	未公开
TRAE	你写代码，AI 辅助	仓库级	支持	部分	未明确	未公开

1.3 实测 Token 效率（关键反直觉数据）

工具	Token 效率	实测来源	备注
Claude Code	基准 1x（最省）	futureproofing.dev 2026-06-29 实测	在公开 benchmark 上比 Cursor 少用 5.5 倍 token 完成同一任务
Cursor	基准 5.5x（多耗 5.5 倍）	同上	上下文管理粗糙，有”为压成本截断上下文”的争议
Claude Code 重度用户	8 个月 100 亿 token	murphye.medium 实测	Max plan $100/月扛住，同等用量按 token 计费会高得多

$$
Upload failed
$$

1.4 各工具踩坑速查

工具	三大典型坑	出处
Cursor	① 2025-06 改 usage-based 后出现”意外账单”，Anysphere 公开道歉退款 ② 被吐槽为压成本在后台”优化”token，导致上下文被截断、解决方案不完整 ③ Ultra $200 档被吐槽”out of control”	r/cursor、r/singularity、r/ChatGPTCoding
Claude Code	① 烧 token——onevcat 一个半月烧掉价值 3000+ 美金 token，后 Anthropic 出 weekly 限制 ② 特定栈幻觉：前端/TS 如鱼得水，iOS/Swift 各种臆造不存在的 API，onevcat 原话”幻觉严重” ③ 国内需第三方网关中转，存在合规与稳定性风险	onevcat 博客、Anthropic 官方国家列表
Copilot	① “账单震撼”——The Register 形容为”AI 时代的账单震撼”，有人新制第一天就用完整月额度 ② 没有清晰用量追踪器，被形容为”开一辆没有油表、却被告知汽油很贵的车” ③ Agent Mode 体验不如 Cursor 顺滑、模型选择不灵活	The Register、AI 郵报、zapier 实测
Devin Desktop（原 Windsurf）	① 14 个月三易其名（Codeium → Windsurf → Devin Desktop），旧评测引用即过时 ② 被 Cognition 收购后 Reddit 反馈文件编辑 bug 增多 ③ 底层绑定 Gemini，模型选择受限 ④ “Sorry Windsurf, I Loved You”——r/windsurf 用户出走情绪	r/windsurf、博客园横评
Cline	① 配置复杂——要自己调模型、设权限、配 MCP，门槛不低 ② 太依赖底层模型质量，模型不行再灵活也白搭 ③ 2026-02 有 GitHub issue 反馈执行 MCP server 工具时不询问权限（安全议题）	GitHub issue、博客园
TRAE	① 免费政策退坡——2026-07 前完全免费，现设每日限额 ② 模型上限受制于国产模型，DeepSeek/Kimi K2 接入后能力抬升但仍与 Claude Sonnet 4.5 有差距 ③ 海外英文评测少，参考数据薄弱	知乎专栏、CSDN

1.5 一句话选型提示（懒人版）

你要生态最成熟、愿意接受定价不透明 → Cursor
你做重型任务、追求 token 效率、能搞定国内中转 → Claude Code
你已经在 GitHub 企业版生态里、想要 SWE-Bench 略胜一筹 → Copilot
你最看重并行任务管理面板、对底层模型绑定不敏感 → Devin Desktop（原 Windsurf）
你要开源、BYOK、不愿被任何厂商绑定 → Cline
你在国内、不想折腾网络、要中文场景优化 → TRAE

② 四款编排工具能力矩阵

2.1 核心维度对比

维度	n8n	Dify	Coze（扣子）	LangFlow
当前版本	2.x（v2.10.4，2026-03）	v1.5.0（2026-03）+ 2026-07-27 release	Coze 2.0（2026-01）	IBM Watsonx 体系内
开源协议	fair-code（Sustainable Use License），可商用但有限制	修改版 Apache 2.0（非 AGPL！）；多租户 SaaS 商用需授权	闭源；coze-studio 在 GitHub 但与商业版有功能差异	开源，IBM 管控
部署重量	轻量——一个 docker 容器跑起来	重——docker-compose 服务容器多，被 V2EX 戏称”小小的震撼”	云端 SaaS 为主，无自托管	中等，pip install 可启动
HITL（人在回路）	一等公民，最强——2026-01-30 新增 HITL sub-node，可挂 AI Agent 节点上做细粒度审批；可路由 Slack；2026-03 Reddit 公布”Human-in-the-Loop for Tool Calls”	有审批节点，但工程化深度不如 n8n	弱，平台级限制	较弱，偏原型
可观测性	执行日志完善，节点级变量追踪	1.5.0 升级了 workflow debugging——保存节点产出、实时变量追踪、单步即时测试	平台级仪表盘，不透明	偏原型，生产级可观测性弱
回滚能力	最完善——执行日志 + 节点级回滚；Wait 节点 v2.0 修复后子工作流更安全	节点级回滚，但调试体验被吐槽	平台级，不可控	依赖 LangChain checkpoint，生产级短板明显
触发机制	Webhook、Cron、事件驱动、HITL sub-node	API、Webhook、定时、Agent 自主触发	对话触发、定时、平台事件	API、手动、LangChain 触发
AI 节点数量	70+（digitalapplied 2026-03 评测）	50+ 内置工具（Google Search、DALL·E、Stable Diffusion、WolframAlpha 等）	字节系模型生态 + Skills Store	LangChain 全家桶
Agent runtime	自研（2025-12 社区确认：不使用 LangChain，跑在 n8n 自己的 tool-calling + workflow orchestration 上）	基于 LLM Function Calling 或 ReAct；1.5+ 的 agent roster 把 agent 升级为”可复用资产”	字节系自研，Skills 体系	LangChain 原生
更新节奏	稳定，2.x 持续迭代	更新快（V2EX 多人提及）	字节系政策变化频繁	被 IBM 收购后节奏待观察
国内可用性	自托管无障碍	自托管无障碍	国内版（扣子）闭源，平台风险高	自托管可用

$$
Upload failed
$$

2.2 各工具的”杀手锏”与”致命伤”

工具	杀手锏	致命伤
n8n	HITL 一等公民 + 轻量自托管 + 执行日志最完善	AI 结构化数据解析”挺折腾”；自带智能体配了 DeepSeek 还在请求 OpenAI 接口的 bug（issue 长期未修）；HITL 与 n8n UI 耦合紧，外部审批要 Wait+Webhook 绕开
Dify	一站式功能最全 + 更新快 + agent roster 把 agent 变可复用资产	部署重（”很肥很耗资源”）；docker-compose 升级”够你喝一壶”；工作流 API 被吐槽”稀烂”、返回非标准 JSON；调试体验差（1.5.0 部分缓解）
Coze	门槛最低 + 2.0 Skills 体系 + 字节系生态（飞书/微信/钉钉）	闭源 + 付费化启动（2025-08-15 起）+ 平台风险；大并发 2-3 秒延迟；不适合长期产品基座；企业级系统对接、模型自由接入封闭
LangFlow	上手最低门槛 + 可视化 LangChain + IBM Watsonx 生态	偏原型，一站式能力被 Dify 碾压（ZenML: “Dify is an all-in-one alternative”）；2025-12-05 CVE-2025-34291 Critical 漏洞（Account Takeover + RCE），生产级安全短板暴露

2.3 编排工具选型一句话

你要 HITL 最强、自托管轻量、能接受折腾 → n8n
你要一站式功能全、agent 可复用、能接受部署重 → Dify
你做 MVP 验证、非技术用户、能接受闭源平台风险 → Coze
你做原型验证和教学、能接受生产级短板 → LangFlow

2.4 HITL 工程化深度对比（这是生产级关键）

维度	n8n	Dify	Coze	LangFlow
审批节点粒度	sub-node 级——可挂特定工具调用上	节点级	平台级，不可控	弱
审批路由外部工具	可路由 Slack 等（但耦合 n8n UI）	可定制	不可控	弱
外部审批绕开方案	Wait for Webhook 模式（推荐）	API 调用	无	无
失败可回滚	是，执行日志完善	是，节点级	平台级，不透明	依赖 LangChain checkpoint
适合生产级	是	是（需接受调试体验短板）	否	否（CVE 未修复前不建议生产）

③ 工作流选型决策矩阵

3.1 三个变量

知乎 V3 第三章末尾说过——你的最优工作流组合取决于三个变量的交叉：

团队规模：个人 / 小团队（2-5）/ 中大团队（5+）
产品形态：内部工具 / 对外服务 / MVP 验证
自动化边界：全自动 / 半自动（关键节点人审）/ 全程人审

3.2 决策树（十二分支）

下表把三个变量交叉出 12 条典型分支，每条给出推荐工具组合 + 真实案例参考 + 失败模式提醒。

#	团队规模	产品形态	自动化边界	推荐编程+编排组合	真实案例参考	主要失败模式
1	个人	内部工具	全自动	Cursor + n8n	newline.co 2026-04 案例	n8n 工作流无版本控制，迭代多了会乱
2	个人	内部工具	半自动	Cline + n8n	——	配置门槛高，依赖底层模型质量
3	个人	对外服务	半自动	Claude Code + Dify	Dify issue #35940 集成提案	Dify 部署重，调试体验差
4	个人	对外服务	全自动	不推荐	——	全自动对外服务 = 高风险，不建议个人搞
5	个人	MVP 验证	全自动	Cline + Coze	——	Coze 闭源 + 付费化，长期不可押
6	小团队	内部工具	半自动	Cursor + n8n	Mattermost 2026-03 完整实现（Cursor Automations + n8n 6 个互联 workflow + Mattermost 通知）	HITL 与 n8n UI 耦合，外部审批要 Wait+Webhook 绕开
7	小团队	对外服务	半自动	Claude Code + Dify	——	“伪 Agent”陷阱——看起来是 Agent，实际只是固定流程
8	小团队	对外服务	全程人审	Cursor + n8n + 显式审批节点	——	人审成瓶颈，AI 跑得飞快但堵在人审这一步
9	中大团队	内部工具	半自动	Copilot + LangFlow	——	CVE-2025-34291 未修复前不建议生产；用 n8n 或 Dify 替代
10	中大团队	对外服务	全程人审	多 Agent 协作 + HITL 审核（Cursor 前端 + Claude Code 后端 + n8n/Dify 调度）	n8n Workflow Builder MCP Server（GitHub salacoste/mcp-n8n-workflow-builder 2025-12）	多 Agent 通信开销指数级，token 成本爆炸
11	中大团队	内部工具	全自动	Copilot + Dify	——	Dify 升级时 docker-compose 配置调整”够你喝一壶”
12	任意	任意	拿不准	——	——	先按”高风险”处理，等摸清失败模式再往下放

3.3 决策树使用说明

先定位你的分支：按团队规模 → 产品形态 → 自动化边界三步走，找到对应行。
看推荐组合：这是基准起点，不是唯一答案。
看失败模式：这是关键——每个组合都有典型坑，提前知道能少走弯路。
第 12 条是兜底：如果你拿不准自动化边界，先按”全程人审”处理。放出去自动跑省的是几分钟人工，一旦出事可能是几周修复——赔率不划算。

3.4 五种典型工作流组合模式（知乎 V3 详述，此处摘要）

模式	适合谁	一句话场景
模式一：Cursor + n8n 串联交付	独立开发者、小团队	你用 Cursor 做菜，n8n 负责上菜、传菜、收盘子
模式二：Claude Code + Dify 构建 Agent 服务	需要对外提供 AI 能力的小团队	Claude Code 炒菜，Dify 开窗口对外卖
模式三：Copilot + LangFlow 企业内部编排	有 GitHub 企业版的中大团队	Copilot 是前台厨师的副手，LangFlow 是后台的菜品研发部
模式四：Cline + Coze 个人独立开发组合	国内独立开发者、副业项目	Cline 做后厨，Coze 当前厅服务员
模式五：多 Agent 协作 + HITL 审核	做生产级 AI 产品的团队	多个厨师分工炒菜，总厨在出菜口试味把关

④ Token 经济学计算器

4.1 使用方法

输入两个变量——任务类型 和 团队规模——查表得到推荐工具组合 + 预估月账单区间。

预估基于社区成员脱敏分享的真实账单数据 + 各工具官方定价计算，不含网络/中转/第三方服务费用。是估算不是承诺——你的实际账单取决于用量级别、模型选择、任务复杂度。

4.2 任务类型 × 团队规模 → 推荐组合 + 月账单

任务类型	团队规模	推荐编程工具	推荐编排工具	预估月账单（美元）	备注
轻量补全（行内代码、格式化、简单重构）	个人	Copilot Pro $10	不需要	$10	包月最稳，无意外账单
轻量补全	小团队（2-5）	Copilot Business $19×N	n8n 自托管（免费）	$38-95	n8n 自托管 = 0 编排费
轻量补全	中大团队（5+）	Copilot Enterprise $39×N	n8n 自托管	$195+	企业版含 GitHub 集成
中等开发（多文件编辑、模块实现、bug 修复）	个人	Cursor Pro $20	n8n 自托管	$20	注意 usage-based 可能超
中等开发	个人（国内）	TRAE 免费（限量）	n8n 自托管	$0	限量后可能需切换
中等开发	个人（开源党）	Cline + 自带 Key	n8n 自托管	$5-30（取决于模型）	BYOK 最灵活
中等开发	小团队	Cursor Pro+ $60 或 Teams $40×N	n8n 自托管	$80-200	适用于并行开发
重型任务（系统重构、跨仓库改造、架构级改造）	个人	Claude Code Max $100	n8n 自托管	$100	Token 效率最高（5.5x 省）
重型任务	小团队	Claude Code Max $100×N	Dify 自托管	$200-500	Dify 部署重，但 agent roster 可复用
重型任务	中大团队	Claude Code Max $100×N + Copilot 辅助	Dify 自托管	$500+	多 Agent 协作成本指数级上升
MVP 验证（快速搭原型、对话机器人）	个人	Cline + Coze	Coze（扣子）	$0-15	Coze 闭源，长期不可押
生产级 AI 产品（对外服务）	小团队	Claude Code + Cursor	n8n 或 Dify 自托管	$300-800	必须设 HITL 节点，否则风险失控
生产级 AI 产品	中大团队	多 Agent 协作（Cursor + Claude Code）	n8n + Dify 混合	$800-2000+	token 成本爆炸，必须做上下文隔离

4.3 计费方式分类速查

工具	计费方式	可预测性	适合的用量级别
Cursor	usage-based（2025-06 起）	低——曾引发”意外账单”事件	中等用量，重型任务慎用
Claude Code	Max plan 固定费率 / API 按 token	高（Max plan）/ 中（API）	重度用户必选 Max plan——8 个月 100 亿 token 也扛得住
Copilot	$10/月包月 + 消耗性附加	中——”账单震撼”问题	轻量补全首选
Devin Desktop	usage allowance（按日/周刷新）	中	中等用量
Cline	开源免费，模型费自付	取决于底层模型	任意，BYOK 最灵活
TRAE	每日限额免费	高（但限量）	轻量国内场景

4.4 关键反直觉：Claude Code 比 Cursor 省 5.5 倍 token

这个数据来自 futureproofing.dev 2026 年 6 月的实测——在同一套公开 benchmark 上，Claude Code 比 Cursor 少用 5.5 倍 token 完成同一任务。

为什么？因为 Claude Code 的 context engineering 做得更精细——Agent SDK + subagents 会把不同子任务的上下文隔离开来，而不是一坨全塞给模型。上下文隔离 = 不重复消耗 = token 省。

这意味着：看工具不能只看单价，要看 token 效率。Claude Code Max plan $100/月看起来比 Cursor Pro $20 贵 5 倍，但完成同一任务省 5.5 倍 token——重度用户实际总账可能反而更便宜。

4.5 编排层成本规律（容易忽略）

规律	说明	对策
链越长越贵	每多一个节点，token 成本指数级上升（不是线性）——每个节点都要把上游上下文重传一遍	不值得自主决策的环节，老老实实写固定规则路由
多 Agent 通信开销	Agent A → B → C 传递过程本身烧 token，你以为跑一次实际烧好几轮	能用单 Agent 完成就别拆多 Agent
自主 vs 固定的权衡	Agent 自主决策贵但灵活，固定规则路由便宜但僵化	需要灵活应变的环节才交给 Agent，其他写死规则

⑤ 可 fork 的工作流配置文件模板

下面是四份可以直接复制使用的工作流配置模板。每一份对应一个典型场景，来自社区成员的真实实现脱敏后公开。fork 之后按自己环境改 webhook URL、API Key、模型名即可。

5.1 模板一：n8n 工单自动化工作流（Cursor 驱动 + n8n 串联 + 通知回流）

对应模式：模式一（Cursor 驱动 + n8n 串联交付）
真实参考：Mattermost 官方博客 2026-03-12 完整实现
适用场景：个人开发者 / 小团队，git push 后自动跑测试 → 部署 → 通知

{
  "name": "git-push-to-deploy-notify",
  "nodes": [
    {
      "parameters": {
        "path": "github-webhook",
        "options": {}
      },
      "name": "GitHub Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [0, 0]
    },
    {
      "parameters": {
        "command": "git pull && npm ci && npm test",
        "executeOnce": false
      },
      "name": "Pull & Test",
      "type": "n8n-nodes-base.executeCommand",
      "typeVersion": 1,
      "position": [220, 0]
    },
    {
      "parameters": {
        "conditions": {
          "boolean": [
            {
              "value1": "={{ $json.exitCode }}",
              "operation": "equal",
              "value2": 0
            }
          ]
        }
      },
      "name": "Test Pass?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 1,
      "position": [440, 0]
    },
    {
      "parameters": {
        "command": "npm run deploy",
        "executeOnce": false
      },
      "name": "Deploy",
      "type": "n8n-nodes-base.executeCommand",
      "typeVersion": 1,
      "position": [660, -100]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK",
        "bodyParameters": {
          "text": "=:部署成功 {{ $json.repository }} @ {{ $json.head_commit.timestamp }}"
        }
      },
      "name": "Notify Slack",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 1,
      "position": [880, -100]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK",
        "bodyParameters": {
          "text": "=:测试失败 {{ $json.exitCode }}，请检查"
        }
      },
      "name": "Alert Fail",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 1,
      "position": [660, 100]
    }
  ],
  "connections": {
    "GitHub Webhook": { "main": [[{ "node": "Pull & Test", "type": "main", "index": 0 }]] },
    "Pull & Test": { "main": [[{ "node": "Test Pass?", "type": "main", "index": 0 }]] },
    "Test Pass?": {
      "main": [
        [{ "node": "Deploy", "type": "main", "index": 0 }],
        [{ "node": "Alert Fail", "type": "main", "index": 0 }]
      ]
    },
    "Deploy": { "main": [[{ "node": "Notify Slack", "type": "main", "index": 0 }]] }
  }
}

使用方法：

在 n8n 中导入此 JSON
替换 YOUR/SLACK/WEBHOOK 为你的 Slack incoming webhook
在 GitHub 仓库 Settings → Webhooks 添加指向 https://your-n8n/webhook/github-webhook 的 webhook
按 Cursor 生成的代码改 npm test 和 npm run deploy 为你的实际命令

5.2 模板二：n8n + HITL 审批节点（生产级半自动工作流）

对应模式：模式五（多 Agent 协作 + HITL 审核）
适用场景：关键节点必须人审的生产级工作流，如支付回调、数据迁移、安全策略

{
  "name": "production-with-hitl-approval",
  "nodes": [
    {
      "parameters": {
        "path": "start-task",
        "options": {}
      },
      "name": "Trigger",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [0, 0]
    },
    {
      "parameters": {
        "model": "gpt-4o",
        "messages": {
          "messageValues": [
            {
              "content": "=:执行任务：{{ $json.task_description }}"
            }
          ]
        }
      },
      "name": "AI Agent",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "typeVersion": 1,
      "position": [220, 0]
    },
    {
      "parameters": {
        "assignedTo": "={{ $env.APPROVER_EMAIL }}",
        "description": "=:审批 AI 生成的方案：{{ $json.task }}",
        "options": {
          "waitTill": "approval"
        }
      },
      "name": "Human Approval",
      "type": "n8n-nodes-base.hitl",
      "typeVersion": 1,
      "position": [440, 0]
    },
    {
      "parameters": {
        "conditions": {
          "boolean": [
            {
              "value1": "={{ $json.approved }}",
              "operation": "equal",
              "value2": true
            }
          ]
        }
      },
      "name": "Approved?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 1,
      "position": [660, 0]
    },
    {
      "parameters": {
        "command": "=:{{ $json.execution_command }}"
      },
      "name": "Execute",
      "type": "n8n-nodes-base.executeCommand",
      "typeVersion": 1,
      "position": [880, -100]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK",
        "bodyParameters": {
          "text": "=:审批被拒绝：{{ $json.task }}"
        }
      },
      "name": "Reject Notify",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 1,
      "position": [880, 100]
    }
  ],
  "connections": {
    "Trigger": { "main": [[{ "node": "AI Agent", "type": "main", "index": 0 }]] },
    "AI Agent": { "main": [[{ "node": "Human Approval", "type": "main", "index": 0 }]] },
    "Human Approval": { "main": [[{ "node": "Approved?", "type": "main", "index": 0 }]] },
    "Approved?": {
      "main": [
        [{ "node": "Execute", "type": "main", "index": 0 }],
        [{ "node": "Reject Notify", "type": "main", "index": 0 }]
      ]
    }
  }
}

工程化提醒：

HITL sub-node 仍与 n8n UI 耦合较紧——如果你做外部审批（如 Slack 按钮审批），推荐改用 Wait for Webhook 模式绕开
把 APPROVER_EMAIL 放到 n8n 环境变量里，别硬编码
审批超时要有兜底——默认拒绝 + 告警，别默认放行

5.3 模板三：Dify Agent 服务化工作流（Claude Code + Dify 对外服务）

对应模式：模式二（Claude Code + Dify 构建 Agent 服务）
真实参考：Dify issue #35940（External Agentic Node 提案）
适用场景：把 Claude Code 写好的能力包装成 Dify 对外的 Agent API

# Dify DSL - 保存为 .yml 文件后在 Dify 中导入
app:
  name: "claude-code-agent-service"
  mode: "agent_chat"
  description: "把 Claude Code 写好的能力封装为对外服务"
  icon: "🤖"

model_config:
  model:
    provider: "anthropic"
    name: "claude-sonnet-4-5"
    mode: "chat"
    request_params:
      temperature: 0.3
      max_tokens: 4096
  prompt_template:
    - role: "system"
      text: |
        你是一个封装好的代码服务 Agent。
        用户通过 API 调用你，你需要：
        1. 理解用户的任务需求
        2. 调用相应的代码模块完成
        3. 返回结构化结果

        你可以调用的工具有：
        - generate_code: 生成代码片段
        - review_code: 审查代码
        - run_test: 跑测试

        对于高风险操作（部署、数据库迁移、支付逻辑），
        必须返回 "NEEDS_HUMAN_REVIEW" 标记。

agent_tools:
  - name: "generate_code"
    description: "生成代码片段"
    api:
      url: "http://your-claude-code-runner:8080/generate"
      method: "POST"
      headers:
        Authorization: "Bearer {{ api_key }}"
      body:
        task: "{{ task }}"
        language: "{{ language }}"
  - name: "review_code"
    description: "审查代码"
    api:
      url: "http://your-claude-code-runner:8080/review"
      method: "POST"
      body:
        code: "{{ code }}"
  - name: "run_test"
    description: "跑测试"
    api:
      url: "http://your-claude-code-runner:8080/test"
      method: "POST"
      body:
        test_path: "{{ test_path }}"

workflow:
  nodes:
    - id: "start"
      type: "start"
      data:
        variables:
          - name: "task"
            type: "string"
            required: true
    - id: "agent"
      type: "agent"
      data:
        strategy: "function_calling"
        tools: ["generate_code", "review_code", "run_test"]
    - id: "risk_check"
      type: "if"
      data:
        condition: "{{ output.risk_level == 'high' }}"
    - id: "human_review"
      type: "human_approval"
      data:
        message: "高风险操作，需要人审：{{ output.summary }}"
    - id: "end"
      type: "end"
      data:
        output: "{{ output }}"
  edges:
    - source: "start"
      target: "agent"
    - source: "agent"
      target: "risk_check"
    - source: "risk_check"
      target: "human_review"
      when: "true"
    - source: "risk_check"
      target: "end"
      when: "false"
    - source: "human_review"
      target: "end"

使用方法：

在 Dify 中导入此 DSL
替换 your-claude-code-runner 为你 Claude Code 代码服务的实际地址
把 {{ api_key }} 设为 Dify 凭据变量，别硬编码
测试时先用 review_code 这种低风险工具，再上 generate_code

5.4 模板四：MCP 桥接工作流（n8n Workflow Builder MCP Server）

对应模式：模式五的连通方式
真实参考：GitHub salacoste/mcp-n8n-workflow-builder（2025-12-27）
适用场景：编程层 agent 通过 MCP 直接操作编排层 workflow——对话式创建和管理 n8n 工作流

{
  "mcpServers": {
    "n8n-workflow-builder": {
      "command": "npx",
      "args": ["-y", "mcp-n8n-workflow-builder"],
      "env": {
        "N8N_BASE_URL": "https://your-n8n-instance.com",
        "N8N_API_KEY": "your-n8n-api-key"
      }
    }
  }
}

怎么用：

把上面的 JSON 加到 Claude Code 的 MCP 配置文件 ~/.claude/mcp.json
在 Claude Code 终端里直接对话：

“帮我在 n8n 里创建一个工作流：每天 9 点跑一次数据导出，结果发到 Slack”
“看一下 n8n 里那个 deploy 工作流，把测试步骤加上覆盖率检查”

Claude Code 通过 MCP 协议直接操作 n8n 的 workflow API
这就是编程层（Claude Code）通过 MCP 协议直接编排编排层（n8n）的具体落地

安全提醒：

2026-02 有 GitHub issue 反馈 Cline 执行 MCP server 工具时不询问权限——用 MCP 时务必检查权限提示是否正常
n8n API Key 权限要收窄——只给 workflow 读写权限，别给管理员权限
生产环境 n8n 实例建议加 IP 白名单

5.5 模板使用通用建议

场景	用哪个模板
个人开发者 + 简单 CI/CD	模板一
生产级 + 关键节点要人审	模板二
把代码能力对外做成 API 服务	模板三
让 AI 通过对话管理 n8n 工作流	模板四
多 Agent 协作（Cursor 前端 + Claude Code 后端）	模板二 + 模板四组合

⑥ 这份资源帖怎么维护

这篇帖子是活文档——数据每月会刷新，工具有大版本更新会同步修订。几个维护承诺：

Cursor / Claude Code / n8n / Dify 每次大版本更新——24 小时内刷新对比表
工具易主/改名/收购——立即更新（参考 Windsurf → Devin Desktop 的教训）
社区新出现的真实工作流案例——补充到 ⑤ 模板库
Token 实测数据——每季度校准一次

社区成员可以：

在帖下评论补充自己的实测数据 / 踩坑记录
提交自己的工作流配置模板（n8n 的 workflow JSON、Dify 的 DSL、Coze 的 bot 配置）——审核后合并到 ⑤
报告数据错误——核验后立即修订

数据时点：2026 年 8 月初。
数据来源：林恩-深度技术架构师 13 项联网查证报告（36 条一手来源索引，存于社区”数据来源”板块）+ 陈子期社区情绪素材包 + Mattermost / newline.co / GitHub issue #35940 / salacoste/mcp-n8n-workflow-builder 等公开案例。
引用的社区原话：均注明出处（V2EX / Reddit / 博客园 / onevcat / Threads），如原作者认为有不当引用请联系删除。

知乎版是”讲清楚为什么”，社区版是”拿走就能用”。两篇配合着看，工具会变，活法长存。

文章版权归作者所有，未经允许请勿转载。

THE END