邮箱｜damoxingjidongzu@pingwest.com
在最新的 LangChain Interrupt 峰会上，AI Fund 创始人吴恩达与 LangChain 联合创始人 Harrison Chase 展开了一场对话。吴恩达在对话中分享了关于AI智能体自主性、开发技能、工具应用以及行业趋势的深刻见解。以下是这场对谈的内容实录：
Harrison Chase：我想在做的各位应该都认识吴恩达。我猜很多人上过他在Corsera的课程，吴恩达也是技术转型的重要推动者，我是在两年多前的一个会议上认识他的。我们聊起Lingchain，他邀请我们开设Lingchain和深度学习课程。这应该是他们早期的第二或第三门课，很多人因此接触了Lingchain，吴恩达对LangChain的发展帮助巨大，有请他上台和我们展开炉边对话。
吴恩达：谢谢！Harrison的团队已开设六门AI短期课程，这些课程评分很高，Susie应该去上Harrison的所有课程，Vincent LanGrath的课程解释最清晰（笑）。
Harrison Chase：非常感谢你们的付出，你们涉猎了行业众多领域，我经常引用你关于“应用自主性”的观点。也许该把会议改名为“自主性会议”，你能详细说明这个观点吗？这个观点提出已有一年半到两年，想知道你有新的看法吗？
吴恩达：大概一年多以前我们同台演讲，当时我们都试图说服人们重视智能体，去年夏天营销人员滥用这个术语。尤其是一年半前，很多人争论 “这是否能算智能体”，我认为应该用“自主程度”来衡量，无论自主程度高低都是可行的，不必争论“这是否算真正的智能体”，都可以称为不同自主程度的系统，这样减少了无谓争论。
Harrison Chase：现在大家倾向于怎样程度的系统？
吴恩达：我们团队用LangGrath解决难题，处理复杂流程很有效。我也看到很多线性工作流的商机，比如表单处理、网页搜索等场景，或是复制粘贴信息的工作，这类业务流程很多其实是线性的，分支很少。通常如果中间有个步骤失败了，人类就介入处理，所以我看到很多机会。但我发现企业面临的挑战之一是，即使看出了一些流程可以自动化，用智能体去做，但要将现有做法改造成一个新的生成式工作流，依然 相当困难。
我们可能需要把一个大的流程拆解成更细的步骤，做出一个原型，但一开始效果往往不够好，然后团队就需要花很大力气来提升性能。那么应该以何种粒度，将其拆分为微任务呢，应该优化哪些步骤来提升性能，我认为整套技能都很稀缺。包括如何分析人类工作，拆分为连续步骤。判断少量分支点，建立评估机制等，用来衡量每一步的效果，当然还存在更复杂的智能体工作流。你需要亲自去看模型的输出、观察执行轨迹和最终结果，然后迅速决定下一步如何调整，但做到这一点仍然很难。但从数量和价值来看，我认为仍有大量简单流程待开发。
Harrison Chase：我们来聊聊相关技能，你深耕深度学习领域，许多课程都旨在帮助人们构建智能体，你认为智能体开发者应该掌握哪些核心技能。
吴恩达：这是个好问题，希望我能给出好答案。我最近一直在思考这个问题，很多挑战在于业务流程中有合规、法务、HR等人员，如何建立数据管道，通过LanGrath类集成，或借助MCP等方式来吸收数据，然后如何通过提示或多步骤处理，构建端到端系统，常见问题是建立正确评估框架，既要理解整体系统表现，又要追踪单个步骤，可以精确定位问题环节，找出需要优化的提示，很多团队过度依赖人工评估，每次修改后都需要人工核对结果，多数团队建立系统评估的速度偏慢，但找准项目方向仍很困难，新手团队常会走入死胡同，耗费数月改进某个组件，经验丰富的团队会选择绕道而行，希望能更高效获取这种实操经验。面对LangSmith的输出日志，必须在短时间内做出决策，这种能力仍极具挑战性。
Harrison Chase：这种实操经验主要涉及LLM的局限性吗，还是指更广泛的产品实践?？换言之，把一项任务拆解并掌握其中每一步，这种能力是不是主要围绕大型语言模型展开的？
吴恩达：我认为涵盖所有方面。过去几年AI工具公司创造了惊人成果，包括LanGrath等工具，RAG等创新思路，构建聊天机器人的方法，多种记忆实现方式，评估体系建设，安全护栏设计，这些工具令人兴奋。我脑海中常浮现一个画面，这就好比你只有紫色乐高积木，但我觉得这些工具就像乐高积木，种类越丰富，我们搭建的方案就越灵活。好比不能光有相同形状的乐高块去搭建复杂结构。你需要各种颜色、各种形状的乐高积木，不光有紫色的，还要有红色的、黑色的、黄色的、蓝色的……当你手里掌握的积木类型足够多、足够多样时，就能迅速把它们组合出很棒的东西。
所以，我觉得现在很多新工具，其实就是不断增加我们手中乐高积木的颜色和形状。当你尝试构建一个系统时，有时候你需要种类很多的特殊积木，有时候用一个普通积木就能把活干完。但是如果你从来没有尝试过构建某类评估，可能就会在某些问题上白白花掉两三个月功夫，而别人也许只用写一个简单的评测就找到解决办法了。通过一次次实践各种不同的工具，你会慢慢培养出强大的产品直觉。AI的遗憾之处在于，它不止有一个工具，我编程时会使用大量不同工具，我自己并不精通所有工具，但已学会快速组合它们，使用不用工具的实践经验，也有助于更快决策。
另一点是技术也在变化，比如大模型的上下文窗口越来越长，过去我们必须绞尽脑汁做RAG之类，如今不太适用。随着大模型上下文记忆变长，现在我们把更多内容塞进大模型上下文，RAG并未消失。但超参数调优简单多了，现在有大量可用的超参数，随着LLM持续进步，我们两年前的经验如今未必适用。
Harrison Chase：你刚才提到了很多点都很有意思。那么，有哪些“积木式”的工具在你看来目前被低估 了呢? 比如“评估”这个工具，现在大家其实已经在反复强调它的重要性。我想知道，还有哪些东西是大多数人没怎么留意过，但值得推荐的？
吴恩达：这个问题很好。我也不确定自己有没有完美答案，即使“评估”现在被很多人提起，但其实很多 人依然没有真正用好它。很多人觉得写评估要面面俱到、非常完善才行。我的建议是，评估可以从简入手。甚至花二十分钟随便拼一个，哪怕不够完美，也可以作为人工检查的补充。通常我们的系统在某个点上会出问题，然后大家就陷入被动，这个时候，我会赶紧做一个非常简单的自动评测，也许只包含五个测试用例，加上一些非常基础的检测逻辑，专门用来监测这一次出现的回归错误。这并不是说要用自动评测完全取代人工判断，我自己还是会亲自看结果。但当我改了系统某些东西之后，这个简易评估可以立刻告诉我那个错误是不是又冒出来了。
就像我们平时写代码也是这样，一开始先写一个简陋的、可能漏洞百出的版本，然后再不断改进它。同样道理，在构建应用时，我们可以很快地写一个粗糙的评测，不够完善也没关系，有了初步结果之后，你自然会想着不断完善它。就像开发产品一样，我们先快速构建一个效果不完美的东西，再逐步改进。评测也是这个思路。
另外一个是，我认为严重被低估的领域就是语音技术栈。我本人对语音类应用非常兴奋，我身边很多朋友也都很看好语音应用，不少对话式界面的产品团队也非常关注语音交互。但不知为何，在我们这个社区，真正投入语音栈应用开发的工程师相对还是很少。大家对大型语言模型、文本智能体的关注远远高于对语 音的关注。这让我感觉语音方向现在的声量小得出奇，和行业里其他炙手可热的方向比起来形成了鲜明对比。当然，这里的语音应用也不一定都是实时语音对话或语音生成。我个人发现端到端的语音生成模型非常难控制，相比之下，采用“智能体 + 语音技术栈”的方案要可控得多。最近我和很多团队合作开发语音栈相关的东西，希望能逐步攻克这些难题。
还有一点，我觉得很多公司在利用AI辅助编程这方面也做得不够。我们发现，会使用AI工具的开发者编程速度比不用AI的开发者快得多。可现在还有许多公司的CIO、CTO出于种种原因，禁止他们的程序员使用AI工具。这些顾虑可以理解，但真的需要想办法克服。因为我的团队成员现在完全无法想象在没有AI助手的情况下写代码，要是不能用AI工具编程，他们恐怕会抓狂(笑)。换句话说，我觉得有个想法被低估了，每个人都应该去学编程。透露一个小趣事，在我们AI Fund公司里，每个人都懂一点编程，包括前台接待、财务总监、法务顾问，所有人都会写代码。当然，不是要求他们在本职工作中每天写代码，而是说他们都有能力告诉电脑自己想要什么，这实际上大幅提高了各个岗位的工作效率，即使那些岗位本身跟AI没有直接关系。
Harrison Chase：说到利用AI，我们很好奇你自己在编程中用哪些AI工具来提升效率呢？
吴恩达：我们公司内部正在开发一些还没公开的新工具，暂时不方便细说。
Harrison Chase：听起来很令人期待。
吴恩达：我平常自己用的，像Cursor、Replit等多一些，还有一些其他辅助工具。
Harrison Chase：那我们再回到语音应用的话题。如果现场的开发者之前熟悉的是基于LLM的文本智能体，现在想入门语音方向，你觉得这两者相似吗？已有的很多开发心得是否可以直接迁移过来？还是说语音智能体需要全新的技能？
吴恩达：既有相通之处，也有很大不同。从应用角度看，语音作为交互形式在某些场景下非常重要，因为打字对用户来说其实挺有门槛的。对于很多应用，让用户输入文本是不友好的，在纯文字界面下，用户经常会犹豫，很谨慎地措辞，哪怕可以用退格键，他们很多时候还是不太敢随便输入自己的想法。相比之 下，语音交互的门槛就低很多。让用户直接说出想法，然后系统以语音回应，这对用户来说几乎没有什么心理负担。
语音智能体和文字智能体最大的不同在于用户对响应速度的期望。用户通过语音提问后，往往希望一两秒内就听到回答。在电话客服等场景下尤其如此，几秒钟的静默都会让人非常焦虑，期望马上得到回应。但许多智能体流程的后台推理往往需要好几秒甚至更久才能完成。如果我们照搬文本智能体的方法，可能用户要干等十几秒才能听到回答，那体验就太差了。所以我们需要一些技巧来弥合这个差距。
我们尝试过的一个方法是，在系统思考时先播放一些填充话语。就像你问我一个问题，我可能会先说“嗯……这问题很有意思……” 来拖延一下时间，以此来掩饰系统的延迟。事实证明，这种做法效果很好。还有一些小窍门，比如在呼叫中心场景，如果完全静音等待，用户会对延迟非常敏感，但如果在背景播放一点轻微的环境声，用户就不会觉得几秒的等待那么煎熬。总的来说，语音交互跟纯文字相比有很多不同的地方，需要我们仔细打磨。
另一方面，语音作为媒介本身也有有趣的特点。当我们开口说话时，其实并不期望自己的措辞一开始就完美无缺，我们可以一边说一边修正。而打字的时候，人们往往力求一次性打完整。所以，在语音对话中，用户常常会不断调整自己的表述，因为他们会提供更多信息，让智能体更了解真实需求。所以在语音智能体中，我们既要解决延迟和背景噪音这些技术问题，也要充分利用语音交互宽松、自然的特性来优化用户体验。
Harrison Chase：最近出现了一个新东西叫MCP（模型组件协议），你觉得它会对人们构建应用产生什么影响？生态会因此发生什么变化吗？
吴恩达：今早我们还发布了一个和MCP相关的新项目。我看到网上对于MCP其实有不少困惑，所以我们还写了一篇简短的介绍来解释它。简单来说，MCP是一个很棒的标准化尝试。OpenAI等大公司都采纳了它，足见其重要性。当然，我认为MCP标准本身今后还会继续演进完善。
举个例子，很多朋友可能已经了解MCP目前大致是怎么回事，它主要是为了标准化智能体调用外部工具和数据的接口。但目前MCP定义的接口比较扁平，如果以后有一个对LangChain工具的MCP接口，那LangChain 内部其实还是会调用许多API，但MCP现在只是把各种工具列成一个长清单，让智能体自己去挑。我认为未来我们需要让协议变得更分层、更结构化。
可以想象下，如果某个工具本身功能很复杂，光靠一长串列出所有可能操作是不够的，智能体还是难以自主决策。我希望MCP能发展出层级结构来。比如当智能体面对一个复杂工具时，可以逐层深入它的功能目录，而不是被扔给海量平级选项。不过MCP作为统一工具接口的第一步已经相当了不起了。我强烈建议大家了解一下它。MCP不会让你的生活立刻变得轻松，但它至少提供了一个统一的调用方式。
这有点像互联网刚出现的时候，我们终于有了一套标准协议（HTTP）让大家互联互通。不过随之而来的授权、安全等问题也需要解决，比如每个公司或服务都需要处理各自的认证token等等。这些还在早期摸索中。我认为MCP是非常好的一个进展，但它肯定会继续演化，未来可能引入更分层的结构，使智能体更聪明地使用复杂工具。
Harrison Chase：还有一种协议是智能体与智能体之间的通信。我记得大概一年前在哈佛的活动上，你谈过多智能体系统，好像MCP也有助于实现这个目标。你觉得不同智能体之间直接对话、协作这种情况现在进展如何？
吴恩达：其实多智能体互相协作还处于非常早期的阶段。我们自己开发智能体都还经常碰壁，更别提让我的智能体跟别人的智能体无缝对接，感觉简直像两重奇迹叠加（笑）。目前我看到的例子，大多是一家公司或一个团队内部构建了多个智能体，让它们通过某种自定义协议协同工作。这种在同一团队内的多智能体系统有时是有效的，因为是内部使用，协议细节都可控。但截至目前，我个人几乎没看到成功的案例是由不同团队开发的智能体彼此对接合作的。将来肯定会有，但现在还为时尚早。
Harrison Chase：没错，我也觉得现在谈智能体互操作还太早了。另外一个最近很火的词是“即时编程(vibe coding)”。我们刚才稍微提到了大家使用AI辅助编程的现象。你怎么看即时编程，这是不是一种全新的技术？还是说和以前的编程本质上相同？
吴恩达：我觉得我们很多人现在编程时，其实已经很少从头写大量代码了，而更多是在利用AI工具提高效率。即时编程这个说法本身有点误导，听起来好像是随随便便、不用费脑就能编程。但实际上，配合AI进行编程也是一件非常烧脑的事情。我一天用Copilot编程下来，到晚上还是觉得脑子很累，并不是说什么都不用考虑。即时编程是真实存在的，而且带来了巨大的帮助，只是名字起得不太恰当。我注意到过去一年，有些人居然建议新人干脆别去学写代码了，理由是有了这些AI编码助手，人类编程将变得可有可无。我觉得这是非常糟糕的职业建议。
回顾过去几十年，每当编程变得更容易、更高效的时候，结果都是写代码的人反而更多了，而不是不需要程序员了。举几个例子，从打穿孔卡到键盘输入，编程介质更友好后，程序员数量大增；从低级汇编到高级语言，门槛降低后，又有更多人加入编程行列。当时也有人说不再需要那么多的程序员，事实恰恰相反，所以按现在这些AI辅助编程工具的发展趋势来看，编程只会变得更普及，越来越多的人投入编程，而不是相反。
我甚至认为，未来对开发者来说，最重要的技能之一就是能够清楚地告诉计算机想要它做什么。也就是说，得能准确地写出代码或提示，让计算机按你的意图执行任务。而要做到这一点，仍然需要你对计算机如何工作有一定的理解。这会让你的提示词更有力量、调试也更高效。这也是为什么我依然建议每个人都认真去学至少一门编程语言。我知道有人可能觉得以后AI会把代码都包办了，但实际上，即便用了AI工具，你还是得看懂它产出的代码、理解报错信息等等，这些都离不开扎实的编程基础。拿我自己来说，原本我很少写JavaScript这种前端代码，但自从有了AI编程助手，我现在写的JavaScript/TypeScript代码比以前多，即便如此，如果没有一定的编程功底，哪怕AI帮你写了代码，还是得理解比如错误讯息是什么意思、出bug怎么办。所以与其纠结“vibe coding”这个名字，我更想强调，编程门槛降低并不意味着可以不懂编程，反而应该趁机让更多人学会编码。
Harrison Chase：如果你觉得“vibe coding”这个说法不够贴切，那有没有更好的名字来形容这种AI辅助编程方式呢?
吴恩达：我还真没仔细想过哈哈，以后想到再告诉你吧。
Harrison Chase：最后一个问题，我了解到你最近在AI Fund启动了一个新的投资基金，对于在座那些正打算创业做AI初创公司的人，你有什么建议？
吴恩达：我们AI Fund本身既孵化新公司，也投资联合创办的公司。几年下来，我总结出两个最重要的成 功因素，第一，速度。一家初创能否成功，最快的那支团队往往胜出。我见过很多次，优秀团队以惊人的速度执行，在短时间内取得别人几倍的进展，这种敏捷是那些行动迟缓的大公司完全比不了的。
第二，技术深度。当然市场和销售等能力也很重要，但这些方面的know-how在整个行业内其实相对分布得更广泛，不算稀缺资源。反而是对尖端技术的深入理解和直觉判断，才是稀缺且真正能带来差异化的优势。技术演进如此之快，如果你对技术原理没有深刻的洞察，就很难及时调整方向。我非常敬佩优秀的市场、运营、定价人才，这些都不容易做好。但那些知识相对更普及，而真正罕见的是对核心技术的深刻理解。所以我发现，最成功的创业团队往往至少有几位技术高手，对哪些是可行的有很敏锐的直觉，再辅以必要的商业人才，才能跑得更远。
Harrison Chase：非常好的建议，我想这对想要创业的人很有帮助。再次感谢您的分享！
（文：硅星GenAI）