苹果 Sports 应用只做一件事，分析工具却在不断堆功能

Slate 在 2026 年 6 月 10 日发文，认为苹果的 Sports 应用是过去两年里较好的消费科技产品之一，原因恰恰是它几乎什么都不做。应用里没有新闻标题，也没有流媒体指南。它显示队名和队标、战绩、比赛时间和比分，下面还有一个排名页面。

这种克制正是重点。

据 Slate 报道，2024 年冬天应用发布时，一位苹果高管说：“我们创造 Apple Sports，是为了给体育迷他们想要的东西，一个能极快获取比分和数据的应用。”文章把这段宣传与常见的发布话术做了对比，后者通常谈智能体体验、让球迷更贴近赛场。Slate 的作者说，这款应用足够快，斯坦利杯季后赛期间匹兹堡企鹅队的自动更新比流媒体直播还早到。NFL、大学橄榄球和大学篮球比赛也有同样的情况。

这篇文章值得与体育分析工具的现状放在一起读，因为两者的方向正好相反。苹果把产品做减法，企业数据工具却在厂商能出货的速度下不断堆功能。

以 Starburst 于 2026 年 9 月 11 日发表的论文为例，它考察了两种智能体数据分析架构。作者用一个超市例子展开：要判断上周的鸡蛋促销是否盈利，需要知道这次促销是否带来了本来不会来的顾客，这些顾客是否回访，同一笔交易里还买了什么，以及这些商品的利润如何。文章认为，这些后续问题正是智能体可以承担的工作，前提是智能体能拿到底层交易和会员数据，而这些数据往往存放在不同的数据库里。

Starburst 的分析列出了把数据交给智能体的几种方案。一种是抽取表格并把原始文件交出去，作者称之为“方案 0”，除特殊情况外不予考虑，因为把数 TB 数据送给模型既贵又慢。实际可行的替代方案是让智能体直接访问数据库，自己写 SQL 并反复迭代，让数据库引擎完成处理。文章指出，智能体可能比人类用户要求高得多，可能用试探性查询压垮系统，不过数据库厂商正专注于支持智能体工作负载。

在其他地方，工具对数据放在哪里越来越有主张。

DataZen 于 2026 年 8 月 29 日发布在 Hacker News，是一个本地优先的跨数据库桌面客户端。它默认支持 PostgreSQL、MySQL、SQLite 和 Redis，并为 MongoDB、ClickHouse、DuckDB 和 SQL Server 提供可选驱动。它自带 MCP 服务器，让 Claude 和 Cursor 等智能体直接查询数据库，同时也能作为 MCP 客户端使用。项目页面称，凭据以 AES-256-GCM 加密并保存在操作系统钥匙串中，只有结构和查询上下文会发送给 AI 提供商，它不运行任何云数据库服务。项目采用 GPLv3 许可。

两个更小的自托管项目补全了这幅图景。Adaca Analytics 于 2026 年 9 月 8 日发布到 GitHub，在 Cloudflare Workers 上重建 Google Analytics 仪表盘，从 GA4 Data API 或 BigQuery 导出中拉取每日汇总数据，写入运营者自己控制的 D1 数据库，实时数据仍留在 Google。Plainoldanalytics 于 2026 年 9 月 13 日发布，是 Go 应用的外挂式分析包，设计上与存储无关，提供 gin 和 chi 适配器。

贯穿其中的并不是某一种方案胜出，而是用户周六打开的体育应用和企业分析背后的数据管道有同一种失败模式：不断增加表面积，直到最初的任务变慢。按 Slate 的说法，苹果的应用是少数拒绝这么做的产品。