去年我们团队扩招，HR 同事一个人对接了三个部门的招聘需求，高峰期一周要过两三百份简历。我当时坐她旁边，亲眼看着她每天早上打开邮箱，对着一堆 PDF 和 Word 文件一份一份翻，然后在 Excel 里手动记录学历、工作年限、技能关键词……说实话，那个场景让我有点坐不住。

不是说这件事有多难，而是它太适合被自动化掉了。重复、有规律、判断标准相对固定——这几乎是 AI 工作流最喜欢的任务类型。我当时就想，能不能搭一个东西，把简历批量丢进去，自动抓关键信息，按维度打分，输出一个初筛结论，让 HR 只需要看最后的结果？

想法有了，但怎么落地是另一回事。

我最开始的思路是自己写。用 Python 调 LLM 的 API，写个脚本解析 PDF，提取字段，再拼 prompt 让模型打分，最后输出 JSON。这条路我走了大概三天，跑通了一个最简单的 demo，但问题随之而来：每次 HR 提新需求，比如"这个岗位要加一个稳定性评估维度"，我就得改代码、重新测试、重新部署。她提需求的频率远超我改代码的速度，而且她根本看不懂代码，没办法自己调整任何东西。

这个矛盾让我开始认真考虑可视化编排的方案。

顺着 AI Agent 的热度，我先去试了 Dify 和 Coze。两个平台都做得不错，拖拽式的节点编排确实省了不少代码量，逻辑也比较直观。Coze 的生态比较丰富，插件多，上手快；Dify 的工作流设计更偏工程化，适合有一定技术背景的人。但我们团队有一个硬性要求：数据不能出内网。简历里涉及候选人的个人信息，走外部 SaaS 平台在合规上说不过去，私有化部署是必须的。这两个平台在这一点上对我们的场景支持得不够顺畅，所以没有继续深入。

后来我在一个开源社区的讨论帖里看到有人提到一个项目，讨论度挺高，说是支持私有化部署、有可视化工作流、底层基于向量检索做 RAG。我去 GitHub 看了一眼，star 数量不少，文档也比较完整，协议是 Apache 2.0，可以商用。这个项目叫 FastGPT。

---

我花了半天时间把它本地跑起来，然后开始搭简历筛选的工作流。

整体体验用"搭积木"来形容确实比较贴切。一个节点负责接收上传的文件，一个节点做文本提取，一个节点跑信息抓取的 prompt，一个节点做评分逻辑，最后汇总输出。每个节点的输入输出都可以在画布上连线，逻辑走向一目了然。我把评分维度拆成了几个独立节点——岗位适配度、教育背景、工作经历、技能证书、稳定性——每个节点单独调 prompt，这样哪个维度需要调整，直接改那个节点就行，不影响其他部分。

这种结构对我来说最大的好处是：HR 同事可以看懂流程图。她不需要理解代码，但她能看着画布说"这里的稳定性判断逻辑我觉得应该改一下"，然后我们一起对着节点讨论，沟通成本降低了很多。

当然也有不顺的地方。节点一多，画布上的连线就开始乱，尤其是有条件分支的时候，线会交叉，看起来像一团蜘蛛网。我后来养成了一个习惯，每隔几个节点就手动整理一下布局，不然自己过几天回来看都认不出来。另外，如果逻辑里有循环或者多轮迭代的需求，学习门槛会陡一些，需要花时间理解它的循环节点机制，这块文档写得还不够细，踩了一些坑。

说回实际效果。工作流跑起来之后，HR 同事的初筛时间从每份简历大概五到十分钟，压缩到只需要看一眼输出的评分表格和结论摘要。批量上传、自动处理、结构化输出，整个流程跑下来基本不需要人工干预。她现在的工作重心转移到了复筛和面试安排上，这才是真正需要人判断的部分。

对我来说，迭代速度也快了很多。之前改一个评分维度要改代码、跑测试、重新部署，现在直接在画布上改节点的 prompt，保存，立刻生效。私有化部署让数据全程在内网流转，合规这块没有任何顾虑。

这件事做完之后，我有一个感受想记下来。可视化工作流并不是要取代手写代码，它解决的是另一类问题：业务逻辑变化频繁、需要非技术人员参与协作、快速验证想法比性能优化更重要的场景。如果你的需求是高并发、极致性能、复杂的状态管理，手写代码仍然是更合适的选择。

我觉得未来 Agent 的方向会越来越细分，不是一个通用大 Agent 解决所有问题，而是大量轻量级的、领域专用的 Agent 模板，针对具体业务场景做深度适配。简历筛选、发票录入、文档对比、客服应答……这些场景的逻辑其实都不复杂，但重复性高、标准化程度高，非常适合用工作流模板来覆盖。

任何工具都有它的边界，选型的时候想清楚自己的核心约束是什么，比跟风试所有新工具要有效得多。

最后想问问大家：你们在搭 RAG 或者 Agent 的时候，遇到过哪些比较头疼的问题？比如召回率上不去、多轮对话上下文丢失、模型幻觉控制不住……这些我都踩过，如果有类似经历的欢迎评论区聊聊，说不定能互相提供一些思路。