图片来源：LangChain

Z Highlights：

• 我们常把LangGraph、RAG、memory、evals等工具比作乐高积木，经验丰富的人知道如何搭配使用，就能迅速解决问题。

• 我现在已经无法忍受‘没有AI助手’的编程体验。

• 语音是一种更自然、更轻量的输入方式，降低了用户交互门槛，尤其适合Agentic应用。

• 未来最关键的技能，是能准确告诉计算机你想要什么——这就是AI时代的新编程语言。

在LangChain主办的Agent大会上，吴恩达（Andrew Ng）与Harrison进行一场炉边深度对谈，围绕Agentic系统构建、MCP协议、语音交互、AI辅助编码等多个前沿话题展开交流。这场访谈不仅回顾了过去一年Agentic技术的发展路径，也分享了构建AI系统时“从流程拆解到评估体系”的实操经验。访谈于2025年5月29日发布。

从“是否是Agent”到“Agentic性光谱”：构建AI系统的新思维

Harrison：我对接下来的这一部分感到非常兴奋。我们将与吴恩达进行一场炉边对谈。对于在座大多数人来说，吴恩达可能无需太多介绍。我猜很多人都上过他在Coursera上关于深度学习的课程。而且吴恩达其实也是LangChain故事的重要一部分。我大约两年多前在一场会议上首次见到吴恩达，当时我们刚开始谈论LangChain。

他非常慷慨地邀请我们与他合作，为DeepLearning.ai开设一门关于LangChain的课程。我记得那大概是他们开设的第二或第三门课程。我知道现场很多人也可能是通过这门课开始接触LangChain的。因此，吴恩达对LangChain的发展起到了至关重要的作用。我非常激动能邀请他来到现场进行这次对谈。欢迎吴恩达！

吴恩达：顺便说一句，Harrison真的很谦逊。到目前为止，Harrison和他的团队已经开设了六门关于深度学习和AI的短课程。从我们的指标来看，包括净推荐值等，Harrison的课程是评价最高的之一。所以Susie，你应该把Harrison的所有课程都上完。他那门关于LangGraph的课程，是我见过对Agentic概念解释最清晰的之一。

Harrison：他们确实帮助我们将课程内容和解释做得更好。对此也要感谢你们。你在这个行业显然涉猎广泛，思考深入。我经常引用你提出的一个观点，很多人可能也听我提到过，就是你提出的“应用的Agentic性”这一说法，而不是单纯讨论某个系统是否是一个“Agent”。现在我们正身处一场Agent大会——或许应该称作“Agentic大会”，你能否再次阐明你的观点？大约在一年半或两年前你说过这些话，我很好奇你现在是否有新的看法。

吴恩达：我记得那次会议，Harrison和我都在场。当时我们俩都在试图说服其他人“Agent”是一个值得关注的方向。那还是在“Agentic”这个词被一大批市场人员广泛采用之前，他们把这个标签贴在各种产品上。回应Harrison的问题，大约一年半前，我看到很多人都在争论：“这个系统算是Agent吗？是不是太不‘自治’了？”这种争论可以理解，但我觉得我们作为一个社区，如果能转而讨论“Agentic性”的程度，可能会更有效。

也就是说，如果你构建一个Agentic系统，不管它具备少量还是大量自治能力，都是合理的。我们无需浪费时间去判断“它是否真正是一个Agent”。我们可以把它们统称为Agentic系统，自治程度各有不同。这样做，我想能有效减少关于“定义”的无谓争论。从结果来看，这个思路是奏效的。

Harrison：那在从“部分自治”到“高度自治”的这个光谱中，你观察到现在大家在实际构建中更倾向于哪一端？

吴恩达：我们团队在处理最复杂的问题时经常使用LangGraph，例如需要处理复杂流程的情况。但我也看到很多商业机会其实更偏向线性流程，或者只有很少的分支。在很多企业中，目前仍然是由人工执行一些非常线性的流程：比如浏览网页表单、进行网页搜索、检查数据库是否存在合规问题，或判断是否可以对某人销售某些产品。

这些流程往往是“复制-粘贴-再搜索-再粘贴”的模式。大多数情况下，企业内部的工作流其实是线性的，偶尔出现的分支通常也是失败路径，比如“拒绝该流程”。我看到这类简单流程的机会非常多，但问题在于：很多企业仍然难以将已有工作流拆解为Agentic系统。也就是说，如何把一个复杂流程合理拆分为一系列“微任务”？当你构建了一个原型系统后，如果效果不理想，又该对哪一个步骤进行优化？“将流程分解为顺序步骤，并设置评估点”这类技能在当前企业中仍极其稀缺。当然，也存在非常复杂的Agentic工作流，比如带有复杂循环的系统——它们同样很有价值。但就“机会数量”而言，我观察到更大一部分场景仍集中在“较简单、尚未被充分自动化的流程”上。

Harrison：那我们就来谈谈这些构建技能吧。你一直在推动深度学习的普及，很多课程也在帮助人们构建Agent。你认为Agent构建者应该掌握哪些关键技能？从哪一步入门比较好？

吴恩达：好问题。我最近也一直在思考这个问题。很多企业流程中，都涉及合规、法务、人力资源等部门的人执行各种步骤。那么，如何通过类似LangGraph这样的集成方式，或是依赖未来MCP的发展，建立一个数据流入、提示生成、流程串联的完整系统？这是一个挑战。

还有一个常被忽视的问题是：如何建立一个良好的评估体系？不仅要了解整个系统的表现，还要能够追踪到每一个子步骤。我观察到很多团队仍然依赖“人工评估”，每当系统有变更，就需要反复人工查看结果是否正确。而很多团队并没有及时建立起系统性评估流程，这是一个效率瓶颈。经验丰富的团队通常能更快发现：“这个模块没法修好，换路径吧。”而经验尚浅的团队，常常会在错误路径上浪费数月时间。

我希望有更高效的方式去传授这类“触感式判断”。比如看LangSmith的trace，看一堆output，你往往需要在几分钟甚至几小时内作出决定。但这仍然很难。

Harrison：你说的这种“触感式判断”，主要是围绕LLM的局限性，还是更偏产品架构那一侧，比如将任务拆解为结构化流程？

吴恩达：其实两者都有。过去几年AI工具公司创造了很多优秀工具，比如LangGraph，还有诸如RAG、ChatBot设计、memory策略、evals、guardrails等等。这些都非常有用。我常把这些工具比作乐高积木。如果你手上只有紫色的乐高砖，你能搭建的东西是有限的。但如果你有红色、黑色、黄色、绿色等不同形状与功能的积木，你就能快速搭建出复杂系统。

所以，我常常把这些工具当作“积木组件”。经验丰富的人知道哪一块能派上用场，知道怎么组合，就能迅速解决问题。而经验不足的人，可能会因为不熟悉某种eval机制而多花三个月做重复劳动。AI开发并不是只靠一个工具完成。我写代码时会用到很多不同组件。虽然我不是每种工具的专家，但我学会了足够多的工具，能够快速组合使用。

掌握这些工具之后，也能更快做出决策。而且还有一点要注意：随着LLM的context window不断扩大，很多旧有的“最佳实践”已不再适用。比如早期的RAG做法，如今的超参数调整变得更简单——因为LLM能容纳更多内容了。

被忽视的“乐高组件”：从轻量Evals到语音技术栈的巨大潜力

Harrison：你刚才提到了很多内容，那有哪些你觉得现在被“低估”的乐高组件？比如evals，现在很多人谈论evals，我们也安排了三位讲者，但你有没有一些大多数人还没注意到的方向？

吴恩达：好问题，我也不确定。但即使大家在谈evals，实际上很少人真的去做。

Harrison：你觉得为什么大家不做？

吴恩达：很多人把写evals当作一件很重的工作。我不是这样看的。我通常会在20分钟内拼出一个初步的eval，虽然效果不够好，但可以辅助我用肉眼判断系统表现。

比如，我经常遇到某个功能“修好了又坏、修好了又坏”的情况，这很烦。我就会写一个简单的eval脚本，只测这个regression是否再次出现，可能只有5个测试用例，用LLM做个简单打分。这并不是要完全替代人工评估，我仍然会人工检查输出，但这个eval可以帮我节省脑力成本。然后你会发现，这个简单的eval虽然破碎，但有用，于是你开始迭代改进它，就像我们开发应用一样，从“能跑起来”开始，逐步优化。

很被低估的是voice stack（语音技术栈）。我和很多朋友、企业合作伙伴都在推进语音应用，尤其是大型企业，他们对voice use case非常感兴趣。虽然社区中也有开发者在做语音项目，但远低于我在产业侧看到的实际需求。并非都涉及speech-to-speech模型，很多时候我们使用的是Agentic voice stack工作流，具有更强的可控性。我目前正在和多个团队合作voice stack项目，其中一些将在不久后对外发布，结果令人期待。

还有一个也许不是“被低估”，但“被企业忽视”的点是：AI-assisted coding。现在很明显，使用AI辅助写代码的开发者比不使用的效率高很多。但我发现仍有不少CIO、CTO还禁止工程师使用AI助手。我可以理解他们的顾虑，但真的——我现在已经无法忍受“没有AI助手”的编码体验。

再分享一个好玩的事：在AI Fund，包括前台、CFO、法务总顾问在内的所有员工都会编程。我不是要他们成为程序员，而是希望他们能学会“怎么让计算机理解自己的意图”。哪怕是一点点编程能力，也能在他们的本职工作中大幅提升效率。

Harrison：关于AI辅助编程这件事，你个人在使用哪些工具？

吴恩达：我们目前正在开发一些尚未公开的项目。

Harrison：听起来很令人期待。

吴恩达：是的。我个人现在也在使用Cursor、Windsurf，还有其他一些工具。

Harrison：好，那我们稍后再聊这些。接着聊聊语音。如果在场有人想进入语音应用领域，但他们已经熟悉用LLMs构建Agent，这两个方向之间有多少是可以迁移的？他们还需要学习哪些新内容？

吴恩达：实际上，很多应用中语音都很重要。它带来了不同的交互方式。我们发现，从应用角度看，输入文本提示往往令用户感到压力。比如你让用户面对一段提示词框，说“请写下你的想法”，很多人其实会感到不安。

用户在打字时总想修改，会不断使用退格键，所以他们反应更慢。而语音是线性的，时间向前推进，用户只需要继续说话，即使改主意也可以说“我刚刚说错了”。这些系统处理得也很好。我发现，在语音交互中，用户使用门槛更低。你只需要说“请告诉我你的看法”，他们就开口了。

语音系统和文本系统的最大技术差别在于延迟。比如，当用户说完一句话，你必须在不到一秒内做出响应——最好是500毫秒以内，但最多也不能超过1秒。而现在很多Agentic工作流的响应时间都超过几秒。比如我们DeepLearning.AI与RealAvatar合作开发的数字人（你可以在我们网页上与我的数字分身互动），早期版本的响应延迟为5到9秒，这种体验非常差。用户说完话，等了9秒钟才开始回应。

所以说，语音系统与传统文本型LLM确实存在不少差异。但在很多应用中，语音模式可以降低用户心理门槛，鼓励他们表达观点。人们在说话时不会像写作时那样追求“完美”，这使得他们更容易自然地表达、反复修正，从而帮助我们更好地获取信息，推动对话进程。

Harrison：很有趣。

吴恩达：是的，确实如此。

MCP与多Agent的未来、AI编程的转变与初创加速秘诀

Harrison：你刚才提到了MCP，这是当前讨论度很高的新协议之一。你怎么看MCP正在如何改变应用构建方式？生态系统中有哪些趋势？

吴恩达：这真的令人振奋。今天早上我们刚刚和Anthropic一起推出了关于MCP的简短课程。我在网络上看到很多对MCP的解释都挺混乱的。所以我们决定与Anthropic合作，制作一门高质量的MCP简明课程，帮助大家准确理解。MCP是一个非常棒的概念，明确地填补了市场空白。OpenAI也采用了它，说明了它的重要性。MCP标准还会继续演进。它能显著简化Agent，甚至其他类型软件与不同数据源的对接过程。

现在我们在使用LLMs时，常常把大量时间耗在“数据管道”上。尤其在大型企业中，我们的模型其实非常聪明，只要给出合适的上下文，它们就能做出合理判断。所以我们花了很多时间做数据集成，目的就是为了让模型能获取正确的上下文并发挥能力。

MCP的核心优势就是：它试图为API调用和数据源接口建立统一标准。这感觉就像“狂野西部”，目前网络上的许多MCP服务并不稳定，验证机制也不完善，就连大公司发布的服务，验证令牌是否有效、是否过期，都经常存在问题。目前MCP协议还处于初期阶段。比如它目前只能列出所有可用资源，但将来我们可能需要层级式资源发现机制。

想象一下，如果LangGraph将来有MCP接口，它有成百上千个API调用，如果都用一个扁平列表列出来，Agent根本没法处理。所以我们会需要更具结构性的发现机制。MCP是一个非常棒的第一步。如果你找到一个靠谱的MCP服务实现，它将大大简化你的数据对接流程。这背后理念是：如果你有N个模型/Agent，M个数据源，集成成本不应是N×M，而应是N+M。MCP正是向这个方向迈出的第一步，未来还需演进，但前景值得期待。

Harrison：除了MCP，还有一个关注度没那么高的方向，就是Agent-to-Agent通信。我记得我们大约一年前在一场会议上，你也提到了多Agent系统，这类通信机制就是为这种场景服务的。你怎么看Agent之间协作的发展前景？

吴恩达：这个领域还处于非常早期。大多数开发者，包括我自己，光是让自己的Agent正常运行就很不容易了，更别说让它和别人的Agent协同工作了——这简直是“双奇迹”。

所以，我看到的情况是，当一个团队内部构建多Agent系统时，他们能掌控协议、流程，系统也能互通——这是可行的。但当一个团队的Agent要和另一个完全独立团队的Agent合作，目前还几乎没有成功案例。我相信我们会走到那一步，但现在还为时尚早。

Harrison：我同意，如果说MCP还早期，那Agent-to-Agent就更早了。那我们来谈谈“Vibe Coding”吧。你之前也提到了AI编程助手。你怎么看“Vibe Coding”？这是一种新的技能形态吗？它在当今世界的意义是什么？

吴恩达：现在我们很多人写代码时几乎都不再“看代码”了，这其实是一件好事。我觉得不幸的是，它被叫做“Vibe Coding”，这个名称让人误以为可以“跟着感觉走”，接受或拒绝建议。但实际上，当我花整天时间用AI助手编程时，我是非常疲惫的——因为这是个极为智力密集的过程。所以我不喜欢这个名称，但这个现象是真实存在的，并且发展得非常快。

过去一年，有人建议“别学编程了，AI会自动完成”，这是未来最糟糕的职业建议之一。每当编程变得更简单，就会有更多人学会编程。我们从打孔卡片过渡到键盘和终端，从汇编语言变为COBOL时，也有人说“编程太简单了，不需要程序员了”。但事实是，编程越简单，学编程的人越多。AI编码助手会让更多人学会编程。

未来最关键的技能之一，就是能明确地告诉计算机你要什么，让它替你完成任务。理解计算机如何工作，能让你更精准地发出指令，这就是我为什么鼓励大家至少学会一种编程语言，比如Python。我本人Python熟练，但Java较弱。过去我几乎不写Java，现在有了AI助手，我写了很多Java和Type。即便是调试AI帮我生成的Java代码，我不自己手写，但理解其错误机制、异常路径仍非常重要。这使我能有效调试系统。

Harrison：既然你不喜欢“Vibe Coding”这个说法，有没有更合适的名字？

吴恩达：这是个好问题。我应该认真想一想。

Harrison：我们之后再回到这个话题。最近你宣布AI Fund设立了新基金，恭喜！那么，对于在场想创业的人，你有什么建议？

吴恩达：AI Fund是一家venture studio，我们只投资我们共同创办的公司。回顾AI Fund过去的经验，初创企业成功的第一指标是速度。很多人没有见过真正高效的团队能以多快的速度推进项目。如果你没见过，你很难想象真正快速执行是多么震撼。

第二个关键指标是技术知识深度。市场、销售、定价这些知识虽然重要，但它们更普及了，而技术知识在不断演进，稀缺程度更高。我尊重go-to-market负责人，定价和定位都不容易，但最稀缺的，是那些真正理解技术的人。AI Fund最喜欢与这些技术能力强、有判断力的合伙人合作，因为这让你前进速度翻倍。商业方面的知识固然重要，但通常是可以边走边学的。

Harrison：太好了，这是非常宝贵的建议。我们今天的对谈就到这里。感谢Andrew的分享，谢谢！

原视频：Andrew Ng: State of AI Agents | LangChain Interrupt

https://www.youtube.com/watch?v=4pYzYmSdSH4

编译：Wex Wang

请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。