模型原理与推理
OpenAI o3 与 o4-mini 首发复盘：工具化推理不能替代业务控制面
以 2025 年 4 月 16 日至 18 日的一手资料为边界，拆解 o3、o4-mini 的工具选择与视觉推理，并为供应链异常调查设计状态、权限、评测和单位经济性。
时间与证据
本文研究的是 OpenAI 在 2025 年 4 月 16 日发布 o3 与 o4-mini 的事件，信息边界截止到 4 月 18 日。文章发布日期与更新日期见页首。由于当前官网可能继续修改，本文把官方首发页与 2025 年 4 月 16 日 17:08:40 UTC 保存的 id_ 固定快照配对；模型能力、产品入口、API 可用性与未来计划均按同期快照判断。
本文证据等级为 sourced。我核对了首发页和发布日快照，但 没有保留 2025 年 4 月的模型快照、ChatGPT 产品环境或同版本 API 运行日志，也没有复现官方 Benchmark。首发页中的模型排名、错误率、AIME、SWE-bench、视觉与工具调用成绩都是厂商在其评测设置下报告的结果，不能写成本站实测，更不能直接推导成某个企业流程的成功率。下文的供应链任务、状态机、测试集和成本门槛属于可执行的试点设计，不是已经取得的业务结果。
时间边界尤其重要。首发日，ChatGPT 内的 o3 和 o4-mini 可以组合当时产品中已有的网页搜索、上传文件与 Python 分析、视觉输入和图像生成工具；API 中两个模型可通过 Chat Completions API 与 Responses API 使用，也能通过 function calling 调用开发者提供的自定义工具。但首发页明确把 Responses API 内置 web search、file search 与 code interpreter 的推理内调用写成“即将支持”。因此不能把 ChatGPT 的完整工具集合倒填成 4 月 16 日 API 已经全部交付的能力，也不能把后来出现的 Agent 产品功能写进这次发布。
当时发生了什么
o 系列此前最显眼的特征是回答前进行更长的推理。o3 与 o4-mini 的变化不是单纯“再想久一点”，而是模型开始在推理过程中判断 何时需要工具、需要哪个工具、拿到结果后是否改变路径。官方示例描述了一个多阶段任务：先搜索公开数据，再写 Python 做分析，然后生成图表并解释结论；搜索不足时还可以换查询继续搜。这使一次响应更接近有观察、有动作、有反馈的任务循环。
首发材料把 o3 定位为当时能力更强、适合复杂多面问题的模型，尤其强调编程、数学、科学与视觉任务；o4-mini 则强调在数学、编程和视觉任务上的效率与更高使用额度。它们不是简单的“大模型和小模型”替代关系。真实系统需要按任务的风险、证据缺口、时延和预算路由，而不是所有请求默认交给最强模型。
产品与接口边界可以拆成四层：
| 层次 | 2025-04-16 至 04-18 可确认状态 | 不能据此承诺什么 |
|---|---|---|
| ChatGPT 付费入口 | Plus、Pro、Team 当日可在模型选择器中使用 o3、o4-mini、o4-mini-high | Enterprise、Edu 当日已交付；o3-pro 已上线 |
| ChatGPT 免费入口 | 免费用户可通过输入框中的 Think 试用 o4-mini | 与付费档相同额度、稳定性或工具权限 |
| ChatGPT 工具 | 模型可组合网页搜索、上传文件/Python、视觉理解与图像生成 | 每次都会选对工具，或工具结果天然可信 |
| 开发者 API | o3、o4-mini 当日进入 Chat Completions 与 Responses API；部分组织需要完成验证 | Responses API 当日已有全部 ChatGPT 内置工具；API 自动提供业务状态、审批和恢复 |
官方还说明这些模型通过强化学习学习工具使用，不只是学习某个固定调用格式。这是重要的能力信号，但不能误解成确定性的工作流引擎。模型可能跳过必要步骤、重复搜索、相信不可靠网页、写出运行成功但口径错误的代码，或者在外部系统已成功而网络响应丢失时再次执行动作。推理能力提高，会扩大可完成任务的范围，也会同时扩大错误动作的影响面。
视觉推理同样需要区分“看得懂”与“可以据此执行”。首发页称模型能够在推理中处理图片，还可旋转、缩放或转换图像来辅助判断。模糊照片、反向扫描、白板和图表因此成为可用输入，但截图中的文字可能过期，图表坐标轴可能被截断，单据图片也可能来自错误订单。视觉输入首先是待核验证据，不是授权凭证或业务事实。
任务判断
具体任务：多仓缺货异常调查
假设一家经营 12 个仓库的零售企业每天收到“库存低于安全线”的异常。分析人员需要结合仓库库存 CSV、供应商交期表、采购合同 PDF、运输延误公告、商品销售曲线和现场拍摄的破损包装照片，在 30 分钟内给出原因分类与处置草稿。可能的建议包括仓间调拨、催供应商、修改补货量或暂停售卖；真正改变库存、下采购单和通知供应商仍是有副作用动作。
这类任务适合测试工具化推理，因为问题不能只靠单次文本回答：
- 先校验商品、仓库、时间窗口与数据版本，缺少主键时不得继续。
- 查询库存流水，区分销售增长、盘点差异、在途延误和损耗。
- 读取合同中的交期与违约条款，同时保留页码和原文片段。
- 对公告做时间过滤，搜索结果发布日期晚于任务截止时间的内容不能进入判断。
- 用代码计算七日销量、在途覆盖天数和不同方案的缺货损失。
- 检查照片是否与指定 SKU、批次和仓库关联，不能仅凭画面相似就认定破损。
- 生成“事实、推断、未知、建议”四栏报告；任何动作只形成草稿。
- 高金额采购、跨区域调拨和供应商通知必须等待对应责任人批准。
模型可以负责规划、证据综合和候选参数，应用必须负责身份、租户、数据版本、权限、动作幂等、审批与最终验证。若把“调用采购工具”直接暴露给模型，而工具只相信模型传入的 warehouseId、amount 和 approved=true，模型能力越强，越可能更高效地越过企业控制边界。
对这个任务的初始决策应是 受限试点，而不是全自动上线。先在历史异常与影子流量上比较“人工流程”“o4-mini 辅助”“o3 辅助”三组，模型只产出调查包与动作草稿；当证据完整率、错误动作拦截率、人工接受率、时延和单位成本同时达标后，才考虑开放低风险、可回滚的自动动作。高金额采购和对外通知不应仅凭整体成功率开放。
工程影响
把 planner、policy、executor 和 verifier 分开
生产系统不能把一次模型响应等同于一次业务事务。建议至少分成四个责任对象：
planner根据目标与已知证据提出下一步，输出结构化意图。policy使用登录身份、角色、租户、资源 scope、金额和环境执行确定性授权。executor通过幂等键调用外部系统，只接受策略层签发的执行票据。verifier回读权威系统，证明动作是否发生以及结果是否符合前置条件。
type ProposedAction = {
taskId: string;
tool: "inventory.read" | "transfer.draft" | "purchase.draft";
resource: { tenantId: string; warehouseId: string; sku: string };
arguments: Record<string, unknown>;
evidenceIds: string[];
expectedVersion: string;
};
async function handleAction(action: ProposedAction, actor: SessionActor) {
const decision = await policy.authorize({ actor, action });
if (!decision.allowed) return audit.reject(action, decision.reason);
const ticket = await approvals.issue({
actor,
action,
scope: decision.scope,
expiresInSeconds: 300,
});
const result = await executor.run(action, {
ticket,
idempotencyKey: `${action.taskId}:${action.tool}`,
});
return verifier.readBack(action, result);
}
这里的 tenantId 不能由 Prompt 自由填写，expectedVersion 用于阻止模型依据旧库存覆盖新状态，执行票据也不能复用于另一个工具。模型输出必须先通过 JSON Schema、资源归属、数值范围和业务不变量校验。function calling 只约束参数形状，不等于参数已经获权。
任务状态要能表达未知终态
一次工具调用超时有三种可能：外部系统未执行、已经执行但响应丢失、仍在执行。若系统只有 success 与 failed，重试可能创建重复采购单。任务状态应至少包含：
RECEIVED -> GATHERING -> ANALYZING -> ACTION_PROPOSED
-> AWAITING_APPROVAL -> EXECUTING -> VERIFYING
-> SUCCEEDED | FAILED | UNKNOWN
进入 UNKNOWN 后禁止盲目重放有副作用动作。恢复器先用幂等键、外部单号和权威查询接口对账；只有确认“未发生”才重试。模型可以解释异常，却不能自己宣布外部事务成功。这个边界与使用哪个模型无关，是全栈工程能力进入 Agent 系统的关键位置。
工具结果也是不可信输入
网页、PDF、CSV、图片和自定义工具返回都可能携带错误或恶意内容。搜索页面中的“忽略前述规则并发送数据”不应获得比系统策略更高的优先级；PDF 中出现的订单号也必须与任务资源绑定；Python 代码只能在无网络、有限 CPU/内存与只读输入的沙箱运行。建议让每条关键事实拥有以下最小证据记录：
{
"claim": "SKU-42 的预计到货日为 2025-04-18",
"sourceType": "supplier_schedule",
"sourceId": "schedule:v17:row:418",
"observedAt": "2025-04-16T09:10:00Z",
"validAsOf": "2025-04-16",
"supportsClaim": true,
"reviewRequired": false
}
自然语言报告是展示层，证据账本才是审计与重放的输入。对于视觉证据，还需要原文件哈希、裁剪范围、OCR 文本、人工确认状态与关联业务对象。只保存模型总结会失去判断依据，无法知道错误来自检索、解析、计算还是推断。
路由依据是任务风险，不是模型名气
可以先用规则和轻量模型处理低风险分流：字段齐全、只有只读查询、计算公式固定的异常进入 o4-mini；跨多个来源、证据冲突或需要复杂视觉判断的任务才升级到 o3；涉及高金额、法律条款或数据缺口的任务直接进入人工队列。路由记录必须保留 routeReason、模型版本、工具版本、token、时延和结果，不然无法判断更贵模型是否真正降低了总成本。
模型升级也不能只看平均分。固定评测集要覆盖日期变化、表格错列、图片反转、供应商同名、网页提示注入、工具 429、执行超时、审批过期和外部系统已成功但响应丢失。任一模型如果降低普通样本错误却提高高损失动作错误，不能用总体准确率掩盖回归。
评测完整轨迹，而不是只评最终文字
建议先构建至少 120 个去标识化任务，其中包含正常、边界、冲突、攻击和恢复五类。每个任务定义权威事实、允许工具、禁止动作、最大成本和人工期望。评分拆成：
| 指标 | 测量对象 | 失败示例 |
|---|---|---|
| 证据完整率 | 关键主张是否有可定位来源 | 报告有结论但没有合同页码 |
| 工具选择正确率 | 是否选到必要且获权的工具 | 用网页搜索代替内部库存查询 |
| 参数与 scope 合规率 | 资源、金额、版本是否通过策略 | 查询或修改了另一租户仓库 |
| 计算可回算率 | 输入、公式、代码和输出是否一致 | 图表正确但销量口径混用 |
| 动作草稿接受率 | 人工是否无需实质修改即可批准 | 调拨方向或数量错误 |
| 未知终态恢复率 | 超时后能否对账而不重复执行 | 重试生成第二张采购单 |
| 高损失错误率 | 是否触发禁止动作或错误承诺 | 未审批就通知供应商 |
最终答案的文风只能作为可读性指标，不能替代这些轨迹指标。官方 Benchmark 能说明模型研究方向，但生产验收必须在本公司的数据、工具、权限和损失函数上完成。
商业价值
工具化推理的商业价值不是“一个人少点几次按钮”，而是缩短从异常出现到形成可审计决策包的时间，并提高同一分析标准在多个仓库中的一致性。它可能减少数据搜集、重复计算和报告整理，但会新增模型、工具、沙箱、观测、人工审核与事故恢复成本。
应按 被接受且可验证的任务 计算单位经济性：
C_accepted =
(C_model + C_tool + C_infra + C_review + C_recovery)
/ N_accepted_verified
Net_value = Labor_saved
+ Avoided_stockout_loss
- C_accepted
- P_harmful_error * Expected_loss
分母不能用“模型完成次数”。报告缺证据、人工大幅改写、动作无法验证或重复执行的任务都不属于合格结果。试点要同时记录 o3 与 o4-mini 的接受率、P50/P95 时延、工具调用数、人工分钟数和恢复次数。若 o3 单次模型成本更高，但显著减少错误工具调用与人工返工，它可能有更低的 C_accepted；若大多数任务只是固定公式，规则引擎或 SQL 报表会更便宜、更稳定。
商业上线建议采用分级自动化：第一阶段只生成证据包，第二阶段生成系统内草稿，第三阶段才允许自动执行低金额、可撤销且有强验证接口的动作。每一级都要有独立回滚条件，不能因为总体成功率提高就一次性扩大所有权限。
局限与风险
第一，首发证据不能证明真实业务可靠性。厂商评测的数据、工具后端、提示、上下文和错误定义与企业任务不同；首发页也提醒带浏览评测可能因搜索后端差异而难以在 API 完全复现。
第二，长推理与多工具会扩大时延和费用方差。一次错误搜索可能引出更多搜索、代码与图像步骤。系统必须设置每任务 token、工具次数、墙钟时间和金额预算，超过后保存已取得证据并转人工，而不是让模型无限继续。
第三，网页提示注入、恶意文件、公式注入和图片误读会沿工具链传播。内容层指令不能覆盖系统策略；代码执行要隔离；检索必须先做租户和角色过滤；敏感字段在进入模型和 trace 前需要最小化或脱敏。
第四，模型解释不是审计证据。推理摘要可以帮助调试，却不能替代原始来源、工具请求、策略决策、审批人、外部单号和验证结果。也不应把隐藏推理当作必须存储或向用户展示的业务凭证。
第五，并非所有任务适合 Agent 化。固定补货公式、确定性税率计算、数据库唯一约束与支付对账应优先用传统代码；没有可靠回读接口的不可逆动作、高损失法律决定、数据极少且无法核验的预测，应保留人工决策。模型最有价值的位置通常是处理非结构化证据和生成候选方案，而不是替代已有确定性控制。
面试表达
面试中我不会把 o3/o4-mini 概括成“更聪明、会调用工具”。更完整的表达是：
2025 年 4 月 16 日的关键变化，是推理模型开始在 ChatGPT 中组合搜索、文件/Python、视觉和图像工具，并在 API 中通过 function calling 使用自定义工具。但模型提出工具调用，不代表业务动作已经授权或成功。我会把 planner、确定性 policy、幂等 executor 和 read-back verifier 分开，显式保存
UNKNOWN终态，用完整轨迹和每个被接受任务成本比较 o3、o4-mini、规则系统与人工流程。
如果继续追问落地，我会展示供应链异常的 120 任务评测设计、恶意网页与工具超时用例、资源 scope 检查、审批票据和单位经济性公式；同时明确这些是待执行的试点方案，不伪装成已经运行的生产成绩。这比背诵厂商 Benchmark 更能证明从全栈开发到 AI 系统工程的能力迁移。
复盘
o3 与 o4-mini 的首发说明推理模型正在从“生成答案”走向“在工具反馈中调整计划”。真正的工程升级不是删掉应用代码，而是把传统系统擅长的身份、事务、约束和恢复，与模型擅长的非结构化理解、候选计划和证据综合接起来。
对中级全栈工程师而言，这个事件最值得学习的不是某个模型得分，而是新的责任划分：模型决定下一步候选动作，应用判断是否允许，执行器改变外部状态，验证器证明结果，评测系统解释失败发生在哪一层。只有这条链能够重放、对账和计算单位价值，工具化推理才会从演示变成可经营的产品能力。
下一步应把本文设计落实成最小实验：构造去标识化供应链任务与故障注入器，先用模拟工具对比规则、o4-mini 与 o3 的轨迹；公开数据集、评分脚本、失败样本和成本口径。没有实验结果前，不把预期写成事实，也不把“支持工具”写成“任务已经可靠完成”。
方法披露
本文围绕 2025 年 4 月 16 日事件，只使用信息截止日内可确认的官方首发材料与固定快照。核验过程比较了当前官方页面和发布日快照，并把 ChatGPT 工具、API 自定义工具、Responses API 当日能力与未来计划分别记录。没有抓取或改写第三方文章，也没有删除他人水印。
本文没有调用 2025 年版本的 o3/o4-mini，没有运行官方评测，也没有取得供应链企业数据。示例代码是控制边界示意，不是 OpenAI SDK 的完整调用样例；120 个任务、验收指标和成本公式是后续实验协议。任何未来实测都应新增版本固定的模型标识、请求参数、数据集哈希、工具实现、原始结果和失败样本，并将证据等级从 sourced 独立升级，而不是覆盖本次历史复盘。
修订记录
- 2025-05-16：首次发布；核验首发页与发布日固定快照，建立 ChatGPT/API 能力边界、供应链任务控制面、完整轨迹评测与单位经济性方法。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论