agent 经济前夜：58% 流量来自 bot，以及一次 84% 的授权减少

Vercel 网络 58.18% 流量来自 bot，60%+ 部署是 agentic

Vercel CEO Guillermo Rauch 公布了一组流量数据：过去 30 天，整个 Vercel 网络 58.18% 的流量由 bot 发起，2024 年 1 月这个数字是 32%。60%+ 的部署现在是 agentic，2026 年 1 月约 3%。Vercel 自己的文档站点，最多 83% 的 pageview 来自 agent，而且内容为 agent 优化得越多，这个比例越稳定上升。他的判断是，未来几年“直接的”人类互联网流量会变成一个舍入误差。

这组数据值得产品人注意的地方不只是比例大，而是 2026 年 1 月到现在不到一年，部署侧从 3% 到 60%+。文档站点 83% 这个数字说明：面向 agent 的文档优化会直接改变流量结构。如果 Vercel 这个样本有代表性，那么你的 help center、API reference、changelog 的主要读者可能已经不是人。这会反过来影响你写文档的方式：结构、可解析性、状态码语义，可能比人类可读性更优先。但注意这只是 Vercel 一家公司自己的数据，不能直接外推到所有产品。

Anthropic：Claude Code 自动批准 93%，沙箱后权限提示减少 84%

Anthropic Engineering 在《How we contain Claude across products》里给了几个具体数字：telemetry 显示用户批准了大约 93% 的权限提示；OS 级沙箱（macOS Seatbelt、Linux bubblewrap）上线后，权限提示减少了 84%，读允许、工作区内写允许、默认拒绝网络。文章还提到，在 Gray Swan 的 Agent Red Teaming benchmark 上，Claude Opus 4.7 单次尝试的攻击成功率约 0.1%，100 次自适应尝试后约 5–6%；Claude Code auto mode 在执行前捕获约 83% 的过度行为。三个被披露的漏洞都发生在用户同意之前的代码路径，修复方式是延迟解析本地配置直到信任确认之后。

93% 这个数字很刺眼。一个被设计成监督机制的弹窗，实际上变成了橡皮图章。Anthropic 的应对不是继续加弹窗，而是转到 containment：不监督 agent 做什么，而是限制它能碰到什么。这个方向对做 agent 产品的人是个可复用的判断，，如果你的安全策略主要靠“让用户确认”，那你其实没有策略，你有一个平均数。

Managed Agents：把“大脑”从“手”里拆出来，p50 TTFT 降约 60%

Anthropic Engineering 另一篇文章讲 Claude Managed Agents 的架构。早期他们把 session、harness、sandbox 全塞进一个容器，结果容器变成“宠物”：挂了 session 就丢了，出不 responsive 只能手动救。解耦之后，harness 不再住在容器里，容器按需通过 execute(name, input) → string 调用，失败作为 tool-call error 回传给 Claude。harness 本身也变成 cattle，崩了用 wake(sessionId) 重启，从 session log 恢复。凭证从不进入 sandbox：Git 用仓库 token 在初始化时 clone 好，MCP 的 OAuth token 放在 vault 里，经由专用 proxy 调用。改完之后 p50 TTFT 下降约 60%，p95 下降超过 90%。

这篇文章最实用的一句是“harness 编码的是关于 Claude 不能做什么的假设，而这些假设会过期”。他们举的例子是 Sonnet 4.5 的 context anxiety，到 Opus 4.5 就消失了，context resets 变成死重。对做 agent 产品的团队来说，这意味着你的 harness 里每一条 workaround 都该有明确的过期条件，否则它会跟着模型一起变老。

一份 postmortem：一次 system prompt 改动让 benchmark 掉了 3%

Anthropic Engineering 的 Claude Code 质量报告 postmortem 列出三个独立问题：3 月 4 日把默认 reasoning effort 从 high 改成 medium；3 月 26 日的 thinking 清理 bug，本该只清一次却每轮都清，导致 Claude 看起来健忘和重复；4 月 16 日在 system prompt 里加了“tool call 之间文字 ≤25 词、最终回复 ≤100 词”的长度限制，后续 ablation 显示 Opus 4.6 和 4.7 都掉了 3%。三条都已修复（v2.1.116，4 月 20 日）。API 和 inference 层未受影响。他们还提到，back-test 时 Opus 4.7 找到了那个 bug，Opus 4.6 没找到。

这份 postmortem 的价值在于承认了一个很难堪的事实：三个改动每一个单独看都有合理理由（延迟、成本、输出长度），合起来在用户侧表现为“广泛而不一致的退化”。而他们最初的内部 eval 没复现出来。对做 prompt 和 harness 的团队的启发是：system prompt 的一句话就是产品改动，需要走的流程和发版一样。那个 3% 的 ablation 差值是整篇里最该被截图发到团队群里的数字。

你的默认设置，是别人眼里的产品退化

今天这几条材料放在一起，能看到一个共同结构：产品团队用“合理”的局部优化，换来用户侧的体感退化。reasoning effort 从 high 降到 medium 是为了延迟，长度限制是为了 verbosity，thinking 清理是为了 cache 效率。每个决定都有数据支持，每个决定都被用户感知为“变笨了”。

产品人容易低估默认值。用户不会去翻 /effort，也不会去读 in-product dialog 里的理由。他们只会得出一个结论：这东西最近不太行。Anthropic 自己在 postmortem 里写，rollout 后做了多轮 UI 迭代去提示用户可以改，但大多数用户还是留着 medium。

第二个结构是 containment 替代 supervision。93% 的批准率说明“让用户确认”是一种错觉式的安全。把 token 放进 vault、把凭证挡在 sandbox 外、默认拒绝网络，，这些是结构性约束，不依赖用户的注意力。做 agent 产品的人如果还在靠确认弹窗，值得重新想一遍：你的 blast radius 是什么，能不能用环境边界而不是人的耐心来限制它。

第三个结构是 harness 会过期。Managed Agents 团队把 harness 的假设明确写出来，是因为模型换代时那些假设会从保护变成负担。你的 agent 产品里有多少 workaround 是六个月前为了绕开某个模型缺陷加的？如果没人记录它为什么存在，它就会一直留着。

以上是 open letters 的编辑判断，不是任何单一来源的原话。

今天就能做：给你的 agent 写一份“假设过期”审计 prompt

适用于手里已经有 agent 或 Claude Code 类 harness 的团队，尤其是那些积累了不少 workaround 和 prompt 补丁的项目。前提是你手上能看到自己的 system prompt、harness 代码或工具权限配置。

你是我的 agent 产品审计员。下面是我产品的 system prompt、harness 里的 workaround 列表和工具权限配置。请逐条列出：每一项假设了模型“做不到”什么、这个假设最初是为了绕开哪个具体失败、如果模型能力提升这个假设会不会变成负担。对每一项给出一个可检验的过期条件（例如“当模型在 X 任务上不再提前收尾时”），以及一条可以现在就跑的小测试。不要给我泛泛的建议，也不要假设我看过任何外部文档。输出一张表：假设 / 原始失败 / 过期条件 / 测试方法。

这只是一个整理工具，不会自动验证假设是否过期。prompt 里的判断依赖你提供的材料完整度，如果 harness 逻辑散在多处，结果会不完整。涉及生产凭证和权限的配置，先在只读副本或脱敏版本上跑，不要在真实 vault 上操作。

Chief of staff bot 的邮箱名字问题

Peter Yang 提了一个具体的细节：如果你把 Grok Bot 当 chief of staff 用，不要用你自己的名字注册它的邮箱。“Let me copy in Peter to find a time for us”这句话说不通。他的建议是给 bot 另起一个名字，就是你想让这个 chief of staff 被叫的名字。

这是个小点，但它指向一个真实的设计问题：当 agent 代表你出现在邮件、日历、协作工具里时，它以什么身份出现？用你的名字，收件人会收到一封看起来像你自己又在第三人称谈论自己的邮件。产品上，agent 的身份标识是个需要显式设计的东西，不能默认继承用户的身份。