ハーネスだけでは不十分——長期エージェントシステムには「環境エンジニアリング」が必要だ

## ハーネスだけでは不十分シンプルな主張をしたいと思います：長期エージェントシステムには、ハーネスエンジニアリングと同時に、環境エンジニアリングも必要です。多くのエージェントシステムでは、「ハーネス」という言葉が広く使われています。これはエージェントを囲む実行・制御レイヤー全体を指すことが多いです：ツール・権限・コンテキスト処理・リトライ・承認・ストリーミング・停止ルールなど。そのレイヤーは重要です。しかしここでのより強い主張は、それらの責任の一部は、一つの交換可能な実行ランタイムの内部に暗黙的に残すのではなく、耐久的な環境コントラクトに引き出すべきだということです。重要な区別は、簡単なタスクと難しいタスクの間にあるのではありません。強力なハーネスは非常に高度なタスク実行を支援できます。より重要な区別は、**タスク**と**役割**の間にあります。タスクはローカルな目標と停止点を持つ、境界のある作業です。役割は多くのタスク・実行・変化するコンテキストにまたがる継続的な運用責任です。したがって役割は本質的に長期的です：システムは一貫性を保ち、学習したことを保持し、時間をかけて改善する必要があります。ハーネスはエージェントが一つのタスクをうまく実行するのを助けられます。環境はシステムが複数の実行にわたって役割を維持するのを助けます。だからこそ、長期エージェントシステムには環境エンジニアリングが必要なのです。 --- ## 1. 境界：ハーネスと環境ここでは、ハーネスとは一つの実行（run）のための実行サブシステムです。その仕事の大部分はコンテキスト管理です：どの状態が特定のステップでアクティブになるか・何がプロンプトから外れるか・どのツールが見えるか・ループがどのように続くかを決定します。環境はそのサブシステムを囲む耐久的な運用コンテキストです。この分割こそがこの記事の要点です： - **ハーネスエンジニアリング**は実行を操作可能にする - **環境エンジニアリング**は運用コンテキストを耐久的・検査可能・ポータブル・実行間で安定したものにする目標はハーネスを最小化することではありません。目標は、重要なシステム不変条件が一つの実行エクゼキューターのプライベートな動作に閉じ込められないようにすることです。 --- ## 2. ハーネス交換テストアーキテクチャが本当に役割をサポートしているかどうかをテストするシンプルな方法があります： **明日ハーネスを交換したとしたら、何が残るべきか？** 真剣な長期システムでは、少なくとも以下のものが生き残るべきです： - **ワークスペースコントラクトと著作構造**：ファイル・指示・アプリ・スキル・その他の著作意図の場所と構造を含む、作業環境の耐久的な形状 - **メモリと継続性サーフェス**：システムが有用な知識を前に進め、中断後に一貫して再開できるようにする状態 - **ケイパビリティのプロジェクションと可視性ルール**：特定の実行が何を見て呼び出すことが許可されているかを決定する耐久的なルール - **アプリとインテグレーションの配線**：外部ツール・サービス・ドメイン固有のケイパビリティが役割に接続される耐久的な方法 - **出力アーティファクトと運用者の可観測性**：実行にわたって作業を検査可能・再開可能にする、永続的な結果・トレース・運用者向けの可視性これらの不変条件がハーネス交換後も生き残らなければならないなら、環境は付随的なものではありません。それはハーネスを囲む第一級のコントラクトです。コンテキストを例に取ると。ステップの正確なプロンプトはハーネスが変わると変わるかもしれませんが、それがコンパイルされるより広い状態は変わるべきではありません。すべての関連する状態がすべてのステップのプロンプトにあるべきではありません。ある状態は現在の呼び出しでアクティブで、別の状態は近くのランタイム継続性であり、もっと多くの状態は耐久的だが取得可能です。これが、メモリをコンテキストと同義として扱うべきではない理由です。ほとんどのメモリはプロンプトの外に存在し、システムが特定のステップに関連すると判断した場合にのみホットコンテキストになります。これはハーネスも明確にします。大部分において、ハーネスは大きな環境に対して動作するコンテキストコンパイラーです：ウォームとコールドの状態から選択し、現在のステップのホットコンテキストをビルドし、許可されたアクションサーフェスを公開し、そのステップを囲む制御ループを管理します。他のサーフェスについては、フォローアップ記事で詳しく説明する予定ですので、お楽しみに！ --- ## 4. 環境コントラクト環境は一つのフラットな機能の集まりではありません。ハーネス境界を囲むいくつかの状態レイヤーを定義します。 **耐久的著作状態**は、アプリマニフェスト・スキル・コマンド・常時指示を含む著作構造とそのワークスペースルートを包括します。また、環境と反復にわたって再現可能な開始形状を確立するテンプレートとパッケージング境界も定義し、一貫性と明確さを確保します。 **耐久的適応状態**は実行にわたって進化・永続する情報を指します。これには時間をかけて生き残るメモリ・耐久的な出力・再利用可能なアーティファクト・評価トレースが含まれます。また、運用者のフィードバック・承認・その他の報酬ライクなシグナル、および将来のパフォーマンスを向上させる昇格されたメモリや再利用可能なスキルなどのレビュー済み改善も含みます。 **ランタイム継続性状態**は実行間のコヒーレンスを支援する、一時的だが構造化されたデータで構成されています。ターン結果・スナップショット・チェックポイント・セッションスコープの継続性レコードが含まれます。このランタイム所有の状態により、将来の実行がコンテキストを効果的に復元でき、後続のステップや実行が耐久メモリへの完全なプロモーションを必要とせず効率的に再開できるウォームコンテキストを維持します。 **プロジェクトされた実行状態**は、特定の実行に対して実行ハーネスに提供される可視・呼び出し可能なサーフェスを表します。選択されたモデルルーティング・アタッチメント・MCPの可視性・権限・実行メタデータ、および正確で効率的な実行をサポートするためにウォームとコールドの状態の両方からコンパイルされたステップ固有のホットコンテキストパッケージが含まれます。これらのサーフェスの一部は、今日構築されているシステムで既に具体的なものがあります。他は建築的な方向性の一部です。論文は、システム境界についてです：これらの懸念事項は、エクゼキューター固有の動作に散在するのではなく、一つの環境コントラクトとしてモデル化されるべきです。その方向性は、セキュリティ・耐久性・スケールのためにハーネスとコンピューティングを分離すべきだと主張する、新しいOpenAI Agents SDK のアップデートとも一致しています。そのフレーミングでは、耐久的な実行は一つのライブ実行コンテナーがシステム全体であると仮定するのではなく、外部化された状態とスナップショット・再水和から来ています。 --- ## 5. ポータビリティは設計の一部長期システムには永続性以上のものが必要です。担うべき役割の運用形状を失わずに検査・パッケージング・移動・再水和できる耐久的な単位が必要です。つまり、著作ワークスペースコンテンツ・適応状態・ランタイム所有の残留物を、パッケージングルールが異なる異なるカテゴリとして扱うことを意味します。目標は、ランタイム状態のすべての部分がどこへでも移動するということではありません。目標は、ポータブル単位に何が属し、何が一時的なままであるかの明確な境界を持って、耐久的な環境を意図的に再現できることです。ポータビリティは事後に追加されるのではなく、環境コントラクトに設計から組み込まれるべきです。 --- ## 6. 改善には耐久的な境界が必要長期的な作業は、実行にわたって作業を前進させることだけではありません。時間をかけてその作業が上手くなることでもあります。ここで重要な意味では、長期的な作業は多くの実行と変化する条件にわたって役割を担うシステムとして現れることが多いです。メモリの進化・反省・継続的学習・強化は、その改善のための重要なメカニズムです。しかし、それらは環境が以下の耐久的な記録を保持できる場合にのみシステムのケイパビリティになります： - 行動した際のホットコンテキスト、およびそれが引き出されたウォームまたはコールドの状態 - 使用が許可されたアクションサーフェス - 実行を判定した成果・評価・運用者のフィードバック - 耐久メモリ・スキル・ポリシー・ケイパビリティになり得るものを決定するレビュー境界これらのシグナルが一つの一時的なエクゼキューターループに閉じ込められると、そのループを助けるかもしれませんが、時間をかけて長期的な作業を処理するシステムの能力を確実に改善しません。要点は、役割に耐久的な運用境界を与えることで、有用なエビデンスが時間をかけてより良いメモリ・より強いスキル・より安全なポリシー・その他のレビュー済みケイパビリティに蓄積できるようにすることです。今日、最も明確な着地点は耐久メモリ・evolvフロー・候補スキルですが、より広い方向性はそれ以上のものです：繰り返される良い作業は、一時的な実行ループに閉じ込められたままではなく、検査可能なシステムのケイパビリティになるべきです。 --- ## 7. 次に向けて長期的な作業は単なる長いチャットではありません。システムが役割を担うことが期待されるときに起きることです：複数の実行にわたって一貫して継続し、中断に耐え、運用者にもシステムにも検査可能なままでいる必要があります。だからこそ、ハーネスで止まることはできず、環境コントラクトに基づいて構築する必要があります： - 耐久的なワークスペース構造としてのアプリとスキル - 明示的なストレージとガバナンスルールを持つメモリ - 一貫した再開をサポートするランタイム継続性 - 実行ごとの明示的なケイパビリティプロジェクション - 運用単位全体を囲むポータビリティとパッケージング境界これが、エージェントシステムを検査・パッケージング・再開・拡張しやすくする転換です。これはまた、私のオープンソースプロジェクト **holaOS** の背後にある核心的な技術的論拠でもあります。別のハーネスではなく、長期的な作業・継続性・自己改善のために設計されたエージェント環境です。次の記事では、holaOS を直接紹介し、環境エンジニアリングが具体的なランタイムアーキテクチャ・メモリモデル・ワークスペースコントラクトにどのようになるかを示します。耐久的で進化可能なエージェントシステムを構築することに興味がありますか？フォローしてさらなる洞察を得てください——そして私のリポジトリに参加してください！

ハーネスだけでは不十分——長期エージェントシステムには「環境エンジニアリング」が必要だ

AIFCC — AI Fluent CxO Club