企业应用

待验证|OpenAI用Ironclad训练电脑使用

OpenAI把合同SaaS流程变成电脑使用训练任务,但效果仍是研究评测。

2026年10月7日 · 周三深度报告低置信重要度 3/5

本文要点

  • 电脑使用训练从通用网页操作推进到合同管理专业软件。
  • 任务定义由软件厂商员工和OpenAI内部用户共同参与。
  • 模型表现以rubric得分和模拟尝试时间同时衡量。

阅读辅助

先看数字、证据和来源,再读正文。

11项研究任务
55.0%Astra平均分
5 条 Claim Audit

OpenAI在10月6日发布与Ironclad的电脑使用研究合作。

5 个时间点

2026-10-06 10:00 GMT · OpenAI News RSS记录Advancing computer use with Ironclad发布。

6 个来源6 个非 X 来源

研究任务比演示更值得看

OpenAI在2026年10月6日发布与Ironclad的研究合作,目标是把合同管理里的复杂电脑操作变成模型训练和评测任务。新闻锚点落在任务工程上:OpenAI把垂直SaaS厂商的真实产品流程拆成了可评分的研究任务,并用它比较GPT-6 Astra和GPT-5.6 Sol。

已能确认的事实集中在OpenAI官方文本。Ironclad员工和OpenAI内部使用Ironclad的人,协助研究人员定义了11项法律、商业和采购相关任务;OpenAI称熟练用户平均每项需要约30至40分钟。在这组研究评测中,Astra平均rubric score为55.0%,GPT-5.6 Sol为41.6%;估算单次尝试平均时间从Sol的37.0分钟降到Astra的19.2分钟。OpenAI还写到,一个用于Astra开发的内部模型在这些任务上达到63.7%。

边界同样要前置。OpenAI明确说,这些结果只覆盖这11项研究任务,不代表所有Ironclad工作流。文中的时间是基于模型处理与生成速度假设的模拟估算,不是客户现场测到的节省时间。训练和评估任务则来自SEC EDGAR公开合同过滤后生成的模拟任务;OpenAI声明没有使用OpenAI客户数据、OpenAI内部合同,也没有使用非公开Ironclad客户数据或合同。

对企业买方和SaaS厂商来说,这条更新的价值在于任务定义方式。专业软件里的agent落地,难点通常不在“能不能点按钮”,而在模型是否理解业务规则、审批路径、字段复用和完成标准。OpenAI这次把合作对象放在合同生命周期管理场景里,说明模型公司开始把电脑使用能力推向更难外包给通用benchmark的企业流程。

11项任务覆盖哪些工作

OpenAI没有在公告中逐条公开完整任务清单,但它给了任务类型:设置保密协议、创建采购审批流程、更新可复用法律条款,使其能反映请求人选择的司法辖区。这些动作都不是单步点击。它们通常牵涉模板、条件规则、审批节点、字段映射和最终产物检查。

这解释了为什么Ironclad这样的垂直SaaS厂商会进入模型训练环节。通用电脑使用agent可以学习浏览器、表单和文档编辑,但专业软件的“正确”往往藏在业务语义里:某个合同类型应该走哪条审批链,哪个字段会影响条款选择,哪类采购请求需要额外法务审查。软件厂商知道客户流程中的高价值任务,也知道怎样判断一个配置是否可用。

OpenAI把这些任务评测为rubric score。每个任务根据复杂度被拆成8到50项标准,用来判断模型完成了哪些要求、哪里失败。这个设计比只看“任务完成/失败”更适合专业流程,因为合同系统里的风险常落在审批条件、条款变量或可复用配置这类局部错误上。

维度OpenAI披露的口径读者应如何理解
任务数量11项研究任务研究评测规模较小,不能覆盖全部Ironclad流程
人工参考耗时熟练用户平均约30至40分钟这是OpenAI估算的任务复杂度背景
评分方式每项含8到50项标准反映分步骤完成度,不等于线上成功率
Astra平均分55.0%官方自报rubric score,需等第三方或客户验证
GPT-5.6 Sol平均分41.6%同一11项任务的对照分数
Astra模拟时间19.2分钟模拟估算,不是客户现场节省时间
Sol模拟时间37.0分钟与Astra同口径估算,不能单独外推
内部模型63.7%未发布内部模型结果,缺少配置和成本细节

这些数字的组合比单个分数更有信息量。Astra不仅得分高于Sol,估算时间也更短;但得分只有55.0%,说明即使在研究任务和托管软件环境中,模型距离稳定完成复杂合同流程仍有明显缺口。63.7%的内部模型结果则提示OpenAI内部还有进一步收益,但它没有公开模型名称、推理设置、成本和失败分布,因此只能作为研发方向信号。

模拟结果的边界

这篇公告最容易被误写的地方,是把相对改善和模拟时间当作客户收益。OpenAI原文说Astra的average score was 32% higher than GPT-5.6 Sol’s,estimated time per attempt was 48% lower。中文应该保留比较基准:Astra是在同一研究评测里相对Sol平均分高32%,估算单次尝试时间低48%。这不是“合同团队效率提高32%”或“客户节省48%时间”。

OpenAI还在脚注中收紧适用范围。These results cover the 11 research tasks, not all Ironclad workflows。The times are simulated estimates based on assumed model processing and generation speeds, not measured customer time savings。两句话必须一起读:一方面,结果范围限定在研究任务;另一方面,时间是模拟估计,而非部署后的客户数据。

数据使用声明也要忠实保留。OpenAI说合成训练任务来自SEC EDGAR公开合同,经过过滤以移除个人信息;并声明没有使用OpenAI客户数据、OpenAI内部合同、非公开Ironclad客户数据或合同。这个声明很关键,因为合同数据天然包含商业条款、交易对手、定价和个人信息。如果把它漏掉,读者很容易误以为研究直接使用了客户合同库。

需要保留的读法可以压成三条。第一,32%和48%都是相对Sol的研究评测口径,不是客户组织的效率收益。第二,11项研究任务是本次结论的边界,不覆盖Ironclad全部工作流。第三,公开合同生成的合成任务降低了客户数据风险,但也意味着外部仍无法审计过滤流程和任务代表性。

这组口径本身就是新闻价值的一部分。它说明OpenAI知道企业软件agent的评测很容易滑向营销案例,因此主动把范围、数据来源和时间估算写清。对读者来说,判断这条新闻时不能只看Astra领先Sol,还要看任务是否足够代表真实合同团队、rubric是否公开、失败样例是否能复盘。

为什么合同工作流适合训练电脑使用

电脑使用agent过去常被放在通用网页、办公文档和简单表单里演示。合同生命周期管理的难度高得多,因为它同时包含文档语义、业务规则、角色权限和审批状态。一个agent如果只是会找按钮,仍可能把错误条款配置到模板里,或者把本应走采购审批的流程配置成普通业务审批。

Ironclad场景有几个适合作为研究任务的特点。第一,工作有清楚的业务目标,例如创建采购审批流程或更新法律条款。第二,完成标准能被拆成多个rubric项,便于研究人员看模型哪一步失败。第三,任务环境是托管软件,不需要真实客户合同也能构造代表性流程。第四,结果的商业价值足够高,因为法务和采购流程的错误会拖慢交易,也可能带来合规风险。

这也解释了OpenAI为什么邀请“小数量软件公司”直接与研究和工程团队合作。专业软件厂商提供的不只是UI环境,还包括“什么任务值得做”和“怎样算做对”的知识。模型公司如果只在公开网页和合成浏览器任务上训练,很难获得这种业务定义。反过来,SaaS厂商如果只把通用模型接进产品,也很难让模型稳定完成跨页面、多步骤、带审批条件的任务。

但合同工作流也会放大评测风险。合成任务来自公开合同和代表性流程,并不等于客户真实流程。企业合同里的异常条款、历史模板、地区差异、权限限制和内部政策,往往比公开样本更复杂。Astra在研究环境里达到55.0%,说明模型正在进步,也说明现在距离“少监督完成关键合同配置”还有距离。

这对企业Agent落地意味着什么

OpenAI这次给出的路线,是让模型先在合作软件的托管环境里练习,再用reinforcement learning通过实践和反馈改善。这个方向与普通插件集成不同。插件集成让模型调用API或填表,研究合作则把软件中的难任务变成训练样本和评测集。前者偏产品连接,后者偏能力塑形。

对SaaS厂商来说,这是一种新的竞争入口。如果OpenAI能把“与少数软件公司共建高价值任务”的模式复制到CRM、ERP、ITSM、财务、医疗管理和研发工具里,专业软件厂商会开始竞争谁能把自己的工作流变成更好的模型训练场。任务越清晰、rubric越可审计、环境越稳定,越容易被模型公司吸收。

对企业采购方来说,采购指标要比演示更具体。不能只问“是否支持agent自动操作Ironclad”,而要问:覆盖哪些任务,rubric如何定义,失败时是否可回滚,审批和权限如何继承,真实用户平均用时是多少,异常案例如何处理,训练数据边界能否审计。OpenAI公告里的模拟时间和数据声明,恰好给了采购问卷的起点。

对开发者来说,值得关注的是电脑使用能力和业务规则之间的接口。网页自动化常常把UI当作唯一状态,但合同系统的真实状态还包括模板版本、条款库、审批条件、用户角色和组织政策。如果未来模型通过软件伙伴训练获得这些隐性规则,agent应用的壁垒会从“会不会操作浏览器”转向“能不能理解某个垂直系统的成功标准”。

早报观点

早报判断是,OpenAI与Ironclad这次合作把电脑使用agent的竞争焦点推进到了任务定义层。单纯展示模型会点网页按钮,已经不足以说明它能处理专业工作;把合同流程拆成11项研究任务,并用8到50项rubric逐项评分,才更接近企业买方真正关心的可靠性问题。

这条新闻同时暴露出当前阶段的天花板。Astra相对Sol有进步,但平均分仍是55.0%,内部模型也只是到63.7%。如果这些任务代表复杂专业软件的早期样本,那么模型公司距离“无人值守完成高风险SaaS流程”还有明显距离。更合理的产品形态,是让agent承担配置草稿、检查、迁移和建议,把关键提交留给人类或强审批链。

对SaaS生态更大的影响,是模型训练可能开始选择性吸收垂直软件的工作流知识。谁能提供高价值任务、可运行环境和可审计rubric,谁就更可能让自己的产品成为前沿模型训练的一部分。这个机制会让SaaS厂商从单纯接入模型,转向共同定义模型应该擅长什么。

接下来该看哪些验证

第一类验证是任务公开度。OpenAI没有公开完整的11项任务、rubric细项、每项成功率和失败样例。若后续能公开匿名化任务描述或更细的错误分布,外部才能判断Astra的55.0%到底是均衡改善,还是少数任务大幅拉高平均。

第二类验证是真实客户数据。当前19.2分钟和37.0分钟都是模拟估算,人工30至40分钟也是OpenAI给出的复杂度背景。企业真正需要的是部署后的人类审查时间、重试次数、失败恢复成本和误配置率。合同工作流的价值不只在省时间,还在少犯影响审批和条款的错误。

第三类验证是数据边界。OpenAI已经声明没有使用客户、内部或非公开Ironclad客户数据,这对合同场景很重要。后续如果更多SaaS伙伴加入,同样需要公开任务如何合成、个人信息如何过滤、客户数据是否进入训练或评测、客户能否选择退出。

第四类验证是模型迭代。OpenAI提到内部模型达到63.7%,并希望把进一步收益带给未来模型。这个数字是一个研发信号,但暂时没有配置和成本信息。下一步要看未来公开模型是否在同一口径下接近这个分数,并且是否在时间估算、失败率和可审计性上同时改善。

这篇公告给企业agent落地提供了一个更务实的样板:先选高价值流程,再让软件厂商定义成功标准,最后把训练、评测、数据边界和客户验证分开报告。它还不是一个可直接采购的“合同agent上线”故事,但它说明前沿模型公司正在认真寻找专业工作里的可训练任务。