agently-request

Agently Request

このスキルは、作業を単一の ModelRequest ファミリーで完結できる場合に使用します。最初のリクエストの後に生成されるツール結果、システム検索、承認、成果物の読み戻し、またはホスト側の計算を後続のセマンティックステップで必要とする場合、あるいは分岐、並行処理、リトライ、一時停止/再開をアプリケーションライフサイクル内で可視化する必要がある場合は、agently-triggerflow を使用してください。

複数ラウンドのプロンプトコラボレーションでは、実質的な各ラウンドを現在の項目（ステータスを先頭に）と、タイムスタンプおよびバージョン付きの変更履歴テーブルから開始します。複数ラウンドコラボレーションを使用して、保留中の決定事項、変更、破棄を保持します。

必要に応じて読む

• 独立したモデルロール、画像モード/直接出力、音声タスク入力、say または embed: model-capabilities.md。開発 API、インストール済みサポートを確認します。
• 独立した TTS/STT、Agent の音声バインディング、連続音声バイト、または出力ブロック: audio.md。AudioModelRequest は個別のプラグイン機能であり、テキストプロンプトパイプラインではありません。
• プロバイダー、エンドポイント、環境、設定名前空間、または接続性: model-setup.md。
• リクエストの責務、効果のチューニング、入出力の十分性または冗長性、 協調レビュー、プロンプト設定/参照、再利用可能なコントラクトまたは継承: prompt-management.md。
• 構造化出力、Pydantic、ensure/バリデーション、ストリーミングフォーマット、または長い出力の直接配信: output-control.md。
• 1 つのリクエスト結果をテキスト/データ/メタとして再利用する、またはそのストリームを消費する: model-request-result.md。
• セッションの継続性と永続メモリ: session-memory.md。
• 埋め込み、リランクモデル、RecordStore、ContextSource、検索、および根拠に基づく 引用: knowledge-base.md。
• 複数ソースにまたがる段階的な開示と実践的なスキル: context-and-skills.md。

リクエスト契約

• リクエスト契約がモデルの責務を明確にし、実行効果を改善し、欠落または冗長なデータを明らかにできる場合は、協調レビューを使用してください。明示的な「Prompt review」リクエストは不要です。複雑なレビューは、モデルノードと Host のハンドオフを強調するフロー概要から始め、その後に関連するプロンプトテーブルを比較用にグループ化してください。最大 3 つの論理ノードが 1 つの返信を共有できます。密結合されたより大きなグループも許可されます。固定された件数や 1 ノードごとの承認ターンではなく、開発者の理解を優先してください。重大な変更の確認を維持し、設計上の所見と実測された効果を区別してください。references/prompt-management.md を参照してください。クロスノードのフロー/所有権分析には agently-design を使用し、無関係な機械的作業には使用しないでください。
• 実測されたスキーマ/ensure/長さの失敗の後は、より浅いモデル向けプロジェクション、または Host による再構築を伴う整合的なリクエスト分割と、変更されない最終検証を検討してください。references/output-control.md を参照してください。
• 一度きりの流暢なリクエストは 1 つのチェーンとして読めるようにしてください：.input(...)、.info(...)、.instruct(...)、.output(...)、そしてその結果呼び出しです。分割するのは、実際の再利用、独立して所有される設定、または動的なコンポジションの場合のみにしてください。
• 単一の観測インスタンスから得られたリテラルや振る舞いを、規範的なプロンプト指示に昇格させないでください。一般的な不変条件を導出し、対照的なケースをテストしてください。説明的な例は、すでに述べられたルールを説明するためにのみ使用し、その合計レンダリングコンテンツは非例の規範的プロンプトより小さく保ってください。
• 実行時の事実は input に、権威ある証拠/API/スキーマ資料は info に、振る舞いと変換ルールは instruct に、下流で消費される正確な形状は output に配置してください。
• 消費される各フィールドについて、型、意味、必須性、enum/format/range、null 許容性、および該当する場合はクロスフィールド制約を定義してください。
• 最初の試行の前に、機密性のない満たすべきすべての検証ルールをモデルに与えてください。決定論的検証は引き続き権威であり、リトライフィードバックは宣言された契約を修復するものであり、盲目的なルール発見になってはなりません。
• 散文から導出される意図、ルーティング、関連性、グレーディング、受け入れには、ModelRequest の構造化出力を使用してください。スキーマ/型チェック、認可、算術、提供キーのメンバーシップ、および副作用は Host コードが所有します。
• 意味的フィールドを 1 つの順序付けられた応答に結合するのは、それらが同じリクエスト時の証拠スナップショットを共有し、後続のフィールドがディスパッチ後の事実を必要としない場合のみにしてください。ストリーミングは、実行中のリクエストにツールやホストの結果を注入できません。
• 実際の呼び出しや副作用の前に、スキーマ、提供キー、認可、および決定論的制約を検証してください。

VLM リクエストでは、 .image(question=..., file=...|url=...|files=[...]|urls=[...]) を優先してください （モデル機能開発 API は位置引数のファイル、オプションの question と mode も受け付け、繰り返されたグループを追加します）。.attachment(...) を使用するのは、呼び出し元がプロバイダースタイルの混合コンテンツまたは正確なコンテンツ順序を所有している場合のみにしてください。

結果、コンテキスト、メモリ

• 4.1.4.8 では、.auto_continue() は条件付きの出力配信設定です。 .ensure_long_output() はその互換エイリアスのままです。どちらも Execution モードを選択するものではありません。LongContent 宣言が プロアクティブな長文生成を選択します。プレーンテキストおよび 構造化文字列のサポート、完了エビデンス、制限については output-control.md をお読みください。
• 直接の ModelRequest 呼び出しは ModelRequestResult を返します。Agent の クイックチェーンは AgentExecutionResult を返します。テキスト、解析済み データ、メタデータ、ストリームに対して、リクエストを再度発行するのではなく、 同じ結果ファサードを再利用してください。
• 進捗を必要とするコンシューマーがいない場合は、最終ゲッターを直接 await してください。instant フィールドは暫定的な UI、またはキャンセル可能／ 冪等な準備として扱い、最終的に検証された結果と突き合わせて整合させてください。
• セッションメモリはワークフロー状態ではありません。SessionMemory は 抽出と圧縮のポリシーを担い、RecordStore は永続レコードと取得を担い、 TriggerFlow の実行状態はワークフローの進行を担います。
• 生の取得レコードはコールドのままにしてください。モデルにはタスクに関連する 範囲を限定した事実と、候補ごとにホストが発行する 1 つのキーを与え、 正規の識別子はホスト側のコードで検証および再構築してください。
• 取得に基づく回答では、信頼できる ref_id 値を提示し、 [[ref:<ref_id>]] を必須とし、承認済みのソースカード／リンクは ホスト側で解決してください。

避けるべきこと

• Agently の設定と出力契約を確認する前に、プロバイダー向け HTTP、プロンプト テンプレート、JSON 修復、リトライループを手書きすること。
• 表示されるコードを短くするためだけに、単発使用のスキーマやプロンプトの ステップをそのリクエストチェーンから切り離すこと。
• テキスト、データ、メタデータのためにモデルへ個別に再リクエストすること。
• 取得ヒット、メモリレコード、暫定的なストリームフィールド、またはモデルの 文章を、認可や副作用の決定的な証拠として扱うこと。
• エンティティリテラル、単発の入力や環境状態、過去のインシデント、テスト フィクスチャ、または 1 つの観測インスタンスから得た期待される回答を プロンプトの分岐に変えること、あるいは例示的なサンプルによって、規範的な 契約が決して述べていない動作を生み出させること。