Loop Engineering
为 AI 编码助手提供可评分、可审计的循环设计与脚手架。
按维度查看评分与理由
证据显示：README 和 SECURITY.md 明确讨论了最小权限（MCP 只读、denylist）、用户确认（L1 报告、人工门）、数据流透明（STATE.md 不记录 secrets）、敏感数据处理（denylist .env）、外部影响（auto-merge 限制）、回滚（worktree 隔离）。但依赖安全仅提及供应链风险，未提供依赖审计或锁定证据；回滚机制仅提及 worktree，未提供具体恢复流程。因此扣分：依赖安全证据不足，回滚证据薄弱。
证据显示：README 和 package.json 显示多个工具包有测试脚本，但未提供测试结果或覆盖率；依赖可用性通过 npm 发布和 CI 工作流暗示，但未验证；失败消息在 SECURITY.md 和 docs/failure-modes.md 中有提及，但未提供具体示例。因此扣分：测试证据不足，失败消息具体性不足。
证据显示：README 详细列出了多种工具（Grok、Claude Code、Codex 等）和场景（daily-triage、PR babysitter 等），并提供了模式选择器；能力边界通过 L1-L3 阶段和 denylist 明确；触发精度通过模式 cadence 和 CLI 参数说明；环境适配通过 GitHub Actions 和 npm 包支持。因此扣分：能力边界和触发精度证据部分依赖文档声明，未提供实际配置示例。
证据显示：README 提供了清晰的信息架构（目录、快速链接）、安装说明（npx 命令）、命名稳定性（多个 npm 包）、示例和 FAQ（docs/QUICKSTART.md）、已知限制（Caveats 部分）、MIT 许可证、版本变更（讨论区发布说明）和维护责任（CONTRIBUTING.md）。因此扣分：版本变更和变更日志证据不足，维护责任未明确指定。
证据显示：输出可用性通过 CLI 输出和文档说明；边际价值通过模式对比和成本估算；成本效益通过 token 成本估算和 L1-L3 阶段。因此扣分：输出可用性未提供实际输出示例，成本效益未提供实际数据。
证据显示：声明可追溯性通过引用来源（Addy Osmani、Boris Cherny）和文档；跨源验证通过多个来源（Substack、博客）和社区讨论；事实与推断分离通过文档区分概念和模式。因此扣分：跨源验证证据不足，事实与推断分离未明确说明。
- 依赖安全证据不足：未提供依赖审计或锁定文件，供应链风险仅提及。
- 回滚机制证据薄弱：仅提及 worktree 隔离，未提供具体恢复流程。
- 测试证据不足：package.json 有测试脚本，但未提供测试结果或覆盖率。
- 版本变更和变更日志证据不足：仅通过讨论区发布说明，未提供正式 CHANGELOG。
这个 Agent 能做什么，适合哪些场景？
Loop Engineering 是一套面向 AI 编码助手的循环设计参考库与 CLI 工具集，不是单一托管式代理。它提供 7 种生产循环模式、Grok、Claude Code、Codex 与 Opencode 的 starter，以及用于 GitHub Actions 的示例。统一的 @cobusgreyling/loop CLI 可初始化项目、运行 doctor 检查、查看状态、审计循环和估算成本；旧版 loop-init、loop-audit 等包仍受支持。其工作方式是将技能、STATE.md、预算文件、约束和可选工作树等机制放入项目，再以从 L1 报告到 L3 无人值守的分阶段方式运行。输出包括 Loop Ready 分数、首个循环命令、健康检查的三项后续建议，以及状态、成本或漂移检查结果。该项目采用 MIT 许可证，也提供 MCP 运行时查找、隔离 worktree、路径门禁和 GitHub Composite Action 等可组合组件。
在目标项目中运行 npx @cobusgreyling/loop init . --pattern daily-triage --tool grok 时，loop init 会生成 skills、state 与 budget 文件，并打印 Loop Ready 分数和首个循环命令。npx @cobusgreyling/loop doctor . 将 audit、sync 与文件检查合并为三项下一步行动；loop audit、loop cost、loop badge 和 loop status 分别覆盖循环审计、成本估算、徽章和状态查看。loop-sync 检测 STATE.md 与 LOOP.md 的漂移，loop-context --check --ledger run.json 管理长运行的状态记忆与断路器，loop-worktree 为修复尝试创建隔离 Git worktree。可选的 loop-mcp-server 可查找 patterns、skills 和 state，loop-gate 根据 gate.yaml 对路径拒绝列表和自动合并允许列表做机械检查。
- 刚开始引入 Codex 或 Claude Code 的开发团队，可用 Daily Triage 初始化项目，先以 L1 只读报告方式建立日常问题分诊。
- 维护高频 PR 的仓库负责人，可采用 PR Babysitter 模式每 5–15 分钟监看 PR，并在先审查成本后决定是否启用。
- 负责不稳定 CI 的工程师，可用 CI Sweeper starter 设计 5–15 分钟循环，并从 L2 谨慎修复逐步推进。
- 需要定期处理依赖更新的维护者，可运行 Dependency Sweeper，以补丁优先的 L2 策略组织更新工作。
- 希望让自动化在隔离分支中处理修复尝试的团队，可用
loop-worktree create --run-id <id> --pattern <p>管理每次尝试的 Git worktree。
这个 Agent 有哪些优点和局限？
- 统一
@cobusgreyling/loop前门把 init、doctor、status、audit 和 cost 集中为一个 CLI，同时保留旧包，降低既有 fork 的迁移压力。 - 提供 7 个具名循环模式，并为不同节奏、首周自主等级和 token 成本给出明确定位。
- 除脚手架外还包含
loop-sync、loop-context、loop-worktree、loop-gate与 MCP server，覆盖状态漂移、长运行记忆、隔离和门禁等具体运维环节。 - 明确支持从 L1 报告、L2 辅助修复到 L3 无人值守的渐进式采用路径。
- 文档明确警告：子代理和长运行循环可能导致 token 成本快速失控，尤其是 PR Babysitter 与 CI Sweeper。
- 验证责任仍在使用者；无人值守循环也可能产生无人值守的错误。
- 需要设计和维护 STATE、预算、约束、门禁及调度机制，采用成本高于一次性的提示词工作流。
- 来源未给出 Node.js 版本、凭据配置或各支持编码工具的完整运行时要求。
如何安装或部署这个 Agent？
在目标项目的 shell 中使用 npx，无需先克隆此仓库：npx @cobusgreyling/loop init . --pattern daily-triage --tool grok。随后运行 npx @cobusgreyling/loop doctor . 验证初始化结果。--tool 可替换为 claude、codex 或 opencode；来源未说明 Node.js 版本或任何必需凭据，因此所选编码工具的安装、登录和凭据配置需要由使用环境自行满足。
如何使用这个 Agent？
先执行 npx @cobusgreyling/loop init . --pattern daily-triage --tool codex，根据输出的 Loop Ready 分数和首个循环命令检查生成内容。再执行 npx @cobusgreyling/loop doctor . 获取 audit、sync 与文件检查后的三项建议。需要估算时使用 npx @cobusgreyling/loop cost --pattern daily-triage --level L1，并建议先从 L1 报告模式开始，再逐步升级到 L2 辅助修复或 L3 无人值守。
常见问题
它会直接替我运行一个编码代理吗？
如何控制成本和自主性？
loop cost 估算模式成本，并按 L1 报告、L2 辅助修复、L3 无人值守逐步升级。项目明确建议第一周先从报告模式开始。可以防止循环改动敏感文件或自动合并吗？
loop-gate 可根据 gate.yaml 对路径拒绝列表和自动合并允许列表进行检查；安全文档还涵盖 denylist、自动合并与 MCP scopes。长时间运行时怎样保存上下文？
loop-context --check --ledger run.json 管理状态记忆和断路器；项目也将 STATE.md 作为持久状态的一部分，并提供 loop-sync 检查其与 LOOP.md 的漂移。