近期，在 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 助手相比，稍微没那么差。
所以我发现，这种小团队很有效：成员是高上下文的通才，技术能力很强，同时能够使用前沿技术，在其他角色上也承担一部分工作。
比如，坦率地说，所有工程师都可以用 AI 起草一版服务条款，然后再交给律师，让律师最终润色后发布。我发现这些流程能让团队移动得快得多。这一点非常令人兴奋。
Harrison Chase：这些人的理想背景是什么？他们本来就是工程师吗？还是来自其他学科，然后第一次学习写代码？你观察到的情况是什么？
吴恩达：我最密切合作的很多人，确实拥有很深的工程和技术背景。同时，他们也被充分授权，是略带通才属性的人。他们会进入其他角色，并在 AI 的支持下获得混合技能，而这些技能可能原本并不是他们受过训练的领域。
我认为人们可以从任何方向成功转型。我见过产品经理在写代码方面变得强很多，然后参与到这类团队中。
不过，因为 AI 编程本身和工程关系很深，工程师在理解前沿技术上可能天然有优势。所以我最常看到工程师成功扮演这种角色。
但也确实有少数产品经理能做到。我也见过营销人员以非常有效的方式学习写代码。还见过运营人员开始构建越来越多产品。
我认为任何背景的人都有可能学会做很多这类事情。但目前做得最好的最大群体，似乎仍然是工程背景出身的人。
不过，我们鼓励来自任何背景的人都尝试看看，自己是否能扮演这些角色。
Harrison Chase：对于那些想进入这种新软件工程领域的人，你有什么建议？比如有哪些工具值得尝试，应该具备什么心态，或者应该学习哪些技能？
吴恩达：我最近在用一种方式思考软件工程的未来，这是我脑子里的一个心智模型。现在有很多工具提供商，提供各种构建模块，比如 RAG、智能体框架、评估工具、护栏等。这些都是 AI 构建模块。
同时，也有很多非 AI 构建模块，比如用户界面组件、身份认证机制、前端和后端、持久化数据库等等。
所以我认为，在计算机科学里，我们一直都有一套非常棒的构建模块。而随着智能体式编程的发展，构建模块正在快速增加，因为越来越多人在构建开源模块、专有 API 模块，或者其他类型的构建模块。所以我们周围有很多非常棒的构建模块。
我发现，如果开发者能够很好地掌握足够多的构建模块，他们通常就可以用组合的方式，把这些模块快速拼装起来，构建软件。
你可以想象用乐高积木搭东西。如果我手里只有一块白色乐高积木，我能搭一些东西，但不会太有意思。但如果我再加入黑色、黄色、棕色、绿色的积木，再加上一些形状奇特的乐高零件，那么随着我拥有的乐高积木种类变多，我能搭出的东西会以组合式方式增长，甚至呈指数增长。
我认为，我们现在能使用的很多构建模块，也有类似效果。
我发现，那些开发者如果能很好地理解这些构建模块能做什么，就会变得非常强。
DeepLearning.AI 也提供了很多短课程，帮助大家掌握来自不同机构和开发者的这些优秀构建模块。另一个挑战是，如何使用编程智能体，快速把这些构建模块组装成你想要的软件。
现在编程智能体面临的一个问题是，很多构建模块太新了，以至于编程智能体并不知道该如何使用它们。
举个例子，直到最近，很多领先编程智能体所基于的模型，知识截止时间都早于 nano-banana 发布的时间。所以它们并不知道 nano-banana 存在，也不知道如何调用 nano-banana API。
所以我和我的朋友 Rohit Prasad 一直很关注一个项目，叫 Context Hub。它有点像面向 AI 智能体的 Stack Overflow。
AI 智能体可以通过它获取最新文档，了解有哪些最新 API、SDK 和构建模块可以使用；同时，智能体也可以向文档提供反馈，帮助改进文档，让所有人受益。
实际上，有一些 API 是我自己经常使用的，但我总觉得它们的语法有点烦人，很难记住。但通过 Context Hub 加载最新文档后，我可以让编程智能体替我完成这些 API 调用。
所以它确实让我的编码工作加速了很多。
Harrison Chase：这里我补充两点。我们也发布过一个叫 Context Hub 的东西，所以我们在名字上撞车了，但这是非常不同类型的 Context Hub。Andrew 这个 Context Hub 对使用编程智能体更有帮助，所以大家可以去试一下。顺着这个话题，在这个新的 AI 世界里，你如何看待教育的变化？你是否已经把一些新的实践融入 DeepLearning.AI 的课程运行方式，或者融入你对教育的思考？
吴恩达：我们正在尝试很多方式来改善教育体验。就培训内容而言，已经很明确的是，人们需要学习的东西发生了显著变化。对于开发者来说，他们需要学习编程智能体，学习这些构建模块，也许还要学习一些产品管理，或者类似的通用技能，让自己更有效。
所以，我们需要学习的内容正在变化。DeepLearning.AI 和 Coursera 也一直在尝试提供这类培训。
但除了“学什么”之外，还有“怎么交付培训”的问题。我们思考“如何学习会被改变”已经很久了，但感觉真正的变化其实还没有完全到来。
几周前，我们上线了一个预览版新网站，叫 CodeDream.ai。它背后的愿景是：不要只是上在线课程，而是来进行一场对话。
这不是一门课，而是一场对话。我们想构建的体验是，你可以和我进行一场模拟视频通话。
比如，如果你想往后一靠，听我以一对一视频通话的形式给你讲 Context Hub 和编程智能体，你可以这么做，我会给你展示一些想法。
如果你想打断“我”，也就是打断我的 AI，然后问问题，你可以随时这样做。我个人也在大量尝试的一件事，是用 JavaScript 替代视频和幻灯片。这是什么意思？也就是说，当我在视频里演示某个东西时，如果你能点击进入这个视频，然后在视频窗口里输入自己的 prompt 或查询，那会怎么样？
也就是说，视频区域不是一个只能播放的静态视频，而是可交互的。这样可以创造更多和学习内容互动的方式。
如果你感兴趣，可以去试试 CodeDream.ai，和我或者我的 AI 进行某种对话。我会以 AI 形式向你展示如何使用 Context Hub 的编程智能体。
坦率地说，我们现在每天仍在迭代和改进这些体验。
Harrison Chase：你刚才说可以点击视频并输入内容，这个功能现在已经上线了吗？还是一个未来方向？
吴恩达：已经上线了。你可以想象一下，它不是我在视频里共享屏幕，而是我在视频里“共享 JavaScript”。因为它运行的是 JavaScript 代码，而不是预先录好的视频，所以你可以和我所谓的“屏幕共享”内容互动。
如果你有喜欢或不喜欢的地方，我们也非常欢迎反馈。不过，我确实觉得，教育转型在过去被过度炒作了。我认为某些变化正在到来。
但今天来说，上在线课程仍然是主流。我希望我们能拥有比在线课程好得多的东西。当然，我们现在确实已经有比十年前更好的课程了。它们互动性更强。比如今天早上，我们刚发布了一门关于 Transformer 的新课程，由 AMD 的 Sharon Jo 讲授。我发现，相比十年前主要就是视频，现在我们构建了更多交互式可视化内容。现在的课程里有很多比十年前更有趣、可以动手玩的东西。
但那种更大的教育变革，我确实花了很多时间在思考。
Harrison Chase：从软件工程扩展到其他领域，你如何看待企业采用 AI？它比你预期更快还是更慢？正确的方式是什么？大家可以从中学到什么？
吴恩达：我认为每一家企业，我猜也包括你们所有人的企业，都对 AI 采用非常兴奋。我们在很多企业身上看到了一些共同主题。我的一个团队 AI Aspire，是一家 AI 咨询公司，由我和商业伙伴 Chris Tann 共同创立。我们一直和大型企业交流，包括财富 50 强、财富 500 强、G2000 企业，讨论它们的 AI 战略和转型。
有一些一致的主题。
几乎所有企业都投资了自下而上的创新，也就是所谓“百花齐放”的策略。但总体来看，这种策略的回报并不明显。所以 CEO 和董事会都在问：AI 的 ROI 在哪里？
我认为我们仍然应该继续投资自下而上的创新，应该继续做。但事实是，自下而上的创新通常会产生点状解决方案，带来渐进式效率提升。这其实是好事，但它不是 AI 曾经承诺给我们的那种更广泛的转型，而我认为我们应该努力交付这种转型。
我用一个例子说明。我的团队正在和多家银行合作。
吴恩达：我们在金融服务领域做了很多工作。以贷款承销流程为例，它可能有五个步骤：营销贷款产品、接收申请、审核并批准贷款、做最终尽职调查，以及执行贷款。
很多团队注意到，中间的贷款审批环节可以用 AI 来做。如果我们能自动化这个环节，那么原本需要人花一小时审查贷款申请，现在可以由 AI 来完成。这很好，我们当然应该做。
但问题是，如果你的整个贷款承销流程保持不变，只是把原来一小时的人力工作自动化了，那这只是一个小的、渐进式效率提升。
所以有些银行会说，既然如此，我们不如重新思考整个工作流，推出一个“10 分钟内获批”的贷款产品。
因为我们不再需要等一个人一周之后才有一小时空闲去审查申请，我们可以马上把贷款申请发送给 AI，让它立即做出决策。但在很多企业里，真正实施这种变化的挑战在于，它需要一个拥有更大范围权限的人，重新思考和重新设计整个工作流。
因为现在你要营销一个“10 分钟获批”的产品。你需要把申请立即路由到审批环节，而不是一天后再处理。营销、数据、基础设施都需要参与进来。是的，AI 可以做初步决策。但最终尽调和执行环节可能也需要扩展能力。
所以我发现，自下而上的创新非常有价值，它会产生很多想法。但它必须和自上而下的动作结合起来，也就是需要有人拥有更广的视野和权限，能改变所有这些步骤的运作方式，从而真正创造增长。很多企业都在谈降本。
降本没问题，值得做。但我更想推动大家想象一些 AI 能做的更有想象力的事情，也就是推动增长。
因为我们能节省的钱总是有限的，但增长几乎没有实际天花板。所以我发现，更令人兴奋的想法通常和推动业务增长有关，而不只是节省成本。
Harrison Chase：你有没有看到一些通过 AI 推动业务增长的好案例？有没有哪些案例让你特别兴奋，或者你觉得其他人应该关注和学习？
吴恩达：有。刚才银行的例子就是真实案例。我们正在和一些银行、金融机构合作做这件事，其他企业也在做类似的事情。
另外一个模式是客户服务和呼叫中心。客户服务和呼叫中心通常被视为降本场景。降本当然不错。但当你能自动化客户服务，或者自动化、增强其中一部分时，你就能更快服务更多客户，从而提供更令人愉悦的客户体验，并推动增长。
我也和一些企业交流过，它们正在自动化 drive-through 的语音应用，也就是汽车穿梭餐厅的点单流程。我认为这同样能带来更好的客户体验，并推动增长。
所以我看到经济中不同地方正在出现越来越多这样的例子。
还有一些我知道的案例，但我没有权限公开讲。不过，基于我看到的企业正在做的事情，我非常有信心，未来会出现越来越多这样的案例。
Harrison Chase：你刚才提到了 ROI。根据我昨天和今天的很多交流，我知道很多人都在思考这个问题，也在思考如何衡量 ROI。在一些场景里，比如成本节省或者呼叫中心，也许比较容易衡量。但你会如何建议大家思考 ROI 衡量？有什么建议吗？
吴恩达：我希望我知道答案。我发现，挑战可能在于企业非常多样化。所以衡量 ROI 就像衡量业务本身一样，很难有一个放之四海而皆准的答案。不过有一点是，我最兴奋的那些项目，通常是可以衡量的，也应该被衡量，值得被衡量。
有些事情，我们需要“全力挥棒”，去创造非常大的价值。
在这种情况下，我们讨论的就不是“这会不会带来 2% 的增长，再减掉 1% 的实施成本”。有些项目的价值非常明显，会显而易见地改变业务。
当然，我们仍然需要衡量它，尤其是如果你是一家上市公司。
但我学到一件事：有时候，推动渐进式收益反而比推动转型式收益更难。如果你告诉某人，明年把业务结果提升 2%，他可能会觉得，好吧，老板就是让我多努力 2% 或 5%。
但如果你要寻找能带来 20% 或 50% 业务增长的方法，你不可能让全公司每个人都多努力 50%。你必须提出更有创造力的解决方案。
这经常会带来新的思路。
我在 AI Aspire 学到的一点是，很多企业真的会发给我们一张表，里面有几百个想法。
比如有一家金融机构给我们发了一张超过 300 个想法的表格，让我们帮他们判断，在这些想法中哪些值得真正投入资本。
事实证明，这个分析非常困难。我希望自己足够聪明，能一眼扫过去就说，这个想法好，那个想法好。但面对这么多想法时，通常需要进行自上而下和自下而上的头脑风暴。
这需要大量技术分析，判断哪些事情在技术上可行；也需要大量业务分析，判断哪些事情可能带来有意义的变化。
最后需要把这些想法缩小到少数几个值得投入重要资源的赌注上。
Harrison Chase：这类“全力挥棒”的项目，你通常看到它们是自上而下推动的，对吗？
吴恩达：没错。我认为企业最好不要只做一个疯狂的大赌注，而是形成一个由少数几个经过深思熟虑的赌注组成的组合。如果其中任何一个成功，都会对业务产生有意义的影响。
不过，智能体式编程让我很喜欢的一点是，我们可以运行大量实验，不断做原型。原型开发的成本已经大幅下降。
但遗憾的是，你不可能做所有事情。比如在 10 万美元预算下，你不可能什么都做。到某个阶段，对少数几个项目组合中的每一个投入有意义的资源，是合理的。
也正因为在这个级别上需要资源分配，所以往往需要更多自上而下的动作，来配置所需资源。
Harrison Chase：最近关于企业采用 AI，有一个被频繁讨论的话题是 Forward Deployed Engineer，也就是前线部署工程师。未来每家公司都会有 FDE 吗？你怎么看？为什么你认为他们这么有影响力？未来会如何发展？
吴恩达：在硅谷的流行语里，FDE 确实正处在一个高关注时刻。我知道 Aaron 前一两天也在台上非常深入地谈过这个话题。我认为 FDE 是一个很好的想法。
很多企业都会需要这种角色。但展望未来，你觉得一家公司里 FDE 的数量，和公司雇佣的普通 AI 工程师数量之间，会是什么比例？
我认为，大多数企业会拥有更多内部工程师，同时可能嵌入一小支 FDE 团队。所以我喜欢 FDE，也对这个角色的增长感到兴奋。我们应该帮助更多人获得 FDE 工作。
但我也认为，和很多事情一样，围绕它的 hype 可能比现实情况略高。不过它确实是一件好事。
构建智能体工作流是很难的。它需要理解业务，需要面向客户的能力。为了让系统可靠，通常还需要做好可观测性、评估，与客户合作，判断某些需求在技术上其实不可行，并和利益相关方一起决定应该自动化哪个工作流，还要帮助企业完成变革管理。
所以这是一个非常有价值的角色，需要很深的技术判断。让 FDE 嵌入企业，确实可以大幅加速项目。
但我也看到很多企业面临另一个挑战：有没有可能获得一个供应商中立的 FDE？
这其实很难，取决于你想让哪些供应商真正嵌入你的企业。因为我们在 AI 领域看到，领先模型变化非常快。
我不知道一年后领先的 AI 模型会是什么。我也完全不确定一年后领先的编程智能体会是什么。
所以在这种不确定时刻，选择权非常有价值。
坦白说，很多供应商都会来找我们的企业，提供 20%、30% 的折扣，但条件是签三年合同，类似这种。
我不是在给建议，只是说我自己怎么做。无论对方提供多大折扣，我个人几乎从不签超过一年的合同。因为我非常重视这种选择权，希望一年后可以和当时最好的供应商合作，而现在我并不知道那会是谁。
当我们和 FDE 合作时，企业会问的一个问题是：如果你让某家公司派来的少数几个 FDE 嵌入你的公司，并让他们把所有东西都深度绑定到某一个 AI 模型或某个平台上，这会在一两年后多大程度上降低你的选择权？
我认为，这正是很多公司正在思考和挣扎的问题。这也是为什么我个人已经多次使用 LangSmith。我认为 Harrison 把 LangSmith 做得非常易用，这一点很棒。
这类更偏供应商中立的工具非常有价值。它们可以帮助企业做观测，也可以帮助企业在长期保留选择权。供应商当然很好，企业应该和供应商合作。但从长期看，为自己保留选择权同样重要。
Harrison Chase：说到供应商中立，尤其是在模型层面，过去几天我们也多次谈到开源模型。你怎么看这些模型的发展？你如何看待它们和前沿模型之间的关系？
吴恩达：这件事很有意思。开放权重模型似乎一直稳定地落后前沿模型大概六到九个月。但前沿模型足够昂贵，所以在很多使用场景里，我的团队也会大量使用开放权重模型。有时候我们会做微调，有时候不微调。所以我希望大家能继续支持开放权重模型。
过去两周，我听到白宫方面出现了一些让我担心的声音，比如在模型发布前进行检查。我对此其实非常担忧，也和政府里的一些朋友保持沟通。
我感觉，针对开源模型和开放权重模型的战争仍然在继续。有时候它以“美国与中国竞争”的名义出现，有时候则以其他各种理由出现。
但我认为，如果我们能共同保护开源和开放权重模型，这会让世界变得更丰富，也会帮助我们所有人保留选择权。
Harrison Chase：我和一些人讨论过一个问题：在围绕数据构建 Agent 之前，先把数据战略做好非常重要。当你和那些正在构建 Agent 的公司合作时，它们大概率也希望这些 Agent 以某种形式连接到数据。你看到哪些做法比较有效？这些要求最终可以归结为什么？
吴恩达：这是一个很好的问题。在 AI Aspire 和大型企业交流时，一个非常常见的痛点是：它们需要重新思考数据架构。过去 10 年、20 年里，我们投入了大量精力来组织结构化数据，比如表格、关系型数据、电子表格。这当然很好，现在也依然重要。
但如今 AI 可以处理非结构化数据，比如文本、图片、PDF 文件、音频，也许还有视频。如何组织这些数据，让它们能在正确的时间、正确的位置被 AI 或 Agent 使用，并创造价值，突然变得比过去重要得多。
我也花了很多时间观察这个市场。现在有很多供应商开始谈如何处理非结构化数据，但我还没有找到一个真正让我特别满意的好方案。
所以在我的团队里，包括 AI Fund 和 AI Aspire，我们正在做一堆有点疯狂的实验，尝试重新架构我们自己的数据。如果这些实验真的有效，我之后可能会讲更多。
但我确实花了很多时间思考，如何重新架构我们内部的非结构化数据，让这些数据能在合适的时间交给 Agent 使用。
我预见到，就像很多企业过去曾经面对非常大的结构化数据架构问题一样，未来几年，很多企业也会出现非常大的数据架构改造项目。规模可能达到数千万美元，甚至数亿美元。目标是重新思考数据架构，让数据变得更 AI-ready，或者说更 agent-ready。
Harrison Chase：现有数据架构的问题在哪里？为什么它们还不够 AI-ready 或 agent-ready？
吴恩达：问题很多。首先是碎片化、治理问题，数据到处都是，没有统一的共识模式。有些数据甚至还放在某个人的笔记本电脑上。
还有权限问题。很多权限系统原本是为人类设计的，而不是为 Agent 设计的。那么 Agent 是否继承我的权限？我们如何管理治理和可观测性？
我觉得我们都见过这种情况：很多企业有大量 PDF 文件，堆在巨大的存储桶里，过去 20 年都没人看过。在金融服务领域，很多文档是出于合规原因被保存下来的。以前没人有时间看这些东西，所以看它们没什么意义。但现在，如果让 AI 去整理和分析这些内容，就会变得非常有价值。
顺便说一个小点，这不完全属于整个数据架构话题，但我想 CJ 接下来会发言。我想分享一个自己在 AI 编程中学到的小经验。希望 CJ 不介意我这么说。我个人经常使用 MongoDB。
我们当然都喜欢关系型数据库。但我发现，当我快速迭代和原型开发时，重新设计数据库 schema 是一件非常烦人的事情。
我们大概都经历过那种情况：让 AI 做数据库迁移，结果它做了一些“聪明”的事，比如把整个数据库删掉。虽然这几乎不会发生，但它不是永远不会发生，这一点就有点烦人。
所以我发现，如果使用 NoSQL，我可以先把任何我想要的数据扔进数据库，然后在读取时再去处理 schema，而不是在写入数据库时就固定 schema。这会让我迭代得快得多。当然，NoSQL 并不总是适合最大规模的生产负载。对于非常大型的企业级生产系统，最终我还是会更多使用关系型数据库，或者更可扩展的解决方案。
但我认为，如今 NoSQL 的可扩展性比很多人想象得更强，而且它能推动更快的迭代节奏。
我有时候会特别沮丧：已经设计好了一个数据库 schema，结果突然发现，糟糕，我想加一个字段。然后你就不得不重构整个数据库，这真的很烦。
所以我认为，这些都是我们为了更快迭代而调整工作流的例子。既然 AI Agent 写代码这么快，我们就不要再被其他事情拖慢。
原视频链接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。