选型不看工具新不新，看数据在哪、接口稳不稳、出错代价大不大。先用真实样本跑，让接口和数据决定用 Agent、RPA 还是整套系统。
现场共情：四种工具都能演示，却不一定适合你的约束
同一个“收集资料、判断、回填”的需求，可以被包装成 Agent、桌面机器人、小程序或系统接口。演示时它们都能跑通，进入业务后差异才出现：网页改版让 RPA 找不到按钮，API 权限迟迟拿不到，员工不愿切换入口，Agent 遇到模糊输入自行补全。选型不是比较谁更先进，而是决定哪一层负责理解、哪一层负责执行、哪里让人确认，以及失败后怎样恢复。
判断条件：先按四个问题分流
邮件、文档、图片等非结构化材料需要分类、提取或归纳，可先验证 Agent；字段固定、规则明确的任务优先普通程序或 API。
有授权、文档和测试环境时，API 通常比模拟点击稳定；没有接口且页面长期稳定，RPA 可作为受控过渡方案。
如果用户要提交资料、补字段、看状态和确认结果，小程序或网页入口更自然；纯系统间同步无需额外造一个前台。
规则稳定、异常少，确定性流程更合适；需要多步判断时可让 Agent 准备建议，但高风险动作仍交给规则与人工闸门。
常见的最小组合是：小程序负责收集和确认，Agent 处理非结构化材料，API 写入现有系统；只有目标系统没有接口时，才让 RPA 完成有限的页面操作。组合并非越多越专业，每增加一层都意味着权限、日志、重试和维护成本。
明确不适合做的情况
页面频繁变化却坚持用 RPA；核心系统有正式 API 却用模拟点击绕开权限；输入和规则高度固定却为“智能”引入 Agent；员工无需交互却另建小程序；没有测试账号、字段字典和异常负责人就直接跨系统写数据；一次性低频任务却建设通用平台。上述情况会让维护成本超过节省的工时。先用人工加简单脚本验证流程，往往比同时搭四种技术更快得到结论。
3 天最小动作：让样本和接口决定选型
收集 20 个真实样本，把每步标为读取、理解、判断、确认、写入或通知；注明数据格式、责任人、风险和预期输出，不写技术名词。
确认 API、账号、权限、频率限制和测试环境；列出必须由人完成的补充与确认。对无接口页面评估布局变化和失败后回退。
只选一种主实现加必要人工步骤，跑通 5 个正常和 5 个异常样本。比较完成率、人工介入、恢复难度和维护点，再决定是否增加其他组件。
证据与成熟度边界
小程序与企业 RAG 案例提供可演示的入口、处理、引用和权限结构；海外控制台处于 Beta，可用于讨论授权、回采与人工确认；合作流程页说明诊断、PoC 和验收方法。这些材料能帮助比较实现边界，但不能证明某一技术对所有企业更优，也不代表生产稳定性、客户采用率或业务收益。最终选型必须经过你的真实接口、样本和异常演练。
查看小程序可演示入口 →查看 RAG 可演示结构 →
查看海外控制台 Beta →
查看 PoC 验收方法 →