很多人第一次用 Agent 产品，会默认把它当成一个聊天界面：我发一句，你回一句，最好几十秒内结束。但只要任务开始碰到搜索、代码执行、远程工具、长链路推理，这种交互模型很快就不够用了。真正的问题不是模型能不能继续想，而是你的产品能不能承受一个任务跑十几分钟、几十分钟，甚至更久。 这就是我最近特别关注 background mode 的原因。Open…

我一开始以为，所谓云端编码代理，只是把 IDE 里的补全和对话面板搬到浏览器里。后来越看越觉得不是这么回事。真正的变化不在“能不能写代码”，而在它开始接管一整段原本需要人类持续盯着的工程流程：拉代码、看上下文、跑命令、修失败、继续尝试、最后给出可审阅结果。 这件事为什么值得单独写？因为它意味着开发者工具正在从“交互式助手”变成“可持续运行的任务执行…

这两年很多团队做 Agent，表面上看是在升级模型，实际上只是在把 prompt 写得越来越长、把工具列表堆得越来越多、把状态偷偷塞进各种缓存和数据库里。它能跑，但很不稳。 所以我现在看 Responses API 和新一代 Agents SDK，最重要的地方并不是“OpenAI 又发了新东西”，而是它们在把一件长期很混乱的事逐渐收回正轨：Agen…

过去一年做 AI 应用，很像在搭乐高：模型一层、工具调用一层、工作流编排一层、记忆层一层、聊天 UI 一层、部署和监控再来一层。能跑起来当然可以，但拼得越多，后面越像在维护自己的小型集成平台。最近一个很明显的趋势是：统一 AI 应用栈正在开始成形。无论是模型厂商往上做 agent 框架，还是应用平台往下包工具、状态、UI 和部署，大家都在做同一件事…

这两个月，AI 编程圈最不缺的新东西，就是“又一个会写代码的助手”。但如果只把 Codex App 看成 OpenAI 给 ChatGPT 套上的桌面壳子，那就有点低估它了。 我觉得它真正值得关注的点，不是模型更强，也不是界面更花，而是它把多线程软件开发这件事，第一次做成了一个普通开发者也能直接上手的产品：一个项目里并行跑多个线程、每个线程有独立上…

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

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

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

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

如果你最近在做 Agent，最容易踩的坑不是模型不够强，而是流程不受控。一个 agent 会查资料、会调用工具、会写文件，看起来很聪明；但一旦任务稍微变长，系统就会开始出现两个经典问题：一是上下文越跑越乱，二是失败之后你很难知道到底卡在哪一步。 这篇文章不聊空泛概念，直接给一个适合开发者上手的最小实战方向：用 OpenAI Agents SDK 搭…