> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 从AI工作流到自主代理
- URL: https://www.hubwiz.com/blog/from-ai-workflows-to-autonomous-agents/
- Published: 2025-03-28T02:53:19.000Z
- Updated: 2025-03-28T02:53:19.000Z
- Description: 如今的大多数 AI 驱动的工作流并不是像我们想象的那样通过推理来解决问题。它们是一套精心设计的安全护栏，用来控制 LLM 的行为。
- Author: admin
- Tags: APPLICATION, AGENT, #Import 2026-10-14 14:41

构建 AI 代理应该很简单。这就是每个新框架一直在承诺的。插入一个 LLM，连接一些 API，也许再加上一个记忆模块，突然间你就有了一个“自主系统”。

但如果你实际上尝试过在生产环境中让它们工作，你会发现这个幻想很快就会破灭。在受控演示中，一切看起来都很棒——代理检索信息，推理解决问题，并将工具调用串联起来。然后你把它们放在现实世界中，突然间，它们自信地做出错误的决定，陷入无用查询的循环，或者更糟的是，在任务不符合其预期时完全崩溃。

[Anthropic 最近写了一篇关于工作流和代理之间区别的文章，总体上他们说得对](https://www.anthropic.com/engineering/building-effective-agents?ref=hubwiz.com)。你也可以访问 [LangGraph 的这个链接](https://langchain-ai.github.io/langgraph/tutorials/workflows/?ref=hubwiz.com) 查看不同工作流的快速入门示例。工作流是结构化的、可预测的和可重复的——LLM 遵循预定义的步骤，在明确的参数内执行任务。另一方面，代理应该适应环境，选择自己的工具，并根据实际情况调整方法。这是理论。在实践中？这种区别并不总是清晰，我们今天所说的大多数“代理”只是稍微灵活一点的工作流。

有理由让工作流仍然占据主导地位。它们有效。如果你正在运行一个 AI 驱动的客户支持系统、文档处理器或编码助手，你不需要动态推理——你想要的是能稳定高效完成工作的系统。而我们构建这些工作流的方式决定了它们处理实际任务的能力。

如今的大多数 AI 驱动的工作流并不是像我们想象的那样通过推理来解决问题。它们是一套精心设计的安全护栏，用来控制 LLM 的行为。Anthropic 对它们的分类是有道理的，但如果你仔细观察，每种方式都有其优点和明显的局限性。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-594.png)

增强型 LLM——AI 工作流的基础块

**提示链** 是最常见的一种方法之一。与其一次性将整个问题抛给模型，不如将其分解为顺序的子任务，验证每一步后再继续前进。这是一种很好的方法来强制结构化并提高准确性，特别是在复杂推理任务中。但它也引入了瓶颈。更多的步骤意味着更多的延迟。更多的步骤还意味着更多的失败点——如果一步失败，下游的所有内容都会崩溃。而且更糟糕的是，链式操作并不总是意味着更好的推理——有时只是更冗长的推理，最终仍然得出错误的答案。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-595.png)

提示链工作流

**路由框架** 解决了一个不同的问题——确保正确的模型处理正确的任务。与其强迫单一的 LLM 去做所有事情，路由可以确保数学问题交给数学模型，代码相关任务由经过微调的编程模型处理等。这使得事情更加高效。但路由有一个巨大的盲点：LLM 不擅长了解自己的局限性。LLM 不会总是意识到某个任务超出了它的能力范围。它会尝试解决，自信地胡编乱造，并以不明显的方式失败，直到有人后来发现。缺失的部分是什么？一种自我评估机制。直到模型能够识别何时应该将任务转交给其他模型而不是自己尝试解决，仅靠路由是不够的。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-596.png)

路由工作流

**并行化** 看起来像是一个简单的胜利——为什么按顺序运行步骤，而不同时处理多个子任务呢？这对摘要、研究工作流或不依赖严格顺序的任务很有用。但这里的问题出现了：结果合并。当两个并行输出相互矛盾时会发生什么？如何确保独立完成的不同任务之间的一致性？今天的大多数系统对此没有好的答案。它们只是选择其中一个并继续，即使答案并不完全合理。这里的真正挑战不是同时运行多个任务，而是将结果合成成连贯的东西。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-597.png)

并行化框架

**协调器-工作者** 模型是事情开始看起来更像是“代理”的地方——一个中心系统将任务分配给不同的组件，以灵活、可扩展的方式分发工作。这对于处理复杂的多步问题非常有用，并引入了一种比僵硬管道更具适应性的结构。但这里有个问题：它仍然是一个工作流。协调器仍然遵循预定义的逻辑。它仍然依赖于硬编码规则来决定任务去向哪里。如果它做出了错误的决定？整个系统都会受到影响。更重要的是，它仍然缺乏真正的适应性——即超出我们编程模式之外修改自身行为的能力。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-598.png)

协调器-综合器工作流

**评估器-优化器循环** 被认为是解决这些问题的答案。评估器对模型的输出进行评分，优化器基于此反馈优化流程。理论上，这意味着系统会随着时间的推移变得更好。现实中？它完全取决于你的评估指标有多好。如果评估器有缺陷，优化器会强化不良行为而不是修复它们。垃圾输入，垃圾输出。如果没有强大的评估系统，优化循环不会真正改善推理——它们只会让失败变得更高效。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-599.png)

评估器-优化器工作流

那么代理在哪里适合这一切呢？目前还不适合。我们今天所说的“代理”仍然是高度结构化的工作流，只是稍微灵活一些。它们不是动态地思考问题，而只是在预先定义的策略之间进行选择。如果我们真的想超越工作流并构建真正实用的 AI 代理，我们需要解决四个关键问题：**自我意识、可解释性、安全性和可扩展性。**

![](https://www.hubwiz.com/blog/content/images/2025/03/image-600.png)

AI 代理的自我意识、可解释性、安全性与可扩展性

**自我意识** 至关重要。今天的代理不知道自己什么时候错了。真正的代理需要认识到不确定性，调整自己的方法，并知道何时停止。现在，它们只是不断生成——即使应该重新评估自己的推理时也是如此。

**可解释性** 是另一个缺失的部分。工作流容易调试，因为每一步都是事先已知的。代理？没那么容易。如果代理做出了错误的决定，你怎么追溯它为什么会这样做？现在，你做不到。一个真正的代理不仅会产生答案，还会能够解释其推理的每一步。

**安全性** 是最大的风险，没有人愿意谈论。一旦你给代理提供对外部工具、API 或自动化系统的访问权限，你就引入了漏洞。目前，AI 的安全性主要集中在内容审核上——但这还不够。代理需要架构上的保障措施，防止它们执行危险或无意中的操作。

最后，**可扩展性**。工作流之所以能扩展是因为它们有结构。代理不行——因为它们的自治程度越高，失败就越不可预测。现在，我们的应对方式是投入更多计算资源——更大的模型、更长的...更大的上下文窗口，更多的内存。那不是真正的解决方案。一个真正的代理不会仅仅在任务复杂性上扩展——它会在处理意外场景时扩展。这是缺失的一环。

我对AI代理的看法……

现在，我们称工作流程为“代理”，因为它比承认我们还没有构建真正的自主性更容易。向前迈进的突破不会来自更大的模型、更好的提示或更长的上下文窗口。它将来自知道何时出错、能够解释其推理并且在事情变得不可预测时不崩溃的AI。这就是需要发生的事情。尽管有炒作，但我们还没有达到这个目标。但是，如果我们专注于真正的决策，而不仅仅是更好的自动化，我们可能会最终实现这一目标（可能比你想象的要早）。

---

原文链接：[From AI Workflows to Autonomous AI Agents and How We Can Get There](https://generativeai.pub/ai-workflows-vs-ai-agents-and-why-building-ai-agents-is-messier-than-you-think-58c426c5eebb?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处