跳至内容
吴恩达教授关于 Agent 的理解非常深刻，此前做过的几次分享和教学都非常有启发性。
1. 吴恩达，对 Agentic Workflow 持续兴奋
2. Agent>GPT5？吴恩达最新演讲：四种 Agent 设计范式（通俗易懂版）
最近吴恩达与 LangChain 联合创始人 Harrison Chase 又展开了一场对话，交流 Agent 的发展现状。
链接：https://www.youtube.com/watch?v=4pYzYmSdSH4&t=68s
InfoQ 已经对对话内容进行了很好的编译，因此我们基于吴恩达评Agent现状：MCP尚处“蛮荒”，单Agent跑通已是“奇迹”，A2A协作堪称“双重奇迹”做了一些润改，内容如下：
过去几年，AI 工具公司构建出一套功能强大、模块丰富的工具体系。LangGraph、RAG 等组件就像乐高积木，让开发者可以灵活拼装、快速搭建系统。
但在真实场景中，往往会卡在某个细节模块，比如上下文管理或评估。有经验的人能迅速换个解法几天解决，没经验的可能要多绕几个月的弯路。
AI 开发的“残酷”之处也在于此——没有哪一个工具能包打天下，关键在于是否熟练掌握并高效组合整套工具链。
另一方面，工具之间的变化也很快。例如，随着 LLM 的上下文长度持续增加，一年半前的很多 RAG 最佳实践，今天可能就不适用了。而 MCP 的出现则补上了另一个明显的市场空缺，让工具、API、数据源之间的集成变得更容易。
但正如吴恩达所言，MCP 仍处在“蛮荒阶段”——网上有很多服务端实现，但“很多其实跑不起来”，身份验证和 token 管理也尚不成熟。而且， 在 Agent 与 Agent 通信方面，吴恩达坦言，如今大多数人（包括他本人）仍在努力让一个 Agent 正常运行；而要让两个不同人的 Agent 成功协作，则几乎像是完成了两个奇迹。
我们翻译了这场对话，让大家了解吴恩达对 Agent 构建路径、MCP 现状、工具组合能力等核心问题的最新判断与实践思路。
更多优质内容可以在我们精细分类的 ima 知识库内免费查看👇
Harrison Chase：你提议我们不去纠结一个应用是不是 Agent，而是去关注它有多“Agentic”，能不能再解释一下这个观点？
吴恩达：我之所以提出这个观点，是因为我发现大家在不停地争论：“这个是 Agent 吗？”“这个不算吧？”——各种不同的定义争议：它够不够自主？是不是符合某个标准？
我当时的感觉是，与其花那么多时间争论这个是不是 Agent，不如我们整个社区换个方式思考：把“Agenticness（自主性）”看作一个光谱——有些系统 Agentic 能力强，有些弱。
你想做一个稍微具备一点自主性的 Agentic 系统，或者一个非常自主的系统，都是可以的，没必要非得争论“这算不算 Agent”。
所以我提议，我们就叫这些系统“Agentic systems”，然后专注于怎么构建它们。这种思维方式，其实帮我们节省了大量争论时间，让我们能更快进入实操阶段。
Harrison Chase：你怎么看这个光谱——从“低自主性”到“高自主性”？现在大家在构建系统时，大多处在哪个位置？
吴恩达：很多企业里的实际工作，是让员工在网页上填写表单、搜索信息、查数据库有没有合规风险、判断是否可以向某些客户销售某类产品；或者是复制粘贴一些数据，再做个搜索，再粘贴到另一个表单中。这些业务流程，往往是非常线性的，偶尔出现一点小循环或小分支，通常意味着流程失败，比如因为某个条件不满足被拒绝。所以，我看到大量的机会，都来自这些简单流程。
而我也注意到，企业在把已有流程转变为“Agentic workflow”时，仍面临很大挑战：比如，你应该把流程拆分到什么样的粒度？任务要分成哪些微步骤？当你构建了一个原型，但效果不够好时，你要改进哪一个步骤才能提升整体效果？这种“从复杂任务中拆解出可执行的微步骤”、设计工作流结构、评估机制等能力，其实现在还比较稀缺。
当然，更复杂的 Agentic 工作流也非常有价值，尤其是包含大量循环的那些。但就“数量”来说，现在的机会，还是主要集中在这些更简单的线性流程里，大家正在一步步把它们系统化、自动化。
Harrison Chase：你做了很多深度学习相关的教学，也有很多课程是为了帮助大家理解和构建 Agent。那么你觉得对于 Agent 构建者来说，哪些技能是最应该掌握的？
吴恩达：我觉得最大的挑战在于：很多业务流程里，牵涉到的是合规、法务、人力等团队的具体操作。那你要怎么构建一个“管道”把这些流程数字化？是用 LangGraph 做集成？还是看看 MCP 是否也能帮助实现？
一个很重要但常被忽略的点是：要搭建一个正确的 Eval（评估）体系，不只是评估整个系统的效果，还要能追踪每一步骤，这样你才能快速定位“是哪一步坏了”，“是哪个 Prompt 没有发挥作用”。很多团队在这个过程中可能进展比应有的慢——他们一直靠人手评估，每次改完 Prompt，就一个个看输出，人工判断，这会极大影响效率。
我认为，构建系统性评估机制是最理想的方式。但问题是，很多团队还没有这种“下一步该做什么”的直觉。技能不足的团队经常会走进“死胡同”——比如花几个月去优化一个永远也做不好的组件。而经验丰富的团队会说：“这个方案我们放弃吧，换一条路线。”
我希望我能总结出更高效的方式，教会大家这种“经验性判断”，因为很多时候你必须在几分钟甚至几小时内，看着 LangChain 的 Trace 输出、判断当前状态，然后迅速做出决策，而这仍然是非常困难的。
Harrison Chase：你认为这种“经验性判断”，更多是和 LLM（大模型）本身的限制有关，还是更偏向产品结构、任务拆解这些“构建能力”？
吴恩达：我觉得两者都有。过去几年，AI 工具公司构建了一套非常强大的工具体系，包括 LangGraph 在内。你可以思考如何实现 RAG，如何构建聊天机器人，如何做记忆系统、构建 Eval、加上 Guardrails 等等。
我经常会用一个类比：如果你手上只有一种颜色的乐高积木，比如只有紫色的，你其实很难拼出复杂的结构。但现在我们有了更多类型的“积木”工具：红的、黑的、黄的、绿的，各种形状和功能。你拥有的积木越丰富，组装成复杂结构的能力就越强。
我们提到的那些 AI 工具，它们其实是不同形状的“乐高积木”。在构建系统时，你可能就正好需要那个“弯曲奇怪形状的那一块”，有经验的人知道用哪一块，能迅速完成任务。但如果你从没做过某种类型的 Eval，可能会因此多花三个月时间，走弯路。而有经验的人会直接说：“我们用 LLM 做 Judge，评估方式换成这个，三天就能搞定。”
这也是 AI 比较“残酷”的地方之一——它不是一个工具能解决所有问题。写代码时，我自己也会用一堆不同的工具。我不能说自己精通每一个，但我熟悉足够多，可以快速组合。而且，工具之间的变化也很快。例如，随着 LLM 的上下文长度持续增加，一年半前的很多 RAG 最佳实践，今天可能就不适用了。
我记得 Harrison 在这方面很早就开始探索了，比如早期的 LangChain RAG 框架、递归摘要等。而现在，由于上下文窗口扩大了，我们可以往里面直接塞入更多信息。RAG 并没有消失，但调参难度已经大大降低——现在有一大段“都还行”的参数区间。
所以，随着 LLM 的持续进化，我们两年前的一些直觉，有些可能就已经不再适用了。
Harrison Chase：有哪些“乐高积木”组件是现在被低估了，但你会推荐大家去关注的？
吴恩达：虽然大家现在都在谈论评估这件事，但很多人其实并没有真正去做。我不太明白为什么不做，可能是因为大家通常认为写一个评估系统是一项巨大而严谨的任务。
经常会发生这样的事：我构建了一个系统，然后某个问题不断出现。我以为修好了，它又坏了，再修好，又坏了。这时候我就会写一个非常简单的评估，可能只包含五个输入样例，用一些非常基础的 LLM 作为评审，只针对这个特定的回归问题做检测——比如“这个地方是不是又坏了”。
我并不会完全用自动化评估取代人工评估，还是会亲自看输出。但这个简单的评估可以帮我减轻一点负担，自动跑一下，让我不用每次都手动去检查。
然后会发生什么呢？就像我们写论文一样，一开始只是搭一个非常简陋、明显有缺陷的评估系统。但等你有了初版，你会想“其实我可以改进它”，然后就开始迭代优化。
很多时候我就是从一些糟糕透顶、几乎没什么帮助的评估开始做起的。然后随着你查看它的输出，你会发现“这个评估系统是坏的，但我可以修好它”，就慢慢让它变得更好。
另一个我想提的点是，虽然大家也讨论得挺多，但我觉得还远远被低估的，是 Voice stack（语音技术栈）。这是我非常感兴趣的领域，我身边很多朋友也很看好语音应用。我们也看到不少大型企业对语音技术极其感兴趣，而且是规模很大的企业、使用场景也很大。
虽然这个社区里也有一些开发者在做语音，但开发者的关注度相比这些企业的关注度还是小得多。而且我们说的也不仅仅是实时语音 API，也不只是 Speech-to-text 那类原生音频模型——因为那种模型往往很难控制。我更喜欢一种基于 Agentic 工作流的语音技术栈，它更容易控制。我最近在和很多团队一起做语音栈相关的项目，有些希望很快能对外公布。
还有一个可能不算“被低估”，但我认为更多企业应该去做的事情是——让开发者使用 AI 辅助编程。
很多人应该都见过，使用 AI 辅助的开发者效率远远高于不使用的开发者。但我还是看到很多公司，尤其是 CIO、CTO 们，还制定了一些政策，不允许工程师用 AI 编程工具。我知道有时也许是出于合理原因，但我觉得我们需要尽快突破这个限制。坦白讲，我和我的团队，已经完全无法想象在没有 AI 帮助的情况下写代码了。但现在还有很多企业需要接受和适应这一点。
还有一个被低估的观点是，我觉得“每个人都应该学一点编程”。
我们 AI Fund 的一个有趣事实是：我们公司每个人都会写代码，包括前台接待、CFO、法务总顾问……所有人都会写。不是说我希望他们成为软件工程师，但在自己的岗位上，他们通过学一点点代码，能够更清晰地告诉计算机他们想做什么。这带来了各个非工程岗位的显著生产力提升，这个现象我也觉得挺令人激动。
Harrison Chase：如果现在有人想进入语音这个方向，而他们之前已经熟悉了用 LLM 构建 Agent，那你觉得他们的知识迁移性有多强？有哪些是相通的？又有哪些是全新的需要学习的？
吴恩达：我觉得有很多场景语音其实是非常关键的，它带来了某些新的交互方式。
从应用层面看，文本输入其实是一个“令人畏惧”的交互方式。你去跟用户说，“告诉我你的想法，这是一个输入框，写点文字吧”，很多人会觉得压力很大。而且文字输入还能退格，用户回复速度就更慢。
但语音就不一样了：时间是往前推进的，你说了就说了，也可以临时改变主意，比如说“我改主意了，忘了我前面说的”，模型其实处理这些的效果还不错。所以很多时候，语音可以降低用户使用门槛。我们说“说说你的想法”，用户就自然地开口了。
语音系统和文本系统最大的区别在于对“延迟”的要求。如果用户说话了，系统理想中需要在一秒内做出回应（最好是 500 毫秒以内，但至少不能超过一秒），但传统 Agentic 工作流可能需要几秒钟甚至更久的处理时间。比如我们在做一个“我的虚拟分身”项目，你可以在网页上和自己的虚拟形象对话。我们最初版本有 5~9 秒的延迟——你说完话，沉默九秒钟，然后分身才回答，这是非常糟糕的体验。
后来我们做了一些“预回应”的设计。比如你问我一个问题，我可能会先说：“嗯，这是个有意思的问题”或者“让我想想”。我们就让模型去做类似这样的回应，用来掩盖延迟，这招效果很好。
还有一些其他小技巧，比如说，如果你做的是语音客服机器人，在等待期间播放背景音，而不是完全的静音，用户就会更容易接受系统的“迟钝”。
而且在很多应用中，语音让用户更容易进入状态，降低了“自我审查”的门槛。人们说话的时候，不会像写字那样追求完美。他们可以随便说说，改口、反复、自由表达——这让我们更容易从他们那里获取有用信息，也能更好地帮助他们推进任务。
如果说 MCP 还早期，那 Agent 通信就更早期了
Harrison Chase：你认为 MCP 在应用构建方式、类型上，带来了哪些变化？你怎么看它对整个生态的影响？
我个人非常喜欢 MCP，它补上了一个明显的市场空缺，而 OpenAI 的快速跟进也说明了这个标准的重要性。我觉得 MCP 标准未来还会不断演进，目前它主要让 Agent 更容易接入各种数据，但其实不只是 Agent，很多其他软件也可以受益。
我们在用 LLM 的时候，尤其在构建应用时，往往会花很多时间在构建 Pipeline 上——也就是各种数据接入工作上。尤其是在大企业环境下，AI 模型其实已经很聪明了，只要给它正确的上下文，它就能做出合理的事情。
但我们往往要花大量时间处理接入工作，搞清楚怎么把数据喂给模型，才能让它输出你想要的东西。MCP 正是在这方面起到了很大的标准化作用，它让工具、API、数据源之间的集成变得更容易。
当然，现在 MCP 还是有些“蛮荒”。你在网上能找到很多 MCP 服务端，但很多其实跑不起来。身份验证系统也很混乱，就算是一些大公司，MCP 服务也存在 token 是否有效、是否过期等问题。
此外，我觉得 MCP 协议本身也还很早期。现在的 MCP 会返回一个很长的资源列表，未来我们可能需要某种分层发现（hierarchical discovery）机制。比如你要构建一个系统——我不知道将来会不会有 LangGraph 的 MCP 接口——但像 LangGraph 这样的系统，有成百上千个 API 调用，你总不能把所有调用都塞进一个扁平列表里让 Agent 去自己筛选。
所以我们可能需要一种层级式的资源发现机制。我觉得 MCP 是个非常棒的第一步。我非常鼓励大家去了解它，它可能真的会让你的开发更轻松，尤其是如果你能找到一个稳定好用的 MCP 服务端实现来帮你做数据整合的话。
我也认为，从长远看这点非常重要——如果你有 n 个模型或 Agent，要接入 m 个数据源，那你不该为了每一个组合都单独写接入逻辑，工作量不应该是 n × m，而应该是 n + m。而我觉得 MCP 就是朝着这个方向迈出的非常棒的第一步。它还需要继续演化，但的确是个好起点。
Harrison Chase：还有另一种协议，虽然不像 MCP 那么热，但也值得关注，就是 Agent 与 Agent 之间的通信。那么你怎么看 Agent 与 Agent 通信的发展？
吴恩达：现在的 Agent 通信依然非常早期。我们大多数人，包括我自己，在让自己的代码正常运行这件事上都还在挣扎。所以要让我的 Agent 和另一个人的 Agent 正常协作，就像是实现了两个奇迹。
目前我看到的情况是：一个团队内部自己构建的多 Agent 系统，是可以运转起来的。因为大家都在同一个团队，知道协议、约定、接口是什么，也知道怎么打配合——这样就能跑起来。但要让一个团队构建的 Agent 能和另一个完全不同团队的 Agent 协同，现在来看，还太早。 我相信我们终究会实现这一点，但就我自己目前观察到的，还没有看到太多真正成功、规模化运行的案例。不知道你们是不是有类似的观察？
Harrison Chase：没错，我同意你的看法。如果说 MCP 还早期，那 Agent 间通信就更早期了。
Harrison Chase：你怎么看待 vibe coding（氛围编程）？它和传统编程相比是否是一种新的技能？它在当今世界中起到什么作用？
吴恩达：我觉得我们很多人现在编程的时候几乎不再看代码了，这其实是一种非常棒的进展。不过我觉得“vibe coding”这个名字挺不幸的，因为它会让很多人误解，以为这件事只是“靠感觉”——比如这个建议我接受，那个我拒绝，仅凭直觉判断。
但说实话，当我花一天时间用这种“vibe coding”方式，也就是借助 AI 编码助手工作后，我通常会感到非常疲惫。这其实是一种非常需要智力投入的活动。所以我认为虽然这个名字不好，但这个现象是真实存在的，而且它的确在发展，而且是件好事。
过去一年里，有一些人在建议别人“不要学编程”，理由是 AI 会自动帮你写代码。我认为未来回头看这将会是史上最糟糕的职业建议之一。如果你回顾过去几十年的编程发展历史，每一次编程门槛降低，都会让更多人开始学习编程。比如从穿孔卡片转向键盘和终端，或者从汇编语言过渡到 COBOL，我甚至找到了一些非常古老的文章，当时就有人声称，“我们有了 COBOL，就不再需要程序员了”。
但事实是，每次编程变得更简单，学习编程的人反而变多了。
所以我认为，AI 编码助手也将推动更多人学习编程。而且，未来最重要的技能之一，无论是对开发者还是非开发者来说，都是“清晰准确地告诉计算机你想做什么，让它替你完成”这件事。
想要做到这一点，了解一些计算机的基本工作原理其实非常有帮助。我知道你们在座的很多人已经理解了这一点。但这也是我为什么一直建议大家至少学会一门编程语言，比如 Python。
也许你们有人知道，我自己是一个 Python 能力比 JavaScript 更强的人。但在使用 AI 编程助手之后，我写了比以往更多的 JavaScript 和 TypeScript 代码。即使是调试那些 AI 帮我生成、而不是我亲手写的 JavaScript 代码时，理解其中的错误类型和含义，对我来说仍然非常重要，帮助我去修复它们。
（文：特工宇宙）
