Go语言实现只读MCP服务器集成REST API

每个内容团队内部都有一个没人追踪的比例：有多少东西是人写的，有多少是软件写的。对大多数团队来说，这个数字很长一段时间都是零。然后变成了一个舍入误差。现在，在很多团队里，它悄悄地超过了一比一。

一旦 Agent 数量超过编辑，工作的形态就变了。草稿变得廉价且充裕。稀缺的是决定什么值得发布所需的判断力。如果你的工作流是围绕旧的瓶颈构建的，它会以某种特定且可预见的方式崩溃：一堆看起来像样的草稿，没人有时间核实。

Agent 被允许触碰什么的机制是一个独立的话题，我们之前在《AI Agent 写权限：CMS 中你真正获得的四个控制项》中已经覆盖了，包括我们尚未推出的两个控制项。这篇文章讲的是在任何这些设置之前发生的事情：一旦比例翻转，内容团队的日常工作如何自我重组，以及哪四个操作习惯必须随之改变。

比例翻转比流程变化更快

一个两人内容团队运行四个定时任务的 Agent，一周能生成的草稿数量比这两个人的仔细阅读量还多。仔细阅读一篇 1500 字的文章，核对其中的主张是否与主要来源一致，验证链接，这些都需要真正的时间。而生成它只需要几分钟。

所以吞吐量天花板从写作转移到了审核，每一个流程决策都应该跟随这个转移。目标是让审核变快，让劣质输出在结构上难以发布。

转变一：范围成为一个委托决策

最常见的错误是给一个 Agent 广泛的访问权限，然后指望提示词能撑住。提示词会漂移。密钥不会。

当你启动一个新的 Agent 时，把它的工作范围当作职位描述来对待，而不是事后填写的配置界面：

写下每个 Agent 预期触碰的对象类型，把这个列表放到它的指令里。一个社交文案 Agent 没有理由触碰你的定价页对象，你应该明确地告诉它这一点。

默认让每个 Agent 输出草稿。发布应该是分开的、刻意的动作，由对此负责的人来执行。

在你的环境中分离读密钥和写密钥。一个只做流量摘要的 Agent 根本不需要写密钥。

除非人类在该会话中明确要求，否则不要把破坏性操作摆上桌面。

要清楚哪些是强制执行的，哪些只是约定。在 Cosmic，现有的强制边界是 Agent 持有的密钥：跨 bucket 的只读或读写。没有按对象类型的权限设置，所以"这个 Agent 只触碰博客文章"是你给出的指令，也是你审计的习惯，而不是平台为你强制执行的规则。这正是读密钥/写密钥分离如此重要的原因，也是草稿默认设置具有真正分量的原因。

转变二：审核成为吞吐量天花板

草稿状态是你拥有的最便宜的安全机制。它不花任何成本，却能捕捉一切。必须改变的习惯是日历层面的：审核现在是你安排一周工作的核心，而不是附加在别人工作末尾的一个步骤。

这意味着审核队列必须是一个你的团队不用刻意想起来就能看到的真实界面。用 TypeScript SDK 拉取它，并渲染在你团队已经在工作的地方：

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
});

const recent = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('id,title,slug,status,created_at,metadata.author')
  .status('any')
  .sort('-created_at')
  .limit(25);

const reviewQueue = recent.objects.filter((post) => post.status === 'draft');

审批随后是一笔显式的写操作，由只有你的审核界面持有的密钥来执行：

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
  writeKey: process.env.COSMIC_WRITE_KEY!,
});

await cosmic.objects.updateOne(objectId, {
  status: 'published',
  metadata: { last_updated: new Date().toISOString().slice(0, 10) },
});

两个细节看起来不起眼但实际很重要。第一，在写操作之后把对象读回来，确认字段实际存储了你发送的值。报告成功但丢弃字段的写操作是那种会让文章带着空的 meta description 发布的 bug。第二，对关系字段（如标签和分类）使用显式的对象 ID。slug 可能在不同对象类型之间冲突，从而解析到错误的记录。

转变三：归因成为一个每周数字

当五个 Agent 和两个人类同时触碰同一个 bucket，"这是谁写的"就变成了一个你必须快速回答的运营问题。你需要它来 debug 一个错误的声明，淘汰一个表现不佳的 Agent，并回答一个不可避免的问题：网站上有多大比例是机器写的。

Cosmic Insights 按创建底层对象的执行者对流量进行归因，将结果拆分为人类用户、Agent 和自动化三类。这回答了大多数团队根本无法回答的问题：由 Agent 生成的内容是在赢得关注，还是只是在填充索引？

在扩大一个 Agent 规模之前运行那份报告，并把它放到你流量审查的同一节奏上。一个每月生成三十篇文章但总计流量还不如三篇人工文章的 Agent 是成本，而解决方案通常是更窄的范围而不是更大的量。

转变四：内容模型做你不再有时间做的编辑工作

内容模型是唯一对每个写作者一视同仁的护栏，无论人类还是机器。必填字段对所有人都是必填的。有五个选项的选择字段不能用第六个答案。你移到模型里的每条规则都是你再也不必写的审核评论。

值得编码到模型而不是提示词里的东西：

必填的 SEO 字段。如果 seo_title 和 seo_description 是必填的，没有 Agent 能在没有它们的情况下发布文章。

字符限制。元描述上的 maxlength 在写入时就强制执行限制。

用选择选项替代自由文本。分类、内容类型和销售漏斗阶段应该是封闭集合。

一个验证字段。对于任何引用第三方的内容，必填的 last_verified 日期让过时变得可见。

必填的关系。每篇文章上的作者引用意味着归因总是被捕获的。

每一条都将你手工写的审核评论变成了 Agent 在对象保存前必须解决的验证错误。鉴于写权限是跨 bucket 而不是按类型作用域的，模型做的强制执行工作比大多数团队意识到的要多。

需要警惕的失败模式

一旦 Agent 量上升，四个模式会反复出现：

近似重复内容。两个 Agent，或者同一个 Agent 的两次运行，生成了针对同一查询的文章。它们随后在搜索中相互竞争。在委托任何新内容之前先搜索你自己的 bucket。

自信满满的过时第三方声明。一个 Agent 重用了一篇旧草稿中的竞争对手价格或功能限制。修复这条规则很简单：关于另一个产品的任何声明必须在写那个句子的同一次运行中对照该供应商的实时页面重新验证。

捏造的具体性。没有任何来源支持的整数、基准数字和客户数量。要求每个数字旁边附上链接。

偏离品牌语调。单独看没问题，集合起来能被识别为机器输出。保存一个明确的禁用句式列表并对照它检查草稿。

第五个值得命名，因为它在我们写这篇文章时被我们撞上了：一个 Agent 从记忆而不是从当前文档中描述你自己产品的能力。这篇文章的第一个版本声称 Cosmic 可以将对 Agent 的写权限作用域限定到单一对象类型。实际上不能。把应用于竞争对手的同一验证规则应用到你自己产品上。

每一个失败模式都是在发布前设置关卡而不是在修正后进行的论据。

这对人员配置意味着什么

有趣的结果是团队的成长方式不是你预期的那样。产出上升，人数持平，剩下的角色转向编辑、验证和决定委托什么。

当 CMS 不再需要开发者来做日常变更时，客户描述了同样的模式。正如 FINN 联合创始人 Maximilian Wuhr 所说："Cosmic 让我们永远不需要让开发者在网站后端改任何东西。"

如果你确实要增加一名审核者，成本是可预测的。Cosmic 套餐包含一定数量的团队成员（Free 包含 2 人，Builder 3 人，Team 5 人，Business 10 人），额外用户每位每月 29 美元。当前套餐详情在定价页上。

如果你正走向这个比例，有效的顺序是：先收紧内容模型，再让草稿成为默认设置第三，构建审核队列第四，然后才添加 Agent。

Cosmic 为所有这四步提供了所需的各个部分。无头 CMS 提供内容模型和验证，REST API 和 TypeScript SDK 提供审核界面，MCP 服务器将 Claude、Cursor 或任何 MCP 客户端直接连接到你的内容，而 Insights 告诉你这一切是否有效。如果你想要这一切背后的具体权限控制，我们记录了每一个以及如何验证它。

从 Cosmic 账户开始免费使用，无需信用卡。

最初发布于 cosmicjs.com。