公开了什么

OpenAI 关于 Localiza 的案例讲的是：一家出行服务公司同时围绕四层重建了工作方式——面向日常工作的 ChatGPT Enterprise、嵌进产品的 OpenAI API、给工程团队用的 Codex，以及 60 多个专用代理负责可重复的任务。它给出的目标不是「在某处用上 AI」，而是「做出 AI 原生的出行体验」——这是组织层面的说法，不是工具层面的。

公开摘要刻意写得很薄：没有每个代理的采用率、没有节省的工时、也没说哪个团队负责哪个代理。所以把它当成一份架构描述来读，而不是一份效果基准。

四层分别在回答什么问题

把四层当成一个设计来看，每一层回答的问题都不一样：

  • ChatGPT Enterprise 回答「人在哪里提问」。它是通用入口，员工打一句话就能拿到答案。
  • OpenAI API 回答「怎么进到产品里」。它嵌在系统里，用户看不见。
  • Codex 回答「谁来写代码、改代码」。它带着仓库上下文，范围限定在工程。
  • 60 多个专用代理 回答「哪些重复的活可以自己跑」。每一个只管一件事。

真正有意思的是最后一层。六十个代理不是六十个聊天机器人，而是六十个窄范围——各自的输入、各自的输出，理想情况下还有各自的权限边界。

为什么「多个窄代理」胜过「一个万能代理」

一个什么都能干的代理，演示起来很容易，治理起来很难。你回答不了「它被允许碰什么」，因为答案是「什么都能碰」。你没法审计一次运行，因为每次运行长得都不一样。出了问题你也回滚不了，因为不知道是哪一步坏的。

窄代理把这三件事反过来：

  1. 范围是可声明的。「这个代理负责核对供应商发票」——它需要哪些文件、写进哪个系统，一句话就说清了。
  2. 运行是可比的。 同一个窄代理跑两次，产出的结构应该一样，所以 diff 才有意义。
  3. 故障是可控的。 发票代理坏了也发不出客户邮件，因为发邮件是另一个代理、另一套权限。

这些都不需要六十个代理，只需要你做的每一个代理都只有一件活。

搬到 Windows 桌面上怎么抄

在自己机器上跑代理，同一套分工可以按更小的规模落地：

  • 一个通用助手负责临时提问，不给写权限。
  • 三到五个窄流程负责你每周真的会重复的活——重命名归档、核对表格、起草周期性报告。
  • 每个流程显式绑定文件夹。 碰 D:\发票 的流程不该能打开 D:\合同。
  • 每次运行留一份一分钟能读完的日志。 如果你说不清某个代理上周二做了什么，那就是范围太宽。

本地的额外好处是：你可以用文件系统本身来执行这条边界。指向一个文件夹的窄代理，是一个能靠看盘符验证的权限边界，而不是系统提示里的一句承诺。

MOOGH 就是按这个模型做的：任务范围由你交给它的东西决定，每次运行先列出打算用的文件和命令，没经你批准不会执行。下载 MOOGH，在你自己的电脑上试一遍窄流程的做法。

相关阅读

常见问题

这是客户案例还是基准测试？

是案例。OpenAI 把它作为落地示例发布，不是受控测量。没有公开改造前后的周期时间对比。

小团队第一个代理该做什么？

做那个产出最容易检查的。核对发票、批量重命名，比「研究助手」好——结果几秒钟就能验，范围又只有一个文件夹。

一定要用 ChatGPT Enterprise 吗？

不需要。这套架构——通用助手加若干窄流程——换任何模型供应商都成立。企业版主要改变的是身份、数据处理和管理控制。