过去一年，AI 编程工具的叙事一直围绕“模型能力”：谁能写更多代码，谁能一次性修复更复杂的 bug，谁在 benchmark 上多赢几个百分点。但最近 GitHub、OpenAI、Anthropic 一系列面向开发者的动作提醒我们，AI 编程正在从模型竞赛进入工程期。 这个变化对开发者很重要。因为真正影响日常效率的，往往不是模型在理想题目上能不能答…

这两年只要模型上下文一变长，市场上就会周期性出现一种说法：RAG 要死了。现在上下文都到 1M 甚至更高了，文档直接全塞进去不就行了吗？这个说法听起来很顺，但工程上其实站不住。我的判断是：超长上下文会改变知识接入层的设计，但不会替代 RAG，它真正改变的是“接入成本曲线”而不是“信息检索的基本规律”。 这不是抬杠，而是很多团队正在真实面对的架构问题…

MCP 过去最容易被误解成一个“给大模型接工具的协议”。这句话不算错，但已经明显不够了。到 2026 年再看，MCP 更像是在从一个连接协议，慢慢长成一个工具生态的分发层。这件事对开发者的影响，比单纯“又多了一个标准”要大得多。 我的判断是：MCP 现在值得重度关注，但不值得盲目铺摊子。它真正有价值的部分，不在于你能不能在两天里做出一个 MCP S…

这一年再看 Agent，热闹的部分已经不新鲜了。会调工具、会写代码、会多轮对话，这些能力大家都见过了。真正开始拉开差距的，不再是“它能不能做点事”，而是“它能不能把一件事稳定做完，而且中途出错后还能接着做”。 我越来越倾向于一个判断：2026 年值得投入的 Agent 方向，不是继续做一个更花哨的聊天入口，而是做可恢复、可观察、可拆分的任务流系统。…

实战：把一个串行 Agent 循环改造成低延迟执行器：Node.js + Responses API + WebSocket 如果你最近在做 coding agent、自动化修复脚本，或者任何“模型 + 工具调用 + 多轮继续”的应用，大概率已经感受过一个问题：模型本身不算慢，慢的是整条执行回路。一次任务里要读文件、跑命令、回传结果、继续推理，只要…

Assistants API 进入退场期后，独立开发者为什么该尽快把心智切到 Responses API 很多开发者做产品时有一个惯性：只要老接口还没彻底下线，就先不迁。这个习惯在一般业务系统里未必有问题，但在 AI 基础设施上，往往意味着你会持续把新能力挡在门外。最近 OpenAI 已经明确给出时间表：Assistants API 已被弃用，并计…

AI 编程的下一场竞争，不是谁更聪明，而是谁把“等待时间”干掉了 这两年大家讨论 AI 编程，最容易盯着模型能力看：代码补全更准了没有，复杂任务能不能一次做完，多文件修改会不会把项目搞坏。问题当然重要，但到了 2026 年，一个更现实的瓶颈已经浮出水面：很多时候，开发者感知到的“慢”，已经不主要来自模型不够聪明，而来自整条 agent 执行链路太笨…

每隔一段时间，技术圈都会把同一个问题重新问一遍：AI 越来越强，未来还会有人手写代码吗？这个问题之所以总能引发讨论，不只是因为它吓人，而是因为它确实碰到了现实。过去两年，AI 编程已经从“帮你补几行代码”，走到“能读仓库、改多文件、跑测试、提 PR、接 issue、持续执行任务”。这不是噱头层面的升级，而是工作流层面的变化。但我先把结论摆在前面：未…

过去两年，大家对 AI 编程的熟悉路径大致是这样的：先是代码补全，再是对话式问答，然后是 IDE 里的 agent mode。很多人以为这已经差不多了，无非是模型越来越能写代码。可 2026 年更值得注意的变化，不是“写得更像人”，而是 AI 编程工具开始从实时协作走向任务委派。GitHub 最近围绕 Copilot coding agent 的连…

MCP 这半年很火，火到很多人已经默认它会成为 Agent 世界的“USB-C”。这个比喻传播很快，因为它足够顺口：统一接口、统一协议、统一生态，模型终于可以不再为每个工具写一套私有集成。问题是，工程世界里所有“万能插头”的故事，都有一个后半段：统一连接方式会降低接入成本，也会同步放大同一类设计缺陷的传播速度。最近安全研究团队公开披露的 MCP 相…