近半年如果你关注 AI 客户端、MCP、Agent Memory、Computer Use 这些关键词，就会发现很多 AI 工具正在从“聊天窗口”变成更完整的 Agent 工作台。

不知道你有没有注意到，从 2025 年年中到现在，Agent 这个词出现的频率越来越高，大有接替 2023 年开始流行的 Chatbot 的势头。

举个例子，你和它说：“帮我加一个按钮。”Agent 改完代码，跑了测试，回复说搞定了。你一验收，发现细节不对，就又补一句：“这里状态管理漏了，再改一下。”

日常开发中我们会常遇到一个问题：某个复杂的 Agent 框架踩了像是路由失效，或是上下文污染的坑，花了数小时定位并修复，顺手写了一篇详细的复盘文档丢进 Wiki。但在下周另一个同事开发新功能时，他依然会踩进同一个坑。

让 Codex 写代码、Claude 做 review、另一个 Agent 补测试，听起来像个完美的 Agent 协作团队。但现实往往很滑稽：因为它们运行在各自独立的会话窗口、产品形态或执行环境里，甚至可能来自不同的厂商，彼此之间无法直接共享会话、交换状态 。最后居中粘贴 JSON、手动在各种终端和会话框里搬运状态和上下文的，只有你。

问题大概率不出在“有没有地方存东西”，而是这些信息根本没被管理好。长任务会不断冒出新线索、新状态、新经验，如果只是一股脑往文件里堆，用不了多久就会重复记录、旧信息没更新、想查的时候搜不到重点、关键线索被淹没在一堆废话里。

Addy Osmani 上周发表了一篇文章《Agentic Autonomy Levels》，讨论 Agent 在工程实践中该如何分配自主权。借着这篇文章，我们也可以重新看看：Agent 到底应该怎么用，才更稳、更可控。

这周的 AI 世界继续热闹。一边是开发者日常工具的持续进化——Cursor 把 coding agent 带到了手机上，Git 在优化开发体验，模型在变得更长、更快、更便宜。

这不是一句标准化的智能家居指令。它没有说明开哪几盏灯，也没有给出亮度、色温的具体参数。对传统语音助手来说，这很容易变成一次失败的模糊匹配；但在七牛云软件开发工程师张之阳的家里，这句话已经可以被一个 Agent 接住，并完成一条真实系统里的执行闭环。

在 Codex 系列的第一篇 [Vol.01：从跑通 CLI 开始，看懂 Codex 怎么工作] 和第二篇 [让 Codex 读懂开源项目 Typer]中我们先把 Codex CLI 跑起来，又用一个开源项目练习了“读代码”：看目录、找入口、追运行链路、读测试，再尝试做一个很小的修改。

Router 内容计划是由七牛开发者发起的 AI Coding 实践分享计划。我们希望成为连接开发者与开发者的“路由器”：持续收集、整理并分享一线开发者在 AI Coding 中的真实经验，包括工具选择、工作流改造、踩坑复盘和效率实践，让更多人的实践被看见，也让更多开发者可以从中获得参考。

我们平时说 AI 回答慢，一般是遇到这两种情况：一个是问题发出去之后，它隔了一会儿才开始回复；另一个是它已经开始回复了，但输出速度很慢，像是一个字一个字往外蹦。

对个人开发者来说，MCP Server 可能只是本地跑起来的一个小服务；但到了企业环境里，真正有用的 MCP Server 往往都在更封闭的位置：企业内网、私有 service mesh、开发者本机、Kubernetes 集群、VM，或者只能被内部系统访问的业务环境里。

Coding Agent 用久了，规则管理就会变成一个绕不开的问题：哪些内容该放进项目说明，哪些流程得按需调用，哪些动作必须由系统强制执行。

刚刚过去的周末，DeepSeek 发布了一篇关于推理加速的新论文：《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，内容聚焦在大模型推理服务中的一个具体问题：在真实高并发场景下，Speculative Decoding 如何既提升生成速度，又减少目标大模型的无效验证计算？

今天这篇论文「[Agentic Auto-Scheduling: An Experimental Study of LLM-Guided Loop Optimization]」讲的是一个很具体的问题：LLM 能不能参与编译器优化，让程序跑得更快？

我们常用的云端模型可以依赖服务器和数据中心，但手机上的模型就没这么强大的后盾。不仅如此，它还要顾及电池、内存、发热，还有尽量别让用户等太久。

有人做了猫猫版 Pokémon GO，有人想象 Claude Code 如果生在 2010 年会长什么样，还有人做了一个 GitHub 账号毒舌评分器。

大多数人打开 Kimi，只是把它当成一个聊天框。输入一个问题，等它回答，然后关掉页面。当然这用法没毛病，但 0xMovez 给出了他的 Kimi 最佳实践，在本文中我们将一同感受他是如何让 300 个 Agent 一起干活，并让 Claude 当“包工头”验收成果的。

当我们聊起 Agent，或者阅读相关内容时，经常会看到一个词：MCP。它看起来像一个偏底层的技术名词，我们可以先来简单地记住这样一句话：MCP 是一套让 Agent 连接外部资料和工具的通用方式。

上周，在介绍 bugfix 小工具 Superlog（这里需要公众号的链接）：[链接]，热心群友 Frank 提到了一个小工具 SkillOpt，表示它能把 Skill 当作模型来训练，基于方法论来训练你的 Skill。

Warp 创始人 Zach Lloyd 给了一个更工程化的例子：用 GitHub Issues 做一个自我改进的 Issue 分诊系统。这个项目的核心思路是：先让 Agent 按照一个 Skill 去处理新 Issue，再让另一个 Agent 定期读取人类反馈，把这些反馈整理成可复用规则，最后通过 PR 更新原来的 Skill 文件。

今天解读的这篇论文叫 TokenPilot: Cache-Efficient Context Management for LLM Agents，作者来自浙江大学、电子科技大学、西安电子科技大学和 HomologyAI。

不知道大家如何处理自己退役下来的手机，可能大多数人都将它们放进了抽屉，在某个日子里拿出来感叹下它曾经服役的日子。Google Research 最近介绍了一个来自 UC San Diego 的研究项目：把退役智能手机里的主板拆出来，重新组装成一个小型计算集群，用来跑一些通用云计算任务。

这期的「周一上线」，有点像 AI 终于不满足于“坐在聊天框里等你提问”了。一边，Cursor、GitHub Copilot 继续把 AI Coding 推向开发工作台；另一边，支付宝、腾讯 WorkBuddy 也开始让 AI 真正替用户跑流程、找服务、发起支付。

世界杯期间，多数人看球的姿势都很相似：两支球队还在进攻阶段，手机可能只是放在一边听个声响；一旦进球出现，大家会立刻点开体育 App：有人刷新比分，有人打开文字直播，有人去看进球回放。当然，也有人冲进评论区庆祝这粒进球，或者把比分截图转发到群里。

要说世界杯球赛最让球迷抓狂的画面，当属进球之后，射门的球员已经冲向角旗区庆祝，观众已经站起来欢呼，转播画面却突然切到裁判：手指耳机，等待 VAR 确认。随后的几秒钟，或者几十秒后，大屏幕打出结果：越位，进球无效。

一边，模型和开发者工具还在继续往真实工作流里走：Gemini 3.5 Live Translate 开始做近实时语音翻译，Kimi-K2.7-Code 开源，DiffusionGemma 探索更快的文本生成，Codex 和 Chrome DevTools 也在继续给 Agent 补浏览器能力。

在大模型自回归生成过程中，模型每生成一个 token，都需要参考此前已经读过的上下文。为了避免每一步都重新计算历史内容，推理系统会把历史 token 对应的 Key 和 Value 缓存下来。上下文越长，这部分缓存就越大。到了 128K、500K 甚至更长的上下文，KV Cache 往往会成为长上下文服务里最沉重的一笔显存开销。

在 Codex 系列第一篇（上篇），我们用一个很小的本地脚本，跑通了 Codex CLI 的基本流程：进入项目目录，启动 Codex，然后让它读文件、写代码、跑命令。