ワークフローと永続的な結果
ワークフローは、複数のモデルターン、ターミナル、または委任されたエージェントにまたがって一貫性を保つ必要がある作業を表します。これにより、プロバイダーの最終メッセージがより大きなミッションの完了と誤認されるのを防ぎます。
トップレベルと委任された作業
トップレベルワークフロー は、オーナーのミッションのために起動したエージェントまたはスーパーバイザーに属します。委任ワークフロー は、範囲を限定した1件のタスクを割り当てられた子に属します。
Top-level: "Prepare the release candidate"
├── Delegated: "Fix the statistics parser"
├── Delegated: "Review operator authorization"
└── Owner gate: "Approve public publication"各ワークフローには、独自の現在の論理入力と完了状態があります。トップレベルワークフローが開いたままでも、ワーカーは委任ワークフローを完了できます。
Assign と handoff
Assign は独立した範囲限定作業を開始し、親は続行できます。子の結果は後で配信されます。並列の調査、実装、レビューに役立ちます。
Handoff は1つの範囲限定タスクを移譲し、親が続行する前に検証済み結果を待ちます。次の親ステップがその回答に直接依存する場合に役立ちます。
どちらの形式も親子の識別情報と永続的な結果を保持します。どちらも、親が明示的に委任した以上のオーナー権限を子に与えません。
作業コンテキスト容量の枯渇のような、一時的な起動前の受け入れ拒否は、実行済みの割り当てではなく未受け入れとして記録されます。容量が利用可能になれば同じ論理効果を再試行できます。子の起動が受け入れられた後、またはその結果が不確実になった後は、通常の重複防止が有効なままです。
結果のライフサイクル
Task admitted
↓
Child works
↓
Structured result recorded
↓
Result delivered to parent
↓
Parent reads and incorporates it
↓
Parent acknowledges incorporation
↓
Eligible child resources can retire結果には通常、簡潔な要約、変更ファイル、実行したチェック、残るリスク、ブロッカーが含まれます。これは運用上の証拠であり、差分またはテスト出力を確認する代わりにはなりません。
配信は少なくとも1回です。親が配信済み結果を確認応答する前に再起動すると、ThreadCells は再び配信できます。親は不変の結果 ID を使用して、同じ作業を二度組み込まないようにする必要があります。
Inbox 配信はターミナル内で FIFO であり、それを作成した正確なワークフローと論理ターンに結び付けられます。保留中の転送は配信状態であって、ペイロードまたは結果を別のワークフローへ移す権限ではありません。紐づくワークフローがもはや開いていない場合、ThreadCells はその古い転送を終端化し、ペイロード、ワークフロー、配信、受領、効果の識別情報を再バインドせずに、より新しいオープンなオーナー作業を進めます。同じ調整は再起動後にも実行され、冪等です。
プロバイダー完了とワークフロー完了
モデルが制御を返すたびに、プロバイダータ―ンは終了します。ミッションには、別のテスト、保留中の子、修正パス、デプロイ手順など、対象となる作業がまだ残っていることがあります。
そのため ThreadCells は、次の明示的な結果のいずれかが発生するまで、トップレベルワークフローを開いたままにします。
- オーナー承認済みミッションが完了した。
- オーナーゲートが本当に必要である。
- オーナーがキャンセルする。
- 実際に回復不能な障害で、範囲を限定した回復経路が尽きた。
繰り返される通常のプロバイダー最終応答では、上限付きバックオフを伴う、永続的な一度に1ターンの継続を使用します。ワークフローが開いている間、ThreadCells は次の論理ターンを受け入れ続けます。プロバイダーが繰り返し可能な完了フレームを公開せずに直接 Ready で落ち着く場合、ThreadCells は再起動をまたいでその状態を永続的にデバウンスし、同じオープンワークフローを進めます。後続の Processing 観測は一時的な Ready 候補を取り消します。直接のオーナー入力と永続的な子の結果は、進捗なしカウンターをリセットします。有料ループの安全策として、永続的進捗がない連続65回の最終応答は、明示的でオーナーに見えるゲートにワークフローを置きます。プロバイダー完了がミッション完了になることはなく、通常の自律継続にオーナーの起動は不要です。
オーナーゲート
次のステップにミッションが与えなかった権限が必要な場合は、オーナーゲートを使います。公開リモートへの公開、新しいネットワークサービスの公開、リソースへの支払い、実質的に異なる製品セマンティクスの選択が良い例です。
作業が遅い、テストが失敗した、プロバイダータ―ンが1回終了したというだけで、オーナーゲートを使わないでください。まず独立して実行可能な作業を続行してください。
Workflow Composer の新しいメッセージは、対象となる常駐ワークフローを再開するオーナーの決定です。ThreadCells はオーナーゲートからの由来を永続化し、その正確な永続ターンを一度だけ受け入れます。先行ターンが転送再試行を使い切った時点ですでに要求がキューにある場合、そのオーナーターンを別のオーナーゲートの下に隠さず、原子的に昇格します。一時的な容量またはリソースポリシーの拒否は、明示的な永続待機理由を残し、転送失敗の再試行予算を消費しません。
復旧
再起動時、ThreadCells は永続状態からワークフローの所有権を再構築します。配信済みで未確認応答の結果は引き続き利用できます。待機中の handoff は、重複する子を起動する代わりに同じ子に対して再開できます。オープンワークフローで新しい論理ターンが受け入れられると、古い保留中の継続は永続的に置き換えられ、コンパクションまたは中断後に独立した作業として再生されることはありません。
管理対象の子が結果を送信せずに権威的に終了した場合、ThreadCells はプロバイダーの最後の表示状態が古いままでも、同じ上限付き復旧予算を進めます。予算を使い切ると incomplete のライフサイクル結果を記録し、開いている親が読み取って一度だけ確認できるようキューに入れ、遅れて届く送信を拒否します。成功した結果を捏造することはありません。
再起動時の調整では、キャンセル済みの転送先頭に後続の明示的な Composer ターンがすでに存在する場合、最新のオーナーゲート状態のワークフローも再度開きます。置換ターンを作成せずに既存の後続ターンを昇格し、この修復によって Inbox コールバックや Exited ターミナルを復活させることはありません。
論理入力が受け入れられた後、必要な作業が完了する前にプロバイダー/モデル実行が中断された場合、ThreadCells は元の受領を再生する代わりに、新しい永続的な継続ターンを通じて再開します。完了した効果は引き続きフェンスされ、プロバイダー実行の所有権は再開ターンに従い、同じ不変の子結果と完了バリアが組み込みおよび一度だけの確認応答のために利用可能なままです。
直接完了、障害、キャンセル、オーナーゲート、子の終端化、中央の保護ワークフローキャンセルは、同じデータベーストランザクション内で保留中の Inbox 転送をフェンスします。これにより、ターミナル遷移が、後のオーナーターンを抑制しうる通常の配信状態を残すことを防ぎます。
同一ビルドでのサービス再起動では、プロバイダー側の制御接続の互換性が保たれます。昇格したビルドが特権オーケストレーションコードを変更した後は、古い接続が効果を作成する前にフェンスされます。再起動中にアクティブな ID が一時的に利用できない場合、効果なしで操作は拒否され、サービス復帰後に再試行されます。Codex では、ThreadCells は起動準備完了時に正確なプロバイダー会話を管理対象ターミナルとランタイム世代に結び付け、その ID を再接続権限として永続化します。他の開かれたロールアウトファイルによって、その管理対象ターミナルを曖昧にすることはできません。ID が欠落、古い、不正、または証明不能な場合、プロバイダー送出前にフェイルクローズします。永続的な再開 ID により、終了と再起動の間でもサービス再起動は安全です。入力転送、再接続、退役は、ターミナルごとに1つの永続的な変更クレームを共有するため、テキストを再接続シェルの隙間に貼り付けることはできず、古い再接続が退役の勝利後に再起動することもありません。すでに永続化された論理ターンは置き換えられず、再試行されます。
ターミナルが消えた場合、再試行する前にワークフローおよび結果レコードを確認してください。新しいターミナルが、古いターミナルですでに完了した変更を黙って重複させてはいけません。
具体例
- オーナーが、機能追加とその検証のためにスーパーバイザーを起動します。
- スーパーバイザーは実装を開発者に割り当て、テストの調査を続けます。
- 開発者は変更をコミットし、結果を記録します。
- ThreadCells が結果を配信し、スーパーバイザーは差分を読んで組み込みを確認応答します。
- スーパーバイザーは独立したレビュアーを割り当てます。
- レビュアーはブロッキングなブラウザー回帰を見つけ、証拠を記録します。
- スーパーバイザーは同じオープンなトップレベルワークフローを続け、修正を依頼して受け入れを再実行します。
- 受け入れ済みビルドと認可済みデプロイの後にのみ、スーパーバイザーは明示的にワークフローを完了します。
ステップ3、4、6では、個々のモデルターンは終了しています。ミッションは終了していません。
よくある間違い
- 最終ターミナルメッセージをトップレベル完了として扱う。
- 結果を読んだり使ったりする前に確認応答する。
- 永続的な以前の結果を確認せずに、代替の子を起動する。
- 2つの子に同じワークツリーを変更させる。
- オーナーゲートを一般的な一時停止ボタンとして使う。
書き込み分離については プロジェクトと管理対象ワークツリー、受け入れ制限については 容量とリソースモデル を参照してください。