AI营销代理的真正门槛：模型之外的五层架构

当团队在内部使用聊天机器人时，它回答的是自己人的问题。但当AI代理被嵌入到服务众多营销客户的产品中时，它做的是更危险的事：代表客户公开发声——撰写评论回复、广告变体、潜客消息。这彻底改变了工程要求。

InterCode团队在生产环境中的实践表明，模型本身反而是最简单的一环。真正决定项目成败的，是围绕模型的集成、租户隔离、人工审批等"管道工程"。

为什么公开场景让代理工程变得复杂

内部知识库问答与营销平台代理之间存在本质差异。前者答错最多是一个内部笑话，后者则可能把糟糕的回复留在客户的Google商家页面下，被所有潜在消费者看到。

具体来说，营销平台代理面临三重复杂性：

• 多租户：每个客户都有自己的品牌语调、禁用词、渠道组合和升级规则，代理不能依赖硬编码默认值。
• 输出公开：生成内容会直接出现在客户的公开页面上，错误成本极高。
• 数据源混杂：评论网站、广告平台、CRM、物业管理系统、收件箱，每套系统的认证方式、速率限制和数据结构都不同。

这意味着系统的核心挑战不在于让模型写出好文案，而在于确保它在正确的上下文中、用正确的约束、对正确的人说出正确的话。

七种代理形态，一个共同模式

在营销产品中反复出现的代理可以归纳为七类：

代理类型	功能
回复代理	起草符合品牌调性的回复，敏感内容升级处理
资格判定代理	为潜客打分，回答首次咨询问题
研究代理	为销售团队收集潜在客户背景
创意适配代理	根据投放位置重塑素材
组装代理	根据brief构建草稿活动
洞察代理	用自然语言回答效果数据问题
编排代理	决定哪个代理运行、何时需要人工介入

前六种在代码层面高度相似：一个目标、一组工具、一套"何时停下来问人"的策略。第七种是协调层，也是AI代理编排工作最集中的地方——路由、共享状态和交班逻辑。

编排代理（Orchestrator Agent） 是七类代理中唯一不直接面向客户产出内容的角色，它的职责是决定其他代理何时运行、以何种顺序运行，以及何时把控制权交还给人类。典型实现中，编排层维护一个共享的对话或任务状态（state），接收来自渠道层的事件，然后根据规则或轻量模型判断应该调用哪个下游代理。它与普通代理的关键区别在于：编排代理不持有自己的工具集，而是持有对其他代理的路由表。这也使编排层成为最需要可观测性的部分——一旦路由逻辑出错，问题会同时出现在多个代理的输出上，排查难度远高于单个代理的失败。生产实践中，编排逻辑通常与审批门控函数合并在一处，确保所有交班和人工介入都经过同一条可测试的路径。

五层架构：从集成到隔离

实际生产系统被组织为五层结构：

1. 渠道集成层：评论平台、广告网络、CRM、PMS、邮件、短信
2. 带护栏的代理层：生成加语调检查、禁用内容过滤和置信度评估
3. 人工审批队列：等待人工审核的草稿
4. 升级路由层：敏感案例快速转交正确的人工处理者
5. 客户数据存储：按租户隔离的上下文、示例和历史记录

集成层占据最大工作量

第一层通常是工作量的大头。Webhook还是轮询、速率限制、token刷新、把十种不同的"评论"对象归一化为统一schema——这些才是消耗数周时间的地方。如果正在评估项目范围，应该先估算API和集成工作量。

按租户策略驱动每个决策

代理的每个决策都应读取租户策略，而非硬编码默认值。在TypeScript示意中，TenantPolicy接口定义了brandVoice（语调、禁用短语、获批的历史回复示例）、channels渠道列表、autoPublish自动发布条件（是否启用、最低置信度、最低来源评分）以及escalateOn升级触发条件（如法律威胁、安全问题、退款请求）。

关键实践：每个租户初始都设置autoPublish.enabled = false，等到审批数据显示人工很少编辑草稿后，再按渠道逐步开启。

多租户（Multi-tenancy） 指的是同一套软件实例同时服务多个客户，但每个客户的数据、配置和行为必须相互隔离。在SaaS语境下，这通常有共享数据库加租户ID列、每租户独立schema、或每租户独立部署三种方案，成本和隔离强度依次递增。对于营销代理而言，多租户带来的额外约束是：隔离不能只作用于数据，还必须作用于行为层——同一个模型在不同租户下必须读取不同的品牌语调、禁用词和自动发布阈值。因此TenantPolicy实际上承担了“运行时配置中心”的角色，代理的每次决策都要回查它。如果隔离只做在存储层而忽略了策略层，代理仍可能用A客户的语调回复B客户的评论，这是比数据泄漏更隐蔽、更难审计的失败模式。

审批门控是一个可测试的路由函数

所有草稿都经过同一个路由函数，让"发布、审批还是升级"成为单一、可测试的决策。routeDraft函数先检查是否触发升级条件，再检查自动发布是否启用、置信度是否达标、来源评分是否满足最低要求。这种设计的价值在于：判断逻辑集中在一处，便于测试和审计。

租户隔离必须在数据层强制

丢失客户最快的方式，就是在回复中引用另一个客户的数据。最安全的做法是把租户过滤强制在数据层，而不是交给模型处理。在检索函数中通过filter: { tenantId }在向量搜索阶段就完成隔离，模型永远看不到其他租户的数据。

向量检索中的租户过滤 是这类系统里最容易被忽视的安全边界。当代理使用检索增强生成（RAG）来引用历史回复或品牌示例时，向量数据库通常按语义相似度返回结果，如果不加过滤，很容易把其他租户的相似内容召回给当前代理。正确做法是在执行相似度搜索之前，就把tenantId作为元数据过滤器传入查询，让数据库只在属于该租户的向量子集里计算距离。这样做不仅防止数据泄漏，也提升了检索质量——因为不同租户的语调示例本就不应互相干扰。反面模式是“先检索再过滤”，即在拿到结果后用代码过滤掉非本租户条目，这种方式在延迟和安全性上都更差，且容易在代码改动中失效。

生产环境交付成果

几个真实项目的产出数据：

• 评论管理，1200个门店：响应时间从18小时降至4分钟。6周构建，团队约2.5人，3个月内回本。
• 公寓营销租赁助手：62%的首次租客咨询无需人工处理。14周构建，5人团队，多租户，与物业管理系统集成。
• 多户住宅营销机构获客引擎：手动潜客研究减少73%，外呼能力提升3.2倍，未增加销售人手。

权衡与陷阱

几条来自实战的经验：

• 集成主导估算：先数渠道，再数代理。
• 品牌语调保真有成本：需要为每种语调准备按租户的示例和评估集，而不是一个全局prompt。
• 业务量决定回本周期：评论项目之所以成立，是因为它替代了每月约1100小时的人工分流。低业务量工作流可能永远无法覆盖定制开发的成本。
• 不要自动化不稳定的流程：如果人工流程每个月都在变，先把它稳定下来。
• 数据与IP归属要提前确定：涵盖prompt、评估集、日志和任何微调数据。
• 先选指标，再选模型：响应时间、处理的咨询量、节省的研究工时。没有指标就无法判断它是否有效。

交付节奏

这类项目通常需要6到14周，分为四个阶段：发现与可行性评估、架构与数据访问、带护栏的构建、验证与上线。

核心结论

模型是简单的部分。让这些代理可以安全上线的是围绕它的管道工程：集成、按租户策略、审批门控、升级路由和严格的数据隔离。当营销平台考虑引入AI代理时，应该把预算和排期的重心放在这些"模型之外"的工作上，而不是纠结于选择哪个基础模型。