对于很多企业自动化项目来说，AI Agent已经可以完成理解、推理与任务规划，但真正进入执行环节时，仍然经常卡在缺少接口、无法操作传统软件的问题上。尤其在没有开放API的财务系统、办公文档、内部管理系统面前，模型再强，也很难直接点按钮、填表单、导出报表。
围绕这一痛点，科大讯飞开源了AstronRPA。该项目在GitHub上已获得5.5k Stars，采用Apache-2.0协议。它并不是一个只面向脚本操作的传统RPA工具，而是试图把企业级桌面自动化与AI Agent能力打通，让Agent能够调用RPA流程，也让RPA流程中嵌入Agent任务，从而形成“推理—决策—执行”的完整链路。
不只是自动点击，而是让Agent拥有操作桌面系统的能力
RPA长期以来的核心价值，是模拟人工操作鼠标和键盘，去使用那些没有标准API的企业系统。无论是金蝶、用友，还是内部管理平台、网页端业务系统，只要界面可操作，RPA就有机会接管重复流程。
AstronRPA在此基础上进一步强调“Agent-ready”能力。按照项目介绍，它不只是把桌面动作自动化，还会把RPA工作流作为可被Agent调用的能力暴露出来。Agent可以像调用一个函数那样，触发RPA完成具体任务，比如操作财务系统、处理Excel数据、执行浏览器自动化、识别图像并点击界面元素，或者发送邮件、生成PDF报告。
这种设计的意义，在于补齐AI Agent在真实企业环境里的执行短板。很多Agent框架擅长调用工具、生成计划，但一旦目标系统只提供图形界面，没有程序接口，自动化就会停在“知道怎么做”但“无法动手做”的阶段。AstronRPA试图成为AI Agent与企业旧系统之间的一层桥梁，给模型补上一双可以操作桌面的“手”。
双向集成与MCP触发，覆盖更多企业自动化场景
从素材看，AstronRPA的一个关键特点是支持Agent与RPA之间的双向调用。
- Astron Agent可以调用AstronRPA：Agent负责分析任务和做决策，RPA负责执行桌面操作。例如，Agent判断需要提取财务数据后，由RPA进入金蝶系统完成数据导出。
- AstronRPA也可以调用Astron Agent：在RPA流程中嵌入Agent子任务，由RPA完成触发和数据传递，由Agent负责理解非结构化内容。例如，RPA从网页抓取文本，Agent分析提取关键信息，再由RPA写回表格。
这种混合模式更适合企业真实流程。很多任务并非每一步都需要大模型参与，也并非每一步都能用固定规则写死。大量场景是：打开邮件、下载附件、转发通知、写入系统这些步骤规则明确，适合RPA稳定执行；而理解附件内容、判断任务归属、提取非结构化信息，则更适合交给Agent处理。素材中给出的例子是每日邮件报表处理：前几步由RPA完成，中间由Agent理解附件内容并决定路由，后续再由RPA继续执行。
此外，AstronRPA还支持通过MCP，即Model Context Protocol，触发工作流。这意味着支持MCP的客户端或Agent，可以在发现AstronRPA工具后，直接调用已经配置好的桌面自动化流程。素材举的例子是，用户对Claude Code提出“帮我从金蝶系统导出上月销售数据”，Claude Code识别到AstronRPA的MCP工具后调用相应工作流，最终由AstronRPA完成桌面操作并返回结果。
如果这一链路在实际部署中稳定运行，它的价值不只是减少写代码调用接口的步骤，而是让自然语言与桌面操作之间形成更直接的连接。企业用户不需要先理解复杂系统接口，也可以通过自然语言触发一整套自动化流程。
从组件、设计器到部署架构，面向企业级使用场景
AstronRPA将自动化能力封装在astronverse.*命名空间下的组件包中。素材提到，该体系提供300+原子能力，用户可以将组件直接拖入工作流中使用。对于业务人员而言，这种方式降低了流程搭建门槛；对于开发者而言，组件化能力也便于复用和扩展。
项目还提供可视化低代码设计器，支持拖拽式编辑工作流。素材显示，Windows客户端包含可视化工作流设计器、元素拾取器astronverse.picker，以及本地工作流调试运行时。客户端技术栈为Vue 3、TypeScript和Electron，系统要求为Windows 10或Windows 11，内存不低于8 GiB。
服务端则采用Docker Compose部署，整体为前后端分离架构。素材介绍，服务端包括两部分：Java Spring Boot负责业务逻辑层，涵盖用户认证、工作流管理与存储、调度引擎、团队协作与权限；Python FastAPI负责RPA与AI引擎层，执行astronverse.*组件包，集成AI服务，并提供MCP服务端点。
这种分层设计将权限、调度、流程管理与执行引擎拆开，更符合企业级系统对协作和管控的需求。相比个人脚本或单机自动化工具，AstronRPA显然更强调团队使用、权限管理和流程资产沉淀。
部署方面，服务端可通过克隆GitHub仓库、配置环境变量后使用docker compose启动。客户端则可从GitHub Releases下载安装包，或在本地构建。本地构建依赖包括Node.js不低于22、Python 3.13.x、JDK 8+、pnpm不低于9、UV 0.8+、7-Zip和SWIG。
企业自动化的下一步，可能不是纯Agent，而是混合执行
从行业角度看，AstronRPA代表了一种更务实的企业自动化路线：不是把所有操作都交给Agent临场判断，也不是把所有流程都写死为传统RPA规则，而是让确定性的桌面操作由RPA承担，把需要理解、判断和提取的环节交给AI。
这类混合架构对国内企业环境尤其重要。大量存量系统仍然缺少现代API，财务、人事、供应链、审批等关键业务又高度依赖图形界面操作。如果AI Agent只能停留在对话和推理层面，很难真正进入业务闭环；但如果只依赖传统RPA，又难以处理非结构化文档、图像、邮件正文等需要理解能力的任务。
AstronRPA的开源，也给了开发者和企业更多自主选择空间。素材称，当前同时具备开源、AI与Agent深度集成、MCP支持的商业RPA工具并不多。对于希望私有化部署、二次开发，或者把RPA能力接入自有Agent系统的团队来说，这类项目提供了一个可验证的底座。
不过，从评测角度看，项目能否真正覆盖浏览器、桌面应用、文档与图像识别等复杂场景，还要看实际环境中的元素识别稳定性、流程容错能力、异常处理机制，以及与不同Agent框架和MCP客户端的适配程度。至少从公开素材来看，AstronRPA已经给出了一个清晰方向：让AI不止停留在“想清楚”，还要能够在真实桌面系统里“做得到”。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ke-da-xun-fei-kai-yuan-astronrpa-gei-ai-agent-bu-shang-zhuo
