很多开发者第一次做 Agent 应用时，关心的是模型能不能调用工具。等真正上线以后，问题会变成另一个更朴素的版本：它调用得贵不贵，慢不慢，稳不稳。

OpenAI 最近在 Responses API 上提到几个值得注意的方向：工具搜索、长上下文压缩、计算机使用工具，以及通过 WebSocket 优化 agent 工作流的延迟。表面看是 API 功能更新，实际上暴露的是 Agent 应用进入生产环境后绕不开的基础设施问题。

工具越多，问题不一定越少

早期 Agent demo 喜欢把几十个工具塞给模型，仿佛工具越多，能力越强。但在真实系统里，工具列表本身会占上下文，工具描述会影响缓存命中，错误工具会制造无效调用，权限边界也会变复杂。

工具搜索这个方向值得关注，因为它承认了一个现实：模型不应该每次都背着完整工具箱上路。更合理的做法，是让模型在运行时发现和选择需要的工具，把大工具面延迟到真正需要时再展开。

长上下文不是万能药

1M token 上下文听起来很诱人，但个人开发者不能把它理解成“以后不用整理上下文了”。长上下文解决的是容量问题，不自动解决相关性问题。把一堆日志、文档、代码、聊天记录全部塞进去，模型依然可能被噪声拖慢，甚至做出错误判断。

更有价值的是压缩和上下文管理：哪些信息保留，哪些信息丢弃，哪些信息转成结构化状态。Agent 应用的长期运行，本质上需要记忆管理，而不是无限制堆 token。

小团队应该怎么做

对小团队和个人开发者来说，现在不必急着追逐所有新 API。更应该先建立几个底层习惯：记录每次工具调用的输入输出，统计 token 和延迟，给高风险工具加审批，把上下文构造逻辑从业务代码里拆出来。

如果一个 Agent 应用无法解释“为什么这次调用花了这么久、为什么用了这个工具、为什么上下文里有这些内容”，它就还不适合承担关键任务。

我的判断是：未来 Agent 应用的竞争，不只是模型能力竞争，而是调用链路治理能力竞争。会写 prompt 的人很多，能把工具、上下文、延迟、成本和权限管住的人会更稀缺。

参考：OpenAI API Changelog、OpenAI《Speeding up agentic workflows with WebSockets》。