大型语言模型代理工作流的特征化：基于n8n生态系统的研究

# 大语言模型代理工作流特征研究：基于 N8n 生态系统的分析  
来源：https://arxiv.org/html/2606.29116  

∎ 11institutetext:唐雨田 22institutetext:格拉斯哥大学计算科学学院 22email:[email protected] 唐雨田为通讯作者 33institutetext:周宇明 44institutetext:南京大学计算机科学与技术学院 44email:[email protected] 55institutetext:陈华明 66institutetext:悉尼大学 66email:[email protected]  

（收稿日期：/ 录用日期：/）  

###### 摘要  

大语言模型（LLM）正迅速被应用于低代码和无代码自动化平台，非专业用户可在此类平台上设计结合自然语言理解与外部服务及 API 的工作流。LLM 代理是以 LLM 为核心“大脑”进行推理、规划并自主执行复杂多步骤任务的 LLM 系统。尽管近年来涌现了大量标准化评估基准，这些基准主要关注模型在知识理解、代码生成、数学推理等单一任务上的能力；然而，关于 LLM 代理在实际工作流生态系统中的部署方式及其运行特征，仍缺乏系统的实证研究和大规模分析。本文首次针对低代码自动化平台中的 LLM 代理工作流进行大规模实证研究。我们分析了 6000 多个公开可用的 n8n 工作流，并从任务分布、结构及工具使用模式、可靠性机制、自主性水平四个维度审视其设计。分析表明，LLM 工作流并非简单的提示响应流水线。相反，LLM 通常嵌入更广泛的自动化结构中，涉及控制逻辑、外部工具、通信服务、存储系统及人工审核节点。我们进一步发现，尽管许多工作流在 LLM 执行后包含了轻量级后处理或路由逻辑，但明确的可靠性机制（如结构化兜底路径、修复循环、故障特定告警和人工审批关卡）仍相对少见。这些结果揭示了 LLM 代理在实际自动化生态系统中日益增长的部署与可靠性、安全性、治理方面工程支持不足之间的差距。总体而言，本研究为研究人员、平台开发者和实践者提供了十项实证发现和五项研究启示，以助于理解和改进真实世界的 LLM 代理工作流。  

## 1 引言  

大语言模型（LLM）迅速推动了自然语言处理的最新技术水平。它们被广泛用于软件工程中的各类任务，包括代码生成、测试用例生成、代码摘要等。如今，LLM 被广泛用作代理，通过连接第三方工具或库，为终端用户提供实际服务。例如，一个由 LLM 驱动的编码助手可以充当代理：调用 Python 解释器执行生成的代码、从网页获取实时文档、或查询数据库以检索实时项目上下文。代理不再仅限于单一任务（如修复 bug 或生成代码片段），而是能自主运行测试、分析堆栈跟踪、并利用外部工具迭代优化代码。

然而，LLM 代理在真实工作流自动化环境（如 n8n）中的实际有效性仍未得到充分探索。这一差距至关重要，因为在此类环境中运行的代理面临着孤立研究中很少涉及的约束。LLM 代理工作流与传统单任务 LLM 应用存在根本差异。在真实世界的代理工作流中，代理不仅仅被提示生成文本答案或代码片段。相反，它嵌入在一个包含多个互连节点的工作流图中，每个节点代表具体操作，例如发送 HTTP 请求、查询数据库、调用代码执行模块、应用条件分支或等待外部触发器。在实践中，这些节点以工具或 API 的形式实现。因此，代理的行为不仅由底层语言模型驱动，还受到工作流结构、节点配置、数据依赖、执行顺序和运行时上下文的影响。例如，当我们要求一个编码代理为一个网站构建网络爬虫时，它可能首先检索目标网站的结构，检查相关页面，决定采用哪个框架，然后相应地生成代码。它还可能进一步执行生成的代码，观察运行时行为，并据此调整或修复代码。这表明，LLM 代理的行为不仅由模型能力推动和增强，还受到工作流结构、配置、可用工具和运行时反馈的影响。

**动机。** 因此，需要对 LLM 代理工作流进行系统性的特征描述。这种描述应考察常用节点类型、工具如何组合、数据如何在节点间流动、何处需要人工干预，以及执行过程中会出现哪些类型的故障。例如，代理可能选择了正确的工具但传入了错误的参数，检索到相关信息但传播到了错误的下游节点，或者生成了语法有效但语义与用户意图不一致的工作流。在工作流层面研究和表征 LLM 代理工作流，可以揭示代理在实际自动化环境中的实际运行方式，并为提高其可靠性、可用性和安全性提供实证依据。

**现有技术。** 近期研究已将大语言模型从被动的文本生成器转变为能够推理、规划、调用工具并与外部环境交互的代理。Toolformer 训练模型决定何时以及如何调用计算器、搜索引擎、翻译系统和日历等外部工具（schick2023toolformer）。已有工作在 LLM 推理、工具使用、代理架构、工作流生成和基于基准的评估方面取得了实质性进展（yao2023react; schick2023toolformer; qin2024toolllm; wu2024autogen; fan2024workflowllm; liu2024agentbench; zhou2024webarena; jimenez2024swebench; xie2024osworld）。然而，这些研究提供的实证证据有限，未能说明 LLM 代理在公共低代码工作流生态系统中是如何实际组装的。

**研究问题。** 为弥补这一空白，本文开展研究以回答以下问题：

*   **RQ1（任务）：** 在真实世界的自动化工作流中，LLM 用于执行哪些任务？  
    在该研究问题中，我们旨在理解 LLM 工作流的任务分布。这很重要，因为它揭示了以基准为中心的评估与实际应用之间的差距。它还有助于确定未来 LLM 代理、工具和评估研究应聚焦的主导应用场景。
*   **RQ2（结构与工具）：** LLM 工作流具有哪些结构性和工具使用模式？  
    在该研究问题中，我们旨在表征工作流结构和工具使用模式。它可以揭示实践者采用的常见架构设计、集成实践以及新兴的代理组合方式。
*   **RQ3（故障处理）：** 在工作流设计中，围绕 LLM 输出编码了哪些可靠性机制？  
    在该研究问题中，我们旨在了解工作流设计者如何应对可靠性问题。
*   **RQ4（动作耦合与人工控制）：** LLM 输出在多大程度上与外部动作耦合，以及工作流设计中如何放置人工控制？  
    在该研究问题中，我们考察设计层面的动作耦合和人工控制放置。我们并不声称测量运行时自主性。相反，我们分析工作流 JSON 是否编码了从 LLM 节点到外部动作节点的路径，以及这些路径是否经过工作流逻辑或明确的人工控制机制。

**贡献。** 总结而言，本文做出以下贡献：

*   这是对基于 LLM 的自动化工作流进行的**首次**大规模实证研究，分析了任务分布、集成模式和故障处理策略，以弥合基准评估与实际部署之间的差距。
*   我们分析了 N8n 上 6003 个公开可用的工作流，以理解 LLM 工作流是如何设计的。
*   我们研究了 LLM 工作流的可靠性和治理方面，包括故障处理机制、自主性模式和人工监督策略，揭示了工作流作者在实践中如何平衡自动化、鲁棒性和控制。
*   我们发布了数据集、分析框架和复现包，以促进未来对工作流感知型 LLM 代理、自动化系统、可靠性工程和代理治理的研究。

## 2 背景  

**工作流自动化中的 LLM。** 工作流自动化系统是一种自动化的业务流程，用于协调和控制参与者之间工作与信息的流转（tohr2001workflow）。随着大语言模型（LLM）越来越多地嵌入工作流自动化系统，用户能够设计自己的流水线，将 LLM 与其他第三方服务结合起来。在这些低代码/无代码环境中，LLM 很少孤立使用。相反，它们主要作为中间组件，用于转换非结构化文本或数据、翻译和理解服务输出的结果、或生成动作以触发后续事件。一个典型的工作流可以串联多个步骤。例如，在一个客户支持自动化工作流中，当新的支持邮件到达时，LLM 代理可以总结消息内容、提取所需动作、识别意图并评估紧急程度。根据情感分析结果，工作流随后可自动标记高优先级事件供用户跟进，并设置提醒。

**图 1：** 使用 GPT-4 自动生成草稿回复的 Gmail 邮件分类器

**本文范围。** 本文聚焦于 LLM 在工作流自动化系统中的集成，而非新的 LLM 架构或模型级基准。我们的分析单元是工作流设计：即 LLM 节点如何连接到触发器、逻辑节点、工具、外部服务和可靠性机制。因此，我们将公开可用的 n8n 工作流视为设计工件，这些工件揭示了用户如何将 LLM 与真实的自动化基础设施组合在一起。

**N8n。** N8n 是一个开源的工作流自动化平台，用户可以通过可视化、基于节点的编辑器连接应用程序、API 和服务。与 Zapier 等专有工具不同，它可以自托管，使组织能够更好地控制其数据和集成环境。凭借庞大且不断增长的社区驱动集成库，n8n 提供了一种灵活且可扩展的方式来设计和自动化跨多个领域的工作流。

**N8n 中的执行模型。** 在 N8n 中，工作流表示为节点和连接的图。通常有四种节点类型：  
（1）**应用/动作节点**：在工作流内执行操作，例如添加、删除和编辑数据，请求和发送外部数据，以及触发其他系统中的事件；  
（2）**触发器节点**：启动工作流并提供初始数据；  
（3）**核心节点**：可以是触发器或动作节点。与大多数节点不同，它们不绑定到特定的外部服务——而是提供通用功能，如逻辑、调度或通用 API 调用（例如 HTTP 请求、If、Switch、Merge）；  
（4）**AI 集群节点**：协同工作的节点组，主要用于 AI 工作流。每个集群有一个根节点和一个或多个扩展其功能的子节点。

**工作流运行示例。** 现在，我们以 N8n 中的“使用 GPT-4 自动生成草稿回复的 Gmail 邮件分类器”（N8n-8426）为例，说明工作流在实际中如何运行。图 1（https://arxiv.org/html/2606.29116#S2.F1）展示了整个工作流。具体而言，每 15 分钟轮询一次传入的 Gmail 消息，并将其传递给轻量级 LLM 分类器，该分类器将邮件路由到诸如高优先级、咨询或财务/计费等类别。请注意，某些设置/参数（例如每 15 分钟）可以从工作流的对应 JSON 描述文件中获取（参见列表 1（https://arxiv.org/html/2606.29116#LST1）），而不是直接显示在工作流图像中。工作流的 JSON 表示记录了工作流图、节点类型、节点参数、执行设置和连接类型。这使得静态检查 LLM 如何嵌入工作流设计成为可能。例如，JSON 文件揭示了 LLM 节点后是否跟有 IF 节点、AI 代理是否连接到工具、是否启用了重试设置、或者是否附加了结构化输出解析器。然而，JSON 不能完全揭示运行时行为，例如兜底分支是否在实际输入下被触发。因此，我们的分析将 JSON 视为编码工作流设计的证据，而非运行时正确性的证明。

每个部分调用定制的提示：紧急邮件生成简洁的、以行动为导向的草稿并附有澄清问题，咨询邮件得到礼貌且完整的回复并包含下一步操作，而计费消息则生成结构化回复，确认金额、到期日和发票 ID。然后，系统应用相应的 Gmail 标签，并将回复以草稿形式存储在原始邮件线程中。

**列表 1：** Gmail 自动生成草稿回复的对应 JSON 数据  

```
1 {
2   ...
3   "pollTimes": {
4     "item": [{
5       "mode": "everyX",
6       "unit": "minutes",
7       "value": 15
8     }]
9   }
10   ...
11 }
```

在此示例中，展示了 LLM 如何作为工作流代理而非独立的聊天机器人运行：将分类、提示条件生成和草稿持久化组合成一个可复现的流水线。它还突出了可测量的方面：分类准确率、草稿与最终发送之间的编辑距离、或按类别划分的延迟和成本，从而使此类工作流成为在实践和真实环境中评估 LLM 的有用测试平台。

## 3 实证研究与发现  

### 3.1 数据集  

*   **数据来源。** 本研究基于公开可用的、集成了大语言模型的 n8n 工作流模板。在 n8n 中，工作流是连接节点的集合，用于自动化流程，工作流可以导出和导入为 JSON 文件。因此，我们将工作流 JSON 文件作为主要分析工件。收集的工作流来自公共 n8n 模板生态系统，代表了用户为自动化、定制化和知识交流而共享的可重用示例。
*   **过滤标准。** 并非所有公共 n8n 工作流都使用 LLM。为构建数据集，我们应用了三个过滤步骤：  
    *   **第一**，我们选择至少包含一个 LLM 相关组件的工作流，包括明确的 LLM 提供者节点、AI 代理节点、聊天模型节点，或匹配已知文本生成/聊天完成端点的 HTTP 和 API 调用。示例包括 OpenAI、Anthropic、Hugging Face、Gemini、Mistral、Ollama、LangChain、AI Agent 和聊天模型组件。这确保选中的工作流是基于 LLM 的工作流；  
    *   **第二**，我们排除了没有有意义执行逻辑的工作流，例如包含孤立占位节点、未连接模板或可执行节点少于两个的工作流。我们避免只因节点数量少而过滤掉简单但有效的 LLM 工作流，因为诸如 Webhook → LLM → Email 或 LLM → Slack 等工作流仍可代表真实的 LLM 自动化应用；  
    *   **第三**，我们移除了重复的工作流。