大模型发展会让工作流智能体使用率降低吗？

今年早期我们在内网生产环境部署蒸馏模型之后，也接触并测试了基于流程编排的工作流智能体平台。

但随着 Dify、n8n 的发展和迭代，我们发现工作流设计平台中的诸多功能，正逐渐被新一代大模型的能力提升所取代。

工作流式的智能体，以其拖拽式的节点编排逻辑，曾在 AI 落地初期风靡一时。

像 Dify 这类平台，通过将复杂流程拆解为一个个可配置的节点，让技术人员能快速搭建起 AI 应用。

调用模型接口、串联工具 API，类似于用积木搭建城堡。

在测绘院的日常研发中，它也曾助力过一些简单的地理数据解析、基础测绘报告生成等场景。

但如今，随着大模型能力的狂飙式发展，这套逻辑正在被颠覆。

首先，大模型的“全流程理解与执行”能力，让工作流的节点拆分变得多余。

过去，AI 能力不足，我们必须把一个任务拆解成“数据导入 - 格式转换 - 模型推理 - 报告生成”等多个节点，用工作流平台一步步串联。

但现在，大模型能直接理解“生成某区域的地形测绘分析报告”这样的自然语言指令，自主规划步骤、调用工具（如 SQLbot调取PG地理信息数据库、启动视图设计和统计计算），全程无需人工拆分节点。

就像现在用大模型开发的智能助手，只需输入需求，它就能自主完成从数据获取到报告输出的全流程，可以用 Prompt 要求输出中间的“节点”，对用户完全透明，工作流的编排价值自然被削弱。

或者是在火山方舟里我们创建了知识库，在模型市场里选取合适的大模型配合联网检索和知识库检索，设定超级复杂的长工作链的系统提示词，发布成应用时，都可以审计模型内部如何设计联网检索的关键词、从知识库里拿到了哪些切片、后续的分析是如何开展的。

其次，大模型的复杂任务处理能力，让工作流平台的“封装短板”暴露无遗。

在我们实际的研发场景中，常有复杂的地理数据建模、高精度地图渲染等需求，这些任务涉及大量自定义算法和复杂代码。

工作流平台的拖拽逻辑无法直接承载这类复杂代码，必须先将代码封装成 API 再接入平台。

整个封装过程耗时耗力，后续维护更是噩梦，要同步管理平台版本、代码版本以及二者的匹配关系。

而大模型越来越支持的代码级交互与自动化，就像豆包可以用数据分析模式自动根据上传的表单写脚本运行拿到计算结果和图表那样，这一切都变得越来越简单。

所以大模型能协助完成代码编写、调试甚至部署，无需再依赖工作流平台的节点编排。

再者，大模型驱动的智能体模式，重构了 AI 应用的落地逻辑。

工作流智能体是“具象化”的，每个节点的功能、流程的 SOP 都要提前定义得清清楚楚。

但在测绘服务自然资源的场景中，需求常常是动态变化的。

比如突然要新增一种小众地理数据的解析规则，工作流平台的节点修改会变得极其繁琐，几十个节点中逐个排查调整，效率低下。

而大模型智能体是“抽象化”的，它基于 prompt 理解需求，能自主调整策略。

就像要面向某个垂直业务新开发的智能决策助手，面对不同类型的任务，它能用大模型+指令映射的方式，自主调用不同工具实现 function calling，调整分析逻辑，无需人工去修改一个个固化的工作流节点。

这种灵活性，是工作流智能体难以企及的。

对于研发团队来说，经常反思，用复杂的工作流完成一个代码能完成的工作，甚至输出还没有代码运行的结果稳定，是不是有点脱裤子放屁。

所以我们不再需要花费大量精力在工作流平台的节点编排与维护上，而是要将重心转向大模型的 prompt 工程、领域知识注入与智能体策略设计。

比如，如何让大模型更精准地理解测绘地理信息领域的专业术语（如“搜索xx市最大的商业综合体附近500米的停车位”“地理坐标系转换规则”），如何设计智能体的工具调用逻辑以适配测绘院的内部数据库与分析算子库。

当然，这并非完全否定工作流智能体的价值。

在一些极简、标准化的场景中，它仍可作为原型工具快速验证想法。

但从长远看，大模型带来的全流程理解、复杂任务处理与智能体模式，必然重塑 AI 落地的底层逻辑。

我们未来不会首选工作流智能体，这是大模型时代 AI 能力跃迁的必然结果。

还是更倾向于如何驱动模型自主感知和思考，并能输出可信度高的结果，作为主攻方向。