企业官网建设流程全解析

• 人工智能
• AI Agent
• Agent 工作流
• CLI
• 研发协作
• AI 技能
• MCP 服务

本文基于 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）

模式文档明确给出三个典型信号：

1. 本周就要一个循环，而不是安装一套方法论——追求的是尽快让循环转起来；
2. 工作内容就是 PR 审查或 Issue 快照——没有需要持久化、而 GitHub 本身又没有存储的数据；
3. 后续"如果需要"再补STATE.md——当发现某个发现需要跨运行存活（例如积压任务、尝试次数、预算），再升级。

不适用场景（Do NOT start here）

文档明确划出红线：如果你需要以下能力，不要从这里开始，而应改用 Daily Triage 或 PR Babysitter：

• 尝试次数上限（attempt caps）；
• maker/checker 分离（即执行者与检查者分离的职责划分）；
• Token 熔断开关（token kill switch）。

原因很直接：这些能力都依赖跨运行的持久化状态，而瘦循环刻意不维护状态。

三、调度策略与 L1 定位

模式文档给出瘦循环的调度表面：

第一周定位为L1：工作流只向$GITHUB_STEP_SUMMARY写入快照；只有当触发的 issue/PR 线程上**还没有瘦循环标记（marker）**时，才评论一次。

起步模板的 LOOP.md 把这一定位浓缩为一页：

• Pattern: thin-loop
• Level: L1 report-only
• Cadence:issues/pull_requestopened + 工作日 08:00 UTC
• State: 无。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.md（tools/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 即可。

你会得到什么 / 刻意不给你什么

起步模板明确列出了"刻意不给"的三样东西（starters/thin-loop/README.md）：

• STATE.md——当发现需要跨运行持久化时再加（升级方向见 minimal-loop-claude）；
• Agent 调用——之后如需模型入环，可接入 tools/loop-action；
• 高 Loop Ready 评分——文件落盘数量不是这里的目标。

五、工作流解剖：一份完整可运行的 thin-loop.yml

瘦循环的全部实现都集中在一个文件里：starters/thin-loop/.github/workflows/thin-loop.yml。下面是它的四个关键组成部分。

1. 触发条件（on）

on: 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. 权限声明（permissions）

permissions: contents: read issues: write pull-requests: write

这是最小权限集：contents: read用于actions/checkout；issues: write与pull-requests: write用于发布评论。模式文档的失败模式表中特别强调：空快照问题往往就是gh鉴权问题，工作流必须带issues: write/pull-requests: write——缺了写权限，gh命令会失败。

3. 快照步骤（Snapshot open work）

- uses: actions/checkout@v4 - 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，不需要单独创建 PAT；
• gh 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 -->' ...

核心逻辑是"标记防重"：

1. 从事件环境变量中取出 issue/PR 编号；
2. 用gh api "repos/${{ github.repository }}/issues/${NUMBER}/comments"拉取该线程全部评论；
3. 用grep -q 'thin-loop'检查是否已存在标记<!-- thin-loop -->，存在则直接跳过（防止评论轰炸，对应模式文档失败模式表中的"Comment spam"一行）；
4. 不存在则写入一条 L1 评论，内容包含标记、快照链接（指向本次 Actions run）以及"本运行不打标签、不关闭、不编辑代码"的声明；
5. 按 kind 分别调用gh issue comment或gh pr comment。

需要留意一个细节：步骤只对事件驱动的触发（issue/PR 打开）评论，而 cron 定时快照只写 summary，不评论——避免每天 08:00 给所有历史线程重复刷评论。

六、典型循环周期（Typical cycle）

模式文档给出了 5 步标准周期：

1. 事件或工作日 cron 触发；
2. 工作流用gh列出所有 open 的 PR 和 issue；
3. 快照写入 Job Summary；
4. 如果事件来自某个 issue/PR，则在其线程上发布一次简短 L1 评论（仅一次）；
5. 人类阅读 summary 或评论。循环不编辑代码、不自动合并。

对应到注册表的阶段定义（patterns/registry.yaml）：snapshot → summarize → optional-comment，其中 "optional"（可选）正是指评论只在事件触发且无标记时才发生。

七、所需技能与工具说明

技能（Required Skills）

模式文档的关键结论：L1 阶段不要求任何技能，工作流只用gh。

• loop-triage——可选，仅当你之后要通过 loop-action 把 Agent 接入 Action 时才需要；
• loop-verifier——可选，但在任何写操作之前是必须的；一旦存在实现者（implementer），maker/checker 分离依然适用。

需要强调的是：验证器技能模板见 templates/SKILL.md.verifier，其核心思想是"maker/checker，而不是同一会话给自己作业打分"。

状态文件与成本画像

• State file：不需要。GitHub issues/PR 承载积压；可选地，一行loop-run-log.md记录可作为 Loop Ready 活动评分的证明。
• 成本画像（来自 patterns/registry.yaml）：token_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: 0（L1 阶段零衍生任务），印证了它极低的开销定位。

运行时选择

• 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，但不要让循环打标签、关闭或推送。"

十、失败模式速查表

模式文档给出三张最常见的失败场景与对策：

前两行已经在上文的工作流解剖中给出源码级对应（标记防重逻辑与permissions声明）；第三行则提醒团队管理预期：低评分不是缺陷，而是刻意取舍。

十一、成功指标（Success Metrics）

模式文档给出三条可量化的成功标准：

1. 合并后 10 分钟内出现首个绿色工作流运行；
2. 已有标记的线程上不再出现新评论；
3. 循环本身对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.ts（thin-loop工具无关、免AGENTS.md的逻辑见 L21-L99、L1076-L1083）
• 交互式向导：tools/loop/src/wizard.ts
• 相关模式：Daily Triage、PR Babysitter、loop-verifier 模板、loop-action

• 人工智能
• AI Agent
• Agent 工作流
• CLI
• 研发协作
• AI 技能
• MCP 服务