会想不会做，才是 Agent 的真问题

过去一年里，AI 智能体最常被夸的是「会规划」，最常被吐槽的是「只会规划」。它能列出五步方案、能写出一段代码，可真要它去点开某个客户端、填一张表单、把一批文件按规则挪走，往往还是得人来接手。Astron RPA 想补的正是这一段：一套由讯飞开源、以 Apache-2.0 许可发布的企业级 RPA 桌面应用，把桌面操作、浏览器操作、文件与数据处理做成可被流程调用、也可被智能体调用的执行层。

可视化编排，不写代码也能搭流程

它的开发方式接近所见即所得：在桌面客户端里拖拽组件搭出流程，用元素拾取器去点界面上的按钮和输入框，跑一遍就能看到每一步的执行状态，出了问题可以单步调试或整段录屏回放。官方把这种形态称作低代码甚至无代码——业务人员能参与搭建，开发者则可以用自定义组件把特殊逻辑补进去。流程搭完之后不是一次性脚本，它可以被存进组件库、被别的流程复用，也可以挂上定时任务或外部触发。

三百多个原子能力撑起覆盖面

支撑这套编排的是三百多个预置原子能力，按领域切成组件包：系统操作、浏览器自动化、图形界面操作、Excel 表格处理、图像识别、网络请求、邮件收发、Word 与 PDF 文档处理、加解密，以及对接大模型能力的 AI 组件。覆盖面是它比较实在的地方——办公软件里的 WPS 与 Office、财务与 ERP 类的金蝶、用友，加上 IE、Edge、Chrome 这些浏览器，都在官方点名的支持范围内，跨应用的端到端流程因此能串得起来。图像识别这一层则负责那些拿不到控件句柄的老系统界面。

前端、引擎、服务端三段式

架构上它并不假装自己是一个单机小工具。桌面客户端用 Electron 配 Vue 3 与 TypeScript 写成，负责流程编排、运行调试、机器人管理与调度界面；引擎侧是 Python，承担原子能力的真正执行、元素定位、拾取与录屏回放；服务端则是 Java 的 Spring Boot 加 Python 的 FastAPI 组成的微服务，管用户、机器人、卓越中心、AI 服务与包管理，数据落在 MySQL、Redis 与对象存储上，整套用 Docker 部署。客户端与服务端之间走 HTTP 与 WebSocket，本地网关把两边的调用接起来。

这种分层带来的直接结果是能力边界清晰：只在本机跑的流程可以只装客户端，需要多人共用机器人、共享组件、看执行记录时再上服务端。对个人用户来说门槛不算高，对企业来说这条路又能延伸到内网自建。

企业侧的那一半

RPA 落地最容易卡住的往往不是技术，而是资产怎么管、权限怎么分。Astron RPA 在这块堆了不少东西：卓越中心用来沉淀可复用的组件与流程，应用市场负责分发，机器人团队可以共享与协作执行，终端监控能看到每台机器上跑着什么，调度模式支持定时、API 调用与 MCP 服务等多种触发方式。对需要审计的场景，执行日志与流程权限是分开管的。

它跟讯飞自家的 Astron Agent 平台是配套关系：Agent 里可以直接调用 RPA 的流程节点，RPA 的流程里也能嵌入 Agent 的推理节点。用一句常见的说法，一个负责想，一个负责做，中间靠节点调用打通。这也是它把自己称作 Agent-ready 的原因——不是再做一个对话入口，而是把「动手」这一段标准化。

该说清楚的边界

它的主战场是 Windows 桌面与企业内网流程，这一点从组件覆盖面到部署形态都写得很明白；纯 Linux 桌面或移动端不是它的目标场景。产品迭代节奏稳定，当前版本 v1.1.7 发布于 2026 年 10 月，此前几个版本集中在调度、组件与运行稳定性上。许可证是 Apache-2.0，商用与二次开发都不设障碍，但企业版模块与云端能力属于商业范畴，需要按官方口径确认。

如果只是想把某个网页上的数据抓下来，它显得有些重；可当你需要把这件小事变成每天固定时间跑、出错能回溯、换个人也能接着维护的流程时，这套「可视化编排加执行引擎加管理中心」的组合就开始划算了。

Astron RPA 的价值不在「又一个自动化工具」，而在它把智能体的执行层做成了可以交付的工程件：三百多个原子能力、可视化编排、可上服务端的机器人与调度，加上 Apache-2.0 的开源底子。它适合流程多、系统杂、还需要审计的企业团队；个人用户如果只做一次性脚本，会觉得它铺得太开。