拒绝过度设计：何时使用简易管道，何时拥抱 Agentic Framework？

在大模型驱动的时代，我们很容易被各种炫酷的“Agentic Framework”所吸引，例如 LangGraph、Crew AI 等，似乎每一个新项目都需要一个基于图的引擎。但事实果真如此吗？我们是否经常在无意中过度设计了原本简单的线性流程？本文将探讨何时应该坚持使用简易管道，何时应该拥抱 Agentic Framework，以及如何根据实际需求做出明智的选择。

简易管道的魅力：简单、高效、易维护

对于步骤清晰、顺序执行的任务来说，简单的管道仍然具有不可替代的优势。例如，一个三步文本处理任务：清理用户提示、调用外部摘要 API、打包结果。在这种情况下，使用简单的 Python 函数，或者一个最小化的编排脚本，可能就是最佳选择。

简易管道的优点体现在以下几个方面：

可读性：开发人员可以清晰地看到代码的执行流程，易于理解和维护。
低开销：无需额外的依赖，配置简单，降低了项目的复杂性。
灵活性：可以针对每个步骤进行定制化的错误处理，而无需映射到复杂的图结构。

实际案例：数据标准化

假设我们需要将 CSV 文件中的数据进行标准化，然后加载到数据库中。使用 简易管道，我们可以编写一个脚本，包含以下几个步骤：

读取 CSV 文件。
清洗数据（例如，去除空格、转换数据类型）。
将标准化后的数据加载到数据库中。

这个过程简单明了，易于维护。

简易管道适用的场景

以下是一些适合使用 简易管道 的场景：

数据标准化：清洗和标准化 CSV 数据，然后加载到数据库中。
单 API 增强：调用地理编码服务，将坐标附加到记录中。
静态报告生成：提取摘要统计数据，并将其导出为 PDF 文件。

总而言之，当你可以轻松地在白板上将流程绘制为“A → B → C”时，就说明这个任务非常适合使用手动编写的管道。

复杂性涌现：何时管道开始崩溃？

随着时间的推移，“简单”的脚本可能会变得越来越复杂。例如：

API 调用失败时，需要进行重试，并使用指数退避策略。
用户输入需要额外的审查流程。
需要添加更多的工具，例如情感分析器、翻译 API 和拼写检查器。
为了满足 SLA，需要并行处理大量数据。
需要开箱即用的仪表板，以便监控每个步骤的成功/失败率。

此时，原本简洁的代码可能会变得像意大利面条一样，充斥着嵌套的 try/except 块、临时的线程池、自定义日志记录和自制的状态字典。用于处理复杂性的代码甚至超过了原始业务逻辑本身。

挑战与对应的管道解决方案

实际案例：文档处理的困境

想象一下，你需要构建一个文档处理管道，包含以下步骤：

使用 OCR 提取文本。
使用 LLM 进行摘要。
翻译成三种目标语言。
对每种翻译进行不良信息过滤。
保存所有输出并生成仪表板链接。

如果使用简单的 Python 脚本，你可能会遇到以下问题：

串行翻译循环：无法并行翻译。
内联重试逻辑：try/except 块会使代码变得混乱。
缺乏内置的可观察性：需要编写大量的自定义日志记录。

在这种情况下，使用 Agentic Framework 可能更合适。

“X-of-5” 规则：何时升级到 Agentic Framework？

如果满足决策清单中的至少两个条件，那么就应该考虑采用 Agentic Framework。这个规则旨在帮助你避免过度设计，并确保在需要时进行智能扩展。

决策清单

运行时动态分支：在看到中间结果之前，你不知道所有的步骤。
多个工具集成（3+）：API、文档加载器、数据库、自定义实用程序等。
内置的重试和错误策略：你希望定义重试次数、退避策略和回退节点。
并行或扇出执行：可以（而且应该）并发运行的独立任务。
持久状态和可观察性：自动日志记录、可追溯性和跨步骤的状态快照。

管道 vs. Agentic Framework：特性对比

下表对比了手动编写的管道和 Agentic Framework 的特性：

这个表格并非为了贬低手动编写的脚本，而是为了帮助你更好地理解 Agentic Framework 的优势。当你在任何一列中感受到摩擦时，请想象一下 Agentic Framework 可以提供的帮助。

Agentic Framework：核心概念与流行选择

Agentic Framework 的核心思想是将每个 LLM 或工具调用视为图中的一个节点。你需要声明：

节点：函数、LLM 调用、API 封装器。
边：节点之间的数据流或依赖关系。
策略：重试次数、超时、条件触发器。

引擎会自动处理以下事项：

节点之间的状态传递。
基于节点输出的动态分支。
独立分支的并行执行。
错误重试和回退策略。
每个节点执行的日志记录和跟踪。

流行的 Agentic Framework

LangGraph：Python 原生，细粒度控制，由热爱图的研究人员构建。
Crew AI：YAML/JSON 规范优先，低代码，非常适合多学科团队。
内部解决方案：如果你需要完全自定义，但要注意维护成本。

LangGraph 代码示例

以下代码展示了如何使用 LangGraph 实现文档处理管道：

from langgraph import Graph, Node

def ocr_api(doc):
    # OCR API 调用
    return "extracted text"

def llm_summarize(text):
    # LLM 摘要调用
    return "summary"

def translation_api(text, lang):
    # 翻译 API 调用
    return "translated text"

def profanity_filter(text):
    # 不良信息过滤
    return "filtered text"

def save_results(doc_id, summary, filtered):
    # 保存结果
    return "saved results"

def generate_dashboard_link(doc_id):
    # 生成仪表板链接
    return "dashboard link"

g = Graph()
ocr     = Node(ocr_api, name="OCR")
summarize = Node(llm_summarize, name="Summarize")
translate = Node(translation_api,
                name="Translate",
                parallel=True,
                split_on=["es","fr","de"])
retry_translate = Node(translation_api,
                      name="RetryTranslate",
                      condition=lambda out: out["error"]=="Transient",
                      retry_policy={"count":2, "backoff":"exponential"})
filter_node = Node(profanity_filter, name="ProfanityFilter", parallel=True)
save      = Node(save_results, name="Save")
dashboard = Node(generate_dashboard_link, name="Dashboard")

g.add_edges([
    (ocr, summarize),
    (summarize, translate),
    (translate, retry_translate),
    (retry_translate, filter_node),
    (filter_node, save),
    (save, dashboard)
])

g.run(input_document)

这段代码的优势在于：

并行翻译：只需设置 parallel=True 即可实现并行翻译。
集中式重试策略：无需内联 try/catch。
自动日志记录和跟踪：为每个节点提供自动化的日志记录和跟踪。
更清晰的声明式结构：突出显示业务逻辑，而不是底层管道。

明智选择，自信扩展

过度追求复杂性可能会导致过度设计、维护负担和团队挫败感。在基于 Agentic Framework 构建下一个项目之前，请问自己：

我真的需要动态分支和并行性吗？
我的重试和错误处理要求最好由自定义代码还是策略引擎来处理？
自动可观察性是否可以节省我更多的时间，而不是学习新框架所花费的时间？

如果对决策清单中的两个或多个项目回答是，那么恭喜你——放手去构建基于图的解决方案吧！如果不是，那就享受精心设计的 简易管道 的优雅之处。无论哪种方式，你都将为你的项目和团队的理智做出正确的选择。

结论：回归本质，选择最适合的工具

在面对大模型带来的无限可能时，我们需要保持清醒的头脑，避免被各种炫酷的技术所迷惑。Agentic Framework 固然强大，但并非所有场景都适用。我们需要根据实际需求，仔细权衡 简易管道 和 Agentic Framework 的优缺点，选择最适合的工具。只有这样，我们才能真正利用大模型技术，创造出更有价值的应用。记住，简单并不意味着落后，复杂也不一定代表先进。关键在于选择最能解决问题的方案，并避免不必要的复杂性。在 Agentic Framework 的诱惑下，别忘了回归本质，思考你的真正需求。

拒绝过度设计：何时使用简易管道，何时拥抱 Agentic Framework？