吴恩达戳破AI幻象：炒作过头了，未来公司是10人小队＋Agent重做数据架构

近期，在 LangChain 举办的智能体大会 Interrupt 上，吴恩达与 LangChain 创始人 Harrison Chase 进行了一场关于 AI Agent 的对谈。整场交流的核心并不是简单讨论 Agent 有多强，而是围绕一个更现实的问题展开：当 AI Agent 让软件开发变快之后，真正的瓶颈会转移到哪里？ 吴恩达首先提到，过去一年 AI 领域的热度和炒作超出了他的预期。相比之下，更值得关注的是编程智能体的快速进步。他说，六个月前自己几乎主要使用 Claude Code，现在则开始混合使用 OpenAI Codex、Gemini CLI、OpenCode 等工具。编程智能体的能力边界变化很快，甚至连在手机上写代码这样的工作流，也开始变得自然。 但编程智能体带来的最大变化，不只是写代码更快，而是软件生产链条被重新分配。吴恩达提出了“产品管理瓶颈”的概念：当代码实现速度提升 10 倍甚至 100 倍之后，限制团队效率的就不再只是工程实现，而是“到底该做什么”。需求定义、用户反馈、优先级判断、产品边界，都会变得更重要。 与此同时，营销、法务、设计、合规也可能变成新瓶颈。过去一个产品开发三个月，等法务一周签字可以接受；但如果现在一天就能做出产品，再等一周，法务本身就成了阻碍。 因此，未来的软件团队会更小、更快，也更依赖通才型人才。 吴恩达提到，他越来越多地组建一到十人的小团队，成员往往是高上下文、高授权、技术能力强的工程师。他们不只写代码，还会借助 AI 完成产品定义、营销文案、服务条款初稿等工作。AI 不会让工程师瞬间变成优秀营销人员或律师，但可以让他们先产出一个可用初稿，再交给专业人员把关。 在 Agent 开发方式上，吴恩达用了“乐高积木”的比喻。 今天的开发者面对的不只是模型，还有 RAG、Agent 框架、评估工具、Guardrails、UI 组件、身份认证、数据库等大量构建模块。开发者越了解这些模块，越能快速组合出可用系统。但问题是，API、SDK 和工具变化太快，模型未必知道最新用法。因此，Agent 的能力不只取决于模型本身，也取决于它能否获得及时、准确、可执行的上下文。 谈到企业落地，吴恩达认为，很多企业正在做自下而上的 AI 创新，但这种“百花齐放”往往只能带来点状提效，难以形成真正转型。比如银行用 AI 自动化贷款审批，如果只是把一小时人工审核变成 AI 审核，价值有限；更大的机会是重构整个流程，推出“10 分钟获批”的贷款产品。这需要营销、数据、审批、尽调、执行等环节一起变化。 他也提醒企业，不要只把 AI 当作降本工具。成本节省有上限，增长才更有想象空间。客服、呼叫中心、drive-through 点餐等场景中，AI 的价值不只是减少人工，而是更快服务更多客户，改善体验，进而带动业务增长。 在技术选型上，吴恩达特别强调要警惕供应商锁定。AI 模型和 Agent 工具变化太快，没人能确定一年后最强的模型是谁。因此，企业应尽量保留选择权，不要轻易因为折扣签下过长合约。LangSmith 这类供应商中立的观测和管理工具，以及开放权重模型，都有助于企业在快速变化中保持灵活性。 最后，他把企业 Agent 的关键基础落到数据架构上。过去企业主要围绕结构化数据做治理，但 Agent 真正要发挥作用，必须能处理文本、PDF、图片、音频、视频等非结构化数据。现实是，很多企业数据分散、权限体系为人而非 Agent 设计、治理和可观测性不足。吴恩达判断，未来几年，企业会启动大规模数据架构重构，让数据真正变得 AI-ready、agent-ready。 这场对话的重点是：AI Agent 不只是让代码写得更快，它正在倒逼企业重新思考产品、组织、数据、流程和技术选型。真正能从 Agent 中受益的企业，不是简单自动化某个环节，而是有能力围绕 Agent 重构整个业务系统。 以下为完整版对话，经 InfoQ 编译： 编程智能体的崛起 Harrison Chase：距离我们上次对话已经过去一年了，这一年 AI 领域发生了很多事情。哪些事情的发展速度超出了你的预期？哪些事情又比你想象得更慢？ 吴恩达：我觉得，首先是一些热度和炒作程度超出了我的预期。另外，一些末日叙事也获得了比我预想中更多的关注，这有点遗憾。比如所谓的“工作岗位末日”，我并不认为那会真的发生。更积极的一面是，编程智能体的发展速度可能比我预想得更快。 现在的前沿编程智能体发展非常快。虽然外界总说 AI 每三个月就彻底改变一次，这种说法并不完全准确，但在编程智能体上，它确实有点像真的。我们能用编程智能体完成的事情，其前沿能力变化非常快，而且竞争非常激烈。 大概六个月前，我几乎全都在用 Claude Code。现在我仍然大量使用 Claude Code，但也越来越多地使用 OpenAI Codex，同时也会混合使用 Gemini CLI。我也支持 OpenCode，因为它是开放的代码。 所以我们使用的编程智能体组合变化得非常快。 一年前我也不会想到，自己会在手机上写这么多代码。很多工作流都在快速改变。比如像在座很多人一样，我办公室里也有一台 Mac Mini，这些开发工作流变化得非常快。 另外，智能体式工作流也正在真正进入企业。这一点也让人感觉不错。 Harrison Chase：顺着软件工程这个话题，在你看来，软件工程的未来会是什么样？ 吴恩达：大概一年前，我写过“产品管理瓶颈”这个问题。它的意思是，如果构建软件变得快得多，那么决定要构建什么，也就是产品管理工作，包括定义项目范围、获取客户反馈、决定做什么，就会变成瓶颈。 过去一年，我感觉这个产品管理瓶颈以一种好的方式变得更严重了，因为软件构建变得快多了。 但事实证明，当写软件变快 10 倍甚至 100 倍之后，不只是产品管理会成为瓶颈，几乎所有其他事情都会变成瓶颈。 我有些团队已经遇到了营销瓶颈。因为我们能构建太多功能，营销人员反而很难跟上，搞清楚一个新功能到底做了什么，然后再思考该如何对外传播。 过去，如果一个产品需要法律合规，你花三个月构建它，再等一周让法务签字，可能还可以接受。但现在，如果你一天就能构建出来，然后还要等一周法务签字，那就变成了法律合规瓶颈。设计也会成为瓶颈，其他环节也一样。 所以我经常思考，未来的软件工程团队会如何组织。但我不认为自己已经知道答案。 不过，我越来越多地在组建非常小的团队，可能是一到十个工程师。这些人通常是通才型、高上下文、高授权的工程师。团队会被给到一组非常宽的护栏，然后他们就可以在这个范围内疯狂推进、构建并发布代码，甚至推动一些传统上不属于工程范畴的决策，比如写营销文案。 假设你有一个团队，它需要软件工程、产品管理、一点服务条款、一些营销文案、一些设计。也就是说，这个团队需要五种职能，但只有两个人。 那么按照定义，或者用“鸽巢原理”来说，这两个人里的每一个人都必须承担不止一个角色。 好消息是，我不觉得自己是一个很好的营销人员。但当我使用 AI 时，我仍然不是一个好营销人员，只是和没有 AI 助手相比，稍微没那么差。 所以我发现，这种小团队很有效：成员是高上下文的通才，技术能力很强，同时能够使用前沿技术，在其他角色上也承担一部分工