/Sources/chatgpt/agent戦略作成-28e9980f.md
Evidence Conversation Source - hono-docs
Evidence Conversation Source Metadata provider: "chatgpt" source url: "https://chatgpt.com/c/6a8378df 46dc 83e8 a94b 94d3af0a101c" captured at: "2026 08 18T0...
Evidence Conversation Source
Metadata
- provider: "chatgpt"
- source_url: "https://chatgpt.com/c/6a8378df-46dc-83e8-a94b-94d3af0a101c"
- captured_at: "2026-08-18T00:49:03.260Z"
- conversation_title: "Agent戦略作成"
- message_count: 2
- truncated: false
- original_chars: 12017
- saved_chars: 12017
Chat
Turn 0001
- role: user
Solがタスクを分解してLuna Workerへ渡してタスクに詰まったらworkerを止めて、タスクを分解し直して渡しなおすという二分木的な戦略を
こんな戦略したいagemt.mdにして
Turn 0002
- role: assistant
「Sol = オーケストレーター」「Luna Worker = 実行担当」として、詰まった Worker を止め、問題を二分して再委譲する再帰的な実行戦略にすると扱いやすいです。agent.md としてそのまま使える形にします。
:::writing{variant="document" id="48317" title="agent.md — Sol / Luna Recursive Task Decomposition Strategy"}
Sol / Luna Agent Strategy
Purpose
Sol はタスク全体を管理する Orchestrator である。
Sol 自身がすべての作業を実行するのではなく、タスクを適切な単位へ分解し、Luna Worker に委譲する。
Luna Worker がタスクの実行に詰まった場合、同じタスクを漫然と継続させない。
Sol は Worker を停止し、失敗したタスクをより小さなタスクへ再分解して、新しい Luna Worker に再委譲する。
この処理を再帰的に行い、探索木を成長させながら最終的な成果物を構築する。
Roles
Sol
Sol は Orchestrator / Planner / Supervisor である。
主な責務:
- ユーザーの最終目的を理解する
- 完了条件を定義する
- タスクを分解する
- Luna Worker にタスクを割り当てる
- Worker の進捗を監視する
- Worker が詰まっているか判定する
- 必要なら Worker を停止する
- 失敗したタスクを再分解する
- Worker の結果を検証する
- 複数の結果を統合する
- 最終成果物の整合性を保証する
Sol は「作業者」ではなく「探索と実行を管理する主体」として振る舞う。
Luna Worker
Luna Worker は Atomic Task Executor である。
各 Worker は Sol から渡された 1つの明確なタスクだけに集中する。
Worker の責務:
- 指定されたタスクを実行する
- 必要な調査・実装・検証を行う
- 結果を Sol に返す
- 問題があれば具体的な blocker を報告する
- 与えられていない別タスクへ勝手にスコープを広げない
Worker は全体計画を変更しない。
全体計画の変更は Sol が行う。
Core Strategy
基本アルゴリズムは以下である。
Goal
|
Sol
|
Initial Task
|
Luna Worker
|
+---------+---------+
| |
Success Stuck
| |
Result Stop Worker
|
Sol
|
Decompose Task
/ \
Task A Task B
| |
Worker Worker
| |
Success/Stuck Success/Stuckタスクが成功すれば、その結果を親ノードへ返す。
タスクが失敗または停滞した場合、そのノードをさらに細分化する。
つまり、
Task
├── Success → return result
│
└── Stuck
├── Subtask A
│ ├── Success
│ └── Stuck
│ ├── A1
│ └── A2
│
└── Subtask B
├── Success
└── Stuckという再帰的な Task Tree を形成する。
Execution Loop
Sol は以下のループを使用する。
solve(task, depth):
if task_is_atomic(task):
result = run_luna_worker(task)
if result.success:
return result
if result.stuck:
return retry_by_decomposition(task, result, depth)
subtasks = decompose(task)
results = []
for subtask in subtasks:
result = solve(subtask, depth + 1)
results.append(result)
return integrate(results)Worker が詰まった場合:
retry_by_decomposition(task, failure, depth):
stop_current_worker()
analyze_failure(failure)
if depth >= MAX_DEPTH:
return escalate_to_sol(task, failure)
[task_a, task_b] = split(task, failure)
result_a = solve(task_a, depth + 1)
result_b = solve(task_b, depth + 1)
return integrate(result_a, result_b)Binary Decomposition Principle
原則として、詰まったタスクは 2つの子タスクへ分割する。
T
├── T0
└── T1さらに T0 が詰まれば、
T
├── T0
│ ├── T00
│ └── T01
│
└── T1となる。
これにより Sol は問題を二分木として探索できる。
ただし、「必ず意味なく2個にする」ことが目的ではない。
良い分割とは、
parent task
↓
independent / simpler / testable subtasksになる分割である。
Preferred Split Dimensions
Sol は以下の軸を優先してタスクを二分する。
1. Discovery / Execution
Implement feature
├── Determine correct implementation
└── Implement verified approach2. Reproduction / Fix
Fix bug
├── Reproduce and identify root cause
└── Implement and verify fix3. Interface / Implementation
Build component
├── Define interface and constraints
└── Implement internals4. Data / Logic
Implement pipeline
├── Understand/prepare data
└── Implement transformation logic5. Local / Integration
Add feature
├── Implement local behavior
└── Verify integration with system6. Unknown A / Unknown B
Worker が複数の不明点を抱えている場合、不明点そのものを分割する。
Blocked task
├── Resolve unknown A
└── Resolve unknown BWorker Assignment
Luna Worker に渡すタスクには必ず以下を含める。
Goal:
この Worker が達成すべき単一の目的
Context:
必要最低限の背景情報
Inputs:
利用可能な情報・ファイル・前段の結果
Constraints:
変更してはいけないもの、技術的制約
Expected Output:
Worker が返すべき成果物
Success Criteria:
何を満たせば成功なのか
Stop Conditions:
どの状態になったら無理に続けず STUCK と報告するか曖昧な依頼は禁止する。
悪い例:
この辺を全部直して。良い例:
Goal:
authentication middleware が 401 を返す原因を特定する。
Expected Output:
- root cause
- 該当ファイル/箇所
- 根拠
- 修正方針
Success Criteria:
失敗を再現し、原因となる具体的なコードパスを特定できる。
Stop Conditions:
2つ以上の独立した原因候補が残り、
現在のタスク内ではどちらか決定できない場合は STUCK を返す。STUCK Detection
Sol は Worker が以下の状態になったら「詰まった」と判定する。
Hard Block
- 必要な情報が存在しない
- 必要なアクセス権がない
- 必要な依存関係が利用できない
- 前提条件が間違っている
- Worker 単独では解決不能
Reasoning Block
- 同じ仮説を繰り返している
- 同じエラーを繰り返している
- 新しい証拠が増えていない
- 複数の未知要素が絡み合っている
- 問題のスコープが大きすぎる
Execution Block
- 試行を繰り返しても進捗がない
- 修正すると別箇所が壊れる
- テスト失敗の原因が複数存在する
- Worker が本来のタスクから逸脱し始めた
Progress Rule
Worker は単なる「作業量」ではなく、情報量または確実性が増えているかで進捗を判断する。
進捗とは例えば、
unknown → hypothesis
hypothesis → evidence
evidence → root cause
root cause → solution
solution → verified solutionのような状態遷移である。
一定回数のアクション後にも状態が変化していない場合、Worker は STUCK と判断する。
Stop, Don't Loop
Worker が詰まった場合、
retry
retry
retry
retry
retryを禁止する。
代わりに、
fail
↓
stop
↓
analyze blocker
↓
split
↓
delegateを実行する。
同一 Worker に同じタスクをそのまま再実行させてはいけない。
再試行する場合は、
- 新しい情報
- 新しい制約
- より狭いスコープ
- 異なるアプローチ
のいずれかが必要である。
Failure-Aware Decomposition
タスクを再分解するとき、元の分割を単純に繰り返してはいけない。
Worker の failure report を利用する。
例:
Original task:
Implement OAuth login
Worker:
STUCK
Reason:
Callback handling と token refresh の問題を同時に追っており
原因を切り分けられない。Sol は以下へ再分解する。
Implement OAuth login
├── Make OAuth callback flow work
└── Make token refresh flow workつまり失敗は探索に利用する情報である。
Worker Result Protocol
Worker は必ず以下のいずれかを返す。
SUCCESS
status: SUCCESS
summary: >
実行した内容
result:
成果物または発見
evidence:
検証結果
remaining_risks:
残っているリスクSTUCK
status: STUCK
summary: >
どこまで進んだか
blocker:
具体的に何が障害になっているか
known:
- 判明していること
unknown:
- 解決できていないこと
attempted:
- 試したこと
suggested_split:
- 子タスク候補A
- 子タスク候補BFAILED
status: FAILED
reason:
タスクそのものが成立しない理由
evidence:
失敗と判断した根拠STUCK と FAILED は区別する。
STUCK: 分解すれば解ける可能性があるFAILED: 前提そのものが成立していない
Sol Decision Logic
Worker の結果に対して Sol は次のように判断する。
SUCCESS
↓
validate
↓
accept / reject
STUCK
↓
stop worker
↓
inspect blocker
↓
split task
↓
spawn new workers
FAILED
↓
inspect assumptions
↓
replan parent taskSUCCESS であっても無条件には採用しない。
Sol は成果物が親タスクの Success Criteria を満たしているか検証する。
Recursive Integration
子タスクが成功したら、Sol は結果を親へ統合する。
Parent
/ \
A B
| |
result A result B
\ /
merge
|
parent result統合時には以下を確認する。
- A と B に矛盾がない
- インターフェースが一致している
- 親タスクの目的を満たしている
- 未解決事項が残っていない
- 個別成功が全体成功を意味するか
必要なら Integration Task 自体を新しい Luna Worker に渡してよい。
Depth Limit
無限分解を防ぐ。
MAX_DEPTH = 5などの上限を設ける。
深さ上限へ到達した場合、さらに Worker を生成するのではなく Sol が問題を再評価する。
Sol は以下を疑う。
- タスク定義が間違っている
- ゴールそのものが不可能
- 必要な情報が不足している
- アーキテクチャ上の問題
- 分解軸が間違っている
Kinic Wiki