搭建智能体，常见有两条路：用 LangGraph、CrewAI 这类代码框架编写，或者在可视化工作流平台上用节点搭建。两者都能做出可用的智能体，差别在于谁来维护、出错时怎么排查、复杂度上去之后怎么管。本文先按复杂度把智能体分成四层，再对比两条路各自的长处和代价，最后说明什么时候适合混合使用。
- 多数业务需求用固定步骤的工作流就能解决，只有步骤确实无法事先确定时，才需要让模型自行决定下一步。
- 代码框架最灵活，跟进新模型和新特性最快，版本管理与自动化测试也更成熟，适合有工程团队维护的场景。
- 可视化工作流在数据处理、逐步查看中间结果和业务人员参与方面更有优势，适合数据团队主导的场景。
- 两条路不互斥：常见做法是用工作流实现数据处理类工具，由代码或平台里的智能体节点负责调用。
- 无论选哪条路，复杂度上去之后都要管住同样几件事：工具说明、过程可观察、回归测试、成本与失败处理。
智能体的四个复杂度层次
选工具之前，先弄清需求落在哪一层。Anthropic 在 构建有效智能体的实践总结 中区分了两类系统：步骤由代码预先定义的工作流，以及由模型动态决定流程的智能体，并建议从最简单的方案开始，只在确有需要时增加复杂度。按这个思路，可以把常见需求分成四层。
| 层次 | 特征 | 示例 | 建议 |
|---|---|---|---|
| 单次模型调用 | 输入一段内容，模型返回一次结果 | 给一条客服工单打分类标签 | 不需要任何智能体框架 |
| 固定链路 | 多个步骤按预定顺序执行，其中一些步骤调用模型 | 读取工单、分类、按类别统计、生成周报 | 用工作流即可，结果可预测、易排查 |
| 单个智能体调用工具 | 模型根据任务自行决定调用哪些工具、调用几次 | 根据主管的提问，决定查哪张表、按什么维度汇总 | 工具数量控制在少数几个，逐个测试 |
| 多个智能体协作 | 多个分工不同的智能体相互传递任务与结果 | 一个负责检索资料，一个负责分析，一个负责审核 | 调试和成本都明显上升，确认前一层不够用再做 |
很多被称为「智能体项目」的需求，实际落在第二层。先把第二层用工作流做扎实，往往比直接上多智能体更快见效。
搭建智能体：两条路各自的长处
下表只对比两条路的主要特点，具体能力以各框架和平台的最新版本为准。
| 对比项 | 代码框架（如 LangGraph、CrewAI） | 可视化工作流平台 |
|---|---|---|
| 灵活性 | 最高，任何逻辑都能用代码表达 | 受平台提供的节点限制，特殊逻辑需嵌入脚本节点 |
| 跟进新模型与新特性 | 通常最快，开源社区更新频繁 | 取决于平台的版本发布节奏 |
| 上手门槛 | 需要编程能力与对框架概念的理解 | 拖拽节点即可起步，数据与业务人员也能参与 |
| 排查问题 | 靠日志、调试器与追踪工具 | 可以打开出错节点，直接查看输入输出 |
| 版本管理与测试 | Git、代码评审、单元测试等工程实践成熟 | 工作流以文件保存，版本差异比较不如代码直观 |
| 数据处理 | 清洗、关联、统计需自行编写或引入库 | 数据处理与统计节点现成，适合以数据为核心的工具 |
| 适合的团队 | 有专职工程师长期维护 | 数据团队主导，业务人员需要看懂和调整流程 |
这两列没有绝对的优劣。工程团队为主、需求变化快、要集成进现有软件系统的，代码框架更顺手；数据团队为主、工具本身就是数据处理流程、结果需要业务人员复核的，可视化工作流更合适。可视化工作流在数据分析场景里的一般优势，见 为什么选择可视化工作流。
什么时候选哪条路
混合使用时，工具与智能体之间需要一种调用方式。模型上下文协议（MCP）等开放协议正被越来越多的框架和平台支持，用于让不同环境中实现的工具被智能体统一调用；具体能否互通，要按所用框架和平台的版本逐项确认。
搭建智能体：复杂度上去之后要管住什么
不论用代码还是工作流，智能体从一两个工具扩展到十几个工具时，都会遇到同样几类问题：
- 工具说明要写清楚：模型靠工具的名称和说明来决定调用哪个。说明含糊或两个工具用途相近，是选错工具最常见的原因。
- 每一步都要能观察：保存模型每次调用了哪个工具、传入什么参数、返回了什么，否则出错时无从判断问题出在模型还是工具。
- 用测试集做回归：准备一组有标准答案的真实任务，每次换模型、改提示词或加工具后都重跑一遍，避免改好一处、弄坏另一处。
- 控制成本与延迟：智能体每多一轮思考就多一次模型调用。给单次任务的调用次数设上限，并记录每类任务的平均耗时和用量。
- 设计失败时怎么办：工具报错时重试几次、何时放弃、放弃后是给出部分结果还是转交人工，都要事先定好。
在 KNIME 与 iModel 中的做法
KNIME 从 5.5 版 开始提供智能体相关节点，做法是把普通工作流转换成工具，再由 Agent Prompter 或 Agent Chat View 节点调用。它的特点是工具本身就是可以单独运行、逐节点查看结果的工作流，适合上表中「选可视化工作流」和「混合使用」两种情况。
iModel 基于 KNIME 开源内核二次开发。基于 KNIME 5.12 内核的 iModel 版本中，这些智能体节点可以运行，所用模型服务需要按部署环境配置。需要非常规控制逻辑时，仍要借助 Python 脚本节点，或把编排部分交给代码实现。
关键事实
| 关键事实 | 内容 |
|---|---|
| 工作流与智能体 | 工作流的步骤预先定义；智能体由模型在运行时决定调用哪些工具 |
| 四个复杂度层次 | 单次模型调用、固定链路、单个智能体调用工具、多个智能体协作 |
| 代码框架的长处 | 灵活、跟进新特性快、工程测试实践成熟 |
| 可视化工作流的长处 | 数据处理节点现成、可逐步查看中间结果、业务人员可参与 |
| 通用管控要点 | 工具说明、过程可观察、回归测试、成本与延迟上限、失败处理 |
| KNIME 智能体节点 | 5.5 版起提供，工作流可转换为智能体的工具 |
| iModel | 基于 KNIME 开源内核二次开发；基于 KNIME 5.12 内核的版本中，智能体节点可以运行 |
| 核实日期 | 2026 年 9 月 17 日 |
常见问题
搭建智能体，一定要用专门的智能体框架吗？
不一定。如果需求的步骤可以事先确定，用固定步骤的工作流或普通代码就能完成，结果更可预测，也更容易排查。只有步骤确实需要模型根据情况动态决定时，智能体框架或平台里的智能体节点才有必要。
可视化工作流能做复杂的智能体吗？
能做，但要看复杂在哪里。工具以数据处理为主、结果需要逐步复核的复杂度，可视化工作流处理得很好；需要大量自定义控制流程、深度嵌入软件产品，或者依赖最新模型特性时，代码框架更灵活。两者也可以混合使用。
代码框架和可视化工作流，哪个更容易维护？
取决于维护的人。由工程师维护时，代码配合版本管理和自动化测试更容易长期维护；由数据或业务团队维护时，可视化工作流更容易看懂和调整。选型时先确定三年后谁在维护这个系统。
从一个简单智能体扩展到多智能体，要注意什么？
先确认单个智能体已经无法满足需求，再拆分。每增加一个智能体，调试路径、模型调用成本和出错点都会增加。拆分后要为每个智能体准备单独的测试任务，并记录它们之间传递了什么内容。
已有的数据分析工作流，能直接给智能体用吗？
在 KNIME 5.5 及以后的版本中可以转换为智能体的工具，通常需要补上参数输入与结果输出，并写清工具用途说明。建议优先挑选输入输出明确、单独运行结果稳定的工作流。
