AI 生态热点：GPT-5.4 一上，Agent 团队该重写的不是 Prompt，而是工具编排

发表于 更新于 分类于 阅读次数： Changyan： 本文字数： 3k 阅读时长 ≈ 3 分钟
OpenAI 于 2026-03-05 发布 GPT-5.4，并把 1M 上下文、tool search、computer use 与 Codex / API 打通。真正变的不是模型更强，而是大工具集 agent 的上下文成本、权限设计和执行链路都要重算。

如果你把 GPT-5.4 只看成“GPT-5.2 / 5.3 之后的常规升级”，这轮变化很容易被低估。
OpenAI 在 2026 年 3 月 5 日发布 GPT-5.4 时，给出的不只是更强的推理和编码能力，还把几件对 agent 工作流真正关键的东西一起推上来了：

  1. 1M 级上下文
  2. 原生 computer use
  3. 面向大工具集的新能力 tool search
  4. 与 Codex、API、工具生态的更紧密打通

这意味着很多团队接下来要重写的，未必是 prompt，而是工具注册方式、权限边界、执行链路和成本模型。

为什么这次更新值得现在关注

以往很多模型升级，开发者主要关心两件事：

  1. 能力有没有更强
  2. 单价有没有更高

但 GPT-5.4 更值得关注的点在于：
OpenAI 这次同时改动了“模型能力 + 工具使用方式 + 真实执行能力”。

官方发布把 GPT-5.4 定位为面向 agentic, coding, professional workflows 的前沿模型；
API 模型页则把它列成默认 GPT-5.4 版本，支持 1,050,000 上下文窗口、128,000 最大输出，并直接支持 Skills、MCP、Tool search、Computer use、Hosted shell 等工具能力。

这不是“模型更会回答问题”这么简单，而是意味着：

  1. 长任务 agent 可以带着更多状态继续跑
  2. 工具集不必再全部塞进首轮 prompt
  3. 浏览器/桌面自动化能力开始从专项模型走向通用模型能力

它到底更新了什么

1) Tool search：大工具集 agent 的上下文成本开始重算

这次最容易被忽略，但对工程结构影响很大的更新，就是 tool search。
OpenAI 官方解释得很直接：过去给模型上工具时，所有工具定义通常会一次性塞进 prompt。
工具一多，请求会立刻变得更贵、更慢，而且把大量模型可能根本用不到的定义也塞进上下文。

GPT-5.4 的做法变成：

  1. 先给模型一个轻量的工具清单
  2. 需要具体工具时，再动态查到该工具定义并拼进会话

这会直接改变 MCP / connector / 内部工具平台的默认设计。
官方在 MCP Atlas 的 250 个任务、36 个 MCP server 开启的测试里给出的结果是：
把所有 MCP 工具放到 tool search 后，总 token 使用量下降了 47%，准确率保持不变。

一句话：以后大工具集 agent 的关键，不只是模型会不会选工具，而是你的工具目录是否支持“按需检索”。

2) Computer use：通用模型开始接管真实界面操作

OpenAI 把 GPT-5.4 定义为首个具备原生、先进 computer use 能力的通用模型。
它既可以根据截图发出鼠标键盘动作，也适合和 Playwright 这类库配合做代码驱动的界面操作。

官方给出的几个信号都很强：

  1. 在 OSWorld-Verified 上，GPT-5.4 成功率达到 75.0%，高于 GPT-5.2 的 47.3%，也高于文中引用的人类成绩 72.4%
  2. 在 WebArena-Verified 上，浏览器任务成功率继续提升
  3. 开发者可以通过自定义 confirmation policy 调整安全确认强度

这意味着对很多团队来说，浏览器自动化、桌面代理、视觉回归验证，不再一定要拆成“一个代码模型 + 一个专用 CUA 模型”的双模架构。

3) Coding + computer use 开始真正合流

官方还明确提到 GPT-5.4 结合了 GPT-5.3-Codex 的编码优势，并在长任务里能更好地“用工具、迭代、继续推进”。
更值得注意的是，OpenAI 同时放出了实验性的 Codex skill Playwright (Interactive)，用来做 Web 和 Electron 应用的可视化调试。

这个信号很清楚：

  1. 写代码
  2. 跑起来
  3. 自动点界面
  4. 看结果继续修

正在被合成一条更连续的 agent 执行链，而不是四段人工切换的流程。

对开发者工作流的实际影响

这轮更新落到工程层面，至少会改 3 件事。

1) 工具注册方式要从“全量注入”转向“可搜索目录”

如果你还在把几十个函数、几百个 schema、多个 MCP server 一次性塞进系统 prompt，这套结构的边际成本会越来越高。
GPT-5.4 把更合理的方向指出来了：

  1. 工具目录和工具定义分离
  2. 模型先选类目，再拉具体定义
  3. 工具说明支持缓存和按需补充

以后工具平台的竞争点，会越来越像“搜索系统设计”而不是“谁的 prompt 更长”。

2) 评审重点要从 prompt 技巧，前移到权限和确认策略

一旦 computer use 成为通用能力，问题就不只是“它会不会点按钮”，而是：

  1. 哪些操作允许自动执行
  2. 哪些操作必须人工确认
  3. 哪些页面、路径、环境是白名单

也就是说，agent 平台的核心资产会越来越偏向：

  1. confirmation policy
  2. 环境隔离
  3. 审计日志
  4. 工具权限分层

如果这些没有先立起来，computer use 越强，风险只会放大得越快。

3) 成本治理会从“单次请求多少钱”变成“整条执行链多少钱”

tool search 的确能明显压低 prompt 体积，1M 上下文也能减少部分手工拆分。
但另一面是：

  1. agent 能跑得更久
  2. tool yield 和状态切换会更多
  3. computer use / search 等工具调用本身也有额外成本

所以真正需要治理的，不再只是 token 单价，而是：

  1. 每个任务完整闭环的总成本
  2. 每次成功执行平均要消耗多少工具调用和重试
  3. 哪些步骤该自动做，哪些步骤该人工接管

谁应该现在就跟进

这轮更新最值得马上关注的，主要是下面三类团队：

  1. 已经有 MCP、connector 或内部工具平台，工具集越来越大的团队
  2. 正在做浏览器自动化、桌面代理、自动测试、运营自动化的团队
  3. 已经在用 Codex / API 跑长任务，希望把“写代码 + 验证 + 回写”串起来的团队

如果你现在还主要是单轮问答或轻量生成，GPT-5.4 当然也值得评估；
但真正最大的收益，还是会出现在“多工具、多步骤、长执行链”的 agent 场景里。

风险边界与冷思考

这次更新再强，也不意味着几个老问题消失了：

  1. Tool search 降低的是 prompt 负担，不是权限治理难度
  2. Computer use 提高的是可执行性，不是业务判断可靠性
  3. 1M context 放大的是可携带状态，也同样放大了噪声和错误上下文

所以更稳的跟进顺序应该是：

  1. 先把工具目录、权限和确认策略理顺
  2. 再把 computer use 接进低风险、可回放的环境
  3. 最后再评估是否扩大到更长、更复杂的自动化任务

如果一上来就把它直接接到高风险写操作，工程收益很可能会被治理成本反噬。

总结

GPT-5.4 真正改写的，不只是模型能力曲线，而是 agent 工程的默认骨架：

  1. 工具从“全量注入”转向“按需检索”
  2. 自动化从“代码生成”转向“代码 + 界面 + 验证”一体化执行
  3. 成本和安全从 token 优化，转向整条执行链治理

如果你这周只能先做一件事，我最建议的是：
先检查你当前的工具平台是不是还在把所有 schema 一次性塞进 prompt。

因为 GPT-5.4 之后，这很可能已经不是最划算、也不是最可扩展的做法了。

参考来源（一手）

本文永久链接: https://www.mulianju.com/ai-ecosystem-watch/gpt-5-4-tool-search-computer-use-agent-workflow-shift/