Chimera — アーキテクチャ

このドキュメントは、コードベースを設計と、その基盤となる研究にマッピングします。「なぜ」については、VISION.mdを参照してください。

推論コア: LLM-Fusion

chimera/fusion/

フュージョンエンジンはタスクをモデルのパネルに通し、ジャッジに構造化された分析(合意点/矛盾点/部分的なカバレッジ/独自の洞察/盲点)を作らせ、その後シンセサイザーがその分析に基づいて最終的な回答を書きます(FusionEngine)。これは SupportsComplete プロトコルを実装しているため、モデルが期待される場所ならどこでも — エージェントループの内部を含め — 差し替え可能な推論バックエンドとなります。

コスト意識型ルーター(RoutedBackend + RoutingPolicy)は、フュージョンを選択的に保ちます: ツール呼び出しのターンは単一のモデルに送られ(フュージョンはツール呼び出しを行いません)、深い/高リスクな推論ターンだけがフュージョンされます。OpenRouter Fusion(その向上は合成ステップから来るのであって、モデルの多様性だけからではない)とAURORA-AI(異種モデル間の適応的な予算配分)に着想を得ています。

エージェントループとTier-2の自律性

chimera/core/

• Agent — 明示的なトランスクリプト(状態はモデルの外部に存在する)を持つ、最小限のReAct/ツール呼び出しループ。SupportsComplete + ToolRegistry のみに依存します。
• AutonomousAgent — Tier-2: 所有権スコープ付きのSpineコンテキストの組み立て → 計画 → スナップショット → 実行 → マネージャーレビュー(生成 vs 検証) → 検証または差し戻し → フィードバックによる再試行。各試行は経験バッファに記録されます。
• WorkspaceGuard — テキストファイルのスナップショット/復元。検証または差し戻しの背後にある仕組みです。
• CommandVerifier — 「実行可能な証拠」(終了コード0 == 成功)。

継続的進化における劣化への対処

未解決の問題(Agentic Software、2606.05608 による): 独立したタスクでの80%超から、継続的な進化では約38%へと性能が低下します — これは長期にわたるコンテキストとエラーの伝播によるものです。Chimeraの対抗策は、それぞれが文献に根拠を持ちます。

対抗策	場所	根拠
状態の外部化(LLMコンテキストではなく、トランスクリプト/ワークスペース)	core、WorkspaceGuard	HORIZON 2606.28279
所有権スコープ付きコンテキスト(Spine)	core/spine.py	Spec Growth Engine 2606.27045
生成 vs 検証の監督	core/supervisor.py	AdvancedShelLM 2606.27990
検証または差し戻し	core/autonomous.py	autoresearch / AutoMegaKernel 2606.09682
経験バッファ(失敗をネガティブとして扱う)	evolution/experience.py	HORIZON 2606.28279
チーム内でのメッセージ統合	orchestration/comms.py	MOC 2606.02359
継続的進化ベンチマーク	eval/continuous.py	EvoClaw problem statement

メモリと自己進化

chimera/memory/、chimera/evolution/

• メモリマネージャー — 階層化されたアイテム(working / episodic / semantic / persona)で、ADD / UPDATE / DELETE / NOOP(remember)と merge による重複排除を行います(Memory-R1、2606.14502)。
• スキルエボルバー — SkillEvolver は成功事例から再利用可能な LearnedSkill を提案し、テストし、合格した場合のみ保持します(提案 → テスト → 保持/破棄)。学習されたスキルはプロンプトテンプレートであって、実行可能なコードではありません — コードレベルの自己修正の前段階として自律的に作成するのに安全です。改良はテンプレートをその失敗から改善します(VIBEMed 2606.15504)。
• 自己学習型cron — CronLearner は繰り返されるタスクを検出し、cronを提案します(created_by=agent、人間の承認待ちで無効化されています)。
• 継続的進化ベンチマーク — 一連のタスクをソルバーに通し、劣化(全体の合格率、前半 vs 後半、最長連続成功)を報告します。

ガバナンスと安全性

chimera/governance/

自己改善型の信頼カーネル(AgentTrust v2、2606.08539)。

• TrustKernel.evaluate(action) → allow / warn / block / review。字句ベースの RuleSet は固定署名の脅威を決定論的に処理します。オプションのセマンティックジャッジは意図を処理します。蒸留されたルールは時間とともにコストを下げます。不変条件: 良性の行動を決してハードブロックしない。ジャッジとその先例ストアは、出荷されたどの面も配線しないライブラリの継ぎ目です — 2026-09-12 に kernel.py のdocstringにある数値で決定(ルールとtaint台帳は2つのコーパスで 7 / 7 と 6 / 6 をモデル呼び出しゼロでブロック。ジャッジは大半のtool動作にモデル呼び出しと測定済みのバイアスを加えるだけ)。理由を書かずに配線する面があればビルドは失敗します。
• SkillValidator / ScheduleValidator — 自己修正のための制約された、静的にチェック可能な編集面(AutoMegaKernel 2606.09682): 安全でない提案は実行される前に拒否されます。
• AuditLog — 決定と進化の変更の追記専用JSONL。
• GovernedTool / govern_registry — 任意のtoolをラップし、その実行をゲートします。既存のエージェントループに変更なしで組み合わさります(chimera ... --guard)。

汚染層(プロンプトインジェクションの封じ込め)

カーネルの上に重ねられます — ヒューリスティックで、正直で、決してハードな境界ではありません(それはサンドボックスの役割です)。

• TaintLedger + LedgeredTool(ledger.py、ledger_tool.py) — 実行ごとのケーパビリティ台帳。取得(fetch)はそのコンテンツを汚染し、汚染されたコンテンツを消費する書き込み/実行はレビューへエスカレートします(assess_action)。信頼できない取得コンテンツはデータフェンスされた状態で、チャットテンプレートの制御トークンが除去されて(sanitize.py)返されます。汚染された実行から生まれた永続的な成果物は tainted という出所情報を保持するため、毒が「クリーンな」メモリ/スキルに紛れ込むことはできません。
• AggregateMonitor(aggregate_monitor.py) — 1段上のモニター: 各サブエージェントのケーパビリティイベントを踏まえ、エージェントごとのモニターでは見えない分割フローを捕捉します(エージェントAが信頼できないコンテンツを取得し、エージェントBがそれを実行または持ち出す)。
• check_drift(drift.py) — 実行可能な要件の Spec(defines/contains/absent/command)で、solve --verify のグラウンドトゥルースと、プロジェクトオーケストレーターの「完了」に関する権威(後述)を兼ねます。ネガティブチェックはスキャンできないファイルに対してはフェイルクローズ(失敗時に閉じる)します。
• QuarantineTool + 適応型許可リスト(quarantine.py、allowlist.py) — dual-LLM/CaMeLの検疫リーダーと、実行が汚染されると絞り込まれる汚染適応型ツール許可リスト。

マルチエージェントチーム(Tier 3)

chimera/orchestration/

• Role + RoleAgent — ロールの専門化(CrewAIスタイル)。
• SequentialCrew — ロールが順番に実行され、それぞれが統合された前の出力を見ることができ、共有メモリに書き込めます。
• SupervisorCrew — ワーカーがタスクを並行して処理し、出力が統合され、スーパーバイザーが合成します(CAPRAスタイルの parallel_review、2606.18976)。
• consolidate — MOCメッセージのマージにより、チームのコンテキストを軽量に保ちます(2606.02359)。

自己進化するエコシステム(Tier 4)

chimera/ecosystem/

• MetaAgent — 専門化されたエージェントを設計/構築/評価します(エージェントがエージェントを構築する)。Meta-Agent Challenge(2606.04455)由来の2つのセーフガード: ツールの隔離(設計されたエージェントのツールは許可リストにフィルタリングされる)と隠しテストの分離(可視のテストは合格するが隠しテストは失敗する場合、報酬ハッキングが疑われ、成功としては認められない)。
• ChangeQueue — 変更のテンポを統治します(FIFOマージキュー+バッチ上限)。人員数ではありません(「Govern the Repository」、2606.28235)。
• TrajectoryCollector — (プロンプト、応答、結果)を記録し、SFT / DPOデータセットをエクスポートします。実際のファインチューニングはオプトインかつ外部です — Chimeraは収集するだけで、訓練はしません。

コスト経済学と委任階層

chimera/orchestration/(hierarchy、cascade、budget、receipts、envelope_verify)

委任は、それがインラインで作業を行うよりも安い場合にのみ見合います。そしてその主張は主張ではなく計測されます。

• HierarchicalOrchestrator — 分解 → 予算付きワーカーのディスパッチ → 各結果の検証 → 合成。読み取り形のファンアウトは委任され、些細なほど小さいサブタスクは信頼された上位モデルによってインラインで回答されます。
• CascadeBackend — 弱 → ゲート → 中 → ゲート → フュージョンと、ある層の答えが安価な受理ゲートに失敗した場合にのみ上位に上がります。ルートログはすべてのホップを記録するため、コストは受理された1つだけではなく試みたホップの合計になります — エスカレーションにはコストが払われます。
• TokenBudget / BudgetedBackend / EffortPolicy — バックエンドで、ワーカーごとに強制されるハードなトークン上限。
• EnvelopeVerifier — スキーマ → 受理基準 → 確率的な抜き取り検査(要約の忠実性を生の成果物と照合して採点)。抜き取り失敗によって引き起こされた再質問は再監査されます。
• 委任レシート(receipts.py) — すべての委任は、計測されたトークン/コストと、同じ行にインラインの場合の反実仮想を、各モデル自身のレート(未知のモデル → None、決して捏造しない)で価格化してログに記録します。オーケストレーター自身の分解/合成のオーバーヘッドも計測されるため、summarize_delegations(chimera delegations)は監査可能な純節約額を報告し、cascade-bench は平均だけでなくコストのテール(p50/p95/p99)を報告します。

自己進化のフライホイール

chimera/evolution/

重みには一切触れない「訓練」 — フィットネスシグナルによる、勾配不要で、可逆的なもの。

• EvolutionContext — 学習を solve コマンドだけでなくエージェントスタック全体の性質にする、共有アセンブリ(経験、トラジェクトリ、メモリ、自動エボルバー、スキルカード、プレイブック)。
• スキルカード+GEPA改良、ACEのプレイブック、そしてスキルの計測された利用/成功統計によって昇格/降格する SkillLifecyclePolicy(新しいスキルは provisional として生まれます)。
• diff-gate — 「うつろな成功」(検証は合格したがワークスペースの差分が空)はスキルもメモリも生み出しません。フライホイールは実際に起きた作業からのみ学習します。
• transfer-gate(eval/transfer.py) — 調整された成果物は、ホールドアウトでも保持される場合にのみ昇格します。負の転移を防ぎます。maturity.Scorecard.weakest() が目的関数です: ループは最も弱いケーパビリティを狙います。回帰は統計的に有意な低下の場合にのみ自動でロールバックされます(1点だけでなく信頼区間で判断)。

デフォルトの切り替えはすべて事前登録された対応ペアA/B(bench/)の背後でゲートされ、勝っても負けても公開されます — 有意性のための再抽選はありません。

プロジェクトの自律性(始めから終わりまで)

chimera/orchestration/project.py

ProjectOrchestrator はプロジェクト全体を Spec に対して実行します: タスクグラフ(depends_on を持つKanban DAG) → 準備の整った各カードが(上記の進化コンテキストとともに)解決される → check_drift を通じて Specに対して受理される(「完了」に関する唯一の権威) → 満たされていない要件は次のカードを生成し、Specが整合するか、予算/最大反復回数/人間によるチェックポイントが止めるまでループします。リスクのあるステップ(risk: high — デプロイ/マイグレーション/削除)は人間の承認を待って一時停止します。実行は永続的で再開可能です。

横断的な要素

• プロバイダー(providers/) — LiteLLM上のプロバイダー非依存の単一ゲートウェイ。キーは .env に置くことができ、LiteLLMが認識できるよう環境にエクスポートされます。
• ツール(tools/) — ネイティブなプリミティブ。ツールのメタデータはインスタンス属性であるため、動的に生成されるツール(OpenAPI/MCP)も動作します。
• 統合(integrations/) — MCPクライアント(オプションの mcp エクストラ)+OpenAPI→toolインポーター+コネクターレジストリ。
• スケジューラー(scheduler/) — cronとイベントSOP。決定論的なテストのために時刻が注入されます。
• マイグレーション(migration/) — Hermes / OpenClawから設定+スキル+長期記憶をマージでインポートします。重複排除され、破壊的ではありません。

テスト哲学

すべてのサブシステムはフェイクバックエンドでユニットテストされています — 決定論的で、ネットワークなし、キーなし。実際にLLMを呼び出すコマンドは、キーなしの失敗パスについてスモークテストされます。品質ゲート(ruff + mypy --strict + pytest)はPython 3.11と3.12でCI実行されます。