问题
建筑、维修、车队运营等现场密集型行业仍在使用传统的 dispatch/track/bill 软件:派单给人、跟踪人员、管理资产、给客户开账单。随着 AI agent 和机器人开始进入现场作业,这套模型无法把机器劳动和人类劳动放在同一个流程里管理与结算。YC 明确表示在寻找这类“面向物理世界的新型操作系统”。注意:本卡只有一条生态方的 request 信号,缺少一线用户直接抱怨的痛点证据。
目标用户
为建筑、维修、车队运营等现场密集型行业做软件的创业团队,以及这些行业内开始引入 AI agent/机器人的服务商。信号来自 YC 的生态视角而非终端用户,市场大小暂无法从证据判断。
解决方案
- 统一任务路由:把一个工单拆解后分配给 AI agent、机器人或真人,并按能力与成本动态调度
- 端到端工作记录:谁(或哪个 agent/机器人)做了什么、耗时多少,自动留痕
- 人机混合劳动力管理:真人排班与 agent/机器人可用性放在同一视图
- 自动计费:基于统一工作记录直接生成客户账单
- AI 的角色是任务拆解、agent 调度决策与执行结果的结构化记录
为什么是现在
信号显示 YC 在 2026 年明确征集“AI 原生的物理世界操作系统”,背景是 AI agent 与机器人开始实际进入现场作业,传统 dispatch/track/bill 模式无法覆盖机器劳动力,行业正处在软件范式切换的窗口期。
MVP 范围
第一版只做单一垂直(如设备维护或小规模车队):工单创建→在 AI agent 与真人之间分配→统一工作记录→对客户计费。不做机器人实机调度、不做多行业配置、不做自研 agent 运行时(调用现有 agent 框架)。
风险
- 信号只有 YC 的 request,没有真实用户痛点或付费证据,机会可能被夸大。
- 需要与 incumbent 现场作业软件(派单/计费)正面竞争,替换成本高。
- 机器人调度依赖硬件生态,平台依赖性强。
- 行业(建筑、车队)各自合规与结算规则不同,单一产品难以通用。
信号证据
这张卡片依据的原始讨论。摘录保持原文,点“原文”查看上下文。
YC Requests for Startups10月2日投资方向隐含付费意愿
“So if you're building this new kind of operating system for the physical world, we'd love to hear from you.”
Field-service industries (construction, maintenance, fleet ops) need new AI-native operating systems that manage AI agents, robots, and human workers together instead of the legacy dispatch/track/bill model.原文