最新

大家好，我是 Ansh，Mireye 的创始人。我正在构建人工智能代理在物理世界中进行决策所需的基础设施：为美国任何地点提供数据、增强信息、工具和信号，所有这些都通过一个 API 和 MCP 服务器提供。 这是演示视频：https://youtu.be/haqO6UbUqU0 要进行尝试，请将 https://www.mireye.com/skills.md 粘贴到您的代理中，并在 mireye.com 免费获取密钥（5,000 积分，无需信用卡）。文档可在 https://docs.mireye.ai 查看。最快的上手方式是向 API 询问任何关于美国任何地点的问题。在你熟悉的地方进行测试，并根据你的了解对其进行评分。 在 Mireye 之前，我曾构建建筑代理，并亲自遇到了这个难题：我的代理可以处理网络上的任何信息，但对它所处的地面一无所知。然后，一家财富 500 强的保险公司告诉我，他们的工程师也因为同样的原因放弃了承保代理。前沿模型在被问及特定地点的具体问题时，会不断产生幻觉。 我的第一个产品是一个小众的场地筛选应用程序。客户在我熟悉的地点测试了它，结果令人满意，但没有人关心这个应用程序本身。他们想要的是其底层的引擎。使用情况也证实了这一点：目录中的 317 个字段中有 311 个被查询，而且没有一个用例占据主导地位。于是我放弃了应用程序，转而开始构建基础设施。 Mireye 不是一个带有 API 的数据集，因为事实本身并不能构成决策。代理通过它来完成整个任务：引用事实、将一个裸地址增强为所有者、地块面积、建筑物以及附近的电力信息，提供操作模型容易出错的工具，以及在发生变化时（如重新分区申请）发出信号。数据、增强信息、工具、信号。 这些工具的产生源于对代理失败的观察。我们在自己的基础设施上构建代理，但总会遇到同样的问题：代理会凭感觉估算距离而不是计算它，会错误地抓取地址对应的地块信息，或者在批量处理过程中耗尽预算。每一次失败都转化为代理可以调用的功能：确定性的几何和驾驶时间工具、地块解析、一个在运行前定价的报价端点，以及打包整个工作流程（如场地筛选或地址承保）的技能。 最困难的部分出乎我的意料。每个数据源都必须收集（有时是按县收集，以各县发布的任何格式），规范化为统一的模式，进行合同约定（数据来源、每个值的含义、刷新频率），然后永远保持更新。我们目前为 366 个字段运行这个循环，通过一个索引进行多租户服务，而且每个数据源都有其独特的挑战。马里兰州发布了一个名为“隐藏的业主姓名”的数据集。我在北卡罗来纳州提交了公共记录请求，因为没有人对污水管道进行索引。 更深层的问题在于含义。两个县发布了同名的字段，但它们的意思却不同。而最危险的值是 null。它意味着“这里没有洪水区”，还是“这个县从未进行过洪水测绘”？将一个模型放在这个空白处，它就会用一个看似合理的数字来填补沉默。所以我们引入了“缺失”状态。每个字段都返回“ok”、“absent”或“failed”。客户告诉我，正是这种拒绝回答让他们信任 Mireye。 最新的功能是按需索引。当你请求一个我们还没有的字段时，一个长时间运行的代理会研究数据源，收集数据，与地面真实情况进行测试，然后进行索引，通常在一天之内完成。我将从这个帖子中挑选几个字段请求，并报告我构建了什么。 人们已经基于 Mireye 构建了许多我未曾预料到的东西：保险团队筛选投资组合的洪水、风灾和野火风险；一家房地产科技公司通过增强信息清理混乱的房源地址；一个健康品牌为海报张贴点评估街道角落；一家机器人公司寻找仓库；数据中心选址；无人机部署规划；一个城市的校车路线；以及用于人口贩运调查的信号。我们的使命是索引地球上的每一寸土地，并使其像网络一样可查询。 定价是公开的：免费套餐每月 5,000 积分，25,000 积分每月 19 美元，120,000 积分每月 99 美元，企业级可定制。 我很想听听你们正在构建的代理在物理世界中触及了哪些方面。如果你们能在你熟悉的地方运行 Mireye，并告诉我我们哪里做得不对，我将非常高兴。

你们有多少人使用笔记本电脑，有多少人使用台式机？为什么？自从我买了笔记本电脑以来，我一直有反复的颈部疼痛和问题，因为我没有严格遵守桌面设置，而是到处使用笔记本电脑，而不是在桌子上使用。没有好的方法可以在没有支架和外部外设的情况下使用笔记本电脑。我认为这对于学生和旅行的专业人士来说是合理的，但对于大多数人来说，我认为并非如此。我正在考虑现在换回全台式机。加分项：Mac 还是 PC 还是 GNU/Linux 还是 BSD。

论文 [pdf]: https://storage.googleapis.com/deepmind-media/papers/weathernext_3.pdf

今天我通过 YC 的联合创始人匹配平台获得了一个匹配。对方声称是一位名叫“Dave J.”的经验丰富的英国技术专家。 匹配成功后，对方立即发来了 WhatsApp 链接，并要求在那里联系。接着，他们表示“正在接受一项手术”，无法进行语音或视频通话。 对他们在 YC 个人资料照片进行的图片反向搜索，指向了一个名叫“David W.”的个人网站和 GitHub 页面。然而，当我要求与我交谈的人提供他们的 GitHub 时，他们却提供了一个完全不同的账号，里面充满了信息安全相关的项目。 还有其他几个可疑之处： * 尽管声称是英国人，但他们的英语水平很差。 * 他们声称没有 LinkedIn，而使用其照片的真实 David W. 却有一个活跃的 LinkedIn 账号。 * 他们不愿意或无法通过语音或视频验证身份。 我没有足够的时间或兴趣继续与对方进行几分钟以上的互动，但请在联合创始人匹配平台上保持警惕。似乎有人在使用虚构的身份和可能盗用的照片来发起对话，并迅速将对话转移到平台之外。 这也不是我第一次在那里遇到可疑的互动。之前有一次，有人要求我冒用我的身份为他们申请工作，或者替他们发帖到 HN。 我已经将此事报告给了 YC。

大家好，HN。我们构建了一个 API 上下文注册表，旨在帮助编码代理（如 Claude Code）生成生产就绪的 API 集成代码，同时避免超出令牌限制。 我们构建了大量的 API 集成。根据我们的经验，大多数编码代理都能很好地编写基本的客户端调用，但在使代码可交付的细节方面却屡屡碰壁，例如幂等重试、速率限制和身份验证令牌管理。 我们尝试了所有现有的将上下文注入编码会话的方法： * 通过 MCP（例如 Context7 或 Mintlify Docs MCP）提供的 Markdown 转储 * 使用 AGENTS.md 和技能以散文形式描述的 API 行为 * OpenAPI 规范 然而，所有这些方法都未能弥补生产就绪方面的差距。 因此，我们提出了自己的方法，将散文与类型化的 SDK 参考代码结合成一个“上下文插件”。您可以将该插件安装到您的编码代理中，当代理处理 API 时，它会自动注入特定语言的上下文。 在我们的基准测试中，上下文插件将一次性生产就绪率提高了高达 34%，使 Sonnet 在相同的集成任务上能够媲美甚至超越基线 Opus。您可以在此处阅读有关我们实验的更多信息：https://www.apimatic.io/blog/working-api-call-is-not-production-ready-integration 我们已经为社区发布了 24 个 API 的上下文插件，包括 Slack、Google Maps 和 Notion，供大家试用。 我们非常希望您能尝试一下，并就我们的插件以及我们的评估方法分享您的反馈。