事件概述

OpenAI News 于 2026 年 10 月 8 日发布了一篇客户案例，主角是亚太地区的法律科技公司 LegalOn Technologies。这家公司以 AI 支持法律工作及其他关键业务职能，其目标是把 AI 引入管理本身——不只做产品，也让组织变成”AI-native”。

LegalOn 把 Codex 集成进开发流程，并通过日常使用在组织内扩散。但随着采用率上升，成本控制成为新问题：一方面，无限制使用高性能模型会推高支出；另一方面，”一刀切”的限制又可能把 AI 带来的生产力增益抵消掉。

他们的解法是按任务复杂度和开发阶段在多个模型之间做选择，并让预算与各业务的成长阶段对齐。最终结果是：在保持开发速度的前提下，估算日成本下降约 65%。

关键技术点

1. 起点：无限制的高性能模型

最初，LegalOn 给开发者无限制访问主模型 GPT-5.5 的 Fast 模式，并把使用范围扩展到设计、实现和日常工作，通过实验摸索人与 AI 之间的职责划分。

这带来一个必然结果：如果继续无限制使用高性能模型，年度预算必然被击穿。

2. AID CoE：把”选模型”变成组织能力

公司的 AID CoE（AI-powered Development CoE） 开始制定模型选择指南。其职责包括测试和监控模型，管理者再把结论同步给团队，最终让每位工程师能独立为每个任务挑选最合适的模型。

选择逻辑从”所有任务都用最强模型”变成”先轻量模型起步，随任务复杂度上升再切换到更强模型”。

3. 三档模型的具体分工

原文给出了相当明确的任务映射：

模型 定位 典型任务
GPT-6 Luna 最轻量 需求清晰的代码实现、日常自动化、委派相对简单的任务与分析，主要作为 subagent
GPT-6.1 Sol 中等 标准设计与分析、相对简单的软件设计、常规数值分析和文档创建，以及要求比 Luna 更短完成时间的任务
GPT-6 Astra 最强 复杂分析、设计与编排、复杂文档与软件设计，作为 orchestrator 协调多个 agent

这张表值得注意的地方在于：它同时覆盖了”角色分层”和”模型分层”——Luna 是 subagent，Astra 是 orchestrator。模型选择与 Agent 架构里的编排层级被绑定在一起。

4. 功能限制与预算治理

除了选模型，LegalOn 还做了两件事：

  • 默认限制 Fast 模式，只在确有必要时允许单次请求。原文提到这一改动曾引发对开发速度的担忧，团队通过并行执行任务等方式维持了性能并平滑过渡。
  • 在部门、小组、个人三级设置 AI 支出预算上限。成熟业务被要求把成本效率提升最多约 20%，而处于启动阶段的新业务则获得较宽松的预算，以鼓励积极使用 AI。

LegalOn 高级工程经理 Yuta Tokitake 解释说，新业务优先考虑的是业务速度而非成本效率，目标是用足量 AI 提高产出，最终驱动业务增长。

在系统层面，公司通过管理员设置引入月度用量限额，由 AID CoE 监控使用情况并随业务需要调整限额。

最终，模型选择、功能限制和按业务定制的预算三项措施叠加，把估算日成本降低了约 65%（与 GPT-5.5 相比）。

5. 从”开发速度”转向”客户价值”的 ROI 度量

LegalOn 没有停在成本优化上。他们提出一个更尖锐的问题：开发更快，就等于 AI 投资成功吗？

Tokitake 的原话是，AI 加速系统开发和更新几乎已成定局，”我们真正想搞清楚的是，这种更快的开发是否真的转化为客户价值”。

为此公司自研了一个指标，把评估基准从开发速度和用量转向客户价值。Tokitake 描述其设计思路：使用 AI 时可以追踪单项任务的成本，但一件完整工作（一次功能发布）的总成本往往是黑箱。因此他们以每次功能发布为计量单位，把该版本交付的客户价值与实际投入的 AI 成本关联起来。

原文说明，这套计算流水线目前仍在建设中，建成后即可让基于客户价值的真实 ROI 可见。指标的具体名称和计算公式，原文未说明。

6. 组织侧动作

下一步目标是把单个工程师的 AI know-how 变成组织级能力。第一步是建设知识库，收集并分享实践经验——例如设计、实现、评审环节的最佳模型组合——把个人成功快速转化为公司最佳实践。

这些变化也在反向塑造组织与招聘：公司已开始在招聘中强调 AI 技能，并重新思考人与 AI 的工作分工及人力规划。

对数据科学或 AI Agent 落地的意义

这个案例对做 Agent 落地的团队有几个直接可迁移的点：

第一，模型路由是成本的一等公民。 很多团队把”用最强模型”当默认值，成本失控后才想到限制。LegalOn 的做法是把路由规则显式化、文档化、可测试，并且落到具体任务类型上。这与数据科学中”不要用复杂模型解决可以用简单模型解决的问题”是同一套思路，只是对象从模型训练换成了推理调用。

第二，路由规则要和 Agent 架构一致。 Luna 作为 subagent、Astra 作为 orchestrator 的分工，本质上是把”编排层用强模型、执行层用轻模型”固化下来。对多 Agent 系统来说，这可能是最自然的降本路径。

第三，治理需要分级，而不是全员统一限额。 部门、小组、个人三级预算加上”成熟业务提效、新业务放开”的差异化策略，承认了一件事：不同业务阶段的成本容忍度本来就不该一样。

第四，以交付单元而非任务单元核算 ROI。 单次调用成本可观测，但一次功能发布的完整 AI 成本是黑箱——这个观察对任何做 AI 提效度量的团队都成立。把成本归集到”发布”这个粒度，再做价值关联，是一个值得借鉴的度量设计。

我的技术点评

这篇案例的价值不在于”省了 65%”这个数字本身——65% 是估算日成本，与 GPT-5.5 对比，具体口径和计算方式原文未说明，不宜直接外推。真正值得注意的是它的治理结构。

首先，AID CoE 这个中间层是关键设计。它既不是纯粹的中央管控（会拖慢团队），也不是完全放任（会烧钱），而是承担”测试模型—产出指南—培训团队”的职能，最终目标是让工程师自己能做选择。这是把成本优化从”审批流程”变成”工程能力”的做法，可持续性远高于硬性封禁。

其次，Fast 模式默认关闭这一手有点反直觉。原文诚实地说这曾引发对速度的担忧，靠并行任务等手段维持了性能。这提示我们：降本措施是否真的无损，取决于团队是否愿意在工程实践上补位。如果只是简单关掉高级功能而不改变工作方式，速度大概率会掉。

第三，ROI 度量那部分是该案例里最”超前”、也最不确定的部分。把客户价值与 AI 成本绑定听起来很对，但”功能发布交付的客户价值”如何量化，原文未说明，流水线也仍在建设中。这是一个正确的方向，但目前还不能算已验证的实践。

最后一点隐忧：这套分层路由高度依赖模型能力的稳定分层——Luna 足够轻、Astra 足够强，且三者边界清晰。一旦模型迭代打乱这个分层，指南就需要重新校准；同时”个人经验沉淀为组织知识库”如果缺少维护机制，很容易退化成过时文档。原文提到知识库是”计划建设”，尚未说明其维护方式。

总体而言，这是一份难得的、把成本治理和 Agent 编排放在一起讲的一线实践记录。对于正在为 LLM 账单发愁、又不想牺牲交付节奏的团队，它提供了一个可拆解参照的框架：先分层模型、再分级预算、最后用交付单元核算价值。

原文链接