Hi，大家好，我叫秋水，当前专注于 AI Agent （智能体）。

近期许多朋友来问我：

商用 AI Agent，如何选择开发框架？

Manus、Coze 空间等产品相继推出，目前学习 Coze、Dify 等的 AI Agent 平台还有用吗？

带着这个问题，我来为大家解读一下 LangChain 刚出的一篇文章《如何思考 AI Agent 框架》。

这篇文章分为四部分：

第一部分：什么是 AI Agent（智能体）

第二部分：构建 AI Agent 的难点

第三部分：如何评价一个框架的好坏

第四部分：Coze 开发工作流是否会被 Agent 开发平台取代

文章有点长，可以先收藏，慢慢观看。

如果看完对你有协助，希望一键三连，谢谢。

面向小白的《从0到1的AI智能体训练营》也开课了

https://qiushuiai.feishu.cn/wiki/MHHdwjhPHiuFWBk8OWHcTsAansf?from=from_copylink

什么是 AI Agent？

在当前的大模型厂商的官方，貌似都没有对 AI Agent 做过一个精准的定义。

我们看一下 OpenAI 的定义：

Agents 是能取代你独立完成任务的系统。

这个实则是定义了一种未来，通用 AI Agent，目前当下还没有达到这个程度。

相比之下，Anthropic 的定义就比较接地气：

“Agent”可以用几种方式来定义。

一些客户将 Agent 定义为完全自主的系统，它们在较长时间内独立运行，使用各种工具来完成复杂的任务。

另一些人则用这个词来描述遵循预定义工作流程的实现。

在 Anthropic，我们将这些都归类为 Agentic 系统，但我们在工作流 和 Agent 之间划出了一个重大的架构区别：

工作流是通过预定义路径编排 LLM 和工具的系统。

而 Agent 是由 LLM 动态规划其自身的流程和工具使用，从而控制其完成任务的方式。

Anthropic 的定义更贴合目前的情况，他在定义中提到了，工作流、Agent、Agentic 系统。

接下来，我们分别介绍一下他们三者之间的区别和关系。

Agent

Agent 指的是 LLMs（大模型）自主规划控制任务的执行，像 Manus、扣子空间等。

让我用写文章的例子来说明 Agent 的运行特点：

1. 你向 Agent 下达任务：”帮我写一篇关于可持续农业的文章”
2. LLM（大模型）规划写作任务，开始撰写一篇文章初稿，在这个过程中会调用联网搜索等工具。
3. 初稿完成后，Agent 会针对如下问题进行检查
4. 文章是否符合要求的主题和结构
5. 内容是否逻辑连贯
6. 信息是否准确
7. 是否需要更多数据支持论点
8. 针对检查的结果，Agent 再次调用大模型执行第二次循环。
9. 当 Agent 认为文章满足特定条件时，就会停止循环，输出文章。

这个过程可能会经历多个循环。列如，Agent 生成的初稿，反馈：”请添加更多关于堆肥技术的内容”，然后调整文章，再次进入行动-反馈循环，直到最终达到满意的结果。

这种方式，LLM（大模型）控制了整个执行过程，自主性强，可预测性弱。

工作流

在工作流里，LLM（大模型）的控制较少，每一步执行步骤，都是我们预先定义好的。

还是写文章的例子，如果用工作流来执行的话，就是提前定义好工作流执行的每个节点，例如：

1. 你向 Agent 下达任务：”帮我写一篇关于可持续农业的文章”
2. 规划文章大纲
3. 撰写每一章的内容
4. 如果需要联网的话，配置网络搜索工具
5. 对每一章内容进行审核
6. 针对审核意见，改善内容
7. 汇总各章内容，形成最终文章

通过例子，可以看到工作流整个运行节点都是预先配置，LLM 的自主性弱，可预测性强。

Agentic 系统

Agentic 系统就是将 Agent 和工作流结合在一起。

选择工作流还是 Agent？

在我们实际应用过程中，不要纠结于是用 Agent 还是用工作流，根据实际应用场景找到最简单的解决方案。

OpenAI 和 Anthropic 都明确指出，在许多情况下，工作流程更加简单、可靠、经济、快速且性能更佳。

Anthropic 的智能体开发指南中，明确的说过

在使用 LLMs 构建应用程序时，我们提议找到最简单的解决方案，并在必要时才增加复杂性。这可能意味着根本不构建 Agentic 系统。Agentic 系统一般会牺牲延迟和成本以换取更好的任务性能，您应该思考何时这种权衡是合理的。

当需要更多复杂性时，工作流为定义明确的任务提供了可预测性和一致性，而当需要大规模的灵活性和基于模型的决策时，Agent 则是更好的选择。

构建 AI Agent 的难点有哪些？

真正开发过实际应用场景 AI Agent 的人，大多数都会同意构建 Agent 很难。

或者更准确地说，构建一个原型 Agent 很容易，但构建一个可靠的、运行准确、能够支撑业务运行的 Agent 就困难多了。

真正的难点在于如何让它运行准确。

你可以轻松做出一个看起来不错的演示，但能否让它可靠的、准确的、稳定的运行，没有大量调试过程是不可能的。

几个月前，LangChain 对 Agent 开发者进行过一项调查，问他们：”Agent 投入生产最大困难是什么？”.

排名第一的就是：性能质量，让 Agent 准确、稳定的运行超级困难。

那造成运行不好的缘由，大多数在于 LLM（大模型）。

而 LLM 为什么会表现不佳？主要有两个缘由：

1. 选择的大模型能力不行
2. 传递给大模型的上下文错误或不完整

根据 LangChain 的经验，一般是第二种情况，那么，都是哪些方面缘由造成的呢？

• 系统消息不完整或太短
• 用户输入内容模糊
• 没有正确的调用工具
• 工具描述不清晰
• 没有传入正确的上下文
• 工具调用返回的格式不佳

核心难点：

构建可靠的 Agentic 系统的难点在于，确保 LLM（大模型）在执行的每一步都有正确的上下文。

任何使你难以精准的控制传递给 LLM 内容的框架，都会降低 Agent 运行的准确度。

如何评价一个框架的好坏？

在选择不同框架的时候，或者评估哪个框架好，我们需要尤为关注如下几个方面。

短期记忆管理（Short term memory）

如今大多数 Agentic 系统都包含多轮对话组件，一个好的框架满足支撑在生产环境下运行的短期记忆管理。

这看似简单，但在生产环境中实现可靠的管理并不容易。

• 需要处理会话超时
• 需要管理存储成本
• 需要处理并发请求
• 需要实现用户隔离

长期记忆能力（Long term memory）

虽然仍处于早期阶段，但 LangChain 超级看好 Agentic 系统从经验中学习的能力（例如跨对话记住内容）。

一个成熟的框架应提供生产环境下的跨多轮会话记忆的存储。

• 向量数据库集成
• 知识图谱管理
• 相关性自动检索
• 记忆衰减和优先级机制

人机协作支持（Human-in-the-loop）

许多 Agentic 系统可以通过人机协作组件得到更进一步的提升。

什么是人机协作呢？就是在 Agentic 系统过程中，可以从用户获取反馈、批准工具调用或编辑工具调用参数。

例如：

• 金融顾问 Agent 在执行大额交易前请求人工批准
• 客服 Agent 在难以处理的问题上请求人工协助
• 内容生成 Agent 让用户编辑和调整其输出

事后人工干预（Human-on-the-loop）

除了允许用户在 Agentic 系统运行时人类参与决策外，让用户能够在事后检查 Agent 的运行轨迹，甚至回到早期步骤并从那里重新运行也很有用。

流式输出（Streaming）

大多数 Agentic 系统运行需要一段时间，因此向最终用户提供更新对于提供良好的用户体验至关重大。

一个好的框架应该它允许输出结果可以实时地、分批传递给用户，而不是等待所有处理完成后一次性返回结果。

调试与可观测性（Debugging/observability）

构建可靠的 Agentic 系统的难点在于确保向 LLM 传递正确的上下文。

能够检查代理运行的所有步骤，以及每一步的输入/输出对于构建可靠 Agentic 系统至关重大。

一个好的 AI 可观测性系统应该让你：

• 查看 LLM 接收的提示
• 跟踪工具调用及其结果
• 每一步的运行时间和成本

优化能力（Optimization）

与其手动调整提示，有时根据评估数据集自动优化 Agentic 系统可能更容易。

目前这是一个值得思考的能力，dspy 是这方面最好的框架。

工作流是否会被 Agent 取代？

支持 Agent 取代工作流的观点一般是：虽然目前 Agent 在工具调用的效果还不够好，但随着大模型能力提升，未来你只需要简单的工具调用，Agent 就可以解决所有问题。

LangChain 认为以下几个观点是可以同时成立的。

• Agent 在工具调用的性能将会不断提升
• 控制输入到大语言模型的内容依旧至关重大（垃圾输入必然导致垃圾输出）
• 对于某些应用场景，简单的 Agent 就已足够
• 对于其他应用场景，工作流方案将更简单、更经济、更快速且效果更好
• 对于大多数实际应用，生产环境中的代理系统将是工作流和代理的组合体

这种观点认可了技术进步的可能性，同时也承认不同应用场景有不同的最佳解决方案，而不是简单地认为单一方法适用于所有情况。

Anthropic 的官方文章说过

在使用 LLMs 构建应用程序时，我们提议找到最简单的解决方案，并在必要时才增加复杂性。

这可能意味着根本不需要构建 Agentic 系统。

Agentic 系统一般会为了执行更复杂的任务而牺牲延迟和成本，您应该思考何时适用。

OpenAI 的官方文章也说过

在投入构建 Agentic 系统之前，请验证你的应用场景是否能明确满足这些标准。

否则，一个确定性的工作流解决方案可能就足够了。

大模型能力提升如何影响框架选择？

随着大模型能力的提升，我们可能会看到以下趋势：

1. 基础任务：对于基础任务，简单工具调用可能就足够了
2. 复杂任务：对于复杂、关键业务任务，Agent 和工作流混合方式依旧具有优势
3. 框架关注点的转变：框架将更少关注基本功能，更多关注高级功能（可观测性、人机协作等）
4. 垂直专业化增加：我们将看到更多针对特定行业的专业代理框架

我们应该如何应对这种趋势？

面对大模型技术的快速发展，我提议采取以下方法：

1. 从简单开始：对于新项目，从最简单的方法开始（例如工作流）
2. 逐步增加复杂性：只在需要时添加 Agent 功能
3. 保持灵活性：选择允许工作流和 Agent 混合的框架
4. 关注核心价值：不要被炫酷的 AI 技术分散注意力，专注于解决实际业务问题

今天的文章就到这里结束了，如果你觉得不错，随手点个赞、在看、转发三连吧。

如果想第一时间收到推送，也可以给我个星标⭐。

谢谢你看我的文章，我们，下次再见。