閱讀說明
本頁是綜合講解後半部分的中文譯文，接續工作流對映與組織知識。先呈現講義中的工具連線，再保留生成影象、3D 場景與整理示例票據的口頭講解。
這裡描述的是原演示，不代表網站實際執行了這些工具，也不提供原賬戶、金鑰、私人檔案或帶身份的截圖。產品介面、型號和功能可能變化，復現前需要查相應版本。
講義一：無程式碼工具與連線能力
原工具圖列出 Make、Claude、Perplexity Computer、n8n、Zapier、ChatGPT Agent、Cowork、Manus、Hermes Agent 和 ZeroClaw 等名稱，用來展示不同自動化與 Agent 方向。
它們不屬於完全相同的產品類別，也不是一個永久有效的能力排名。選擇時應檢查任務、資料、許可權、維護與費用，而不是隻比較名字。
講義二：API 與 MCP
API 定義軟體怎樣請求資訊或動作：應用發出請求，外部系統處理，再返回響應。呼叫方不必知道服務內部全部實現，但需要遵守介面與許可權約定。
MCP 為 AI 應用發現和使用外部能力提供共同方式。沒有連線時，系統可能只能說明步驟；有合適工具連線和授權以後，才能讀取相應資訊或執行動作。
API 面向具體功能，MCP 則可以作為統一能力介面；服務端背後仍可能呼叫 API。因此，MCP 不替代 API，也不是連線以後就擁有對方全部功能。
檢視圖解文字說明
宿主是 AI 應用，負責管理模型使用方式和多個客戶端。圖中客戶端 A 連線資料服務端，客戶端 B 連線工單服務端；服務端可以暴露工具、資源或提示。連線方式統一不表示訪問範圍、事實與執行安全自動得到保障。
圖中許可權、客戶端和服務端仍然分開。哪些能力公開、哪些請求可以執行，取決於實際配置。
口頭文字稿一：從現成工具開始
無程式碼和 Agent 工具讓沒有完整開發背景的人也能試驗，開發人員也可以用它們減少重複操作，把精力放在關鍵決定上。
原講解計劃使用 Make、Claude 等工具，也提到可自管的 Agent 路線。它先回到 API，說明不同軟體怎樣交換資料、使用對方服務。
在工作流平臺裡連線模型
演示開啟一個已有的社交內容工作流，透過連線配置接入模型和其他工具。工具所需的訪問憑據來自對應服務賬戶，再按平臺要求安全配置。
原演示臨時建立了一個用於示範的 API 金鑰，複製到連線設定，隨後清理。文字稿沒有提供可公開使用的憑據，本頁也不展示任何真實值。
譯註：原講解把金鑰比作地址或電話號碼，容易混淆。API 是介面，端點地址說明訪問哪裡，金鑰則通常用於識別或授權請求，應當作為憑據保護。短期使用也不意味著所有平臺都支援自動到期，應核對實際機制並在不再需要時撤銷。
過去，接入 API 往往需要開發人員專門處理介面；演示強調，許多現代平臺已經把常見連線做成配置入口，讓試驗更容易。但預製連線並不免除認證、介面變化和錯誤處理。透過介面，模型、訊息工具和其他服務可以在同一流程中工作，減少人工切換。它們沒有被“裝進”同一個模型，仍是透過網路和應用邏輯交換請求與結果。
口頭文字稿二：用 MCP 連線影象工具
原演示在聊天應用的聯結器設定中，找到外部影象工具並重新授權。授權完成後，要求生成一張寫實賽車圖片，並明確使用對應工具。
應用先識別可用連線，準備更具體的影象提示，等待確認後發起生成。演示中一度出現顯示問題，隨後嘗試從工具結果返回影象。
這說明對話可以成為工具入口，但請求已發出、服務已受理、影象已生成、結果能顯示，是不同狀態。文字稿不能證明最終影象滿足了全部要求，本頁不把未取得的原圖當作已經復現。
討論中另有一個應用思路：在本地網頁應用中接入影象或語音服務的 API。它說明本地介面也可以使用外部能力；“介面執行在本地”與“模型處理也在本地”仍須分開判斷。原講解說連線以後聊天應用“擁有全部能力”，需要收窄理解：它只能使用服務端實際公開、賬戶有權使用且宿主支援的那部分功能。
口頭文字稿三：用 MCP 操作本地 3D 場景
接下來，演示從雲端影象工具轉向本地 Blender。Blender 是開放原始碼的 3D 製作軟體，但實際建模仍需要知識與練習。
演示環境已經配置了連線元件與本地服務，讓聊天應用能夠透過 MCP 操作場景。原講解在介面中看到相關設定，不代表每一份 Blender 安裝都預設自帶同樣元件。
請求是：先清空示例場景，再製作一把維多利亞風格椅子。也可以提供照片、插圖或攝影測量資料作為參考；完整場景還涉及物件、材質、燈光等不同部分。
譯註：清空場景是修改操作，只應在明確的演示副本中執行並保留可恢復版本。生成一個看起來像目標的模型，也不等於建立了具有工程精度或真實狀態同步的數字孿生。
這個例子展示，本地應用也可以接到 AI 工具流程中。與雲端服務相比，執行位置不同，但資料是否離開裝置，仍取決於整個呼叫鏈，而不是隻看 Blender 在本地執行。
口頭文字稿四：授權身份、組織治理與資料位置
原討論提出一個實際問題：釋出帶連線的 Agent 時，究竟使用終端使用者的許可權，還是製作者的許可權？這會影響誰能夠讀取和執行什麼，也影響治理與使用便利。
組織首先需要避免未經批准的影子 AI。個人能夠登入某項工具，不代表有權把組織資料交給它處理。還要看資料用途、合同、行業規則和服務條件。
原講解用員工把內部程式碼交給聊天工具分析的新聞例子，說明智慧財產權與資料外傳風險。儲存材料未完整確認該事件來源，所以這裡保留的是判斷問題，不把敘述當成經過驗證的事故報告。
雲端處理可能意味著資料傳到服務商，但不能據此認定所有云服務都會拿資料訓練，或所有商業閉源模型都不能用於組織。不同產品、合同、保留設定和訪問方式需要分別檢查。
本地或自管模型是一條可選擇路線，也會有裝置、更新、許可權、日誌和備份方面的要求。開放權重不自動等於安全，全部在本地也不自動等於已經滿足所有治理條件。
原講解偏好對敏感資料採用本地方式，這是其實施取向；適合哪個組織，應根據實際威脅、資源與條款判斷。
口頭文字稿五：先說明票據 Agent 的目標
下一個示例是票據整理。希望把照片、掃描件和郵件 PDF 放進收件資料夾，系統就能識別新檔案，提取日期、商家、金額、幣種、類別、賬戶、稅項和付款線索。
隨後重新命名、分類並放到合適資料夾，更新費用表，再把無法確定的問題留給人。原講解提到 Excel、會計軟體或合併 PDF 等交付形式，取決於實際使用者需要。
這不是讓系統替代所有會計工作，而是輔助整理資料。演示中使用的是虛構票據；原講解也區分了為展示方便使用的雲端工具與其實際部署偏好的本地路線。
初始專案描述
原演示先建立一個專案，用簡短目標說明：把票據的照片、掃描與郵件 PDF 變成會計可以使用的記錄；區分業務和個人，按會計年度與費用型別歸檔，明確命名，並在表格中記錄建議類別。
把資料、目標和指令儲存在專案裡，可以減少重複解釋，但不能預設應用永遠記住全部內容。具體上下文、檔案訪問與記憶方式仍受產品實現限制。
原文字稿對演示時選擇的模型名稱有不清楚的轉寫，因此不猜測版本。講解表達的是使用較合適的計算等級控制投入，而不是所有任務都選最昂貴的配置。
口頭文字稿六：把規則寫成可執行要求
原演示隨後加入更具體的指令。這裡保留其中的知識性要求，目錄名用示意名稱表示。
- 這是票據與費用資料庫，新資料放進收件目錄；執行前先檢視可用背景和目錄。
- 如果一個 PDF 包含多張票據，應當把每張分別識別並儲存對應記錄，同時保留原件。
- 讀取日期、商家、購買專案、總額、稅項和付款線索，例如付款卡末四位；不得收集不必要的完整卡號。
- 根據已確認規則區分業務和個人。沒有明確付款線索時，可檢查賬單名稱或收件地址，但仍須核對。
- 業務票據按實體、會計年度與型別歸檔，個人票據按相應年度整理。
- 用清楚規則命名檔案，把業務專案加入費用表。
- 不要猜測。不確定時移到待審位置，在備註寫出問題；不要刪除原始檔案。
- 完成後說明處理數量、各類別合計和待回答問題。
- 人確認的修正可以形成新規則，儲存在業務說明或規則檔案，並在適當範圍內用於以後執行。
譯註：付款卡只是線索，不足以單獨決定業務性質或稅務處理。會計年度、實體關係與費用分類應由實際規則和具備相應知識的人確認；這段描述用於解釋流程設計。
原演示把本地示例目錄連到應用，然後只發出短請求：“按照專案指令，處理資料夾中的票據。”請求可以很短，是因為詳細邊界已經在專案裡；不是因為系統天然知道應該怎麼做。
口頭文字稿七：執行前怎樣補足缺少資訊
執行開始後，工具列出準備步驟：讀取 20 張示例票據，分類、歸檔和重新命名，建立費用表與業務說明，再檢查並彙總。
它沒有直接假定會計年度，而是詢問年末日期；演示回答採用 12 月 31 日。它還詢問哪些示例付款卡屬於業務。原講解指出，這些可以提前提供，但特意留空後，系統是否會詢問，就成為一個有用觀察。
“不清楚先問”因此是實際要求，而不是最後才加上的口號。取得資料夾許可權也不代表可以任意改動電腦其他位置，執行範圍仍應受限。
原演示等待處理時，再次討論雲端與本地的選擇。把財務資料交給雲端之前，需要確認許可權與處理條件；若採用本地系統，也必須檢查模型、應用與其他連線是否仍有外部傳輸。
口頭文字稿八：檢視結果，再測試糾正
原演示隨後展示：原始檔案仍在，新增了業務與個人目錄，業務內容按年度與類別分開，同時建立表格。
這只是演示者看到的介面結果，不足以證明全部欄位和合計都正確。真正驗收還應比較原件數量、提取值、重複與遺漏、分類依據及表格內容。
接著，演示者挑選一張原先歸為個人的餐飲票據，說明它實際屬於業務費用，觀察系統怎樣修正目錄、表格和規則檔案。
執行過程中發生了命令失敗和檔案覆蓋問題。原演示推測可能因為表格仍被開啟，並出現請求允許刪除檔案的介面；之後又產生了更新版本的費用表。
譯註：這暴露出原演示中的重要張力：前面的要求是保留原件，但後來出現較寬的刪除授權。不能把直接批准永久刪除當成推薦步驟。可靠實現應區分原件與派生檔案、縮小修改範圍、保留備份，確認更新的是正確版本，並檢查糾正是否完整。
原講解開啟業務說明，看到“已學到的規則”區域，把修正用於後續判斷。這裡的“學習”指儲存和重用規則，不必涉及模型重新訓練。新規則還應寫明適用物件，避免把一次例外推廣到所有餐飲票據。
口頭文字稿九：讓流程持續執行
專案可以繼續接收指令，也可能按實際產品支援設定每天、每週等執行方式。但定時啟動、檔案許可權、失敗通知和模型呼叫都需要單獨實現，不能只在對話中說一次就假定已經設定成功。
不清楚時提出問題，是人在迴圈中的一部分。原講解還提到進一步製作待審介面：開啟無法識別的票據，人工修正日期或其他欄位，儲存後再納入系統。
把付款郵件匯出到指定目錄，整理後再交付資料，能夠減少一些月底集中處理的壓力。原講解稱其實際系統已執行一年多，明顯減輕了集中整理的壓力。這是個人實施體驗，不能替代獨立測量或保證所有組織得到同樣效果。
電腦與手機怎樣連線
原討論最後提到，應用可以有網頁介面，部署在自己伺服器、雲端或內網，再按許可權從手機訪問。桌面上的專案也可能支援移動入口，但具體行為取決於產品。
能從手機看到聊天，與手機直接獲得本地檔案許可權，不是同一件事。選擇部署位置時，需要同時考慮訪問方式、資料邊界與持續執行，而不只看介面是否方便。
從演示到可驗證系統
這組例子把目標、資料、規則、工具、執行和人工糾正連線起來。它展示了值得研究的做法，也展示了失敗、許可權與覆蓋問題。真正使用時，應把“工具說完成了”與“記錄已經核對正確”分開，保留原件和可恢復過程。
關聯閱讀
先讀工作流對映與組織知識理解規則從哪裡來；協議的正式概念見MCP 與 API。
參考與延伸閱讀
以下為編輯補充，具體復現條件以實際版本與文件為準。
- Blender 官方手冊：英語，查詢場景、物件和軟體操作；MCP 連線還需核對所用元件。
- MCP 官方架構：英語，查詢宿主、客戶端、服務端與能力邊界。
- Make 幫助中心：英語，查詢連線、憑據和工作流執行。
- OWASP：生成式 AI 安全：英語，瞭解工具呼叫、資料處理與應用安全風險。