用Agentforce+MCP构建AI邮件代理：从3小时到分钟级

传统邮件营销的生产流程有多繁琐？一次邮件开发涉及创意、邮件开发和营销三个团队，跨越六个手动交接环节，单封邮件的动手构建时间需要3到6小时，从简报到上线往往要等上一到两周。Under Armour全球Salesforce Marketing Cloud首席架构师Devin Gisonno用一个AI邮件代理打破了这套流程——把邮件图片丢进Agentforce，几分钟内就能得到一封完整渲染的邮件。

她在Dreamforce上首次分享了这个项目，随后在布拉格Salesforce Marketing Cloud社区组的线上活动中详细拆解了技术实现。这个项目的独特之处在于：它连接的是Marketing Cloud Engagement（而非MC Next）与Agentforce，通过MCP服务器打通两侧，这在当时并不多见。

传统邮件生产流程的痛点

Devin在演讲中梳理了现有流程的完整链路：团队首先收到创意交接文件、设计稿和活动简报，收集所有元数据后，邮件开发人员用HTML、CSS和AMScript在Content Builder中构建内容。这个过程取决于资产数量，通常需要几天。之后还要经过三到六轮内容更新和QA审核，最终才能获得批准。

整个流程涉及三个团队、六个手动交接点，一封邮件的动手构建时间在3到6小时之间，从简报到活动上线的时间跨度从几天到数周不等。Devin的判断很直接：工程师在重复性任务上花费了太多宝贵时间，而这正是AI代理可以介入的地方。

AI邮件代理如何工作

这个代理的核心逻辑并不复杂：用户将邮件设计图上传到Agentforce，填入基本的活动元数据（邮件名称、主题行、预标题和链接），代理随即开始工作。

代理会读取上传的图片，对照Marketing Cloud Engagement中预建的Content Block库存（可复用内容块和内容片段），将每个内容块映射到图片中的对应区域。Devin特别强调，这套系统依赖的是Salesforce Marketing Cloud的Content Block Catalog——这是通过MCP服务器提供给代理的上下文信息。

映射完成后，代理生成内容块结构供人工确认。Devin在演示中审核了格式，批准后提示代理创建草稿并通过Agent Test发送测试邮件。系统利用Marketing Cloud Engagement中配置的测试Data Extension发送测试邮件到指定收件人，生成浏览器预览链接并返回给代理。最终在Agentforce应用内可以直接预览完整渲染的邮件——所有步骤都通过API完成。

据Devin介绍，整个构建使用了Factory AI作为AI应用编排平台，它连接了所有主流AI模型，包括Claude和ChatGPT。

MCP服务器如何连接两侧平台

这个项目在架构上最值得关注的一点，是MCP服务器在Marketing Cloud Engagement和Agentforce之间起到的桥梁作用。

Devin在演讲中解释，她在Marketing Cloud Engagement侧连接了MCE MCP服务器，在Salesforce侧连接了Salesforce MCP服务器。所有内容块、共享内容块、测试Data Extension、跟踪和渲染数据都存放在Marketing Cloud Engagement中，而代理的编排和运行发生在Agentforce侧。

具体连接过程包括：在Marketing Cloud Engagement中创建安装包（她使用的是服务到服务器模式），获取Client ID和Client Secret后通过Factory AI完成认证连接。Salesforce侧则连接到了SIT沙箱环境，同时接入了Salesforce提供的GitHub仓库中的Salesforce Skills，使她能够在Salesforce中无头构建代理。

Devin提到，整个项目在沙箱环境中完成——她在Marketing Cloud Engagement中创建了UAT业务单元，代理构建在Salesforce的SIT环境中，确保在完全就绪前不会触及客户数据。

MCP（Model Context Protocol） 是由Anthropic提出并开源的协议标准，旨在统一AI模型与外部工具、数据源之间的交互方式。在传统架构中，每接入一个新的数据源或工具，开发者都需要编写定制化的集成代码；MCP通过标准化接口，让AI代理可以像插入USB设备一样即插即用地访问外部资源。在本项目中，MCP服务器扮演的是"能力提供方"角色：Marketing Cloud Engagement侧的MCP服务器负责暴露内容块、Data Extension、渲染数据等营销资产，Salesforce侧的MCP服务器则提供代理编排、Agent Test等能力。Agentforce作为"客户端"通过MCP协议同时调用两侧服务器，从而在不编写大量胶水代码的情况下打通两个异构平台。这也是为什么Devin强调该项目"通过MCP服务器打通两侧"在当时并不常见——彼时MCP生态尚处于早期，可用的官方和社区服务器数量有限。

两次构建：经验教训

Devin坦言她构建了这个代理两次。第一次的失败原因很具体：她试图基于已有架构来构建，但没有利用可复用内容块，导致代理的反馈不一致。

转折点出现在Salesforce发布Employee Agent的图片上传功能之后。Devin说，这个功能在Dreamforce前几周才可用，正是图片上传加上Employee Agent这两项能力的结合，让她的第二个代理真正实现了端到端运行。

在第一次构建期间，她曾尝试通过MCP服务器集成Figma和活动简报平台来收集设计信息和活动信息，但这些MCP服务器存在限制，无法完全达到她想要的效果。她花了大约三个半月时间摸索第一个代理，第二个代理因为已经积累了上下文，构建速度快了很多。

这个经历揭示了一个现实：AI工具生态仍在快速演进，今天的限制可能明天就被新功能解决，但前期探索积累的经验不会白费。

Employee Agent 是Salesforce Agentforce平台中面向企业内部员工的代理类型，区别于面向终端客户的Service Agent。它通常用于赋能内部团队完成重复性工作，如报表生成、工单处理、内容创建等。Devin所使用的图片上传功能允许用户直接将设计稿作为输入喂给代理，代理通过多模态能力解析图片中的布局和元素。这一功能之所以成为转折点，是因为在它发布之前，将视觉设计转化为结构化内容块需要依赖Figma等外部工具的API集成，而这些集成受限于MCP服务器的能力边界，无法稳定地提取设计意图。图片上传功能让代理直接"看到"设计稿，绕过了中间环节，实现了从视觉到代码的端到端映射。这也解释了为何Devin的第一个代理在摸索三个半月后仍未达到预期——不是代理逻辑有问题，而是输入端缺少关键的视觉通道。

从沙箱到生产：下一步计划

这个代理目前的首要优化方向是全球化扩展。当前版本只针对一个用例和一种语言构建，而Under Armour的业务覆盖北美、拉美、欧洲中东非洲和亚太地区，团队需要将代理扩展到所有地区和语言。

Devin还提到了更广泛的集成可能性：引入Data Cloud的细分和Flow，实现动态个性化；利用Analytics MCP服务器在活动部署后监控旅程表现；将旅程从Marketing Cloud Engagement迁移到MC Next的Flow中。她已经开始尝试用MCP服务器将一个完整旅程从Marketing Cloud Engagement迁移到MC Next——虽然迁移到Flow后需要重新配置一些东西（因为Flow连接的是Data Cloud对象而非Data Extension），但旅程映射的核心结构可以成功迁移。

Data Extension与Data Cloud对象 是Salesforce营销生态中两种不同层级的数据存储抽象。Data Extension是Marketing Cloud Engagement原生的数据表结构，用于存储发送列表、个性化字段和测试收件人等，其模型相对扁平，适合邮件发送场景。而Data Cloud（原Customer 360 Audiences）中的对象基于更丰富的客户数据模型，支持实时细分、身份解析和跨渠道激活。当旅程从Marketing Cloud Engagement迁移到MC Next的Flow中时，Flow连接的是Data Cloud对象而非Data Extension，因此原本基于Data Extension配置的个性化逻辑、发送流程和测试机制都需要重新映射。Devin提到的"旅程映射的核心结构可以成功迁移"指的是旅程的节点逻辑和分支条件可以保留，但底层数据绑定需要重建。这也是企业在从MCE向MC Next过渡时普遍面临的架构适配问题。

组织推广与知识传递

从个人项目到团队协作，Devin的做法值得借鉴。她计划让Factory AI生成一个完整的Markdown文件，记录代理的全部实现细节，然后交给开发团队导入他们自己的AI平台进行分析，在此基础上为全球各地区构建本地化版本。

Devin在活动中也回应了关于权限管控的讨论。她强调需要与两个平台的管理员合作，按照最小权限原则定义角色，并在沙箱环境中进行开发和测试。她提到Salesforce和Marketing Cloud的DevOps生命周期管理方式不同，需要走完整的端到端流程后才能部署到生产环境。

Dev这位拥有13年Marketing Cloud经验的架构师对这个项目给出了很高的评价。她说这是她做过的最酷的项目之一，对两个平台配合的效果感到惊喜。对于想要入门的团队，她的建议是：从沙箱开始，找一两个用例先玩起来，逐步建立对MCP服务器能力的认知。