エージェントのための安全な配信パイプラインの構築
ほとんどのエージェントのデモでは、極めて重要な問いが無視されています。自律的なシステムに、二重送信や未承認の成果物の送付をさせることなく、あなたの代わりに何かを送らせるにはどうすればよいのでしょうか？
二重送信は稀なエラーではありません。タスクの途中でワーカーが停止した場合、単純なキューにおけるデフォルトの挙動です。ワーカーがメッセージを送信した後、成功を記録する前にクラッシュします。システムはタスクが失敗したと判断し、新しいワーカーに再試行を命じます。顧客にはメールが2通届き、あなたにはサポートチケットが届きます。
すべてのクラッシュを防ぐことはできません。「アクション」と「記録」の間の隙間で発生するクラッシュを想定して設計する必要があります。
実社会に影響を及ぼすエージェントの出力には、この6段階のパイプラインを使用してください。
• 生成 (Produce): エージェントが成果物全体を生成します。この時点ではまだ何も送信しません。 • 保存 (Persist): まず、意図と成果物を永続ストレージに書き込みます。 • スコアリング (Score): 出力に信頼度スコアを付与します。 • レビュー (Review): 信頼度の低い項目を人間へとルーティングします。 • 承認 (Approve): フェイルクローズ（fail-closed）のゲートを使用します。人間が明示的な許可を与えない限り、システムはすべての送信をブロックします。 • 送信と証明 (Send and Attest): リースの条件下でアイテムを送信し、その後に証跡となるレシートを書き込みます。
各ステージは、個別の永続的な遷移である必要があります。状態はワーカーのメモリ内ではなく、データベース内に保持されるべきです。
重複を防ぐには、行レベルのリーシング（row-level leasing）を使用します。Postgresでは SELECT ... FOR UPDATE SKIP LOCKED を使用してください。これにより、一度に1つのワーカーのみがタスクを所有することが保証されます。
最も重要なルールは、期限切れのリースをどのように扱うかです。外部メッセージの送信中にワーカーが停止した場合、自動的に再試行してはいけません。代わりに、そのタスクを保留状態にして人間によるレビューに回してください。目に見える「停止したタスク」は、目に見えない「二重送信」よりもはるかにマシです。
また、以下のフェイルクローズの原則に従う必要があります。
- 送信はデフォルトでオフにする。単一のフラグによってのみ、すべての送信トラフィックを有効にする。
- アイデンティティを確認する。送信の瞬間に、システムは送信元アドレスと転送セキュリティを検証しなければならない。
- すべてにレシートを残す。記録されない送信は失敗である。
内部ログのようなリスクの低いタスクのためにこれを作る必要はありません。ミスが金銭的損失を招いたり、法的問題を引き起こしたり、サポートチケットが必要になったりする場合にのみ使用してください。
Optional learning community: https://t.me/GyaanSetuAi