agently-runtime

Agently Runtime

この Skill は、リクエストまたはワークフローのオーナーが判明した後に使用します。 分岐、並行処理、一時停止/再開、リトライ、または多段階の進行を実行グラフ内で 可視化したままにする必要がある場合は agently-triggerflow を使用してください。 agently-stage は、プロセスローカルのライフタイムと同期/非同期のブリッジにのみ 使用してください。

必要に応じて読む

• 実行の選択、ネストされたプロデューサー、run/rework/control、最終 validate、 artifact/review、または宣言された Agent のケイパビリティ: agent-execution.md。
• 呼び出し可能な Actions、Search/Browse、MCP/ACP、ポリシー、artifact、または AgentTask のエビデンス: actions-runtime.md。
• Action と ExecutionResource の比較、管理対象のクライアント/サンドボックス/プロセス/ ブラウザ/データベース、Shell/BashExecutor、PowerShell、オフライン/オンライン/ホスト プロファイル、承認、およびストリーミングプロセス I/O: actions-execution-resource.md。
• auto_func、KeyWaiter、FastAPIHelper、SSE、または WebSocket の公開: helpers-and-services.md。
• RuntimeEvent、ログ、トレース、評価、playground、または DevTools: devtools.md。
• エビデンスに基づくレビュアーコメント、Coding Agent の応答、および再実行の比較: devtools-review.md。DevTools 0.2 が必要です。使用する前に API のケイパビリティを確認し、書き戻しの手順を実行してください。
• TaskContext、ContextReader、SkillLibrary、および実践的な Skill パッケージ: context-and-skills.md。

オーナーの境界

オーナー	責務
ActionRuntime	モデルが呼び出し可能な操作スキーマ、計画/ディスパッチ、ポリシー、および Action の結果。
ExecutionResource	ライブクライアント、サンドボックス、プロセス、ブラウザ、データベース、および MCP セッションのライフサイクル。
TaskWorkspace	1 つのタスクに含まれるファイル、生成された artifact、読み戻し、アイデンティティ、および昇格。
RecordStore	永続的なレコード、リンク、取得、RuntimeEvent、チェックポイント、スナップショット、リース、および永続参照。
TaskContext / ContextReader	タスク情報のバインディング、およびコンシューマーに紐づく段階的な開示。
SkillLibrary	インストールされた不変の Skill リビジョンとリソースの読み取り。実行権限は決して含みません。
AgentExecution	1 回の実行における交換可能なプロデューサー、タスクスコープのバインディング、コンテキスト、制御、終端ポリシー、結果、およびストリーム。

これらを汎用の Workspace やランタイムマネージャーに統合しないでください。ファイル空間 はレコードストレージではありません。レコードはモデルのホットコンテキストではありません。 Skill パッケージはエグゼキューターでも権限付与でもありません。

ランタイムルール

• @agent.action_func と agent.use_actions(...) を優先してください。tool_* および use_tool(s) という名前は互換性のためのサーフェスです。
• Action ID とモデルが計画した引数は信頼できないものとして扱ってください。ディスパッチ前にスキーマ、認可、ポリシーを検証し、主張された副作用には記録された Action のエビデンスを必須としてください。
• 権限プロファイルは明示的かつ狭く保ってください。AgentTask が存在するというだけの理由で、シェル、ネットワーク、 ブラウザ、インストール、ファイル書き込み、MCP のケイパビリティを公開しないでください。
• 封じ込められたファイル作業と検証済みの成果物読み戻しには TaskWorkspace を使用し、永続的なレコードとリカバリには RecordStore を使用してください。明示的なコンシューマーが読み取るまで、大きな本体は ref の背後でコールドに保ってください。
• 実世界の Skill はガイダンスとアドレス指定可能なリソースを提供します。Actions、 MCP、ExecutionResources、スクリプト認可、副作用の証明は、明示的にホストが所有するバインディングのままです。
• 複数ステートメントのセットアップや無関係な新しいリクエストには、新しい agent.create_execution() を使用してください。完了したリビジョンはイミュータブルです。明示的なプロデューサーによる再作業は同じ実行を進めますが、古い結果のリーダーは自身の リビジョンを保持します。上記の実行契約を参照してください。
• 4.1.4.8 では、create_execution(...) を通じて request、plan、long_content、または long_task を選択してください。最終的な .validate(handler) はハードな出力ゲートです。 .review(..., on_fail="warn" | "block") は、明示的な 終端ポリシーを伴うソフトな評価です。レビューは暗黙的に再作業を行うものではありません。再作業はプロデューサーに属します。.artifact(...) は検証済みの TaskWorkspace 読み戻しを必要とします。
• agent.create_task(...) は、モデルが境界のある計画、実行エビデンス、検証、および再計画を所有すべき場合にのみ使用してください。create_task_loop(...) は互換性のための表記であり、推奨されるサーフェスではありません。安定したアプリケーションオーケストレーションは TriggerFlow に属します。
• リソースディスクリプタを永続化し、ライブクライアントやシークレットは決して永続化しないでください。リカバリ時には、プロバイダー/リゾルバーを通じてリソースを再構築してください。
• RuntimeEvent の永続化を明示的にバインドしてください。RecordStore が利用可能であるからといって、すべての観測が永続的なイベントアーカイブになるわけではありません。
• 観測とトランスポートはアダプターです。それらはルーティング、認可、ワークフローライフサイクル、セマンティックな受理、またはリトライの所有者になってはなりません。

フェイルクローズド

未知の Skill リビジョン、リソース ref、Action ID、選択キー、 コンテキストブロックキー、リカバリプロバイダー、および外部レジューム ID を拒否してください。モデルには、ホストが発行する短い選択キーを 1 つ提示し、提示されたセットに対して検証してから、ホストコード内で正規のレコードを再構築してください。

意図、Skill の関連性、ルート選択、エビデンスの有用性、または出力品質のセマンティックな所有者として、キーワードや正規表現のマッチングを使用しないでください。定型の出力や決定論的なビジネスマッピングで、モデルが所有する成功を偽装しないでください。