人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载本文基于 loop-engineering 仓库的 patterns/thin-loop.md 模式文档结合 starters/thin-loop 起步模板与 tools/loop-init 脚手架源码讲解如何用几乎零额外文件的方式在 GitHub Actions 上搭建一个仅报告report-only的自动化循环。读完你将掌握什么时候该用瘦循环、如何 10 分钟内部署一个绿色工作流、底层 workflow 每个步骤的写法与权限含义以及何时应当升级到带STATE.md的成熟模式。一、什么是 Thin Loop把问题跟踪器当作状态本身瘦循环Thin Loop是 loop-engineering 模式注册表中的一类低风险模式patterns/registry.yaml 中id: thin-loop。它的核心主张只有一句话问题跟踪器和 Actions 的 Job Summary 就是状态state不需要额外的STATE.md。模式文档开篇给出了它的设计动机现实中大多数 AI 编码 Agent 循环其实已经长这样——仓库里提交了触发器cron 定时任务或pull_request工作流却几乎从不提交STATE.md。瘦循环是有意顺应这种现实形态而不是强行要求一套完整的方法论安装。在模式注册表中瘦循环的定位非常明确patterns/registry.yaml目标report-only 的 GitHub Action 快照问题跟踪器即状态节奏1d事件触发 每日定时风险low低阶段snapshot→summarize→optional-comment快照 → 汇总 → 可选评论人机门禁all-writes所有写操作都留给人类第一周模式L1仅报告。与之配套仓库在 patterns/README.md 的模式索引表中将 Thin Loop 标注为event 1d、Low 风险的模式并链接到本文档。二、适用场景与反模式什么时候该瘦什么时候别瘦适用场景When to use模式文档明确给出三个典型信号本周就要一个循环而不是安装一套方法论——追求的是尽快让循环转起来工作内容就是 PR 审查或 Issue 快照——没有需要持久化、而 GitHub 本身又没有存储的数据后续如果需要再补STATE.md——当发现某个发现需要跨运行存活例如积压任务、尝试次数、预算再升级。不适用场景Do NOT start here文档明确划出红线如果你需要以下能力不要从这里开始而应改用 Daily Triage 或 PR Babysitter尝试次数上限attempt capsmaker/checker 分离即执行者与检查者分离的职责划分Token 熔断开关token kill switch。原因很直接这些能力都依赖跨运行的持久化状态而瘦循环刻意不维护状态。三、调度策略与 L1 定位模式文档给出瘦循环的调度表面表面Surface触发器TriggerGitHub Actionsissues/pull_requestopened 工作日 cron见起步模板Claude / Grok / Codex可选稍后/loop 1d读取上一次 job summary第一周定位为L1工作流只向$GITHUB_STEP_SUMMARY写入快照只有当触发的 issue/PR 线程上**还没有瘦循环标记marker**时才评论一次。起步模板的 LOOP.md 把这一定位浓缩为一页Pattern: thin-loopLevel: L1 report-onlyCadence:issues/pull_requestopened 工作日 08:00 UTCState: 无。GitHub issues 和 PR 就是积压队列Actions job summary 就是报告Writes: job summary每个线程至多一条评论!-- thin-loop --Denylist: 不编辑代码、不打标签、不关闭、不推送Kill switch: 禁用.github/workflows/thin-loop.yml或取消工作流这里的Denylist拒绝清单是瘦循环安全性的关键循环本身被明确禁止做任何有副作用的写操作这与所有写操作留给人类的human_gates: [all-writes]注册表配置patterns/registry.yaml完全对应。四、10 分钟部署安装方式与脚手架方式一使用 loop-init 脚手架起步模板 starters/thin-loop/README.md 给出的标准安装命令npx cobusgreyling/loop-init . --pattern thin-loop --tool claude从 tools/loop-init/src/cli.ts 源码可以看到thin-loop被显式列入模式白名单Pattern联合类型与thin-loop: thin-loop映射见 tools/loop-init/src/cli.ts并且是TOOL_AGNOSTIC工具无关集合的成员tools/loop-init/src/cli.ts——这正是模式文档所说tool suffix is ignored; you still get the workflow工具后缀会被忽略你仍然得到工作流的源码依据。值得注意的一个实现细节脚手架在pattern ! thin-loop且非 dry-run 时才要求目标目录存在AGENTS.mdtools/loop-init/src/cli.ts。也就是说瘦循环特意不要求任何 Agent 配置文件这与无技能、无预算文件、无 STATE.md的极简哲学一脉相承。CLI 帮助信息也印证了这一点thin-loop (GitHub Action snapshot — no STATE.md)tools/loop-init/src/cli.ts。同样loopCLI 的交互式向导tools/loop/src/wizard.ts将瘦循环选项描述为 Just a GitHub Action, no extra files仅一个 GitHub Action无额外文件并从loop-init侧给出了对应的操作指引tools/loop-init/src/cli.ts。方式二手动复制mkdir -p .github/workflows cp starters/thin-loop/.github/workflows/thin-loop.yml .github/workflows/然后合并到main打开一个 issue 或等待工作日 cron读取 Actions summary 即可。你会得到什么 / 刻意不给你什么文件用途.github/workflows/thin-loop.yml事件 工作日快照LOOP.md一页说明节奏与门禁起步模板明确列出了刻意不给的三样东西starters/thin-loop/README.mdSTATE.md——当发现需要跨运行持久化时再加升级方向见 minimal-loop-claudeAgent 调用——之后如需模型入环可接入 tools/loop-action高 Loop Ready 评分——文件落盘数量不是这里的目标。五、工作流解剖一份完整可运行的 thin-loop.yml瘦循环的全部实现都集中在一个文件里starters/thin-loop/.github/workflows/thin-loop.yml。下面是它的四个关键组成部分。1. 触发条件onon: issues: types: [opened] pull_request: types: [opened, ready_for_review] schedule: - cron: 0 8 * * 1-5 workflow_dispatch:issues: opened——新 issue 打开时触发pull_request: opened, ready_for_review——新 PR 打开、或 PR 从 draft 转为 ready 时触发schedule: 0 8 * * 1-5——工作日周一至周五08:00 UTC 定时快照对应 LOOP.md 中weekdays 08:00 UTC的节奏workflow_dispatch——支持手动触发便于调试。2. 权限声明permissionspermissions: contents: read issues: write pull-requests: write这是最小权限集contents: read用于actions/checkoutissues: write与pull-requests: write用于发布评论。模式文档的失败模式表中特别强调空快照问题往往就是gh鉴权问题工作流必须带issues: write/pull-requests: write——缺了写权限gh命令会失败。3. 快照步骤Snapshot open work- uses: actions/checkoutv4 - name: Snapshot open work id: snap env: GH_TOKEN: ${{ github.token }} run: | { echo # Thin loop snapshot $(date -u %Y-%m-%dT%H:%M:%SZ) echo echo L1 report-only. No code edits, labels, or closes. echo echo ## Open pull requests gh pr list --state open --limit 20 --json number,title,updatedAt \ --jq .[] | - #\(.number) \(.title) (updated \(.updatedAt)) \ || echo _none_ echo echo ## Open issues gh issue list --state open --limit 20 --json number,title,updatedAt \ --jq .[] | - #\(.number) \(.title) (updated \(.updatedAt)) \ || echo _none_ } | tee $GITHUB_STEP_SUMMARY /tmp/thin-loop-summary.md要点解析使用github.token作为GH_TOKEN不需要单独创建 PATgh pr list/gh issue list各取最近 20 条 open 项通过--jq输出为- #编号 标题 (updated 时间)格式|| echo _none_兜底——即使查询失败也保证 summary 非空tee $GITHUB_STEP_SUMMARY /tmp/thin-loop-summary.md把内容同时写入 Job Summary 和临时文件供后续步骤引用。4. 一次性评论步骤Comment once- name: Comment once on the triggering item if: github.event_name issues || github.event_name pull_request env: GH_TOKEN: ${{ github.token }} EVENT_NAME: ${{ github.event_name }} ISSUE_NUMBER: ${{ github.event.issue.number }} PR_NUMBER: ${{ github.event.pull_request.number }} run: | set -euo pipefail MARKER!-- thin-loop -- ...核心逻辑是标记防重从事件环境变量中取出 issue/PR 编号用gh api repos/${{ github.repository }}/issues/${NUMBER}/comments拉取该线程全部评论用grep -q thin-loop检查是否已存在标记!-- thin-loop --存在则直接跳过防止评论轰炸对应模式文档失败模式表中的Comment spam一行不存在则写入一条 L1 评论内容包含标记、快照链接指向本次 Actions run以及本运行不打标签、不关闭、不编辑代码的声明按 kind 分别调用gh issue comment或gh pr comment。需要留意一个细节步骤只对事件驱动的触发issue/PR 打开评论而 cron 定时快照只写 summary不评论——避免每天 08:00 给所有历史线程重复刷评论。六、典型循环周期Typical cycle模式文档给出了 5 步标准周期事件或工作日 cron 触发工作流用gh列出所有 open 的 PR 和 issue快照写入 Job Summary如果事件来自某个 issue/PR则在其线程上发布一次简短 L1 评论仅一次人类阅读 summary 或评论。循环不编辑代码、不自动合并。对应到注册表的阶段定义patterns/registry.yamlsnapshot → summarize → optional-comment其中 optional可选正是指评论只在事件触发且无标记时才发生。七、所需技能与工具说明技能Required Skills模式文档的关键结论L1 阶段不要求任何技能工作流只用gh。loop-triage——可选仅当你之后要通过 loop-action 把 Agent 接入 Action 时才需要loop-verifier——可选但在任何写操作之前是必须的一旦存在实现者implementermaker/checker 分离依然适用。需要强调的是验证器技能模板见 templates/SKILL.md.verifier其核心思想是maker/checker而不是同一会话给自己作业打分。状态文件与成本画像State file不需要。GitHub issues/PR 承载积压可选地一行loop-run-log.md记录可作为 Loop Ready 活动评分的证明。成本画像来自 patterns/registry.yamltoken_cost: low空操作 1000 tokens、报告 5000 tokens、动作 1000 tokens稳定性比例 0.9即 90% 的运行几乎不消耗 token建议日上限 20000 tokens且要求尽早退出early_exit_required: true。从 tools/loop-init/src/cli.ts 还可以看到thin-loop的每日运行上限为 24 次、maxSpawnsL1: 0L1 阶段零衍生任务印证了它极低的开销定位。运行时选择GitHub Actions 是原生运行时起步模板见 starters/thin-loop其他工具可统一用npx cobusgreyling/loop-init . --pattern thin-loop --tool claude脚手架生成工具后缀会被忽略你得到的仍是同一个工作流文件。八、验证策略Verification Strategy瘦循环没有实现者implementer因此也没有验证者verifier。模式的验证是纯机械检查gh命令执行成功且 summary 非空。这正是|| echo _none_兜底与tee双写设计的用意——保证 summary 永远非空、可被人类阅读。文档同时给出升级路径如果之后接入 Agent必须在任何写操作前添加 loop-verifier坚持 maker/checker 分离而不是同一会话自我评分。九、人工交接Human hand-off模式文档对人工交接的定义非常干脆一切都是交接。循环不关闭 issue、不打标签、不推送提交。这正是所有写操作都留给人类human_gates: [all-writes]的落地形态快照和一次性评论是循环与人类之间的交接物而决策与动作关闭、打标签、合并、改代码永远发生在循环之外。起步模板第一周指引starters/thin-loop/README.md也明确要求阅读 summary但不要让循环打标签、关闭或推送。十、失败模式速查表模式文档给出三张最常见的失败场景与对策失败对策评论轰炸Comment spam标记!-- thin-loop --会跳过重复评论空快照Empty snapshotgh鉴权问题——工作流需要issues: write/pull-requests: write人们期待高 Loop Ready 评分瘦循环在出现带日期的运行日志或STATE.mdLast run 之前保持低分这是设计使然前两行已经在上文的工作流解剖中给出源码级对应标记防重逻辑与permissions声明第三行则提醒团队管理预期低评分不是缺陷而是刻意取舍。十一、成功指标Success Metrics模式文档给出三条可量化的成功标准合并后 10 分钟内出现首个绿色工作流运行已有标记的线程上不再出现新评论循环本身对main的零文件编辑。这三条分别验证了部署速度、防重复机制和只读纪律——三者共同构成瘦循环按预期运转的完整证据。十二、升级路径什么时候该长胖瘦循环刻意保持薄但模式文档和模板都给出了明确的毕业方向当积压需要跨运行存活尝试次数、预算、观察清单时升级到 Daily Triage 并添加STATE.md对应起步模板 README 中的指引 starters/minimal-loop-claude当需要模型入环时通过 tools/loop-action 接入 Agent并在任何写操作前引入 loop-verifier当需要尝试次数上限、maker/checker 分离或 token 熔断时参考 PR Babysitter。用 LOOP.md 的话说当队列必须跨运行存活时升级到 Daily Triage 并添加STATE.md。瘦循环不是终点而是让循环以最低成本转起来、并以真实需求驱动演进的起点。相关资源索引模式文档patterns/thin-loop.md起步模板starters/thin-loop含 LOOP.md、README.md、thin-loop.yml模式注册表条目patterns/registry.yaml脚手架实现tools/loop-init/src/cli.tsthin-loop工具无关、免AGENTS.md的逻辑见 L21-L99、L1076-L1083交互式向导tools/loop/src/wizard.ts相关模式Daily Triage、PR Babysitter、loop-verifier 模板、loop-action赞分享人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载相关推荐gs-quant 量化金融回测实战一段脚本跑通均值回归策略看懂 5 个核心指标gs quant 量化金融回测实战一段脚本跑通均值回归策略看懂 5 个核心指标 gs quant 是 Python 量化金融工具包内置回测引擎、触发器与绩人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务用单个 GitHub Action 搭建 L1 只读循环loop-engineering Thin Loop 模式实战用单个 GitHub Action 搭建 L1 只读循环loop engineering Thin Loop 模式实战 Thin Loop 是 loop en人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务MLX JACCLThunderbolt 5 RDMA 分布式通信实战指南MLX JACCLThunderbolt 5 RDMA 分布式通信实战指南 JACCLJack and Angelos Collective Commun人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载本文基于 loop-engineering 仓库的 patterns/thin-loop.md 模式文档结合 starters/thin-loop 起步模板与 tools/loop-init 脚手架源码讲解如何用几乎零额外文件的方式在 GitHub Actions 上搭建一个仅报告report-only的自动化循环。读完你将掌握什么时候该用瘦循环、如何 10 分钟内部署一个绿色工作流、底层 workflow 每个步骤的写法与权限含义以及何时应当升级到带STATE.md的成熟模式。一、什么是 Thin Loop把问题跟踪器当作状态本身瘦循环Thin Loop是 loop-engineering 模式注册表中的一类低风险模式patterns/registry.yaml 中id: thin-loop。它的核心主张只有一句话问题跟踪器和 Actions 的 Job Summary 就是状态state不需要额外的STATE.md。模式文档开篇给出了它的设计动机现实中大多数 AI 编码 Agent 循环其实已经长这样——仓库里提交了触发器cron 定时任务或pull_request工作流却几乎从不提交STATE.md。瘦循环是有意顺应这种现实形态而不是强行要求一套完整的方法论安装。在模式注册表中瘦循环的定位非常明确patterns/registry.yaml目标report-only 的 GitHub Action 快照问题跟踪器即状态节奏1d事件触发 每日定时风险low低阶段snapshot→summarize→optional-comment快照 → 汇总 → 可选评论人机门禁all-writes所有写操作都留给人类第一周模式L1仅报告。与之配套仓库在 patterns/README.md 的模式索引表中将 Thin Loop 标注为event 1d、Low 风险的模式并链接到本文档。二、适用场景与反模式什么时候该瘦什么时候别瘦适用场景When to use模式文档明确给出三个典型信号本周就要一个循环而不是安装一套方法论——追求的是尽快让循环转起来工作内容就是 PR 审查或 Issue 快照——没有需要持久化、而 GitHub 本身又没有存储的数据后续如果需要再补STATE.md——当发现某个发现需要跨运行存活例如积压任务、尝试次数、预算再升级。不适用场景Do NOT start here文档明确划出红线如果你需要以下能力不要从这里开始而应改用 Daily Triage 或 PR Babysitter尝试次数上限attempt capsmaker/checker 分离即执行者与检查者分离的职责划分Token 熔断开关token kill switch。原因很直接这些能力都依赖跨运行的持久化状态而瘦循环刻意不维护状态。三、调度策略与 L1 定位模式文档给出瘦循环的调度表面表面Surface触发器TriggerGitHub Actionsissues/pull_requestopened 工作日 cron见起步模板Claude / Grok / Codex可选稍后/loop 1d读取上一次 job summary第一周定位为L1工作流只向$GITHUB_STEP_SUMMARY写入快照只有当触发的 issue/PR 线程上**还没有瘦循环标记marker**时才评论一次。起步模板的 LOOP.md 把这一定位浓缩为一页Pattern: thin-loopLevel: L1 report-onlyCadence:issues/pull_requestopened 工作日 08:00 UTCState: 无。GitHub issues 和 PR 就是积压队列Actions job summary 就是报告Writes: job summary每个线程至多一条评论!-- thin-loop --Denylist: 不编辑代码、不打标签、不关闭、不推送Kill switch: 禁用.github/workflows/thin-loop.yml或取消工作流这里的Denylist拒绝清单是瘦循环安全性的关键循环本身被明确禁止做任何有副作用的写操作这与所有写操作留给人类的human_gates: [all-writes]注册表配置patterns/registry.yaml完全对应。四、10 分钟部署安装方式与脚手架方式一使用 loop-init 脚手架起步模板 starters/thin-loop/README.md 给出的标准安装命令npx cobusgreyling/loop-init . --pattern thin-loop --tool claude从 tools/loop-init/src/cli.ts 源码可以看到thin-loop被显式列入模式白名单Pattern联合类型与thin-loop: thin-loop映射见 tools/loop-init/src/cli.ts并且是TOOL_AGNOSTIC工具无关集合的成员tools/loop-init/src/cli.ts——这正是模式文档所说tool suffix is ignored; you still get the workflow工具后缀会被忽略你仍然得到工作流的源码依据。值得注意的一个实现细节脚手架在pattern ! thin-loop且非 dry-run 时才要求目标目录存在AGENTS.mdtools/loop-init/src/cli.ts。也就是说瘦循环特意不要求任何 Agent 配置文件这与无技能、无预算文件、无 STATE.md的极简哲学一脉相承。CLI 帮助信息也印证了这一点thin-loop (GitHub Action snapshot — no STATE.md)tools/loop-init/src/cli.ts。同样loopCLI 的交互式向导tools/loop/src/wizard.ts将瘦循环选项描述为 Just a GitHub Action, no extra files仅一个 GitHub Action无额外文件并从loop-init侧给出了对应的操作指引tools/loop-init/src/cli.ts。方式二手动复制mkdir -p .github/workflows cp starters/thin-loop/.github/workflows/thin-loop.yml .github/workflows/然后合并到main打开一个 issue 或等待工作日 cron读取 Actions summary 即可。你会得到什么 / 刻意不给你什么文件用途.github/workflows/thin-loop.yml事件 工作日快照LOOP.md一页说明节奏与门禁起步模板明确列出了刻意不给的三样东西starters/thin-loop/README.mdSTATE.md——当发现需要跨运行持久化时再加升级方向见 minimal-loop-claudeAgent 调用——之后如需模型入环可接入 tools/loop-action高 Loop Ready 评分——文件落盘数量不是这里的目标。五、工作流解剖一份完整可运行的 thin-loop.yml瘦循环的全部实现都集中在一个文件里starters/thin-loop/.github/workflows/thin-loop.yml。下面是它的四个关键组成部分。1. 触发条件onon: issues: types: [opened] pull_request: types: [opened, ready_for_review] schedule: - cron: 0 8 * * 1-5 workflow_dispatch:issues: opened——新 issue 打开时触发pull_request: opened, ready_for_review——新 PR 打开、或 PR 从 draft 转为 ready 时触发schedule: 0 8 * * 1-5——工作日周一至周五08:00 UTC 定时快照对应 LOOP.md 中weekdays 08:00 UTC的节奏workflow_dispatch——支持手动触发便于调试。2. 权限声明permissionspermissions: contents: read issues: write pull-requests: write这是最小权限集contents: read用于actions/checkoutissues: write与pull-requests: write用于发布评论。模式文档的失败模式表中特别强调空快照问题往往就是gh鉴权问题工作流必须带issues: write/pull-requests: write——缺了写权限gh命令会失败。3. 快照步骤Snapshot open work- uses: actions/checkoutv4 - name: Snapshot open work id: snap env: GH_TOKEN: ${{ github.token }} run: | { echo # Thin loop snapshot $(date -u %Y-%m-%dT%H:%M:%SZ) echo echo L1 report-only. No code edits, labels, or closes. echo echo ## Open pull requests gh pr list --state open --limit 20 --json number,title,updatedAt \ --jq .[] | - #\(.number) \(.title) (updated \(.updatedAt)) \ || echo _none_ echo echo ## Open issues gh issue list --state open --limit 20 --json number,title,updatedAt \ --jq .[] | - #\(.number) \(.title) (updated \(.updatedAt)) \ || echo _none_ } | tee $GITHUB_STEP_SUMMARY /tmp/thin-loop-summary.md要点解析使用github.token作为GH_TOKEN不需要单独创建 PATgh pr list/gh issue list各取最近 20 条 open 项通过--jq输出为- #编号 标题 (updated 时间)格式|| echo _none_兜底——即使查询失败也保证 summary 非空tee $GITHUB_STEP_SUMMARY /tmp/thin-loop-summary.md把内容同时写入 Job Summary 和临时文件供后续步骤引用。4. 一次性评论步骤Comment once- name: Comment once on the triggering item if: github.event_name issues || github.event_name pull_request env: GH_TOKEN: ${{ github.token }} EVENT_NAME: ${{ github.event_name }} ISSUE_NUMBER: ${{ github.event.issue.number }} PR_NUMBER: ${{ github.event.pull_request.number }} run: | set -euo pipefail MARKER!-- thin-loop -- ...核心逻辑是标记防重从事件环境变量中取出 issue/PR 编号用gh api repos/${{ github.repository }}/issues/${NUMBER}/comments拉取该线程全部评论用grep -q thin-loop检查是否已存在标记!-- thin-loop --存在则直接跳过防止评论轰炸对应模式文档失败模式表中的Comment spam一行不存在则写入一条 L1 评论内容包含标记、快照链接指向本次 Actions run以及本运行不打标签、不关闭、不编辑代码的声明按 kind 分别调用gh issue comment或gh pr comment。需要留意一个细节步骤只对事件驱动的触发issue/PR 打开评论而 cron 定时快照只写 summary不评论——避免每天 08:00 给所有历史线程重复刷评论。六、典型循环周期Typical cycle模式文档给出了 5 步标准周期事件或工作日 cron 触发工作流用gh列出所有 open 的 PR 和 issue快照写入 Job Summary如果事件来自某个 issue/PR则在其线程上发布一次简短 L1 评论仅一次人类阅读 summary 或评论。循环不编辑代码、不自动合并。对应到注册表的阶段定义patterns/registry.yamlsnapshot → summarize → optional-comment其中 optional可选正是指评论只在事件触发且无标记时才发生。七、所需技能与工具说明技能Required Skills模式文档的关键结论L1 阶段不要求任何技能工作流只用gh。loop-triage——可选仅当你之后要通过 loop-action 把 Agent 接入 Action 时才需要loop-verifier——可选但在任何写操作之前是必须的一旦存在实现者implementermaker/checker 分离依然适用。需要强调的是验证器技能模板见 templates/SKILL.md.verifier其核心思想是maker/checker而不是同一会话给自己作业打分。状态文件与成本画像State file不需要。GitHub issues/PR 承载积压可选地一行loop-run-log.md记录可作为 Loop Ready 活动评分的证明。成本画像来自 patterns/registry.yamltoken_cost: low空操作 1000 tokens、报告 5000 tokens、动作 1000 tokens稳定性比例 0.9即 90% 的运行几乎不消耗 token建议日上限 20000 tokens且要求尽早退出early_exit_required: true。从 tools/loop-init/src/cli.ts 还可以看到thin-loop的每日运行上限为 24 次、maxSpawnsL1: 0L1 阶段零衍生任务印证了它极低的开销定位。运行时选择GitHub Actions 是原生运行时起步模板见 starters/thin-loop其他工具可统一用npx cobusgreyling/loop-init . --pattern thin-loop --tool claude脚手架生成工具后缀会被忽略你得到的仍是同一个工作流文件。八、验证策略Verification Strategy瘦循环没有实现者implementer因此也没有验证者verifier。模式的验证是纯机械检查gh命令执行成功且 summary 非空。这正是|| echo _none_兜底与tee双写设计的用意——保证 summary 永远非空、可被人类阅读。文档同时给出升级路径如果之后接入 Agent必须在任何写操作前添加 loop-verifier坚持 maker/checker 分离而不是同一会话自我评分。九、人工交接Human hand-off模式文档对人工交接的定义非常干脆一切都是交接。循环不关闭 issue、不打标签、不推送提交。这正是所有写操作都留给人类human_gates: [all-writes]的落地形态快照和一次性评论是循环与人类之间的交接物而决策与动作关闭、打标签、合并、改代码永远发生在循环之外。起步模板第一周指引starters/thin-loop/README.md也明确要求阅读 summary但不要让循环打标签、关闭或推送。十、失败模式速查表模式文档给出三张最常见的失败场景与对策失败对策评论轰炸Comment spam标记!-- thin-loop --会跳过重复评论空快照Empty snapshotgh鉴权问题——工作流需要issues: write/pull-requests: write人们期待高 Loop Ready 评分瘦循环在出现带日期的运行日志或STATE.mdLast run 之前保持低分这是设计使然前两行已经在上文的工作流解剖中给出源码级对应标记防重逻辑与permissions声明第三行则提醒团队管理预期低评分不是缺陷而是刻意取舍。十一、成功指标Success Metrics模式文档给出三条可量化的成功标准合并后 10 分钟内出现首个绿色工作流运行已有标记的线程上不再出现新评论循环本身对main的零文件编辑。这三条分别验证了部署速度、防重复机制和只读纪律——三者共同构成瘦循环按预期运转的完整证据。十二、升级路径什么时候该长胖瘦循环刻意保持薄但模式文档和模板都给出了明确的毕业方向当积压需要跨运行存活尝试次数、预算、观察清单时升级到 Daily Triage 并添加STATE.md对应起步模板 README 中的指引 starters/minimal-loop-claude当需要模型入环时通过 tools/loop-action 接入 Agent并在任何写操作前引入 loop-verifier当需要尝试次数上限、maker/checker 分离或 token 熔断时参考 PR Babysitter。用 LOOP.md 的话说当队列必须跨运行存活时升级到 Daily Triage 并添加STATE.md。瘦循环不是终点而是让循环以最低成本转起来、并以真实需求驱动演进的起点。相关资源索引模式文档patterns/thin-loop.md起步模板starters/thin-loop含 LOOP.md、README.md、thin-loop.yml模式注册表条目patterns/registry.yaml脚手架实现tools/loop-init/src/cli.tsthin-loop工具无关、免AGENTS.md的逻辑见 L21-L99、L1076-L1083交互式向导tools/loop/src/wizard.ts相关模式Daily Triage、PR Babysitter、loop-verifier 模板、loop-action赞分享人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载相关推荐gs-quant 量化金融回测实战一段脚本跑通均值回归策略看懂 5 个核心指标gs quant 量化金融回测实战一段脚本跑通均值回归策略看懂 5 个核心指标 gs quant 是 Python 量化金融工具包内置回测引擎、触发器与绩人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务用单个 GitHub Action 搭建 L1 只读循环loop-engineering Thin Loop 模式实战用单个 GitHub Action 搭建 L1 只读循环loop engineering Thin Loop 模式实战 Thin Loop 是 loop en人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务MLX JACCLThunderbolt 5 RDMA 分布式通信实战指南MLX JACCLThunderbolt 5 RDMA 分布式通信实战指南 JACCLJack and Angelos Collective Commun人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
