前面幾天，我們已經有：
但要建立 Workflow，還是要自己進 Workflow page：
這些資訊其實很多都可以從 user intent 推出來。
所以這次把 Workflow 接回 Chat。
User 可以直接說：
幫我做一份 Monday Report。Users 放 Median Session Length 和 Daily Active Users，Content 放 Views per YouTube Category 和 Average Views by Publish Hour，Business 放 Monthly Bookstore Revenue。Session Length 用
events_enterprise，然後直接跑。
Agent 會自己：
這次實際跑了 5 個 Analysis，分成 3 個 sections，最後 5 / 5 都完成，整個 Workflow 花了 21 秒。
我沒有讓 Agent 自己產生 canvas 座標或 edges。
Agent 使用的是比較接近 user intent 的結構：
Workflow
├── Users
│ ├── Median Session Length
│ └── Daily Active Users
├── Content
│ ├── Views per YouTube Category
│ └── Average Views by Publish Hour
└── Business
└── Monthly Bookstore Revenue
Agent 只需要描述：
run_first
真正的 nodes、edges 和 layout 由 code 產生。
這樣 Agent 處理的是：
這份 report 應該包含什麼？
而不是：
node A 的 x / y 座標是多少？
目前給 Agent 三個 tools。
list_workflows讓 Agent 找已經存在的 Workflow，包括：
所以 user 說：
再跑一次 Monday Report
Agent 不需要重新建立，只要先找到它。
save_workflow建立或修改 Workflow。
Input 主要是：
title
sections
report_title
sandboxes
replaces
每個 section 裡再放 Analysis 和 datasource mapping。
如果 Workflow 不合法，例如：
就不會 save，原因會直接回給 Agent，讓它修正後再送一次。
run_workflow執行 saved Workflow。
它走的還是 Day 27、28 同一套 runtime：
Chat 沒有另一套特別的 Workflow execution。
Agent 建好 Workflow 後，Chat 下面會直接顯示同一個 canvas。
這不是另外做一套 preview，而是 reuse Workflow page 本來的 node / edge components，只是改成 read-only：
執行時，canvas 也會跟著更新：
waiting for a sandbox...
running...
done
needs optimization
edges 也會反映 execution state。
User 不需要離開 conversation，就能看到 Workflow 現在跑到哪裡。
Chat 裡也會直接顯示：
Chat preview 不是 Workflow editor 的替代品。
如果 user 想進一步調整 Workflow，可以直接按 Open workflow。
會直接回到原本的 Workflow page。
在這裡還是可以：
所以兩個入口的角色很清楚：
這裡我刻意讓 Chat tools reuse Workflow API 本來的 implementation。
因此從 Chat 建的 Workflow 和 UI 建的 Workflow，會經過同樣的 checks。
例如 Analysis 換到 incompatible datasource，一樣不能 save。
某個 Analysis Run 超過 execution limit，一樣會變成：
needs_optimization
Agent 不會自己繞過 Validation，也不會偷偷改 Analysis。
Optimize 還是走前面 Day 24、25 建好的流程。
所以 Chat 只是另一個入口，不是另一套 runtime。
Chat 裡的 Workflow preview 一開始不是 live 的。
第一版只在 Workflow 出現時 load 一次，結果 save_workflow 完成後 preview 就顯示：
Not run yet.
即使後面的 Workflow 已經跑完，它也不知道。
第二版在 run_workflow 出現時 reload，但 reload 得太早，拿到的反而是 previous run。
最後改成：
run_workflow 還沒有 response 時這樣才真的能看到：
waiting → running → done
這裡又碰到一次 streaming UI 很常見的問題：
backend state 是對的，不代表 frontend refresh timing 就是對的。
實際跑了幾次後，又發現一個之前 Workflow 沒碰到的情況。
Chat 的 sandbox 會在最後一則訊息後保留 15 分鐘。
有一次 account 裡剛好有 3 個 idle Chat sandboxes，而 account limit 也是 3。
這時 Workflow 完全拿不到 sandbox：
這不是 Chat Workflow 特有的 bug。
從 Workflow page Run 也會遇到一樣的問題。
目前比較合理的方向是：
Conversation history 不會消失；下次 Chat 需要執行 code 時，再拿一個新的 sandbox。
這部分目前還沒有做完。
做到這裡，Chat 不只是拿來問一次性的 analysis。
它開始可以操作前面建立的 reusable artifacts：
整條路徑現在變成：
User Intent
→ Agent
→ Saved Analyses
→ Workflow
→ Parallel Execution
→ Report
→ Performance
Agent 負責把 intent 轉成操作。
真正的 execution、validation、scheduling 和 resource control，還是由 deterministic system 負責。
iThome鐵人賽
看影片追技術