客戶發來一封詢盤，附件是一份不整齊的需求表。系統要識別產品、查資料、發現缺失條件，再準備回覆。固定欄位可以對映，含糊的要求需要判斷，最後的報價又不能未經確認就發出去。
這類工作不是“自動化或 Agent”二選一。Make 已把 Agent 放進 Scenario Builder：場景負責接收事件、組織輸入和連線系統，Agent 在其中選擇工具、使用知識並處理變化的資訊。Buda 則把執行放在一個能開啟檔案、檢視瀏覽器和終端、反覆修訂產物的工作區。
選擇的關鍵是：你主要在維護一條跨系統業務流程，還是在經營一份需要持續檢查與修訂的工作成果？
先把任務分成三類，而不是全部交給 Agent
Make 的新 Agent 入門文件給出了很實用的分流方式：
- **固定規則：**表單提交後同步 CRM、更新訂單狀態，使用標準 scenario。
- **固定引數的 AI 處理：**給定文字做翻譯、轉寫、摘要，使用帶 AI app 的 scenario。
- **變化輸入與判斷：**分類支援工單、篩選候選人、分析市場資料，使用帶 Agent 的 scenario。
如果輸出完全由輸入規則決定，增加 Agent 會引入不必要的不確定性。反過來，客戶需求不完整、工具呼叫要臨時選擇時，不能用幾十條固定分支假裝已經覆蓋所有情況。
Make AI Agent (New) 的文件對應 2026 年 2 月 2 日釋出的新版本，截至本次核驗仍標為 open beta。公開說明提醒功能與價格可能變化。
在 Make，一封詢盤如何進入 Agent
先搭一個只生成內部草稿的詢盤流程，暫不傳送客戶郵件、不寫正式報價。
**1. 用觸發模組接住輸入。**Make 的觸發說明覆蓋郵件、聊天、表單、webhook 和 mailhook，也說明可以按計劃自主執行。觸發模組決定請求從哪裡來，並不是 Agent 自己猜測該處理哪條記錄。
**2. 把本次需求和長期資料分開。**客戶訊息、附件是每次變化的 input 與 files；產品說明、FAQ、品牌政策可以作為 knowledge。文件將 knowledge 描述為儲存在 Agent memory 中的參考檔案，因此不能說 Make 沒有記憶或不會用檔案。
**3. 給 Agent 可呼叫的工具。**Make 的 tools 可以是 modules、scenarios、MCP server tools 和其他 agents。已配置的產品查詢 scenario 可以成為工具，但需要核對它接受的輸入、返回結果和寫入許可權，而不是隨意暴露整個後臺。
**4. 把判斷結果交給後續模組。**可以要求輸出產品分類、證據、缺失欄位和回覆草稿，再對映到內部稽核位置。給 Agent 一個明確的輸出要求，比要求“自己處理好客戶”更方便檢查和接手。
這裡的維護重點是觸發、欄位對映、連線與工具契約。每個環節都應有負責人，尤其是客戶附件格式變化、CRM 欄位改名或舊查詢工具返回空結果時。
Make 的可視除錯，不只是看最終回覆
新應用釋出說明描述了 Scenario Builder 內的建立、執行、測試和除錯：實時動畫展示思考狀態、耗時與工具呼叫順序；Reasoning 面板顯示用於排查決策的解釋；可以新增 tools 與 knowledge、聊天測試並處理檔案。
這些能力意味著 Make 的路線也能觀察 Agent 行動，不能把比較寫成“Make 黑箱、Buda 可見”。但可見資訊的組織方式不同：Make 圍繞場景與工具呼叫除錯，Buda 把檔案、網頁、命令和程式碼產物放在同一個執行現場。
Reasoning 面板提供的解釋不是正確性的獨立證明。工具選對了，也可能引用過期資料；場景全部執行成功，也可能遺漏客戶要求。驗收仍要檢查結果、來源和未解決問題。
在 Buda，讓詢盤形成一份可修訂的工作包
Buda 的Agent Workspace將聊天、持久 Files、Terminal、AI Browser、Web Preview 和 Git 放在同一臺雲電腦的多個檢視中。
同樣的詢盤可以先變成明確的任務包：客戶原文、批准使用的產品資料、禁止承諾的條款、回覆要求和交付目錄。Agent 整理附件，必要時瀏覽公開資料或執行指令碼，再生成需求表、來源清單與回覆草稿。
負責人檢查真實檔案和中間產物，指出需要改的引數。下一輪保留工作檔案，繼續修訂，而不是隻複製一段完成訊息。檔案的存在不代表授權完成；連線郵箱、CRM 或外部工具仍要單獨配置與核驗。
Drive 與記憶也需要明確邊界：一個 Agent 的持久檔案與團隊共享的 Space Drive 不是同一個位置。給第二位同事接手時，應明確哪些資料共享、哪個版本已接受，不能假設全部上下文會自動跨 Agent 出現。
比較維護物件，而不是比較誰“更智慧”
| 維護問題 | Make AI Agents 路線 | Buda 工作區路線 |
|---|---|---|
| 輸入從哪裡來 | scenario trigger 與欄位對映 | 任務輸入、Drive 與已配置連線 |
| 如何查業務資料 | knowledge 與 modules／scenarios／MCP 等工具 | 檔案、瀏覽器、指令碼與已授權工具 |
| 失敗後檢查什麼 | 場景步驟、工具順序、輸入輸出、Reasoning | 檔案、命令、網頁過程、任務與產物 |
| 第二個人接手什麼 | 場景配置、連線、工具契約與測試輸入 | 工作目錄、業務說明、版本與驗收標準 |
| 輸出怎樣回業務系統 | 後續模組及對映，需核驗授權 | 接受後的檔案交付或已驗證連線 |
如果核心問題是“某個事件發生後，幾套系統如何同步、路由、再插入一段判斷”，Make 的場景組織很自然。已有 Make 工作流的團隊，不應只因為出現新 Agent 產品就整體遷移。
如果工作常變成多份檔案、網頁研究、指令碼加工和跨輪修改，負責人需要直接開啟成果並繼續工作，Buda 的工作區更值得試用。這是對工作組織方式的判斷，不是經過實測的效率排名。
用失敗輸入檢查可維護性
不要只給兩個平臺一個乾淨樣本。準備三種測試：缺少產品型號、附件與正文衝突、查詢工具沒有結果。兩邊都要求停止猜測、標出缺口，並留下草稿供人決定。
記錄以下五件事：
- 能否追到原始輸入與採用的資料版本。
- 缺失資訊是否明確列出，而非被模型補全。
- 哪個工具失敗，重跑是否會產生重複寫入或重複傳送。
- 第二個人是否無需借用原賬號就能檢查並接手。
- 人接受了哪個版本，下一次由誰維護。
計量連線配置、返工、檢查和接手的實際耗時，再決定是否擴充套件。不預設 Make 更便宜或 Buda 更快；Make Credits、上游模型費用和 Buda Credits 也不能直接混成一個數字。
不必把同步流程和開放式產物綁在一起遷移
現有 Make 場景可以繼續承擔固定同步；需要研究和反覆修改的任務，可以在 Buda 準備審閱產物。兩邊交接時先約定檔案格式、記錄 ID、資料版本、寫回負責人和允許動作。
先從明確的檔案交付做起，分別配置兩邊需要的連線與工具；不要讓兩個 Agent 同時修改同一客戶記錄。最小試點只生成內部草稿，確認交接後再評估正式寫入。
在 Buda，先用真實但脫敏的輸入形成一份可審閱工作包。重複的步驟再整理為 Skill；也可以在 Buda AI 的 Marketplace 搜尋並安裝適用 Skill。先讓第二個人接手成功，再把“怎麼做”接上“何時執行”。
搭建時最容易卡住的三個地方
instructions 寫好了，為什麼 Agent 還是查不到 CRM？
先確認負責查詢的 module 或 scenario 已加入 tools，使用的連線賬號能訪問目標記錄。用同一個客戶 ID 單獨測試工具，檢查返回欄位，再把結果交給 Agent。把“查 CRM”寫進 instructions 只是提出任務，不會建立連線或補齊許可權。
已有的 scenario，怎樣改成 Agent 能呼叫的工具？
先縮到一個明確動作，例如“按產品編號查庫存”，而不是“處理整筆銷售”。定義必填輸入、返回欄位、查不到時的結果，並單獨測試。涉及傳送或寫入的動作，與只讀查詢分開；在草稿試點裡先不開放。Make 支援 scenario 作為工具，工具契約決定它能否被 Agent 正確使用。
怎樣避免 Agent 猜缺失資訊，或重跑時重複傳送？
輸出裡固定保留“缺失欄位”和“待確認項”，缺少產品型號時返回草稿，而不是生成報價。傳送與正式寫入放在獨立步驟，由人接受後觸發；每筆輸入保留記錄 ID，執行前檢查是否已處理。再用缺型號、衝突附件、空查詢結果各測一次，看系統是否按預期停在稽核位置。