r/openclawの開発者が、OpenClawにおけるマルチエージェントチームでの作業における思考モデルの転換について述べています。当初、サブエージェントを名前やバックストーリーを持ち、記憶を期待されるジュニア従業員のように扱ったことで、数週間にわたる混乱とワークフローの崩壊を招きました。

関数のアナロジー

突破口は、サブエージェントが「ミニ・自分」や永続的なチームメンバーではなく、関数であると認識することから生まれました。具体的には：

• サブエージェントは永続的なチームメンバーではなく、ステートレスな関数呼び出しである
• 開発者のジュニア版ではなく、専門化されたツールである
• コンテキストを記憶せず、純粋な入力→出力で動作する
• 互いに話すのではなく、呼び出し元に値を返す

ソースでは、間違ったアプローチと正しいアプローチを対比するコード例を提供しています：

# 間違い：サブエージェントを永続的なオブジェクトとして扱う
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Frankが記憶していると仮定

正しい：サブエージェントを関数呼び出しとして扱う
result = frank_task(
  instructions="ログインページを構築",
  context={"requirements": reqs, "design": mockup}
)
frank_taskが実行され、出力を返し、終了する

実践的な意味合い

この思考モデルの転換には、いくつかの具体的な意味合いがあります：

1. SOUL.mdを関数のドキュメンテーションとして：性格プロファイルではなく、SOUL.mdは仕様書になります：

# frank_task()
目的： Next.jsの機能を構築する
入力： 要件（辞書型）、デザイン（オプション）
出力： {コード、テスト、メモ}
制約： 承認なしの外部API呼び出しは禁止

2. 反復処理のための明示的な状態受け渡し：サブエージェントはコンテキストを記憶しないため、必要な情報はすべてパラメータで渡す必要があります：

# 間違い
frank_fix("バグを修正") # 生成、試行、終了
frank_fix("まだ壊れている") # 新規生成、コンテキストなし

正しい
result = frank_fix({
  "code": previous_output,
  "issues": ["ログイン検証が失敗", "モバイルCSSが壊れている"],
  "test_cases": failing_tests
}) # パラメータに完全なコンテキストを含める

3. コーディネーターをメインプログラムとして：開発者はチームマネージャーではなく、オーケストレーター関数になります：

def build_feature(spec):

関数を順番に呼び出す
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # 明示的なコンテキストで反復処理
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

ソフトウェア設計との類似点

このアプローチは、確立されたソフトウェア設計原則と一致しています：

• 単一責任：各サブエージェントは一つのことを行う
• 純粋関数：同じ入力→同じ出力
• 単体テスト可能：各サブエージェントの出力を独立してテストできる
• 合成可能：quinn_test(frank_code(spec))のようにサブエージェントを連鎖できる
• ステートレス：隠れた依存関係がない

開発者は、価値が「エージェントが多いほど賢い」ではなく「専門化された関数＝よりクリーンなアーキテクチャ」であると指摘しています。

転換後の結果

このモデルを採用した後、開発者は以下を構築しました：

• 2週間で11,249件のジムデータベース
• 5つの汎用エージェントではなく、5つの専門化されたエージェント
• 引受ワークフローを備えたCRM
• 日々のMoltbookエンゲージメント

これらすべてが、ステートレスなサブエージェントとコンテキストを維持するコーディネーターを使用して実現されました。