標籤: 自動化工作流

  • 用 Claude.md 做一個不會爛掉的長跑代理

    用 Claude.md 做一個不會爛掉的長跑代理

    📌 本文重點

    • 用 CLAUDE.md 嚴格約束代理行為,避免長跑爛掉
    • 核心原則是「行動+證據」,禁止空談與無限迴圈
    • 透過上下文壓力自查與簡潔憲法,讓代理長時間穩定運作

    用一份不到 100 行的 CLAUDE.md,就能讓你的 Claude 代理連跑幾小時都不會開始胡言亂語、卡住不動或重複修同一個 bug。

    參考原作者在 Reddit 的分享:
    – 長跑 Claude Code 代理的設定檔開源文:https://www.reddit.com/r/ClaudeAI/comments/1tjy3sk/i_opensourced_the_operating_file_that_keeps_my/
    – 100 條個人 AI 代理實戰心得:https://www.reddit.com/r/ClaudeAI/comments/1thi6nh/100_tips_tricks_for_building_your_own_personal_ai/


    核心功能:這份 CLAUDE.md 到底做了什麼?

    1. 只允許「行動與證據」,禁止長篇空談

    長跑代理會爛掉,通常是這三個症狀:

    1. 開始寫「我將會…」「接下來我要…」但不真的執行工具
    2. 一直說「應該已修好」但沒有測試結果
    3. 花很多篇幅重複解釋計畫,實際變更很少

    CLAUDE.md 的核心規則,就是把這些行為全部關掉:

    • 輸出只允許三種型態:
    • 已完成的動作(例如:檔案修改、指令執行、API 呼叫)
    • 具體問題 / 需要決策的提問
    • 極短的進度摘要
    • 聲稱「完成」前要附證據:如測試輸出、報表截圖路徑、命令列結果

    💡 關鍵: 將輸出限制為「行動+證據」,能大幅減少長篇空談與無效迴圈,讓長跑代理真正持續推進任務

    你可以做的事:
    – 在你的專案根目錄放一份 CLAUDE.md,明確寫出:
    – 「不要描述你要做什麼,只要直接做並回報結果」
    – 「任何『應該已修好』前,必須貼出測試輸出」

    2. 內建「上下文壓力」自我檢查

    長跑幾小時後,對話上下文會變超長,Claude 開始:

    • 忘記早期需求
    • 無法把握目前專案狀態
    • 回答變模糊或重覆

    原作者在 CLAUDE.md 裡加了一條關鍵原則:

    代理要定期自查上下文壓力:發現自己搞不清狀態,就主動整理摘要、刪除多餘上下文、或要求人類幫它重設現狀。

    具體做法通常包含:

    • 每完成一個階段任務,就輸出一個「短摘要 + 關鍵檔案清單」
    • 長度過大時,優先保留:
    • 最新的決策
    • 目前版本的檔案 / 結構
    • 尚未完成的待辦

    你可以做的事:
    – 在 CLAUDE.md 寫明:
    – 「當你感覺自己不確定目前狀態時,先輸出一份 10 行內的現況摘要,再繼續工作。」
    – 「如需要,可要求人類提供『目前唯一真實狀態』說明,並用這份說明覆蓋舊假設。」

    3. 任務憲法:不靠「一長串 Prompt」,靠幾條簡潔原則

    多數人用代理會寫一大段 prompt,結果 Claude 讀不完、也記不住。CLAUDE.md 的思路是:

    • 用 10–20 條簡短規則,定義這個代理的「憲法」
    • 每條都要能對應到實際行為約束,例如:
    • 「若有工具可以做某事,優先用工具,不要手寫模擬輸出」
    • 「對同一錯誤連續嘗試 3 次仍失敗,就停下來請人類決策,不要無限迴圈」

    💡 關鍵: 把 10–20 條行為規則寫成固定「憲法」,比灌輸一大段單次 prompt 更能在長跑中維持穩定行為

    參考 Reddit 另一篇實戰文:https://www.reddit.com/r/ClaudeAI/comments/1thi6nh/100_tips_tricks_for_building_your_own_personal_ai/

    你可以做的事:
    – 先列出你的代理最常「爛掉」的 3 個行為,逐條寫進 CLAUDE.md,用「禁止 / 應改為」的格式:
    – 「禁止:連續兩次貼出幾乎相同的錯誤訊息。應改為:第二次失敗時,整理你已試過的方法,請人類選下一步。」


    適合誰用:3 個實戰場景

    1. 單機腳本型代理:排程任務、批次資料處理

    你有這些需求時,很適合:

    • 每晚跑一次報表轉檔腳本
    • 每週整理一批 CSV / Excel 檔,把欄位標準化
    • 定期爬某個網站的資料、存到本地或資料庫

    做法:

    1. 用 Claude Code 或本地腳本,讓代理可以:
    2. 讀寫特定資料夾
    3. 執行 shell 指令(或以 PowerShell / bash 包一層)
    4. 把 CLAUDE.md 放在專案根目錄,寫清楚:
    5. 允許改動哪些檔案
    6. 批次任務完成的判定方式(例如輸出檔案數量、檔名規則)
    7. 用排程工具觸發:
    8. macOS / Linux:cron 或 systemd timer
    9. Windows:排程工作排程器 + 命令列啟動代理腳本

    2. 長連線開發代理:Claude Code / VS Code / Cursor 類工作流

    如果你常用 Claude 來寫程式、改大型專案,長時間開著一個 session,很容易出現:

    • 忘記三小時前的設計決定
    • 重複修同一支檔案
    • 一直在講解架構,但實際 commit 很少

    這時 CLAUDE.md 非常好用:

    實際操作:

    1. 在 VS Code 專案根目錄新增 CLAUDE.md,內容包含:
    2. 專案簡述
    3. 允許的工具(例如:跑測試、執行 npm test、pytest 等)
    4. 「行動 > 敘述」與「證據 > 猜測」等規則
    5. 在 Claude Code / Cursor 內重新開啟專案,確保代理會讀到這個檔案
    6. 開發時明確下指令:
    7. 「請遵守 CLAUDE.md,連續工作直到完成以下任務…」
    8. 「每完成一個子任務,產出最多 5 行的進度摘要」

    進階:也可以搭配多代理流程,參考:https://www.reddit.com/r/ClaudeAI/comments/1thi16y/how_i_built_a_9agent_team_where_my_agents/

    3. 自建小型自動化服務:抓報表、清理資料

    你想做一些「半自動」小工具,例如:

    • 每週自動登入內部系統下載報表
    • 讀取資料夾裡的新檔案,做資料清洗 / 格式標準化
    • 根據最新資料,產出簡短摘要寄 Email

    可用的整合方式:

    • MCP / shell 指令:
    • 透過 Model Context Protocol 暴露一組工具給 Claude,例如:
      • list_files, read_file, run_command
    • 規則寫進 CLAUDE.md:

      • 「處理檔案時,一律用工具列出檔名,不要從記憶猜」
    • Power Automate:

    • 由 Power Automate 排程觸發 HTTP / CLI,呼叫你的 Claude 代理後端
    • 回傳的結果可再串 Outlook 寄信、寫入 Excel、更新 SharePoint

    你可以做的事:
    – 先選一個最小自動化任務,例如「每週整理銷售報表」,只把這一個流程寫入 CLAUDE.md,確保跑穩,再慢慢加其他任務。


    10 分鐘上手:從 fork 到跑起你自己的代理

    以下是一條「10 分鐘內能動起來」的最短路徑,你可以依你使用的工具微調。

    Step 1:fork 開源專案

    1. 前往 Reddit 原文查看作者提供的 repo(通常會在貼文內):https://www.reddit.com/r/ClaudeAI/comments/1tjy3sk/i_opensourced_the_operating_file_that_keeps_my/
    2. 在 GitHub 上 fork 到自己的帳號
    3. 本地 git clone 下來

    Step 2:複製 CLAUDE.md 到你的專案

    1. 打開作者的 CLAUDE.md,通讀一遍規則
    2. 複製到你自己的專案根目錄
    3. 只做三種修改:
    4. 把專案描述改成你的任務(例如:財報整理、數據清洗、網站爬蟲)
    5. 調整允許使用的工具(例如是否允許 rm / 刪檔)
    6. 加上 2–3 條你最在意的「不准爛掉」條款

    💡 關鍵: 只動專案描述、工具白名單與 2–3 條關鍵禁令,能在 10 分鐘內把通用 CLAUDE.md 變成專屬代理憲法

    Step 3:綁定你常用的工作環境

    依你用的平台選一條:

    • Claude Code / VS Code / Cursor:
    • 在這個專案資料夾內開啟編輯器
    • 確認工具(跑測試、shell、檔案操作)已啟用
    • 對 Claude 說:「請讀 CLAUDE.md 並照裡面的規則長時間工作」

    • MCP + shell 指令:

    • 建立一個 MCP server,提供 run_shell, read_file, write_file 等工具
    • 在 CLAUDE.md 明確寫出「所有系統操作一律經由 MCP 工具」
    • 用你偏好的前端(例如自寫 CLI、簡單 Web)呼叫 Claude

    • Power Automate / 其他自動化:

    • 建一個小型後端服務(可用 Python FastAPI / Node.js)包住 Claude API
    • 後端每次呼叫 Claude 時,都把專案檔案+CLAUDE.md 帶入 context
    • 用 Power Automate 定期觸發這個 API

    Step 4:跑一個「能觀察的」任務,調整規則

    1. 選一個 30–60 分鐘的任務給代理連續跑(例如重構某一個資料夾的程式碼)
    2. 觀察:
    3. 什麼時候開始廢話變多?
    4. 哪種情況會卡在同一個錯誤?
    5. 直接把這些「失敗模式」寫回 CLAUDE.md 變成新條款

    重複兩三輪,你會得到一份專屬於你工作流、而且真的能「長跑不爛」的代理憲法。


    小結:先管好行為,再管工具

    長跑 AI 代理很容易越跑越爛,通常問題不在模型,而在缺乏清楚的行為規則。透過一份設計良好的 CLAUDE.md:

    • 把輸出限制在「行動+證據」
    • 讓代理主動監控上下文壓力
    • 用幾條簡單原則當作「憲法」

    你可以在單機腳本、開發環境、多工具自動化裡,得到一個穩定得多的 Claude 代理。

    建議從今天開始:先為你最常用的一個專案寫一份 CLAUDE.md,跑一個完整任務,看看它能連續跑多久還保持專注。那會是你感受到「長跑代理真的可用」的第一步。

    🚀 你現在可以做的事

    • 在一個常用專案根目錄新建 CLAUDE.md,寫入「行動+證據」與上下文自查規則後實際跑一次長任務
    • 從 Reddit 原文 fork 作者 repo,閱讀並複製其中 CLAUDE.md,依你的工作流做 2–3 處客製調整
    • 列出你代理常見的 3 個「爛掉模式」,逐條轉寫成禁止條款加進 CLAUDE.md,並在下一次工作中觀察效果
  • 讓 Notion 變成你的 AI Agent 中樞

    讓 Notion 變成你的 AI Agent 中樞

    📌 本文重點

    • Notion 成為托管多個 AI Agent 的工作台
    • 以狀態變化與欄位更新觸發各種自動化工作流
    • 結合外部 SaaS,打造從資料拉取到 AI 清洗的資料管線

    只要把 Agent 綁在 Notion 頁面和資料庫上,你就能用原本的工作區,托管多個 AI 助手,自動整理內容、跑專案流程、甚至接上外部 SaaS 資料管線。

    參考:Notion 開發者平台介紹(TechCrunch 報導)
    https://techcrunch.com/2026/05/13/notion-just-turned-its-workspace-into-a-hub-for-ai-agents/


    核心功能:Notion 現在是「Agent 工作台」

    💡 關鍵: 把 Agent 綁定在「頁面 / 資料庫」上,等於讓 Notion 變成專屬 AI 助手的工作台,而不是單純筆記工具。

    1. 在頁面 / 資料庫綁定 Agent

    你可以把 Agent 視為「住在某個頁面或資料庫裡的專屬助手」:

    • 每個資料庫都能指定一個或多個 Agent,負責:
    • 自動摘要新頁面內容
    • 解析出行動項(Action items)
    • 幫你填欄位(負責人、優先級、標籤)
    • 每個重要頁面(像 PRD、會議紀錄)可以加上「頁面專屬 Agent」,只處理這一頁的內容與後續追蹤。

    你可以做的事:

    • 為「Meeting Notes」資料庫新增一個 會議整理 Agent,設定規則:只要有新筆記,就產出摘要+行動項目,寫回同一筆紀錄的欄位。

    2. 依「狀態改變」自動執行工作流

    Notion 的資料庫欄位(Status、Select、Checkbox 等)可以變成觸發條件:

    • 例:任務狀態從 Todo → In progress:
    • Agent 自動產生子任務(切分工作)
    • 寫一段「本週進度更新」到更新紀錄欄位
    • 例:狀態改為 Done:
    • Agent 生成 Retro 小結
    • 自動發 Slack 通知給相關頻道

    你可以做的事:

    • 在「專案任務」資料庫加一個 狀態更新 Agent,規則:
    • 當 Status 改成 In progress 時,自動新增 3–5 個子任務欄位建議,讓你選擇採用。

    3. 連接外部 API & 自家服務,變成資料管線

    透過 Notion 開發者平台,你可以把外部 SaaS 當作資料來源,丟進 Notion 再交給 Agent 清洗:

    • 從 CRM(如 HubSpot)、工單系統、回饋表單拉資料進一個「集中資料庫」
    • Agent 負責:
    • 解析文字欄位(工單描述、回饋內容)
    • 自動分類(類別、產品線、嚴重程度)
    • 加標籤或指派負責人

    你可以做的事:

    • 建一個 客戶回饋 資料庫,接上 HubSpot API,讓 Agent 自動幫每則回饋打標籤:功能請求 / Bug / 體驗問題。

    三種實戰場景:從內容、專案到資料管線

    💡 關鍵: 最穩起手式是「先在 Notion 裡把資料結構化」,再讓 Agent 針對欄位與內容運轉,而不是一開始就做複雜自動化。

    1)內容與知識管理:自動整理 PRD、會議紀錄

    典型設定方式:

    1. 建立一個 PRD 資料庫,每個 PRD 是一筆資料。
    2. 為這個資料庫綁定 產品文件 Agent,定義任務:
    3. 讀取 PRD 內容區塊
    4. 生成:
      • 300 字內摘要
      • 主要風險與假設
      • 需要決策的問題清單
    5. 生成內容寫回欄位(Summary / Risks / Decisions)。

    會議紀錄也一樣:

    • Meeting Notes 資料庫 + 會議助手 Agent:
    • 生成摘要
    • 抽取行動項目
    • 自動填入 Owner、Due date 欄位(依你設定的規則或會議參與者)。

    你可以馬上做的事:
    挑一個你最常用的會議紀錄資料庫,新增一個文本欄位 AI 摘要,再設定一個 Agent 規則:新紀錄建立後 1 分鐘內,自動寫入摘要。


    2)專案與工作流:從狀態變化觸發自動化

    想像 Notion = Trello + AI 助手:

    例:產品開發看板

    • 資料庫欄位:Status、Assignee、Priority、更新紀錄 等。
    • 綁定 專案 Agent 規則:
    • 當 Status 從 Design → Dev:Agent 讀整個卡片內容,
      • 自動產出測試清單(Test cases)
      • 寫入 更新紀錄:@QA 並貼測試重點
    • 當 Status → Ready for Release:
      • Agent 產生一段英文 / 中文 release note 草稿
      • 寄出或貼到 Slack 產品頻道。

    你可以馬上做的事:

    • 在專案資料庫加一個 Release note draft 欄位,設定 Agent:只要任務進入 Ready for Release,就根據「變更內容」欄位自動生成初稿。

    3)資料管線:外部工具 → Notion → Agent 清洗

    把 Notion 當成「中間站」:

    範例流程:HubSpot → Notion → AI 標註

    1. 用 Notion developer platform 建立一個簡單整合:
    2. 定期呼叫 HubSpot API 拉新聯絡人 / 回饋
    3. 寫進 Notion Leads 或 Feedback 資料庫
    4. 綁定 銷售線索 Agent 或 回饋分析 Agent:
    5. 解析文字欄位(詢問內容、工單描述)
    6. 填 機會大小、產品類別、優先級 欄位。

    工單系統也類似:

    • 從 Zendesk / Jira Service Management 拉工單進 Notion
    • Agent 自動:
    • 判斷是否為緊急問題
    • 建議指派對象
    • 生出對客戶的回覆草稿。

    你可以馬上做的事:

    • 先選一個來源(如 HubSpot),只同步最小的一個表格(例如最近 50 筆 leads),專心把「自動分類與優先級」這一步做好,再往後串通知或報表。

    怎麼開始:從零到第一個「週報 Agent」

    💡 關鍵: 從一個很小、明確的用例(例如週報)開始,比一次導入整個專案管理更容易落地與調整。

    步驟 1:開啟 Notion 開發者平台權限

    1. 進入工作區 Settings & members。
    2. 在 Integrations / Developers 區塊啟用開發者平台(某些方案需管理員權限)。
    3. 建立一個新 Integration,取得:
    4. Integration ID / Secret
    5. 可存取的資料庫與頁面範圍(務必限制在必要範圍)。

    官方入口:https://www.notion.so/my-integrations (依實際帳號會導向對應頁面)

    行動建議:
    先只開放一個「實驗用」工作區或資料庫給這個 Integration,避免一開始就讓 Agent 看到整個公司內容。


    步驟 2:建立你的第一個 Agent ——「週報助手」

    目標:你在 Notion 填一週做了什麼,Agent 自動:

    • 產出精簡週報
    • 幫你分欄:本週亮點 / 風險 / 下週計畫

    設計方式:

    1. 建立一個 Weekly Report 資料庫,欄位:
    2. Week(日期 / 文字)
    3. Raw notes(你隨便輸入的本週記錄)
    4. Summary(AI 產生)
    5. Highlights、Risks、Next week。
    6. 在開發者平台中,創建一個 週報 Agent:
    7. 觸發條件:Raw notes 更新
    8. 任務:讀取 Raw notes,用固定模板輸出 3 段內容,分別寫入三個欄位。

    你可以馬上做的事:
    找一週你真的很忙的那週,貼入原始 notes(甚至可以是 Slack 摘錄),讓 Agent 幫你整理,看輸出是否能直接拿去給主管或團隊。


    步驟 3:接一個常用 SaaS,從「一句需求」到「實際 automation」

    假設你想要:

    「每天把 HubSpot 新增的高潛力 leads 拉進 Notion,並且自動生成一段聯絡話術。」

    拆成執行步驟:

    1. 自然語言需求 → 規格
    2. 描述給你內部的 AI 或開發同事:
      • 資料來源:HubSpot 新增 leads
      • 條件:lead_score > 80
      • 寫入:Notion Leads 資料庫(Name / Company / Note)
      • Agent 任務:為每一筆產生一段 100 字內的開場訊息。
    3. 實作連接腳本(Node / Python 皆可):
    4. 呼叫 HubSpot API 抓資料
    5. 使用 Notion API 建立資料庫項目
    6. 在 Notion 綁定 銷售話術 Agent:
    7. 觸發:新 lead 建立
    8. 利用 lead 的欄位內容,生成個人化的聯絡訊息,寫入 Opening message 欄位。

    行動建議:
    先把這個流程做成「每天一次批次」而不是即時,方便你人工 review,一兩週成熟後再改成即時自動化。


    與 Zapier / Make 的差別在哪?

    工具類型 名稱 實際核心功能 免費方案 適合誰
    自動化平台 Zapier 連接上百種 SaaS,依事件觸發工作流 有,步數與任務量有限 以「事件轉發」為主的自動化(如表單 → Slack)
    自動化平台 Make 視覺化流程設計、條件分支豐富 有,執行次數有限 複雜條件、自定義 API 整合多
    Agent 中樞 Notion + Agents 在內容上下文中運行 Agent,直接操作頁面 / 資料庫 視方案與工作區設定而定 已把工作放在 Notion,上下文豐富、需要 AI 理解內容的人

    關鍵差異:

    • Zapier / Make:強在「事件與資料欄位」,邏輯清楚但不懂內容。
    • Notion + Agent:強在「內容與上下文」,適合需要理解長文、文件關係的自動化(PRD、會議、工單描述)。

    最實用的做法通常是:

    • 讓 Zapier / Make 負責「資料搬運」
    • 讓 Notion Agent 負責「讀懂內容、整理與生成」。

    安全與權限:啟用前要先想好的事

    在公司導入前,至少做這三件事:

    1. 縮小可見範圍:
    2. 為每個 Agent 建立專用資料庫與頁面,不要一開始就給整個 workspace 權限。
    3. 區分測試與正式環境:
    4. 先在 sandbox workspace 測試 prompt、輸出格式,再搬到正式專案。
    5. 記錄與監控:
    6. 保留 Agent 執行紀錄(可考慮接像 Voker.ai 這類 agent analytics 工具)
    7. 定期 review Agent 產出,調整規則與權限。

    只要你把權限、資料範圍與監控設計好,Notion 就不再只是筆記本,而會變成團隊所有 AI Agent 的中樞:每天在你已經習慣的頁面和資料庫裡,默默跑完一堆你本來要手動做的事。


    🚀 你現在可以做的事

    • 在現有的 Meeting Notes 資料庫新增 AI 摘要 欄位,綁定一個簡單的會議整理 Agent 測試輸出品質
    • 建一個獨立的 Weekly Report 資料庫,實作文中「週報 Agent」流程,實際跑一週看看是否減少整理時間
    • 選一個你常用的 SaaS(如 HubSpot / Zendesk),只同步一小部分資料到 Notion,讓 Agent 做分類與摘要清洗實驗
  • 用 Sim 管一整隊 AI 員工

    用 Sim 管一整隊 AI 員工

    📌 本文重點

    • Sim 幫你管理一整隊多 Agent AI
    • 用 TypeScript 定義角色與完整工作流
    • 支援多家 LLM 與外部 API 工具
    • 先從一條固定流程開始導入

    Sim 要解決的問題很單純:你不想再手動 copy / paste 提示詞,而是讓一整隊 AI 员工自己分工、排程、回報進度。

    專案連結:https://github.com/simstudioai/sim


    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. 內容生產流水線:多步驟寫作

    典型流程:

    1. researcher:收集資料、整理架構
    2. writer:產生初稿
    3. editor / reviewer:針對品牌語氣、錯字、結構調整

    用 Sim,你可以:

    • 把這條線寫成一支 workflow
    • 每天丟一批題目進去,由 AI 團隊自動輸出草稿
    • 人類只負責最後一層審稿

    行動建議:

    • 先挑一種固定格式內容(例如每週電子報)導入,不要從最複雜的長文開始

    💡 關鍵: 把「固定格式內容」交給多 Agent 流水線,可穩定產出草稿,讓人類專注在高價值審稿。

    2. 程式碼維護:issue triage → patch → review

    典型流程:

    1. triage Agent:閱讀 issue / log,分類並估工
    2. patch Agent:嘗試產生修補碼
    3. reviewer Agent:檢查 patch 是否合理

    這個工作流很適合用 Sim:

    • 由 triage Agent 先過一遍 backlog,把 issue 打標籤
    • patch Agent 先產生 PR 草稿
    • reviewer Agent 給出建議,最後再交給人類工程師合併

    行動建議:

    • 先從「只產出 patch 草稿,不自動 merge」開始,上線風險較低

    3. 資料處理 / 報表自動化

    場景:

    • 每天從內部系統拉數據
    • 清洗 / 合併
    • 生成自然語言報表,發到 Slack / Email

    用 Sim 可以:

    1. data-fetcher Agent:呼叫 API 把原始資料抓回來
    2. transformer Agent:整理成標準格式
    3. reporter Agent:寫出「本日營收摘要」「異常提醒」

    行動建議:

    • 從一份你現在已經在做的固定報表開始,把現有流程翻成 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

    1. 建一個 .env 或使用 repo 提供的環境變數範本
    2. 至少填一個 provider:
    OPENAI_API_KEY=你的key
    # 或
    ANTHROPIC_API_KEY=你的key
    
    1. 在 config 檔裡確認預設 model 指向你有 key 的 provider。

    步驟 3:啟動一個簡單 workflow

    1. 在 examples/ 目錄中選一個最小示例(通常會有 content pipeline / hello-world workflow)
    2. 執行:
    pnpm run dev
    # 或 repo 內標註的 demo 指令,例如:
    pnpm run demo:content
    
    1. 到終端機或簡單 web UI 中,輸入一個主題,例如:
    {
      "topic": "2025 年 AI 多 Agent 平台現況"
    }
    

    你應該會看到:

    • researcher 的查資料結果
    • writer 的初稿
    • reviewer 的修改建議

    行動建議:

    • 先改一下 instructions,讓它用你的品牌語氣寫,感受一次「只改提示就換整隊 AI 風格」的效果

    跟現有工具銜接:Routing、MCP、部署注意事項

    與 Routing 工具(如 Followloop)搭配

    Sim 專注在「多 Agent 工作流內部的協作」,而像 Followloop 這類工具更像是:

    • 負責不同入口的請求路由(例如:客服問答 → FAQ Agent;技術問題 → Dev Agent)
    • 決定「這個請求要送到哪條 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

    部署在自家伺服器時注意:


    一句話收尾:先把你的一條「固定流程」交給 Sim

    不要一口氣把所有工作丟給多 Agent 系統,先挑一條你每天都在重複的流程(例如每週電子報、bug triage、固定報表),在 Sim 裡寫成 workflow,跑通一次,就能感受到「管理一整隊 AI 員工」的差別。

    🚀 你現在可以做的事

    • 到 GitHub 把 sim 專案 git clone 下來,跑一次官方 examples workflow
    • 把你現行的一條固定流程畫成步驟圖,翻成第一個 Sim workflow
    • 把現有給 ChatGPT 的系統提示整理進 instructions,測試同一 workflow 換不同提示的效果
  • 一行指令接上多模態 AI:MMX-CLI 實戰

    一行指令接上多模態 AI:MMX-CLI 實戰

    用一句話講清楚:MMX-CLI 讓你用一行指令,就能在本機腳本或 Agent 裡,直接調用文字、圖片、影片、語音、音樂、視覺分析與搜尋等多模態 AI 能力,而且輸出格式乾淨,好串自動化。

    📌 本文重點

    • 一套 mmx CLI 管文字、圖片、影片等七種多模態能力
    • stdout / stderr 分流設計,超適合腳本與 CI 自動化
    • 支援語義錯誤碼與 async,穩定掛在長鏈式工作流後面
    • Node / JS 友善,當「通用多模態 AI 插件」掛在任何工具裡

    專案來源:Reddit 介紹帖(含原始連結):https://www.reddit.com/r/LocalLLaMA/comments/1skfhix/minimax_released_mmxcli_one_cli_for_text_image/


    核心功能:為「會寫指令的人」準備的多模態外掛

    💡 關鍵: 一套 mmx 前綴的 CLI 就涵蓋七種多模態能力,大幅減少安裝與學習不同 SDK 的成本

    1. 七大多模態指令組:一套 CLI 管全部

    MMX-CLI 的指令前綴都是 mmx,再接子指令:

    • mmx text:文字生成功能(寫文案、草稿)
    • mmx image:圖片生成、批次生成
    • mmx video:影片生成(支援非同步)
    • mmx speech:文字轉語音 / 語音相關
    • mmx music:音樂生成
    • mmx vision:圖片理解、標註、OCR 類任務
    • mmx search:網路搜尋 / 檢索

    可行動重點:

    • 想做「終端裡直接問圖」、「批量出圖」或「自動生成影片」,都只要學一個 mmx 開頭的 CLI 即可,不必各裝一套 SDK。
    • 在腳本中只要換子指令,就能把文字流程擴充到圖像、影音,不用改整個架構。

    2. stderr/stdout 分流:為自動化管線設計的輸出

    多數 AI CLI 會把提示訊息、JSON 結果都塞在一起,要解析結果時只好寫一堆正則。MMX-CLI 的設計直接幫你分好:

    • stdout:只輸出「乾淨結果」,例如 JSON、檔案路徑
    • stderr:UI 提示、進度條、debug 訊息

    💡 關鍵: 把結果與提示嚴格分流,讓你在 CI / 腳本裡直接吃 JSON,不用再寫正則清洗輸出

    這代表你可以這樣用:

    mmx image generate \
      --prompt "一張藍底白字的活動宣傳圖" \
      --json \
      1> result.json \
      2> log.txt
    
    • result.json:可直接被 jq、Python、Node 解析
    • log.txt:留給人類看錯誤、進度

    可行動重點:

    • 在任何 Shell/CI pipeline 裡,用 1>、2> 就能區分機器要吃的結果、跟人類要看的訊息,少很多「切字串」的工作。

    3. 語義錯誤碼與 async:穩定接在長鏈式工作流後面

    MMX-CLI 有兩個很適合自動化的設計:

    1. 語義錯誤碼(semantic exit codes):
    2. 不只是 0/1,而是用不同 exit code 表示不同錯誤類型(如:授權、配額、參數錯誤等)。
    3. 你可以在腳本裡根據 $? 做分支處理,而不是只知道「失敗」兩個字。

    4. async 影片與圖片一致性:

    5. mmx video 支援 --async 或 --no-wait,提交生成後直接結束,不會在終端卡很久。
    6. 產生的任務 ID 可存起來,之後再查詢結果,適合長影片或大量任務情境。
    7. mmx image 支援像 --subject-ref 這類選項,可讓同一批生成的圖片保持主體一致(同一個角色、同一個風格),方便做系列素材。

    💡 關鍵: 用語義錯誤碼搭配 async 任務查詢,可以在長鏈式自動化裡做精細錯誤分流,又不會堵住整條 pipeline

    可行動重點:

    • 在 CI / 排程任務中,影片生成用 --async,後面接一個輪詢/查詢腳本,不會讓 pipeline 掛住。
    • 社群素材、產品圖需要「同一個角色」時,在同一批任務加入主體參考參數,減少後期修圖重工。

    適合誰用:把 MMX-CLI 當「通用 AI 插件」來掛

    1. 本機腳本與自動化 pipeline:用 CLI 批量做內容

    典型用法:每天自動生成社群素材(文字 + 配圖)。例如一個簡單的 cron 任務:

    1. 用 mmx text 生成今天要發的貼文文案。
    2. 把文案丟給 mmx image 生成對應主圖。
    3. 結果存到指定資料夾 + JSON 清單。

    Shell 示例:

    #!/usr/bin/env bash
    set -e
    
    # 1. 生成文案
    caption=$(mmx text generate --prompt "替科技品牌寫一則今日 IG 貼文,50 字內,口吻輕鬆" --plain)
    
    # 2. 生成圖片(輸出 JSON,內含檔案路徑)
    mmx image generate \
      --prompt "$caption" \
      --json 1> image.json 2> /dev/null
    
    image_path=$(jq -r '.outputs[0].path' image.json)
    
    echo "文案:$caption"
    echo "圖片:$image_path"
    

    可行動重點:

    • 任何原本用 Bash / Python 後面接 curl + OpenAI API 的地方,都可以試著改成 mmx text/image/...,讓指令更短、錯誤處理更好做。

    2. 在 Claude Code / Cursor / OpenClaw 裡當「外掛能力」

    MMX-CLI 可以直接被這些 Agent/IDE 工具當成外部命令調用,不需要額外架 MCP Server:

    • Claude Code / Cursor:程式碼助手可以呼叫系統指令(例如 !mmx ... 或 task runner),把多模態功能塞進 coding workflow。
    • OpenClaw 等 Agent 框架:把 mmx 視為一個 tool,交給 Agent 自己 decide 什麼時候用圖像、影片、搜尋能力。

    範例 workflow(以 Cursor 為例):

    1. 在專案的 script 區塊新增一條:「mmx vision analyze 對當前專案的 UI 截圖做說明」。
    2. 用自然語言跟 Cursor 說:「請幫我分析 screenshot.png,找出 UI 過於擁擠的區域」,由 Cursor 呼叫該 script,再回傳結果給你。

    可行動重點:

    • 如果你已經在用 Claude Code / Cursor,試著加一條腳本(後面會給最小範例)讓它能調用 mmx vision,等於幫 Agent 長出「看圖」能力。

    3. 想要簡化多模態 API 整合的工程師 / Side project 作者

    MMX-CLI 用 TypeScript 寫成,跑在 Node.js 18+ 上:

    • 對前端 / JS 工程師特別友善,可以輕鬆串到 Node 腳本、Electron、Next.js 後端。
    • 不想碰太多 SDK,單純想「能被命令行叫起來,回傳 JSON」,就很適合直接用這一套。

    可行動重點:

    • 當你在 side project 裡只需要一兩個 AI 能力(例如:上傳照片 → 生成說明文字),優先考慮用 child_process 呼叫 mmx,先把功能打通,再考慮要不要換成直接 API。

    怎麼開始:3 分鐘跑通你的第一個多模態任務

    1. 環境需求與安裝方式

    基本需求:

    • Node.js 18+(建議直接裝 LTS 版本)
    • npm / npx 可用

    安裝成全域「技能」:

    npx skills add MiniMax-AI/cli -y -g
    

    或一般全域安裝(若專案說明有提供 npm package):

    npm install -g @minimax-ai/mmx-cli   # 依官方實際名稱調整
    

    最新安裝指令以官方 README 為準,可從 Reddit 原文往下點到 GitHub 或官網。

    可行動重點:

    • 先確認 node -v 是 18 以上;若不是,先更新 Node,再來跑 npx skills add ...。

    2. 最小可執行範例:一行文字 → 一張圖片

    安裝完後,先試一個最簡單的生成任務:

    mmx image generate \
      --prompt "一張極簡風格的藍底白字技術活動海報" \
      --json
    

    預期行為:

    • 終端 stdout 輸出一段 JSON,其中會包含生成圖片的本地路徑或 URL。
    • stderr 會有模型載入、進度等訊息,不會干擾 JSON。

    若只想要檔案路徑,可以接 jq:

    mmx image generate \
      --prompt "一張極簡風格的藍底白字技術活動海報" \
      --json 2>/dev/null | jq -r '.outputs[0].path'
    

    可行動重點:

    • 改幾個不同 prompt(例如品牌名稱、活動主題),就能快速做出一批風格一致的海報草稿。

    3. Node 腳本範例:用 JS 串多模態流程

    如果你想直接在 Node 專案裡用 MMX-CLI,下面是一個「讀文字 → 生成語音檔」的最小範例:

    // file: tts.js
    import { execFile } from 'node:child_process';
    
    function runMMX(args) {
      return new Promise((resolve, reject) => {
        execFile('mmx', args, { maxBuffer: 1024 * 1024 }, (error, stdout, stderr) => {
          if (error) {
            console.error('MMX stderr:', stderr);
            return reject(error);
          }
          try {
            const json = JSON.parse(stdout);
            resolve(json);
          } catch (e) {
            reject(e);
          }
        });
      });
    }
    
    (async () => {
      const text = '歡迎使用 MMX-CLI,這是一個多模態 AI 的命令列工具。';
      const result = await runMMX([
        'speech',
        'generate',
        '--text', text,
        '--json'
      ]);
    
      console.log('生成的音檔路徑:', result.outputs[0].path);
    })();
    

    執行:

    node tts.js
    

    可行動重點:

    • 把這支腳本換成 vision analyze 或 video generate,你就能在 Node 專案裡快速測出多模態能力,不用先研究一整套 API。

    小結:MMX-CLI 的定位與你可以立刻做的三件事

    MMX-CLI 適合被當成「通用多模態 AI 插件」掛在任何能呼叫命令列的地方:腳本、CI、Agent、IDE。

    你現在可以立刻做的三件事:

    1. 安裝並跑通最小範例:升級 Node → npx skills add MiniMax-AI/cli -y -g → 跑一個 mmx image generate。
    2. 在現有腳本裡替換一個原本用 curl + API 的地方,改用一條 mmx text,感受 stderr/stdout 分流帶來的差異。
    3. 在 Claude Code / Cursor 專案裡加一條呼叫 mmx vision 的 script,讓你的程式碼助手從「只會看文字」變成「看得懂圖片」。

    只要能打開終端,你就能用 MMX-CLI 把多模態 AI 接到任何地方。

    🚀 你現在可以做的事

    • 打開終端,確認 node -v 版本後,依文中指令安裝 mmx 並跑一次圖片生成
    • 挑一個現有 Bash / Node 腳本,把其中一段 curl + API 改寫成對應的 mmx text 或 mmx image
    • 在你的 Claude Code / Cursor 專案設定裡新增一條腳本,讓它可以呼叫 mmx vision analyze 來查看專案截圖