 | 方針: - budget = 1000 - 各 `provision_gpu(a100)` 呼び出し = 500 結果: - 呼び出し 1 -> 許可 - 呼び出し 2 -> 許可 - 呼び出し 3 -> 拒否（`BUDGET_EXCEEDED`） 重要なポイント: 3回目のツール呼び出しは、実行前に拒否されます。ツールは一度も実行されません。 さらに出力: - 認可アーティファクト - ハッシュ連鎖された監査イベント - 検証用エンベロープ - 厳密なオフライン検証: `verifyEnvelope() => ok` これは副作用を伴うエージェントに欠けていたレイヤーのように感じます: 提案 -> 認可 -> 実行 エージェント -> ツールを直接、ではなく。 実行時の認可を行っていますか？それとも主に、承認 / リトライ / サンドボックスに頼っていますか？ 役に立てば、正確な出力 / デモの流れを共有できます。 [link] [comments] |
2台のGPUをプロビジョンできるエージェントのデモを作ったが、3回目の呼び出しでハードブロックされた
Reddit r/artificial / 2026/4/9
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIdeas & Deep AnalysisTools & Practical Usage
要点
- 著者は、ツール呼び出しによってGPUをプロビジョンできるエージェントのデモを作成した。固定予算と、1回あたりのコストを設定している（合計予算1000、`provision_gpu(a100)` 呼び出し1回あたり500）。
- 最初の2回のツール呼び出しは許可されるが、3回目の呼び出しはツールが実行される前に `DENY` によってハードブロックされ、`BUDGET_EXCEEDED` が返される。
- システムは、ハッシュ連鎖された監査イベントや検証用エンベロープ（verification envelope）などの、認可に関する成果物も生成する。さらに、厳格なオフライン検証（`verifyEnvelope() => ok`）に対応している。
- このデモは、副作用を伴うエージェントに対する実行時認可の「欠けているレイヤー」として位置づけられており、「エージェント→ツール直通」ではなく、「提案→認可→実行」というパイプラインを強調している。
- 投稿は実務者にとっての実践的な問いを提起する。チームは実行時に認可を強制しているのか、それとも主に承認、リトライ、またはサンドボックスに依存しているのか。
