出海营销服务商经常同时提供建站、内容、社媒、搜索优化和客户跟进。客户需要这些环节协作，但采购了更多工具，并不意味着内容、线索与成交已经连起来。
本文提出一套全链路营销 AIMOS（AI Marketing Operating System）规划：将可组合的业务能力、可追踪的数据与持续评测组织起来，再让 Agent 成为其中一种交互入口。核心价值是减少环节之间的重复劳动，并用实际结果改进下一轮交付。 对话入口服务于这个目标，不能代替它。
这是一份业务与架构方案，尚不能把其中的收入结构、效果提升和跨客户复用视为已经验证的成果。传统服务团队如何逐步实施，见配套转型文章。
一、从客户要完成的任务拆分业务
建站、内容运营和营销传播承担不同职责。建站提供可持续运营的载体；内容运营解释产品、积累可信信息；营销传播让目标人群接触这些信息；承接与 CRM 则把意向转化为可跟进的关系。
职责应分清，服务可以打包。问题不在于“混在一起卖”，而在于合同、交付和评价没有说明每个环节究竟负责什么。
把增长拆成可核对的经营指标
原先常见的“流量 × 转化率 × 客单价 × 复购率”不能直接等同于利润。复购率不是订单次数；即使没有复购，首次订单也可能产生收入。
在统一统计周期与口径后，可以先用以下关系组织分析：
收入 = 支付订单数 × 平均订单金额
利润 = 收入 − 对应口径下的全部成本
进一步讨论获客时，应区分新客首单、老客复购、退款与跨渠道重叠。对 B2B，询盘、商机、签约和实际回款又是不同阶段。AIMOS 的任务是让这些口径能够对应，不能只用一个看似完整的乘法替代经营模型。
五级阶梯描述组合，不规定客户必须走完全程
下图展示服务范围如何扩展。已有站点的客户可以直接从内容或承接进入，只需要单点服务的客户也不应被强推全链路。
| 能力 | 主要交付 | 需要与下游约定的接口 |
|---|---|---|
| 建站 | 页面、组件与运行环境 | 内容结构、表单、事件与发布方式 |
| 内容运营 | 可审阅、可更新的多语言内容 | 内容版本、来源、适用市场与分发标识 |
| 营销传播 | 渠道适配、排期与投放 | 渠道标记、落地页、预算和发布结果 |
| 承接转化 | 表单、咨询、线索接收 | 身份关联、来源、意向与接收状态 |
| CRM 经营 | 跟进、商机、订单及反馈 | 状态定义、回流时延与确认责任 |
接口先服务于真实交接，不要求一开始就建设完整中台。例如，先把内容版本与咨询来源关联起来，就可以检查哪类内容更容易引出有效问题。
二、按购买过程选择指标，而不是套用统一画像
B2B 与 DTC 有常见差异，但不能把前者一律视为理性采购，把后者一律视为情绪消费。高客单 DTC 商品也可能有很长的比较周期，小额 B2B 采购也可能快速完成。
对涉及多角色的企业采购，可以同时观察联系人行为与企业购买组进展：技术人员是否阅读规格，采购是否开始询价，负责人是否参加讨论。购买组人数和周期取决于产品与组织，不能把固定人数写成通用规律。
DTC 场景则可以围绕首单、复购、退款和客户生命周期分析。两者都需要将短期代理指标与最终结果校准，不能把“有人评论”自动视为高于一次有明确购买意图的页面浏览。
用一个工业品客户贯穿链路
假设一家工业泵制造商希望开拓德国市场。以下是说明性场景，不是实测业绩：
- 客户提供经过确认的规格、适用范围、认证材料与案例
- 内容工具检索这些资料，生成德语产品页草稿，并保留来源与版本
- 审核者确认专业表述与认证声明后，发布工具执行已批准的计划
- 渠道带回访问与询盘，CRM 记录企业、联系人、来源及跟进进展
- 团队核对哪些内容引出了合格需求，再提出下一轮改进假设
不能为了优化转化而让模型自行补写认证资格，也不能把自动生成的线索评分直接当成真实采购意向。渠道配置同样要通过客户访谈与试验确认：专业搜索、展会、社媒和行业伙伴可以互补，不能仅凭“工业品”就排除某个平台。
三、数据闭环先解决标识，再解决效果判断
下面六个环节构成反馈链：知识提供生成依据，内容经渠道发布，访问和线索进入承接流程，结果回收后通过评测决定如何改进。返回知识库的边代表经过筛选的反馈，不代表任何成交都会自动使系统变得更好。
先分清“谁的客户”
服务商的委托企业，与这家企业的潜在买家，是两类对象。两篇文章统一使用以下约定：
| 标识 | 表示对象 | 作用 |
|---|---|---|
| Tenant ID | 购买 AIMOS 服务的委托企业 | 隔离数据、权限、合同与配置 |
| Content ID 与版本 | 一份内容及其具体发布版本 | 连接生成、审核与效果观察 |
| 渠道或分发标识 | 一次渠道投放或发布 | 关联来源和活动 |
| Visitor / Contact ID | 匿名访问者或已确认联系人 | 在允许且有依据时关联行为 |
| Account / Customer ID | 委托企业的买家企业或顾客 | 连接商机、订单与客户经营 |
UTM 是链接上的活动参数，不是可靠的个人身份标识。渠道也未必保留所有参数；没有数据时应记录未知，而不是由模型猜出一条完整路径。同邮箱后缀只能作为企业匹配线索，不能直接证明两条记录属于同一对象。
可追踪，不等于带来了增量
追踪回答“观察到了哪些触点”，归因模型按规则为触点分配贡献，增量测量则尝试回答“如果不做这项营销，结果会怎样”。三者应分别验收。
基础链路可以检查来源覆盖率、错误合并率、订单回流时延和重复事件比例。效果评估则需要选择比较方式，并交代假设：
- 随机对照实验要处理分组、污染、样本量与观察周期
- 地域实验需要考虑地区差异、跨区曝光及同期活动
- MMM 使用聚合数据建模，因果解释仍依赖变量选择、模型假设和数据质量
- Last-click 等触点归因可以帮助分析路径，不能单独证明因果增量
Google 的 Meridian 文档也强调，MMM 的因果解释依赖不可直接检验的识别假设；不能把“回归算出一个系数”当作归因已经可靠。Meridian 因果推断说明。
反馈进入生成前，要经过评测
可以先将咨询中的问题、异议和产品关注点整理成带来源的候选标签。通过抽样复核确认质量，再决定是否更新检索材料、内容模板或提示词。
更新后还要检查事实准确率、有效询盘、编辑耗时与业务结果。一次提升可能受季节、价格或渠道变化影响；一次未提升也不等于闭环毫无价值。反馈机制的能力体现在能否识别无效改动、撤销错误版本并继续检验，而不是每轮指标必须上涨。
四、隐私与授权决定数据能怎样连接
不能把“第三方 Cookie 已全面消失”作为架构前提。Google 在 2025 年 4 月明确表示维持 Chrome 当时向用户提供第三方 Cookie 选择的方式，没有按此前方案推出新的独立提示。浏览器、平台和用户设置的差异需要分别处理。Google 官方说明。
工程上的合理前提是：数据会不完整，访问与处理需要依据，架构应能在这些边界内工作。
| 机制 | 能提供什么 | 不能据此推出什么 |
|---|---|---|
| 服务端事件接入 | 统一事件校验、去重与后端回流 | 可以绕过用户选择或平台规则 |
| 第一方数据管理 | 组织已获准处理的客户与订单信息 | 第一方数据可以任意使用 |
| 数据净室 | 按具体技术和查询规则限制数据暴露 | 所有方案都只靠加密且没有泄露风险 |
| 同意与权限记录 | 保存适用的授权、撤回与用途状态 | 有一个弹窗就完成全部合规要求 |
跨客户复用尤其要区分客户资料、商业秘密、可共享案例和服务商积累的方法。去掉公司名不等于不能重新识别客户；聚合结果也可能暴露业务信息。先确认用途和权利，再设计最小化、隔离与输出审查，最后检查复用是否真的改善结果。
法规应按地区、角色、数据和用途分别评估。EU AI Act 采用风险分级且分阶段适用，普通营销分群或价格优化不能仅因使用 AI 就自动归入高风险系统；GDPR 等数据保护义务也不能被 AI Act 取代。部署在哪个国家、调用哪家模型，同样不能单独证明合规。欧盟委员会 AI Act 说明。
对于具体市场，平台可以提供数据驻留、供应商选择、保留期限、访问记录与删除能力，但适用判断需要结合当时规则和具体业务。这应成为交付过程中的持续工作，不能包装成一次配置就能保证的能力。
五、先验证场景，再沉淀共享能力
推荐的演进顺序是场景验证、能力抽取、共享治理、Agent 编排。它是一条适合多业务线的路径，不意味着所有团队都必须设立名为“中台”的组织或独立平台。
| 阶段 | 主要工作 | 进入下一阶段的依据 |
|---|---|---|
| 场景验证 | 在一类客户的具体任务中试用 AI | 质量、交付时间或业务结果得到验证 |
| 能力抽取 | 复用内容生成、检索、标注和评测能力 | 多个场景出现稳定重复需求 |
| 共享治理 | 统一租户隔离、权限、版本、日志与成本管理 | 分散实现的治理成本开始明显增加 |
| Agent 编排 | 用工具组合完成跨模块任务 | 工具契约、异常处理和授权边界可靠 |
例如，工业泵产品页与同类客户的邮件内容都需要产品资料检索，可以共享检索能力；它们的专业知识、市场语气与审核要求仍应留在各自配置中。
抽取能力不是删除场景差异。也不能承诺新场景只写提示词就能上线：工具权限、错误处理、评测与业务验收仍然需要完成。底层升级可能带来收益，也可能产生回归，应通过版本管理与分场景验证控制影响。
六、四层架构让 Agent 调用有依据、有边界
下图是目标结构。评测与权限虽然画在底部，实际贯穿交互、工具与知识访问；外部接入也必须进入同一套鉴权和审计体系。
交互层负责理解任务、澄清必要信息、展示计划和结果。对话不是唯一界面，批量操作、审批和数据比较仍可能需要表格或专用页面。
工具层提供明确的输入、输出、权限、幂等与失败语义。例如，生成草稿与发布内容是两个工具；广告计划建议与实际花费也是两个不同动作。
知识与记忆层区分企业资料、行业知识和效果记录。检索结果应带来源、版本与适用范围，租户隔离在查询与返回结果两端执行。RAG 组织知识，不自动训练模型，也不自动保证内容正确。
评测与治理层记录模型、提示词、工具版本、审批和调用结果。只读任务也可能泄露数据或产生错误建议，不能称为零风险；发布、付款等操作则需要与用户授权相匹配的控制，并说明哪些后果可以撤销、哪些只能补偿。
外部入口按需求开放
早期可以先提供稳定 API 与必要 Webhook，再按真实接入需求增加 MCP 或其他协议适配。预留扩展边界，与第一天就实现所有入口是两回事。
MCP 面向模型应用连接工具与上下文，A2A 面向 Agent 之间的协作，不应将两者混成同一个接口。它们可以互补，但不会自动解决业务身份、授权或责任划分。A2A 官方介绍。
无论通过自有界面、客户脚本还是外部 Agent 调用，都应使用同一套租户范围、操作权限和结果确认机制。
七、商业模式取决于可交付价值
建站费、订阅费、实施服务费和按结果计费可以并存。建站不是天然没有利润，Agent 也不会自动使客户更愿意付费。需要分别计算交付成本、持续支持成本、获客成本、回款与续费。
本文将按约定结果计费称为 RaaS（Results as a Service）。在讨论这类合同前，双方至少应明确：什么结果可以计费，数据由谁确认，基线如何确定，退款和延迟成交如何处理，发生争议时如何复核。
| 方式 | 对应价值 | 主要核对项 |
|---|---|---|
| 项目费 | 建站、迁移或一次性实施 | 范围、验收、变更与维护 |
| 订阅费 | 持续工具能力与运营服务 | 使用范围、交付频率与支持成本 |
| 线索计费 | 达到约定条件的线索 | 有效性、重复线索与归属 |
| 结果分成 | 约定的成交或增量结果 | 数据、比较方法、结算与风险分担 |
不能把几家软件产品的公开起售价与定制服务混在一起，得出统一市场报价；也不能把某个分成比例写成行业标准。试点应根据实际人力、模型调用、渠道与支持成本测算，再检查客户是否认可相应价值。
对于已有站点和 CRM 的客户，深度集成可能比要求迁移更合适；对于缺少基础设施的客户，则可以提供更完整的组合。B2B 不必全部自建，DTC 也不必只做轻量插件，选择取决于客户现状与维护责任。
八、让试点决定平台做多大
传统服务商可以从少量有明确协作需求的客户开始，先跑通数据与交付，再决定是否扩张。这与配套转型文章的 P0、P1、P2 对应：先形成共同目标和最小闭环，再沉淀能力，最后评估全面编排。
每轮试点可以检查三类结果：
- 交付是否改善：重复录入、内容返工、跨团队等待与问题定位是否减少
- 业务是否受益：有效线索与成交有哪些变化，证据能支持多大的结论
- 经营是否成立：服务毛利、回款、续费与支持成本是否可持续
阈值应在试点前根据基线设定。不能用统一的 Agent 周调用次数、升单率或 NRR 变化，裁定所有客户是否成功。低频但高价值的任务可能成立，高频调用也可能只是在反复修正错误。
如果跨模块协作没有带来收益，就收窄到最有价值的能力；如果客户更需要实施服务，就先做好交付；如果多个场景确实复用了同一套能力，再扩大平台投入。这些结果都比“已经上线一个完整 AIMOS”更有判断价值。
AIMOS 的机会，是把零散能力组织成可靠、可追踪且能持续改进的服务。 未来模型和协议继续进步时，基础集成可能更容易，持续的领域知识、交付质量和客户信任则仍需要积累。是否形成竞争优势，应由这些能力的实际表现证明，而不是由“飞轮”这个名字保证。