2026 年的代理式营销：系统必须暴露的四件事
十一页内容定义了代理式营销；其中八页从未提及工具调用。一个基于代理实际所需构建的定义——以及 Zealy 不足之处。
作者 Mathis Grosjean
本页内容
简短回答： 代理式营销是由软件执行的营销工作，该软件自行选择下一步行动并加以执行。共识大致到此为止。我们于 2026 年 8 月 18 日抓取了该术语及其变体返回的十一个页面，其中八个完全没有提及协议、工具调用或函数调用——而这一层正是代理从聊天窗口转变为能够改变你的社区、你的活动或你的客户记录的东西的地方。因此，本文通过系统在代理能够开展任何营销工作之前必须暴露的四件事来定义代理式营销，引用模型上下文协议关于这些系统自我发布的标签为何不可信的说明，并按照该定义对 Zealy 自身的代理接口进行评分，包括我们未通过的部分。
披露： Zealy 发布此页面，且 Zealy 销售本文所讨论的产品。Zealy 是一个社区和任务平台。其两项功能属于本文所定义的代理：一个可由外部 AI 驱动的 MCP 服务器，以及一个产品内 AI 审核器。三者均在下文出现。本文中关于 Zealy 自身代理接口的一切均为第一方信息：从 Zealy 的代码仓库读取，由我们针对 Zealy 自己的服务器运行，未经任何其他方审计。你应当以对待任何供应商描述自身产品时的怀疑态度来阅读。
最后验证： 2026 年 8 月 18 日。
什么是代理式营销？
代理式营销是由软件执行的营销工作，该软件朝着目标自行选择下一个行动，而不是遵循人工绘制的流程。一个系统只有在暴露以下四件事时才符合条件：具名工具而非聊天框、在行动前发现它们的方式、刻意的审批边界，以及返回内容的信任边界。
该定义是我们的，并且刻意基于机制而非愿景构建。我们阅读的每一个已发布定义都描述了软件试图做什么。没有一个描述你的技术栈在能够做到之前必须满足什么条件。以下是四个部分，按系统必须满足它们的顺序排列。
- 具名工具，而非文本框。 代理需要具有名称、参数和返回结构的操作，例如
create_campaign,list_members和send_message，因为只能生成文本的模型只能生成文本。模型上下文协议是当前发布此类列表的通用方式，其工具即所谓模型控制的：语言模型根据上下文和用户提示自行发现并调用它们。没有这一层，你拥有的只是一个写作助手。那是一个有用的产品；但不是本文所讨论的。 - 行动前发现。 代理必须能够在做出任何承诺之前询问存在什么以及每样东西做什么。如果人类已经选好了三个调用的硬编码集成，那只是附带了模型的自动化文案。
- 有人刻意选择的审批边界。 每个操作要么为人工停下，要么不停，并且某处有规则决定哪个是哪个。规则可以严格或宽松。它不能是未经审视的。
- 返回内容的信任边界。 工具结果是由他人写入的数据：成员、客户、表单、抓取的页面。如果返回的字符串能说服代理进行下一次工具调用，你就构建了一个从任何填写你任务提交字段的人那里接受指令的系统。
由此产生两个后果，这也是我们费心撰写定义的原因。 缺少第一部分的东西只是营销更好的聊天机器人。 而 缺少第三部分的东西并没有对自主性做出决定——而是自主性降临到了它身上。 你没有选择的审批边界不是一种设计立场，而是一个尚未让你付出代价的意外。
现有的定义，以及每个定义在哪里划定自主性界线
已发布的定义都同意代理会自行规划和行动，但在允许保留多少人工参与上存在分歧。Vlerick 商学院允许最小干预。Braze 描述的是感知、决策和行动的系统。Young Urban Project 和 Netcore 都将界线定在每一步人工审批。Forrester 将代理与代理式 AI 完全区分开来。
先读中间一列，再读右边一列。谁在定义这个类别，很大程度上说明了他们把界线放在哪里。
| 来源 | 他们销售什么 | 界线，按他们的原话 |
|---|---|---|
| Vlerick 商学院 — Steve Muylle，数字战略与营销教授，2025 年 4 月 18 日 | 高管教育 | “代理式营销是指 AI 代理以最小干预自主代表你执行其中许多任务” |
| Treasure Data — Kazuki Ohta | 客户数据平台 | “代理式营销是使用 AI 代理跨渠道自主规划、执行和优化营销活动” |
| Tofu | AI 营销平台 | “代理式营销是使用自主 AI 代理基于目标而非预定义规则或模板来规划、执行和优化营销活动的实践。” |
| Braze | 客户互动平台 | “Agentic AI 营销系统感知其环境、做出决策并自主采取行动以实现特定目标。” |
| Young Urban Project — Arjun Kumar | 营销培训 | “全程无需人工批准每一个单独步骤” |
| Netcore — Vaishnavi Manjarekar | 营销自动化 | “全程无需在每一步都获得人工批准” |
右栏中的每个字符串都与所链接页面在 2026 年 8 月 18 日抓取时的原始文本进行了比对，而不是从搜索结果中读取。有六个在此词条下排名靠前的页面完全无法读取。Salesforce、IBM、Gartner 和 BCG 对每次尝试都返回 403，McKinsey 和 Adobe 则超时。此处未引用其中任何一个。
其中三个页面还针对一个相邻术语划出了可用的边界，而这是我们找到的唯一三个值得保留的。
与营销自动化对比。 Treasure Data 写道，“Agentic 营销比 AI 营销更窄，且与营销自动化不同”，因为“营销自动化执行的是固定的、由人定义的工作流”。检验标准不是软件是否在你不在时采取行动。你的邮件工具已经做到了这一点。检验标准是步骤顺序是否由人预先选定。
与生成式 AI 对比。 Optimove 将其表述为两种触发方式之间的对比：“生成式 AI 基于人类提示创建内容”，而“Agentic AI 无需等待提示即可采取自主行动。”提示驱动与目标驱动，这是一个真实的区别，也是一个很少被尊重的区别。
与助手对比。 这组材料中最犀利的一句话来自 Docket 的 Arjun Pillai：“助手等待用户，协助完成一项任务，并存在于人类工作流之中。”其智能体的一半则是“智能体朝着目标行动，做出有边界的决策，触发工作流，并在监督下承担部分执行。”同一页面上的另一段文字提供了该表述所缺失的机制：人类“定义目标、升级规则、主题约束和审批阈值。智能体在这些边界内运作。当某事超出这些边界时，它会升级。”升级就是我们定义中的审批边界，从智能体一侧来描述。
有一处分歧值得如实呈现，而不是加以抹平。Forrester 在 一个关于 AI 智能体用例的页面 上（署名 Craig Le Clair）区分了上面每个供应商页面都视为可互换的两个术语：AI 智能体基于“预定义规则”运行，而“Agentic 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 通过告诉你阅读服务器的工具列表来回答智能体能对你做什么的问题，然后告诉客户端不要相信该列表关于自身的说法。说明这一点的注释位于 schema 而非正文中，这也是很少有人读到它的部分原因。
以下是该段落，来自 ToolAnnotations 接口，位于 规范的 schema 中，修订版 2026-07-28：
注意：
ToolAnnotations中的所有属性都是 提示. 它们不保证提供对工具行为的忠实描述（包括诸如title).
而在同一主题上，来自 工具页面:
出于信任、安全和保障考虑，客户端 必须 将工具注解视为不可信，除非它们来自受信任的服务器。
先停下来体会一下这个设计的含义。协议对“我如何知道这个东西能对我做什么”的回答是：读那份清单。而它的下一条指令就是：这份清单是被评估方自己作出的声明。工具 名称 和 模式 是承重的，因为模型会调用它们，服务器必须遵守它们。而附加在它们之上的风险标签，是服务器对自身行为的自我描述。
这样的标签共有四个—— readOnlyHint, destructiveHint, idempotentHint 和 openWorldHint ——其中两个， destructiveHint 和 openWorldHint，默认为 true。因此，一个未标注的工具会被默认为具有破坏性，并默认为会触及外部世界，这是正确的做法，也与大多数人的预期相反。
对于智能体营销的定义而言，真正重要的是 destructiveHint，因为它没有问什么。它把覆盖与新增区分开来。危害是另一个维度，而模式里没有为它留出字段，所以一个纯新增的调用可能是智能体对你的技术栈所做的最具后果的事情，却仍被一个完全善意的服务器标为安全方式。每个标志在实践中意味着什么，以及应用默认值后一份真实的清单是什么样子，见 旁边的逐步讲解.
这也是营销人员一直称之为“智能体洗白”的那件事的诚实版本。Young Urban Project 对此的命名很精确：“最常见的失败是智能体洗白，即拿一个现有的自动化或聊天机器人产品，重新包装成智能体，却没有在底下加上规划或决策层”，并补充说“演示是被脚本编排的，恰好掩盖了真正重要的那个缺口”。工具清单比演示难编排得多。它也是这整个类别中唯一一件买家无需供应商配合就能核查的产物，这就是为什么我们另写了一篇逐步讲解，说明 如何在连接任何 MCP 服务器之前枚举它的工具.
审批边界设在哪里，以及应该由谁来设
模型上下文协议说，人类应始终在环，并有权拒绝工具调用，而它是对客户端应用说的，且是 SHOULD 而非 MUST。协议中没有任何内容约束你所连接的服务器。你的审批边界设在哪里，是某人做出的选择，而且往往不是你。
原句是：
出于信任、安全和保障考虑， 应当 始终有一个人在环，并有权拒绝工具调用。
同一安全章节还要求客户端“在调用服务器之前向用户展示工具输入，以避免恶意或意外的数据外泄”，并“在传递给 LLM 之前验证工具结果”。这两条都是对客户端说的：即运行在你这一侧、承载模型的那个东西，Claude、ChatGPT 或自研框架。所以按协议的直白读法，你的智能体营销的安全性是你客户端的职责，而你所连接的服务器除了提供一份诚实的工具清单之外，并不欠你什么。
这个类别知道这一点，却不太确定该怎么办。供应商指南常常用“没有人”来定义智能体，然后在同一页往下又告诉你把人放回哪里；我们在 AI 智能体真的能运营你的社区吗中拆解了其中一页。两半都是真诚的。定义是写给市场的，指令是写给部署的，而两者之间的缺口，正是每一个关于自主性的真实决策实际发生的地方。
值得主张的版本既不是“完全自主”，也不是“事事审批”。而是：边界是一个逐项决策的设置，两侧都有成本，而执行它的机制本身也是可能出故障的软件——这正是今年早些时候 Discord 审核故障所展示的：人工审核步骤存在于公布的设计中，而一个 bug 把它从路径中拿掉了。我们另写了 这对让智能体运营社区意味着什么 ，因为它值得的不止一个从句。
现在也有了一个经过测量的答案，来回答 哪些 调用值得设闸，而它并不是直觉给出的那个。 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 的智能体接口 | 结论 |
|---|---|---|
| 具名工具而非聊天框 | 一个 MCP 服务器，发布带有 schema 和风险标注的工具列表，涵盖任务、成员、审核、分析、webhook 和活动 | 是 |
| 行动前先发现 | 工具列表可通过协议枚举，服务器还发布一份活动操作手册作为资源，智能体可以在规划前阅读 | 是 |
| 刻意的审批边界 | 除非操作员启用，否则写入是关闭的，而且每一次写入随后都要等人 | 是，而且设置得比定义允许的更严格 |
| 对返回内容的信任边界 | 存在。它由什么构成，以及其中我们不认为已解决的部分，会在审计文章中拆解，而不是在这里 | 是 |
四项都具备，这是容易的部分。第三项相对于这个标签设置反了。Zealy 的服务器把审批关卡放在服务器端，这超出了协议对服务器的要求，也超出了智能体营销严格定义所允许的范围。工具接口本身足够大，值得审计—— 我们统计时有 72 个具名工具 ——但数量不是重点。设置才是。
我们也不能声称整个产品是一致的。Zealy 还提供了一个 AI 审核器，它可以自行关闭任务领取，这条路径中没有人工：同一家公司，在涉及成员是否能获得报酬的决策上，设置了相反的档位。两种选择都站得住脚；我们不能诚实地说的是，对于多少自主权才合适，存在一个全公司统一的答案。
所以把标签去掉吧。Zealy 实际提供的是一个智能体可读的接口，外加一个人工提交步骤，对于大多数团队应该首先想要的东西来说，这是个无聊的名字。如果你想了解连接它的机制， MCP 集成文档 是权威来源，本文刻意不再赘述；如果你想了解下面更旧、更广的接口， API 文档 涵盖了它。如果你从未使用过这个产品， Zealy 是什么 是更短的入门途径。
在购买名为智能体营销的东西之前该问什么
索要工具列表。销售智能体营销的供应商要么能给你看智能体获得的具名操作及其附带的权限，要么不能。其他一切——规划语言、目标导向语言和演示——都与一个接在表单上的聊天机器人兼容，而 Young Urban Project 对此有个名字。
五个问题，按能让你用最少会议时间获得最多信息的顺序排列：
- “智能体获得哪些操作，按名称列出？” 如果答案是一句能力描述而不是列表，你就得到答案了。如果是列表，就看动词。读、写、删除、发送、发布、支付。
- “其中哪些可以在没有我的情况下行动？” 不是“有没有人在回路中”：这个问题所有人都会回答有。要问哪些具体调用跳过了人，以及是谁选择了这种划分。
- “当智能体读取客户写的文本时，这些文本会怎样？” 你在问工具结果是被当作数据还是潜在指令。考虑过这一点的供应商会立刻回答，因为这是让他们的工程师夜不能寐的失败模式。
- "你们的风控标签是什么意思？" 然后对照规范而非销售演示来核对答案，并询问默认值是什么——大多数人的猜测正好相反。
- "它不能做什么？" 边界清单是最廉价的可信度信号，而几乎没有人发布它。它的缺失不能证明什么。它的存在价值很大。
最后要说的是顺序问题，因为这里的购买决策通常时机不对。大多数评估代理式营销的团队还没有写下哪些重复性任务可以安全移交、哪些不可以——而这个决定无论执行者是承包商、版主还是模型，都是同一个。 如何委派社区任务 会与人一起梳理这个问题，分析几乎可以原样迁移。先做这件事。代理仍然会在那里，而你会知道自己真正想让它拥有哪些工具。