注意了！本文纯干货，比较硬核！

前几天，吴恩达和LangChain 联合创始人 Harrison Chase 进行了一场对话。

他们讨论了目前AI领域现存的一些挑战。

我个人根据自己的一些Agent构建经验，也是有一些自己的想法。

不过他们聊的太多了，干货也太多了，我太懒了，一次是真写不完，还是分多篇文章写吧。

感兴趣的可以自己先提前去听听。

下面是他们的对话原文的一部分：

Harrison Chase：你提议我们不去纠结一个应用是不是“Agent”（代理），而是去关注它有多“Agentic”（具备代理性）。能不能再解释一下这个观点？

吴恩达： 我之所以提出这个观点，是因为我发现大家在不停地争论：“这个是 Agent 吗？”“这个不算吧？”——各种不同的定义争议：它够不够自主？是不是符合某个标准？

我当时的感觉是，与其花那么多时间争论这个是不是 Agent，不如我们整个社区换个方式思考：把“Agenticness（代理性）”看作一个光谱——有些系统代理性强，有些弱。

你想做一个稍微具备一点自主性的 Agentic 系统，或者一个非常自主的系统，都是可以的，没必要非得争论“这算不算 Agent”。

所以我提议，我们就叫这些系统“Agentic systems”，然后专注于怎么构建它们。这种思维方式，其实帮我们节省了大量争论时间，让我们能更快进入实操阶段。

Harrison Chase：你怎么看这个观点——从“低自主性”到“高自主性”？现在大家在构建系统时，大多处在哪个位置？

吴恩达： 很多企业里的实际工作，是让员工在网页上填写表单、搜索信息、查数据库有没有合规风险、判断是否可以向某些客户销售某类产品；或者是复制粘贴一些数据，再做个搜索，再粘贴到另一个表单中。这些业务流程，往往是非常线性的，偶尔出现一点小循环或小分支，通常意味着流程失败，比如因为某个条件不满足被拒绝。所以，我看到大量的机会，都来自这些简单流程。

而我也注意到，企业在把已有流程转变为“Agentic workflow（代理性工作流）”时，仍面临很大挑战：比如，你应该把流程拆分到什么样的粒度？任务要分成哪些微步骤？当你构建了一个原型，但效果不够好时，你要改进哪一个步骤才能提升整体效果？这种“从复杂任务中拆解出可执行的微步骤”、设计工作流结构、加评估机制等能力，其实现在还比较稀缺。

当然，更复杂的 Agentic 工作流也非常有价值，尤其是包含大量循环的那些。但就“数量”来说，现在的机会，还是主要集中在这些更简单的线性流程里，大家正在一步步把它们系统化、自动化。

Harrison Chase：你做了很多深度学习相关的教学，也有很多课程是为了帮助大家理解和构建 AI Agents。那么你觉得对于 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：有哪些“乐高积木”组件是现在被低估了，但你会推荐大家去关注的？

吴恩达： 虽然大家现在都在谈论评估这件事，但很多人其实并没有真正去做。我不太明白为什么不做，可能是因为大家通常认为写一个评估系统是一项巨大而严谨的任务。但我自己是把评估当成一个可以在 20 分钟内快速搭起来的小工具，可能做得不够完美，但可以作为我人工 评估的补充。

经常会发生这样的事：我构建了一个系统，然后某个问题不断出现。我以为修好了，它又坏了，再修好，又坏了。这时候我就会写一个非常简单的评估，可能只包含五个输入样例，用一些非常基础的 LLM 作为评审，只针对这个特定的回归问题做检测——比如“这个地方是不是又坏了”。我并不会完全用自动化评估取代人工评估，还是会亲自看输出。但这个简单的评估可以帮我减轻一点负担，自动跑一下，让我不用每次都手动去检查。

然后会发生什么呢？就像我们写论文一样，一开始只是搭一个非常简陋、明显有缺陷的评估系统。但等你有了初版，你会想“其实我可以改进它”，然后就开始迭代优化。很多时候我就是从一些糟糕透顶、几乎没什么帮助的评估开始做起的。然后随着你查看它的输出，你会发现“这个评估系统是坏的，但我可以修好它”，就慢慢让它变得更好。

我觉得吧，有两个点比较重要。

是不是Agent有那么重要么？

不了解Agent的朋友总在纠结一个应用是不是Agent，属实是本末倒置了。

因为很多定义并非是“非此即彼”的，Agent并没有严格的边界，毕竟Agent的概念也早在几十年前就已经有人提出来过。

目前一些比较火的概念：

• RPA：自动操控电脑等设备进行一系列模拟人类点击的操作。
• Coze/Dify：将一系列工具按照一定的执行顺序串联起来，实现工作流的自动执行。
• Manus：自动将一个任务分解为子任务工作流，并自动通过一系列工具完成工作流的执行。
• MCP：通过MCP、A2A等协议，便捷性的通过代码直接调用各种工具，用代码实现工作流。并可以通过Cursor等工具自动生成这些代码，实现工作流的自动生成。

真要说起来，这些东西做出的程序或产品，那都能称之为Agent，都能够模拟人类的行为自动执行某些任务并给出最终结果反馈给人类。

而就像吴恩达说的一样，他们的自主性程度可能不太一样。

有些Agent只能固定的遵循特定工作流做一些小任务，而有些Agent能够自动生成工作流并自主探索任务的可行性。

而目前基于Agent技术还未成熟的原因，更大的或者说更有价值的机会，可能还是在于一些更简单的线性任务上，能够更容易做出对应的Agent并实际产生应用价值。

一个Agent究竟如何才能做得更好呢？

所以怎么做好一个Agent呢？

重点就在于“评估”系统，只要能够检验出哪里有问题，那么只需要无数次优化Agent对应的部分即可。

在足够的测试次数和时间之下一定可以产出更高性能的Agent，Agent的能力上限由评估Agent系统能力的上限决定。

怎么理解呢？

这就类似于机械零件生产，生产零件的精度上限由检验精度的技术手段上限决定，而不是由生产设备本身的精度上限所决定。

有点抽象的，啥意思呢？

我来举个例子。

本来一个机器只能生产出1mm误差内的零件，但现在需要一个1.3mm的零件该咋整？

首先你得有测量一个零件是否有1.3mm的方法吧，记住哈，测量方法可不等于生产方法。

然后直接大力出奇迹，生产100个长度在1mm~2mm之间的零件，总能随机搞出个1.3mm的零件吧，不行就继续加数量。

然后用最质朴的方法，一个个的评估零件是否符合要求，留下符合要求的零件就行了。

那生产设备的精度就没用吗？

那肯定是有用的。

你想想啊，一个能将零件范围控制在1mm~2mm的机器与一个只能控制范围在1mm~10mm的机器，哪个产出的零件碰运气碰到1.3mm的概率更大呢？

很简单的概率学问题对吧，很明显机器性能越好，测试次数和成本会越低。

而成本越低，就意味着更容易进入我们普通人的生活中，否则只能是停留在实验室里。

Agent也是一样，只要有更强的评估方法就能让Agent性能更强。

拿提示词来讲，只要有评估Prompt好坏的策略，大不了写一万个Prompt测试，总能找到最好的Prompt。

而当我们拥有更高精度的零件后，就可以用这些零件造出拥有更高精度的生产设备。

所以这个顺序应该是：已有的生产设备→找到更好的评估方法→造出更高精度的零件→造出更高精度的生产设备。

而Agent系统也可以用同样的道理。例如：

已有通用的LLM，当有了更好的LLM生成结果的评估方法就能收集到更好的正确QA的数据集，用这些数据集就能微调出更好的领域LLM，增强对应Agent组件的性能。

现在大多数Agent系统评估的方法都是人工评估，这种“经验性判断”十分不严谨。

可以说这种评估压根就没有精度可言，纯粹是主观判断。

就跟早期没有测量工具时用肉眼判定长度一样，所以基于这种评估方法构建的Agent妥妥的是做不好的。

往期文章

我是关注AI提效与AI智能体的辰星。

谢谢你看我的文章，也祝你在AI时代能找到自己真正想要的生活。

也可以链接我，领取之前我整理的AI相关的一些学习资源。