LifeOS 命令行工具详解：Arbol CLI、Runner 与管道式 Action 组合模型

LifeOS 命令行工具详解Arbol CLI、Runner 与管道式 Action 组合模型【免费下载链接】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/LifeOSLifeOS 坚持 CLI-first 架构哲学让山丘攀升hill-climb的每一步都变成可以脚本化、可测试、可信任的代码由提示词prompt负责编排、由代码负责执行。本文以官方文档 Cli.md 为主体完整讲解 LifeOS 本地执行层提供的三层命令行工具——统一 CLIpai、低层 Runner 与 Pipeline Runner——的使用方法、输入/输出契约与 UNIX 风格管道组合模型并结合仓库中的 install.sh、ArbolSystem.md 与 CliFirstArchitecture.md 等文件说明这套 CLI 栈的适用边界与底层设计依据。读完本文你可以掌握如何在本地运行 Arbol Actions 与 Pipelines、如何在 Action 之间用管道串联 JSON 数据流以及如何理解公开版与私有版在 CLI 能力上的差异。一、先说清楚适用范围公开版不包含本地 Arbol CLI 树在深入命令之前必须先明确一个关键边界这也是原文档用醒目提示反复强调的本地 Arbol CLI 树不在公开发布包中。LIFEOS/ARBOL/包含Actions/、Flows/、Pipelines/三个子目录在 rsync 发布流程中被排除因此在公开安装后~/.claude/LIFEOS/ARBOL/...下的路径与命令实际不存在。Arbol 的模型——三个原语Action / Pipeline / Flow、管道模型、云端 Workers——是公开的本地 runner 树则不公开。仓库中这一事实有源码级佐证install.sh 在 386 行附近的注释明确写道维护者侧的 Arbol CLI 别名ARBOL/Actions/lifeos.ts并不随公开 payload 分发not shipped in the public payload。也就是说本文后半部分的所有~/.claude/LIFEOS/ARBOL/...命令描述的是 LifeOS 私有部署形态公开安装的用户能拿到的是模型与文档而非可执行的本地 runner 树。同时文档还记录了一次重要的能力收缩原 Algorithm CLILIFEOS/TOOLS/algorithm.ts现已删除已于 2026-07-14 随 phase-machinery 深度剥离而退役——Algorithm 现在在会话内针对 ISA 运行不再有独立 runner。这条变更说明 LifeOS 的 CLI 面在持续收敛只保留值得做成确定性命令的能力。这一取舍原则出自 CliFirstArchitecture.md 中的判断标准如果你会再次想要完全相同的行为并且需要信任它就把它做成命令如果只是一个问一次的问题就直接问。二、三层 CLI 栈总览LifeOS 的本地执行层提供三个由浅入深的命令行入口全部以bun为运行时工具用途命令入口Arbol CLIpai运行 action 与 pipeline 的统一接口bun ACTIONS/lifeos.ts action nameRunner低层 action 执行引擎bun ACTIONS/lib/runner.v2.ts run actionPipeline Runner通过 YAML 定义串联 actionsbun ACTIONS/lib/pipeline-runner.ts run pipeline三者的关系是pai是面向人的统一门面runner.v2.ts是底层执行引擎pai与 pipeline runner 共用它pipeline-runner.ts则在其之上加载 YAML 编排定义、按序串联 actions。三、Arbol CLIpai统一接口详解位置~/.claude/LIFEOS/ARBOL/Actions/lifeos.tsArbol CLI命令别名pai提供运行 actions 与 pipelines 的统一接口支持三种输入方式参数 JSON、stdin 管道、具名参数并支持 UNIX 风格的 action 组合。快速上手cd ~/.claude/LIFEOS/ARBOL/Actions # 用内联 JSON 运行一个 action bun lifeos.ts action A_EXAMPLE_SUMMARIZE --input {content: Your text here} # 把 JSON 通过管道送入 action echo {content: Your text} | bun lifeos.ts action A_EXAMPLE_SUMMARIZE # 列出所有可用 actions bun lifeos.ts actions # 列出所有可用 pipelines bun lifeos.ts pipelines # 查看 action 详情 bun lifeos.ts info A_EXAMPLE_SUMMARIZE命令结构pai action name [--input json] Run an action pai pipeline name [--param value] Run a pipeline pai actions List all actions pai pipelines List all pipelines pai info name Show action/pipeline details选项Options选项缩写说明默认值--mode—执行模式local或cloudlocal--input—以 JSON 字符串形式提供输入—--verbose-v显示执行细节耗时、输入/输出off其中--mode的local/cloud双模设计与 ArbolSystem.md 中的 Execution Modes 章节一致同一套 actions、pipelines、flows 可以在本地bunrunner.v2.ts手动触发或云端Cloudflare WorkersCron 触发运行无需改代码。三种输入方式及其优先级Actions 接受三种输入方式按优先级从高到低解析action 只取第一个命中的来源Stdin 管道——echo {content:text} | bun lifeos.ts action A_EXAMPLE_SUMMARIZE用于链式组合--input标志——bun lifeos.ts action A_EXAMPLE_SUMMARIZE --input {content:text}用于脚本化的单次调用具名参数——bun lifeos.ts action A_EXAMPLE_SUMMARIZE --content text人工输入时最易读原文档给出的选择建议很实用组合compose时用 stdin脚本里单次调用用--input人直接敲命令用具名参数。Action 组合管道模型Arbol CLI 把 JSON 写到 stdout从而支持 UNIX 风格的 action 间管道# 先总结再格式化结果 bun lifeos.ts action A_EXAMPLE_SUMMARIZE --input {content: Long text...} \ | bun lifeos.ts action A_EXAMPLE_FORMAT这正是 pipeline 内部使用的管道模型——上一个 action 的输出成为下一个 action 的输入。透传passthrough模式...upstream字段保证元数据能贯穿整条链。关于管道模型的完整定义可参阅 ArbolSystem.md透传模式的写法是const { content, ...upstream } input;然后return { ...upstream, myField: result };——保留所有前置 action 的输出、再叠加自己的贡献。其效果是pipeline 中最后一个 action 能看到每一个前置 action 产生的字段而不仅是紧邻的上一跳。详细模式Verbose-v把执行细节写到stderrstdout 保持干净便于管道bun lifeos.ts action A_EXAMPLE_SUMMARIZE --input {content: test} -v # [pai] Running action: A_EXAMPLE_SUMMARIZE # [pai] Mode: local # [pai] Input: {content:test} # [pai] Duration: 1234ms # {summary:...,word_count:42}这个诊断信息走 stderr、结果走 stdout的分离正是 LifeOS 全系统通用的 CLI 设计约定——例如 Tools.md 中描述的Inference.ts也是同样的做法模型降级提示[model] requested… → executed…打印到 stderrstdout 只保留纯净的答案。四、Arbol Runner低层执行引擎位置~/.claude/LIFEOS/ARBOL/Actions/lib/runner.v2.tsRunner 是paiCLI 与 pipeline runner 共用的底层引擎也可以直接调用cd ~/.claude/LIFEOS/ARBOL/Actions # 运行一个 action输入为 JSON 参数 bun lib/runner.v2.ts run A_EXAMPLE_SUMMARIZE {content: Your text here} # 列出所有已注册的 actions bun lib/runner.v2.ts list响应格式{ success: true, output: { summary: The text discusses..., word_count: 42 }, metadata: { durationMs: 1234, action: A_EXAMPLE_SUMMARIZE, version: 1.0.0 } }响应契约是三段式的success布尔值、outputaction 的业务输出、metadata耗时、action 名、版本。云端部署的 worker 也使用同构的信封success/action/duration_ms/output这让同一个 action 在本地 runner 与 Cloudflare Worker 之间的行为可以无缝对等。五、Pipeline RunnerYAML 驱动的 Action 串联位置~/.claude/LIFEOS/ARBOL/Actions/lib/pipeline-runner.tsPipeline runner 加载 YAML pipeline 定义按序串联 actionscd ~/.claude/LIFEOS/ARBOL/Actions # 用具名参数运行 pipeline bun lib/pipeline-runner.ts run P_EXAMPLE_SUMMARIZE_AND_FORMAT --content Your text here # 列出所有 pipelines bun lib/pipeline-runner.ts listPipeline YAML 格式name: P_EXAMPLE_SUMMARIZE_AND_FORMAT description: Summarizes text and formats the result as structured markdown. actions: - A_EXAMPLE_SUMMARIZE - A_EXAMPLE_FORMATRunner 把数据按序穿过每个 actionaction N 的输出成为 action N1 的输入。注意一个边界规则与 ArbolSystem.md 的 Loop Gate 章节一致pipeline 永远只跑一遍如果需要迭代直到满足退出条件循环逻辑属于上层 Flow 的职责pipeline 自身不迭代。两级 Action 解析Two-Tier ResolutionRunner 与 pipeline runner 都按以下优先级在两个位置查找 actionsLIFEOS/USER/CUSTOMIZATIONS/ARBOL/ACTIONS/—— 个人 actions覆盖系统 actionsLIFEOS/ARBOL/Actions/—— 系统/框架 actions含示例Pipelines 同理LIFEOS/USER/CUSTOMIZATIONS/ARBOL/PIPELINES/—— 个人 pipelinesLIFEOS/ARBOL/Pipelines/—— 系统/框架 pipelines公开仓库中确实存在用户侧的定制目录 USER/CUSTOMIZATIONS/ARBOL这正是个人层覆盖系统层这一解析策略的落点你可以在 USER 树下创建个人 actions 与 pipelines去扩展或覆盖内置示例而无需触碰系统目录。六、Shell 别名配置为便于日常使用可以在 shell 配置.zshrc、.bashrc中添加别名# The Arbol CLI alias paibun ~/.claude/LIFEOS/ARBOL/Actions/lifeos.ts # Runners可选——pai CLI 已封装它们 alias arbol-runbun ~/.claude/LIFEOS/Actions/lifeos.ts/../lifeos.ts 2/dev/null || alias arbol-runbun ~/.claude/LIFEOS/ARBOL/Actions/lib/runner.v2.ts alias arbol-pipebun ~/.claude/LIFEOS/ARBOL/Actions/lib/pipeline-runner.ts然后直接使用pai action A_EXAMPLE_SUMMARIZE --input {content: text} pai actions前两行为原文档给出的原始别名此处按原文保留意图pai指向统一 CLIarbol-run/arbol-pipe分别直通两个 runner。七、实战示例把任务变成命令而不是提示词一个任务用命令而非 prompt 执行假设你想总结一段文本并把结果格式化。可以请求模型总结并格式化但每次得到的结构可能略有不同或者把它作为两个确定性 action 用管道串起来echo {content: Long text...} \ | bun lifeos.ts action A_EXAMPLE_SUMMARIZE \ | bun lifeos.ts action A_EXAMPLE_FORMATSummarize action 把 JSON 写到 stdout这段 JSON 就是 format action 的 stdin。同样的输入、同样的命令、同样的输出形状——每次运行都是如此。步骤之间的管道plumbing是代码而不是 prompt因此它可以被脚本化、被测试、原封不动地放进 pipeline。模型在 action 内部完成语言工作CLI 拥有线路wiring的所有权。输入解析与输出流动由于每个 action 都读 JSON、写 JSONactions 像 UNIX 工具一样可以组合——两个 action 之间的箭头就是一条管道。这就是 CLI 成为确定性骨架的原因prompts 决定运行哪些actionsactions 与它们的线路决定如何运行而如何永不漂移。八、设计依据CLI-First 与消费走 CLI、服务走 MCP理解这套 CLI 栈为什么长这样需要看它背后的两条设计文档1. CLI-First 三步骤CliFirstArchitecture.mdRequirements → CLI Tool → Prompting Layer (what) (how) (orchestration)相对 prompt 驱动方式输出漂移、难调试、不可复现、难测试CLI-first 的优势是同一命令同一结果、可直接检查所执行的命令、独立于 AI 单元测试、行为变更进入版本控制。该文档还确立了一条边界判据——谁调用它我们调用 → CLI非我们调用 → MCP。任何 LifeOS 自己 harness 消费的能力都做确定性 CLI任何暴露给外部客户端claude.ai connectors、他人 harness的能力才走 MCP。这解释了为什么 Arbol 的本地 runner 是纯 CLI而不是通过协议层暴露。2. 管道模型与三原语ArbolSystem.md原语前缀职责组合对象ActionA_单个工作单元LLM 调用、API 调用、shell 命令无PipelineP_用管道模型按序串联 actionsActionsFlowF_在调度上连接 source → pipeline → destinationPipelines本文中的pai action/pai pipeline命令面正是这个三原语层级中 Action 与 Pipeline 两层在本地 runner 上的投影Flow 层在本地只有手动触发调度属于云端 Cron 的职责。3. 公开仓库中的配套 CLI 工具需要与 Arbol CLI 区分开的是 LifeOS 公开发布的另一类工具Tools.md 描述的单一职责 CLI 工具如Inference.ts统一推理工具、TOOLS/目录下的各类单用途脚本。它们的哲学是简单工具不需要独立 skill记录在这里、直接执行与 Arbol 的 action/pipeline 抽象属于不同层面——前者是扁平的单文件 CLI 集合后者是带 manifestaction.json与能力注入requires的结构化执行模型。九、延伸阅读文档路径说明系统架构总览LifeosSystemArchitecture.md主架构参考Arbol 总览ArbolSystem.mdArbol 系统架构三原语、管道模型、云端 Workers工具参考Tools.md公开版 CLI 工具参考CLI-First 架构模式CliFirstArchitecture.mdCLI-first 设计原则与 MCP 边界LifeOS 论点LifeOsThesis.mdhill-climb 与确定性执行的设计论据关键要点回顾pailifeos.ts是统一入口runner.v2.ts是共用引擎pipeline-runner.ts负责 YAML 编排三层各司其职Action 间组合完全依赖读 JSON、写 JSON的 UNIX 管道契约诊断信息与数据流通过 stderr/stdout 分离两级解析USER 覆盖系统让个人 actions/pipelines 可以无侵入地扩展内置能力本地 Arbol CLI 树不随公开版分发见 install.sh 注释公开用户获得的是模型、文档与蓝图一切取舍服从 CLI-First 原则重复的、确定性的行为做成命令一次性问题直接问——prompts 编排代码执行。【免费下载链接】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），仅供参考