LifeOS Arbol FLOWS 分支流程详解Flow 注册、条件路由、并行扇出与错误传播实战指南【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本文围绕 LifeOS 中CUSTOMIZATIONS/ARBOL/FLOWS目录的核心契约展开讲解 Flow 这一顶层编排原语如何把 Actions 与 Pipelines 组装成带条件路由、并行执行与错误处理的有向处理图。读完本文你将掌握flow-index.json注册机制、Flow YAML 定义结构、F_命名规范、Loop Gate 迭代与 Queue 生产-消费组合模式并能在自己的 LifeOS 安装中新增或覆盖一个分支流程。一、FLOWS 目录的本质什么是 LifeOS 中的 Flow在 LifeOS 的 Arbol 执行层中所有云端工作由三个可组合原语构成Actions动作→ Pipelines流水线→ Flows流程。FLOWS/README.md 给出了 Flow 的精确定位Purpose:Branching workflow definitions that compose actions into processing graphs with conditional routing, parallel execution, and error handling.Flow 是分支工作流定义——它把多个动作组合成处理图processing graph并具备三类 Pipelines 所没有的能力条件路由conditional routing根据上游输出决定下一步走哪个分支并行执行parallel execution分支可以扇出fan out再汇聚join错误处理error handling定义失败如何传播、是否重试。Flow 与 Pipeline 的选择标准在该 README 中写得非常直白Flow 是正确的工具当工作流需要决策、重试或并发步骤时Pipelines 只负责纯线性工作“先做 A再做 B再做 C”PIPELINES/README.md 中明确说明 Pipelines 没有分支、没有条件、没有并行扇出。可以这样记忆三个原语的分工见 ArbolSystem.mdAction --- Pipeline --- Flow (unit) (chain) (scheduled system)原语前缀做什么组合对象ActionA_单一工作单元LLM 调用、API 调用、shell 命令不组合PipelineP_通过管道模型按顺序串联动作ActionsFlowF_按调度把 数据源 → 管道 → 目的地 连接起来Pipelines需要说明的一点仓库中随发行版提供的是 FLOWS 的模板契约与注册机制实际的 Flow 执行层位于维护者私有运行的云端基础设施Cloudflare WorkersArbolSystem.md 将其称为 LifeOS 的云执行层并明确标注“Not included in the public LifeOS release”——它作为架构蓝图供你参考或自建。二、FLOWS 目录结构注册表 每流一个 YAML按 FLOWS/README.md 的说明FLOWS/目录中只放两类内容FLOWS/ ├── flow-index.json # 流程注册表 └── *.yaml # 每个 Flow 一个 YAML 定义文件flow-index.json全局注册表登记所有可用流程及其元信息每个 Flow 一个 YAML 文件描述该流程的有向图——动作之间的路由条件、并行分支在哪里扇出与汇聚、失败如何传播。从源码结构看这与ACTIONS/、PIPELINES/的模板是同一设计模式ACTIONS/目录“每个动作一个子目录含action.json清单与action.ts实现”见 ACTIONS/README.mdPIPELINES/目录“一个pipeline-index.json注册表 每个管道一个 YAML”见 PIPELINES/README.md。三个原语共享“注册表 定义文件”的组织哲学但注册表文件名不同flow-index.jsonvspipeline-index.json定义粒度也不同。目录的填充方式How it gets populatedREADME 给出了两条来源用户显式添加往目录里放一个 YAML并在flow-index.json中注册技能skills自带某些 LifeOS 技能会随安装携带自己的 Flow 定义。全新安装时的样本状态是空目录 / 仅有本 README。真正的 Flow 内容会随着你实际使用 LifeOS 逐渐出现。三、flow-index.json 注册表格式与字段解读ArbolSystem.md 给出了 Flow Registry 的完整 JSON 示例这是理解注册表字段最权威的素材{ flows: [ { id: flow-your-source-pipeline, name: Your Flow Name, source: { type: rss, url: https://example.com/feed }, pipeline: P_YOUR_PIPELINE, destination: { type: email, address: your-emailexample.com }, schedule: { intervalMinutes: 30, enabled: true } } ] }各字段的语义结合 README 的“Source → Pipeline → Destination”定位如下字段类型含义idstring流程唯一标识形如flow-source-pipelinenamestring流程的人类可读名称sourceobject数据源如{ type: rss, url: ... }也可以是 API 端点、webhookpipelinestring关联的 Pipeline 名称P_前缀destinationobject结果写往何处如{ type: email, address: ... }也可以是数据库、API、文件scheduleobject调度配置intervalMinutes运行间隔、enabled是否启用这与 Flow 的定义式ArbolSystem.md完全一致Source ──(schedule)── Pipeline ── Destination即Flow 不关心管道内部怎么做它只负责“何时schedule从哪取source、交给哪条管道pipeline、结果放哪destination”。四、Flow YAML 定义模板有向图、路由条件、并行与错误传播由于全新安装时 FLOWS 目录为空仓库没有内置的 Flow YAML 具体实例。下面这份模板是按 README 对“每个 yaml 描述有向图”的定义归纳而成的参考骨架非仓库现成文件帮助你理解一个分支流程定义文件应包含哪些要素# my-digest-flow.yaml name: F_BLOG_DIGEST description: 每日把博客新文章处理成摘要邮件并做质量评分路由 source: type: rss url: https://example.com/feed pipeline: P_EXTRACT_SUMMARIZE_RATE destination: type: email address: meexample.com schedule: intervalMinutes: 1440 # 每天一次 enabled: true graph: # 有向图动作节点 路由条件 nodes: - id: extract action: A_EXTRACT - id: summarize action: A_SUMMARIZE - id: rate action: A_RATE - id: notify_urgent action: A_SEND_EMAIL edges: # 边 路由条件条件路由 - from: extract to: summarize - from: summarize to: rate - from: rate to: notify_urgent when: rating high # 条件路由仅高分项继续 else: skip # 失败/不满足时的传播行为 parallel: # 并行扇出与汇聚 fan_out: [rate, archive] join_at: notify_urgent error_handling: max_retries: 3 on_failure: retry propagate: stop对照 README 的核心描述这份模板覆盖了 Flow YAML 应表达的四个维度动作的有向图directed graph of actionsnodesedges节点间的路由条件routing conditions边上的when/else并行分支的扇出与汇聚parallel fan-out and joinparallel.fan_out/parallel.join_at失败的传播方式how failures propagateerror_handling块。注意具体字段名取决于你采用的 Arbol 实现/蓝图上面模板的意图是演示“分支、并行、错误传播”这三类 Pipeline 不具备的能力如何在一个 YAML 中被表达。五、命名规范从 F_ 前缀到 Worker 名Flow 的命名规范见 ArbolSystem.md前缀F_对应 Action 的A_、Pipeline 的P_模式F_SOURCE_PIPELINE——“什么喂给什么”例如F_HN_LABEL_EMAILHN → 打分 → 邮件Worker 名arbol-f-{kebab-case-name}。仓库文档中的真实命名示例FeedSystem.md包括流程含义F_HN_LABEL_EMAILHackerNews 条目 → 打分 → 邮件F_YOUTUBE_DIGESTYouTube → 转写 → 打分 → 摘要F_SECURITY_ALERTS安全源 → 打分 → 紧急才通知F_SOCIAL_CONTENT高分内容 → 生成社媒帖 → 入队三个原语的 Worker 命名规则统一为arbol-{a|p|f}-{kebab-case-name}例如arbol-a-rate-article、arbol-p-example、arbol-f-example见 ArbolSystem.md。六、Flow 如何运行调度触发到目的地写入ArbolSystem.md 给出了 Flow 的完整执行链路共四步Cron 触发Cloudflare 按配置的间隔触发scheduled()处理器源拉取Flow Worker 从配置的数据源抓取内容管道执行每个源条目通过 service binding服务绑定送入管道 Worker写入目的地结果写往配置的目标数据库 / API / 文件。每个 Flow 还暴露两个 HTTP 端点用于人工干预GET /health——公开无需认证仅返回健康状态GET /trigger——需认证手动触发一次执行。在云端实现中Flow 依赖 Cloudflare 原生能力完成调度与组合ArbolSystem.mdCloudflare 特性用途Cron Triggers调度流程执行无需外部调度器Service BindingsWorker 间零跳转内部调用Secrets安全存放AUTH_TOKEN、API keyWorkers无服务器执行环境所有非 health 端点均要求Authorization: Bearer YOUR_AUTH_TOKENArbolSystem.md。七、新增一个 Flow 的完整操作步骤按 ArbolSystem.md 的“Creating a New Flow”流程如下在flow-index.json添加条目填入 source、pipeline、destination、schedule见第三节 JSON 示例确保引用的 Pipeline 已部署Flow 通过 service binding 调用管道管道不存在会导致绑定失败创建 Worker 目录包含wrangler.jsonccron 触发器 service bindings与src/index.ts部署bash deploy.sh f-your-flow。部署顺序必须自底向上因为每层依赖下一层ArbolSystem.md1. Actions (无依赖) 2. Pipelines (通过 service bindings 依赖 actions) 3. Flows (通过 service bindings cron triggers 依赖 pipelines)提醒该小节命令属于维护者私有云环境~/.claude/LIFEOS/USER/CUSTOMIZATIONS/ARBOL仓库公开发行版中不含这些本地运行器请以自己部署的 Arbol 蓝图为准。调度配置Cron 语法速查云端 Flow 使用标准 5 段 cronArbolSystem.md表达式调度*/5 * * * *每 5 分钟0 */6 * * *每 6 小时0 9 * * 1-5工作日周一至周五UTC 9:000 0 * * *每日 UTC 午夜八、进阶模式一Loop Gate——让 Flow 循环直到达标Flow 还有一个 Pipeline 不具备的能力迭代。规则非常明确ArbolSystem.mdPipelines 不循环管道跑完一次动作链就返回Flows 控制迭代for 循环与退出条件写在 Flow Worker 里永远设置maxIterations没有上限失败的退出条件会造成死循环退出条件要简单检查结果上的某个字段——分数、布尔值、状态字符串。工作原理Flow 调用管道 → 检查输出是否满足退出条件 → 满足则写入目的地不满足则携带更新后的输入再次调用 → 超过maxIterations强制终止。// 位于 Flow worker 的 scheduled() 处理器内部 const maxIterations 5; let result null; for (let i 0; i maxIterations; i) { const response await env.P_MY_PIPELINE.fetch( new Request(https://internal/, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${env.AUTH_TOKEN}, }, body: JSON.stringify({ content: input, previousResult: result, iteration: i, }), }) ); result await response.json(); if (result.qualityScore 8) { break; } } await writeToDestination(result);九、进阶模式二Queue Composition——Flow 连 Flow 的生产-消费模式当一个调度任务的子请求量超过 Cloudflare 单次调用 1000 次子请求上限时把单个 Flow 拆成生产者-消费者对ArbolSystem.md生产者 Flowcron 触发轮询数据源、去重KV、批量入队消费者 Flow队列触发每批处理一次message.ack()确认 /message.retry()重试。┌──────────────────────────┐ │ F_PRODUCER (cron) │ │ fetch sources │ │ dedup (KV) │ │ sendBatch() → queue │ └────────────┬─────────────┘ │ Cloudflare Queue ▼ ┌──────────────────────────┐ │ F_CONSUMER (queue) │ │ queue() handler │ │ extract → rate → write │ │ message.ack() / retry() │ └──────────────────────────┘关键规则队列连接的是 Flow不是 Action 或 PipelinesendBatch()单批最多 100 条消息生产端与消费端都要去重重试是逐消息的。仓库文档中的既有范例是F_FEEDS_POLLER生产者F_FEEDS_PROCESSOR消费者。十、用户优先解析顺序你的 Flow 覆盖系统 FlowFLOWS/位于USER/CUSTOMIZATIONS/ARBOL/之下这一点本身就有运行语义。CUSTOMIZATIONS/README.md 明确定义了解析契约Arbol 读取CUSTOMIZATIONS/ARBOL/获取用户的 actions、pipelines、flows 与 worker 代码。解析顺序永远个人优先CUSTOMIZATIONS/ARBOL/ACTIONS/name覆盖LIFEOS/ARBOL/Actions/namePIPELINES/与FLOWS/同理。用户的副本胜出。因此覆盖系统 Flow 或新增个人 Flow 的规则是一致的把你的定义放进ARBOL/FLOWS/并注册到flow-index.json运行时会优先选择你的版本。这也是为什么该目录被归类为Customizations行为覆盖层而非普通参考数据——它会改变 LifeOS 在该用户下的实际运行行为。目录结构总览CUSTOMIZATIONS/README.mdCUSTOMIZATIONS/ ├── SKILLS/ ← 每个被定制技能一个子目录的覆盖文件 └── ARBOL/ ← 用户 actions、pipelines、flows 与 worker 代码 ├── ACTIONS/ ├── PIPELINES/ ├── FLOWS/ └── (worker 代码Workers/, cli/, scripts/ 等)十一、Flow 运行异常排查要点ArbolSystem.md 提供了与 Flow 直接相关的排障清单症状排查方向Cron 不触发核对wrangler.jsonc中 cron 语法、确认scheduled方法已导出、查看 Cloudflare Dashboard → TriggersFlow 运行但无输出检查flow-state.json中的错误常见原因是管道输出格式错误、AUTH_TOKEN不匹配、Action Worker 缺 API keyService binding 错误目标 Worker 不存在或名称不匹配先部署被绑定的 Worker再部署绑定方401 未授权AUTH_TOKEN未设置或不一致成本考量Flow 配合 LLM 类 Action 会产生持续成本。文档给出的参考每 5 分钟间隔、每次 30 个条目约8,640 次 LLM 调用/天ArbolSystem.md。缓解手段拉长间隔30 分钟 6 倍削减、去重、质量过滤、对打分类任务使用更便宜的模型。十二、总结何时该写一个 Flow回到 FLOWS/README.md 的判断标准一句话即可决定工作纯线性A→B→C无条件、无并发→ 用Pipeline工作需要决策、重试或并发步骤条件路由、并行扇出/汇聚、错误处理→ 用Flow。而一个完整的 Flow 概念上等价于“给 Pipeline 加上调度、源与目的地并允许它按条件分支、并行与重试”。配合个人优先解析机制你在ARBOL/FLOWS/中维护的每一个 YAML 注册项都在把 LifeOS 的自动执行边界向你的个人工作流推进。参考文档仓库内路径FLOWS/README.md——本主题核心模板契约ACTIONS/README.md——Action 原子单元模板PIPELINES/README.md——Pipeline 线性链模板ArbolSystem.md——Arbol 云执行层权威文档Flow 注册表、Loop Gate、Queue 组合、部署、排障CUSTOMIZATIONS/README.md——用户覆盖层与个人优先解析契约FeedSystem.md——F_HN_LABEL_EMAIL、F_YOUTUBE_DIGEST等真实 Flow 命名示例【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考