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 合作的能力。”

文章来自于“有新Newin”，作者“有新”。