6.3 KiB
6.3 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Loop Engineering | 2026-06-29 | 2026-06-30 | concept |
|
|
medium |
Loop Engineering
Loop engineering は、LLM やエージェントを「人間が毎回プロンプトする道具」としてではなく、自分で次の仕事を見つけ、隔離された実行先へ渡し、別の評価者に検証させ、結果を永続化し、次回実行へつなぐループとして設計する考え方。PDF「Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents」は、prompt / context / harness engineering の上に来る第四層としてこの概念を置いている。
中心になる 1 ターンは、discovery、handoff、verification、persistence、scheduling の 5 段階。これは wiki-maintenance-loop の ingest / query / lint / log / cron にかなり近く、Discord link ingest のような自動キュレーションでは、リンク発見だけでなく評価基準、重複検出、raw 保存、wiki 更新、状態ファイル更新までを同じループの一部として扱う必要がある。
設計上の要点
- Generator / evaluator separation: 生成したエージェント自身に採点させると甘くなりやすい。別プロンプト、別モデル、別プロセスの「疑う評価者」を置く方が、ai-assisted-reverse-engineering の命名・型付け検査や wiki ingest の品質判定にも応用しやすい。
- Persistence first: ループの成果はチャットの返答だけでなく、PR、Issue、wiki、state file、log のような再利用可能な場所に残す。残らない自動化は、次回の discovery と評価に使えない。
- State machine として考える: GitHub の IssueOps 記事は、Issue、label、comment、approval、Action を状態機械として扱う。これは loop engineering の persistence と scheduling を、監査可能な GitHub timeline に置く方法として読める。
- Repository-native loop: agentic-hardware-design の HORIZON は、Markdown harness から evaluator / acceptance predicate / git policy を持つ project pack を作り、隔離された worktree 上の diff・commit・log・notes をそのまま探索 trace にする。ループの状態を外部データベースに逃がさず、作業対象の repository 自体に残す設計として重要。
- Operator observability: abtop は Claude Code、Codex CLI、OpenCode の session、token、context、rate limit、child process、open port をローカルで可視化する。複数 agent を同時に回す loop では、成果物だけでなく「いま何が動いているか」「どの資源を占有しているか」も運用対象になる。
- Agent-native work surface: kiro の Agent Focus は、コード編集画面ではなく session、会話、spec、diff を前面に置く。loop を IDE の中に寄せると、人間の仕事は直接編集よりも、仕様・承認・差分確認・権限ルールの管理へ移る。
- Agent harness minimalism: pi-coding-agent は、read / write / edit / bash、tmux、明示的な session file など既存の可視な道具に寄せることで、隠れた sub-agent や巨大な system prompt に頼らない loop を作ろうとする。loop の強さは機能数だけでなく、operator が context、tool result、process、cost をどこまで観測できるかにも依存する。
- Worktrees as everyday agent infrastructure: GitHub Desktop 3.6 の worktree support は、agent が複数 branch / sandbox を使う流れを GUI 側にも取り込む。isolated worktree は agentic-hardware-design や IssueOps 的な repository-native loop と同じく、並列作業を見える単位に分けるための基礎部品になる。
- Evaluator market pressure: ai-evaluation-infrastructure の Arena 事例は、評価が研究用 leaderboard から商用分析・post-training 改善の基盤へ広がっていることを示す。loop engineering でも、実行する agent だけでなく、それを測る evaluator とデータ収集の設計が競争力になる。
- Agent-oriented tools: agent-oriented-cli-design は、JSON first、actionable error、search/read 分離、鮮度情報、少ないフラグを通じて、agent が推測せずに次の行動へ進める CLI を作る考え方。loop の実行単位である tool が曖昧だと、verification や persistence 以前に誤った状態で進んでしまう。
- Human judgment is scarce: 生成は安くなっても、何を通し、何を止め、何を記録するかの判断は希少になる。自動化は人間の判断を消すのではなく、判断すべき点を狭く明確にするべき。
Failure Modes
- Nodding loop: 自己承認しているだけで、独立した検証がない。
- Amnesiac loop: 前回の状態、失敗、採用・却下理由が保存されず、毎回同じ判断をやり直す。
- Manual loop: 実行自体が人間の思いつきに依存し、定期実行・イベント駆動になっていない。
- Blind loop: 何を探すか、何を高く評価するかが固定され、発見結果から rubric が改善されない。
- Tangled loop: 並列エージェントや自動 PR が同じ資源を同時に触り、検証や rollback が追いつかない。
Open Questions
- Hermes の scheduled job では、どの変更を即時実行し、どの変更を review item として止めるべきか。
- ai-agent-identity-security のような認可・監査の標準を、個人用エージェントのローカル自動化にもどう縮小適用するか。
- IssueOps や llm-wiki-pattern のような永続メディアを、チャット駆動の一時的な作業とどう接続するか。