【要約】エージェントが本番で黙って止まる4つの場面と、物理で防ぐパターン — AOS v0.2 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がエージェントを本番へ移行する際、「黙って壊れる」問題に直面する。プロンプトによる指示だけでは、以下の事象を防げない。
- ・例外を飲み込み、不完全な状態で「完了」と報告する。
- ・実行の証拠となるログや成果物がディスクに残らない。
- ・再起動により対話セッションが消失し、継続性が失われる。
- ・ルール違反をエージェント自身が報告しない。
// Approach
エージェントを物理的制約で縛る「AOS」を採用する。具体的には、以下の4つのパターンを用いて実装を行う。
- ・Manifest宣言:
manifest.jsonで書き込み可能領域を宣言し、実行時に強制する。 - ・物理証拠パターン: 成果物ファイルが存在することを完了の前提条件とする。
- ・免疫ループ: 違反検知と修復を分離し、違反を物理レポートとして残す。
- ・systemdランタイム: OSのプロセス管理を利用し、再起動後の継続性を確保する。
// Result
AOS v0.2の公開により、規範に具体的な実装例が紐付けられた。これにより、開発者は以下の成果を得られる。
- ・
physical-agent-patternsを通じて、即座に実装を開始できる。 - ・「仕様の言葉」を「動くコード」へ接続し、導入の障壁を下げた。
- ・エージェントの動作を、物理的な証拠に基づいて検証可能にした。
- ・再起動時でも、業務の継続性と整合性を担保できる。
Senior Engineer Insight
> エージェントの信頼性を「ホスト側の制約」に逃がす設計は極めて合理的だ。プロンプトによる制御は不確実性が高い。対して、ファイルシステム等の制約は決定論的である。大規模運用では、エージェントの「嘘」を検知するコストが膨大になる。そのため、この物理的ガバナンスは必須となるだろう。ただし、設計の複雑化には注意が必要だ。