企业官网建设流程全解析

• 人工智能
• AI Agent
• Agent 编排
• AI 技能

本文以仓库内研究文档 docs/loop-engineering-research.md 为主体，结合 oh-my-opencode-slim 仓库源码（src/skills/loop-engineering/SKILL.md、src/skills/worktrees/SKILL.md、src/agents/orchestrator.ts、src/utils/background-job-board.ts 等）展开。你将掌握：Loop Engineering 的完整概念体系（五个构建块 + 持久状态）、Claude Code / Codex / OpenCode 三方的能力对比结论、从 Ralph 最小循环到全量循环工程的演进路径，以及 oh-my-opencode-slim 当前在自动化循环链路中的真实实现水位与缺口。

Loop engineering（循环工程）正在取代"逐条提示编码 Agent"这一交互方式：你不再亲手敲每一条指令，而是设计一套系统，让它自动发现工作、分发给 Agent、核验结果、记录进度并决定下一步——按计划运行，直到目标达成。本文把这一实践拆解为可复用的构建块，并给出可落地的技术方案。

一、什么是 Loop Engineering

Loop engineering 的定义可以用一句话概括：把自己从"提示编码 Agent 的人"替换为"设计提示 Agent 的循环的人"。过去的工作方式是 turn-by-turn 地输入指令；循环工程则要求你构建一个自动化的系统：发现工作 → 交给 Agent → 检查结果 → 记录进度 → 决定下一动作，周而复始，直到目标完成。

这个概念在 2026 年 6 月前后经由两个标志性事件定型：

• Peter Steinberger（OpenClaw 作者，2026-06-07，相关视频播放量约 650 万次）："你不应该再逐条提示编码 Agent，你应该设计循环来替你提示 Agent。"
• Boris Cherny（Anthropic 旗下 Claude Code 负责人，2026-06-05）："我已经不再直接提示 Claude 了。我有正在运行的循环，由它们来提示 Claude 并决定做什么。我的工作就是写循环。"

随后 Google 工程师Addy Osmani发表了给这一实践命名并建立解剖结构的文章，提出"五个构建块 + 记忆（持久状态）"的框架。这一框架构成了本文全部论述的理论骨架，也是 oh-my-opencode-slim 仓库中技能体系、Agent 编排与后台任务设施的设计参照。

二、五个构建块 + 持久状态

Osmani 的框架识别出构成一个循环的五个原语，外加跨迭代持久化的状态。下面逐一展开，并在每个构建块后给出 oh-my-opencode-slim 仓库中的对应实现证据。

1. Automations（触发 + 调度）

作用：按定时器或事件发现工作、做分流（triage），再喂给 Agent 循环。

为什么重要：没有自动化，每次运行仍然要手动启动。自动化是循环获得自治性的关键。

典型形态：Cron 作业、GitHub Actions、事件驱动触发器、定时扫描。

oh-my-opencode-slim 现状：从仓库结构看，自动化这一块仍是最薄弱的环节。研究文档明确将其标记为"Not implemented / Deferred to Phase 4"。仓库中可观察到的是事件驱动的半自动形态：例如 src/hooks/orchestrator-wake/ 会在会话闲置后被唤醒调度器恢复，src/utils/background-job-coordinator.ts 在后台任务终结时协调恢复编排者——这些是"任务完成事件"驱动的内部触发，但面向外部的定时扫描、webhook 级自动发现工作仍未落地。

2. Worktrees（隔离）

作用：让每个并行 Agent 拥有独立的 git checkout，避免多个 Agent 在同一份文件上互相覆盖。

为什么重要：多个子 Agent 在同一分支上并行编辑会产生合并冲突和损坏状态。Worktree 从根上杜绝这一点。

典型形态：git worktree、按线程隔离、按 Agent 分目录。

oh-my-opencode-slim 现状：worktrees 已作为编排者专属技能实现，见 src/skills/worktrees/SKILL.md。该技能定义了完整的"Worktrees Orchestration Protocol"：

• 核心契约：这是 orchestrator-only 工作流。@fixer、@designer等专家可以被派进 worktree 车道干活，但车道规划、分支/路径选择、文件归属、委托、diff 校验、集成与清理全部由 Orchestrator 拥有。
• 默认路径：所有 worktree 统一落在.slim/worktrees/<slug>/，并明确禁止在仓库同级目录创建 worktree。
• 状态追踪：通过可选元数据清单.slim/worktrees.json（version、lanes[]，每个 lane 记录slug、branch、path、base、purpose、owner、status、areas、createdAt）维护结构化追踪。
• 四阶段流程：Planning & Setup（git worktree add -b <branch> .slim/worktrees/<slug> <base>）→ Execution & Delegation（子 Agent 工作目录严格限定在车道内）→ Integration & Validation（先跑最终状态验证计划、展示 diff、经用户确认再集成）→ Cleanup & Pruning（git worktree remove后更新清单状态为archived）。
• 安全护栏：技能内置 pre-flight 检查清单、强制用户确认（对git worktree add/remove、分支创建/删除/改名、merge/rebase/cherry-pick、git prune、git reset --hard等破坏性操作）、以及.gitignore/.ignore双文件的管理块同步（.gitignore忽略.slim/worktrees/，.ignore用!.slim/worktrees/**允许 OpenCode 读取车道文件）。

这与研究文档中"OpenCode 的 worktrees 是 skill-only、prompt 驱动、尚无程序化运行时集成"的判断一致：隔离能力已具备，但还没有像 Claude Code 的--worktree那样成为运行时原语。

3. Skills（项目知识）

作用：把项目约定、构建步骤、领域知识固化成文件，让 Agent 每次运行都读取。这防止"意图债务"（intent debt）——即 Agent 对项目工作方式做出错误猜测。

为什么重要：Agent 每次会话都是"冷启动"。没有书面知识，它就会用自信的猜测填补空白。Skill 是"写一次、每次读"的意图载体。

典型形态：SKILL.md文件、CLAUDE.md、AGENTS.md、项目专属指令。

oh-my-opencode-slim 现状：技能体系是该仓库最成熟的部分，与文档"7 bundled skills"的判断相比，当前仓库技能目录实际更多——src/skills/ 下现包含 9 个技能：clonedeps、codemap、deepwork、loop-engineering、oh-my-opencode-slim、reflect、simplify、verification-planning、worktrees。其中worktrees、loop-engineering、codemap、simplify等均以标准SKILL.md（frontmattername+description+ 正文协议）组织，可被 Agent 在每次运行时直接读取。技能与 Agent 的绑定还受 src/agents/permissions.ts 的权限控制，例如 orchestrator 提示词中@explorer仅授予read_files、@fixer授予read_files, write_files。

4. Connectors（工具集成）

作用：把 Agent 接进真实工具——数据库、API、文件系统、CI/CD、issue 追踪器。

为什么重要：无法作用于真实世界的循环只是思想实验。Connector 给循环装上"手"。

典型形态：MCP 服务器、CLI 工具、API 集成、数据库连接。

oh-my-opencode-slim 现状：仓库的 MCP 设施位于 src/mcp/，包含context7.ts与grep-app.ts两个内建实现文件，经index.ts组装导出（对应文档所称 websearch / context7 / gh_grep 内建 MCP 中的可确认部分）。更重要的是按 Agent 细粒度的 MCP 权限系统：src/config/agent-mcps.ts 支持通配（wildcard）、排除（exclusion）、显式（explicit）三种授权形式，这是 Claude Code 与 Codex 目前都不具备的能力——它们只有"全开或全关"的用户级配置。

5. Sub-agents（Maker/Checker 分工）

作用：把"干活的人"（maker）和"验证的人"（checker）拆开。一个 Agent 提出方案，另一个不同的 Agent 做校验。

为什么重要：让 Agent 给自己打分，等于让学生自己批改考卷。maker/checker 拆分是无监督循环可信的关键。

典型形态：专门的评审 Agent、测试运行器、lint 检查器、oracle 评审者。

oh-my-opencode-slim 现状：子 Agent 体系是文档认定"OpenCode 最强的一块"。仓库中的编排者提示词 src/agents/orchestrator.ts 内置了 7 个可委派专家（@explorer快速代码侦察、@librarian外部知识/文档研究、@oracle架构与评审、@designerUI/UX、@fixer有界实现、@council多模型共识、@observer视觉/媒体分析），加上 Orchestrator 自身构成完整编排体系。maker/checker 的分工被显式编码：执行 Agent 从 fixer/designer/explorer/librarian 中选，验证 Agent 从 oracle/observer/test 中选（见下方 loop-engineering skill）。支撑这一切的运行时设施包括 src/utils/background-job-board.ts（Background Job Board，带 alias 的作业追踪，例如fix-1 / ses_abc / fixer，AGENT_PREFIX 映射fix→fix、ora→oracle等）、src/utils/background-job-persistence.ts（alias 高水位持久化，保证重启后不重用历史 alias）、src/tools/cancel-task.ts（task_cancel工具）、src/tools/task-result.ts、src/tools/task-status.ts、src/tools/task-revive.ts 与 src/tools/task-message.ts。

Plus: Durable State（持久状态 / 记忆）

作用：在循环迭代之间持久化"试过什么、通过了什么、还有什么未决"。状态存在磁盘上，而不是上下文窗口里。

为什么重要：模型在会话之间会遗忘，但仓库不会。状态文件、git 历史、进度日志就是循环的长期记忆。

oh-my-opencode-slim 现状：仓库的持久化证据分散在多处：src/utils/background-job-persistence.ts 负责 Background Job Board 记录的跨进程持久化（包括 alias 高水位）；src/skills/worktrees/SKILL.md 的.slim/worktrees.json清单；以及 src/skills/reflect/SKILL.md 这类让 Agent 把发现写回仓库的技能。这些正是"状态在磁盘、不在上下文"原则的工程化体现。

三、工具对比：Claude Code vs Codex vs OpenCode

研究文档对三方在六个维度做了逐项对比。以下六张表格完整收录，并补充 oh-my-opencode-slim 仓库中可验证的实现事实。

Automations / 调度

结论：Claude Code 与 Codex 都交付了完整的自动化原语；OpenCode（即本仓库 oh-my-opencode-slim）的循环引擎在 spec 中已完整设计但尚未实现。

Worktrees（隔离）

结论：Claude Code 与 Codex 把 worktree 作为与循环引擎集成的运行时原语；OpenCode 的 worktree 是带 apply-patch 支持的 orchestrator 技能，尚无程序化运行时集成。仓库侧证据见 src/skills/worktrees/SKILL.md 与 src/hooks/apply-patch/ 目录。

Skills（项目知识）

结论：三者都有成熟的技能系统。OpenCode 的尤为丰富——仓库技能库现含 9 个内建技能目录（src/skills/）、按 Agent 的权限控制（src/agents/permissions.ts），以及插件更新时的自动同步机制（src/hooks/auto-update-checker/skill-sync.ts）。

Connectors / MCP

结论：三者都支持 MCP。OpenCode 的差异化在于内建 MCP（context7、grep-app 等）与精细的按 Agent 权限系统（src/config/agent-mcps.ts）。

Sub-agents（Maker/Checker 分工）

结论：三者都支持子 Agent。OpenCode 的结构化程度最高——多专家编排体系、正式的 Background Job Board、会话复用（src/utils/background-job-board.ts 中的 Reusable Sessions 语义与 alias 复用，如task_id: "fix-1"或task_id: "ses_abc"续用既有会话）、以及一个"从不亲自实现、只做派发与校验"的专属 Orchestrator（src/agents/orchestrator.ts 的角色定义："You are a workflow manager for coding work... You are not the default implementation worker."）。

Loop Engine（迭代原语）

结论：Claude Code 与 Codex 已有可工作的循环原语；OpenCode 的循环引擎在 spec 中完整设计（Orchestrator → LoopEngine → Specialists 三层架构）但尚未实现。重要更新：从当前仓库看，该 spec 已经以技能形式部分落地——src/skills/loop-engineering/SKILL.md 提供了循环运行时的交互协议（详见下一节），且 Background Job Board 的数据结构（BackgroundJobRecord）已内置totalErrors、timeoutCount、lastErrorAt等收敛信号字段。

四、Ralph 技术：最简单的循环

Ralph 是什么

Ralph Wiggum 循环是循环工程的一个具体实现模式。由 Geoffrey Huntley 于 2025 年 7 月以《辛普森一家》角色 Ralph Wiggum（"I'm in danger!"）命名。它是最简单的循环：

while :; do cat PROMPT.md | claude; done

其最纯粹的形式就是一个 Bash 循环——仅此而已。

工作原理

1. 定义 PRD（产品需求文档），内含小而原子的任务项
2. 编写 PROMPT.md，指示 Agent 读取 PRD 并只做其中一个任务
3. 运行循环——每次迭代都生成一个上下文干净的全新 Agent 实例
4. 记忆通过磁盘持久化——git 历史、progress.txt、prd.json在迭代间存活
5. 完成即停——Agent 发出完成信号，或命中最大迭代上限

四条原则

1. 每次迭代 = 全新上下文。Agent 不记得上一次迭代。只有 git 历史、progress.txt 和 prd.json 持久存在。
2. 保持任务小。每个 PRD 条目必须能装进单个上下文窗口。"构建整个 dashboard"太大；"给列表加一个筛选下拉框"才是合适的粒度。
3. 更新 AGENTS.md。每次迭代结束时把发现的模式与注意事项写回去，下一次迭代会读到它们。
4. 失败即数据。确定性失败意味着失败是可预测、有信息量的，循环从中学习。

Ralph 与全量循环工程对比

何时用 Ralph

• 任务定义清晰且由测试驱动
• 想要最大限度的简单
• 愿意手动审查 diff
• 代码库足够小，可承受每次迭代的全新上下文
• 想今天就零配置开始循环工程

何时用全量循环工程

• 任务需要跨多文件并行工作
• 需要自动化验证（maker/checker）
• 工作跨越多天或多个会话
• 需要成本控制与预算管理
• 代码库庞大且上下文沉重

五、oh-my-opencode-slim 的循环工程现状

现状盘点

已设计但尚未构建（或已部分落地）的内容

规划中的循环工程运行时包括（括号内为仓库当前可确认的对应物）：

• LoopEngine 类：事件驱动编排 —— 尚无独立类实现，但 src/utils/background-job-coordinator.ts 与 src/hooks/orchestrator-wake/ 提供了事件驱动的任务协调与唤醒基础
• LoopSession 状态机（executing ↔ verifying 二元振荡）—— 设计文档所述；BackgroundJobRecord.state已在运行级别实现running / completed / error / cancelled / stopped / reconciled的转换
• SuccessCriterion 路由（test、build、lint、fileExists、command、oracle、observer）—— src/skills/loop-engineering/SKILL.md 的 success type 列表已覆盖 test、build、lint、command、fileExists、oracle、observer，并额外加入manual
• 收敛信号（totalErrors、timeoutCount、lastErrorAt）—— src/utils/background-job-board.ts 的BackgroundJobRecord已内置这三个字段，且在applyStatus中实现递增逻辑
• .loop-history.md 上下文压缩—— 未在仓库中确认
• Layer 0 仅限 @council 的升级—— src/agents/council.ts 与@council专家描述（多模型共识引擎）已存在
• 分阶段发布：Phase 1（运行时引擎）→ Phase 2（loop 技能）→ Phase 3（routine 集成）→ Phase 4（触发器）→ Phase 5（持久记忆）—— 其中 Phase 2 的 loop 技能已在仓库落地

循环技能的实际协议（Grill + Loop Monitor）

仓库已实现的 src/skills/loop-engineering/SKILL.md 是目前离"循环运行时"最近的落地物，它定义了完整的两段协议：

Grill（编排者访谈）——循环启动前的需求采集：

1. Goal："你想完成什么？"
2. Success criteria："描述我们如何判断循环成功。"
3. Success type：从test、build、lint、command、fileExists、oracle、observer、manual中选择。CLI 步骤提供successCommand；文件检测提供successPath。
4. 执行 Agent：fixer / designer / explorer / librarian
5. 验证 Agent：oracle / observer / test
6. 最大尝试次数（默认 3）
7. 可选上下文文件：执行前应读取哪些文件或目录？

Loop Monitor（循环监视）——运行期回调协议：

• 监听回调：onLoopComplete(loopID, success)上报最终结果；onEscalated(loopID, reason)升级给人类；onManualReview(loopID, reason)提示人类批准/否决并调用resolveManualReview(loopID, passed, reason)
• 每次回调展示当前状态与尝试次数
• 人工验证时先展示失败原因再请求通过/否决
• 人类强制取消时经 orchestrator 调用cancel(loopID)

技能注释里还有两条关键设计决策值得注意：manual 验证是最小入门（autoresearch 模式），它暂停循环直到resolveManualReview被调用、绝不自动放行；以及BackgroundJobBoard 的收敛信号（totalErrors、timeoutCount）已经内置到运行时——这与研究文档"收敛信号已设计"的判断一致，说明技能协议与实际数据结构是打通的。

缺口

按研究文档的判断：OpenCode 的五个构建块中已有三个完全打通（skills、connectors、sub-agents），worktrees 是技能形态，automations 与循环引擎仍停留在 spec。子 Agent 基础设施是最强的一环——Background Job Board、会话复用、原生深度追踪都比 Claude Code 或 Codex 暴露的更加结构化。

缺失的外层循环是调度器本身：那个按定时器运行、生成工作、并在无人干预下持续前进的组件。一旦它落地（spec 的 Phase 1-2），oh-my-opencode-slim 将拥有完整的循环工程栈。就当前仓库而言，loop-engineering 技能 + Background Job Board 收敛信号已经为这个外层循环准备好了接口协议与数据结构。

六、案例研究：Andrej Karpathy 的 autoresearch

autoresearch（2026 年 3 月）是循环工程最纯粹的真实世界实现：一个极简的自主 AI 研究框架。一个待编辑的 Python 文件（train.py）、一个固定评估框架（prepare.py）、一个驱动 AI Agent 无限实验循环的 Markdown "技能"文件（program.md）。

工作方式

1. Agent 读取program.md，其中定义了LOOP FOREVER构造
2. Agent 用一个实验想法修改train.py
3. 在单张 GPU 上运行 5 分钟训练实验
4. 评估验证集 bits-per-byte（BPB）
5. 若有提升：保留提交、推进分支
6. 若持平或更差：git 回退到之前状态
7. 无限重复（约 12 个实验/小时，每晚约 100 个）

映射到五个构建块

与 Ralph 及全量循环工程的对比

关键经验

1. 技能文件是最重要的一块。program.md定义了循环、成功标准与失败处理。没有它，Agent 根本不知道该做什么。
2. 对许多循环来说，git 就是足够的记忆。无需复杂的状态管理。提交历史本身就是状态。
3. 固定的时间预算让实验可比较。无论 Agent 改了什么，每个实验都精确运行 5 分钟。这对公平评估至关重要。
4. 快速失败防止浪费算力。NaN 或爆炸性 loss（>100）立即退出。没必要跑 5 分钟垃圾。
5. Agent 可以自己当调度器。对简单循环，无需外部 cron。Agent 跟随循环指令持续前进。
6. 最小可行循环 = 技能 + git + 评估。不必凑齐完整五块积木才能从循环工程中获得价值。从简单开始，当任务需要时再增加复杂度。

值得对照的是：oh-my-opencode-slim 的 src/skills/loop-engineering/SKILL.md 明确把manual 验证称为"最小入门（autoresearch 模式）"——即用一个会暂停等人确认的resolveManualReview回调来模拟 autoresearch 的"人审 diff"环节，这正是把上述"最小可行循环"经验翻译成工程协议的直接证据。

七、关键结论

1. 转变是真实的。最流行编码 Agent 的构建者们已经停止手工提示。杠杆从模型转移到了模型外围的循环。
2. 五块积木正在趋同。Claude Code 与 Codex 交付了近乎相同的原语。这个模式正在变得与具体工具无关。
3. Ralph 是最简单的入门。想今天就启动循环工程，一个 Bash 循环 + PRD + git 历史就足够。当复杂度要求时再升级到全量循环工程。
4. 技能才是资产。一个内部没有可复用技能的循环，只是对一个陌生人的 while-true。要构建值得调用的技能。
5. 成本是当前的瓶颈。token 消耗随循环迭代线性增长。预算上限是强制的，不是可选的。
6. oh-my-opencode-slim 大约完成了 60%。Skills、Connectors、Sub-agents 已成熟；loop 技能与 Background Job Board 收敛信号已落地；循环引擎与 automations 已设计但未实现。子 Agent 基础设施是整个栈中最强的一环——带 alias 追踪的 Background Job Board、会话复用与原生深度追踪都比 Claude Code 或 Codex 暴露的更结构化。
7. autoresearch 证明了最小可行循环。不需要完整五块积木。一个技能文件 + git + 评估指标就足以让自主实验运行一整晚。从简单开始，任务需要时再增加复杂度。

本文事实来源：研究文档 docs/loop-engineering-research.md（汇总了 2026-06-27 前后九个平台的公开讨论：Reddit、X、YouTube、TikTok、Instagram、Hacker News、GitHub、Digg 与 Web，涉及 Addy Osmani、Peter Steinberger、Boris Cherny、Geoffrey Huntley、Andrej Karpathy 等人的公开言论与项目）；仓库源码佐证集中于 src/skills/、src/agents/、src/utils/、src/mcp/、src/config/ 与 src/tools/ 目录。文中关于各工具能力对比的表述以研究文档结论为准，oh-my-opencode-slim 的具体实现状态以当前仓库实际内容为准。

• 人工智能
• AI Agent
• Agent 编排
• AI 技能