别再折腾 AI 智能体了，大部分时候你根本用不着它！
嘿，大家好！今天咱们请来了超级厉害的 Hugo。他可不是一般人，给 Netflix、Meta 还有美国空军的工程师们都提供过咨询和指导，教他们怎么开发那些酷炫的 AI 大语言模型（LLM）系统。
Hugo 还专门开了一门课，叫做“LLM 软件开发生命周期”，从怎么搜索信息、评估模型，到怎么设计智能体，中间的各种门道都讲得清清楚楚。
Hugo 说： 我教过也指导过几十个团队开发基于 LLM 的系统，但老实说，我总是看到一个让人特别头疼的问题：
大家一上来就想搞智能体！他们搭记忆系统，加路由逻辑，定义各种工具，给角色编背景故事……感觉好像特别厉害，特别有进展。
结果呢？没多久就全崩了！而且一旦出问题（这几乎是必然的），谁都搞不清楚到底是哪里出了毛病。
是智能体把任务给忘了？是不是选错了工具？是不是活动部件太多，没法调试了？整个系统是不是从根本上就很脆弱？
我可是吃尽了苦头才明白这些道理的。就在六个月前，我用 CrewAI 搭了一个“研究团队”：三个智能体，五个工具，在纸上看起来简直是天衣无缝。但实际用起来呢？研究员竟然忽略了网页抓取器，总结器忘了用引用工具，协调器一遇到长文档就直接罢工了！一个看似完美的计划，结果却以一种惨烈的方式彻底瓦解了。
我给你们看一张图，这是我调试了无数个崩溃的智能体系统后，在课上总结出来的一个流程图。注意看最后那个小小的方框了吗？大部分时候你根本不需要智能体！ 但每个人都习惯从那里开始。
我从失败中吸取的教训：怎么完全避开那些坑
这篇文章就是关于我从这些失败中学到的东西，包括怎么才能彻底避开这些坑。
我接下来要讲的模式，灵感来自 Anthropic 公司的一篇文章，叫做《构建高效智能体》。但这可不是什么理论空谈，这些都是真实的代码，真实的失败，还有我在教授这些系统时做出的真实决策。 这里面的每一个例子，都来自于我亲自搭建或者调试过的项目。
你们会明白为什么智能体（大多数时候）不是正确答案。更重要的是，你们会学到该怎么真正地去构建系统。
你们会学到：
* 为什么智能体通常不是你应该迈出的第一步。
* 解决大多数问题的五种 LLM 工作流模式。
* 什么时候智能体才是正确的工具，以及如何安全地构建它们。
所有的例子都在这个 GitHub笔记本里。
不要从智能体开始！
所有人都觉得智能体是你开始的地方。这也不能怪他们：各种框架把智能体做得看起来太简单了，演示视频也特别激动人心，科技圈的推特上更是各种炒作。
但我在搭建了 CrewAI 研究团队之后明白了一个道理：大多数智能体系统之所以崩溃，不是因为功能不够，而是因为它们太复杂了。
在我的演示里，有三个智能体一起工作：
* 一个研究员智能体，可以浏览网页。
* 一个总结器智能体，可以访问引用工具。
* 一个协调器智能体，负责任务的分配。
这听起来很标准，对吧？但实际上：
* 研究员有 70% 的时间都忽略了网页抓取器。
* 总结器在处理长文档时完全忘了使用引用工具。
* 当任务没有明确规定时，协调员就直接撂挑子不干了。
等等，“智能体到底是个啥？”要回答这个问题，我们得先看看 LLM 系统的四个特点。
* 记忆： 让 LLM 记住过去的交互。
* 信息检索： 通过 RAG（检索增强生成）为上下文添加更多信息。
* 工具使用： 让 LLM 访问各种函数和 API。
* 工作流控制： LLM 输出控制要使用哪些工具以及何时使用。
所有这些加起来，就构成了一个智能体。
当人们说“智能体”的时候，他们指的是最后一步：LLM 控制工作流。大多数人直接跳到让 LLM 控制工作流，却没意识到更简单的模式通常效果更好。使用智能体意味着把控制权交给 LLM。但是，除非你的任务动态到流程无法预先定义，否则这种自由往往弊大于利。大多数时候，由人类负责的简单工作流仍然优于成熟的智能体。
我已经和几十个团队一起调试过这种模式了：
* 我们有多个任务需要自动化。
* 智能体看起来是显而易见的解决方案。
* 我们构建了带有角色和记忆的复杂系统。
* 结果一切都崩溃了，因为协调比我们想象的要困难得多。
* 我们意识到更简单的模式会更好。
要点： 除非你明确知道你需要记忆、委托和规划，否则请从更简单的工作流（比如链式或路由）开始。
你应该使用的工作流模式
这五种模式来自 Anthropic 的分类法，并且已经在我的笔记本中实现、测试和演示过了：
(1) 提示链式（Prompt Chaining）
用例： “根据 LinkedIn 个人资料写一封个性化的外联邮件。”
快速链式工作流
你想联系你感兴趣的公司里的人。首先从 LinkedIn 个人资料中提取结构化数据（姓名、职位、公司），然后生成一封量身定制的外联邮件来开启对话。
这里有 3 个简单的步骤：
1. 将原始 LinkedIn 个人资料文本转换为结构化数据（例如，姓名、职务、公司）：
linkedin_data = extract_structured_data(raw_profile)
2. 为个性化添加相关的公司背景（例如，使命、开放职位）：
company_context = enrich_with_context(linkedin_data)
3. 使用结构化的个人资料 + 公司背景生成个性化的外联邮件：
email = generate_outreach_email(linkedin_data, company_context)
指导原则：
* 什么时候用： 任务按顺序一步步进行。
* ❌ 失败模式： 如果其中一步失败，整个链条就断了。
* 优点： 容易调试，流程可预测。
(2) 并行处理（Parallelization）
用例： “从配置文件中提取结构化数据。”
现在链式处理已经搞定了，你希望一次处理多个配置文件，并加快处理速度。你可以把每个配置文件拆分成教育、工作经历和技能等部分，然后并行运行 extract_structured_data()。
这里有两个简单的步骤：
1. 定义任务以并行提取关键配置文件字段：
tasks = [ |
2. 同时运行所有任务并收集结果：
results = await asyncio.gather(*tasks)
指导原则：
* 什么时候用： 独立的任务可以同时运行，速度更快。
* ❌ 失败模式： 可能出现竞态条件、超时问题。
* 优点： 非常适合从多个来源提取数据。
(3) 路由（Routing）
用例： “LLM 对输入进行分类，并将其发送到专门的工作流。”
假设你正在构建一个支持工具，用于处理产品问题、账单问题和退款请求。路由逻辑会对每条消息进行分类，并将其发送到正确的工作流。如果分类不清楚，则回退到通用处理程序。
这里有两个简单的步骤：
1. 根据配置文件类型选择处理程序：
if profile_type == "executive": |
2. 使用选定的处理程序处理配置文件：
result = handler.process(profile)
指导原则：
* 什么时候用： 不同的输入需要不同的处理方式。
* ❌ 失败模式： 边缘案例可能会漏掉。
* 优点： 为未知情况添加全面的路由。
(4) 协调器-工作者模式（Orchestrator-Worker）
用例： “LLM 将任务分解为 1 个或多个动态步骤。”
你正在生成外发邮件。协调器将目标公司分类为科技公司或非科技公司，然后委托给专门的工作人员为该上下文生成消息。
这里有两个简单的步骤：
1. 使用 LLM 将配置文件分类为科技公司或非科技公司：
industry = llm_classify(profile_text)
2. 根据分类发送给相应的工作人员：
if industry == "tech": |
协调器-工作者模式将决策与执行分离：
* 协调器控制着流程：它的输出控制着需要发生什么以及以什么顺序发生。
* 工作人员执行这些步骤：他们处理委托给他们的特定任务。
乍一看，这可能类似于路由：分类器选择一条路径，然后处理程序运行。但在路由中，控制权是完全移交的。在本例中，协调器保留控制权：它启动分类，选择工作者，并从头到尾管理流程。
这是一个最小版本的协调器-工作者模式：
* 协调器控制流程，做出决策并协调子任务。
* 工作人员根据这些决定执行专门的步骤。
你可以使用多个工作者、顺序步骤或聚合逻辑来扩展它（我鼓励你这样做！如果你这样做了，请给我发个 PR），但核心结构保持不变。
指导原则：
* 什么时候用： 任务需要专门的处理。
* ❌ 失败模式： 协调器分配子任务不佳或错误地分解任务。
* 优点： 保持协调器逻辑简单明了。
(5) 评估器-优化器（Evaluator-Optimizer）
用例： “优化外展电子邮件，使其更好地满足你的标准。”
评估器-优化器工作流
你有一个邮件生成器在运行，但你希望改善邮件的语气、结构或与标准的对齐程度。你可以添加一个评估器，它会给每条消息打分，如果没有通过，就将其发回生成器，并附上反馈，然后循环，直到它达到你的标准。
这里有两个简单的步骤：
1. 从配置文件生成初始电子邮件：
content = generate_email(profile)
2. 循环，直到电子邮件通过评估程序或达到重试限制：
python
while True:
score = evaluate_email(content)
if score.overall > 0.8 or score.iterations > 3:
break
content = optimize_email(content, score.feedback)
指导原则：
* 什么时候用： 输出质量比速度更重要。
* ❌ 失败模式： 无限优化循环。
* 优点： 设置明确的停止条件。
总结： 大多数用例不需要智能体。它们需要更好的工作流结构。
什么时候才应该用智能体（如果你真的需要的话）
当有一个敏锐的人在循环中时，智能体才能大放异彩。这是我的热门观点：智能体擅长处理不稳定的工作流，在这种情况下，人类的监督可以发现并纠正错误。
当智能体确实运行良好时：
示例 1：数据科学助理
一个智能体可以编写 SQL 查询、生成可视化并建议分析。你在那里评估结果并修复逻辑错误。智能体在探索数据方面的创造力胜过了僵化的工作流。
要构建这样的东西，你需要让 LLM 访问 run_sql_query()、plot_data() 和 summarize_insights() 等工具。智能体根据用户的请求在它们之间进行路由——例如，编写查询、运行查询、可视化结果以及生成叙述性摘要。然后，它将每个工具调用的结果反馈到另一个 LLM 请求及其内存上下文中。我们通过一个活生生的例子，这种模式在我们的建设与 LLM 课程中。
示例 2：创意写作伙伴
一个智能体可以头脑风暴标题，编辑文案，并建议结构。人类判断质量并在需要时重定向。智能体擅长用人类的判断来构思。
示例 3：代码重构助手
提出设计模式，捕捉边缘情况，并提出优化建议。开发人员审查并批准更改。智能体发现了人类错过的模式。
什么时候不应该用智能体
* 企业自动化：
如果你正在构建稳定可靠的软件，就不要使用智能体。你不能让 LLM 来决定生产环境中的关键工作流。请改用协调器模式。
* 高风险决策：
金融交易、医疗诊断和法律合规——这些都需要确定性逻辑，而不是 LLM 瞎猜。
回到我的 CrewAI 研究团队：智能体不断忘记目标，跳过工具。这是我学到的：
* 失败点 \#1：智能体以为他们有上下文，但实际上没有。
问题： 长文档导致总结器完全忘记引用。
我现在会怎么做： 使用明确的记忆系统，而不仅仅是角色提示。
* 失败点 \#2：工程师未能选择正确的工具。
问题： 研究员忽略了网页抓取器，却支持一般搜索。
我现在会怎么做： 用明确的工具菜单来限制选择。
* 失败点 \#3：智能体处理协调不佳。
问题： 协调员在任务范围不明确时就放弃了。
我现在会怎么做： 建立明确的切换协议，而不是自由形式的委托。
要点： 如果你正在构建智能体，那就把它当成一个完整的软件系统来对待。不要跳过可观察性！
表格：什么时候使用 LLM、增强 LLM 或智能体
LLM：基础语言模型简单任务，如文本生成、摘要、翻译
增强 LLM：加入记忆、信息检索、工具使用需要上下文、外部数据或特定功能辅助的任务
智能体LLM ：控制工作流任务动态多变，需要人类监督，能够发现并纠正错误，例如数据科学助理、创意伙伴
我的看法： 智能体被过度炒作和过度使用了！
* 大多数时候，你需要的是更简单的模式，而不是智能体。
* 智能体在“人在环”的场景中表现出色。
* ❌ 不要将智能体用于稳定的企业系统。
* ️ 构建时要注重可观察性和明确的控制。
智能体被过度宣传了，也经常被滥用。在大多数实际应用中，简单的模式和直接的 API 调用比复杂的智能体框架效果更好。智能体确实有它们的用武之地，特别是当它们在需要人类监督和灵活性的“人在环”场景中才能大放异彩。但对于稳定的企业系统来说，它们引入了不必要的复杂性和风险。相反，你的目标应该是构建具有强大可观察性、清晰评估循环和明确控制的产品。