REFERENCE
開発者リファレンス
認証、API、SDK、Flow Agent のプロセッサ、パラメータ解決のリファレンスです。
Entry
ワークフローの起点で、このワークフローがどう呼ばれるかを決めます。
Entry はワークフローの開始点を示すプロセッサーです。
基本的な使い方
ワークフローが起動されると、実行は Entry から始まります。すべてのワークフローに少なくとも 1 つ必要です。
Workflow CRD での形
Workflow CRD を直接書く場合、Entry は
spec.processorsの一員ではなくspec.entriesという独立した最上位の項目です。Entry がどのプロセッサー型の一覧にも現れないのはこのためです。spec:
entries:
- name: entry-main
labels:
display_name: Entry
description: agent がこのツールを呼び出す入口
handlingProcessor: proc-query
inputSchema: |-
{
"type": "object",
"properties": {}
}
tooling:
name: list_scenario_recommendations
description: |-
3 つの開業シナリオごとに推奨される設備の機種とその分類を一覧します。
顧客が「カフェを開きたいのだが、どんな設備が必要か」と言ったときに使います。
allowUploadFile: false
processors:
- name: proc-query
type: query-databasehandlingProcessor
この Entry が処理を渡す先のプロセッサーで、値はそのプロセッサーの
nameです。この 1 行を書き忘れるのは実際に踏む落とし穴です。ワークフローにプロセッサーがあっても、入口がつながっていなければ実行されません。しかも
helm lintとhelm templateはそのまま通ります。検証しているのは YAML とテンプレートの構文で、グラフがつながっているかは見ないためです。レンダリングが成功することは、フローが通ることと同じではありません。inputSchema
この入口が受け取るパラメータを定義する JSON Schema の文字列です。Automation Tool が agent から呼ばれるとき、agent はこの schema をもとにパラメータを組み立てます。
agent が送れる値を限定するのは schema 自身の
requiredとenumの役目で、descriptionの文面ではありません。{
"type": "object",
"required": ["consumer_type", "action_type", "subject_id"],
"properties": {
"consumer_type": {
"type": "string",
"enum": ["inventory", "order", "product"]
}
}
}description に制約を書いても、項目自体が絞られていなければ制約になりません。検証は項目の階層で行われます。
tooling
この入口を agent が呼び出せるツールとして公開します。ツール名、agent が読む説明、ファイルのアップロードを許可するか(
allowUploadFile)を含みます。descriptionの書き方が、agent が適切な場面でツールを呼ぶかどうかを左右します。実務では利用場面まで書き込み、たとえば「顧客がカフェを開きたいので必要な設備を尋ねたときに使う」といった記述にします。ツールの実行にユーザーの同意が必要かどうかは、ここではなく Toolset の階層で設定します。
注意事項
- ワークフローには最低 1 つの Entry が必要で、複数持てます。
- Entry は processor ではありません。Workflow CRD の
spec.entriesであり、キャンバス上ではmainノードです。プロパティパネルには Name と Description しかなく、以下で説明するhandlingProcessor、inputSchema、toolingは CRD にのみ存在し、画面には出てきません。