REFERENCE
開發者參考
認證、API、SDK、Flow Agent 處理節點與參數取值的完整參考。
Entry
工作流程的起點,決定這個流程怎麼被呼叫。
Entry 是標記工作流程起始點的 processor。
基本用法
當工作流程被觸發時會從 Entry 開始執行。每個工作流程都必須至少有一個 Entry 作為執行的起點。
在 Workflow CRD 中的形狀
直接撰寫 Workflow CRD 時,Entry 不是
spec.processors裡的一員,而是spec.entries這個獨立的頂層欄位。這也是為什麼 Entry 不會出現在任何 processor 型別清單中。spec:
entries:
- name: entry-main
labels:
display_name: Entry
description: agent 呼叫這支工具的入口
handlingProcessor: proc-query
inputSchema: |-
{
"type": "object",
"properties": {}
}
tooling:
name: list_scenario_recommendations
description: |-
列出三個開店情境各自推薦的設備機型與所屬分類。
客戶說「我要開一間咖啡廳,需要什麼設備」時用這支。
allowUploadFile: false
processors:
- name: proc-query
type: query-databasehandlingProcessor
這個 Entry 進來之後交給哪一個 processor 處理,值是該 processor 的
name。漏掉這一行是實務上會踩到的坑。工作流程裡即使有 processor,入口沒接上去它就不會被執行,而
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 那一層而不是這裡。
注意事項
- 每個工作流程至少要有一個 Entry,可以有多個。
- Entry 不是 processor,它是 Workflow CRD 的
spec.entries,畫布上就是那個main節點。屬性面板只有 Name 和 Description,下面幾節的handlingProcessor、inputSchema、tooling都只存在於 CRD,畫面上找不到。