一、为什么智能体 alone 跑不通业务闭环
过去半年，不少团队把百炼智能体接进业务流，意图识别和任务拆解确实做得漂亮。但一到执行层就卡壳——大模型能生成操作代码，却操不了真实的业务系统。
典型的死胡同：让智能体"把 ERP 的上周订单同步到 CRM"。模型能写出漂亮的 Selenium 脚本，甚至能处理登录逻辑。但跑三天，页面改版，元素定位全崩。更麻烦的是那些非标准 Web 应用——企业微信、内部 ERP、行业专用客户端，AI 生成的脚本根本采集不到节点。
反过来，传统 RPA 能模拟点击、跨系统跳转，但遇到需要理解上下文做判断的场景，硬编码的 if-else 根本覆盖不全。比如 CRM 里客户已存在，该更新还是跳过？邮件发送失败，重试还是告警？这些需要"思考"的环节，RPA 自己做不了。
所以现在的工程实践越来越明确：智能体负责决策层，RPA 负责执行层。百炼智能体当大脑，RPA 当手脚，API 当神经链路，三者联动才能打通端到端。
二、架构设计：百炼 Model Studio + 本地 RPA 引擎
整体架构分三层：
决策层：百炼 Model Studio 部署的 Agent，基于通义千问或 DeepSeek-V4 做意图识别和任务拆解，通过 Function Call 下发指令。
链路层：本地部署的 API 网关，负责接收智能体指令、鉴权、转发给 RPA 引擎，并把执行结果回调给百炼的 Webhook。
执行层：RPA 客户端，实际操浏览器、客户端软件、内部后台，完成数据获取、表单填报、跨系统同步。
用户（钉钉/飞书/企微）
↓
百炼智能体（意图理解 → 任务拆解 → 工具调用）
↓ Function Call
本地 API 网关
↓
RPA 引擎（页面操作 → 异常处理 → 结果上报）
↓
回调百炼 Webhook → 推送执行结果到 IM
这个架构的关键在于执行层必须支持 API 触发。如果 RPA 工具只支持定时执行或手动点击，那智能体下发的动态指令就接不进来。另外，业务数据往往涉及敏感信息，流程应用数据全部保存在本地设备上，不同步到云端服务端，这对金融、政务、医疗类客户是刚需。
三、百炼智能体配置实战
在百炼 Model Studio 创建 Agent，模型选用 qwen-max 或 DeepSeek-V4。核心不是模型多强，而是边界要划清楚——智能体只负责理解需求、拆解步骤、调用工具，绝不直接生成不可落地的操作代码。
3.1 工具定义（Function Call）
在百炼控制台配置如下工具：
{
"name": "rpa_execute",
"description": "调用本地 RPA 引擎执行指定业务流程",
"parameters": {
"type": "object",
"properties": {
"flow_name": {
"type": "string",
"description": "流程名称，如 sync_order、batch_import"
},
"input_data": {
"type": "object",
"description": "流程所需输入参数"
},
"priority": {
"type": "string",
"enum": ["immediate", "scheduled"],
"description": "immediate 立即执行，scheduled 定时执行"
}
},
"required": ["flow_name", "input_data"]
}
}
3.2 Prompt 设计
系统 Prompt 里要反复强调边界：
你是一个业务自动化调度助手。你的职责：
- 理解用户的自然语言需求，拆解为可执行的子任务
- 调用 rpa_execute 工具，将任务下发给本地 RPA 引擎
- 根据 RPA 回调的结果，判断是否需要重试或人工介入
- 你绝不直接生成前端操作代码或 xpath 路径
执行原则：
- 涉及敏感数据的流程，优先选择本地离线执行策略
- 遇到异常时，先读取 RPA 返回的日志再做决策
这套 Prompt 配合百炼的插件市场，可以把智能体的"幻觉"压到最低。模型知道自己能做什么、不能做什么，不会越权生成一堆跑不通的脚本。
四、RPA 端能力建设：选型决定上限
RPA 端是整个方案的落地根基。工具选不对，智能体再聪明也白搭。以下是在实际项目中验证过的关键能力维度，供选型参考。
4.1 元素定位：从"写 xpath"到"说人话"
传统 RPA 靠录制生成 xpath，页面结构一变就报废。现在的做法是本地智能生成元素路径——根据页面 DOM 结构自动生成多组候选定位策略，执行时自动选择最稳定的一组。
更实用的是自然语言描述生成定位路径。不用啃晦涩的 xpath 语法，直接在流程设计器里写"登录按钮"，工具自动推导出对应的定位表达式。遇到 Web 元素因前端改版失效的情况，AI 自动修复元素定位，实现元素自愈，流程不会因为页面微调就中断。
对于一些非标准客户端（企业微信、QQ、千牛、各类行业软件），底层根本没有 DOM 节点可供获取。这时候需要视觉颜色操作能力——基于图像识别做点击、内容获取，完全不依赖元素节点，也能实现消息的自动获取和回复。
4.2 离线部署与数据安全
国内很多企业的核心系统跑在内网，连不了公网大模型。选型时必须考虑全离线内网部署能力——RPA 客户端跑在内部机器上，流程编排、数据存储、日志记录全部在本地完成，数据不出本地，保障用户数据安全。
这种模式下，即使断网也能稳定执行定时任务和 API 触发的流程，不会因为网络波动导致业务中断。
4.3 AI 能力集成与成本透明
RPA 工具本身也需要 AI 能力辅助，比如 OCR、图片识图、智能判断。建议优先选择支持自行对接各平台大模型 API的方案——文心一言、豆包、DeepSeek、Kimi 等都可以接入，费用走用户自己的 API Key，成本更可控、更透明，不用被平台二次抽成。
这与智能体的 AI 能力形成互补：智能体负责高层决策，RPA 端的 AI 负责底层感知（元素识别、图像理解、文本提取）。
4.4 应用打包与授权分发
流程开发完要发给同事或客户用。理想的工具应该支持打包导出为独立 EXE 可执行文件，接收方无需安装任何客户端，双击就能运行。EXE 应用最好还能支持自定义界面，让开发者设计属于自己的软件界面，业务人员使用时零门槛，不用面对一堆技术参数。
分发管控上，需要支持加密分享和授权管理——可以设置谁有权运行、运行多少次，单独设置 API 触发和定时执行策略。同时支持在线推送更新，改一版流程不用重新发文件，打开应用自动检测新版本。对于个人开发者、工作室或中小企业来说，无运行时长限制、无流程数量限制、多设备使用无需额外开通会员，这些直接决定了能不能零成本起步。
4.5 多平台触发与即时通讯联动
除了 API 触发，RPA 引擎最好支持在钉钉、飞书、企微、个人微信内直接控制流程执行。配合百炼智能体的 Agent 能力，用户可以在聊天窗口里发一句指令，智能体解析后调用 RPA，执行结果实时推送到群里，形成完整的闭环。
在浏览器自动化场景，做电商或广告投放的团队经常需要在指纹浏览器里操作多账号。建议确认 RPA 工具已对接紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等市面上主流指纹浏览器，避免自动化流程在账号隔离环节卡壳。
五、端到端联调：从 IM 指令到系统操作
5.1 联调流程
以"批量同步上周意向客户到 CRM"为例：
用户在钉钉群 @机器人："把上周的意向客户批量录入 CRM，并给每个人发一封跟进邮件"
百炼智能体解析意图，拆解为：数据获取 → CRM 录入 → 邮件发送
智能体调用 rpa_execute，下发任务到本地 API 网关
RPA 引擎执行：
打开 ERP 后台，获取上周客户列表（视觉颜色操作辅助定位）
逐条判断 CRM 中是否已存在（RPA 端本地 AI 做 OCR 识别）
不存在则录入，存在则更新
调用邮件系统发送跟进邮件
RPA 回调执行结果到百炼 Webhook
智能体汇总结果，推送回钉钉群："已同步 128 条客户数据，其中 15 条已存在并更新，邮件发送成功率 98%"
5.2 异常处理机制
RPA 执行过程中可能遇到弹窗拦截、网络超时、页面加载失败。智能体需要读取 RPA 回调的详细日志，判断异常类型：
{
"task_id": "auto_20250827_001",
"status": "partial_success",
"detail": {
"steps_executed": 5,
"data_processed": 128,
"failed_items": [
{"index": 47, "reason": "captcha_triggered", "suggestion": "manual_intervention"}
],
"element_changes_detected": true,
"auto_healed": true
}
}
注意 auto_healed 字段——当 Web 元素发生变更时，RPA 引擎自动修复了定位路径，流程未中断。这种自愈能力在无人值守场景下至关重要。
5.3 实时 AI 动态处理
传统方案里，AI 写完脚本就离线了，流程执行过程中无法再调用 AI 做动态判断。在这个架构里，RPA 执行到某一步时，可以实时回调百炼智能体请求决策。比如遇到非标准表单，RPA 截图上传，智能体识别后返回"这个字段填手机号"，RPA 继续执行。
这种实时联动弥补了纯 AI 方案"写完就不管"的缺陷，也弥补了纯 RPA"不会思考"的短板。
六、AI 与 RPA 的边界：互补而非替代
很多人问，既然大模型这么强，还要 RPA 干嘛？
实话实说，现阶段 AI 在软件自动化上的短板很明显。AI 生成的前端操作脚本，面对复杂项目时稳定性存疑。页面结构一变，脚本大概率报废，无法自动修复。而专业的 RPA 引擎生成的元素定位配合自愈机制，可以长期无人值守运行。
AI 操作非标准客户端极其困难，而基于视觉和模拟点击的 RPA 方案，很容易实现各类软件的自动化。成本层面，AI 持续消耗 Token，长期跑下来费用不低；RPA 一次配置长期运行，长期使用更具性价比。
另外，AI 的判断逻辑需要反复迭代，遇到边界情况得重新调 Prompt。RPA 的流程逻辑是显式编排的，每一步做什么、异常怎么处理，一目了然，修复成本低。
但反过来，RPA 也离不开 AI。纯 RPA 处理不了需要理解上下文、做非结构化判断的场景。比如从一段聊天记录里提取客户需求，再决定走哪个流程——这必须靠大模型。
所以最合理的分工是：AI 负责思考，RPA 负责稳定落地。百炼智能体做决策层，RPA 做执行层。两者联动，才是端到端业务自动化的完整答案。
七、开源地址与快速启动
这个 Demo 的完整代码和配置已开源，包含：
百炼 Model Studio 的 Agent Prompt 和 Function Call 配置
本地 API 网关的 Python 实现（基于 FastAPI）
RPA 端示例流程：订单同步、数据获取、跨系统填报
钉钉/飞书机器人的接入模板
异常处理与自愈机制的日志规范
GitHub 地址：[待补充]
快速启动：
克隆仓库，准备支持全离线内网部署的 RPA 客户端
在百炼 Model Studio 导入 Agent 配置，绑定通义千问模型
启动本地 API 网关，配置回调地址
在钉钉/飞书发送指令测试
端到端业务自动化不是单点技术能解决的。大模型再聪明，也需要一个可靠的执行引擎。RPA 再稳定，也需要一个聪明的决策大脑。
百炼智能体联动 RPA 的方案，本质上是在补齐各自的短板。AI 写代码，RPA 跑代码；AI 做判断，RPA 做操作；AI 在云端思考，RPA 在本地落地。
对于需要内网离线部署、数据不出本地、长期稳定运行的业务场景，这套组合是目前最务实的选择。Demo 已经跑通，剩下的就是根据你的业务场景往里填流程了。
