Sim 把 agent 流程變成畫布

我拆 Sim 的畫布式 agent 編排，順手整理成可直接套用的工作流模板、自架與向量搜尋做法。

我玩 agent workflow 一陣子了，最煩的不是模型不會答，是工具一多就開始亂。今天接 prompt，明天補 YAML，後天加 queue、vector store、重試，最後整套東西像在跟我鬧脾氣。Demo 看起來很順，真的要上線時，流程一複雜就露餡。我最近盯上 Sim，https://github.com/simstudioai/sim，因為它至少沒假裝這些麻煩不存在。

它的路數很直白：把 agent orchestration 做成 visual canvas，讓你能設計、執行、自己架、自己擴。這種產品我通常半信半疑，因為很多工具都只是在換皮，複雜度沒少，只是換個地方藏。Sim 比較像是把流程攤開來給你看，這點我反而比較能接受。

我會想拆它，不是因為它多神，而是它踩中了我一直在意的那條線：workflow editor、runtime、self-host、vector search、tools，全都要能接起來，不然就是半套。這篇我就直接拆它的玩法，順手整理成你可以抄的版本。

觸發我仔細看的是 Sim 的 GitHub repo，還有它自己講的產品定位。README 明講它是 build、deploy、orchestrate AI agents 的平台，而且有 visual canvas 跟 self-host 路線。這不是空話，我看的是 repo 結構跟安裝路徑，不是只看首頁文案。原始來源在這裡：https://github.com/simstudioai/sim。

我先看它有沒有把「畫布」當裝飾品

“Design agent workflows visually on a canvas—connect agents, tools, and blocks, then run them instantly.”

翻譯一下就是：先把流程畫出來，再直接跑。這句話聽起來很像低碼平台的老梗，但我覺得重點不是畫，而是「畫完就能跑」。很多工具都卡在中間那段，設計和執行是兩套系統，最後你還是得自己補 glue code，照樣痛。

我以前做過一個客服分流 agent，需求很簡單：先判斷問題類型，再去抓知識庫，最後決定要不要轉人工。結果實作時，流程拆在三個檔案、兩個 handler、外加一堆臨時 flag。每次改一個分支，我都要回頭找是哪個 callback 在偷改狀態。那種時候我最想要的不是更強的模型，是一張能一眼看懂的流程圖。

Sim 的 canvas 如果只是美觀 UI，我不會多看一眼。但它把 agent、tool、block 都攤在同一個視覺層，這就有價值了。因為 agent 系統最麻煩的地方不是推理，而是你根本看不出哪一步把資料弄壞了。畫布至少讓你先把責任切清楚。

實操寫法很簡單：每個 node 只做一件事，輸入和輸出都要能說人話。不要一個 agent 包五個任務，然後怪模型不穩。你要的是可讀性，不是把複雜度塞進黑盒。

• 一個 node 對應一個責任，不要混雜。
• 工具要窄，別做萬用工具。
• 先畫 failure path，再畫 happy path。

如果你本來就有在看 LangChain 或 Mastra，Sim 比較像是把你腦中那張流程圖直接做成產品，而不是只給你一堆 runtime API 叫你自己想像。

它不是 editor 而已，是 editor 綁 runtime

“Build Workflows with Ease”

這句很像行銷話，但我看它的重點不是「容易」，而是「設計完能立刻跑」。很多平台都能讓你拖拉幾個節點，問題是拖完之後要怎麼執行、怎麼測、怎麼改，答案通常很破碎。你最後還是要跳出去寫另外一套執行層。

我比較在意的是 design 和 execution 的距離有沒有被縮短。因為 agent workflow 一旦拆成兩個世界，debug 就會變成災難。你在畫布上看到的是 A，runtime 跑出來的是 B，然後大家開始互相懷疑。這種事我看太多了。

Sim 的價值在於，它讓你在同一個介面裡做建模、測試、執行。這對我來說不是便利，是少掉翻譯成本。少一次翻譯，就少一次出錯。尤其是當工具輸出格式變了、模型回傳半成品、或者某個分支只在真實資料下炸掉時，你會很感謝這種緊密耦合。

實操上，我會這樣用：先做最小流程，只放一個 input、一個 agent、一個 tool、一個 output。先別急著加分支，先確認主幹穩。很多人一開始就想做完整 orchestrator，結果連最基本的 schema 都沒驗證。

• 先跑最小閉環，再加分支。
• 用真實髒資料測，不要只拿乾淨範例。
• 每次改節點，都回頭看執行紀錄。

它的 editor 用的是 React Flow，這選得很務實。React Flow 的好處就是 node graph 不會變成裝飾品，是真的能拿來編排流程。

Copilot 在這裡不是噱頭，是省你點來點去

“Supercharge with Copilot — Leverage Copilot to generate nodes, fix errors, and iterate on flows directly from natural language.”

翻譯一下就是：你可以直接叫 Copilot 幫你生節點、修錯、改流程。這比那種「問答型 AI 助手」有用多了，因為它是插進 workflow authoring 的中間層，不是掛在旁邊聊天。

我對這種東西一直是半信半疑。原因很簡單，AI 很會把東西生得像真的。節點名稱看起來對，連線看起來也順，但細看就會發現它偷偷編了欄位、漏了例外、或是把一個應該失敗的情況硬寫成成功。這種假順手，我吃過太多次虧。

所以我會把 Copilot 定位成「草稿機」，不是「驗證機」。它適合幫我把流程先搭出來，減少點選成本；但最後的 schema、權限、錯誤處理，還是得我自己看。尤其 agent workflow 這種東西，一個錯誤的 edge 就可能讓整個流程走歪。

實操寫法：叫它先生骨架，再人工補血。你可以讓它幫你把節點類型、連線順序、基本說明先列出來，但不要直接把生成結果當成可上線版本。任何自然語言產物，都要過一輪人工檢查。

• 用 Copilot 產生骨架，不要直接產生最終版。
• 每個 node 的輸入、輸出、權限都要人工確認。
• 把錯誤處理當成必填，不要等出事才補。

如果你想對照更熟悉的生態，可以看 GitHub Copilot 跟 GitHub Models。Sim 的做法比較像把這類能力直接塞進流程編排裡，而不是讓你自己切頁面。

它把 vector search 當流程的一部分，不是外掛

“Integrate Vector Databases — Upload documents to a vector store and let agents answer questions grounded in your specific content.”

翻譯一下就是：文件上傳進向量庫，agent 回答時直接用你的內容當依據。這件事我很在意，因為太多 RAG 系統都死在一個地方：大家都在講 embedding，卻沒人處理資料清理、更新、切 chunk、查詢品質。

我以前做內部知識庫問答時，最煩的不是模型不夠聰明，是 retrieval 一直亂撈。文件版本沒控好、索引沒更新、查回來的段落跟問題根本不對焦，最後使用者只會說「這 AI 很會講廢話」。所以我現在看任何 agent 平台，第一個問題都是：它怎麼把 retrieval 接進整個 workflow？

Sim 讓我比較舒服的地方，是它不是把 vector search 當成額外功能，而是當成 agent flow 的一段。這很重要。因為 knowledge retrieval 不是獨立服務，它本來就應該跟工具調用、模型推理、輸出校驗放在同一條路上看。

實操寫法：把 ingestion 跟 query 分開。不要把文件匯入、索引更新、回答查詢混在同一個流程裡，不然你會很難 debug。再來，測試時不要只問正確答案，要故意問模糊、矛盾、過期的問題，看看 agent 會不會亂編。

• 只索引真的會用到的內容。
• ingestion 和 query 分開做。
• 用 adversarial 問題測 retrieval。

它提到的後端選項包含 pgvector，這種選擇我反而比較信。夠普通，才比較容易維護。

自架不是加分項，是它能不能進公司內網的門票

“Cloud-hosted: sim.ai” and “Self-hosted: Docker Compose”

翻譯一下就是：你可以用雲端版，也可以自己架。這件事看起來平凡，但對台灣很多團隊來說超現實。因為一旦牽涉到內部文件、客戶資料、權限控管，很多 SaaS 直接就被打槍。你沒有 self-host，連 PoC 都很難推進。

我看 Sim 的安裝路徑時，會注意它是不是只會講漂亮話。結果它把 NPM、Docker Compose、手動安裝都列出來了，還明講需要 Bun、Node.js 20+、PostgreSQL 12+ 和 pgvector。這種寫法很實際，因為它承認世界上真的有人要自己管環境。

更重要的是，這代表它不是那種只給你一個雲端控制台的殼。你可以看到它有 Next.js、socket server、database migrations、background jobs 這些東西。這些不是裝飾，是你之後要維運的現實。

實操上，我會這樣落地：先用 hosted 版驗證流程，再切 self-hosted。這樣可以先知道產品有沒有用，再決定值不值得把它放進自己的 infra。別一開始就把整套系統綁死，結果 demo 完才發現權限、資料流、網路政策全部卡住。

• 先用 hosted 跑 PoC，再決定要不要自架。
• 把 staging 跟 production 分開。
• 先寫好 secrets 管理規則，再讓別人碰流程。

它的技術棧也很直白：Next.js、Bun、PostgreSQL、Socket.IO。我喜歡這種沒有刻意炫技的組合。

這 repo 看起來像平台，不像週末 demo

“The open-source platform to build AI agents and run your agentic workforce.”

翻譯一下就是：它想當平台，不只是 library。這差很多。Library 是拿來拼的，platform 是拿來長期用的。你如果要做的是一套會被團隊反覆修改、反覆跑、反覆接工具的 agent 系統，那你要看的就不是「它能不能 demo」，而是「它能不能活下來」。

我會看 repo 的結構、文件、背景工作、執行邊界，因為這些東西比首頁文案誠實。Sim 的 repo 有 monorepo 味道，也有 async jobs、remote execution、schema 驗證這些痕跡。這表示它不是只想把 prompt 包成 UI，而是真的在處理 agent 會遇到的髒活。

我也注意到它用了 Trigger.dev、E2B、isolated-vm、Zod、Drizzle。這組合很像在告訴我：它知道 agent 不是只會聊天，還會跑任務、碰資料、執行程式碼，所以邊界要先畫好。

實操寫法很直接：你要先問自己，現在缺的是畫布、runtime、還是執行平台。不要因為看到 visual canvas 就誤以為整套問題都解了。如果你的痛點是權限、排程、重試、審計，那你要找的是平台級設計，不是漂亮 editor。

• 先判斷你需要 library 還是 platform。
• 看 repo 有沒有 tests、migrations、docs、deploy path。
• 凡是會 async 跑任務的系統，都要先想失敗怎麼收。

可抄的模板

# Agent Workflow Blueprint for a Sim-like Canvas

## 1. Goal
- Problem:
- User:
- Success criteria:

## 2. Inputs
- User request:
- System context:
- Retrieved documents:
- Required secrets:

## 3. Nodes

### Intake
- Type: input
- Purpose: normalize request
- Output schema:

### Router
- Type: agent
- Purpose: choose path
- Output schema:

### Retrieval
- Type: vector search
- Purpose: ground answer in internal content
- Output schema:

### Tool Call
- Type: tool
- Purpose: call external API or internal service
- Output schema:

### Synthesis
- Type: agent
- Purpose: combine context and tool results
- Output schema:

### Validation
- Type: guardrail
- Purpose: check schema, policy, and safety
- Output schema:

### Delivery
- Type: output
- Purpose: send final result
- Output schema:

## 4. Connections
- Intake -> Router
- Router -> Retrieval
- Router -> Tool Call
- Retrieval -> Synthesis
- Tool Call -> Synthesis
- Synthesis -> Validation
- Validation -> Delivery

## 5. Rules
- Every node has one job only.
- Every external call is retryable.
- Every retrieval step is testable with known docs.
- Every agent decision is logged.
- Every workflow has a failure path.

## 6. Self-host checklist
- [ ] PostgreSQL ready
- [ ] Vector support enabled
- [ ] Migrations applied
- [ ] Secrets stored outside repo
- [ ] Background jobs configured
- [ ] Realtime server reachable
- [ ] Workflow editor accessible

## 7. Testing checklist
- [ ] Happy path passes
- [ ] Empty input fails cleanly
- [ ] Tool timeout handled
- [ ] Retrieval returns no results handled
- [ ] Malformed model output rejected
- [ ] Retry path works
- [ ] Logs show node-by-node execution

## 8. Minimal orchestrator prompt
You are the workflow orchestrator.

Your job:
1. Inspect the request.
2. Select the correct path.
3. Retrieve only the needed context.
4. Call tools only when necessary.
5. Produce a structured final result.
6. Fail clearly when a step cannot continue.

Return:
- route
- reasoning summary
- required actions
- final output schema

這段我刻意寫成你可以直接拿去改的版本，因為我覺得這才是拆方法論該有的樣子。不是只講概念，而是讓你馬上能落到自己的 workflow、自己的工具、自己的部署規則。

我如果明天要開一個新的 agent 專案，我會先拿這份骨架，然後把工具、retrieval、validation、self-host 規則一個個填進去。不要一開始就追求花俏，先把資料流、錯誤流、執行流講清楚，才不會又做出一套看起來很猛、實際上很脆的東西。

來源致謝：上面的拆解主要來自 Sim GitHub repo https://github.com/simstudioai/sim，以及我對 README、安裝說明和 repo 結構的整理。模板段落是我根據原始資料重寫的衍生版本，不是直接複製原文。