MCP 最早被很多人理解成“让大模型连接外部工具的协议”。这个理解没错，但已经不够了。最近 MCP 社区围绕 skills、apps、transport、conformance tests 的讨论，说明它正在变成更底层的东西：Agent 应用的边界定义方式。 这对开发者有实际意义。因为 Agent 应用一旦从玩具 demo 走向真实工作流，最大的问…

很多开发者第一次做 Agent 应用时，关心的是模型能不能调用工具。等真正上线以后，问题会变成另一个更朴素的版本：它调用得贵不贵，慢不慢，稳不稳。 OpenAI 最近在 Responses API 上提到几个值得注意的方向：工具搜索、长上下文压缩、计算机使用工具，以及通过 WebSocket 优化 agent 工作流的延迟。表面看是 API 功能更…

过去一年，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、持续执行任务”。这不是噱头层面的升级，而是工作流层面的变化。但我先把结论摆在前面：未…