2026 年 9 月 3 日,YC S26 创业公司 Mireye 在 Hacker News 发布《Launch HN: Mireye (YC S26) – Infrastructure for Physical World AI Agents》,28 分首页关注,创始人 Ansh Chokshi 把公司定位成"AI Agent 用得起的物理世界基础设施"——任何美国地理位置的数据、enrichment、tools、signals,通过一个 API + MCP server 提供。这件事在 AI Agent 落地版图里填补了一个长期被忽视但极其关键的能力层——Agent 能在线上做推理,但对"地面下到底是什么"一无所知。Mireye 把 366 个 location-specific field 收编进 catalog,311 个被客户实际 query,没有单一用例占主导,这条数据本身揭示了 physical world Agent 的真实需求:工程师在各种垂直场景(保险 underwriting、proptech、robotics 选址、数据中心选址、drone 部署规划、城市校车路线、人贩子调查信号)都撞到同一类问题——模型可以在线推理但不知道脚下这块地具体是什么。这件事的工程价值在于它把一个长期被埋没的"ground truth"问题第一次用产品形态暴露出来,提示企业 AI Agent 落地必须补一层 physical infrastructure。
一、Mireye 的核心问题定义
Ansh Chokshi 在 HN 帖里直接复述了驱动他做 Mireye 的完整心路历程。他在 Mireye 之前做 construction agent,撞到了一面无法绕过的墙——Agent 可以推理任何 online 的东西,但对它脚下那块地一无所知。然后一家 Fortune 500 保险公司告诉他,他们的工程师已经放弃做 underwriting agent,原因相同。前沿模型在被问到"某个具体地点的具体问题"时,会持续 hallucinate。
这个故事把企业 AI Agent 落地最隐蔽的一个问题摆到桌面上。今天的 AI Agent 几乎全部围绕在线数据(网页、文档、API、数据库)做推理,而现实世界里有大量决策必须基于 ground truth——某块地的 flood zone、某栋建筑的 owner、某条街的 power infrastructure、某片地的 sewer main。模型在推理时如果把这些 ground truth 留成 null 或者靠预训练数据去猜,产出的决策就是 hallucination。
Mireye 的早期产品是一个 niche 的 site-screening app,客户用它来评估特定地点。客户测试时答案在他们熟悉的地点都站得住,但 app 本身没人用,大家都想要 app 下面的引擎。311 个 fields 被客户 query,317 个 fields 中只有 6 个没人用,没有单一 use case 占主导。这个数字本身就揭示了 ground truth 需求的真实分布——不是某一两个垂直场景需要,而是几乎所有跟物理世界打交道的场景都需要。
二、Mireye 的三层基础设施
Mireye 把 ground truth 拆成 data、enrichment、tools、signals 四层,通过一个 API + MCP server 暴露给任何 AI Agent。
第一层是 data,基础 location 数据集。366 个 fields,从 owner 到 acreage 到 structures 到 nearby power,每个 field 都有来源(where it comes from)、含义(what each value means)、刷新频率(how often it refreshes)的契约。契约是 deterministic 的,不是 AI 生成的。这条设计直接对应 OpenAI 内部 Coding Agent 监控实践里反复强调的"verified data-access contract"——任何 AI Agent 拿到的数据必须有显式契约,不能是模型自由生成。
第二层是 enrichment,把 bare address 丰富成结构化信息。Mireye 在帖里举了一个典型例子——一个地址进入后被丰富成 owner、acreage、structures、nearby power,加上地理边界、规划分区、邻近风险。Enrichment 链是 deterministic 流水线,不是 AI 生成,这样保证结果可重现。
第三层是 tools,AI Agent 经常出错的 operations。Mireye 的工程团队在自建 Agent 时观察到一系列高频失败,每个失败都被工程化成 Agent 可以直接调用的工具。例子包括:Agent 经常靠 eyeball 估距离而不是 compute——Mireye 提供 deterministic geometry 和 drive-time tool;Agent 经常给错地址匹配错 parcel——Mireye 提供 parcel resolution tool;Agent 经常把整个 batch 跑一半就烧光 token——Mireye 提供 quote endpoint 在跑之前定价;Agent 经常想跑完整的 site-screening 或 address underwriting 流程——Mireye 提供 skill package 把整个 workflow 打包。
第四层是 signals,地理位置状态变化的通知。当某块地的规划分区变更、某栋建筑的所有者变更、某片地的 flood zone 重新划定,Mireye 把这些事件作为 signals 推送给 Agent。这层能力让 Agent 从"查询当下"升级到"监测变化",对 insurance underwriting、property management、city planning 这类场景至关重要。
三、Mireye 的核心创新:类型化缺省
Mireye 工程团队在 HN 帖里点出一个长期被 AI 行业忽视但对 ground truth 极其重要的设计——类型化缺省(t yped absence)。
他们发现了一个关键洞察:不同 county 的同名字段含义不同,而且最危险的字段值是 null。如果一个 county 的 flood zone 字段返回 null,它可能意味着"这里没有 flood zone",也可能意味着"这个 county 从来没画过 flood map"。把模型放在这种 null 前面,模型会自动填一个"看似合理"的数字,而这个数字是 hallucination。
Mireye 的解法是 Every field returns ok, absent, or failed,而不是单一返回 value 或 null。这条设计的关键在于它把"我们知道我们不知道"显式化——absent 意味着"我们确认这个地点没有这个属性",failed 意味着"我们尝试获取但失败了",ok 意味着"我们获取到了具体值"。三种状态在语义上完全不同,Agent 在处理 absent 时知道这是确认过的缺失,在处理 failed 时知道需要重试或 fallback,在处理 ok 时才知道可以信任。
这条设计的影响在帖里被客户反复提及——有客户说"rejections are why they trust it",意思是 Mireye 的"我不知道"比"我给你一个看似合理的数字"更值得信赖。这条原则对企业 AI Agent 落地极其关键——任何内部 AI 系统如果要在真实业务里承担决策,必须把"我知道我不知道"显式化,而不是让模型用预训练数据去填补未知。
四、Mireye 与 on-demand indexing
Mireye 最新一块能力是 on-demand indexing——客户问一个 Mireye 还没有的 field,一个 long-running agent 自主 research sources、收集数据、对照 ground truth 验证、index,通常在一天之内完成。Ansh 在 HN 帖里公开承诺从评论里挑几个 field request,实际跑一遍 on-demand indexing 流程,然后回来报告他建了什么。
这条能力的工程价值在于它把 Mireye 从"静态数据集"升级为"动态 ground truth 引擎"。客户不再受限于 366 个预定义 fields,可以通过 API 直接驱动 Mireye 扩 catalog。这意味着 Mireye 的 capability 是开放的,客户不需要等 Mireye 自己开发新 field,可以驱动它做长尾扩展。
但 on-demand indexing 也带来了新的工程问题——long-running agent 跑 research + validation + indexing 这种工作流,跨小时甚至跨天,需要 machine0 的持久 VM + suspend/resume 能力,需要 OneCLI 的 HITL approval 在关键节点把关,需要 Ridge 的 resource access 把 research 用的工具和数据源串起来。Mireye 自己大概是用了某个开源 Agent framework,但 on-demand indexing 这种 long-running 工作流在企业落地时必须用同类持久化机制。
五、把 Mireye 放进 Physical AI Agent 的基础设施矩阵
把 Mireye 和同时期的几个相关产品放在一起,可以看到 Physical AI Agent 的基础设施正在分裂成清晰的层次。
第一层是 ground truth infrastructure,对应 Mireye。AI Agent 需要知道脚下那块地的具体属性——owner、acreage、structures、power、flood zone。366 个 typed field 是基础,但会持续扩展到 on-demand indexing。Mireye 是这个方向的第一个产品形态。
第二层是 real-time robot agent,对应 computer-use agent 公司(Anthropic Computer Use、OpenAI Operator、谷歌 Astra system card 描述的 Astra)。这类 Agent 控制 mouse/keyboard 在数字设备上执行任务,但仍属于"数字物理交互"而非"实物物理交互"。
第三层是 embodied robot,对应人形机器人、自动驾驶、warehouse robot、drone。这是 physical AI 的最终形态,但当前受限于硬件成本、safety certification、latency。Mireye 这类 ground truth infrastructure 是 embodied robot 的前置依赖——机器人要做 site navigation,必须先知道脚下那块地的属性。
第四层是 physical process simulation,对应 physics-informed simulation、digital twin、crash test simulation。这些是物理过程的数字孪生,Agent 在仿真环境里训练物理行为。
Mireye 命中的是第一层——ground truth infrastructure。这层在企业 AI Agent 落地版图里最容易被忽视,因为大多数 AI 工程师的思维模型是"Agent 处理在线数据",不熟悉 ground truth 数据集的来源、契约、刷新机制。但对 insurance、real estate、construction、urban planning 这些依赖 ground truth 的行业来说,这一层缺失意味着 Agent 永远不能从 demo 走向生产。
六、企业 AI Agent 的 ground truth 落地 checklist
把 Mireye 的设计哲学映射回企业落地,可以列出一份 ground truth 落地 checklist。
第一条,企业必须维护一份内部 ground truth 数据集。任何依赖物理世界决策的业务场景,都必须有内部 ground truth 来源——customer location、asset inventory、field service record、sensor data。数据集必须用 deterministic 流程收集,不能依赖模型生成。
第二条,每个 ground truth field 必须有 typed return contract。ok / absent / failed 三态是最低要求,任何 ground truth field 必须能区分"知道没有"、"不知道有没有"、"尝试过但失败"三种状态。Null 是 AI 落地最危险的语义,必须避免。
第三条,ground truth 必须支持 on-demand indexing。新业务场景需要新 ground truth field,企业必须有能力通过工程流程扩展 ground truth catalog,而不是无限期等 IT 部门排期。Mireye 的 on-demand indexing 模型——long-running agent 自动 research + validate + index——是可借鉴的工程模式。
第四条,ground truth 集成必须通过 MCP / API 等标准接口。Agent 不能依赖特殊的 prompt 模板来获取 ground truth,必须通过标准化接口(MCP server、REST API、GraphQL)。Mireye 把 API + MCP server 作为唯一入口就是这个原则的具体落地。
第五条,ground truth 集成必须覆盖 typed failure handling。Agent 调用 ground truth 时,如果返回 failed,必须有 retry、fallback、escalation 三种策略。Retry 适用于暂时性故障,fallback 适用于确定缺失,escalation 适用于持续失败需要人工介入。
第六条,ground truth 数据集必须有来源契约。每个 field 必须明确标注来源(where it comes from)、含义(what each value means)、刷新频率(how often it refreshes)、法律和合规约束。Mireye 的 contract 设计是基础模板。
第七条,ground truth 集成必须有版本管理。Field 含义可能变化、source 可能更替、刷新频率可能调整,这些变化必须有版本控制,Agent 在 prompt 里引用具体 version 而不是 latest。
第八条,ground truth 集成必须可审计。任何一次 ground truth 查询都必须留下日志——谁查的、什么时间、查了哪个 field、什么来源、返回了什么状态。这条是企业合规要求,不是 AI 工程的内部需求。
七、下一步:Physical AI Agent 基础设施的标准化
把这件事放到更大的图景里看,Physical AI Agent 基础设施正在从"垂直散点"过渡到"标准化基础设施"。Mireye 是第一个把 ground truth 做成可独立购买服务的公司,但不会是最后一个——insurance、real estate、logistics、construction 这几个垂直都会出现类似玩家,各自深耕自己的 field catalog。
接下来一年内,ground truth infrastructure 会像 vector database 一样成为 Agent 平台的标配组件。任何严肃的 enterprise Agent 平台都会问两个问题:Agent 能访问哪些 ground truth?ground truth 是 typed absence 还是 raw null?答案决定了 Agent 能不能在真实业务里做决策,而不是停留在 demo 阶段。
回到一开始的问题——Mireye 把"AI Agent 对脚下那块地一无所知"这件事第一次用产品形态暴露出来,366 个 typed field 加 on-demand indexing 加 typed absence 三件套,是 Physical AI Agent 落地的最小可行基础设施样本。剩下的是企业 IT 在落地时把这套模式按自己业务定制,把 ground truth 从"IT 部门的内部知识"升级为"Agent 平台的可发现服务"。这是 2026 年下半年 Physical AI Agent 走向成熟的标志,也是企业 AI Agent 真正能承担物理世界决策的入场券。
