Agent 进入工程时代！吴恩达详解 AI Agent 构建全流程，核心不在模型，而是任务拆解与评估机制

大家好，欢迎来到IT知识分享网。

在 LangChain Interrupt 峰会上，吴恩达详细阐述了 AI Agent 构建的方法论、评估机制等关键内容，强调核心在于任务拆解与评估机制。本文将深入解读其观点，探讨 AI Agent 构建的关键要素与发展前景。

在最新的 LangChain Interrupt 峰会上，AI Fund 创始人吴恩达与 LangChain 联合创始人 Harrison Chase 展开了一场对话。

作为 AI 教育和创业孵化的重要推动者，吴恩达围绕 Agent 构建方法论、评估机制、语音与协议基础设施，以及开发者与创业者应具备的直觉判断力展开系统性阐述。

他提出，“agenticness” 应被理解为连续程度，而非标签判断；未来 AI 构建者的核心竞争力，不在提示设计，而在流程建模与执行速度。

“agenticness” 是程度而非标签

吴恩达回顾了一年多前与 Harrison 同台演讲的场景。那时他们正试图说服行业相信 Agent 是一个值得投入关注的方向。“那时候，大家还不确定 Agent 是不是一个重要的东西。”他说。那之后，随着 Agent 概念走红，“agenticness” 这个词也迅速被市场营销人员广泛使用，渐渐变得语义模糊。“这个词被滥用了，大家开始用它指代各种系统，但实际含义已经不明确了。”

他指出，当时很多人在争论“这个系统到底是不是 Agent”、“它是否真正具备自主性”，但这类争论本身并没有太大价值。与其浪费时间在这些语义层面的问题上，不如换一种方式思考。他提出“agenticness 是一个光谱”的概念：不同系统具有不同程度的 agenticness，从几乎无自主性到高度自主都是合理的存在，只要系统具备一定程度的自主性，都可以归入 agentic 系统的范畴。

“如果你想构建一个具备一点点或者很多自主性的 agentic 系统，那都是合理的。没必要去纠结它是否‘真正是 Agent’。”吴恩达说。

这种包容性的定义有助于整个社区从语义纠缠中解放出来，更高效地推进实际落地工作。他表示，这种思路确实起到了积极作用，让更多开发者从“是否为 Agent”的问题中抽身，专注于系统是否能解决实际问题。

Agent 建模经验严重不足

当被问到当前构建者处于怎样的“agenticness 光谱”阶段时，吴恩达表示，他所在团队会使用 LangGraph 去处理一些较复杂的问题，比如多步骤流程自动化。“但我也看到很多现实中的商业流程其实是线性的，或者是线性中夹杂一些失败分支。”他说。

他举例说明，在一些业务中，人类目前仍在重复完成一系列可预测的操作，比如：填写表格、在网页搜索信息、访问数据库确认是否涉及合规、判断是否可以销售某样物品。这类流程其实是“复制—粘贴—再搜索—再粘贴”的循环，结构相对固定。

这些流程本质上非常适合 agent 化处理，但最大挑战是，许多公司还不知道如何将其转化为 agentic 系统。“比如应该以什么样的粒度去拆分任务？如果原型效果不佳，该从哪个步骤优先改进？这类知识在业界其实是非常稀缺的。”

尽管有更复杂的 agentic 工作流存在，比如多循环、多代理系统，但吴恩达指出，当前阶段构建者面临的主要问题仍集中在简单流程的建模与拆解上。“我们现在最缺的，其实是让这些结构化流程自动化的‘中间技能’。”

Agent 系统需要系统直觉，快速且实用

谈到构建 Agent 所需的关键技能时，吴恩达表示，系统管道的搭建能力是第一步。他指出，在现实业务流程中，往往涉及多个角色：合规、法务、人力资源等。每个角色都执行特定任务，Agent 系统需要模拟这些角色的逻辑，将流程顺利衔接。

那么开发者该怎么做？是用 LangGraph？还是 MCP Host？是否需要模块化集成不同子任务？这些都取决于任务本身。而很多团队在遇到系统出错时，反而不知道问题在哪，也不知道下一步该优化哪个部分。

“我发现很多团队其实花太多时间依赖人工评估。每次系统调整之后，就人工看输出是否正确。”吴恩达说。他认为评估机制的缺失，是当前 Agent 构建过程中最大的“看不见的问题”。

他主张快速搭建“哪怕很烂”的初级评估系统，比如针对某一失败步骤，写一个只覆盖 5 个输入示例的检测脚本，用一个简单模型去判断系统是否回归。“它不需要完全替代人眼，而是去承担那些重复性判断任务。”

他认为最理想的状态是：开发者能在几分钟到几小时内，迅速基于 LangSmith 等工具做出决策。这种基于真实数据、真实失败路径的“触觉型直觉”，才是系统构建中最宝贵的经验。“没有这种触觉，你可能花几个月优化某个组件，但有经验的人一眼就知道这个方向做不出来。”

工具即积木，认知覆盖决定效率高低

吴恩达强调，现在 AI 社区已经出现大量强大的工具，但开发者间的工具认知差距非常大。他将其比喻为“彩色乐高积木”：过去如果只有一种积木，比如紫色积木，那你能搭出来的东西非常有限。但现在我们有红色、蓝色、绿色、各种形状、大小的乐高，你可以搭出几乎任何结构。

这些乐高积木的存在，比如 LangGraph、Retriever、RAG、Memory、Email Generator、Guardrail 机制等，构成了构建 agentic 系统的技术库。而真正掌握这些工具的开发者，能在系统失败时迅速重组结构，而不是陷入冗长 debugging。

“我写代码的时候也会混合用很多工具。我不需要是每个工具的专家，但我知道它们能做什么，能解决什么问题。”吴恩达说。

他补充道，在过去一两年中，RAG（检索增强生成）的最佳实践也发生了变化。大模型的上下文窗口增大，意味着许多过去对超参数的调节现在不那么紧迫。很多旧的直觉已经不再适用，开发者必须不断更新自己的“工具知识图谱”，否则就会严重落后。

语音栈与 MCP 协议被低估了

在讨论哪些关键领域仍被忽视时，吴恩达直言，语音技术栈与 MCP 协议是最值得关注的方向。他认为语音应用的价值远未被开发出来。

“用户写提示词其实是很高门槛的。长文本需要组织语言、反复修改，这会让人不愿意开口。”但语音是时间向前推进的过程，用户说出来就可以继续下去，哪怕说错了也能反悔，互动过程更加自然。

他说，在与 Reald Avatar 合作构建的虚拟分身中，一开始系统响应时间为 5～9 秒，用户体验非常糟糕。后来他们加入了“预响应机制”，即大模型会先说出“让我想想”、“这个问题挺有趣”等缓冲语句，填补这几秒的空白，大幅提升了体验。

他们还发现，给语音系统加上“呼叫中心背景音”也会缓解等待感。这种小技巧虽然简单，却是构建语音系统时非常重要的工程方法论。“语音 Agent 的运行逻辑和文本 Agent 是完全不同的。”

同时，他也强调 MCP 协议在未来多模型系统中的价值。当前企业在构建 Agent 时常常需要连接多个数据源、API、服务接口，如果每一对都要手写适配器，维护成本极高。

“MCP 是一次真正意义上的接口标准化尝试。”吴恩达表示。他指出，目前 MCP 服务端实现仍不稳定，很多认证机制不完善、Token 管理不一致，但整体方向是正确的。未来 MCP 应该发展出分层式资源发现机制，不再是列出一大堆平铺的 API，而是让 Agent 能结构化地发现调用路径。

他总结道，我们正在迈向一个“n 个 Agent 对接 m 个数据源”的世界，MCP 的存在让它从 n×m 的维护成本变成 n+m 的接口管理，这是一次计算复杂度的飞跃。

胜负手取决于技术理解和执行速度

在对谈最后，吴恩达谈到 AI Fund 的工作。他表示，AI Fund 并不做外部投资，而是共同创办公司。他们在筛选合作对象时最看重两点：

一是“技术理解力”。他说，现在很多人讲市场、讲定位、讲 go-to-market 策略，这些当然重要，但都是可以短期内补课的。而对技术的理解、对系统的建构直觉，是长时间积累的稀缺能力。

二是“执行速度”。吴恩达表示，他见过一些团队，在 2 周内完成其他团队 3 个月才能做完的事情。而这类速度，几乎是成败的分水岭。“很多团队从来没见过‘一个优秀团队到底能有多快’。”他说。

他最后说，无论是否是程序员，未来最重要的技能就是“能精确表达你想让计算机做什么”。他说：“哪怕你是 CFO、法律顾问、前台，如果你能写一点 Python，哪怕很基础，也能极大提升你和 AI 合作的能力。”

本文由人人都是产品经理作者【江天 Tim】，微信公众号：【有新Newin】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。