网站运维 Agent 如何减少协作消耗

一个网站要管 SEO、商店、内容和部署，就该给每件事配一个 AI agent 吗？作者在一家家族酒庄的网站上试过，结果多个 agent 忙着互相传话，DNS 迁移和博客排期反而漏了。改成一个 webmaster agent 统筹后，原本 2 天耗尽的额度，还能留给另外 2 到 3 个项目。

这篇值得读的地方，是把「一个 agent 管网站」拆成了岗位、工具、记忆、例行任务和审批边界。但省额度只是个人案例，不能直接推导出单 agent 在所有任务上都更强。

为什么分工更多，事情反而没人负责

作者服务的 Sogas Mascaró 是一家生产 cava 和葡萄酒的家族酒庄。他最初安排了 SEO agent、商店管理 agent 等多个角色，每个角色都有自己的指令和项目认知。

问题出在职责交界处。网站迁移需要调整 DNS，博客需要维护发布日历，这些工作很难完整归进某一个角色，于是停留在 agent 之间的聊天里，最后遗漏了。

作者给出的解释是：每次交接都会压缩信息，接收方不知道哪些细节被省掉，只能自行补全。两个 agent 对同一件事作出不同假设，后续操作就可能冲突。

一个 webmaster 同时负责迁移和排期，至少减少了一类风险：事情跨越职责时，没有人持续跟进。这里的 webmaster 可以理解为网站负责人，既处理内容和运营，也跟进技术健康，而不是只等用户提问的聊天窗口。

作者使用的是 Grok Bot。多 agent 方案在 2 天内耗尽全部使用额度；改成单 agent 后，剩余额度还能支持另外 2 到 3 个项目。这是他提供的实际观察，但原文没有交代额度总量、两种方案的任务数量和运行周期，不能据此计算节省比例。

他认为同样的思路也可能适用于半自主运行的 Claude Code、Codex，同时明确承认：这只是观点，没有验证结果。

研究支持的是收紧写入权，不是取消多 agent

原文引用的研究，支持的是有条件的取舍。

Cognition 在 2025 年 6 月的「Don't Build Multi-Agents」中强调，agent 应共享上下文和完整执行轨迹，不能只交换几条消息。原因在于，操作本身包含隐含决策：一个 agent 修改了实现，可能已经选定一种方案，另一个 agent 却还按旧假设行动。

10 个月后的 2026 年 4 月，Cognition 在「Multi-Agents: What's Actually Working」中介绍了生产环境里的多 agent 用法，重点变成：写入操作保持单线推进，其他 agent 提供分析和审查。

原文转引的数据是，针对 Devin 编写的 PR，Devin Review 平均每个 PR 找出 2 个 bug，其中约 58% 属于严重问题。这支持增加审查角色，但没有证明让多个 agent 同时改代码更有效。

Anthropic 在 2025 年 6 月的研究系统文章中给出了另一种成立条件：Claude Opus 4 担任主 agent，Claude Sonnet 4 担任子 agent，在内部研究评估中，比单独使用 Claude Opus 4 高出 90.2%。

代价也很明确：agent 通常消耗聊天交互约 4× 的 tokens，多 agent 系统约为聊天的 15×。两个倍数的基准都是聊天，不能直接读成多 agent 比单 agent 贵 15 倍。90.2% 也是内部研究评估结果，不能外推为网站运营或编码效率。

独立检索可以分头进行；商品资料、页面内容、广告和部署却经常互相牵连。判断是否增加 agent，应该先看任务依赖和修改权限。

一个 webmaster 真正需要哪些工作条件

作者建议先写招聘说明，再写提示词。岗位是 webmaster，使命是让网站和商店卖得更多，向站点所有者汇报，只在重要事项出现时提醒。

他认为，清楚的岗位比 40 条零散规则更容易让 agent 推理。这是经验判断，但「先明确职责」确实比直接堆工具更容易检查遗漏。

他的职责清单相当具体：

• 网站使用 Next.js，部署在 Vercel；通过云端 coding agent 在分支上修改，每周合并为一个 PR，以控制构建成本。合并前要求 CI 通过并检查预览，之后再检查生产环境。
• 每天改善 10 个 WooCommerce 商品页，使用核实过的文案、官方图片和 FAQs。
• SEO 涵盖关键词、分类、meta tags、schema、llms.txt、性能与索引；内容日历按 TOFU、MOFU、BOFU，也就是认知、考虑和转化阶段安排。
• SEM 负责 Google Ads 和 Merchant Center；每天监控关键页面、sitemap、购物车、结账、部署、订单和转化追踪。

工具逐项对应职责：GitHub、云端 coding agent、Vercel、WordPress/WooCommerce REST API，以及 Google Search Console 的 API 和浏览器入口、Bing Webmaster Tools、GA4、Google Ads、Merchant Center。没有 API 的操作使用浏览器，产品资料通过搜索与官方来源核对。

记忆放在 Notion，保存 SEO 计划、博客日历、商品页数据库和变更日志。每项实验记录基线，行动前读取，行动后更新，否则过一段时间就无法判断修改有没有效果。

例行工作也要明确：每天处理商品页和监控；周一检查 Search Console、Bing 及接近搜索结果第 1 页的关键词；周二、周五写博客；周三处理广告和 Merchant Center；周四改落地页、更新旧文；周五做外链，自动提交免费目录，外联只准备草稿；每月 15 日做技术审计。没有异常就保持安静。

最后是权限。符合品牌规则、通过链接检查的博客可以自行发布，否则保留草稿；价格、库存、商品名称、影响支出的广告调整，以及服务器和 DNS 操作需要批准；不得冒用作者身份发送邮件或消息，也不得付款。

若确实需要多个 agent，作者只推荐两类辅助角色：并行只读研究，例如调查 50 个关键词对应的竞争页面；以及只检查事实、链接和论据的审查者。

协作记录仍放进 Notion，每个分区只有一个写入者，其他 agent 只读。记录决策与当前状态，通过引用访问原记录，避免不断复制会过期的摘要。

我的判断

我赞同把「谁持续负责」和「谁有权修改」放在 agent 数量前面。对小型商业网站，这通常比先建立 SEO、内容、商店等多个角色更容易落地。

但原文没有同等任务量、质量和成本的对照实验。它证明作者找到了更适合自己业务的配置，尚不足以证明单 agent 普遍更省、更稳。相关研究也针对不同任务，不能拼成统一排行榜。

单 agent 同样会遗忘和误判。职责越多，上下文管理和任务优先级越重要；Notion 能保存状态，却不会自动保证它读取了正确页面。每区一个写入者减少了冲突，也不能替代工具层面的权限限制。

一些安排还有业务前提。每周一个 PR 适合可批量处理的常规更新，线上故障显然不能等周五；每天优化 10 个商品页是产能安排，不是质量标准。作者说配置不需要编码，但他自己有 webmaster、软件工程和 SEO 经验，知道该授权什么，这部分经验不能忽略。

与复杂编排相比，值得先试的是：一个负责人承担执行，确定性的检查交给 CI 和脚本，再按需要增加只读审查。任务已经能独立拆分时，才有理由为并行付出额外成本。

能拿来做什么

• 给半自主运行的 Claude Code 或 Codex 写一份项目职责说明，明确任务范围、汇报条件和完成标准；把它当作待验证的配置，观察遗漏和返工是否减少。
• 为 Next.js 网站写清分支、PR、CI、预览和生产验证流程，按实际更新频率安排发布，并给故障修复保留及时处理的通道。
• 在现有文档系统中记录关键词归属、内容排期、实验基线和待批准事项，要求 agent 行动前读取、完成后更新，不必为了记忆单独迁移到 Notion。
• 需要第二个 agent 时，先让它只读审查事实、链接或代码问题；将 DNS、服务器和广告支出调整保留为明确的审批动作。