AI Agent 香港中小企指南：工作流程、自動化、MCP、風險點樣做？

AI Agent 是 2026 年最多人問的 AI 題目之一。很多香港公司已經用過 ChatGPT、Copilot 或 AI 自動化工具，下一步自然會問：可不可以讓 AI 自己處理客服、銷售 follow-up、文件整理、報表、email、CRM 或內部流程？

答案是可以，但不要一開始就把 agent 當成完全自主的員工。比較實際的理解是：AI Agent 是一個受控的工作流程系統。它有目標、有指令、有可用工具、有可讀資料、有審批門檻、有日誌和監控，也有測試評估。設計得好，它可以節省重複工作；設計得差，它可能亂發訊息、改錯資料、洩露客戶資料或做出不應做的承諾。

本文不是法律、私隱、資訊安全或採購意見。本文原刊 2026 年 7 月 7 日，並於 2026 年 9 月 15 日併入本站原本獨立的「AI Agent 與 n8n 工作流概念」教學：新增 deterministic workflow 對照、成熟度路線、九個部件、工具與狀態設計、agent loop 與退出條件、guardrails 邊界、MCP 與 n8n 授權說明、平台選型表、查詢分流藍圖、evals、成本模型和規格模板，同時重新核對 OpenAI agents 文件、MCP 官方說明及 n8n 的 AI Agent node、Webhook、自託管與授權頁。AI agent 工具、MCP、生態、平台條款和香港法例會改變，正式上線前請核對供應商文件、PCPD 指引、公司資訊安全政策和相關專業意見。

關鍵字研究：香港用戶正在搜尋甚麼？

香港地區 autocomplete 顯示，AI Agent 搜尋需求集中在：

• 定義和入門：AI Agent、AI Agent 中文、AI Agent 教學、AI Agent 是甚麼、AI 代理人是甚麼。
• 本地需求：AI Agent 香港、香港 AI Agent 課程、香港用 AI Agent、香港可用的 AI Agent。
• 技術和工具：AI agent workflow、AI agent workflow design、AI agent tools、AI agent tools LangChain、AI agent tools n8n。
• 趨勢詞：agentic AI 中文、agentic AI 是甚麼、agentic AI 應用、agentic AI vs AI agent。
• MCP：MCP AI agent、MCP AI agent 是甚麼、MCP AI agent architecture、MCP AI agent n8n。

這些搜尋反映兩個意圖：一是理解概念，二是想落地工作流程。本文會把兩者連起來。

AI Agent 與普通 ChatGPT 有何不同？

普通 AI 對話通常是你問一句，它答一句。AI Agent 則會多幾個能力：

• 目標：例如「把今日客戶查詢分類並草擬回覆」。
• 狀態：知道現在處理到哪一步、哪些資料已查、哪些動作未完成。
• 工具：可以查 CRM、讀試算表、建立工單、草擬 email、搜尋知識庫或調用 API。
• 結構化輸出：用指定 JSON、表格或欄位格式輸出，方便系統接收。
• 審批：遇到高風險操作時停下來，等人批准。
• 監控：記錄輸入、工具調用、結果、錯誤和審批人。

所以 agent 的重點不是「更會聊天」，而是「可以在限制內完成一段流程」。

AI Agent 架構

一個可控 agent 至少要有以下六個部分：

模型

模型負責理解任務、推理下一步、產生輸出和決定是否使用工具。不要只看模型是否「聰明」，也要看成本、延遲、私隱、工具調用能力、結構化輸出和供應商政策。

指令

指令是 agent 的工作規則。它應該寫清楚：

• 任務目標和成功標準。
• 可以做和不可以做的事。
• 何時必須請人審批。
• 遇到資料不足或工具錯誤時怎樣處理。
• 輸出格式、語言、語氣和保密要求。

工具

工具可以是 email、calendar、WhatsApp、CRM、Google Sheets、Notion、Slack、ticketing system、資料庫、API、搜尋或內部知識庫。工具愈多，風險愈大；正式上線前要逐個設定權限和測試。

資料

Agent 需要上下文，但不代表可以讀所有資料。香港公司應先分類資料：

人手審批

人手審批不是阻慢流程，而是把風險鎖在可控範圍。以下操作應先要求人批准：

• 對外發出 email、WhatsApp、報價、合約或投訴回覆。
• 修改 CRM、訂單、付款、庫存、會計或 HR 系統。
• 刪除資料或覆蓋 production 記錄。
• 涉及醫療、金融、法律、保險、教育、招聘或安全建議。
• 使用客戶個人資料作新用途。

監控

每次 agent 執行都要留低記錄：輸入、檢索資料、工具調用、輸出、審批、錯誤、重試和最終結果。沒有日誌的 agent 不應進入重要流程。

香港中小企可以先做哪些場景？

Agent 與 deterministic workflow：不要二選一

最可靠的自動化通常是「規則外殼＋Agent 判斷核心」。能以程式清楚表達的規則，交給程式；只有需要理解語意、處理例外或選擇工具的部分，才交給模型。

判斷準則很簡單：若同一輸入必須永遠得到同一結果，或錯誤一次便造成實際損失，優先使用 deterministic code；若輸入語意多變，而且錯誤可被 schema、政策或人工覆核攔截，才考慮 Agent。

成熟度路線：由單步輔助到受控自治

1. 第 0 級—人工工具：模型只產生草稿，人手複製和執行。
2. 第 1 級—單步增強：workflow 固定調用一次模型，輸出結構化分類或摘要。
3. 第 2 級—工具選擇：Agent 可在少量唯讀工具之間選擇，但不能造成外部副作用。
4. 第 3 級—受控動作：可提出寫入操作；schema、政策和人工批准通過才執行。
5. 第 4 級—有限自治：只在明確範圍、預算、時限和評測門檻內自動運行，並有完整 trace 和停止機制。

每一級都要先取得基線數據，再決定是否升級。若第 1 級的分類仍不穩定，增加工具和循環只會把小錯誤放大。

一個可靠 Agent 的九個部件

OpenAI 現行 Agents 文件把 agent 定義為一個包含模型、instructions，並可選配 tools、guardrails、MCP、handoffs 和 structured outputs 的工作單元。這個定義很重要：工具和限制是設計的一部分，不是模型生成答案後才補上的附加項。

工具設計比提示詞更接近真正的權限系統

模型只能「建議」調用工具；真正執行工具的是你的 runtime。工具層要把危險能力切細，例如把 manage_customer 拆成 get_customer、draft_customer_note 和需要批准的 commit_customer_note。不要讓一個通用 HTTP、SQL 或 shell 工具接觸整個環境。

• 精準名稱和描述：何時用、何時不要用。
• 嚴格 schema：enum、長度、格式、必填欄和未知值。
• 最小權限：唯讀與寫入分開；服務帳戶只可接觸必要資料。
• 冪等鍵：重試不會重複發信、扣款或建立記錄。
• 逾時與錯誤碼：讓 workflow 分辨可重試、不可重試和要人工處理。
• 輸出最小化：只把下一步所需欄位送回模型，避免整份客戶記錄進入 context。
• 審計資料：run ID、工具版本、參數摘要、結果和批准人。

狀態不等於記憶：分開四個資料層

Agent loop：用狀態機和可證明的完成條件

不要用一句「直到完成為止」作 loop。建立有限狀態，例如 RECEIVED → VALIDATED → NEEDS_CONTEXT → PROPOSED → AWAITING_APPROVAL → EXECUTED → VERIFIED，並為每個轉移寫明前置條件。

• 成功：有外部證據確認結果，而不是 Agent 自稱完成。
• 需要資料：列出缺少欄位，停止工具調用並詢問使用者。
• 需要批准：保存可恢復狀態，展示具體動作和參數。
• 安全拒絕：輸入違反政策或要求超出授權。
• 工具失敗：達到重試上限後進入人工 queue。
• 逾時／預算：達到最大步數、token、API 成本或 wall time。
• 低信心：分類或抽取未達門檻，不以猜測補齊。

成功也要可驗證。例如「已寄出」應由電郵服務回傳 message ID；「CRM 已更新」應再讀取目標記錄或檢查版本；「沒有重複」應由 idempotency key 和唯一約束保證。

Guardrails 與人工批准要放在正確邊界

OpenAI 文件把控制分成 input、output、tool guardrails，以及 human-in-the-loop approvals。它們不是同一件事：guardrail 是自動檢查；批准是把 run 暫停，等待人或政策批准／拒絕，再由同一狀態恢復。

批准不是橡皮圖章：畫面要顯示將要做甚麼、影響誰、使用哪個帳戶、關鍵參數、預期成本及能否回復。批准要綁定該次 payload；payload 改變便要重新批准。

MCP、function calling、n8n、Copilot Studio 點樣分？

不同工具處理不同層面：

• Function calling / tool calling：讓模型用固定格式要求系統執行某個工具，例如查訂單或建立 ticket。
• MCP：提供較一致的方法，讓 AI 應用連接不同工具、資料和上下文。
• n8n / Zapier：適合 no-code/low-code workflow，把 AI 節點和業務系統串起來。
• Copilot Studio：適合 Microsoft 365/Teams/企業流程和內部 agent。
• LangChain / LangGraph / CrewAI / OpenAI Agents SDK：適合開發團隊做更高控制度、自定工具和測試的 agent。

選型時不要只問「哪個最強」。先問：

1. 是否需要接公司現有系統？
2. 是否有技術團隊維護？
3. 是否需要詳細日誌和 evals？
4. 資料是否可放入該平台？
5. 可否做到最小權限和人手審批？

MCP 再說清楚一點

MCP 官方文件把它定義為「an open-source standard for connecting AI applications to external systems」，並以 USB-C 作比喻：正如 USB-C 提供標準化的裝置連接方式，MCP 提供標準化的方式，讓 AI 應用連接資料來源（例如本機檔案、資料庫）、工具（例如搜尋、計算）和工作流程（例如專門提示）。官方亦指出它是開放協定，Claude、ChatGPT、Visual Studio Code、Cursor 等客戶端都支援，所以可以「build once and integrate everywhere」。

對中小企而言，重點不是「支援 MCP＝更安全」。MCP 減少的是整合工作量，不是權限風險：一個 MCP server 能讀寫甚麼、由哪個帳戶授權、寫入前有沒有人批准、日誌會否記下完整 payload，仍要逐項設計。把 MCP 當成接線標準，把上文的工具設計、狀態分層和批准邊界當成安全設計。

n8n：授權名稱和自託管責任要說準確

n8n 是 workflow orchestration 平台，也提供 AI Agent node。官方文件指出目前所有 AI Agent node 都以 Tools Agent 運作，而且「You must connect at least one tool sub-node to an AI Agent node」。這正好說明 Agent 和普通模型節點的差別：Agent 能在受限工具之間選擇動作，而整條 workflow 仍可用普通節點控制觸發、驗證、分支、批准、重試和輸出。

授權方面要說準確：n8n 採用 Sustainable Use License，官方自述屬 fair-code／source-available，並明確寫「according to the Open Source Initiative (OSI), open source licenses can't include limitations on use, so we do not call ourselves open source」。一般內部商業、個人和非商業使用有較大空間；把 n8n 白標轉售、託管並就存取收費，或讓產品價值主要來自 n8n 功能，則受限制，使用前應閱讀現行條款。

自託管代表控制，也代表責任：官方 hosting 文件說明自託管在沒有 license key 時運行 Community edition。你可以選擇網絡和資料邊界，但亦要負責 TLS、資料庫、加密金鑰、憑證、備份、升級、worker、queue、監察、容量、事故和復原。團隊未準備好做這些工作時，managed cloud 可能有較低總風險。

平台選型：用同一張需求表，不要比較 connector 總數

先按場景給每個維度 1–5 權重，再用同一個 prototype 為候選平台評 1–5 分。總分只作討論起點；任何硬性要求，例如指定資料地域、必須自託管或必須有人手審批，應先作 pass／fail gate，不能由其他高分抵銷。至於 Coze 等平台，官方條款和開發者文件顯示可用來建立 bot／software 並提供 API 與插件，但功能、方案、地區、配額和價格會改變，應以登入後的官方文件和控制台為準。

Agent 風險檢查

上線前至少要做以下五項檢查：

權限最小化

一開始只給 agent 它真正需要的權限。能 read-only 就不要給 write；能只讀某張表就不要讀整個資料庫；能用測試環境就不要直連 production。

人手審批

所有對外訊息、金錢、合約、敏感資料、刪除、production 修改和高風險行業建議，都應該先停下來請人批准。審批畫面要讓人清楚看到 agent 根據甚麼資料作出建議。

日誌追蹤

日誌應記錄工具輸入、工具輸出、agent 判斷、最終行動、審批人和時間。日誌既是 debug 工具，也是出事後追查責任和改善流程的基礎。

測試評估

不要只用一兩個 demo 測試。建立一組測試案例，包括正常、模糊、惡意、缺資料、工具失敗和高風險場景。每次改 prompt、模型、工具或資料來源後都要重跑。

資料脫敏

在普通 AI 工具或外部平台處理資料前，先刪除或遮蔽不必要的姓名、電話、電郵、地址、身份證、付款資料、合約細節和商業機密。能用匿名 ID 就不要用真實客戶資料。

Agent 指令模板

你是 [公司/部門] 的內部 AI agent。
任務：協助處理 [流程名稱]。

可做：
- 讀取 [批准資料來源]
- 產生 [草稿/摘要/分類/建議]
- 使用 [工具清單]

不可做：
- 不可對外發送訊息，除非人手批准
- 不可修改、刪除或覆蓋 production 資料
- 不可編造政策、價錢、合約條款或專業建議
- 不可處理未脫敏的高敏感資料

遇到以下情況必須停下並要求人手審批：
- 資料不足或互相矛盾
- 涉及投訴、退款、法律、醫療、金融、保險、人事或安全
- 需要發送外部訊息
- 需要改系統資料

輸出格式：
- 任務摘要
- 使用資料來源
- 建議行動
- 需要審批的原因
- 風險級別：低 / 中 / 高

30 日 AI Agent 落地計劃

第一個專案藍圖：客戶查詢分流與回覆草稿

這個專案有真實價值，但不會讓 Agent 自動退款或直接發信，適合作為第一個受控 prototype。

在 n8n 實作：由外向內逐層收窄

1. 建立測試 Webhook：先用 test URL；正式發布 workflow 後才改用 production URL。n8n 官方 Webhook 文件列明可選 Basic auth、Header auth、JWT auth 或 None，亦提供 IP allowlist 限制誰可以呼叫觸發 URL；正式 endpoint 不應沿用無認證預設。
2. 固定驗證：用普通節點檢查 request_id、message、locale 和大小；非法輸入立即結束。
3. 建立 structured output：只容許預先定義 category；未知便輸出 other，不要自由創造標籤。
4. 加入 AI Agent node：連接 chat model 和最少量唯讀工具；system message 寫清楚目標、禁止事項和 tool budget。
5. 把寫入拆開：Agent 只產生 proposed_action；普通 workflow 驗證後進入人手批准。
6. 保存狀態：以 request ID 和 idempotency key 關聯輸入、工具調用、批准與最終結果。
7. 錯誤分流：429／timeout 可指數退避；驗證錯誤不可重試；未知故障進人工 queue。
8. 加入觀察資料：記錄節點時間、模型用量、工具次數、分類、批准和錯誤，但遮蔽 secret 和敏感內容。
9. 先以 draft 模式上線：至少收集一段時間的人手改寫和錯誤資料，才考慮自動提交低風險類別。

需要定時執行而不是被動觸發時，n8n 的 Schedule Trigger 可按固定時間、間隔或 cron 執行；同樣要處理重複執行、失敗重試和告警。

可直接複製的 Agent 指令範例

角色：你是客戶查詢分流 Agent，只處理產品使用和訂單狀態。
目標：輸出 category、urgency、language、missing_fields、draft_summary。
可用工具：lookup_order（唯讀）、search_help_center（唯讀）。
規則：
1. 未有 order_id 時不要猜訂單；把 order_id 加入 missing_fields。
2. 不可承諾退款、折扣或送貨日期。
3. 任何付款、健康、安全或法律內容一律標記 human_review。
4. 工具無結果時，保留 unknown；不要把不存在寫成已確認。
5. 最多調用三次工具，之後必須成功、求助或停止。
輸出：嚴格符合指定 JSON schema，不要加入額外文字。

評測：不是問「看起來聰明嗎」

OpenAI 的 agent evals 文件建議先看 trace，再把已知良好行為整理成可重複 dataset 和 eval runs。Trace 應包含模型調用、工具調用、guardrails、handoffs 和最終結果，讓你知道錯在分類、工具、資料、政策還是 orchestration。

測試集至少包括：常見正常案例和不同寫法；缺欄、矛盾、拼錯、混合語言和極長輸入；工具沒有結果、回傳部分資料、429、timeout 和 500；外部內容內含惡意指令或要求洩露資料；要求付款、退款、刪除、改權限或跨客戶存取；重複 webhook、重播舊 request、批准後 payload 被更改。

成本：計算完整單位經濟

用實際 prototype 跑 100 次，再按正常、長輸入、工具失敗和人手批准分組。平均成本會掩蓋最貴的 p95；亦要量度每個成功任務，而不是每次模型調用。若 Agent 經常重試或需要大量人手改寫，看似便宜的單次 API 價格可能沒有意義。

可直接複製的 Agent Workflow 規格模板

# 1. 業務目標
使用者：
成功結果：
不包含範圍：
風險等級：

# 2. 輸入與資料
觸發方式：
必要欄位與 schema：
敏感資料：
可信來源優先次序：
保存期與刪除：

# 3. Deterministic workflow
固定驗證：
固定計算：
固定路由：
錯誤與重試：

# 4. Agent
目標：
Instructions：
Structured output：
可用工具：
最大步數／時間／成本：
不可猜測事項：

# 5. Tools
每個工具的 schema、權限、timeout、錯誤碼、冪等鍵和審計資料。

# 6. State 與 memory
Run state：
Conversation context：
Business memory：
只屬 runtime 的依賴／密鑰：

# 7. Controls
Input／output／tool guardrails：
需要人手批准的工具和參數：
Approval payload 與恢復方式：

# 8. Exit conditions
成功：
需要更多資料：
需要人手：
拒絕：
工具失敗：
逾時／預算超限：

# 9. Observability 與 evals
Trace 欄位：
測試資料集：
指標與門檻：
告警：
版本與 rollback：

# 10. 上線策略
Shadow → Draft → Approved action → Limited automation
每一階段的升級條件和停機條件：

哪些場景暫時不應交給 Agent？

• 自動批准付款、退款、折扣或合約。
• 自動刪除、合併或覆蓋 production 資料。
• 未經覆核就對外提供法律、醫療、金融、保險或安全建議。
• 未經同意使用客戶資料作新用途。
• 自動處理員工紀律、招聘篩選或敏感 HR 決定。
• 連接太多工具但沒有日誌、權限和回滾。

應該追蹤哪些 KPI？

• 每週處理任務數。
• 平均節省時間。
• 需要人手修改的比例。
• 錯誤工具調用次數。
• 高風險任務被正確攔截的比例。
• 客戶或員工滿意度。
• 資料外洩、越權、誤發、重試和失敗次數。
• 每個任務的成本和人工覆核成本。

延伸閱讀

• n8n 2026 自動化用例與選型：甚麼情況值得選 n8n，以及一條仍可控制的 inbox triage 流程。
• n8n Structured Output 與 Switch 語意路由：本文第 4 步「Classify」的完整節點實作。
• n8n、Claude Code、Google AI Studio 工具選型：比較自動化平台、coding agent 和快速 App 建構環境。
• n8n 本機 Docker 安裝：想先在自己電腦試自託管時的起步。
• Claude Code MCP 教學：把本文的 MCP 概念落到一個具體客戶端的 scope、權限和安全設定。
• AI 輔助研究流程：當 Agent 要處理資料搜集和證據時的驗證關卡。
• 香港 ChatGPT 私隱指南：把公司資料交給 agent 前的資料分類與帳戶設定。

總結：Agent 的價值在於可控，不在於全自動

AI Agent 可以成為香港中小企的實用工具，但前提是你把它設計成可控流程，而不是放任的自動員工。最好的第一步不是追最新框架，而是選一個低風險、可驗收、可回滾的流程，給 agent 最少權限，要求它只做草稿或建議，加入人手審批、日誌和測試，再逐步擴大。

當 agent 有清楚目標、工具邊界、資料規則、審批門檻和監控，你就可以把 AI 從「聊天助手」提升成真正的營運能力。