服务智能体流量

你已经在服务它了，而你的仪表盘正在把两个总体平均在一起。

这不是预测。观测着相当一大片网络的 Cloudflare Radar 在 2026 年年中录得：自动化请求占 HTML 流量的 57.5%，人类占 42.5%——这个交叉点比它自家公布的预测早了整整一年。HUMAN Security 的基准报告则把智能体式流量（指会采取行动的智能体，而非只收集文本的爬虫）的同比增长放在了千分位百分比的量级。值得与之并排看的，还有 Cloudflare 2026 年 5 月对 AI 爬虫目的的拆分：51.8% 的请求用于训练，只有 9.3% 用于搜索——它说的是，抵达一个公开端点的自动化，大多数并不打算把任何人送回来。

把这些数字当作数量级而非常数；不同行业、以及你有多少表面是公开的，会让这个配比差得非常远。但运维层面的后果不取决于具体数值：

• 你盯着的每一个延迟分位数，如今都是混合的。智能体发出的是一串没有思考间隔的小读取；人类发出的是带停顿的稀疏请求。在两者之上算出的 p99，是一个关于两者谁都不是的数字，而且它会在配比变动时移动——不是在你的服务变动时。
• 转化与活跃指标继承了同一个毛病。一个按会话计数的漏斗会把智能体会话算进去，而一个读了六个页面才回答一个问题的智能体，看上去就是一个高度投入、转化率为零的读者。
• 基于人类季节性做的容量预测会失效。智能体流量没有傍晚的低谷，也没有周末，而且它以扇出形状的突发抵达——看起来像攻击，其实不是。

在任何策略决定之前，第一件事是打标签：把每个请求归类为人类、已验证智能体、未验证自动化，并把每一张仪表盘按它拆开。本页后面几乎每一个决定都需要这个标签先存在；而团队们一再发现，「这里面有多少是智能体」这个问题他们根本答不上来。

智能体的重试就是它的控制循环，所以你的 429 是一条它听不进去的建议。

撞上速率限制的人会走开。带指数退避的浏览器试几次就放弃。而循环中的智能体会把一次失败的工具调用当成一个步骤，对它做一番推理，然后再调一次——而且可能已经把请求改写成了能绕开你原有去重逻辑的样子。这个循环终止于模型认定自己成功，或者它的 harness 步数预算用尽，而这两者都不是你的速率限制。

这把「限流器是干什么用的」整个翻转了过来。它曾是一种带塑造行为副作用的容量控制；面对智能体流量，它首先是一条通信通道，而你怎么塑造这个响应，决定了调用方是退避还是猛捶：

• 永远带上 Retry-After，并且让它是真的。智能体能遵守一个数字。它没法从一个光秃秃的 429 里推出一张时刻表，而模型的先验是立刻再试一次。
• 在响应体里区分「太快了」与「配额用完了」，不要只靠状态码。这两者要求的行为完全相反——等一等，还是停下来找人——而它们都以 429 抵达。一个机器可读的原因码，就是「暂停的智能体」与「卡死的智能体」之间的差别。
• 永远不要为永久性状况返回一个可重试的状态码。因为缺了一个必填字段而发出的 503，买来的是一个由你自己付费的无限循环。永久性失败必须是 4xx，并且必须说清是哪个字段。
• 能整形就别拒绝。把一个请求排队两秒，成本是占住一条连接；拒掉它，成本是一百毫秒后这个请求再来一遍，外加调用方为「决定要重试」烧掉的模型 token。面对由循环驱动的客户端，看起来便宜的那个选项往往是更贵的那个。

这与速率限制与厂商容量里那套纪律是镜像关系——那一篇讲的是你作为调用方的那一侧。两半遵循同一条规则：一个撞上它的东西读不懂的限制，就是一个会被再撞一次的限制。

你的错误信息现在是提示词，所以请把它当指令来写。

一个收到「Invalid request」的人会去翻你的文档。一个智能体会把这串字符放进上下文里然后猜，而它下一次尝试所抽自的那个分布，被你用恰好九个字符影响过。错误响应体是你整个 API 表面上杠杆最大的一段文字，通常也是维护得最差的一段。

什么样的错误能让智能体一轮就恢复，什么样的会再引出三次失败调用，差别在这里：

• 点名字段与约束。「start_date 必须是 ISO-8601 且不得晚于 end_date」是一轮就能恢复的。「日期区间无效」则是抛硬币。
• 说清重试到底有没有可能成功。响应体里一个布尔的 retryable 就能消掉一整类循环。人类从语气里推断这一点；模型无处可推。
• 取值集合小的时候，把它给出来。返回那八个允许的枚举值只花几十个字节，却消掉了一个搜索问题。这与写好工具错误信息是同一套纪律——受众完全一致，因为它越来越就是同一个受众。
• 保持错误码稳定且有文档，因为它们正在被记住。一个在训练数据或工具描述里见过你 API 的模型，对你的错误形状是有先验的。改一个错误码，就是一次对所有调用方同时生效、且没有弃用通道的行为变更。

同样的逻辑再往外推一层。如果你发布了 OpenAPI 描述或一个 MCP 服务端，那份文档对大多数非人类调用方而言就是你真正的文档，而那页散文只是兜底。schema 里描述不足的参数，会产出工具 schema 与契约里编目过的那些失败形态——只不过在这里，吸收那些重试的是你。

写操作需要一份你公布出来的幂等契约，而不是一份你指望对方有的。

智能体流量的读那一侧是容量问题。写那一侧是正确性问题，而且是会产生退款的那一个。一个在写到一半时掉线的智能体，并不知道这次写有没有落地；模型的选项是重试或者去问人，而有史以来每一个 harness 都偏向重试。重复下单、重复工单、重复消息、重复扣款。

你没法从调用方那一侧修好它，因为调用方不归你管。那就把契约公布出来：

• 在每一个会产生变更的端点上接受幂等键，并把它写进 schema 的描述里——模型真正会看到的地方。把键与响应一起存一段明示的时间窗，遇到重复请求时回放原来那份响应。
• 让回放的响应完全一致，状态码也一样。第一次 200、回放时 409，等于在教智能体「出问题了」，而它会试图去修。
• 每个写响应都返回一个稳定的资源标识符。这给了智能体一条「去核对」而不是「再来一次」的路——而只要核对既便宜又显眼，「先核对」是一个你真能拿到的行为。
• 提供一条廉价的回读路径。大多数重复写入本质上是一次失败的读取：智能体确认不了，于是动手了。一个快速、且不计入速率限制的「这件事发生了吗」端点，比任何重试调参都值钱。

这套论证面向内部的版本在幂等与重试；面向外部的差别在于，你必须把契约表达在 schema 里而不是运行手册里，因为读它的那个客户端从没见过你。

识别不了的东西，你既没法定价、也没法配额、更没法豁免。

每一条值得拥有的策略——给付费客户的智能体更高的额度、给匿名自动化更低的额度、给回读端点一个豁免——都需要调用方是可识别的。User-Agent 字符串是自称的，一直以来都只是一种客气。真正有分量的那几套机制，以及它们诚实的边界，在机器人验证与智能体访问里；由此而来的运维决定是这几条：

• 明确决定未验证自动化能得到什么。今天的默认是「它会降级」——更慢、被限流、偶尔被挑战——而这是一条没人写下来、也没人能向一个智能体间歇性失败的合作方解释清楚的策略。把这一档写下来，并且公布。
• 把身份与意图分开。知道一个请求来自某个知名智能体平台，并不告诉你它在为谁行事。一个客户的助理与一个陌生用户的研究智能体，可以从同一套基础设施、带同一个签名抵达，而它们该有不同的额度。需要区分的地方，就要求一份终端用户凭证，并把平台签名只当作一条线索。
• 为工作量定价，而不是为会话定价。按席位、按会话的定价假设每一个背后都有一个人。面对智能体调用方，稳定的计价单位是操作——一次查询、一次写入、一份报告——而这也正是你的成本真正随之伸缩的单位。更宽的论证在定价模型。
• 预期自己会成为别人循环里的一个工具。如果你的端点被包进了一个你管不着的 MCP 服务端，那么消耗你速率限制的那个调用方看不见这个限制，而它所代表的那个用户甚至不知道你存在。请为这样的读者写你的错误文案。

把那四个能说明策略是否奏效的数字量起来。

智能体流量会在两个方向上悄悄失败——你可能在自掏腰包过度服务它，也可能把一个合作方服务不足、直到他们开工单——而两者都不会出现在一张标准仪表盘上。四项测量足以覆盖：

• 按类别、按端点的流量占比。人类、已验证智能体、未验证自动化。按端点分很重要：定价页上的配比与写 API 上的配比是两个不同的产品，答案也不同。
• 4xx 或 429 之后的重试倍数。接下来一分钟内，同一调用方还会发来多少个请求。这是对「你的错误文案有没有起作用」的直接测量，计算成本很低，而且是改进它时能拿到的最快反馈回路。
• 重复写入率。被幂等键合并掉的变更请求，加上那些没带键就到达的近似重复。第二个数字才是会变成退款的那个。
• 按类别的成本。算力、带宽，以及任何下游模型或厂商开销，归到自动化头上而不是归到人头上。没有它，一次由智能体驱动的流量上涨会一路读作「增长」，直到谈毛利的那一天；而钱包耗尽与成本攻击里的风险，在变大之前都是隐形的。