2026 年的代理式行銷：系統必須公開的四件事

簡答： 代理式行銷是由軟體自行決定下一步並付諸實行的行銷工作。共識大致到此為止。我們在 2026 年 8 月 18 日抓取了該詞及其變體搜尋結果中的十一頁，其中八頁完全沒有提及協定、工具呼叫或函式呼叫——而這正是代理從聊天視窗變成能改變你的社群、活動或客戶紀錄的關鍵層。因此本文以系統在代理能執行任何行銷工作之前必須公開的四件事來定義代理式行銷，引用 Model Context Protocol 說明為何這些系統自行發布的標籤不可信，並以該定義評估 Zealy 自身的代理介面，包括我們未達標的部分。

揭露： 本頁由 Zealy 發布，而 Zealy 銷售本文所談的產品。Zealy 是一個社群與任務平臺。其中兩項功能符合本文定義的代理：可由外部 AI 驅動的 MCP 伺服器，以及產品內的 AI 審核員。三者皆於下文出現。本文關於 Zealy 自身代理介面的一切均為第一方資料：由我們從 Zealy 的儲存庫讀取、對 Zealy 自家伺服器執行，未經他人稽核。你應以看待任何廠商描述自家產品的懷疑態度來閱讀。

最後驗證： 2026 年 8 月 18 日。

什麼是代理式行銷？

代理式行銷是由軟體執行的行銷工作，該軟體會朝目標自行選擇下一個動作，而非遵循人為繪製的工作流程。系統唯有公開四件事才符合資格：具名工具而非聊天框、在行動前探索這些工具的方式、刻意的核準邊界，以及對回傳內容的信任邊界。

這個定義是我們提出的，且刻意從機制而非野心出發。我們讀過的每個已發布定義都在描述軟體試圖做什麼，卻沒有一個描述你的技術堆疊必須具備什麼條件才能做到。以下是四個部分，依系統必須滿足的順序排列。

1. 具名工具，而非文字框。 代理需要有名稱、參數與回傳結構的操作，例如 create_campaign, list_members 和 send_message，因為只能產出文字的模型就只能產出文字。Model Context Protocol 是目前發布此類清單的常見方式，其工具屬於它所稱的模型控制：語言模型根據上下文與使用者提示自行探索並呼叫。沒有這一層，你得到的只是寫作助理。那是有用的產品；但不是這個。
2. 行動前先探索。 代理必須能在承諾任何事之前，詢問有哪些東西存在以及各自的功能。由人預先選好三個呼叫的硬編碼整合，只是附上模型的文案自動化。
3. 有人刻意選擇的核準邊界。 每個動作要麼停下來等人，要麼不停，而某處有規則決定是哪一種。規則可嚴可鬆，但不能未經檢視。
4. 對回傳內容的信任邊界。 工具結果是他人撰寫的資料：成員、客戶、表單、擷取的頁面。若回傳的字串能說服代理進行下一次工具呼叫，你就打造了一個聽命於任何填寫你任務提交欄位者的系統。

由此得出兩個後果，這也是我們特地寫出定義的原因。 缺少第一部分的一切，只是行銷話術更好的聊天機器人。 而 缺少第三部分的一切，並未對自主性做出決定——而是被決定發生了。 不是你選擇的核準邊界不是設計立場，而是一場尚未讓你付出代價的意外。

現有的定義，以及各自把自主性界線畫在哪裡

已發布的定義都同意代理會自行規劃與行動，但對允許保留多少人為介入則有分歧。Vlerick Business School 允許最低限度介入。Braze 描述能感知、決策與行動的系統。Young Urban Project 與 Netcore 都把界線畫在每一步都需人工核准。Forrester 則將代理與代理式 AI 完全區分。

先讀中間欄，再讀右欄。誰在定義這個類別，很能說明他們把界線畫在哪裡。

右欄的每一段字串，都是與 2026 年 8 月 18 日擷取的連結頁面原始文字比對後所得，而非從搜尋結果中讀取。有六個在此詞彙上排名靠前的頁面完全無法讀取。Salesforce、IBM、Gartner 和 BCG 對每次嘗試都回傳 403，McKinsey 和 Adobe 則逾時。此處未引用其中任何一個。

其中三個頁面也針對鄰近詞彙劃出了可用的界線，而這是我們認為值得保留的全部三個。

相對於行銷自動化。 Treasure Data 寫道，「代理式行銷的範圍比 AI 行銷更窄，且與行銷自動化截然不同」，因為「行銷自動化執行的是固定、由人定義的工作流程」。判準不在於軟體是否在你未介入時採取行動。你的電子郵件工具早已如此。判準在於步驟的順序是否由人預先選定。

相對於生成式 AI。 Optimove 將其表述為兩種觸發條件的對比：「生成式 AI 依人類提示產生內容」，而「代理式 AI 不等提示便採取自主行動」。提示導向對比目標導向，這是真實的區別，也是鮮少被遵守的區別。

相對於助理。 這組資料中最精闢的一句話出自 Docket 的 Arjun Pillai：「助理等待使用者、協助完成任務，並存在於人類工作流程之中。」其代理的那一半則是「代理朝目標行動、做出有界線的決策、觸發工作流程，並在監督下承擔部分執行工作。」同一頁面的另一段文字補上了該說法所缺的機制：人類「定義目標、升級規則、主題限制與核准門檻。代理在這些界線內運作。當某件事超出界線時，它會升級處理。」升級處理正是我們定義中的核準界線，只是從代理的角度來描述。

有一處分歧值得如實刊出，而非加以粉飾。Forrester 在 一個關於 AI 代理使用案例的頁面 上，署名 Craig Le Clair，將上述每個供應商頁面都視為可互換的兩個詞彙區分開來：AI 代理依「預先定義的規則」運作，而「代理式 AI 則帶來更廣泛的自主性與適應性」。關於該引用的誠實提醒——那是播客的到達頁，而非已發表的研究報告，我們是將其作為某家分析機構的框架來引用，而非作為研究發現。

十一項定義中有八項遺漏的那一層

在我們於 2026 年 8 月 18 日為此詞彙擷取的十一個頁面中，有八個從未提及 Model Context Protocol、工具呼叫或函式呼叫。那一層正是能替你寫出活動簡報的模型，與能建立任務、封禁成員，或將你的事件串流導向新位置的模型之間的差別。

其餘八個完全未提及上述任何字串：braze.com、cdp.com、docket.io、forrester.com、netcore.ai、tofuhq.com、vlerick.com 與 youngurbanproject.com。剩下三個之中，hubspot.com 提到了 Model Context Protocol，但並非定義性頁面。 Optimove 是讓我們印象最深的一個：字串 MCP 只出現在其頁面的導覽選單中，寫成「The Optimove MCP」，從未出現在解釋該類別的文章正文裡。一家廠商推出了 MCP 伺服器，但其自家對代理式行銷的說明卻從未觸及它所推出的東西。這只是關於某一天十一個頁面的陳述，並非關於整個類別——但我們檢查的每個頁面都符合。

這組頁面中有兩頁確實點出了缺失的那一層，而且都講得很好。

HubSpot 的 Duncan Lennox 寫道：「但代理不會點擊儀錶板或瀏覽介面；它們會呼叫 API、讀取結構化輸出並採取行動。」同一頁面將範疇界定為「代理能讀取、寫入與操作的內容」，這才是正確的單位。不是「它能不能做行銷」，而是哪些名詞與哪些動詞。

Real Story Group 是一家販售廠商評測的 martech 研究公司，提供了終結這場爭論的那句話。在 2025 年 6 月 11 日的一篇 關於 MCP 的文章 中，首席分析師 Scott Simmons 稱之為「為 AI 代理打造的通用 API 抽象層」，並得出結論：代理「的能力僅限於廠商選擇揭露的範圍」。

最後那句就是全部重點。代理式行銷不是你選了哪個模型的屬性，而是你的廠商所發布介面的屬性。如果工具是唯讀的，你的代理就只能報告。如果根本沒有工具，你的代理就只能寫文案。能力問題與採購問題是同一個問題，這正是為何跳過這一層的定義讀起來如此愉快，卻如此難以付諸行動。如果你想更全面瞭解代理將在其中運作的各種管道，我們的 web3 行銷支柱 涵蓋它們以及它們的成本。

為什麼工具清單是證據，而工具標籤只是提示

Model Context Protocol 透過要求你讀取伺服器的工具清單，來回答代理能對你做什麼這個問題，接著又告訴用戶端不要相信該清單對自身的描述。這則說明放在結構定義中而非正文裡，這也是為什麼很少人讀過它的部分原因。

以下是這段文字，出自 ToolAnnotations 介面，位於 規格結構定義 的 2026-07-28 修訂版：

注意： ToolAnnotations 中的所有屬性皆為 提示. 它們不保證能忠實描述工具行為（包括諸如 title).

而在同一主題上，來自 工具頁面:

出於信任、安全與保障考慮，客戶端 必須 將工具註解視為不可信，除非它們來自受信任的服務器。

先停下來體會一下這意味著什麼。協議對“我如何知道這東西能對我做什麼”的回答是：讀那份清單。而它緊接著的指令是：這份清單是被評估方自己作出的聲明。工具的 名稱 和 模式 是承重的，因為模型會調用它們，服務器必須遵守它們。而附加其上的風險標籤，是服務器對自身行為的自我描述。

這樣的標籤共有四個—— readOnlyHint, destructiveHint, idempotentHint 和 openWorldHint ——其中兩個， destructiveHint 和 openWorldHint，默認值為 true。因此，一個未加標籤的工具會被默認為具有破壞性，並被默認為會觸及外部世界，這是正確的判斷，也與大多數人的預期相反。

對於智能體營銷的定義而言，真正重要的是 destructiveHint，因為它沒有問什麼。它把覆蓋與新增區分開來。危害是另一個維度，而模式裡沒有為它留出字段，因此一個純新增的調用可能是智能體對你的技術棧所做的最具後果的一件事，卻仍被一個完全善意的服務器標為安全方式。每個標誌在實踐中意味著什麼，以及應用默認值後一份真實的清單長什麼樣，見 旁邊的逐步講解.

這也是營銷人員一直稱之為“智能體洗白”的那件事的誠實版本。Young Urban Project 說得準確：“最常見的失敗是智能體洗白，即拿一個現有的自動化或聊天機器人產品，重新包裝成智能體，卻沒有在底下加上規劃或決策層”，並補充說“演示是被編排好的，恰好掩蓋了真正重要的那道缺口”。工具清單比演示難編排得多。它也是這整個類別中唯一一件買家無需供應商配合就能核查的產物，這就是為什麼我們另寫了一篇逐步講解，說明 如何在連接任何 MCP 服務器之前枚舉其工具.

審批邊界設在哪裡，以及應該由誰來設

Model Context Protocol 說，應當始終有人在環路中，並有權拒絕工具調用，而它是對客戶端應用說的，且是 SHOULD 而非 MUST。協議中沒有任何內容約束你所連接的服務器。你的審批邊界設在哪裡，是某個人做出的選擇，而且往往不是你。

原句是：

出於信任、安全與保障考慮， 應當 始終有人在環路中，並有權拒絕工具調用。

同一安全章節還要求客戶端“在調用服務器之前向用戶展示工具輸入，以避免惡意或意外的數據外洩”，並“在傳給 LLM 之前驗證工具結果”。這兩條都是對客戶端說的：即運行在你這一側、承載模型的那個東西，Claude、ChatGPT 或內部自建的運行框架。因此，按協議的直白解讀，你的智能體營銷的安全性是你客戶端的職責，而你所連接的服務器除了提供一份誠實的工具清單之外，對你沒有任何義務。

這個行業知道這一點，卻不太確定該怎麼辦。供應商指南常常以“沒有人”來定義智能體，然後在同一頁往下又告訴你把人放回哪裡；我們在 AI 智能體真的能運營你的社區嗎中拆解了其中一頁。兩半都是真誠的。定義是寫給市場的，指令是寫給部署的，而兩者之間的缺口，正是每一個關於自主性的真實決策實際發生的地方。

值得主張的版本既不是“完全自主”，也不是“事事審批”。而是：邊界是一個按決策設定的開關，兩側都有成本，而執行它的機制本身也是可能出故障的軟件——這正是今年早些時候 Discord 審核故障所展示的：人工審核步驟在公佈的設計中存在，而一個缺陷把它從路徑中拿掉了。我們另寫了 這對讓智能體運營社區意味著什麼 ，因為它值得的不止一個從句。

現在也有了一個經過測量的答案，來回答 哪些 調用值得設閘，而它並不是直覺給出的那個。 SABER：小動作，大錯誤——在 LLM 智能體中保護變更性步驟，作者為 Alejandro Cuadron、Pengfei Yu、Yang Liu 和 Arpit Gupta，於 2025 年 11 月 26 日提交，研究了使用工具的智能體軌跡出錯時究竟在哪裡讓你付出代價。它報告稱：“相比之下，非變更性動作的偏差幾乎沒有影響。”緊接其前的一句給出了另一面：在其兩個領域之一，每一次額外的 變更性 動作偏差會使成功率最多降低 92%，在另一個領域最多降低 96%，這是針對最先進的模型而言。失敗集中在改變狀態的調用上。

這個設計結論既不華麗也不昂貴：把寫入操作擋住，讀取操作則不設限，並且別再把「人在迴路中」當成只有單一設定值的旋鈕。Zealy 的伺服器恰好就是這樣運作，而我們應該說清楚，我們並不是從這篇論文推導出這個設計——論文是在設計完成之後才出現，而且與設計相符；這比以證據為導向的工程來得弱，但比什麼都沒有來得強。引用這篇論文時要附帶一項提醒：SABER 記錄了它所依據的基準測試中的標註錯誤，並發布了修正版本，這正是我們不該把較舊的工具代理基準測試分數當成仍能描述當前模型的原因。在這裡對單一數字保持謹慎的另一個原因，是代理失敗在很大程度上是變異數問題—— 多輪研究將效能退化拆解為能力的小幅損失與可靠度的大幅上升，這與模型單純不夠好是截然不同的管理問題。

同樣的「留給實作者決定」模式也出現在下一層，也就是我們定義的第四個部分。我們在 2026 年 8 月 18 日下載了七份規格與安全性頁面並加以搜尋：規格的威脅模型是授權與傳輸威脅模型，涵蓋混淆代理、權杖直通、伺服器端請求偽造以及遭入侵的本機伺服器等多項，而模型層的攻擊則留給實作者處理。在我們下載的頁面中，「提示注入」這個詞並未出現；安全性最佳實務文件中「注入」的四次相符分別是跨網站指令碼、shell 命令注入與遠端程式碼執行。這並不是在抱怨一份傳輸規格，因為它本來就有權界定自己的範圍。這是在說明：你一旦連接了某個東西，就立刻繼承了問題的哪一半，以及為什麼對回傳資料建立信任邊界必須是某人明確的職責，而不是協議理所當然具備的屬性。

Zealy 不符合它自己的定義，而這正是

依照本文中最嚴格的定義——Young Urban Project 的「無需人工核准每一個步驟」與 Netcore 的「無需在每一步都要求人工核准」——Zealy 並未在做代理式行銷。透過 Zealy 代理介面的每一次寫入都會停下來等人，而且在操作員開啟之前，寫入功能是關閉的。

我們寧可現在這麼說，也不要之後輸掉爭論。以下是對照我們自己四個部分的完整評分表，屬於第一方資料且未經稽核。

四項全部具備，而這是最容易的部分。第三項的設定方向與這個標籤正好相反。Zealy 的伺服器把核准關卡放在伺服器端，這超出了協議對伺服器的要求，也超出了代理式行銷嚴格定義所允許的範圍。工具介面本身大到值得稽核—— 我們清點時共有 72 個具名工具 ——但數量並非重點。設定才是。

我們也不能聲稱整個產品都一致。Zealy 也推出了一個 AI 審核員，能自行結案任務認領，那條路徑上沒有人參與：同一家公司，在涉及成員是否獲得報酬的決策上，卻是相反的設定。兩種選擇都站得住腳；我們無法誠實說的是，對於多少自主程度才恰當，公司內部有單一的統一答案。

所以把標籤拿掉吧。Zealy 實際提供的是可供代理辨識的介面，並附有人工提交步驟，這對多數團隊應該優先想要的東西來說是個無趣的名字。如果你想了解連接它的機制， MCP 整合文件 是權威來源，本文刻意不再重述；如果你想了解底下較舊、較廣泛的介面， API 文件 涵蓋了它。而如果你從未使用過這個產品， Zealy 是什麼 是更短的入門途徑。

在購買名為代理式行銷的東西之前該問什麼

要求提供工具清單。販售代理式行銷的廠商，要嘛能向你展示代理取得的具名操作及附帶的權限，要嘛不能。其他一切——規劃的措辭、追求目標的措辭，以及示範——都與接上表單的聊天機器人相容，而 Young Urban Project 對這種東西有個名稱。

五個問題，依能用最少會議時間取得最多資訊的順序排列：

1. 「代理取得哪些操作，名稱是什麼？」 如果答案是能力描述句而非清單，你就得到答案了。如果是清單，就讀其中的動詞。讀取、寫入、刪除、傳送、發布、付款。
2. 「其中哪些可以在沒有我的情況下行動？」 不要問「有沒有把人工納入迴路」：這個問題每個人都會回答有。要問哪些具體呼叫會跳過人工，以及是誰決定了這樣的分工。
3. 「當代理讀取客戶寫的文字時，那些文字會怎樣？」 你問的是工具結果會被視為資料，還是潛在的指令。思考過這個問題的供應商會立刻回答，因為這正是讓他們的工程師夜不能寐的失效模式。
4. 「你們的風險標籤代表什麼意思？」 然後拿規格書而非銷售簡報來核對答案，並詢問預設值是什麼——大多數人都會猜反。
5. 「它不能做什麼？」 邊界清單是最廉價的可信度訊號，卻幾乎沒有人發布。它的缺席不能證明任何事，但它的存在價值極高。

最後要談的是順序，因為這裡的採購決策通常時機不對。大多數評估代理式行銷的團隊，還沒寫下哪些例行任務可以安全交出去、哪些不行——而無論接手的是承包商、版主還是模型，這個決定都一樣。 如何委派社群任務 會與人一起梳理這件事，而這套分析幾乎可以原封不動地套用。先做這件事。代理還是會在那裡，而你會知道自己真正想讓它擁有哪工具。