Windowsは、長期間稼働するAIコーディングエージェントを実行するには難しい環境です。
失敗のモードは、しばしば静かです。ターミナルウィンドウはまだ開いているかもしれません。プロセスはまだ存在しているかもしれません。しかし作業の途中で、ゲートウェイが応答しなくなる、メモリ検索が壊れる、あるいはバックグラウンドサービスが黙って終了する、といったことが起きます。
この記事では、最近の作業から得られた2つの具体的な経緯をまとめます。
- OpenClawは、メモリインデックスのスワップ中に発生する一時的なWindowsファイルロック問題の修正を統合しました。
- Hermesは、こちらのWindowsゲートウェイ用ヘルパーPRを統合しませんでしたが、メンテナーが、これがより広いWindowsサポート計画の中でどう位置づけられるかを明確にしました。
OpenClaw: メモリインデックスのスワップ中に発生する一時的なファイルロック
PR:
https://github.com/openclaw/openclaw/pull/76024
メモリの再インデックス処理の間、OpenClawはSQLiteのインデックスファイルを入れ替えます。Windowsでは、fs.renameは、ファイルが一瞬だけシステムやアンチウイルスソフト、インデクサ、または別のプロセスに保持されている場合に失敗し得ます。
エラーは次のように見えることがあります。
EBUSY
EPERM
EACCES
ユーザー側の見え方は曖昧になりがちです。メモリ検索が失敗する、あるいはエージェントのタスクが詰まってしまう、といった症状です。
統合された修正は、意図的に範囲を狭くしています。原子的なインデックススワップ処理の周りに、上限付きのリトライを追加するものです。メモリシステムを作り直したり、あらゆる失敗をすべてリトライに変えたりはしません。
こうした安定性のための作業は、実際のエージェント利用で重要になりやすいタイプのものです。
後片付けの経路も重要
関連するOpenClawの経緯:
https://github.com/openclaw/openclaw/pull/59137
これは私たちの最初のPRではありません。私たちは、後片付けの順序に関する焦点を絞ったフォローアップを提供しました。すなわち、仮のSQLiteファイルを削除しようとする前に、一時データベースを閉じる、という対応です。
Windowsでは、この細部が重要です。ファイルハンドルがまだ開いている場合、メインロジックが正しくても、後片付けの経路が失敗する可能性があります。
Hermes: Windowsにおけるゲートウェイのライフサイクル
PR:
https://github.com/NousResearch/hermes-agent/pull/15846
Hermesの提案は、より安全なWindowsゲートウェイのライフサイクルに焦点を当てていました。
- ユーザーレベルのScheduled Taskから開始する。
- 表示されるPowerShellやCMDウィンドウへの依存を避ける。
- 実行時の状態を追跡する。
- ログを保持する。
- 可能な範囲での再起動動作を提供する。
PRはクローズされ、統合されませんでした。
しかし、メンテナーのレスポンスはそれでも役に立ちました。Hermesには、バラバラに積み上げた一連のネイティブWindows向けPRではなく、統合されたWindows設計が必要だということでした。この作業は社内のWindowsサポート計画に整理されており、後に統合されたPRに反映される可能性があります。
教訓: ウィンドウを信じるな
表示されているターミナルウィンドウは、ヘルスチェックにはなりません。
Windowsのエージェントでは、退屈な要素が重要です。
- バックグラウンド起動
- ヘルスチェック
- ログ
- 上限付きのリトライ
- ロールバックの経路
- 新しいバージョンを本番の実作業に使う前の小さなアップグレードテスト
AIエージェントのデモは、通常はモデルの振る舞いに焦点を当てます。実際の利用は、いずれプロセスのライフサイクル、ファイルロック、環境変数の継承、そして復旧にぶつかります。
それらは単なるサイドイシューではありません。エージェントが動き続けられるかどうかを決めます。
画像カードとエビデンスの経緯が揃った標準的なバージョンはこちらです。
https://kunpeng-ai.com/en/blog/openclaw-hermes-windows-agent-stability-evidence-trail/
