LifeOS 管线PIPELINES完全指南用 YAML 编排顺序动作链构建可复用的线性工作流【免费下载链接】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 的 Arbol 执行层三大原语之一——Pipeline管线讲解它是什么、在 LifeOS 中处于什么位置、如何通过pipeline-index.json注册表与 YAML 定义文件组织顺序执行的动作链并与 ACTION原子动作和 FLOW分支流程划清边界。阅读完本文你将掌握在 LifeOS/install/USER/CUSTOMIZATIONS/ARBOL/PIPELINES/ 下从零声明一条可运行管线、理解其输入/输出契约与 Pipe 数据流模型并能结合仓库中的 PipelineOrchestrator.ts 看懂底层执行原理。一、PIPELINES 目录是什么LifeOS 中的线性工作流仓库在 LifeOS 的用户自定义树中ARBOL/PIPELINES/README.md 是这一目录的用途说明书。它的定位一句话即可概括顺序处理链Sequential processing chains——把多个动作Actions组合成线性工作流前一个动作的输出直接作为后一个动作的输入。这是整个 Arbol 执行层的最小组合单位之上的第一个组合层级。LifeOS 官方架构文档 ArbolSystem.md 给出了三大原语的完整层次Action --- Pipeline --- Flow (unit) (chain) (scheduled system)原语前缀作用组合对象Action动作A_单一工作单元一次 LLM 调用、一次 API 调用、一条 shell 命令无Pipeline管线P_通过 Pipe 模型按顺序串联动作ActionsFlow流程F_按调度把 来源 → 管线 → 目的地 连接起来Pipelines管线处于中间层它不关心数据从哪来、不关心何时运行那是 Flow 的职责只负责按顺序把一系列动作跑完。⚠️ 需要特别说明的是Arbol 云执行层本身是维护者私有的 Cloudflare Workers 基础设施ArbolSystem.md 明确声明其不随 OSS 版本发布属于参考文档与自建蓝图。但PIPELINES 目录本身位于公开的 install 树中且仓库 TOOLS 目录 内确实存在公开的本地管线编排实现PipelineOrchestrator.ts因此本文既讲公开模型也讲公开源码中的本地实现。二、目录内容一个注册表 每管线一个 YAML原文档明确了什么放在这里的约定一个pipeline-index.json注册表外加每条管线一个 YAML 文件。每条管线声明一组有序的动作列表以及它们之间的输入/输出契约。这构成了两个核心事实注册与定义分离pipeline-index.json负责登记有哪些管线可用YAML 文件负责描述这条管线具体怎么跑。新增一条管线 丢一个 YAML 文件进来 在注册表里登记一行。契约显式化管线定义必须写明每一步读什么、产出什么这使管线具备可验证性和可复用性也让 PipelineMonitor 之类的观测工具能按步跟踪。从公开源码 PipelineOrchestrator.ts 可以印证这套约定的落地形态它按{name}.pipeline.yaml的命名模式加载管线文件例如blog-review.pipeline.yaml、content-report.pipeline.yaml并用yaml库解析为结构化的 Pipeline 对象interface Step { id: string; action: string; input: Recordstring, unknown; } interface Pipeline { name: string; version: string; description: string; steps: Step[]; }注意这里的字段steps有序步骤、每步的id步骤标识、action动作名、input本步输入模板——这就是有序动作列表 输入/输出契约在代码层面的直接映射。一个可运行的管线 YAML 示例综合 ArbolSystem.md 的云格式与本地编排器的字段约定一条典型的管线定义长这样# 云格式Arbol 参考文档 name: P_MY_PIPELINE description: Processes items through enrichment and formatting actions: - A_PARSE - A_ENRICH - A_FORMAT# 本地编排器格式PipelineOrchestrator.ts 加载 name: blog-review version: 1.0 description: 提取内容 → 格式化 → 校验发布就绪 steps: - id: extract action: extract/article input: url: {{input.url}} - id: format action: format/markdown input: content: {{steps.extract.output.content}} - id: validate action: validate/publish input: body: {{steps.format.output.body}} minWords: {{input.minWords}}本地格式中有两个值得注意的机制均来自 PipelineOrchestrator.ts 源码模板插值{{input.xxx}}引用管线初始输入{{steps.stepId.output.xxx}}引用前面某一步的输出。源码中的interpolate()与resolvePath()实现了按点号路径取值、并在对象/数组上递归插值的能力步骤级上下文累积执行器维护一个context含input和steps每跑完一步就把该步输出写入context.steps[step.id]后续步骤可以引用任意先前步骤的结果而不只是上一步。三、为什么叫管线Pipe 模型与 Passthrough 模式原文档强调管线刻意比 FLOWS 简单——没有分支、没有条件、没有并行扇出。它的数据流模型是 Unix 风格的Pipe 模型Source -- Action 1 -- Action 2 -- Action 3 -- Destination | | | transform enrich format即动作 N 的输出成为动作 N1 的输入。这带来一个关键设计——Passthrough 模式透传每个动作接收上游数据时先保留所有既有字段再叠加自己的输出保证上下文在管线中累积而不是逐跳丢弃。参考文档给出了标准写法// Action receives upstream data, adds its own, passes everything forward const { content, ...upstream } input; return { ...upstream, // preserve all prior action output myField: result, // add this actions contribution };这意味着管线中最后一个动作能看到前面所有动作产出的全部字段。参考文档用A_EXTRACT_TRANSCRIPT → A_LABEL_AND_RATE举例抽取步骤产出content、video_id、title、source标注步骤除了产出自己的one_sentence_summary、labels、rating、quality_score还能读到透传下来的video_id与title。从源码实现看本地编排器对透传的承载方式是步骤级上下文每一步的输出被存入context.steps[stepId].output{{steps.xxx.output.yyy}}即可跨步骤访问效果与云管线的 passthrough 一致。四、与 FLOWS、ACTIONS 的边界什么时候用管线原文档给出的判定标准非常干脆如果任务是先做 A再做 B再做 C管线就是正确的形状。管线刻意比 FLOWS 简单——没有分支、没有条件、没有并行扇出。把三份同级模板并排看PIPELINES/README.md、FLOWS/README.md、ACTIONS/README.md选择逻辑一目了然场景用什么原因一步操作、无依赖ACTION原子单元单一输入输出如给一段文字打分多步顺序衔接、数据单向流动PIPELINE有序链 Passthrough 累积如抽取→摘要→评分需要决策、重试、并发、调度、来源→目的地FLOW有向图 条件路由 并行分叉/汇合 错误处理 cron 调度参考文档补充了 Action vs Pipeline 的对比表判据ActionPipeline步骤数12依赖无顺序依赖数据模型单一输入/输出Passthrough 累积复用性高可组合编排层还有一个重要的运行时边界管线永远只跑一次run-once。如果需要迭代例如结果必须达到某个质量分才通过迭代逻辑归 Flow 负责——参考文档称之为Loop Gate 模式Flow 反复调用管线直到输出满足退出条件并以maxIterations防止死循环。也就是说循环是 Flow 的职责管线本身绝不自循环。五、如何填充用户显式添加或由技能自带原文档说明了目录的两种填充方式由用户显式添加或由携带自身管线定义的技能skills填充。新增管线 丢一个 YAML 文件进本目录并在pipeline-index.json中登记。在本地执行路径上参考文档给出了创建新管线的五步流程梳理工作流确认有哪些动作可用、需要新建什么、各步骤之间传递什么数据创建目录mkdir -p ~/.claude/LIFEOS/ARBOL/Pipelines/[Domain]_[Pipeline-Name]云侧或按本地编排器约定放置{name}.pipeline.yaml定义总览表在 PIPELINE.md 中列出 Step / Action / Purpose 对照表逐步骤明确契约指定动作、上游输入字段、本步输出字段云部署创建 Worker通过 service bindings 绑定到每个动作。仓库中的本地编排器还提供了一条零部署的本地运行路径适合开发与验证# 运行指定管线可传 JSON 输入并指定 agent 名称 bun PipelineOrchestrator.ts run blog-review --input {content: # Hello, minWords: 50} bun PipelineOrchestrator.ts run research --topic AI agents --depth 3 bun PipelineOrchestrator.ts run youtube-knowledge --url https://youtube.com/... --domain security # 列出用法帮助 bun PipelineOrchestrator.ts # 演示模式并行运行多条管线blog-review / content-report / blog-qa bun PipelineOrchestrator.ts demo运行时会向MONITOR_URL默认http://localhost:8765上报/api/start、/api/step、/api/update进度事件便于 PipelineMonitor 可视化跟踪监测器未启动时上报静默失败不影响管线本体执行。六、底层执行原理源码级的顺序执行语义PipelineOrchestrator.ts 完整展示了本地管线的执行循环可作为理解顺序链语义的最佳源码样本加载loadPipeline(name)读取PIPELINES_DIR/{name}.pipeline.yaml并解析上报开始reportStart(agent, pipelineName, steps)向监测器登记本次执行初始化上下文context { input, steps: {} }顺序遍历 stepsfor (const step of pipeline.steps)用interpolate(step.input, context)把{{...}}模板解析为真实输入按action.split(/)得到分类与名称从ACTIONS_DIR/{category}/{name}.action.ts动态导入动作模块用动作的inputSchema.parse(input)做输入校验执行action.execute(parsedInput, { mode: local })再用outputSchema.parse(output)做输出校验成功则写入context.steps[step.id]并上报 completed失败则上报 failed 并立即中止整条管线返回{ success: false, error }——这正是顺序链的严格语义任何一步失败后续步骤不再执行汇总全部成功后返回{ steps: context.steps }作为最终结果。这里可以看到管线在工程上的两个核心属性Schema 校验贯穿每一步输入/输出都有 Zod 风格 schema 把关以及失败即中止fail-fast。这与参考文档中动作的最佳实践Fail Fast——立即校验输入抛出清晰错误完全一致。七、命名与部署约定命名约定来自 ArbolSystem.md 的 Primitive 表与 Worker 命名表管线前缀P_UPPER_SNAKE_CASEWorker 名arbol-p-{kebab-case-name}例如arbol-p-example本地目录~/.claude/LIFEOS/ARBOL/Pipelines/[Domain]_[Pipeline-Name]/PIPELINE.md。云部署遵循自底向上的顺序——先部署 Actions无依赖再部署 Pipelines通过 service bindings 依赖 Actions最后部署 Flows依赖 Pipelines cron 触发器。本地模式与云模式共享同一套 Passthrough 数据流模型区别仅在运行时bun vs Cloudflare Workers、调度手动 vs cron与认证本地直通 vs Bearer token。八、管线最佳实践速查综合原文档定位与参考文档的 Best Practices 章节保持步骤原子性每一步只做一件事便于测试与复用善用 Passthrough始终展开...upstream让下游动作拿到前面所有步骤的字段文档化数据流为每个动作写明读什么、产出什么这正是管线输入/输出契约的落地方式保持动作可复用动作不应与特定管线强耦合管线不循环迭代与重试交给 FlowLoop Gate 模式管线只负责单次顺序执行。九、全新安装的初始状态原文档最后明确全新安装时该目录为空或仅含本 README真实内容会随你使用 LifeOS 逐步产生——这正体现了 CUSTOMIZATIONS 树的由用户驱动哲学框架不预设你的管线只提供约定的存放位置、注册机制与执行引擎等你把抽取→增强→格式化这类线性工作流沉淀成可复用的 YAML 定义。参考文件索引PIPELINES 目录说明本文主文档FLOWS 目录说明对比分支流程ACTIONS 目录说明对比原子动作Arbol 执行层权威架构文档Pipe 模型、三大原语、Loop Gate、部署PipelineOrchestrator.ts本地管线编排器源码实现LifeosSystemArchitecture.md系统架构中的三原语描述【免费下载链接】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），仅供参考 LifeOS 管线（PIPELINES）完全指南：用 YAML 编排顺序动作链，构建可复用的线性工作流
LifeOS 管线PIPELINES完全指南用 YAML 编排顺序动作链构建可复用的线性工作流【免费下载链接】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 的 Arbol 执行层三大原语之一——Pipeline管线讲解它是什么、在 LifeOS 中处于什么位置、如何通过pipeline-index.json注册表与 YAML 定义文件组织顺序执行的动作链并与 ACTION原子动作和 FLOW分支流程划清边界。阅读完本文你将掌握在 LifeOS/install/USER/CUSTOMIZATIONS/ARBOL/PIPELINES/ 下从零声明一条可运行管线、理解其输入/输出契约与 Pipe 数据流模型并能结合仓库中的 PipelineOrchestrator.ts 看懂底层执行原理。一、PIPELINES 目录是什么LifeOS 中的线性工作流仓库在 LifeOS 的用户自定义树中ARBOL/PIPELINES/README.md 是这一目录的用途说明书。它的定位一句话即可概括顺序处理链Sequential processing chains——把多个动作Actions组合成线性工作流前一个动作的输出直接作为后一个动作的输入。这是整个 Arbol 执行层的最小组合单位之上的第一个组合层级。LifeOS 官方架构文档 ArbolSystem.md 给出了三大原语的完整层次Action --- Pipeline --- Flow (unit) (chain) (scheduled system)原语前缀作用组合对象Action动作A_单一工作单元一次 LLM 调用、一次 API 调用、一条 shell 命令无Pipeline管线P_通过 Pipe 模型按顺序串联动作ActionsFlow流程F_按调度把 来源 → 管线 → 目的地 连接起来Pipelines管线处于中间层它不关心数据从哪来、不关心何时运行那是 Flow 的职责只负责按顺序把一系列动作跑完。⚠️ 需要特别说明的是Arbol 云执行层本身是维护者私有的 Cloudflare Workers 基础设施ArbolSystem.md 明确声明其不随 OSS 版本发布属于参考文档与自建蓝图。但PIPELINES 目录本身位于公开的 install 树中且仓库 TOOLS 目录 内确实存在公开的本地管线编排实现PipelineOrchestrator.ts因此本文既讲公开模型也讲公开源码中的本地实现。二、目录内容一个注册表 每管线一个 YAML原文档明确了什么放在这里的约定一个pipeline-index.json注册表外加每条管线一个 YAML 文件。每条管线声明一组有序的动作列表以及它们之间的输入/输出契约。这构成了两个核心事实注册与定义分离pipeline-index.json负责登记有哪些管线可用YAML 文件负责描述这条管线具体怎么跑。新增一条管线 丢一个 YAML 文件进来 在注册表里登记一行。契约显式化管线定义必须写明每一步读什么、产出什么这使管线具备可验证性和可复用性也让 PipelineMonitor 之类的观测工具能按步跟踪。从公开源码 PipelineOrchestrator.ts 可以印证这套约定的落地形态它按{name}.pipeline.yaml的命名模式加载管线文件例如blog-review.pipeline.yaml、content-report.pipeline.yaml并用yaml库解析为结构化的 Pipeline 对象interface Step { id: string; action: string; input: Recordstring, unknown; } interface Pipeline { name: string; version: string; description: string; steps: Step[]; }注意这里的字段steps有序步骤、每步的id步骤标识、action动作名、input本步输入模板——这就是有序动作列表 输入/输出契约在代码层面的直接映射。一个可运行的管线 YAML 示例综合 ArbolSystem.md 的云格式与本地编排器的字段约定一条典型的管线定义长这样# 云格式Arbol 参考文档 name: P_MY_PIPELINE description: Processes items through enrichment and formatting actions: - A_PARSE - A_ENRICH - A_FORMAT# 本地编排器格式PipelineOrchestrator.ts 加载 name: blog-review version: 1.0 description: 提取内容 → 格式化 → 校验发布就绪 steps: - id: extract action: extract/article input: url: {{input.url}} - id: format action: format/markdown input: content: {{steps.extract.output.content}} - id: validate action: validate/publish input: body: {{steps.format.output.body}} minWords: {{input.minWords}}本地格式中有两个值得注意的机制均来自 PipelineOrchestrator.ts 源码模板插值{{input.xxx}}引用管线初始输入{{steps.stepId.output.xxx}}引用前面某一步的输出。源码中的interpolate()与resolvePath()实现了按点号路径取值、并在对象/数组上递归插值的能力步骤级上下文累积执行器维护一个context含input和steps每跑完一步就把该步输出写入context.steps[step.id]后续步骤可以引用任意先前步骤的结果而不只是上一步。三、为什么叫管线Pipe 模型与 Passthrough 模式原文档强调管线刻意比 FLOWS 简单——没有分支、没有条件、没有并行扇出。它的数据流模型是 Unix 风格的Pipe 模型Source -- Action 1 -- Action 2 -- Action 3 -- Destination | | | transform enrich format即动作 N 的输出成为动作 N1 的输入。这带来一个关键设计——Passthrough 模式透传每个动作接收上游数据时先保留所有既有字段再叠加自己的输出保证上下文在管线中累积而不是逐跳丢弃。参考文档给出了标准写法// Action receives upstream data, adds its own, passes everything forward const { content, ...upstream } input; return { ...upstream, // preserve all prior action output myField: result, // add this actions contribution };这意味着管线中最后一个动作能看到前面所有动作产出的全部字段。参考文档用A_EXTRACT_TRANSCRIPT → A_LABEL_AND_RATE举例抽取步骤产出content、video_id、title、source标注步骤除了产出自己的one_sentence_summary、labels、rating、quality_score还能读到透传下来的video_id与title。从源码实现看本地编排器对透传的承载方式是步骤级上下文每一步的输出被存入context.steps[stepId].output{{steps.xxx.output.yyy}}即可跨步骤访问效果与云管线的 passthrough 一致。四、与 FLOWS、ACTIONS 的边界什么时候用管线原文档给出的判定标准非常干脆如果任务是先做 A再做 B再做 C管线就是正确的形状。管线刻意比 FLOWS 简单——没有分支、没有条件、没有并行扇出。把三份同级模板并排看PIPELINES/README.md、FLOWS/README.md、ACTIONS/README.md选择逻辑一目了然场景用什么原因一步操作、无依赖ACTION原子单元单一输入输出如给一段文字打分多步顺序衔接、数据单向流动PIPELINE有序链 Passthrough 累积如抽取→摘要→评分需要决策、重试、并发、调度、来源→目的地FLOW有向图 条件路由 并行分叉/汇合 错误处理 cron 调度参考文档补充了 Action vs Pipeline 的对比表判据ActionPipeline步骤数12依赖无顺序依赖数据模型单一输入/输出Passthrough 累积复用性高可组合编排层还有一个重要的运行时边界管线永远只跑一次run-once。如果需要迭代例如结果必须达到某个质量分才通过迭代逻辑归 Flow 负责——参考文档称之为Loop Gate 模式Flow 反复调用管线直到输出满足退出条件并以maxIterations防止死循环。也就是说循环是 Flow 的职责管线本身绝不自循环。五、如何填充用户显式添加或由技能自带原文档说明了目录的两种填充方式由用户显式添加或由携带自身管线定义的技能skills填充。新增管线 丢一个 YAML 文件进本目录并在pipeline-index.json中登记。在本地执行路径上参考文档给出了创建新管线的五步流程梳理工作流确认有哪些动作可用、需要新建什么、各步骤之间传递什么数据创建目录mkdir -p ~/.claude/LIFEOS/ARBOL/Pipelines/[Domain]_[Pipeline-Name]云侧或按本地编排器约定放置{name}.pipeline.yaml定义总览表在 PIPELINE.md 中列出 Step / Action / Purpose 对照表逐步骤明确契约指定动作、上游输入字段、本步输出字段云部署创建 Worker通过 service bindings 绑定到每个动作。仓库中的本地编排器还提供了一条零部署的本地运行路径适合开发与验证# 运行指定管线可传 JSON 输入并指定 agent 名称 bun PipelineOrchestrator.ts run blog-review --input {content: # Hello, minWords: 50} bun PipelineOrchestrator.ts run research --topic AI agents --depth 3 bun PipelineOrchestrator.ts run youtube-knowledge --url https://youtube.com/... --domain security # 列出用法帮助 bun PipelineOrchestrator.ts # 演示模式并行运行多条管线blog-review / content-report / blog-qa bun PipelineOrchestrator.ts demo运行时会向MONITOR_URL默认http://localhost:8765上报/api/start、/api/step、/api/update进度事件便于 PipelineMonitor 可视化跟踪监测器未启动时上报静默失败不影响管线本体执行。六、底层执行原理源码级的顺序执行语义PipelineOrchestrator.ts 完整展示了本地管线的执行循环可作为理解顺序链语义的最佳源码样本加载loadPipeline(name)读取PIPELINES_DIR/{name}.pipeline.yaml并解析上报开始reportStart(agent, pipelineName, steps)向监测器登记本次执行初始化上下文context { input, steps: {} }顺序遍历 stepsfor (const step of pipeline.steps)用interpolate(step.input, context)把{{...}}模板解析为真实输入按action.split(/)得到分类与名称从ACTIONS_DIR/{category}/{name}.action.ts动态导入动作模块用动作的inputSchema.parse(input)做输入校验执行action.execute(parsedInput, { mode: local })再用outputSchema.parse(output)做输出校验成功则写入context.steps[step.id]并上报 completed失败则上报 failed 并立即中止整条管线返回{ success: false, error }——这正是顺序链的严格语义任何一步失败后续步骤不再执行汇总全部成功后返回{ steps: context.steps }作为最终结果。这里可以看到管线在工程上的两个核心属性Schema 校验贯穿每一步输入/输出都有 Zod 风格 schema 把关以及失败即中止fail-fast。这与参考文档中动作的最佳实践Fail Fast——立即校验输入抛出清晰错误完全一致。七、命名与部署约定命名约定来自 ArbolSystem.md 的 Primitive 表与 Worker 命名表管线前缀P_UPPER_SNAKE_CASEWorker 名arbol-p-{kebab-case-name}例如arbol-p-example本地目录~/.claude/LIFEOS/ARBOL/Pipelines/[Domain]_[Pipeline-Name]/PIPELINE.md。云部署遵循自底向上的顺序——先部署 Actions无依赖再部署 Pipelines通过 service bindings 依赖 Actions最后部署 Flows依赖 Pipelines cron 触发器。本地模式与云模式共享同一套 Passthrough 数据流模型区别仅在运行时bun vs Cloudflare Workers、调度手动 vs cron与认证本地直通 vs Bearer token。八、管线最佳实践速查综合原文档定位与参考文档的 Best Practices 章节保持步骤原子性每一步只做一件事便于测试与复用善用 Passthrough始终展开...upstream让下游动作拿到前面所有步骤的字段文档化数据流为每个动作写明读什么、产出什么这正是管线输入/输出契约的落地方式保持动作可复用动作不应与特定管线强耦合管线不循环迭代与重试交给 FlowLoop Gate 模式管线只负责单次顺序执行。九、全新安装的初始状态原文档最后明确全新安装时该目录为空或仅含本 README真实内容会随你使用 LifeOS 逐步产生——这正体现了 CUSTOMIZATIONS 树的由用户驱动哲学框架不预设你的管线只提供约定的存放位置、注册机制与执行引擎等你把抽取→增强→格式化这类线性工作流沉淀成可复用的 YAML 定义。参考文件索引PIPELINES 目录说明本文主文档FLOWS 目录说明对比分支流程ACTIONS 目录说明对比原子动作Arbol 执行层权威架构文档Pipe 模型、三大原语、Loop Gate、部署PipelineOrchestrator.ts本地管线编排器源码实现LifeosSystemArchitecture.md系统架构中的三原语描述【免费下载链接】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），仅供参考