OpenClaw+腾讯云：构建广告营销Agent基础设施实战指南

这段时间我在帮一家广告营销公司搭企业级的Agent基础设施，最后跑的方案就是腾讯云加OpenClaw。很多人一听到OpenClaw，第一反应是“这不就是个开源的个人AI助理吗”，确实，它前身那套东西在开发者圈子里更多是被拿来接微信、Telegram，做私人助手用。但真正把它放到广告营销的业务场景里，配合腾讯云的资源体系去做私有化部署和成本管控，你会发现它完全有资格承担起“Agent基础设施”这个角色。

广告营销这个行业有个特别现实的问题：线索来得快、内容需求量大、渠道极其分散，人工响应根本跟不上。一套能自动接消息、自动查数据、自动产出内容、还能把结果回写到业务系统里的Agent底座，比什么花哨的营销中台都实在。这篇文章我就把这次从选型、部署到成本优化的完整过程拆开讲，重点不是OpenClaw的配置手册，而是它在企业级场景里到底怎么落地、怎么省钱、有哪些坑。

1. 为什么是OpenClaw：广告营销Agent基础设施的选型逻辑

1.1 广告营销行业的信息流困局

先说说我们面对的现状。这家公司有四个项目部，分别负责房产、教育、本地生活、电商四个赛道的投放和内容代运营。每天早上，各个项目组的微信工作群、企业微信客户群、公众号后台、邮件、表单系统里会涌入大量线索和咨询，客服团队要人工复制粘贴线索到Excel，再分给销售去跟进。投放素材方面，一个月要产出几百条短视频脚本、推文、海报文案，创意团队长期处于“爆肝”状态。

这还只是日常运营。更麻烦的是舆情和竞品监控——哪个竞品又上了新广告、哪个平台的用户风向变了、哪个关键词的热度上来了，单纯靠人盯根本盯不过来。整个业务的信息链路是断裂的，客服、创意、投放、销售各管一段，之间靠微信群转发来衔接。

这种局面下，广告营销公司其实比任何行业都更需要Agent。原因很直接：Agent能同时处理多个渠道的实时消息，能按规则自动执行任务，能调用外部工具查数据、发内容、做图片，还能在无人值守的夜间继续工作。这些恰好击中了广告营销行业“多线程、高时效、强内容”的痛点。

1.2 从“个人助理”到“企业底座”：OpenClaw的能力拆解

市面上的Agent项目不少，从各种以“pi Agent”“hermes Agent”命名的开源框架，到商业化的Agent平台，我基本都扫过一遍。最后选OpenClaw，核心原因是它对“渠道接入”和“自主执行”这两件事的处理方式最契合广告营销场景。

OpenClaw的核心能力可以拆成四层来看。第一层是渠道接入层，它内置了丰富的Channel适配器，能够连接主流IM、邮件、社交平台，上图里的“微信、Telegram、Discord、X”等只是基础，实际上它还能通过Webhook和自定义渠道接入企业自研系统，这就让广告营销公司可以把企业微信客户群、公众号消息、表单提交、邮件咨询全部统一收口到一个Agent入口。第二层是Agent核心层，负责理解意图、规划步骤、调度技能。第三层是技能层，也就是Skills和Tools，Agent可以调用浏览器自动化工具去抓取网页数据，可以调用绘画接口生成创意素材，可以执行搜索查询热点话题。第四层是记忆与触发层，OpenClaw支持对历史对话的短期和长期记忆，同时提供Triggers机制，支持定时触发、关键词触发、事件触发，这对舆情监控、定时日报这类场景太关键了。

这里要补一个很多人问的概念区分：Skill和Agent到底什么关系。简单说，Agent是那个“做决策的人”，Skill是Agent手里可以随时拿起来用的工具包。比如“竞品监控”是一个Skill，里面可以包含搜索、浏览网页、抓取信息、总结对比等多个子操作；而Agent负责判断什么时候调用这个Skill、调用完结果怎么处理。这种松耦合设计让广告营销团队可以像搭积木一样，把不同技能分配给不同场景的Agent使用。

1.3 为什么放在腾讯云而不是本地跑

选云平台的时候，我们也纠结过是本地服务器还是云上部署。后来统一判断：OpenClaw要承担企业级消息收发的入口，必须有一个稳定、有固定公网IP、能扛住DDoS攻击的环境。本地网络一断，所有渠道的消息就全断了，这是广告营销公司不能接受的。

腾讯云在这方面的优势很直接。一是基础设施成熟，CVM、轻量应用服务器Lighthouse、对象存储COS、负载均衡CLB、云监控这些组件都现成，不用自己造轮子；二是生态完善，部署要用的镜像市场、运维要用的监控告警、存储要用的COS生命周期管理，都是开箱即用。最关键的是，企业微信、微信公众号这类官方渠道接入时，要求回调地址必须是公网可访问的HTTPS地址，腾讯云的安全组和SSL证书服务可以一站搞定，不需要额外折腾内网穿透。

还有一点是合规层面的考量。企业场景下接微信个人号有封号风险，但通过企业微信官方API接入是安全合规的。腾讯云的服务器配合企业微信应用的回调机制，可以实现一个完全合规的Agent消息通道，这在广告营销这种需要长期稳定运营的场景里是必须的。

2. 企业级方案的整体架构与资源规划

2.1 一套能支撑广告营销团队的部署架构

我们最终确定的架构是一个“接入层-控制层-执行层-存储层”的四层模型。接入层跑在腾讯云的公网入口上，负责接收企业微信、公众号、邮件、表单等渠道的消息；控制层是OpenClaw的主进程，负责Agent的调度、技能的编排以及消息上下文的管理；执行层是一个个独立的AgentWorker，它们去调用大模型API、执行浏览器操作、对接投放平台的开放接口；存储层则使用腾讯云COS存放日志、生成的素材文件、导出的报表。

多项目的隔离是这次架构里一个很重要的点。四个业务项目部，如果共用一个Agent实例，很容易出现上下文串味、权限越界的问题。我的做法是用OpenClaw的多Agent机制，为每个项目部创建独立的Agent配置，每个Agent绑定各自的项目知识库、技能列表和渠道白名单。底层共用一个OpenClaw主程序，但上层业务逻辑完全隔离，这样既节省了部署成本，又保证了业务边界清晰。

数据流向是这样的：客户在企业微信里发来一条咨询消息，渠道适配器把消息转成标准事件格式，交给对应的Agent处理。Agent先检索项目知识库判断客户的意图，如果是想了解投放报价，就调用“报价生成”技能，调取项目报价表数据，生成一段结构化的回复，由Agent发送回企业微信。同时，这个交互记录会异步写入COS，并触发一个“线索归集”的技能，把新客户信息同步到CRM系统。整个流程从收到消息到完成归集，控制在几秒内。

2.2 腾讯云资源清单与选型建议

具体到腾讯云资源的选择，我按“起步阶段”和“规模化阶段”分别做了规划，表格如下：

这里有个很实用的建议：别一上来就买最高配的服务器。OpenClaw单实例在4核8G的机器上跑广告营销场景的常规任务完全够用，先把业务跑通，再根据云监控的数据决定要不要扩容。我们踩过的坑是早期为了省事买了8核16G的大机器，结果CPU长期只用15%，纯属浪费。

网络规划上，重点说一下安全组。OpenClaw需要对外提供Webhook接收端口，但绝不是所有端口都对外开放。安全组策略只需要放行80/443、SSH端口和OpenClaw管理端口，其他端口一律拒绝。如果你对接企业微信，还需要在企业微信后台配置可信IP，这个IP就是腾讯云服务器的公网IP。我第一次配置的时候漏了这个环节，结果企业微信回调一直报错，查了半天才发现是IP白名单的问题。

3. 腾讯云部署OpenClaw的实操全流程

3.1 准备一台干净的云服务器

我们从实际操作来梳理一遍。先在腾讯云控制台购买一台轻量应用服务器，镜像选择Ubuntu 22.04 LTS或者Debian 12，这两个系统对Docker和Node.js的支持最友好。选系统的时候注意：别选带宝塔面板的镜像，虽然可视化操作方便，但宝塔会自带一套Nginx、MySQL，占用的内存不少，对Agent这种轻量级应用来说有点杀鸡用牛刀。如果你确实习惯用宝塔管理文件，也可以后面再装，但记得把用不到的组件停掉。

登录服务器的几种方式我都试过。网页版VNC适合应急，但操作起来延迟高；最推荐的方式是SSH密钥登录，在腾讯云控制台生成密钥对，私钥保存到本地，然后用终端工具连接。密钥登录比密码登录安全得多，还能避免“密码太简单被暴力破解”的问题。如果你是在Windows上操作，直接用自带的Terminal或者PowerShell就能ssh登录，不需要额外装软件。

登录之后第一件事是更新系统包，然后装上基础工具，包括curl、git、vim这些。这一步看着普通，但能避免后面部署时因为缺依赖而报各种莫名其妙的错。

3.2 Docker方式安装OpenClaw

OpenClaw的安装方式有几种，本地npm安装适合Mac和Windows开发机，但在云服务器上我强烈建议用Docker。原因很简单：Docker方案把运行环境完全隔离了，Node.js版本、依赖库冲突这类问题统统不用管，而且升级版本时只需要重新拉镜像，回滚也方便。

安装Docker的过程不复杂，国内服务器建议配置腾讯云镜像加速器，不然拉镜像会很慢。配好镜像加速后，从GitHub把OpenClaw的部署仓库clone到服务器上，进入目录后会看到docker-compose相关文件。把模型API Key、渠道Token这些敏感配置写进.env文件，然后执行docker compose up -d把服务拉起来，再用docker compose logs -f跟踪启动日志。

启动成功的标志是日志里出现服务监听端口的记录，同时OpenClaw会生成一个配置后台的二维码或者访问链接，用浏览器打开就能进入管理界面。这里有个小细节：如果是第一次部署，OpenClaw会引导你创建管理员账号，这个账号密码一定要保存好，它是管理所有Agent和渠道的总入口，丢了只能重置数据，麻烦得很。

3.3 渠道接入：企业微信、公众号与邮件

渠道接入是企业级部署的重头戏。广告营销公司日常用最多的就是企业微信、公众号和邮件，这三个渠道的接入方式各有差异。

企业微信的接入走的是“自建应用”模式。在企业微信管理后台创建一个应用，拿到Corp ID和Secret，再把腾讯云服务器的公网地址配置成接收消息的URL，同时填上Token和EncodingAESKey。这串配置填进OpenClaw的企业微信渠道配置里，保存之后，企业微信里发给这个应用的消息就会被转发到Agent处理。

公众号的接入逻辑类似，在公众号后台的“基本配置”里开启服务器配置，把服务器地址指向OpenClaw的回调地址。需要注意的是，公众号的服务器配置启用后，公众号后台的自动回复功能会失效，消息全部转发给Agent处理，所以配置前要确保Agent的回复逻辑已经调试好。

邮件渠道更简单，配置一个IMAP/SMTP邮箱账号，OpenClaw就能定时拉取收件箱里的咨询邮件，自动提取正文，用Agent生成回复，再通过SMTP发回给客户。广告营销公司收到的合作咨询邮件、媒体询价邮件，都可以交给这个渠道自动处理。

这里必须提醒一句：个人微信的接入要非常谨慎。OpenClaw社区确实有一些个人微信的接入方案，但个人号协议本身存在账号安全风险，企业一旦被封号，所有客户关系都受影响。正规做法就是走企业微信和公众号的官方API，虽然配置麻烦一点，但胜在安全、稳定、合规，广告营销公司在这个问题上绝对不能图省事。

3.4 对接腾讯云COS做存储与日志

Agent跑起来之后，会产生大量的中间产物：生成的图片素材、抓取的网页快照、对话日志、技能执行记录。这些文件如果都放在系统盘里，很快就把磁盘塞满了。我们的方案是统一接到腾讯云COS对象存储上。

在腾讯云COS控制台创建存储桶，权限设置为“私有读写”，然后生成一组API密钥。在OpenClaw的技能配置里，把COS的SecretId、SecretKey、存储桶名称、地域这几个参数填进去，就可以通过技能调用上传和下载文件了。比如广告素材生成技能，Agent画完图直接上传到COS，再把COS的临时链接发给项目组，不需要经过服务器本地磁盘。

日志处理这块，COS的好处是可以设置生命周期规则。比如“对话日志保留30天，30天后自动转为归档存储，90天后自动删除”。这样既保留了审计追溯的能力，又不会让日志存储费用无限增长。还有一个与这相关的经验：视频和素材的大文件管理，不要在服务器本地腾挪，直接用COS的预签名URL做上传下载，腾讯云上录制的视频、拍摄的素材，都通过这个路径在内部流转，权限可控，还不用占用服务器的带宽资源。

4. 广告营销场景的Agent技能编排与落地

4.1 场景一：线索秒级响应与自动归集

广告营销行业有一条铁律：线索的响应速度直接决定转化率。传统的人工客服模式，从客户留言到销售跟进，中间隔几个小时很正常，有的甚至隔天才看到。用OpenClaw可以把这条链路压缩到秒级。

我们在企业微信渠道里配置了一个“线索响应”技能。触发条件是客户发送的消息里包含“报价、合作、投放、咨询”等关键词，Agent收到消息后，先识别客户所在行业和需求类型，检索对应的项目知识库，生成一段包含合作案例、基础报价区间、下一步沟通建议的回复，在10秒内发送给客户。同时，技能会调用CRM接口，把客户信息、聊天记录、需求标签自动写入CRM系统，并给销售推送一条跟进提醒。

这个技能的编排逻辑里，最关键的其实是“拒绝无效响应”。热点消息、闲聊消息、广告轰炸这类信息，很多人希望被实时响应，我建议给这些噪音设置一个更便宜的本地小模型，或者干脆设置最低置信度阈值，让Agent不理会这些不明确的消息，避免浪费模型调用成本。我们有一版没做这个过滤，结果一个月光闲聊回复就烧掉了上千块的API费用。

另一个细节是，线索归集后要打好“状态位”。Agent的能力边界要清晰，客户问到报价单里没有的定制需求，Agent不要硬编一个价格回给客户，而是明确告知“需要顾问人工介入”，并把会话转给人工销售。这个设计既避免了Agent乱承诺带来的风险，也保住了销售环节的存在价值。

4.2 场景二：竞品暗战与舆情监控

广告营销公司做竞品分析向来是个体力活。以前的流程是，养一个实习生，每天早上把十几个竞品的公众号、视频号、抖音号刷一遍，把更新内容截屏存档，整理成表格发到工作群里。这套流程可以用OpenClaw的定时触发器彻底自动化。

我在OpenClaw里配置了两个定时任务。第一个任务是“竞品内容快照”，每天早上9点触发，Agent调用浏览器工具，打开竞品矩阵的各个账号主页，抓取最近发布的内容标题、封面、发布时间和互动数据，然后调用大模型生成一份简洁的竞品更新摘要，发到项目管理群里。第二个任务是“舆情预警”，通过关键词监控工具，定时搜索行业核心关键词的讨论热度，当热度异常升高或者出现负面舆情时，Agent生成预警消息，并附上舆情的来源链接和初步分析，推送给品牌负责人。

这套系统跑了一段时间后，我们最大的感受是：Agent不怕烦，它能做到“日日不断”。人工做竞品监控，周末和节假日基本停滞；Agent可以365天不间断运行，即使春节期间竞品发布了重要活动，我们也能第一时间掌握。这个能力对广告营销公司的价值，用最直白的话说就是——“别人放假你开工”。

4.3 场景三：批量内容生产Pipeline

内容生产是广告营销行业的另一个重头戏。这个场景里我们没有让Agent完全替代创意人员，而是把它定位成一个“内容生产流水线的调度员”。

具体流程是：项目经理把本周的内容需求brief，用固定格式发到项目群，Agent自动拆分需求，识别出需要的素材类型、数量、风格调性和交付时间。拆分完成之后，Agent调用文案生成技能，先产出几版标题和核心卖点，再调用图片生成技能，制作对应的创意素材草稿，最后把文案和素材草稿整理成一份内容提案，发到项目群里供创意团队审核修改。

产品文档里常常把这种流程叫“Human-in-the-loop”，翻译成大白话就是“AI先干粗活，人来干精活”。创意人员不用再从一张白纸开始写，而是在Agent生成的几个方向性草稿上做优化和调整，效率能提升不少。内容定稿之后，Agent还能调用各平台的发布接口，按照排期定时发布，并自动收集发布后的数据反馈，形成内容效果报告。这就是一个从需求到发布到复盘的全链路Pipeline。

4.4 场景四：投放日报自动生成

投放数据的统计汇报是一项极其枯燥但绝对不能出错的工作。以前投放人员每天上午要花一两个小时，把腾讯广告、巨量引擎等平台的后台数据手动导出，再整理成Excel日报发出去。现在这个工作完全交给了Agent。

OpenClaw通过定时触发器，每天早上8点自动调用各投放平台的开放API，拉取昨天的消耗、展现、点击、转化数据，接入到技能里。Agent拿到数据之后，先判断数据是否有异常波动（比如消耗突然翻倍、转化率骤降），如果有异常，就在日报里同步生成预警；然后按照广告组、创意维度和地域维度，生成一份数据解读文案，附上关键结论和优化建议，整理成图文消息发送给投放团队。

投放日报的关键是准确性，这直接关系成本判断。为了确保这一点，我在技能里增加了数据校验环节：Agent从API拿到的数据，先和前一天的系统存量数据做交叉比对，如果发现前后矛盾，就标记为“待人工确认”，而不是直接把错误数据写进日报。宁可不自动，也不能错着自动。

4.5 权限、审计与安全边界

Agent一旦接入企业微信并拥有发送消息、操作CRM、调用投放API的能力，权限管控就成了一件不能被忽略的事。我用的是最小权限原则：每个项目组Agent只配置它业务范围内需要的API账号，技能调用外部系统时使用独立的访问令牌，并在操作日志中记录谁在什么时间调用了什么技能、修改了哪些数据。

对广告营销公司来说，审计日志还有一个额外用途——它是月结的时候跟客户对齐工作量的依据。Agent处理的线索量、生成的内容数量、发出的日报数，全都有日志可查，这比人工汇报可信得多。

数据安全方面，我们做了两个硬性规定：涉密客户数据不出内网，聊天记录里的个人身份信息在写入COS之前做脱敏处理；模型的训练数据关闭，客户对话不会成为模型服务提供商的数据源。广告营销公司手里的用户画像和投放数据，是公司的核心资产，这个红线不能碰。

5. 成本优化：把Agent跑起来的账算明白

5.1 模型调用成本：最大的隐形开销

Agent基础设施的成本结构和传统服务器不一样。传统应用的成本大头在服务器，Agent应用的成本大头在大模型API的调用。腾讯云的机器一个月几千块是固定的，但大模型API如果控制不住，一天烧掉几千都很正常。

模型调用的成本优化，我们从三个维度下手。

第一是提示词压缩。OpenClaw默认会把对话上下文完整传给模型，上下文越长，token消耗越大。广告营销场景里很多对话其实是重复的，比如企业微信里客户问“你们做不做抖音投放”，跟问“能投抖音吗”本质是同一个问题。我们在技能层做了一个意图识别前置处理，先判断这句话是否命中已有意图，如果命中，就直接走预设的话术模板，不调用大模型。这个优化直接把API调用量降了接近四成。

第二是模型分级路由。简单任务用小模型，复杂任务用大模型。OpenClaw支持给不同技能配置不同的模型。像关键词提取、消息分类、定时任务检查这类简单任务，用便宜的小模型处理；撰写创意方案、分析竞品策略、生成投放结论这类复杂任务，才调用更强的大模型。一个广告营销公司如果全流程都用最好的大模型，那成本几乎是必然失控的。

第三是结果缓存。同一个客户反复问“你们价格怎么算”，第一次Agent算出完整报价，第二次就应该直接读缓存，不再重复调用模型计算。我们给Agent配了一层Redis缓存，按客户ID加问题摘要做键，命中缓存就直接返回结果。对于咨询高峰期的大量重复问题，这个策略能省下很可观的模型费用。

5.2 基础设施成本：云资源怎么省

服务器成本这块，我的核心建议是用“够用就好”的起步配置，然后靠监控数据驱动扩容。OpenClaw本身对资源的消耗并不夸张，真正吃资源的是浏览器自动化和图片处理这类技能。如果某一个技能特别耗CPU，可以单独拆出去，用一台按量的竞价实例来跑，跑完就释放，不用长期持有。

腾讯云的竞价实例价格远低于包年包月，适合舆情监控这种跑完就结束的任务。比如每天抓取竞品数据的分布式任务，用竞价实例开几台临时的执行机器，抓完数据写入COS自动销毁，成本相比长期持有几台固定服务器能省掉不少。

另外，别忽略流量带宽的成本。OpenClaw如果频繁传输大图片、视频，公网流量费用是一笔不小的开销。我们的处理方式是，图片和视频素材的对外传输一律走COS，利用COS的内网流量访问，避免占用服务器的公网带宽，同时也降低公网流量费用。

5.3 成本预估：一张表看清投入产出

给准备入手的团队一个参考区间。以一家5到10人、4个业务项目的广告营销公司为例，腾讯云基础设施成本大致如下：

真实的数据是，这套基础设施上线后，原先一位负责每天整理线索、发布内容、收集数据的运营助理，可以转去做更偏策略的投放优化工作。一个人的月人力成本就覆盖了这套系统全年的大部分开销。成本优化到最后，其实算的不是省了多少钱，而是同样的钱换来了多几倍的执行能力。

6. 常见问题与排查技巧实录

6.1 部署类问题：WSL2验证失败与Windows安装报错

部署环节最常见的问题是Windows用户想在本地跑OpenClaw，装了Docker Desktop之后，启动时提示类似“could not safely verify the WSL2 environment”的错误。这个报错的原因通常是WSL2内核版本过旧，或者没有安装“Windows Subsystem for Linux”的可选组件。

解决办法分三步：先用管理员身份运行PowerShell，执行wsl --update把WSL2内核更新到最新；然后执行wsl --set-default-version 2，确保默认版本是WSL2而不是WSL1；如果还报错，检查BIOS里虚拟化功能是否开启。这里有个经验：本地Windows环境跑OpenClaw再做微信渠道调试，不如直接在腾讯云服务器上跑省心，因为Windows的防火墙和网络代理经常拦截回调请求，排查起来比Linux麻烦得多。

6.2 渠道类问题：消息能发出去但收不到回复

这是我们实际运营中遇到最多的问题：OpenClaw能正常给客户发消息，但客户回复过来之后，Agent完全没有反应。这个问题的根源通常不是Agent本身，而是回调链路上的某个环节断了。

按顺序排查：先在企业微信后台查看应用的“接收消息”回调日志，如果回调记录是空的，说明消息根本没有推到服务器，问题在企业微信的URL配置或者可信IP配置；如果回调日志里有请求但OpenClaw没有反应，去OpenClaw的运行日志里查Webhook的接收情况，看看是不是签名校验失败，这通常是Token和EncodingAESKey填错了；如果日志显示消息已接收但Agent没有生成回复，那就要检查模型API的Key是否过期、余额是否充足。

这类问题我们整理了一个排查顺序表格，按“渠道后台-回调日志-模型调用”三层从外到内查，基本能在十分钟内定位问题。

6.3 运行类问题：Agent无响应与模型返回失败

运行过程中，有时候会遇到Agent收到消息后长时间不回复，OpenClaw日志里出现类似“agent couldn't generate a response”的提示。这种情况大部分是模型API超时，或者模型的上下文过长导致请求失败。处理办法是给Agent的模型调用配置一个超时时间，并设置重试机制；同时在技能层限制单次请求输入的文本长度，避免长文章一次性丢给模型处理。

还有一个容易被忽略的原因：并发冲突。多个渠道同时给同一个Agent发消息，Agent处理队列堵住了，后来的消息迟迟得不到响应。我测过之后，把企业微信、公众号、邮件拆成三个独立的Agent实例，各跑各的队列，互相不抢资源。这里建议每个渠道单独创建一个Agent配置，不要所有渠道共用同一个Agent实例。

6.4 运维类问题：磁盘爆满与日志膨胀

Agent跑久了，最容易出问题的其实是磁盘空间。OpenClaw会把每次技能执行的日志、临时文件、图片缓存都写到本地，如果不管，磁盘很快就满了。

我们的处理办法是三层防护。第一层是给系统盘设置自动清理脚本，每天删除超过7天的临时文件；第二层是把重要的日志持续同步到COS，本地只保留最近几天的量；第三层是用云监控设置磁盘使用率告警，超过80%就推送通知，提前介入处理，不至于等磁盘满了再救火。

最后再分享一点实操中的体会

整套方案从选型到落地，前后花了两周多。第一周把OpenClaw在腾讯云上跑通，第二周才真正在业务里用起来。对比之前用过的商业SaaS工具和自研框架，OpenClaw这套方案最大的价值不是某个单点功能有多强，而是把“渠道接入、Agent执行、技能扩展、数据存储”这几个基础设施级的模块全部打通了，并且把控制权完全交到了自己手里。

如果你也准备在广告营销行业尝试Agent基础设施，我的建议是别追求一步到位。先跑通一个场景，比如线索自动响应，用两周时间让业务团队感受到“消息秒回、线索自动归集”的体验，再逐步把舆情监控、内容生产、投放日报这些场景叠加上去。Agent这东西，最怕的不是功能弱，而是没有解决好业务里最痛的那个问题就急着铺开。找到那个痛点，把它用Agent彻底解决掉，就是一次成功的基础设施建设。