2026 年 9 月 3 日,YC S26 批次里的 Mireye 在 Hacker News 完成 Launch HN,拿到 28 分。Mireye 给自己的定位非常直接:面向物理世界 AI Agent 的字段级数据基建。它把美国境内任何地点的数据、富化、工具、信号整合到一个 API 和 MCP server 后面,解决 Agent 在面对具体地点、具体问题时普遍存在的「幻觉」。Mireye 的基础设施把 366 个字段横跨 7 个层次(地形、土地覆盖、建成环境、公用事业、地块、气候、灾害)15 个用例预设(洪水风险、野火承保、选址、太阳能选址、数据中心选址等)统一在一个 schema 里,每一字段返回 ok、absent 或 failed 三态而非 null,所有失败以 `partial_failures` 显式返回可重试标记。这种工程选择解决了一个长期被低估的可靠性问题:LLM 看到 null 倾向于填一个看似合理的猜测,这种「confident over gaps」恰恰是 Agent 在物理世界任务里最危险的失败模式。同类企业的踩坑经验(中型建筑 Agent、Fortune 500 保险公司承保 Agent)反复证明了同一个判断——线下 Agent 的瓶颈不是模型能力,而是模型无法访问到结构化、可验证、可追溯的真实世界字段。Mireye 把这一判断工程化为可复用的基础设施。
一、Agent 在物理世界的隐性失败模式
过去一年,大量「智能体落地」的演示集中在数字世界——网页抓取、表单填写、API 调用、文档生成。但当 Agent 的工作场景扩展到物理世界(选址评估、风险核保、施工监管、机器人路径规划)时,同一类 LLM 在数字世界表现良好,在物理世界却普遍崩溃。崩溃不是因为模型能力不足,而是因为模型在面对具体地点、具体问题时缺乏可验证的真实世界数据。
Mireye 的创始人在公告里直接披露了踩坑经历。他在做建筑 Agent 时发现,自己的 Agent 能就任何在线内容进行推理,但对脚下的土地一无所知。一个 Fortune 500 保险公司的工程团队也告诉他,他们的承保 Agent 在内部测试中同样无法稳定输出可被监管接受的答案。问题不是模型不够聪明,而是模型被问到「这块地的洪水区是什么?这块地的所有者是谁?这块地附近是否有变电站?」时,根本没有可信的数据源。LLM 在没有数据时倾向于用训练记忆里的统计模式填充答案,产出一个看起来合理但实际上完全不存在的回答——比如「这块地位于 X 县,洪水区为 A」,而 X 县可能根本不存在或者根本不属于这块地所在的州。
这一失败模式在 HN 评论里得到了验证。一个长期运行多 Agent 系统的实践者直接评论:「我花最多代价的不是错误答案,而是模型本应拒绝的『自信地填补空缺』」。这正是 LLM 在真实世界任务里最危险的行为——它不是给错答案,而是给「看起来对但实际没有依据」的答案,且这种答案会以自信的语气输出,让 Agent 的下游消费者(无论是另一个 Agent 还是人类用户)无法识别其不可靠。
二、Mireye 的字段级数据基建
Mireye 的工程方案是把 366 个字段全部收拢到一个统一 schema,横跨 7 个层次,每一个字段都标注来源、含义、刷新频率。这种结构化设计从根上解决了传统地理空间数据接入的几个经典痛点。
第一个痛点是「同一字段名在不同数据源语义不同」。两个县可能都发布一个名为「owner」的字段,但一个是当前所有者,另一个是历史所有者。如果模型不加区分地调用,会输出错误结论。Mireye 通过统一 schema 强制把语义对齐,任何字段在 Mireye 内部必须有明确语义、明确来源、明确刷新周期。
第二个痛点是「null 的语义歧义」。最危险的 null 不是「这里没有数据」,而是「这个县从来没测绘过相关字段」。模型面对 null 时无法区分这两种情况,倾向于默认「没有数据就是无风险」,导致严重误判。Mireye 的工程对策是把所有字段返回类型显式定义为三态:ok(已知)、absent(确知没有)、failed(无法获取)。`absent` 与 `failed` 都带原因说明,模型与下游消费者可以直接判断「这是已知的事实」还是「这是缺失的事实」,不会把两者混为一谈。
第三个痛点是「数据来源的差异性」。每个县、每个州的地理空间数据发布格式都不一样——有的是 CSV,有的是 shapefile,有的是 PDF,有的是专门 API。Mireye 在后台对每个数据源做独立的爬取、解析、归一化、契约化(明确每个值的来源与含义),并持续监控数据源的更新频率。这一工作的工程量极大,但只有做到这一步,Agent 才能在不同地点获得稳定可比的查询体验。
第四个痛点是「Agent 还需要工具」。仅提供数据不足以让 Agent 完成任务——Agent 还需要确定性几何计算(距离、面积、相邻关系)、包裹归属解析(parcel resolution)、报价预估(job quote)。Mireye 把这些 Agent 普遍做错或计算成本极高的工具统一封装为 API 调用,Agent 只需要调用对应 endpoint,而不是自己用 Python 算距离或估算项目成本。
三、字段级 MCP server 的工程落地
Mireye 把上述能力通过 MCP 协议暴露为标准工具,直接对接 Claude Code、Cursor、自定义 Agent。MCP server 暴露三个核心操作:POST /v1/ask 让 Agent 用自然语言提问(内部 planner 选字段 → 并行抓取 → synthesizer 整合带内联引用的答案)、POST /v1/fetch 让 Agent 直接获取原始字段、POST /v1/proximity 提供驾车时间与距离工具、POST /v1/field-requests 让 Agent 请求一个新字段(后台长跑 Agent 自动研究源、抓数据、与 ground truth 对比、入库,通常一天内完成)。
MCP server 的工程价值在于:Agent 开发者不需要学习任何地理空间数据 API,不需要处理 50 个不同县的元数据,不需要担心「null 是不是真的没有」,只需要在 Agent 的 prompt 里加一句「请用 Mireye 的 MCP 工具获取关于 [地点] 的字段」即可。所有「我能不能访问这个数据」「数据来源可信吗」「字段值是已知还是缺失」的问题都被前置到基础设施层解决。
这种设计对企业级 Agent 落地的启示是双重的。第一,Agent 的可靠性来自基础设施层而非模型层。当 Agent 能访问可验证、可追溯、带 provenance 的数据时,模型本身的幻觉问题被前置消除;当 Agent 只能访问 prompt 里的常识时,任何确定性输出都是侥幸。第二,字段级别的工程粒度(而非数据源级别)是 Agent 时代的数据基建新基元。传统 API 把「获取一个数据集」作为基本操作;Agent 时代的基本操作应该是「获取一个字段的值,带 provenance、freshness、absent 状态」。这一粒度的迁移决定了 Agent 能在多大程度上从「互联网知识」跨越到「物理世界知识」。
四、企业 Agent 拒绝幻觉的工程新基线
把 Mireye 的设计与 HN 评论里同行的反馈合并,可以看到 2026 年企业 Agent 拒绝幻觉必须落地的五项工程基线。
第一项基线是字段级而非数据集级的数据接入粒度。Agent 不能访问「数据集」,只能访问「字段」。每个字段必须有明确的来源、含义、刷新频率、值域、缺失语义。粒度下沉到字段层,才能让 Agent 在调用时获得确定性,而不是面对一团模糊的数据集。
第二项基线是三态返回值而非 null。所有字段必须显式返回 ok / absent / failed 三个状态,缺失与失败必须带原因。任何把缺失或失败伪装成「似乎合理」的默认值的做法都会让 Agent 进入「confident over gaps」的失败模式,这种失败在监管行业会直接导致合规事故。
第三项基线是 provenance 可追溯到原始记录。Mireye 公开承诺「No black-box scores」——不提供「AI 推导出来的魔法数字」。每个字段值必须能追溯到一份原始记录,消费者可以随时重新拉取并验证。这一原则把 Agent 的「能信度」建立在数据可重现性上,而不是模型置信度上。
第四项基线是 partial failure 显式返回。Mireye 的 API 显式返回 `partial_failures` 字段,可重试标记——当一次调用中部分字段获取成功、部分失败时,Agent 不应该被欺骗为「全部成功」,也不应该被欺骗为「全部失败」,而应该看到「成功 X、失败 Y、可重试 Z」的细粒度状态。这一设计让 Agent 可以在不放弃整体响应的前提下,针对失败字段做针对性重试或人工介入。
第五项基线是 MCP server 作为 Agent 接入标准。Mireye 的核心数据能力全部通过 MCP server 暴露,而不是给每个 Agent 框架写专用 SDK。MCP 协议是当前 AI Agent 工具调用的事实标准,把数据基建通过 MCP 暴露意味着任何兼容 MCP 的 Agent(Claude Code、Cursor、自研 Agent)都能直接受益,数据基建的投资不会被绑定到某个特定框架上。
五、链路视角下的最终判断
Mireye 的一个关键决策最能体现「链路 > 模型」立场:创始人在公告里直接承认「frontier models keep hallucinating when asked a specific question about a specific place」,并把整个产品的工程价值锚定在「为模型提供可信数据,让模型不再需要凭空猜测」上。这是一种诚实的工程判断——它没有宣称自己的产品让模型变得「更聪明」,而是承认模型的能力边界,并在边界外用基础设施补足。
这种工程姿态对企业 AI 落地具有方法论价值。当企业评估一个 Agent 供应商或自研 Agent 能力时,真正应该问的不是「它的模型能做什么」,而是「它在哪些环节依赖外部数据基建,这些数据基建是否可验证、可追溯、可重试」。如果一个 Agent 在所有关键决策上都依赖模型自身的「智能」,它在监管行业无法通过审核;如果它在关键决策上依赖可验证的字段级数据基建,它就能在监管行业稳定运行。
把视角拉到 2026 年下半年,可以看到 Agent 基础设施的演进已经形成了一个清晰的脉络:从 OKF Agent Memory 的 Git 原生持久记忆,到 machine0 的 NixOS 全系统代码化持久 VM,到 Mireye 的字段级物理世界数据,所有这些都是把过去依赖模型能力的环节下沉到基础设施层,让 Agent 可以在更稳定、更可审计、更可验证的链路上工作。模型可以迭代——Fable 5 之后会有更强的模型,Opus 5 之后会有更弱的模型——但字段级数据基建、Git 原生记忆、持久化 VM、fail-closed 安全策略这些链路层要素不会因为模型升级而失效,只会因为 Agent 规模扩大而变得越来越重要。把资源投到这些不散的链路层要素上,既是企业 AI 落地的硬性要求,也是工程回报率最高的投资方向。
