杀死自动化项目最常见的说法就是“这个系统没有 API”。这听起来像一堵墙，团队也把它当成一堵墙，悄悄搁置了本可以节省最多时间的工作流。但它不是一堵墙。几乎在所有情况下，没有 API 的系统仍然可以被自动化，因为对于一个已经由人来操作的系统，总有不止一种方式可以把数据输入和输出。本文就是一份实战指南，介绍三种真正行之有效的模式，并按你应当尝试的顺序排列。
我自动化过很多没有 API 的系统，从古老的 ERP 到早于 REST 出现的门户，规律总是一样的：API 是最简单的路径，而不是唯一的路径。当它缺失时，你就退而求其次使用下一种模式；当那种模式也不可行时，再用下一种。下面我会逐一介绍这三种模式、各自适用的场景、如何让它们足够可靠以用于生产环境，以及那些会把一个可行的无 API 项目变成脆弱项目的常见错误。
没有 API 不等于无法自动化
缺少 API 只是去掉了最干净的自动化路径，而不是排除了自动化的可能性，因为任何一个人能操作的系统，软件同样能操作。如果一个人可以登录、读取屏幕、在字段中输入，那么自动化程序也能做到同样的事；如果系统把数据存储在某个地方，那个存储往往可以直接读取。“没有 API 就无法自动化”这一观念是企业自动化中代价最大的误解，因为它让价值最高、最混乱的工作流始终无人问津。
这一点之所以重要，是因为没有 API 的系统往往正是支撑企业核心业务的系统：老旧的 ERP、行业专用的桌面工具、政府门户、没人能扩展的内部应用。恰恰是这些地方堆积着大量手工、重复的工作，也恰恰是自动化回报最大的地方。仅仅因为缺少 API 就把它们排除在外，等于放弃了最大的收益，而实际上它们是可以触达的，只是需要换一种模式。
正确的思路是：不要再问“它有没有 API”，而是开始问“我如何可靠地把数据输入和输出”。这个问题总是有答案的，下面的三种模式就是答案，并且按优先级排序。这与我们关于 AI 能否与遗留系统协作 的文章直接相关，因为缺少 API 正是大多数遗留软件的标志性特征。
三种模式一览
自动化没有 API 的系统有三种模式，你应按顺序尝试，在每个集成点上使用其中最高效可行的那一种。在深入展开之前，先在这里列出它们。
这个顺序是刻意安排的。隐藏数据接口最可靠，所以要先找它。屏幕自动化是在没有数据接口时的主力手段，强大但更脆弱。人在回路是两者都行不通、或操作风险太高无法完全自动化时的诚实兜底方案。大多数真实项目都是混合使用，为每个系统选择合适的模式，这正是一个有经验的部署处理跨多个工具的工作流的方式。
模式一：寻找隐藏接口
在做任何事之前，先寻找隐藏接口，因为许多没有公开 API 的系统仍然通过数据库、导出、文件投递或未公开的端点暴露数据。系统必须把数据存在某处，而且往往必须把数据移动到某处，这些点就是集成机会。只读数据库连接、定时 CSV 导出、系统投递文件的文件夹，或前端调用的内部端点——任何一种都能让你比自动化屏幕可靠得多地获取或输出数据。
这个模式之所以最少被使用，是因为它需要调查而不是假设。询问供应商是否有你可以访问的数据库或导出功能。观察应用加载时的行为，有时前端会调用一个你可以直接使用的内部 API。检查报表能否定时输出到某个文件位置。在设置里寻找隐藏的导入或导出菜单。花一小时做这样的调查，往往能找到一条干净的路径，省去数月维护脆弱的屏幕自动化的时间。
- 直接数据库读取：查询系统的数据存储，通常是读取数据最干净的选项。
- 定时导出：让系统按计划投递 CSV 或文件供你摄取。
- 文件投递或导入文件夹：写入系统要导入的文件，或读取系统生成的文件。
- 未公开端点：前端已经在使用的内部 API，有时可以直接使用。
我的规则：在退而求其次使用屏幕自动化之前，先在这里投入真正的精力，因为隐藏接口的稳定性是屏幕永远无法比拟的。一旦找到隐藏接口，在系统的整个生命周期里，它的价值远超一个每当界面变化就会失效的巧妙自动化。只有当确实没有任何数据路径时，才转向模式二。
模式二：自动化屏幕
当一个系统完全没有数据接口时，你就自动化屏幕，像真人一样通过软件的真实界面来操作它。浏览器自动化通过控制一个真实浏览器来处理基于 Web 的系统：登录、导航、读取字段、输入数据。桌面自动化对已安装的应用做同样的事情。这是针对老旧软件的主力模式，它能解锁那些所有人都以为无法自动化的系统，因为只要人能操作它，屏幕自动化也能操作。
这种权衡在于对脆弱性的诚实。屏幕自动化依赖于界面保持稳定，因此当布局发生变化时，自动化可能会失效，这意味着它需要监控和偶尔的修复。这不是回避它的理由，而是正确工程化它的理由：加入错误处理、重试机制，以及在屏幕表现不符合预期时发出警报。以这种方式实现后，屏幕自动化每天都能在无数真实部署中可靠地运行。AI 提供关于读写内容的智能，自动化则提供执行之手。
到 2026 年，AI 已经让屏幕自动化能力大幅提升，因为模型现在能够理解屏幕并适应小幅变化，而不是遵循僵化的脚本。这使得这一模式比几年前那些脆弱的旧脚本更具韧性，尽管仍然需要监控。对于驱动这种自适应控制的 Agent 工具，我们关于 2026 年最佳 AI 编程 Agent 的综述是一个有用的参考，其底层行为在我们的 Agentic AI 指南 中有详细介绍。
模式 3：刻意设计的人机协同
当数据接口和屏幕自动化都行不通，或者操作风险太高而无法完全自动化时，正确的模式是刻意设计的人机协同步骤。AI 完成繁重的工作——读取、提取、决策、起草——然后将一个干净、经过审核的结果交给人类，由人类在不可触碰的系统中执行最终操作。这不是自动化的失败，而是一种成熟的设计选择，在保留人类把关关键步骤的同时，捕获了大部分价值。
关键词是“刻意设计”。一个良好的人机协同步骤是深思熟虑且精简的：AI 完成百分之九十的工作，因此人们只需花几秒钟确认或输入一个准备好的结果，而不是花几分钟从头做起。糟糕的设计则假装自动化已经完成，并悄悄依赖人们来清理它留下的烂摊子。区别在于人类步骤是经过规划且微小的，还是意外且持续的。设计得当，它仍然能带来巨大的时间节省。
无论是否存在 API，这一模式也是高风险操作的正确答案。对于付款、法律备案或不可逆的变更，将最终操作交由人类处理是一项治理决策，而非技术限制。决定 AI 可以单独做什么、什么需要人来处理，正是我们在 为什么 AI 试点会失败 中讨论的审批边界，而刻意设计的人机协同步骤正是安全实现这一边界的方式。
如何选择正确的模式
选择正确的模式是一个简单的决策：按顺序尝试各种模式，并为每个集成点使用可行的最高级别模式。你不是为整个项目选择一种模式，而是为工作流涉及的每个系统选择最佳可用模式，这就是为什么真实部署中往往三种模式都会用到。
- 从隐藏接口入手。调查是否存在数据库、导出、文件投递或端点。如果存在且可用，就使用它。
- 退而使用屏幕自动化。如果没有数据接口，就自动化 UI，并加入监控和错误处理来进行工程设计。
- 最后退回到人机协同。如果两者都行不通，或者操作风险很高，就为最终操作设计一个最小的人工步骤。
原则在于按顺序尝试，而不是直接跳到最炫的方案。屏幕自动化很吸引人，但一个隐藏的数据库读取在可靠性上每次都能胜过它。而在高风险场景下，一个经过设计的人工步骤胜过完全自动化。让模式匹配每个系统的实际情况，你就能得到一个在安全范围内尽可能自动化的工作流，不多也不少。
还有一条值得内化的决策规则：选择团队中非专家也能维护的模式。一个只有作者本人能看懂的巧妙自动化，在作者离开的那天就成了负担。一个用简单方式记录文档的隐藏接口，或一个带有清晰告警的受监控屏幕自动化，都能经受人员变动。可靠性不仅是技术问题，也是组织问题，最易维护的模式往往就是正确的选择，即使存在稍微更聪明的方案。
RPA vs API vs 人机协同：成本与可靠性
这三种模式不仅工作方式不同，成本和可靠性也不同，理解这些权衡有助于你做出正确选择并设定合理预期。隐藏接口运行成本最低，一旦找到也最可靠，但需要调查才能发现。屏幕自动化搭建迅速，几乎随处可用，但需要持续维护，因为接口一变它就会失效。人机协同步骤在高风险操作的正确性上最可靠，但由于有人留在流程中，会限制你能节省的时间。
对这张表的实际解读是尽可能往上爬：优先选择隐藏接口以获得可靠性和低成本，没有数据通路时退到屏幕自动化，只在正确性或风险要求时才保留人工环节。一个跨越多个系统的工作流往往会同时用到这三种，每个集成点用一种，这种组合是精心设计的部署的特征，而不是妥协。
让无 API 自动化变得可靠
无 API 自动化只有在为可靠性而精心设计时，才配进入生产环境，因为这些模式，尤其是屏幕自动化，比干净的 API 更脆弱。可靠性不是靠运气，而是一套从一开始就融入的实践。自动化能运行多年的团队会应用这些实践；自动化每周都出故障的团队则跳过了它们。
- 监控与告警：观察每一次运行，让损坏的屏幕或失败的导出立即显现，而不是悄无声息地被忽略。
- 重试与错误处理：预期会出现瞬时故障并加以处理，而不是在第一次小故障时就崩溃。
- 校验：检查读取或写入的数据是否合理，避免误读的字段破坏系统。
- 兜底方案：定义自动化无法完成时该怎么办，包括转交给人工处理。
- 明确负责人：当布局变更或更新导致其失效时，由一个人负责修复。
这些可靠性实践正是演示级自动化与生产级自动化的分水岭，也是我们在整个 FDE 系列中反复强调的区别。一个没有监控和负责人的无 API 自动化，只是碰巧今天还能运行的演示。有了这些，它才是一个你可以依赖的系统。请为可靠性工作预留预算，因为这是省时间的自动化与制造新救火场景的自动化之间的差别。
何时推动供应商提供真正的 API
有时最好的长期策略不是绕过缺失的 API，而是争取拿到一个，知道何时推动供应商可以省去多年的维护负担。如果该系统具有战略意义、在公司内被广泛使用，且供应商仍然活跃，那么请求或付费获取 API 访问权限是值得的，因为真正的 API 远比任何变通方案稳定。许多供应商在更高档的套餐中提供 API 却无人购买，仅仅开口询问就可能揭示一条你以为不存在的干净路径。
当集成是核心且长期存在、当你已经是有谈判筹码的重要客户、或者当变通方案脆弱到维护成本高于 API 成本时，就应推动获取 API。当系统即将退役、供应商毫无回应、或者工作流足够小以至于屏幕自动化能低成本处理时，就不必费心。这是一个经济决策：将获取 API 的一次性成本与在系统剩余生命周期内维护变通方案的持续成本进行比较。
诚实的中间路径是先用变通方案上线，同时并行争取 API。你通过屏幕自动化或隐藏接口立即获得价值，如果真正的 API 后来到位，就将其替换为更稳定的连接。这种“先部署、后改进”的顺序胜过等待一个可能永远不会到来的 API 数月之久，而这正是前沿部署工程师面对无 API 问题时所展现的务实精神。
一个真实案例：自动化无 API 的 ERP
下面是一个在工作流中同时运用全部三种模式的示例。一家公司想自动化订单录入：订单通过邮件到达，库存需要在一套没有 API 的 12 年老 ERP 中查询，确认后的订单要录入另一个独立的门户。最初的直觉是 ERP 没有 API，所以无法自动化。其实可以，只要在每个环节使用合适的模式。
邮件读取直接使用了 AI，从杂乱、有时是多语言的邮件（包括扫描附件）中提取订单详情。ERP 库存查询没有 API，但调查发现有一个只读报表数据库——一个隐藏接口，因此可以干净地读取库存而无需触碰界面。门户订单录入既没有 API 也没有安全的数据库写入方式，且涉及财务后果，因此采用了设计好的“人在回路”步骤：AI 准备好完整订单，由人来点击确认。三种模式，一个工作流，而 ERP 从未被替换。
举例来说，结果是：一个三人手工流程被缩短到原来的一小部分时间，几周内上线，旧 ERP 原封未动。教训是：没有 API 是一个路由决策，而不是死路。你能找到隐藏接口就找隐藏接口，必须时才自动化界面，在需要人的环节保留人工，于是那个所有人都说无法自动化的工作流就成功上线了。
需要避免的错误
有几个错误会把一个可行的无 API 自动化变成脆弱的方案，而这些都是可以避免的。
- 假定没有 API 就意味着无法自动化，从而把价值最高的工作流束之高阁。
- 不先寻找隐藏接口，就直接跳到界面自动化。
- 构建界面自动化时没有任何监控，导致布局一变就悄悄失效。
- 把本应保留人工的高风险操作完全自动化。
- 上线时没有指定负责人，导致第一次接口变更就彻底终结了自动化。
这些错误背后的模式要么是过早放弃，要么是草率地过度自动化。平衡的做法——按顺序尝试这些模式并为可靠性而设计——可以避免这两者。无 API 系统不是放弃某个工作流的理由，而是选择正确模式并妥善构建它的理由。
因此，关于自动化一个没有 API 的系统，最后的结论是：缺失的 API 是一个路由决策，而不是死路。调查是否存在隐藏接口，必须时才自动化界面，在需要人的步骤保留人工，并为整个系统做好可靠性设计，包括监控和负责人。做到这些，那个所有人都说因为系统没有 API 而无法自动化的工作流，就会变成一个上线运行、可靠的系统——而这正是前沿部署工程师受雇交付的那种不起眼却高价值的成果。下次再听到“它没有 API”时，把它当作一个路由问题，而不是句号。
常见问题
如何自动化一个没有 API 的系统？
按顺序使用以下三种模式之一：寻找隐藏接口，例如数据库、导出或文件投递；如果都不存在，就用浏览器或桌面自动化来驱动界面，像人一样操作 UI；作为最后手段或针对高风险操作，设计一个“人在回路”步骤，由 AI 准备好工作，由人来执行最终操作。
AI 能与没有 API 的软件协同工作吗？
可以。AI 可以通过隐藏的数据接口、通过自动化驱动界面并由 AI 提供智能，或通过设计好的“人在回路”环节，与没有 API 的软件协同工作。缺少 API 只是去掉了最干净的路径，而不是排除了可能性，因为凡是人能操作的软件，软件同样可以操作。
RPA 和 API 有什么区别？
API 是软件内置的、结构化的直接数据交换方式，干净且可靠。RPA（机器人流程自动化）则像人一样通过用户界面驱动系统，进行点击和输入，通常在没有 API 时使用。RPA 比 API 更灵活，但也更脆弱，因此需要监控和维护。
浏览器自动化在生产环境中可靠吗？
可靠。只要在工程上配备监控、重试、校验以及针对界面变化的快速修复，浏览器自动化就可以用于生产环境。它比 API 更脆弱，因为它依赖界面保持稳定，所以需要专人负责和告警机制。只要把它当作真正的工程来做，而不是一次性脚本，它每天都能可靠地支撑遗留系统集成。
如何将 AI 连接到遗留系统？
将 AI 连接到遗留系统时，首先寻找隐藏的接口，例如数据库或导出功能；如果没有数据路径，就自动化屏幕操作；对于无法触达或风险太高、不宜完全自动化的环节，则使用“人在回路”步骤。系统的老旧程度很少会阻碍 AI，几乎总有可靠的方式实现数据的进出。
构建 API 还是自动化屏幕操作，哪个更好？
如果能让供应商添加 API，或者能找到可用的数据接口，那比屏幕自动化更好，因为它稳定得多。只有在没有任何数据接口时，屏幕自动化才是正确的选择。只要存在数据路径就应优先使用，屏幕自动化只留给那些确实没有其他接入方式的系统。
AI 能让无 API 自动化更可靠吗？
可以。现代 AI 能够理解屏幕内容并适应小幅变化，而不是死板地执行脚本，这使得屏幕自动化比几年前脆弱的脚本更有韧性。它仍然需要监控，但 AI 驱动的自动化在应对轻微的布局变化和杂乱的输入方面表现好得多，从而扩大了可以可靠自动化的无 API 系统的范围。
什么时候应该保留“人在回路”？
当最终操作具有高风险或不可逆时，例如付款、法律申报或重大数据变更，或者不存在可靠的自动化路径时，应保留“人在回路”。设计该环节时应让 AI 完成大部分工作，人只负责确认或执行最终操作，这样既保留了节省时间的好处，又控制了风险。
哪种无 API 模式最可靠？
隐藏数据接口（例如只读数据库、导出或文件投递）是最可靠的模式，因为它不依赖于可能发生变化的用户界面。其次是屏幕自动化，经过精心设计并配备监控时较为可靠，但更脆弱。人在回路（human-in-the-loop）环节对于高风险操作的正确性最为可靠，但会限制自动化的范围。优先选择可行的最高层级模式。
屏幕自动化需要多少维护工作？
屏幕自动化需要定期维护，因为在目标系统更新或重新设计后界面发生变化时，它可能会失效。有了监控和告警，故障可以快速修复，而不是无声的中断；而能够适应小幅变化的现代 AI 驱动自动化可以降低失效频率。为维护工作安排专人负责，它就能可靠运行多年。