← 回成果库

手机上最大限度实现 n8n 式多代理工作流:能力对标 · 差距清单 · 升级路线


一、一句话结论(结论先行)

手机 + 订阅 Claude Code 已经能覆盖 n8n 六大核心能力里的四个半(AI 处理、多步编排、定时触发、模板库、数据抓取),而且"智能节点"这一层比 n8n 强得多;真正的硬差距只有两个——【秒级/事件级的常驻触发(webhook)】和【上千 SaaS 插件的凭据托管】。你的 batch 项目最值钱的升级方向不是把画板做得更像 n8n,而是把"网页画板/进度页"与"真实执行"焊起来:网页点一下 ▶️ → 云端会话真跑 → CSV 进度秒级回显。


二、n8n 到底强在哪(先拆到第一性)

n8n 的本质 = 5 层积木,逐层对标才不糊:

#n8n 能力层它解决什么
T触发层 Trigger定时(Schedule)、webhook、邮件到达、手动
I集成层 Integrations上千插件节点 + OAuth 凭据保管箱(Gmail/Sheets/Slack…)
L逻辑层 Logic节点连线、分支、聚合、循环、数据在节点间传递
AAI 层 AI nodes接大模型 API 做总结/判断,双向 MCP
P持久层 PersistenceSQLite/Postgres 存工作流与执行历史;JSON 导入导出分享

外加一层体验:可视化拖拽编辑器 = 编辑器和执行引擎是同一个东西(画完点 Execute 立即真跑、每个节点亮绿灯看数据)。


三、逐层对标:手机 + Claude Code + 你的 batch 项目,现在能做到什么

T 触发层 —— 能做到 70%

n8n 能力手机上的等价物现状
手动触发对 Claude Code 说一句口令(zj/ua/flowrun/批量引擎)✅ 已有,甚至比 n8n 顺手(自然语言即触发)(E1)
Schedule 定时(如每4小时)Claude Code 的 Routines(定时任务):cron 表达式定时自动开会话干活,手机上一句话就能建,最小间隔 1 小时(E1:本会话环境自带该机制)✅ 可用但你的 batch 引擎还没接上——目前每次批量都要主席手动开会话
分钟级定时GitHub Actions 定时工作流(约5分钟级;仓库已在用 Actions 自动部署笔记本页)(E2)🟡 可做未做:适合"纯脚本可判定"的活
Webhook / 邮件到达即触发无常驻监听进程❌ 硬差距(见第四节 G1)

I 集成层 —— 能做到 40%,但换了路线

n8n 靠"上千现成插件+凭据保管箱";你这套的路线是"云端容器里有完整 Linux + 网络,任何有 API 的服务都能用脚本打",等于把"插件"变成"随写随有的处理器":

L 逻辑层(多步编排)—— 能做到 90%,且质量上限更高

A AI 层 —— 反超 n8n

n8n 的 AI 节点=调一次 API 填个 prompt;你这边每个"AI 节点"是带工具、带文件系统、带红队/验收纪律的完整 agent。这层不是差距,是你的护城河。 双向 MCP:作为 MCP client,claude.ai 的连接器可接外部服务(E2);作为 MCP server 把自家工作流暴露给外部 AI 调用——未做(G6,优先级不高)。

P 持久层 —— 已解决,且优于 n8n 默认

体验层(编辑器=执行引擎)—— 这是你项目最大的"两层皮"

n8n:画完点 Execute,同一个页面看节点逐个亮绿。

你现在:画板(flow-board/flow-canvas)负责"画",执行靠把 FlowText 粘给 Claude 会话,进度页(batch)负责"看"——三件套没有焊死,中间靠主席人肉搬运。这不是能力缺失,是闭环缺失,也是升级路线的头号目标。


四、差距清单(诚实版,按痛的程度排)

#差距痛度有没有绕法
G1无常驻 webhook/事件触发:n8n 能 7×24 监听"邮件到了/表单提交了/价格破位了"秒级开跑;Claude 会话是临时容器,最小定时 1 小时🔴有:Cloudflare Worker 收 webhook → 写入仓库队列 → 定时 Routine 消费(延迟=轮询间隔);分钟级用 GitHub Actions
G2无 OAuth 凭据保管箱:上千 SaaS 深度集成(Gmail/Sheets/Notion)n8n 点几下授权就通🟠部分:优先选"纯 API key"服务(Resend/Telegram Bot/Notion API),key 存私有仓库(现行做法);OAuth 类用 claude.ai 连接器顶一部分
G3画板→执行→进度 三层皮:网页不能点"▶️ 运行",要人肉粘 FlowText🟠完全可修(见升级 U1,这是自家问题不是平台限制)
G4确定性与成本:agent 步骤贵且有漂移;n8n 跑一千次一分钱不花🟡结构性绕法已在设计里:能脚本化的写成 HANDLERS 脚本处理器,agent 只做判断类步骤
G5无逐节点执行回放:排错靠翻会话记录🟡可修:workspace 里统一落 run-<时间>/step-N.md 即得 80%
G6MCP server 化未做:自家工作流不能被外部 AI 客户端远程调用🟢可做但非刚需(你自己就是最大用户)

总评:六大层里,真正被平台卡死的只有 G1 的"秒级"部分和 G2 的 OAuth 部分;其余全是自家工程可解。


五、升级路线(按性价比排序,每条都给"最小可用版")

U1 🔴 头号升级:把"网页 ▶️ 按钮"焊到真实执行上(补 G3)

U2 🔴 给 batch 引擎接上定时触发(补 T 层)

U3 🟠 Webhook 入口(补 G1)

U4 🟠 自家"插件库"按需生长(补 G2 的 80%)

U5 🟡 执行历史可回放(补 G5)

U6 🟢 锦上添花:模板一键化 + MCP server

手机工具的分工建议(现有订阅的最优阵型)


六、红队自审(Rex,≥1 条最强反对)

1. 最强反对:「你这是拿轮询冒充事件驱动,别自欺」——成立。G1 的绕法延迟=分钟到小时级,永远不是 n8n 的秒级 webhook。回应:主席的真实工作负载(研究/简报/批量分析/内容生产)全部是"分钟级延迟无感"的;需要秒级的场景(交易触发)本就不应放进 LLM 工作流。已在 U3 里显式标注,不掩盖。

2. 反对:「n8n 免费跑一万次,你每次批量都烧订阅额度」——部分成立。回应:结构性对策=U4 把确定性步骤下沉为脚本处理器(跑脚本几乎不耗额度),agent 只做判断步;这正是 batch 引擎 demo/avatar 二分的本意,升级路线不改变这一点。

3. 反对:「再建一堆按钮/队列,会不会又是'建好却不用'」——警惕成立。回应:U1/U2 都绑定主席已经真实在跑的任务(META-FORECAST、市场简报、combo 批量),不是新造场景;上线判据=Routine 真实自动跑满一周且主席看过进度页。

七、本报告的可证伪锚


*支撑事实来源:batch/README.md、flow-* 画板与案例库页面、a129-flowrun 技能(均在仓库内可点验);Routines/Workflow 机制为本会话环境实测可见(E1);GitHub Actions 分钟级 cron 与 claude.ai 连接器为平台公开机制(E2)。*