YYLO CLI
用可审计凭据编排编码代理、任务、验证与受保护合并。
按维度查看评分与理由
最小权限、用户确认、数据流透明度和外部影响控制证据充分：只读观察与变更命令分离，发布权限独立，网络访问和模型提供商使用被明确标注，合并使用围栏所有者与旧 SHA 比较交换，测试还覆盖显式授权、脏工作区、陈旧引用和异常状态的拒绝。回滚、备份、恢复计划及保留冲突字节也有具体说明和测试，因此这些项满分。敏感数据处理仅说明凭据由外部提供商配置、工作流无 npm 令牌，未给出完整的秘密存储、日志脱敏或保留政策，故扣分。依赖使用 npm ci、精确发布身份及版本边界，但运行依赖多为宽松插入符范围，材料中没有漏洞扫描、供应链签名或更新政策，故依赖安全为 2。仓库、包、问题入口、公司作者和许可证归属一致，但发布者身份未经企业注册表验证，且没有更完整的治理或人员归属，故来源归属为 2；未知身份本身未被视为可疑。
README、package 清单、发布工作流和测试所描述的 CLI 名称、Node 门槛、版本通道、任务边界及发布身份总体一致；稳定版 0.2.2 与当前 0.2.3-rc.1 的差异被明确解释为 stable/next 通道，因此自洽性满分。依赖可用性有明确先决条件、独立 Ledger/Benchmark 安装方式和兼容版本，但 Pi、模型提供商、npx/Git 回退及外部注册表仍是未被随附材料保证的运行依赖，故为 2。失败消息和失败关闭行为证据很强，测试覆盖超时、漂移、权限缺失、脏状态、分离 HEAD、陈旧引用、重复配置及中断恢复，并断言具体诊断文本，因此失败消息满分。
材料分别面向初学开发者、项目操作员和维护者，覆盖无模型 canary、交互代理、受控循环、YAML 工作流、任务、合并、发布和迁移场景，因此受众与场景满分。能力边界明确区分编排器、外部模型凭据、独立 Ledger/Benchmark、控制器、任务工作树和集成所有者，也明确哪些命令只观察、哪些会变更，故边界满分。命令触发条件、显式授权参数、精确任务 ID、版本通道、模型选择和拒绝条件均具体，故触发精度满分。Node、npm、Git、Bash/Zsh/Fish、交互终端、源代码工具链及路径迁移要求均被说明，并提供本地诊断命令，因此环境适配满分。
README 的快速开始、所有权表、初学者流程、工作流、任务合并、恢复、发布、委托包、开发和帮助入口组织完整；安装说明包含先决条件、稳定/预发布通道、精确固定建议和成功 canary，因此信息架构与安装均满分。yylo 与 yy 的等价关系、ypl 展开方式、旧 lifecycle 移除及兼容别名都有明确说明，故命名稳定性满分。大量可复制示例、占位符解释、帮助入口以及限制和禁止操作构成充分的示例与常见问题支持；外部凭据、独立安装、状态输出上限、脏工作区和权限边界等已清楚披露，故已知限制满分。MIT 元数据与完整 LICENSE 一致，故许可证满分。package 清单提到 CHANGELOG.md 会随包发布，但该文件内容未提供，现有材料只展示版本和发布通道而非实际变更历史，故版本与变更日志仅为 1。公司名称、支持邮箱、源码和问题入口给出了一般维护路径，但发布者未经验证且没有维护者名单、响应承诺或治理政策，故维护责任为 2。
结构化状态、JSON 模式、截断与游标元数据、持久收据、日志、恢复包和显式帮助使输出适合人工诊断及自动化消费，因此输出可用性满分。相较于直接运行代理，任务工作树、验证证据、受保护合并、工作流恢复和发布绑定显示出明确的附加价值，但材料没有比较基线、采用数据或独立效果证据，故边际价值为 2。循环上限、日志边界、风险分级评审和无模型 canary体现成本控制，但没有令牌、时间、存储或运维成本测量，且系统引入 Ledger、Benchmark、代理和多工作树复杂度，因此成本收益为 2。
关键主张被具体命令、模式名、版本、文件职责、发布检查及测试断言连接，发布工作流还校验标签、清单、打包身份和注册表哈希，因此主张可追溯性满分。README 中若干安全和恢复主张得到工作流及两组测试交叉支持，但仅提供少量实现与测试文件，许多大型任务、合并和工作流声明仍只有 README 描述，故跨来源佐证为 2。材料明确区分源码版本与已发布版本、观察与变更、同步与推送、无模型 canary 与可能联系提供商的代理命令，也未声称本次静态审查已执行测试，因此事实与推断分离满分。
- 这是静态低置信度审查；未执行 CLI、测试、发布流程或网络操作。
- 代理运行可能把提示词和仓库上下文发送给外部模型提供商；材料未给出完整的秘密脱敏、日志保留或数据删除政策。
- 运行依赖使用多个插入符版本范围，且材料未展示锁文件、漏洞扫描、制品签名或依赖更新治理。
- Ledger、Benchmark、Pi、模型提供商和技能安装是独立依赖；安装前应固定并审查各自版本及其权限。
- README 描述的任务、合并和恢复保证只有部分得到所提供测试文件交叉验证，应在生产仓库采用前审查完整实现和测试集。
- 发布者身份未知但不因此被视为可疑；需要企业供应链保证时，应另行核验 JUNO AI INC.、npm 包和仓库控制权。
这个 Agent 能做什么，适合哪些场景？
YYLO 是一个本地优先的命令行编排器，提供等价的 `yylo` 与 `yy` 启动命令，用于运行编码代理和可重复的软件开发流程。它将普通命令观察、验证证据、类型化任务、独立工作树、合并队列和发布准备划分为明确的权限边界。执行结果以受限日志、终态、输入绑定证据、运行清单和持久化回执等形式保留，而不依赖终端滚屏记录。代理模型与凭据由外部工具或提供商管理；Pi 是可选代理，文档还展示了 Codex、Claude Code 及 OpenAI、Anthropic 模型选择。Ledger 任务存储和 Benchmark 评估包是独立安装的产品，`yy ledger` 与 `yy benchmark` 只负责透明委派。它适合重视 Git 拓扑隔离、可恢复操作和审计证据的团队，但对于只想执行一次提示的个人项目，完整的控制器、工作树和合并边界可能偏重。
YYLO 通过 yy pi、yy start 和已安装版本帮助中列出的代理别名启动编码代理，并可用 -i 限制代理内部迭代。yy loop 或 YAML Workflow Runner 按顺序执行代理命令、测试及其他 shell 步骤，并记录命令身份、标准输出、标准错误、响应、会话 ID、尝试次数、声明的回执哈希和终态清单。yy watch exec|status|await 为普通本地命令生成有界日志和机器可读终态；yy evidence run|status|await 则为任务的精确输入生成内容寻址验证证据。任务流程使用 yy task start|run|status|checkpoint|preflight|finish 创建和管理专用分支及工作树，完成后进入队列而不会直接合并。yy merge status|plan|arbiter|drive|next|resolve 通过单一受保护目标所有者、预期旧 SHA 的 CAS 检查和按风险分级的审查执行或恢复合并。yy info、yy where、yy doctor workspace 与 yy integration status 读取注册信息和仓库拓扑；改变集成目标、推送或发布则需要单独的显式命令与权限。
- 需要让 Pi、Codex 或 Claude Code 轮流实现和检查代码，并在每轮后运行
npm test的开发团队。 - 维护受保护分支、希望每项功能都在独立工作树中实现，并通过预检和队列合并交付的仓库运营者。
- 必须为测试结果、代理响应、输入哈希和失败状态保留持久证据的审计或合规型项目。
- 需要在中断后验证既有成功步骤、只恢复首个无效步骤，而不是重跑整个自动化流程的操作者。
- 希望先以只读方式诊断控制器、任务工作树和集成工作区拓扑，再授权同步、修复或推送的维护者。
- 需要把多步编码流程固化为受审查 YAML，并以明确迭代次数和错误策略重复执行的团队。
这个 Agent 有哪些优点和局限？
- 将元数据控制器、任务工作树和集成所有者分离，明确限制产品编辑、任务记录和受保护目标变更发生的位置。
- 为普通命令、工作流和任务验证保留有界日志、终态清单及内容寻址证据，降低仅依赖终端历史进行追溯的风险。
- 合并采用单一围栏所有者和预期旧 SHA 的 CAS，并保留冲突及无关脏文件，提供明确的恢复入口。
- 同时支持内联循环和受审查的 YAML Workflow Runner，可分别限制外层步骤迭代和代理内部迭代。
- Pi 支持多提供商，并提供 OpenAI Codex 与 Anthropic 模型快捷方式；提供商凭据和模型可用性仍保持外部边界。
- 要求 Node.js 20.10 以上、npm、Git，并且实际代理运行还需单独安装代理 CLI、配置凭据并承担相应提供商可用性或费用。
- 完整生命周期依赖控制器注册、专用工作树、干净提交、预检、证据和合并队列，采用成本高于简单的单次代理命令。
- Ledger 与 Benchmark 不随 CLI 捆绑，必须分别安装兼容版本；技能内容也来自独立仓库和安装流程。
doctor workspace在发现可操作的拓扑问题时会故意返回非零，自动化脚本需要正确区分诊断结果与程序故障。- 同步、合并、推送和发布是相互独立的权限边界；操作者必须理解不同工作区角色，不能把一次授权推断为后续操作授权。
如何安装或部署这个 Agent？
前置条件是 Node.js 20.10 或更新版本、npm 和 Git。安装稳定版并验证：
npm install --global '@yylo/cli@latest'
yy --version首个无需模型提供商的本地验证流程：
mkdir yylo-demo
cd yylo-demo
git init
yy init --task "Document the onboarding path" --subagent pi
yy watch exec pwd成功时会初始化 .juno_task/，并生成包含 "state":"COMPLETED"、"exit_code":0 和非零 log_bytes 的 watch 回执。若要安装 YYLO 的七项代理技能，可另行运行 yy skills install；技能不包含在 @yylo/cli 中。实际运行编码代理前，还需单独安装相应代理并配置其提供商凭据。例如 Pi 可通过 npm install --global '@mariozechner/pi-coding-agent' 安装。安装 npm 包、获取技能和调用模型通常需要网络。
如何使用这个 Agent？
先检查工作区和命令清单：
yy info --json
yy doctor workspace
yy --help运行一次不保留 Pi 会话的仓库分析：
yy pi --no-session 'Summarize this repository and make no changes'该命令可能联系已配置的模型提供商。运行受限迭代及测试：
yy loop -n 2 --step 'yy pi "Implement the next increment"' --step 'npm test'对于类型化任务，可在元数据控制器中运行：
yy task start TASK_ID# 在命令返回的任务工作树中修改、测试并提交
yy task preflight TASK_ID
yy task finish TASK_ID
yy merge arbiter run --through TASK_ID托管路径可使用 yy task run TASK_ID，再显式执行 yy merge drive --through TASK_ID。观察状态时使用 yy task status TASK_ID、yy merge status 或 yy evidence status TASK_ID；这些状态命令不会自动获得合并、发布或推送权限。
常见问题
第一次验证 YYLO 是否必须配置模型 API？
yy watch exec pwd 是不联系模型提供商的本地 canary；运行 yy pi 等模型支持的命令时才需要相应代理、凭据和可用模型。YYLO 会自动合并、推送或发布代码吗？
task finish 只把干净且已提交的任务排入队列；merge drive、integration push 和维护者发布脚本分别需要显式调用与独立权限。仓库存在未提交修改时会怎样？
Ledger、Benchmark 和技能是否包含在 npm CLI 中？
yy skills install 从独立版本化仓库获取。工作流中断后是否必须全部重跑？
recover-attempt RUN_DIRECTORY --dry-run 和 doctor RUN_DIRECTORY；恢复会先验证既有成功证据未变，再从第一个无效步骤继续。