Minicor 完成 380 万美元种子轮，把遗留桌面软件变成 AI 可调用的 API 端点
旧金山初创公司 Minicor 的产品定位是把没有 API 的遗留桌面软件包装成 AI 可以调用的端点。据 Thesaasnews 报道，本轮融资披露日期为 2026 年 10 月 14 日，Minicor 完成 380 万美元种子轮融资，由 IA Ventures 的 Brad Gillespie 领投，Y Combinator、Paul Graham、Pioneer Fund、Robinhood Ventures、Garage Capital、Rebel Fund、K5 Global 和 20VC 等参投。
这笔钱规模不大，但它押注的是一个被反复讨论却始终没有好答案的问题：当企业软件的现实是大量关键系统仍停留在桌面时代，AI 智能体如何真正把手伸进去。Minicor 选择切入的层面不是模型层，不是应用层，而是连接层。这个层面通常不被视为性感的技术领域，却可能决定一批 AI 公司能否从试点走向真实交付。
| 字段 | 内容 |
|---|---|
| 公司 | Minicor |
| 轮次 | 种子轮 |
| 金额 | 380 万美元 |
| 投资方 | IA Ventures（领投，Brad Gillespie）、Y Combinator、Paul Graham、Pioneer Fund、Robinhood Ventures、Garage Capital、Rebel Fund、K5 Global、20VC |
| 总部 | 旧金山 |
| 创始人 | Faizaan Chishtie、Saheed Akinbile |
| 官网 | https://minicor.com |
把桌面软件变成 API 端点，而不是再造一个 RPA 平台
Minicor 的产品逻辑可以概括为一句话：描述一个工作流，得到一个 API 端点。YC 页面上的公司自述称，每次调用会在 Windows 虚拟机上触发自愈式桌面自动化，支持本地、云端或 Citrix 环境，并可通过 MCP 由编码智能体构建。系统提供完整视频回放、细粒度日志和 Slack 告警等可观测性工具。这意味着调用方不需要理解底层界面结构，也不需要维护自动化脚本，只需要像调用普通 HTTP 接口一样触发一个工作流。需要说明的是，YC 页面发布时间早于本轮融资，其内容来自公司自述，仅作背景参考。
公司通稿称，构建 RPA 需要大量工程投入，而计算机操作智能体容易部署，但常比人工录入数据更慢。Minicor 试图把这两条路径的缺陷同时绕开：由 agents 学习软件运作方式、构建自动化并保持其运行，企业侧只面对一个 API。换句话说，Minicor 把 RPA 的工程负担从客户侧转移到了平台侧，同时用 API 的稳定性承诺替代了通用智能体的不可预测性。
公司通稿还称，70% 的《财富》500 强企业仍运行在无 API 的桌面应用上。这一数字是单方声明，尚无独立第三方验证。Minicor 目标客户涉及的系统记录包括医疗 EHR、汽车 DMS、金融后台和物流领域的 Windows 桌面应用，这些系统往往已经运行了十年以上，替换成本极高，而业务连续性要求又使得任何停机都不可接受。对 Minicor 而言，集成问题不是技术偏好，而是其客户能否交付 AI 产品的前提。
从已披露的产品形态看，Minicor 的差异化不在“能不能自动化桌面”，而在“自动化之后能不能像 API 一样稳定地被调用”。视频回放、错误日志和 Slack 告警这些可观测性设计，针对的正是桌面自动化最致命的缺陷：失败往往静默发生，直到业务侧发现数据没进去。YC 页面上的公司自述称其采用自愈式桌面自动化，但这一能力在多大程度上能覆盖真实界面变动，仍需要更多客户场景验证。界面元素位置的微小变化、弹窗的意外出现、网络延迟导致的加载时序差异，都可能成为自动化断裂的触发点。自愈机制能否在这些真实条件下持续工作，是产品从演示走向生产的关键分界线。
“仅在数据写入时付费”是一句定价口号，也是一条验证路径
Minicor 的商业模式被公司通稿概括为“仅在数据写入时付费”。这意味着收入确认与自动化是否真正完成数据写入绑定，而不是按调用次数或席位收费。这种设计在销售话术上很有吸引力，因为它把风险从客户侧转移到 Minicor 自己身上：如果自动化失败、数据没有写入，理论上客户不付费。对于正在向遗留行业销售 AI 的客户来说，这种定价方式降低了他们采用 Minicor 的心理门槛，因为集成失败不再是一个需要预先承担的成本项。
但这同时意味着公司的单位经济模型高度依赖自动化成功率。如果自愈机制不能把失败率压到足够低，每一次失败不仅是客户体验问题，还会直接侵蚀收入。传统 RPA 按席位或按项目收费，收入在部署阶段就已经确认，后续维护成本另算；Minicor 的模式则把收入确认推迟到了每一次成功写入之后。这在理论上更符合客户利益，但也意味着公司必须持续证明其自动化在真实生产环境中的可靠性。
YC 页面上的公司自述称，Minicor 目前每周处理数千个工作流，覆盖医疗 EHR 及其他遗留系统，并有客户在 POC 后三周内上线。该页面发布时间早于本轮融资，其运营数据仅作背景参考。不过，从产品逻辑看，“数千个工作流/周”如果属实，说明其系统已经在真实生产环境中运行，而非停留在演示阶段。每周数千次调用意味着系统已经经历了相当数量的真实界面状态和异常路径，这本身就是一种产品成熟度的间接信号。但这一信号仍然需要付费客户数量和续约情况来支撑，而 Minicor 目前均未披露。
客户不是企业 IT 部门，而是卖给遗留行业的 AI 公司
Minicor 的目标客户有一个值得注意的错位：它不直接卖给医院或汽车经销商集团，而是卖给那些正在向医疗、汽车服务、金融服务业和物流行业销售 AI 产品的公司。根据 YC 页面上的公司自述，这些 AI 公司的客户使用的系统记录——EHR、ERP、DMS——是无 API 的 Windows 桌面应用。这个定位意味着 Minicor 的销售对象不是那些对遗留系统有深厚依赖但缺乏现代化动力的传统企业，而是那些已经拿到终端客户订单、却卡在集成环节的 AI 供应商。
这个定位解决了两个问题。其一，AI 公司有强烈的集成动机，因为无法写入客户系统就意味着无法交付，直接影响签单和回款。对于一家已经向医院卖出 AI 病历质控产品的公司来说，如果数据不能写回 EHR，产品就只是一个只读的分析工具，价值大打折扣。其二，AI 公司比传统企业 IT 部门更愿意接受 API 化的抽象方式，因为它们本身就在构建现代软件栈。它们不需要被说服“API 是未来”，它们只是缺一个能把遗留桌面系统变成 API 的中间层。
但这也带来一个结构性风险：Minicor 的收入取决于其 AI 客户能否持续签下终端企业客户。如果 AI 公司向遗留行业的销售周期拉长，或者终端客户对 AI 写入关键系统的合规审查收紧，Minicor 的增长会间接受到抑制。医疗行业的合规审查尤其严格，任何涉及患者数据的自动化写入都可能触发额外的安全评估。汽车经销商管理系统和金融后台同样有自己的监管框架。公司通稿没有披露客户集中度、合同期限或续约情况，这些是判断该模式可持续性的关键缺口。
与 RPA 厂商和计算机操作智能体的双重竞争
以下为编辑分析。Minicor 所处的赛道并不空旷。UiPath、Automation Anywhere 等 RPA 厂商已经在企业自动化市场经营多年，拥有成熟的销售网络和客户关系。与此同时，OpenAI、Anthropic 等模型厂商推动的计算机操作智能体正在快速演进，试图让 AI 直接像人一样操作屏幕。这些公司属于同一赛道，但并非 Minicor 的直接竞争对手。通用智能体的吸引力在于其零集成的愿景：不需要为每个应用单独构建自动化，智能体自己就能理解界面并执行操作。
Minicor 的立场介于两者之间。它不像传统 RPA 那样要求客户构建和维护流程，也不像通用计算机操作智能体那样追求端到端的自主操作，而是把桌面自动化封装成稳定的 API 端点。公司通稿称计算机操作智能体容易部署，但常比人工录入数据更慢。通用智能体的速度劣势可能确实存在于某些场景中，因为模型需要在每一步操作前进行视觉理解和决策，而人工录入在某些高度重复的任务中可能更快。但这一劣势是否普遍成立，取决于具体任务类型和模型能力的发展速度。
从 Minicor 已披露的医疗 EHR、汽车 DMS、金融后台等具体系统类型看，其封装层被通用智能体替代的条件至少包括：通用模型能否在 Citrix 和本地 Windows 环境中保持稳定操作，能否在界面变动时维持足够低的失败率，以及能否提供与 Minicor 视频回放、细粒度日志和 Slack 告警相当的可观测性。这些条件目前均无公开基准测试支持。Minicor 的防御在于其积累的特定系统集成经验、自愈机制和可观测性工具，但这些是否构成足够深的护城河，目前还无法从公开信息中判断。另一种可能性是，Minicor 本身可以随着底层模型能力的提升而受益，因为其平台可以调用更强的模型来改进自愈和自动化构建能力。这种“站在模型肩膀上”的路径能否成立，取决于 Minicor 是否能在模型能力之外积累足够的系统级知识。就 Minicor 的具体差异化而言，“仅在数据写入时付费”的定价模式意味着其收入与自动化成功率直接挂钩，这与传统 RPA 按席位或项目收费的模式形成对比；如果 Minicor 能持续证明高成功率，这一模式可能成为其对抗 RPA 厂商的定价优势，但前提是自愈机制在真实生产环境中的失败率足够低。
资本结构里的信号：第三方数据库记录与本次披露的差异
以下为第三方数据库记录，不是本次融资披露。PitchBook 资料称 Minicor 成立于 2024 年、总部位于旧金山、有 9 名员工，公司未在本轮披露中确认这些信息。该平台还列出 2024 年 10 月 24 日种子轮、2026 年 1 月 1 日加速器/孵化器、2026 年 6 月 8 日种子轮等历史记录，但均未披露金额。PitchBook 同时显示 Minicor 累计融资 50 万美元，投资方包括 Pioneer Fund、Rebel Fund、Y Combinator 和 NOMO Ventures。
NeuronFeed 将 Minicor 的融资记为 50 万美元种子轮，并称这反映 YC P26 批次的标准投资（12.5 万美元对应 7% 股权，另加 37.5 万美元 MFN SAFE），总额未披露。上述第三方数据库记录的抓取时间或最后更新日期未在本次材料中明确，其与本次融资披露的时间关系无法确认。这些记录与本次 380 万美元种子轮在金额和时间线上存在明显不一致，且公司未说明二者关系。对于依赖公开数据判断公司融资历史的观察者来说，这种不一致意味着需要更谨慎地对待单一数据源的结论。
公司通稿感谢名单中列出 Pioneer Fund、Robinhood Ventures、Garage Capital、Rebel Fund、K5 Global、20VC 以及 Austen Allred、Henri Stern、Matteo Franceschetti、Jeff Henriod 等，Thesaasnews 报道的投资方名单未列出这些个人名字。这种差异可能源于不同来源对“参投方”的统计口径不同。Minicor 未披露各投资方的具体出资金额和股权比例。
资金用途明确，但商业化瓶颈同样明确
据 Thesaasnews 报道，Minicor 计划将资金用于进一步开发其自动化基础设施，支持平台将桌面工作流转化为 API 端点，并完善其 AI 智能体技术。这是一个典型的种子轮资金用途：继续打磨产品，扩大可覆盖的遗留系统类型，并提升自愈机制的可靠性。
Minicor 目前披露的客户信息极为有限：没有客户名称，没有收入数据，没有续约率。YC 页面上的公司自述提到的“每周处理数千个工作流”和“三周内上线”是仅有的量化信号，但无法据此判断客户质量、付费意愿或流失情况。每周数千次调用可能来自一个重度使用的客户，也可能分散在多个试用客户之间。三周内上线说明部署速度有优势，但不能说明客户在试用期结束后是否转化为付费合同。
另一个待验证的假设是跨系统泛化能力。医疗 EHR 的桌面自动化经验能否直接迁移到汽车 DMS 或物流 ERP，取决于这些系统的界面结构、数据格式和操作逻辑的相似程度。公司通稿称其 agents 学习软件运作方式、构建自动化并保持其运行。以下为编辑分析：每一种新的遗留系统都可能需要额外的适配工作，这一判断不构成对公司能力的否定。如果泛化成本过高，公司可能陷入“每接一个客户就是一个定制项目”的困境，而这正是传统 RPA 集成商模式的顽疾。YC 页面上的公司自述称，Faizaan Chishtie 曾在一家 YC 初创公司工作，Saheed Akinbile 曾在 Morgan Stanley 和 Ford 工作。这种背景可能有助于理解企业系统的复杂性，但并不自动转化为跨行业的泛化能力。
一个针对本项目的验证边界
本轮融资的金额和领投方在 Thesaasnews 报道与公司通稿中表述一致，参投方名单以 Thesaasnews 报道为准。公司通稿属单方声明。Thesaasnews 文末列出的来源链接指向 Dealroom 的一条记录，但该记录内容未在本次材料中展开，因此不构成独立核验。
公司通稿和 YC 页面中关于产品能力的描述——agents 学习软件运作方式、构建自动化并保持运行、自愈式桌面自动化——均未经过独立技术评估。70% 的《财富》500 强企业仍运行在无 API 桌面应用上的说法，也没有可追溯的原始研究来源。YC 页面发布时间早于本轮融资，其运营数据仅作背景参考，YC 作为投资方并不构成独立验证。
如前所述，PitchBook 和 NeuronFeed 的记录与本次披露存在冲突。在缺乏公司主动澄清的情况下，本次 380 万美元种子轮与 PitchBook 所列 2026 年 6 月 8 日种子轮之间的关系无法确认。NOMO Ventures 出现在 PitchBook 的投资方名单中，但未出现在本次融资报道中，这一差异同样未得到解释。
从已披露的信息可以确认的是：Minicor 正在解决一个真实存在的产业问题，其产品形态与目标客户定位有内在逻辑一致性，且已进入生产环境运行。但它的商业化深度、自愈机制的实际效果、跨系统泛化能力以及单位经济模型，都还处于早期验证阶段。Minicor 需要验证的具体指标包括定价区间、自动化成功率、付费客户数、续约率和跨系统泛化成本，这些均未披露。
RecodeX 极客视：Minicor 的故事本质上是一个关于“最后一公里”的故事。把遗留桌面软件变成 API 端点，听起来像是工程上的补丁，实际上是在为 AI 落地企业流程铺设一条被长期忽视的通道。真正的考验不在于能不能自动化一个 EHR 界面，而在于当界面变动、网络抖动、数据格式不一致同时发生时，这套系统能不能像真正的 API 一样让人忘记它背后是一台 Windows 虚拟机。视频回放、细粒度日志和 Slack 告警这些可观测性设计，是它试图把桌面自动化的不确定性关进笼子里的方式。但笼子是否足够结实，只有付费客户数和续约率能给出答案。
信息来源
本文在采集与核验阶段引用了以下公开来源，按站点去重列出；来源内容归原发布方所有，其口径不代表 RecodeX 的核实结论。