Glitch Grow AI Ads Agent：电商广告投放的自主运营代理\n\n在数字营销领域，广告投放运营往往是一项繁琐且高度重复的工作。从数据分析到预算调整，从创意测试到效果追踪，运营人员需要同时监控多个平台、处理海量数据。Glitch Grow AI Ads Agent正是为解决这一痛点而设计——它是一个能够自主运行付费媒体运营的AI代理，让运营者从执行者转变为监督者。\n\n## 项目定位与核心价值\n\nGlitch Grow AI Ads Agent是Glitch Executor Labs数字营销领域的产品，专注于为Shopify和电商品牌提供端到端的广告运营自动化。与市面上各种AI营销工具不同，它不是一个简单的数据分析仪表盘或报告生成器，而是一个能够真正执行操作的自主代理——它可以暂停表现不佳的广告组、调整预算、更换创意，并在获得授权后自动执行这些决策。\n\n该代理的核心价值在于"闭环运营"：它不仅分析发生了什么，还决定下一步做什么，执行决策，然后观察结果并学习。运营者从繁琐的日常操作中解放出来，只需要设定约束条件（预算上限、品牌调性、审批阈值），在关键决策点进行监督，并接收执行结果。\n\n## 架构设计：计划-分析-执行-学习闭环\n\n代理的运行遵循一个完整的运营闭环：\n\n首先是计划阶段，代理根据历史数据和当前趋势决定下一步测试什么。然后是分析阶段，评估已执行动作的效果。接着是执行阶段，根据品牌设定的自主阈值决定是暂停、调整预算还是更换创意。最后是学习阶段，将每次决策的经验沉淀到记忆中，用于指导未来的决策。\n\n这种设计让代理具备了持续改进的能力。每一次决策都会记录理由、备选方案和预期结果，形成可审计的决策日志。代理不是简单地重复固定规则，而是在实践中学习每个品牌的独特行为模式。\n\n## 多平台数据整合与归因\n\n代理原生整合了三个核心平台的数据：\n\nShopify提供单店GMV、平均订单价值、复购用户群和UTM覆盖情况。Meta Ads提供广告系列/广告组/广告级别的花费、创意和目标URL数据。Amazon则通过Seller Central订单、SP广告表现和单ASIN盈亏数据补充电商全貌。\n\n在归因方面，代理解决了跨平台追踪的行业难题。对于Shopify到Meta的归因，它使用PostHog的 ground truth 数据而非Meta自身可能夸大的数字。对于Meta到Amazon的归因，在无法使用Amazon Attribution API的情况下，采用减法模型（总Amazon订单减去Amazon SP广告订单）进行估算。\n\n这种真实的归因能力让代理能够回答运营者最关心的问题："品牌在Meta到Shopify和Meta到Amazon渠道的真实混合ROAS是多少？""哪个ASIN获得了不成比例的Meta点击但没有Amazon转化——应该暂停还是迭代？"\n\n## LangGraph驱动的状态机架构\n\n代理选择LangGraph作为编排框架，这是一个关键的技术决策。与CrewAI的角色框架或AutoGen的对话模型不同，LangGraph提供了更适合广告运营的状态机抽象。\n\nLangGraph的优势体现在几个方面：持久化检查点让状态能够在人机协同审批等待期间存活（当动作在审批队列中停留数小时时这一点至关重要）；按节点选择模型让推理节点使用Gemini 2.5 Pro，批量摘要节点使用Flash，解析节点使用GPT-4o-mini，成本与认知需求匹配；确定性重试机制在代理触碰真实Meta预算之前提供必要的可靠性保障；条件入口点让一个图能够服务12种以上命令类型而无需重建。\n\n## 人机协同与Telegram界面\n\n代理通过Telegram Bot与运营者交互，每个工作空间拥有独立的Bot实例。所有命令都需要运营者的Telegram用户ID在管理员白名单中，确保安全性。\n\n已实现的诊断命令包括：/insights查看GMV、订单、AOV和UTM覆盖；/roas获取真实ROAS与Meta报告数据的对比；/tracking_audit提供像素/CAPI差距的修复建议；/ads查看按花费排序的广告排行榜；/creative使用Gemini视觉能力评估创意素材；/ideas基于获胜模式生成创意简报；/alerts监控CPC漂移、匹配率下降等异常；/amazon汇总Amazon Seller和广告数据；/attribution展示Meta到Amazon的归因分析。\n\n在开发中的v2版本将引入自主动作层：代理可以提出暂停、调整预算、更换创意等写操作，在超过品牌自主阈值时进入Telegram人机协同审批队列，运营者可一键批准或拒绝。\n\n## 记忆系统与学习能力\n\n代理的记忆系统基于PostgreSQL的pgvector（HNSW余弦索引）和tsvector全文检索。每次代理回合都会被索引用于混合检索，确保代理在每个决策开始时都能回顾"上次面对X情况时，我们做了Y，结果是Z"。\n\n夜间整合cron会基于相关性、频率、多样性、时效性和整合度对记忆进行评分，将持久的经验提升到按品牌分类的MEMORY.md文件中，作为系统提示上下文加载。这种设计让代理能够从长期经验中学习，而不只是依赖短期上下文。\n\n## MCP架构与数据层解耦\n\n代理采用MCP（Model Context Protocol）架构，将各平台的数据获取委托给专门的MCP服务器。这种解耦设计让更换数据源变得简单——例如从Amazon Supermetrics切换到原生LWA只需服务器端变更，无需重新部署代理。\n\n当前架构包括：glitch-grow-ai-ads-agent（本仓库）负责LangGraph代理、Telegram Bot、PostHog归因和记忆；glitch-ads-mcp负责Meta Ads数据读写；amazon-ads-mcp负责Amazon Seller Central和广告数据。所有数据最终汇聚到Postgres的ads_agent.*_daily_v视图中，提供去重、类型化的归因计算和财务分析。\n\n## 部署与安全性考量\n\n代理采用分离部署模式：Cloud Run托管LangGraph代理的HTTP端点和Cloud Scheduler作业；VM/systemd托管Telegram Bot和Shopify webhook接收器（需要本地访问meta-ads-mcp）。\n\n安全方面，关键端点都有多重保护：Telegram webhook通过secret_token验证；Shopify webhook通过HMAC验证；/agent/run端点需要Bearer token，并在生产环境配合Cloud Run IAM使用。建议不要将--allow-unauthenticated用于任何端点，而是将Cloud Run置于HTTPS负载均衡器后，按路径配置策略。\n\n## 技术栈与依赖\n\n代理的技术栈体现了现代AI应用的最佳实践：LangGraph提供持久化状态机和重试机制；Pydantic AI提供类型化的工具模式；LiteLLM实现多模型路由（Claude Sonnet用于推理、Gemini Flash用于批量、Pro用于深度审计）；PostHog Cloud提供CDP、归因和身份拼接；Meta Ads和Amazon数据通过MCP服务器获取；Shopify数据通过自研GraphQL客户端获取；Telegram界面使用python-telegram-bot。\n\n## 应用场景与价值主张\n\nGlitch Grow AI Ads Agent最适合以下场景：管理多个Shopify店铺的电商品牌需要统一的多渠道广告视图；希望从手动报告分析转向自动化决策的运营团队；需要跨Meta和Amazon进行真实归因以优化预算分配的品牌；希望减少人工监控时间同时保持控制权的广告主。\n\n对于运营者而言，代理的价值在于将时间从"看数据、做表格、调预算"转移到"设定策略、审批关键决策、优化代理行为规则"。代理不会取代人类的判断，而是将人类从重复性工作中解放出来，专注于真正需要创造力和战略思维的工作。