科技周刊 第 2 期：代理开始进入真实工作流，底层系统也跟着重写
2026-04-03 这期值得看的是，多代理协作、MCP、AI 缓存和代码沙箱这些过去像概念的东西，正在变成正式工程层。
这一期最明显的变化，不是哪个模型又刷新了分数，而是越来越多团队开始把 AI 当成一类真正的系统用户来对待。产品侧，工具开始学会拆任务、并行推进、接手复杂服务流程；基础设施侧，数据库、缓存、沙箱和安全系统也都在被迫重写，去适应代理、爬虫和自动化程序这种新的流量结构。
如果把这期内容浓缩成一句话，大概就是：AI 不再只是一个聊天框里的能力展示，而是在往真实工作流、真实权限、真实成本和真实基础设施里落。
本周话题：AI 流量已经大到开始改写缓存层
来源：Cloudflare Blog
Cloudflare 这篇文章最值得记住的，不是“AI 很热”这种空话，而是一个很具体的工程信号：它说自己网络里的自动化流量已经占到 32%，而 AI crawler 和 agent traffic 又和传统的人类访问很不一样。它们更并发、更偏长尾、更像系统性扫库，而不是很多人反复点同一批热门页面。对缓存系统来说，这意味着过去那套围绕“热点内容复用”建立起来的优化假设，开始失灵。
文章里还提到一个很直观的例子：Wikimedia 因为机器人抓取，多媒体带宽一度增加了 50%。这说明问题已经不是“要不要服务 AI”，而是如果继续把 AI 流量和真人流量塞进同一套缓存策略里，站点最终会被迫在两种用户之间做取舍。
真正值得跟踪的，是 Cloudflare 明确在讨论为 AI 访问单独设计缓存层、替换缓存淘汰算法，以及重新定义什么叫“命中率”。这类变化看上去离普通用户很远，但它最后会传导到所有产品上：页面是否更慢、成本是否更高、站点是否愿意继续开放给机器访问，都会受影响。
原文链接：Why we're rethinking cache for the AI era
产品动向
1、多代理协作开始从演示视频走进开发工具
来源：GitHub Blog
GitHub 给 Copilot CLI 加上的 /fleet，本质上是在把“一个 agent 回答一个问题”升级成“一个 orchestrator 把任务拆开后派给多个 agent 并行执行”。官方文章里写得很直白：主 agent 会先拆解工作项、识别依赖、决定哪些可以并发，然后把子任务分发给不同 sub-agent，最后再把结果收回来。每个 sub-agent 有自己的上下文，但共享同一份文件系统。
真正重要的不是多开几个 agent，而是编码助手开始从聊天式接口变成任务调度器。以后开发工具的差异，可能不再主要体现在“回答质量”上，而会越来越体现在它能不能拆任务、管依赖、收敛结果，以及在团队真实代码库里稳定跑完一整段流程。
原文链接：Run multiple agents at once with /fleet in Copilot CLI
2、银行客服开始从问答机器人走向 AI 客户经理
来源：OpenAI Blog
Gradient Labs 这篇案例的有意思之处，不是“银行也在用 AI”这种结论，而是它把 AI 放进了一个很难犯错的场景。文中提到，这套系统用 GPT-4.1 和 GPT-5.4 mini、nano 去处理银行客服流程，语音场景延迟大约在 500 毫秒，并且靠一个中央推理代理去协调多个专用技能和 15 套以上的 guardrail。它追求的不是聊天顺滑，而是低延迟、高可靠、能落在 SOP 里的执行能力。
这个方向值得看，是因为很多人还把 AI 客服理解成“把 FAQ 换成大模型”，但银行这种场景已经在逼着产品往另一边走：不是回答器，而是带权限、带边界、带审计要求的流程执行层。只要这条路跑通，接下来会被重做的就不只是客服。
原文链接：Gradient Labs gives every bank customer an AI account manager
3、AI 开始接手那种最容易跨团队扯皮的流程
来源：InfoQ
GitHub 这条案例很有代表性。它不是在讲 AI 写代码，而是在讲 AI 怎么管理无障碍反馈这类跨产品、设计、工程和支持团队的流程。整套系统基于 GitHub Actions、Copilot 和 Models API，把分散的反馈先统一收口，再让 AI 去判断严重程度、补齐 WCAG 相关元数据、分发到对应团队，最后再由人工审核关键标签。官方给出的数据也很硬：Copilot 能自动补全约 80% 的结构化元数据，90 天内解决反馈的比例从 21% 提升到 89%，整体处理时长同比下降了 60% 以上。
这类信号比“AI 帮你写函数”更值得看。因为真正昂贵的组织成本，很多时候不是敲代码，而是分类、转派、对齐、跟进和复核。谁先把这些中间流程做成半自动化，谁就更有机会把 AI 变成组织能力，而不是个人插件。
原文链接：Github Integrates AI to Improve Accessibility Issue Management and Automate Feedback Triage
新想法
1、MCP 开始从“会不会用”变成“怎么治理”
来源：InfoQ
Pinterest 把 MCP 做成公司内部生产系统，是这周最有代表性的一个信号。它不是停留在 demo，而是做了面向真实工程团队的 domain-specific MCP server、中央注册表、审批链路和权限治理，再把这些能力接到聊天工具、IDE 和内部开发环境里。按报道里的数据，这套系统已经有 844 个活跃用户、每月大约 66000 次调用，节省约 7000 小时的人力时间。
这件事真正重要的地方，是它把 MCP 的讨论重心从“接口酷不酷”推进到了“怎么注册、认证、审批、审计”。过去大家讨论 agent tool use 时常常停在连接成功那一步，但企业里真正能不能用，往往取决于谁能把这套东西变成一个可治理的平台层。
原文链接：Pinterest Deploys Production-Scale Model Context Protocol Ecosystem for AI Agent Workflows
2、持久化代理的竞争，开始脱离单轮对话体验
来源：The New Stack
The New Stack 把 OpenClaw 和 Hermes Agent 放在一起比较，其实点出了一个很核心的问题：下一代 AI assistant 到底是不是还应该按“会话”来理解。OpenClaw 强调跨渠道存在、外部集成和技能生态，Hermes 则更强调持续记忆、用户画像和长期学习。两条路线不一样，但都在试图解决同一个老问题：现在的大多数助手，一旦会话结束，几乎就等于重新开始。
这类产品值得持续跟踪，因为它们在改写用户对 agent 的默认预期。未来大家也许不会再问“这个助手回答得像不像人”，而会先问“它记不记得我、会不会持续进化、能不能跨工具接着干活”。一旦预期变成这样，代理产品就不再只是聊天产品的一个分支。
原文链接：OpenClaw vs. Hermes Agent: The race to build AI assistants that never forget
3、数据库给代理开放能力，问题已经不是 API 设计而是边界设计
来源：The New Stack
pgEdge 这篇文章有意思的地方，在于它公开站队：让 AI agent 访问数据库，更适合通过 MCP，而不是继续把问题理解成传统 API 暴露。它们做的 MCP server 支持 Postgres 14 以上版本，默认走只读模式，能做 schema introspection，也能通过 TSV 和上下文压缩把 token 成本压下去。文章里给出的说法是，这套方式能减少大约 30% 到 50% 的 token 开销。
这里面最值得看的一点，是数据库厂商已经开始按“代理用户”的思路重写交互层。等 agent 真正成为数据库的常见访问者后，大家比拼的重点不会只是吞吐和 SQL 能力，而会变成权限模型、上下文暴露粒度、成本控制和可审计性。
原文链接：Why pgEdge thinks MCP (not an API) is the right way for AI agents to talk to databases
4、AI 评测可能该从“打榜”切回“协作”
来源：MIT Technology Review
这篇文章提出了一个很重要、但这两年常被忽略的问题：我们仍然太习惯用“模型能不能赢过一个人”来评估 AI，好像只要把考试题、代码题、数学题做得更高分，产品价值就自然更强。但真实世界里，AI 很少是孤立完成任务的，它通常嵌在团队、流程和工具链里，影响的是协作方式、错误暴露、责任分配和决策节奏。
这类判断的价值，在于它提醒大家别只盯着 leaderboard。接下来真正有意义的评估，可能要看人和 AI 一起工作时，组织是否更快、更稳、更容易发现错误，而不是只看模型单独做题有多强。
原文链接：AI benchmarks are broken. Here’s what we need instead.
新底座
1、给 AI 生成代码配沙箱，正在变成云平台的新卖点
来源：InfoQ
Cloudflare 把 Dynamic Worker Loader 推到 open beta，本质上是在回答一个越来越现实的问题：当 agent 开始频繁生成并执行代码时，谁来提供足够快、足够便宜、又足够隔离的运行环境。按报道，这套能力基于 V8 isolate，可以在毫秒级启动、只占用几 MB 内存，官方说法是相对容器大约快两个数量级、内存效率也高得多。
这件事值得看的原因很直接。只要“让 AI 先跑一下这段代码”开始变成常见操作，代码执行环境就会从后台能力变成前台竞争力。未来 developer platform 的差异，可能不只是谁模型接得多，还包括谁能更安全地托住 agent 的执行。
原文链接：Cloudflare Launches Dynamic Workers Open Beta: Isolate-Based Sandboxing for AI Agent Code Execution
2、直播基础设施的优化，开始直接回到体验和成本
来源：Netflix TechBlog
Netflix 这篇文章讲的是一个看上去不花哨、实际上非常关键的改动：从 2026 年 1 月 26 日开始，Netflix 所有 Live 活动都从 CBR 切到 VBR 编码。这个变化的结果很具体，官方披露平均能减少大约 15% 的字节量、把 rebuffer per hour 降低约 5%，并把峰值分钟流量压低约 10%。但代价也很明确，VBR 让流量峰谷更不稳定，容量规划和调度策略都得跟着重做。
这类文章的价值，在于它提醒人们：很多真正影响用户感知的创新，并不长在前台界面上，而是长在这些极其工程化的细节里。视频产品的竞争，最后往往是由这类看不见的优化慢慢拉开差距。
原文链接：Smarter Live Streaming at Scale: Rolling Out VBR for All Netflix Live Events
3、客户端安全也开始用“多阶段 AI 判断”来降误报
来源：Cloudflare Blog
Cloudflare 把更高级的 Client-Side Security 检测开放给更多用户，这条新闻最有意思的地方不是“用了 AI”，而是它怎么用。它先用图神经网络去做高召回的脚本风险识别，再让 LLM 做第二层判断，目的是把那种让安全产品很难用的误报压下去。官方给出的数字很激进：针对唯一脚本的误报率从 1.39% 降到 0.007%，接近 200 倍改善。
这个方向值得看，是因为安全产品长期有一个老问题：越想抓得全，越容易把团队淹没在噪音里。现在如果多阶段模型真能在保持发现能力的同时显著降误报，那安全工具的可用性会被重新定义，而不只是检测率被重新定义。
原文链接：Cloudflare Client-Side Security: smarter detection, now open to everyone
这一期如果要浓缩成一句话，就是：AI 真正进入生产环境以后，变化最大的往往不是聊天体验，而是那些以前被认为太底层、太工程、太后台的东西。