30 秒看懂
在 2026 年 OpenAI DevDay 上，OpenAI Developer Experience 的 Aarti Bagul 采访了 Stack Overflow 产品副总裁 Alexandra Lato，谈他们如何用 Codex 交出两款截然不同的产品。Stack Internal 是面向大型、往往部署在本地的客户的企业知识智能层；Stack Overflow for Agents 则是一款小而实验性的、以 agent 为先的公开产品。Lato 的论点是：同一个编程 agent，该圈住还是该放开，取决于风险——企业产品给它服务契约、授权模型和人工把关；从零开始的假设，则让它提出架构。 她强调的实际收益是原型：Codex 在 Slack、Google Docs、Jira、Confluence 和 Notion 里找出的共享模式，工程师就不必再一个个重做连接器，可以把时间花在信任、新鲜度，以及谁有权看到什么上。在 agent 产品上，Codex 建议把每个 agent 的身份绑到一个人身上。Agent 可以发 Today I Learned 笔记和蓝图，也可以在生产环境里验证已有答案，再写回真正管用的做法。Stack Internal 的第一版第二天就要上线；Stack Overflow for Agents 当时已经可以免费试用。
- 1两款产品，两种风险Stack Internal 是面向大规模部署的企业知识智能产品。Stack Overflow for Agents 是一款小而实验性的、面向个人、以 agent 为先的产品。两款都用了 Codex，但用在开发生命周期的不同阶段。
- 2实验上，让 Codex 去闯做 Stack Overflow for Agents 时，团队把 Stack Overflow 的架构黄金路径交给 Codex，让它提出决策、约束和容器。产品从假设起步，他们想保持小作坊式的糙劲。
- 3企业产品上，把 Codex 圈住Stack Internal 要交给现有客户，席位从 150 到 10,000，也包括大约 50,000 席的银行，以及本地部署。在这里团队规定得很死：服务契约在这里，在这个安全容器里做，并保留人工把关。
- 4用原型，而不是一次性连接器Codex 看出各来源共享的模式，并据此做出原型。一个文档原型可以在同一套 API 后面覆盖 Google Docs、Teams 附件、Confluence 和 Notion——Lato 说这本来要花好几周，结果几天就做完了。
- 5工程师的时间花在信任上，而不是接入入口这一关——把来源接进来——搞定之后，工程师就能去做难的问题：判定昨天的 Slack 线程比三月那条更权威，再把这个判断交给客户。
- 6把 agent 绑到人身上构思 Stack Overflow for Agents 时，Codex 根据 Stack Overflow 的品牌规范和公司历史，建议把 agent 的身份绑到它的人类主人身上，以保留品牌。贡献就这样做成了带着声望。
- 7Agent 应该在生产环境里验证答案贡献只是回路的一半。如果 agent 碰到一条未闭合的答案，它可以在生产环境里试一下，再写回：这个建议不行，真正修好的是这个。
要点建议
- 给编程 agent 多少自由，要跟产品的风险匹配：从零开始的实验，让它提出架构；已经有客户、还有本地部署约束的系统，就把它关在既有契约里。
- 企业知识工作不只是检索。Codex 需要的不只是架构图，还要授权模型、隐私规则，以及每个来源自己的上下文。
- 把杂乱的集成收成共享原型，这样一个文档 API 就能覆盖 Google Docs、Confluence、Notion 和 Teams 附件。
- 原型省下的时间，花在信任上：哪条线程更权威，哪份文档够新，谁有权看到它。
- 面向 agent 的设计不只是让页面方便机器读。要让 agent 贡献知识，把每个 agent 绑到一个人的身份和声望上，并把自主程度做成可配置。
- 把回路闭合：让 agent 在生产环境里验证已有答案，再写回什么失败了、真正修好问题的又是什么。
按章节阅读完整文稿
台上的客户
Aarti Bagul 开场介绍 Stack Overflow 是 Codex 的重度用户，并请来产品副总裁 Alexandra Lato。Alex 说明自己负责的范围：公开问答平台，以及两款新产品——Stack Internal 和 Stack Overflow for Agents。
Aarti Bagul 在 OpenAI DevDay 这一场的开场先提起 Stack Overflow：这家客户在大量使用 Codex。她介绍 Stack Overflow 产品副总裁 Alexandra Lato，请她讲讲公司的几项新动作、分享用 Codex 的实操经验，并说明 Stack Overflow 如何为一个不只是人、还有 agent 在用平台的世界而建设。随后她请 Alex 上台。
Alex 上台就开玩笑：她以为加州会很热，结果冻得要命。她说自己来自加拿大，对付寒冷仍然是个糟糕的加拿大人。被问到自己是谁时，她说自己负责 Stack Overflow 整个产品组合：许多开发者从小用到大的公开问答站，再加上今天要拆开讲的两款新产品——Stack Internal 和 Stack Overflow for Agents。
两款产品，两种用 Codex 的方式
Stack Internal 是面向大型和本地部署客户的企业知识智能；Stack Overflow for Agents 是小作坊式、以 agent 为先的实验。实验产品上，Codex 在黄金路径里自由发挥；企业产品上，它被圈在服务契约和一个人工把关的盒子里。
Aarti 问这两项是什么、Codex 用在哪里。Alex 说它们处在光谱的两端。Stack Internal 是企业级知识智能产品，为大规模部署而做。Stack Overflow for Agents 是一款小而实验性的、面向个人、以 agent 为先的产品。两款都大量用了 Codex，但用在软件开发生命周期的不同阶段。
Codex 的用法也不一样。Alex 是产品人，工程师不在场时喜欢假装自己也能当工程师。她说 Stack Overflow for Agents——简称 SOFA——起步时只是一个假设。团队想保持小作坊式的糙劲。他们把 Stack Overflow 的架构黄金路径交给 Codex，然后让它自己闯：提出决策、约束，以及在哪个容器里做。
Stack Internal 正好相反。它要交给现有客户，席位从 150 到 10,000，也包括大约 50,000 席的大银行，还有许多约束多得多的本地部署。在这里他们规定得很死：服务之间的契约和架构约定在这里，架构就是这样搭的，请在这个安全容器里干活。有的地方让 Codex 自己转，有的地方则故意留着人工把关。
Aarti 指出，企业产品的安全门槛迫使他们一开始就加上更多护栏。Alex 同意：Codex 需要的不只是架构图，它得理解企业真正要求什么。Stack Internal 把散落的原始知识拉过来、结构化，立刻就会碰到数据泄露的问题——谁能看到什么、适用哪套授权模型、某个来源是本地还是云上。这层复杂性必须作为上下文交给 Codex。
非企业产品是全新架构，所以 Alex 可以告诉 Codex 她要什么，问它最好怎么做，再从那里往下想。Aarti 转到 Stack Internal 必须理清的众多数据源。在“是不是有 grep 就够了？”的年代，她觉得答案是否定的，并问团队是怎么过这一关的。
知识来源、信任与原型
企业每天都在 Slack、Docs、Jira 和 Confluence 里产生上下文，各自形状不同、权限不同。Codex 用原型帮 Stack Overflow 把这摊乱摊子做大规模，工程师就能把时间花在核验、权威性和新鲜度上，而不是接入。
Alex 说，企业里的人每天都在创造上下文：Slack 线程、Teams 聊天、Google Docs，不停地改、不停地分享，每份都带着权限。再乘以每一位员工。Stack Internal 是一层知识智能：走进这些原始上下文，结构化、组织起来，再押上 Stack Overflow 一贯的赌注——信任与核验。要做到这一点，就得拿着一长串隐私、治理和泄露约束走进那些系统，并且从头到尾都遵守。
一条 Slack 消息、一份 Google Doc、一张 Jira 工单、一页 Confluence，存信息的方式都不一样。然后这家企业这样配 Jira，那家又那样配，Stack Overflow 全盘接手。他们得把这些来源做大规模，还不能变慢。她说，Codex 能看穿这层复杂性，帮他们想怎么扩。
Codex 做出的，是原型这个想法：各来源共享的模式。一个文档原型可以覆盖一份 Google Doc、一个 Teams 附件、Confluence 或 Notion。如果在这个原型外包一层 API，Codex 就可以说它在十个来源里看到了同样的模式，下游连接都能复用。这套逻辑本来要花好几周去建；Codex 几天就做完了。
Aarti 指出，这不只是检索性能：有些来源比 Slack 或 Teams 里的噪音更权威，新鲜度也很重要。原型帮他们给每个来源套上上下文。对 Alex 来说，这是进门这一关的重活。模式就位之后，工程师就能把时间花在难的问题上：施加信任——判定 Alex 昨天的 Slack 线程应该排在别人三月那条前面。她不想让人把产能耗在把来源接进系统上。Codex 把这关扛了，她说这简直是及时雨。
为 agent 设计 Stack Overflow
Stack Overflow 的下一章，是人和 agent 一起消费、一起贡献知识。Codex 建议把每个 agent 绑到一个人的身份上。Agent 可以发 Today I Learned 笔记和蓝图，自主程度可配置，也可以在生产环境里验证已有答案。
话题转到 Stack Overflow for Agents。在 OpenAI 做开发者体验的 Aarti 说，如今来查文档的常常根本不是人——开发者把 agent 指向文档，按这种方式来做。这给网页产品提出一个设计问题：怎么同时为 agent 和人来设计？她问 Stack Overflow 是怎么处理的。
Stack Overflow 一直是由人主导、默认开放的公共社区。Alex 的工作是重新想下一章：一个人与 agent 一起消费、一起贡献知识的世界。对 Stack Overflow 这样的公司，这是另一盘棋。版主要怎么办？问答要怎么办？问题被当成重复关掉、那种熟悉的痛还在不在？SOFA 就是为了去戳这些问题而做的。
SOFA 是实验性的赌注，放在单独的架构上，好走得更快。他们告诉 Codex：我们有个想法，想要一种让 agent 能在平台上贡献的产品体验。构思阶段，Codex 回信问：要不要把 agent 的身份绑到它对应的人身上，好保留 Stack Overflow 品牌的一部分——这个想法是它从品牌规范和公司历史里抠出来的。Alex 觉得这主意很好，产品就这么做成了。
他们做了一个公开平台，agent 可以把生产环境里正在学到的东西接进来，推回给社区。不再潜水——这是 Stack Overflow 对只消费、不贡献的叫法——agent 可以贡献。修好了什么，就可以发一条 Today I Learned。也可以发布某个架构或某种语言的蓝图。转变在于：从只通过 MCP 消费的 agent，变成也会把知识写回去的 agent，这对 Stack Overflow 是新的。
Aarti 同意，“agent native”通常是指让页面方便 agent 读，但更有意思的一步是贡献：agent 补充知识，可以比人类潜水者一向做得更稳定。Alex 说，给这些 agent 多少自主权，他们还在试。
如果 agent 绑在一个 Stack Overflow 的人身上，这个人就有声望——字面意义上的声望分，帖子上也挂着他的名字。人希望以自己名义发出去的东西说得通。自主程度可以配置：每条都要人点头，或者在某个话题上让 agent 自己闯。
回路不只是贡献。Agent 也可以验证站点上已有的内容。如果 agent 碰到一个问题、上面有未闭合的答案，它可以拿这个建议去生产环境里试，再写回来：我试过这个，不行，真正修好的是这个。他们想把以 agent 为先的知识回路闭合——消费和贡献。
接下来可以试什么
Aarti 回顾了两种 Codex 用法、原型，以及作为贡献者的 agent。Alex 请社区看看新产品：Stack Internal 的第一版第二天就要上线，Stack Overflow for Agents 当时已经可以免费试用。
Aarti 回顾了他们讲过的内容：企业产品上给 Codex 加上厚厚的护栏，全新的 agent 产品上则放手；用原型给杂乱的数据源编码上下文；以及 agent-native 意味着把 agent 放回路里，作为新知识的贡献者。她问 Alex 还有没有想留给观众的话。
Alex 说，如果你对 Stack Overflow 这二十年里为你的职业做过的事还有一点感情，就去看看他们正在做的东西。企业组织产品——那层知识智能——的第一版第二天就要上线。Stack Overflow for Agents 当时已经可以免费试用。她请社区去试、给反馈，让他们继续为开发者做下去。Aarti 收尾，现场鼓掌。
