AI 跨境增长站
← AI 邮件与 CRM

Klaviyo K:BOS 2026：Headless 把 490 个 API 开给了 Claude 和 ChatGPT

email-marketing ai-agent mcp klaviyo claude chatgpt

Klaviyo 的秋季大会 K:BOS 2026 在 9 月 9 到 10 日开完，地点是波士顿的 Hynes Convention Center。春季那波更新（Composer 和 Customer Agent）解决的是「在 Klaviyo 里面用 AI」，这次发的 Headless 反过来，Klaviyo 整个变成一层可以被外部 agent 调用的能力，你在 Claude 或者 ChatGPT 的对话框里就能把活动发出去。对已经在用 Klaviyo 的卖家来说，变的是你团队每天从哪个界面进去干活。

这次到底发了什么

按发布内容排一下：

发布项状态一句话说明
Headless发布260 多个 MCP 工具和能力、490 多个 API 对外开放
KDP 里的 SQL预览大白话问题转成 SQL 查询，走 Composer 和 MCP
Customer Agent在售环比增长 40%，Klaviyo 历史上增长最快的产品
Composerbeta累计 138,000 个客户用过

Klaviyo 这次还把自己的定位改成了 The Autonomous B2C CRM，2026 年第三季度开始用这个说法。这个定位对应的是 Headless 这条产品线：CRM 不再要求人坐在界面前操作，改成由 agent 代跑。

Customer Agent 环比 40% 的增速值得单独看一眼。跑得最快的是客服自动化这条线，做内容生成的 Composer 还在 beta。排预算的时候可以参考这个先后顺序。

Composer 的计费方式，第三方信息显示还在 beta 阶段、按 credit 扣，具体报价以你账户里看到的为准。

Headless 对已经在用 Klaviyo 的卖家改了什么

Headless 的能力可以拆成三档：读、写、发。

读这一档春季就有了。Klaviyo 和 Anthropic 打通之后，Claude 能拉客户数据、订单数据、flow 表现数据，做审计和报告。那时候 agent 是个分析师，看完给你结论，改还是你自己进后台改。

写和发这两档是这次新加的。260 多个 MCP 工具覆盖的不只是查询接口，agent 可以往 Klaviyo 里写数据，也可以把一个活动发出去。加上 490 多个 API，Klaviyo 这边的能力基本都有对应的程序化入口。

实际差别举个例子。你在 Claude 里说「把过去 60 天打开过邮件但没下单的用户拉出来，建个 segment，写一封复购邮件，周四上午 10 点发」，春季的版本会给你一份 segment 定义和一段文案，你复制到 Klaviyo 后台去建；现在这一整串可以在对话里跑完，最后一步是活动进入排期。

对团队的影响是岗位分工。原来运营的工作量里有很大一块是搬运：把分析结论搬成后台配置。这块被吃掉之后，剩下的工作是判断该不该发、发给谁、以及审一遍 agent 生成的东西。

还有一层变化容易被忽略，入口从 Klaviyo 移到了你团队本来就在用的 AI 工具里，不懂 Klaviyo 后台的人也能提需求。产品经理想看某个 SKU 的邮件表现，不用再找运营排队。麻烦的那一半在于，权限没收紧的话，能对着生产账号提需求的人一下子就不只是运营那几个了。

KDP 里的 SQL 预览：用大白话查数

Klaviyo Data Platform 这次加了 SQL 查询，目前是预览状态，通过 Composer 和 MCP 两个入口用。

它的工作方式是把你用大白话提的问题翻译成一条 SQL 查询。能查的对象包括 profiles、events、segments、lists 和 catalogs，也就是客户档案、行为事件、分群、列表和商品目录这五类数据。

这个功能解决的是一类老问题：Klaviyo 后台的报表是预设好的，你想问一个报表里没有的问题，以前要么导 CSV 自己算，要么写 API 脚本。现在直接问。比如「过去 90 天买过两次以上的客户里，有多少人在最近 30 天打开过邮件但没点任何链接」，这个问题在原来的报表界面里拼不出来，SQL 能查。

预览阶段的东西建议按这个顺序用：先拿已经知道答案的问题去问，对一下数字对不对；数字对得上，再拿它查新问题。翻译出来的 SQL 如果能看到，最好看一眼过滤条件和时间窗口是不是你想要的，语义歧义在这一步最容易暴露。

最容易翻车的是时间口径。「最近 30 天」是自然日还是滚动窗口，「买过」算下单还是算付款成功，这类定义在你脑子里是清楚的，在提问的那句话里往往没写出来。养成习惯把口径写进问题里，比事后核对省事。

catalogs 这个数据源值得多用。它意味着你能把商品属性和客户行为放在一个查询里问，比如「买过某个品类的客户，在最近一次浏览里看的是不是同品类」。这类跨商品和行为的问题原来要在 Shopify 和 Klaviyo 两边各导一次数据再拼。

Agent 能自己发活动之后，权限怎么收

Customer Agent 那套 Agent Guidance 管的是客服代理说话的语气和什么时候转人工，管不了 Headless 这条线。这里的风险是另一类，一封发错的活动邮件发出去就收不回来，收件人可能是几十万个。

几条具体做法。

按 API key 的权限范围分开建。给 agent 用的 key 只给它这个场景需要的读写范围，查数的 key 不给写权限，建活动的 key 不给删除权限。别图省事用一把全权限的 key 接所有 agent。

把「创建为草稿」和「直接发送」当成两个不同的授权等级。日常让 agent 只能建到草稿状态，发送这一步留给人点。需要 agent 端到端跑通的场景（比如触发式的补货通知），单独开一把只能操作那一个 flow 的 key。

设发送量上限。agent 判断失误的典型表现是把 segment 条件写宽了，本来要发 8,000 人变成发 80,000 人。上线前先问清楚超过某个收件人数量时会不会有拦截，没有的话就用固定 segment，别让 agent 现场建 segment。

留审计记录。哪个 agent、什么时间、调了哪个接口、改了什么，这套记录在出问题复盘的时候是唯一能查的东西。对话框里的聊天记录不算审计日志，它不带接口调用的参数。

管住谁能对着生产环境提需求。key 的权限收得再干净，agent 也还是听谁说话就照办，所以访问控制有两层，一层是 key 的范围，另一层是哪些人能用到带生产 key 的那个 agent。第二层经常被漏掉，因为它不在 Klaviyo 后台里，在你团队用的 AI 工具那边。

先跑影子模式。让 agent 跑两周，所有输出只建草稿不发送，人工逐条对一遍，对得上再放开发送权限。这两周花在人工对草稿上的时间，比一次发错群发之后要收拾的事少得多。

什么时候值得接，什么时候先别接

接不接 Headless，取决于你们团队现在卡在哪一步，按下面四种情况对号入座。

已经有人在写 Klaviyo API 脚本的团队，接入成本最低，MCP 工具基本能替掉手写的那层封装，接完之后脚本维护量会掉一截。

营销团队只有一两个人、流程也不多的小店，收益有限。你的瓶颈是想不出该发什么，不是配置太慢。这种情况下 Composer 比 Headless 更实用。

数据分散在 Klaviyo、Shopify 和广告后台三头的团队，Headless 加上 KDP 的 SQL 查询值得排进这个季度。让 agent 一次把三边数据拉齐做判断，省下来的是每周固定几小时的对数时间。

多市场多账户的品牌要注意，Headless 的接入是按账户来的。五个市场五个 Klaviyo 账户，就是五套 key 和五套权限配置，别指望一次配完通吃。

Read this article in English: Klaviyo K:BOS 2026: Headless Opens 490 APIs to Claude and ChatGPT

相关文章