1. 从RPA到AI Agent一个工作流工程师的认知迭代最近在圈子里看到不少人在讨论“RPA要被AI干死了”这个话题尤其是一些标题党动不动就是“一键生成监听100个小红书博主的工作流”。作为一个从传统RPA机器人流程自动化项目摸爬滚打过来现在又深度参与AI Agent智能体落地的人看到这种说法我第一反应是太片面了。这根本不是谁“干死”谁的问题而是一场深刻的范式转移和生产力升级。今天我就结合“监听100个小红书博主”这个具体场景掰开揉碎了讲讲RPA和AI Agent到底有什么区别以及我们该如何用新的思路去构建真正智能、健壮的工作流。首先我们得明确“监听100个小红书博主”这个需求到底是什么。它绝不仅仅是定时刷新页面、抓取新内容那么简单。一个完整的“监听”工作流至少需要完成以下任务1. 目标博主列表的动态管理与更新博主改名、注销怎么办2. 新内容笔记、视频的实时或准实时发现与捕获3. 内容关键信息的结构化提取标题、正文、图片、发布时间、互动数据如点赞、收藏、评论4. 基于内容的关键信息分析与判断这条笔记是不是广告主题是否符合我们关注的领域情感倾向如何5. 最终结果的汇总、通知与存档。传统的RPA思路和融合了AI的新思路在实现这五个环节时逻辑和效果是天差地别的。2. 传统RPA方案的“笨重”与天花板如果用纯RPA工具比如影刀RPA、UiPath等来实现这个需求我们会怎么做这其实是一条非常经典且“硬编码”的路径充满了工程师的“匠气”与无奈。2.1 核心实现逻辑模拟与抓取整个工作流会高度依赖于对小红书Web端或App端UI元素的精准定位和操作模拟。登录与维持会话首先需要一个账号通过RPA工具录制或编写脚本模拟输入用户名密码、点击登录、处理可能的验证码这通常是第一个大坑可能需要接入打码平台。循环遍历博主主页将100个博主的个人主页URL存成一个列表。RPA机器人依次访问每个URL。页面滚动与内容探测进入博主主页后需要模拟鼠标滚动或触屏滑动让页面加载出新的内容。然后通过查找固定的HTML CSS选择器或XPath来定位“笔记”卡片元素。内容提取从定位到的卡片元素中再次通过子选择器去提取标题文本、正文可能需要点击“展开”、图片链接、发布时间、点赞数等。这些选择器必须非常精确一旦小红书前端页面改版选择器失效整个流程就会崩溃。去重与存储将提取到的内容与本地数据库或文件中记录的历史内容进行比对通常基于笔记ID或发布时间标题的哈希值判断是否为新增。如果是则存储到Excel或数据库里。通知可能通过邮件、钉钉/飞书Webhook等方式发送一条格式固定的通知。2.2 为什么说它“笨重”且易碎这套方案能跑通但维护成本和脆弱性极高主要体现在极度依赖页面结构前端工程师的一次常规迭代就可能让你的几十个精心编写的XPath全军覆没。你需要建立一个持续的监控和修复机制这本身又增加了工作量。无法处理非结构化信息RPA擅长提取“摆在明面上”的、位置固定的信息。但如果博主把联系方式藏在图片里或者笔记正文是纯图片无OCR情况下RPA就无能为力了。对于“判断笔记是否为广告”这种需要理解语义的任务传统RPA完全无法胜任。效率瓶颈模拟人工操作需要等待页面加载、元素渲染。监听100个博主串行执行耗时可能长达数小时失去了“实时”的意义。虽然可以引入多线程但账号风控、IP限制等问题会立刻凸显。逻辑僵化工作流是预先设定好的固定路径。如果小红书推出了新的内容形式如直播预告、合集或者博主将内容放在了“瞬间”里现有流程无法自动适应必须人工修改逻辑。注意这里会涉及一个灰色地带。直接大规模爬取公开平台数据尤其是绕过反爬机制、模拟登录的行为可能违反平台的服务条款甚至相关法律法规。任何自动化方案的设计都必须首先评估合规风险考虑使用官方API如果有的话或确保爬取行为在合理使用范围内。本文讨论的技术方案更多是用于说明技术逻辑的演进。3. AI Agent赋能的新范式从“操作工”到“分析员”现在我们引入AI大模型的能力看看整个工作流的构建思路会发生怎样的质变。这里的AI不是指某个单一功能而是一个能够理解任务、调用工具、进行决策的“智能体”Agent体系。3.1 架构重塑以LLM为调度核心新架构的核心是将大型语言模型LLM作为工作流的大脑和调度中心。它不再局限于按部就班地执行鼠标点击而是能够理解我们的自然语言指令并动态规划执行步骤。对于“监听并分析100个小红书博主”这个任务我们可以向AI Agent下达这样的指令 “请持续监控以下100位小红书博主的动态。每当有新的笔记发布你需要1. 获取笔记的完整内容文字和图片描述。2. 分析笔记的主题判断它是否属于‘美妆教程’、‘好物分享’、‘生活Vlog’还是‘商业广告’。3. 如果是‘好物分享’或疑似广告提取其中提到的产品品牌、名称和关键卖点。4. 评估笔记的互动数据点赞/收藏比初步判断其热度质量。5. 将满足我们关注条件例如是‘美妆教程’且点赞过千的笔记摘要和链接汇总发送到我的飞书群。”这个指令包含了目标、条件、动作和输出格式。一个设计良好的AI Agent会这样拆解和执行3.2 关键组件与执行流程规划与拆解模块PlannerLLM首先将你的复杂指令拆解成可执行的任务序列。例如[获取博主列表 - 定时触发 - 对每个博主获取最新内容 - 内容去重 - 内容理解与分析 - 结果过滤与汇总 - 发送通知]。工具调用模块Tool Calling这是与传统RPA最大的不同。Agent本身不“操作”界面而是调用各种专用工具。数据获取工具这可能是一个合规的、封装好的数据采集服务通过合法途径或者一个更健壮的爬虫模块处理反爬、解析结构。它的接口返回结构化的数据而不是HTML源码。这样前端改版只需要更新这个工具内部的解析逻辑不影响主工作流。内容理解工具这是AI的主场。将抓取到的笔记正文、图片通过多模态模型或图片描述接口扔给LLM让它执行分类、摘要、情感分析、实体品牌、产品提取等任务。例如LLM可以判断“这条笔记虽然提到了某产品但主要是分享使用心得并非硬广”。数据存储与查询工具Agent可以调用数据库客户端将处理后的结构化结果博主ID、笔记ID、内容摘要、分类标签、提取的实体、分析时间存入数据库并能在需要时进行查询和去重比对。记忆与状态管理Agent需要记住已经处理过哪些笔记去重记住100个博主的列表甚至记住每个博主的内容风格历史。这可以通过向量数据库存储内容语义用于相似度去重和传统数据库存储结构化记录结合来实现。自主决策与异常处理当工具调用失败如采集工具返回超时LLM可以根据预设策略决定重试、跳过还是上报人工。它比固定流程的RPA更灵活。3.3 技术栈选型参考构建这样一个AI Agent工作流不再是单一RPA工具能搞定的事而是一个微服务架构。你可以选择以下组件进行组合智能体框架Dify、Coze、LangChain、LlamaIndex。这些平台提供了可视化或代码化的方式来编排LLM、工具和记忆。Dify和Coze的低代码特性让非深度开发者也能快速搭建原型。工作流引擎n8n、Apache Airflow。它们擅长调度和编排复杂任务。你可以用n8n来管理定时触发和工具调用序列然后在其中集成一个LLM节点来做决策分析。核心大模型根据需求选择GPT-4、Claude、国产大模型如DeepSeek、通义千问的API。对于内容分析任务可能需要具备较强文本理解和指令跟随能力的模型。数据存储PostgreSQL存结构化数据、Chroma/Qdrant向量数据库用于语义去重和检索。采集模块可能需要自研一个稳定的、合规的数据获取服务或者寻找可靠的第三方数据提供商。4. 实战对比监听100个博主两种方案长什么样为了更直观我们用一个简化版的例子对比两种实现。场景发现博主“美妆达人A”发布了一条包含“口红”和“显白”关键词的新笔记时将其标题和链接发到钉钉。传统RPA方案伪代码逻辑1. 启动浏览器访问 xiaohongshu.com 2. 找到登录框输入账号密码点击登录 3. 等待页面跳转验证是否登录成功 4. 导航到 “美妆达人A” 的主页URL 5. 循环执行 a. 滚动页面到底部 b. 等待新内容加载 c. 使用预设的CSS选择器 [data-testidnote-item] 获取所有笔记元素列表 d. 对于列表中的每个元素 i. 使用子选择器提取 标题文本、发布时间、笔记ID ii. 检查 发布时间 是否晚于上次检查时间 iii. 检查 标题文本 是否包含“口红”和“显白” iv. 如果满足条件调用钉钉Webhook发送消息 e. 将最新的发布时间记录为“上次检查时间” 6. 等待10分钟后跳回步骤4脆弱点>
