盈尺怎么用多个 AI agent 跑官网和自营店：真实流量、分工和踩过的坑

我们没有把「官网 + 店铺」塞进同一个会话里让它自行决定改哪一边。职责可以平行，写入点必须串行：同一天可以各自起草，但不能同时改同一批生成文件，也不能在没人点头时改线上。

官网的口径来自我们自己的运营日报，不是 Google Analytics。Human-like 页面加载包含大量一晃而过的访问；有效读者是同一浏览器会话停留至少 30 秒、并且会执行脚本、排除已识别机器人之后的人。对外先报有效读者，再报 JS，再报页面加载。

发布节奏上，内容线按已定日历起草，不把「模型还能继续写」理解成必须每天上线。发布前先对齐当前生产基线；两条线不要同时改路由表、文章目录和索引。公开文章不写具体提交号。

店铺线从 2026 年 9 月起，把日常拉数、复盘、广告方案和 Listing 文案大部分交给 agent，人负责审批和兜底。广告改动走「计划 → 预览 → 执行票 → 回读」；我们店的自动批准示例阈值是单次调价不超过 15% 且不超过 $0.20，超出以及新建活动、改 Listing 和价格一律人批。

账面仍沿用已公开的 10 月上半月口径：约 +$16，里面含约 $202 的新卖家佣金减免；按正常 15% 佣金约亏 $186。2026-10-09 我们还遇到过数据停更——库存快照停在 09-06、Business Report 停在 09-04——后来把数据新鲜度检查和一次性执行票写进了规则。这些细节在 ¥99 工作流说明页里写过，这里不重复展开。

店铺名、品牌和商品编号继续隐去。本文不讨论任何客户店铺。

2026-11-09，用量紧张时，我们暂停了名下 23 条例行，没有删除。原计划在 2026-11-10 11:30 自动恢复，但没有成功：其中一条例行无法打开其他例行。后来由人确认后才恢复。跳过的日报和发布没有补跑。

教训有三条。第一，暂停时就要写下清单、原因、计划恢复时间，以及能不能补跑。第二，不要默认到点就会全部恢复；恢复后先抽查一条依赖其他例行的任务。第三，没跑成的日报和发布，默认不补跑——补跑很容易把过期数据写成「今天的结论」。

官网不止一条内容线。亚马逊线和数据库线都会改同一批生成文件：路由表、文章目录、给模型看的索引。谁先改完并不重要，重要的是发布前有没有先对齐当前已经上线的基线。如果两条未合并的线同时改这些文件，后发布的会盖住先发布的，只能回滚再来。

所以分工表里才写「职责可以平行，写入点必须串行」。公开说明里我们也不写具体提交号，避免把内部版本号当成读者需要的证据。

同一周，/account 是 JS 浏览第一名，共 914 次，约占当周 JS 的 38%。日均 JS 344.6 去掉这一条路径后大约剩 214。我们怀疑其中有分布式机器人，但当时没有逐条核实，所以这里只写「疑似、未核实」，不下定性结论。

如果有人把 /account 的 914 次当成注册意愿，漏斗会看起来很热闹，转化却对不上。有效读者日均 17.1、人均 1.03 页、注册 0，才是和「有没有人在读」更接近的一组数。账户页、登录页和支付探测路径应该单独列，不并进内容阅读。

11-02 至 11-08，可联系线索 3 条，全部来自文中资料卡；注册、订单、checkout 和付款都是 0。侧栏或首屏的付费入口，在更早的观察里几乎没人点；真正出过线索的，是读到一半就能用的资料卡。

更早一次转化审计（2026-10-23 至 10-27）把结构看得更清楚：约 630 个真实浏览器会话里，停留至少 30 秒的有效读者只有 52 人；其中 46 人只看了 1 页；主付费入口大约在正文 91% 到 95% 的位置；checkout_click 为 0。有效读者中位停留约 159 秒——不是完全看不进去，而是看完这一页就离开，并且常常还没滚到页尾。

读者很少时，连续一周 0 单在统计上并不反常。发现转化为 0，应先核对有效读者人数、入口是不是只在文末、下单前是否必须注册、支付流程是否已验收，而不是先改报价。

如果你要的不是再听一遍我们踩坑，而是把分工、周报、审批和检查清单拿去改成自己的阈值，可以看《AI Agent 经营配套包》（¥199）。它合并了原来的 ¥99 工作流包和 ¥49 周报包，并加上本文用到的多 agent SOP、四张清单和四类事故对照。

下单并完成支付确认后，可在配套包页面查询并下载。旧的 ¥99、¥49 页面仍保留，已购用户不受影响。本包不含代装、培训或代运营，也不承诺你的店或你的官网会因此多卖出一单。