吴恩达最新对话：MCP如同蛮荒西部，而氛围编程太误导人 | 全文

主持人 Harrison： 我很期待接下来的环节。我们将与吴恩达进行炉边谈话。在座的各位对他可能都很熟悉，很多人也许上过他在 Coursera 或 deep learning.AI 上的课程。吴恩达在 Langchain 的发展历程中也扮演了重要角色。两年多前我在一个会议上遇到了他，当时我们开始谈论 Langchain，他慷慨地邀请我们合作开设了一门关于 Langchain 的 deep learning.AI 课程。这应该是他们开设的第二门或第三门课程。我知道在座的很多人看过那门课，或是因此开始使用 Langchain。所以吴恩达在 Langchain 的发展道路上扮演了极其重要的角色。我非常激动能邀请他上台进行炉边谈话。让我们欢迎吴恩达。感谢您的到来。

吴恩达： 顺带一提，Harrison 人真的很好。他和他的团队在 deep learning.AI 上已经提供了六门短期课程，涉及净推荐值等内容。Harrison 的课是评分最高的课程之一。所以，Susie，你应该去看看 Harrison 的所有课程。我觉得 Vincent 关于 LangGraph 的那门课，对许多智能体概念的解释是我见过最清楚的。

主持人 Harrison： 你们确实帮助我们改进了课程和解释，所以我们也要感谢你们。在这个行业里，你显然接触并思考过很多事情，但我经常引用、大家可能也听我谈论过的一点是你的看法：与其争论某个事物是否“是”一个智能体，不如探讨其“智能体化程度”。既然我们现在是在一个智能体大会，也许我们应该把它改名为“智能体化大会”？你能否就此澄清一下？你提出这个看法大概是一年半到两年前，我想知道你在这方面的看法是否有改变。

吴恩达： 我记得，大概一年多前，Harrison 和我都在同一个会议上发表演讲。当时我们俩都在努力说服其他人：智能体是真实存在的，我们应该关注它们。那时候，在去年夏天之前，这个词被到处滥用，失去了其原有的意义。但回到你的问题，大约一年半前，我确实看到很多人在争论某个东西是不是一个智能体。争论点在于：它是否真正自主？或者它不是一个智能体？我认为争论本身并非完全没有价值，但如果作为一个社区，我们能认识到事物可以具备智能体化程度的不同等级，我们会做得更好。如果我们简单地说你想构建一个具有少量自主性或大量自主性的智能体化系统，这都没有问题。没有必要花费时间争论某个东西是否真正是一个智能体。我们不如把所有这些都称为具有不同自主性程度的智能体化系统。我认为这种方法确实减少了人们浪费在争论某个东西是不是智能体上的时间。通过这样做，我们可以简单地将它们都称为智能体化系统，然后更富有成效地向前发展。所以我觉得这个方法确实奏效了。

主持人 Harrison： 在这个从少量自主性到大量自主性的范围里，你认为现在人们主要在构建哪一类系统？

吴恩达： 是的。我的团队通常使用 LangGraph 来解决我们最困难的问题，比如复杂的流程等等。我也看到了大量的商业机会，坦白说，它们是相当线性，或基本线性的工作流，只是偶尔有分支。在很多业务中，有一些机会是目前人们正在做的：查看网站上的表单、进行网络搜索、查询某个数据库以确定是否存在合规问题，或者是否存在我们不应该向其销售某些东西的人。在业务流程中，实际上有很多相当线性，或基本线性、分支非常小的流程，这些分支往往意味着流程的失败，会拒绝这个工作流。所以我看到了大量的机会。我看到企业面临的一个挑战是，仍然很难识别业务中正在完成的一些任务，并将它们转化为智能体工作流。你应该以怎样的粒度将这些任务分解为微任务？在构建了最初的原型之后，如果效果不够好，你应该改进哪些步骤来提升性能？我认为如何识别人们正在做的一系列任务，将其分解为有序步骤，找出少量分支，并建立相应的评估体系——我认为所有这些技能都非常稀缺。当然，更复杂的智能体工作流，涉及非常复杂的循环，也非常有价值。然而，无论从数量还是价值来看，我在那些我认为仍在构建中的更简单的工作流中看到了更多的机会。

主持人 Harrison： 我们来谈谈其中的一些技能。你在做 deep learning.AI，我认为很多课程都致力于帮助人们构建智能体。那么，你认为各种智能体构建者都应该掌握和入门的技能有哪些？

吴恩达： 唉，这是个好问题。我真希望自己知道更好的答案。最近我确实一直在思考这个问题。我认为很多挑战在于，如果你有一个业务流程工作流，通常是合规、法务、人力资源等部门的人在执行这些步骤。如何建立底层机制，无论是通过 LangGraph 式的集成，还是看看 MCP 是否也能提供帮助，来摄取数据？然后，如何进行提示或处理并执行多个步骤来构建这个端到端系统？我发现一个常见的问题是，很多人没有建立正确的评估框架，不仅要理解整个系统的表现，还要能追溯到具体步骤，找出问题所在（例如，是哪个步骤或哪个提示出了问题），从而进行改进。我发现很多团队在使用人工评估时，可能耗时过长，每次进行调整后，你都要坐在那里查看大量的输出结果。我觉得大多数团队在建立系统性评估方面往往比理想情况要慢。然而，我发现要具备正确的直觉来判断项目下一步该做什么仍然非常困难。初学者团队，那些仍在学习这些技能的团队，经常会走入死胡同，花费几个月的时间去尝试改进某个组件。而更有经验的团队会说，我觉得这个方法根本行不通，还是换个思路解决这个问题吧。我希望自己知道更有效的方法来获得这种近乎触觉般的知识。这需要你深入查看（输出、追踪日志，例如 LangSmith 的结果），并在几分钟或几小时内迅速判断下一步该怎么做，这仍然非常困难。实际上，我认为是兼而有之。在过去几年里，AI工具公司创造了一系列令人惊叹的工具。这包括像LangGraph这样的框架，考虑如何做RAG，如何构建聊天机器人，如何处理记忆，如何构建评估（evals），以及如何构建防护措施（guardrails）等等。这是一个非常广阔、多样且令人兴奋的工具集。

我脑海中经常浮现一个画面：如果你只有紫色的乐高积木，你搭不出多少有趣的东西。我认为这些工具就像乐高积木。你拥有的工具越多，就像你不仅有紫色的积木，还有红色、黑色、黄色和绿色的。拥有更多不同颜色和形状的积木，你就能非常快速地组合出令人惊叹的成果。许多这样的工具，正如我之前提到的，可以看作是不同类型的乐高积木。当你尝试构建某物时，有时你需要那种特定形状、有些弯曲的积木——有些人知道它，能立即拿来用，并有效解决问题。然而，如果你从未构建过某种类型的评估，你最终可能会多花三个月时间，去摸索别人已经掌握的方法。比如，你可能没意识到应该如何利用评估元素（elements judged）以某种方式构建评估，并遵循某个流程，这样会快得多。AI开发并非只需要单一工具。就像我写代码一样，我使用一整套不同的资源。我不是所有工具都精通的大师，但我学会了足够多的工具，可以快速将它们组合起来。我认为，练习使用不同的工具也有助于更快地做出决策。另一个重要方面是它会随着时间变化。例如，由于大型语言模型（LLMs）的上下文记忆（context memory）越来越长，一年前关于RAG的许多最佳实践，如今已经不太相关了。我记得Harrison很早就参与了许多这些发展。我尝试过早期的Langchain、RAG框架、递归摘要（recursive summarization）等等。随着大型语言模型上下文记忆变得更长，我们现在会将更多信息直接放入模型上下文（LLM contexts）中。这并不是说RAG消失了，而是超参数调整变得更容易了，并且有很大范围的超参数都可以正常工作。随着大型语言模型不断进步，我们两年前积累的直觉，如今可能不再适用。

主持人 Harrison： 你提到了很多我想谈论的事情。那么，目前有哪些被低估的“乐高积木”，你认为人们还没怎么谈论，但你会推荐他们去了解？比如评估（evals），我们已经有三个人谈论过评估了，我认为那是人们关注的焦点。但还有哪些是大多数人可能还没想到或没听说过的，你会推荐他们去研究的？

吴恩达： 好问题。我不知道。或许我可以分享这个。尽管人们谈论评估，但出于某种原因，人们并不去做。

主持人 Harrison： 你觉得为什么他们不去做？

吴恩达： 我认为这可能是因为人们常觉得... 我看到有人提过‘评估写作障碍’（evals writer's block）。人们认为编写评估是一件非常庞大、必须做到完美的事情。而我认为，评估是我能在20分钟内快速拼凑出来的东西。它可能不完美，但能开始补充我的手动评估。所以通常会发生的是，我构建了一个系统，然后出现一个问题，我总遇到回归现象——以为修好了，结果又坏了。这种情况每个人都遇到过，非常烦人。这时我会快速编写一个非常简单的评估，可能只有五个输入示例和几个简单的评估点，专门用来检查这个回归问题，看它是否再次出现。我并非用自动化评估完全取代手动评估，我仍然会查看输出。但当我进行调整时，运行这些评估可以减轻我的负担，不必每次都重头检查。然后，就像我们写文章一样，一旦你有了某个稍微有点帮助但显然很粗糙、不完美的评估，你就会开始想：‘我可以改进它，让评估变得更好。’所以，就像我们构建许多应用程序时那样，先快速搭建一个非常简陋、可能还不完善的原型，然后逐步改进。我构建评估的很多时候，都是先写一些非常基础、几乎没啥用的评估。当你看到它实际运行时，你就会意识到：‘这个评估有问题，我可以修复它。’然后，你就能一步步把它完善起来。

我认为被低估的其他一些事情；另一个值得关注的点，或许不是被低估，而是更多企业亟需去做的事。我认为你们许多人都看到，在编码中使用AI助手的开发者比不使用的开发者快得多。令人意外的是，仍有不少公司，包括一些首席信息官（CIO）和首席技术官（CTO），其政策竟然还不允许工程师使用AI辅助编程。我认为这有时可能有其理由，但我认为我们必须跨越这个障碍，因为说实话，我的团队和我都发现，没有AI助手编写代码简直难以忍受。我认为一些企业仍然需要克服这一点。

我认为被低估的一个想法是，我认为每个人都应该学习编程。AI Fund的一个有趣事实是：从前台接待员到我的首席财务官（CFO）和法律总顾问（general counsel），我们AI Fund的每个人都懂得编程。这不是说我想让他们成为软件工程师，他们也不是。但在各自的岗位上，通过学习一点点编程，他们能够更有效地向计算机发出指令，从而显著提升工作效率。这一点也令人兴奋。

主持人 Harrison： 谈到AI辅助编程，你个人使用哪些工具？

吴恩达： 我们正在开发一些尚未宣布的东西，太令人兴奋了！我用Cursor、Windsurf以及其他一些工具。

主持人 Harrison： 好的，我们稍后再回过头来谈那个。说到语音，如果这里的人想涉足语音领域，并且熟悉使用大型语言模型（LLMs）构建智能体（agents），这有多相似？有很多想法是可迁移的吗？或者有什么是全新的？他们需要学习什么？

吴恩达： 在很多应用场景中，我认为语音是至关重要的。它能创造出更加引人入胜的互动。从应用的角度来看，输入文本提示有时可能会让人感到畏缩或困难。在许多应用中，我们接触用户时会说，“告诉我你的想法”。但当用户面对一个大大的文本框，并被要求写大量文字时，很多人会觉得无从下手。其中一个问题是，人们会使用退格键，导致通过文本的响应速度变慢。相比之下，使用语音时，时间是持续流动的，用户只需要不停地说。他们可能会改变主意，或者说“哦，我改变主意了，之前的那些都忘掉吧”，而我们可以很好地处理这些变化。

我发现，鼓励用户采用语音交互，能显著降低许多应用的整体用户阻力。我们可以简单地问用户“告诉我你的想法”，他们就可以口头回答。在语音技术方面，一个最重要的区别是延迟。如果有人说了什么，我们理想情况下希望在不到一秒的时间内做出回应，最好是在500毫秒以内。然而，许多智能体工作流程可能需要几秒钟。例如，当DeepMind.ai与RealAvatar合作构建我的数字分身时，最初的版本有五到九秒的延迟，这导致用户体验非常糟糕。用户说完话后，会有九秒钟的沉默，我的分身才会回应。

为了解决这个问题，我们开发了一些功能，比如“预响应”（pre-response），这样当用户提问时，我可以提供一些提示语，比如“嗯，这很有趣”或者“让我考虑一下”。这种方法有助于掩盖延迟，并且已被证明是有效的。还有各种其他技术。例如，在语音客服机器人中，播放类似呼叫中心的背景音，能让用户对延迟的容忍度显著高于一片寂静的情况。

总的来说，我相信纯文本交互与语音交互之间存在许多关键差异。当语音模式能让用户感到舒适并参与对话时，它会显著降低获取信息的阻力。当我们说话时，不像书面交流那样感觉需要做到完美。这使得人们更容易表达他们的想法、改变主意并进行你来我往的对话。这最终能帮助我们收集到推动用户继续所需的信息。

主持人 Harrison： 嗯，这很有趣。当前出现的一个新事物，你刚才也简要提到了，是MCP。你认为它正如何改变人们构建应用的方式、应用类型，以及整个生态系统？

吴恩达： 我认为这真的令人兴奋。今天早上我们刚与Anthropic合作发布了一个关于MCP的短时对话（short talk）。我在网上看到许多关于MCP的信息，坦白说，我觉得相当令人困惑。所以当我们在Anthropic聚在一起时，我们说，我们应该创建一个关于MCP的真正优秀的短时对话，清晰地解释它。我认为MCP非常棒。我认为它填补了一个非常明显的市场空白，OpenAI也采用了它，这本身就说明了其重要性。我认为MCP标准将继续发展。

例如，你们许多人都知道MCP是什么，对吧？它主要使得智能体更容易接入不同类型的数据源。说实话，当我构建应用程序，使用大型语言模型（LLMs）时，我们很多时间花在了基础架构上。对于那些来自大型企业的人来说，人工智能，特别是推理模型，非常非常智能，只要提供正确的上下文，它们可以做很多事情。然而，我发现我的团队花费大量时间在基础架构和数据集成上，以便将上下文提供给大型语言模型，让它在拥有正确的输入上下文时能做出合理的反应。

所以，MCP是一种非常棒的方式来尝试标准化接口。现在有很多工具、API调用和数据源，感觉有点像蛮荒西部。你在网上找到的许多MCP服务器都无法工作，身份验证系统有些笨拙，即使对大型公司也是如此。对于MCP服务器，身份验证令牌是否完全有效以及何时过期，总是不清楚，这种情况很多。我认为MCP协议本身也处于早期开发阶段。

现在，MCP提供的是可用资源的长列表。然而，最终，我认为我们需要某种更具层次结构的发现机制。想象一下，你想构建某种东西——也许会有一个MCP接口到LangGraph——但是LangGraph有如此多的API调用，你不可能为智能体提供所有可能的接口的长列表让它去整理。所以我认为某种形式的层次结构发现机制是必要的。

总的来说，我认为MCP是一个非常棒的第一步。我绝对鼓励你们了解它。如果你能找到一个好的MCP服务器实现来帮助进行一些数据集成，你的生活可能会因此变得更容易。N个模型或N个智能体与M个数据源相结合，不应意味着需要N乘以M的工作量来进行所有集成；而应该是N加上M。我相信MCP是实现这种数据集成的重要第一步。

主持人 Harrison： 另一种协议，它的热度不如MCP，是一些智能体到智能体（agent-to-agent）的东西。我记得大约一年前我们参加一个会议时，你似乎谈论过多智能体系统，这正是智能体到智能体协议可能实现的功能。那么，你如何看待一些多智能体或智能体到智能体技术的发展？

吴恩达： 我认为智能体人工智能仍然处于非常早期。我们大多数人，包括我自己，甚至都在努力让自己的代码正常运行。因此，让我的代码，我的智能体，与别人的智能体协同工作，感觉需要两个奇迹才能实现。

所以我认为，当一个团队构建一个多智能体系统时，它通常会成功，因为我们构建了一批智能体，它们可以相互交互。我们理解协议，所以这是可行的。

但目前，至少在眼下这个时刻，也许我的看法是错误的，我看到的案例中，一个团队的智能体或智能体集合成功地与另一个完全不同的团队的智能体或智能体集合进行交互的例子相当有限。我认为我们离那一步还尚早。

我确信我们最终会实现，但我个人还没有看到这方面的真正成功，巨大的成功案例。我不确定你是否看到了。

主持人 Harrison： 不，我同意。我认为这非常早期。如果说MCP还算早期，那么智能体到智能体的东西就更早了。另一件人们目前比较关注的事情是所谓的“氛围式编程”（vibe coding）及其相关的一切。你之前也稍微提到了人们如何使用这些AI编程助手，但你是怎么看待“氛围式编程”的？这是一种不同以往的技能吗？它在这种新的范式下有什么样的作用？

吴恩达： 我认为我们许多人现在能够以更少的代码审阅来完成开发任务，我认为这非常棒。但很不幸，这个现象被冠以“氛围式编程”之名，因为它误导了很多人，让人以为这是种随意的、靠感觉的编程方式，只要凭感觉来，接受这个，拒绝那个。说实话，使用“氛围式编程”或AI编程助手写一天代码后，我在一天结束时感到非常疲惫。这是一项深刻的智力活动。所以我认为这个名字不太恰当，但这种现象是真实存在的，并且正在流行，而且很棒。

在过去一年里，有些人建议其他人不要学习编程，理由是AI将自动化编程。我认为将来我们回顾时，会发现这是史上最糟糕的职业建议之一。因为在过去的几十年里，随着编程变得更容易，更多人开始学习编程。事实证明，当我们从打孔卡发展到键盘和终端时，当时就有人争论说，我们已经有了COBOL，编程变得如此容易，不再需要程序员了。显然，当编程变得更容易时，更多人学会了编程。AI编程助手的出现，理应鼓励更多人学习编程。

我认为未来最重要的技能之一，无论对开发者还是非开发者而言，是能够清晰准确地向计算机表达意图，让它为你完成任务。对计算机工作原理有所了解，能让你向计算机发出提示或指令时更加精准有效。这就是为什么我仍然试图建议每个人学习一种编程语言，比如Python或其他什么。

你们中的许多人可能知道，我可能认为自己比JavaScript开发者更擅长Python编程。然而，有了AI编程助手，我现在编写的JavaScript和TypeScript代码比以前多得多。即使在调试别人为我写的JavaScript代码时，理解错误情况以及它们意味着什么，对我有效地调试JavaScript代码也非常重要。

主持人 Harrison： 如果你不喜欢“Vibe Coding”这个名字，你有没有想到更好的名字？

吴恩达： 哦，这是个好问题。我应该好好想想。

主持人 Harrison： 我们回头再讨论这个问题。这确实是个好问题。你最近宣布的一件事是为 AI Fund 成立了一支新基金，恭喜。对于在场可能正在考虑创业或对此感兴趣的人，你有什么建议给他们？

吴恩达： 哦，谢谢。AI Fund是一家风险投资工作室，我们自己创办公司，并只投资于我们共同创立的企业。回顾 AI Fund 以及我们学到的经验教训，我会说，一家初创企业成功的首要决定因素是速度。我知道我们在硅谷，但我发现许多人从未见识过一支精干团队能达到何等的执行速度。如果你从未见过（虽然我知道你们很多人见过），它远超那些行动迟缓的企业所能企及的速度。同样关键的第二大决定因素，是技术洞察力。审视创办一家初创企业所需的技能，市场营销、销售和定价等要素固然重要，这些知识也相对普及。然而，真正稀缺的，是对技术实际运作方式的深刻理解。拥有深刻的技术洞察力是无价的。我非常尊敬那些擅长市场进入策略的人；定价、市场营销和定位都非常困难。然而，相比真正理解技术复杂性这种稀缺资源，这些技能相对更容易获取和普及。在 AI Fund，我们倾向于与技术功底深厚、直觉敏锐、深知哪些方向值得探索、哪些应避免的个人合作。这种深刻理解能让团队的执行速度至少提升一倍。在当今快节奏的环境中，技术洞察力是推动创新的关键，相较之下，这些商业技能通常更容易习得。

主持人 Harrison： 好的，这是关于如何创业的极好建议。我们要结束这一环节了。现在我们要进入休息时间，但在那之前，请大家和我一起热烈鼓掌感谢 Andrew。

参考资料: https://www.youtube.com/watch?v=4pYzYmSdSH4