📌 本文重點
- Sim 幫你管理一整隊多 Agent AI
- 用 TypeScript 定義角色與完整工作流
- 支援多家 LLM 與外部 API 工具
- 先從一條固定流程開始導入
Sim 要解決的問題很單純:你不想再手動 copy / paste 提示詞,而是讓一整隊 AI 员工自己分工、排程、回報進度。
Sim 是什麼?一句話定位
如果把 Claude、GPT 看成「單一員工」,Sim 就是幫你管理一整支 AI 團隊的中控台:
- 不提供自己的模型
- 專門用來定義多個 Agent 角色(
researcher、writer、reviewer…) - 負責任務分派、狀態管理、排程
- 幫你接上各家 LLM 與外部 API / 工具
你可以把它想成「用 TypeScript 寫的一個 Agent 作業系統」。
核心功能:用 TypeScript 排好一條完整工作線
1. 在一個專案裡定義多個 Agent 角色
Sim 的基礎就是:所有 Agent 都是 TypeScript 物件,你可以清楚寫出每個角色的職責與能力。
最小範例(簡化版):
// agents/researcher.ts
import { defineAgent } from "sim";
export const researcher = defineAgent({
name: "researcher",
model: "gpt-4.1",
instructions: "負責查找資料,整理重點,用 bullet points 回覆。",
});
// agents/writer.ts
export const writer = defineAgent({
name: "writer",
model: "claude-3-5-sonnet",
instructions: "根據研究重點,寫成條理清楚的文章草稿。",
});
// agents/reviewer.ts
export const reviewer = defineAgent({
name: "reviewer",
model: "gpt-4o",
instructions: "檢查文章結構、錯字與邏輯,提出修改建議。",
});
你可以採取的行動:
- 先從兩個角色開始(例如
researcher+writer),不要一開始就弄 5 個 Agent - 把你平常給 ChatGPT 的系統提示,搬進
instructions裡
💡 關鍵: 所有 Agent 以 TypeScript 物件定義,讓職責、模型與提示詞都可版本控制與共用。
2. 中央排程、任務分派與狀態管理
有了多個 Agent,接下來是:誰先做、做完交給誰、每一步狀態記錄在哪?
Sim 提供「任務 orchestrator」,你可以用工作流的方式描述整條流程:
// workflows/contentPipeline.ts
import { defineWorkflow } from "sim";
import { researcher, writer, reviewer } from "../agents";
export const contentPipeline = defineWorkflow({
name: "content-pipeline",
steps: [
{
agent: researcher,
input: (task) => `請針對主題:${task.topic} 搜集 5 個重點`,
saveAs: "researchNotes",
},
{
agent: writer,
input: (ctx) => ctx.researchNotes,
saveAs: "draft",
},
{
agent: reviewer,
input: (ctx) => ctx.draft,
saveAs: "reviewedDraft",
},
],
});
這段程式直接做到:
- 定義固定步驟順序(
research→write→review) - 每一步產出的結果存進 context(
researchNotes/draft) - 後面 Agent 直接讀 context,不用你再 copy / paste
你可以採取的行動:
- 先用一條同步工作流(一次跑完)熟悉 API
- 等熟悉後再考慮加排程(例如每天 9 點自動跑一次報表)
💡 關鍵: 透過 workflow 把多步驟流程寫死在程式中,避免人工在多個對話間來回 copy / paste。
3. 接現有 LLM 與外部 API / 工具
Sim 本身不訓練模型,而是非常直接地:
- 支援
OpenAI/Anthropic/Mistral等主流 LLM - 可設定不同 Agent 用不同模型(便宜模型做抓資料,貴模型做審稿)
- 提供工具介面讓 Agent 呼叫外部 API
範例:設定不同 Agent 用不同 provider:
// config/models.ts
export const models = {
cheap: { provider: "openai", model: "gpt-4.1-mini" },
strong: { provider: "anthropic", model: "claude-3-5-sonnet" },
};
// agents/reportBot.ts
import { defineAgent } from "sim";
import { models } from "../config/models";
export const reportBot = defineAgent({
name: "report-bot",
model: models.cheap,
tools: ["fetchSalesAPI", "generateCSV"],
});
你可以採取的行動:
- 先只用一個 provider(例如
OpenAI或Anthropic),確保 key 正常 - 把現有內部 API 包成簡單 function(例如
fetchIssues()),讓 Agent 直接呼叫
延伸閱讀:關於「模型只是基礎,缺的是中間這層 Agent / Workflow」的觀念,可以看這篇:
From Models to Agents: The Missing Layer Between AI and Real Problems
https://pub.towardsai.net/from-models-to-agents-the-missing-layer-between-ai-and-real-problems-8b08498780bd
適合誰用?三個具體場景
1. 內容生產流水線:多步驟寫作
典型流程:
researcher:收集資料、整理架構writer:產生初稿editor/reviewer:針對品牌語氣、錯字、結構調整
用 Sim,你可以:
- 把這條線寫成一支 workflow
- 每天丟一批題目進去,由 AI 團隊自動輸出草稿
- 人類只負責最後一層審稿
行動建議:
- 先挑一種固定格式內容(例如每週電子報)導入,不要從最複雜的長文開始
💡 關鍵: 把「固定格式內容」交給多 Agent 流水線,可穩定產出草稿,讓人類專注在高價值審稿。
2. 程式碼維護:issue triage → patch → review
典型流程:
triageAgent:閱讀 issue / log,分類並估工patchAgent:嘗試產生修補碼reviewerAgent:檢查 patch 是否合理
這個工作流很適合用 Sim:
- 由
triageAgent 先過一遍 backlog,把 issue 打標籤 patchAgent 先產生 PR 草稿reviewerAgent 給出建議,最後再交給人類工程師合併
行動建議:
- 先從「只產出 patch 草稿,不自動 merge」開始,上線風險較低
3. 資料處理 / 報表自動化
場景:
- 每天從內部系統拉數據
- 清洗 / 合併
- 生成自然語言報表,發到
Slack/Email
用 Sim 可以:
data-fetcherAgent:呼叫 API 把原始資料抓回來transformerAgent:整理成標準格式reporterAgent:寫出「本日營收摘要」「異常提醒」
行動建議:
- 從一份你現在已經在做的固定報表開始,把現有流程翻成 workflow
怎麼開始:最小 Demo 三步走
下面是一條「10 分鐘內跑起來」的路線,假設你有基本 Node / TypeScript 基礎。
步驟 1:拉專案 + 安裝
git clone https://github.com/simstudioai/sim
cd sim
pnpm install # 或 npm install / yarn
(建議用 pnpm,與官方 repo 一致。)
步驟 2:設定 LLM Key
- 建一個
.env或使用 repo 提供的環境變數範本 - 至少填一個 provider:
OPENAI_API_KEY=你的key
# 或
ANTHROPIC_API_KEY=你的key
- 在
config檔裡確認預設model指向你有 key 的 provider。
步驟 3:啟動一個簡單 workflow
- 在
examples/目錄中選一個最小示例(通常會有 content pipeline / hello-world workflow) - 執行:
pnpm run dev
# 或 repo 內標註的 demo 指令,例如:
pnpm run demo:content
- 到終端機或簡單 web UI 中,輸入一個主題,例如:
{
"topic": "2025 年 AI 多 Agent 平台現況"
}
你應該會看到:
researcher的查資料結果writer的初稿reviewer的修改建議
行動建議:
- 先改一下
instructions,讓它用你的品牌語氣寫,感受一次「只改提示就換整隊 AI 風格」的效果
跟現有工具銜接:Routing、MCP、部署注意事項
與 Routing 工具(如 Followloop)搭配
Sim 專注在「多 Agent 工作流內部的協作」,而像 Followloop 這類工具更像是:
- 負責不同入口的請求路由(例如:客服問答 →
FAQAgent;技術問題 →DevAgent) - 決定「這個請求要送到哪條 Sim workflow」
實際做法:
Followloop端:根據使用者請求分類,決定要呼叫哪個 Sim API endpoint- Sim 端:把每條 workflow 對外暴露成 HTTP endpoint
| 名稱 | 核心功能 | 免費方案 | 適合誰 |
|---|---|---|---|
| Sim | 多 Agent 工作流編排與執行 | 開源、可自架 | 想打造 AI 團隊的人 |
| Followloop | 請求路由與入口流量分配 | 視官方方案而定 | 有多入口流量的產品 |
與 MCP 工具共用
現在很多工具透過 MCP(Model Context Protocol)暴露能力,例如:
- 檔案系統存取
- 資料庫查詢
- 內部 API 代理
你可以:
- 在 Sim 的 Agent 定義裡,把 MCP 工具包裝成
tool - 讓 Agent 在 workflow 中直接呼叫 MCP 工具
好處是:
- 你不用重寫工具,Sim 只負責編排誰在什麼時候用哪個工具
部署:Vercel 或自家伺服器
Sim 是 TypeScript 專案,所以部署邏輯跟一般 Node / Next app 相近。
部署到 Vercel 時注意:
- 把各家 LLM 的 API key 設成 Vercel environment variables
- workflow 若有排程,需要配合 Vercel cron / Edge function 或外部 scheduler
- 注意 Vercel 的執行時間限制,長任務可能要改為 background job
部署在自家伺服器時注意:
- 確認
Node版本與 repo 要求一致 - 如果有敏感資料,建議:
- 把 LLM 呼叫走自家 proxy(避免直接暴露 key)
- 在 workflow context 中控制「哪些欄位可寫 log」
- Agent-to-Agent 通訊要考慮狀態持久化(例如用
Redis/Postgres),避免 Google A2A 那種「stateless agent 忘光對話」的問題(可參考這篇 Reddit 討論:https://www.reddit.com/r/artificial/comments/1synrp2/i_analyzed_3_a2a_approaches_2_already_failed/)。
一句話收尾:先把你的一條「固定流程」交給 Sim
不要一口氣把所有工作丟給多 Agent 系統,先挑一條你每天都在重複的流程(例如每週電子報、bug triage、固定報表),在 Sim 裡寫成 workflow,跑通一次,就能感受到「管理一整隊 AI 員工」的差別。
🚀 你現在可以做的事
- 到 GitHub 把
sim專案git clone下來,跑一次官方examplesworkflow- 把你現行的一條固定流程畫成步驟圖,翻成第一個 Sim workflow
- 把現有給 ChatGPT 的系統提示整理進
instructions,測試同一 workflow 換不同提示的效果


發佈留言