仪表盘已死——Sarah Simionescu(Composio)

▲ 图注：她把一张 Datadog 流水线看板做成了电视突发新闻——红底 BREAKING NEWS 配大字 DASHBOARD IS DEAD，底部滚动条上能读到 NO ONE HAS OPENED IT IN 6 MONTHS。

• Sarah Simionescu（Composio）开场先「坦白」：她每天用 Datadog（监控告警工具）用了六个月，前几天同事请她看一条告警，她打开才发现自己是登出状态，登录后对着 dashboard（仪表盘，把数据做成图表给人看的页面）完全不知道东西在哪——她天天在用它，却一眼都没看过它的界面。她说明这不是在吐槽 Datadog。→ 详细
• 由此抛出论点「仪表盘已死」，说这对在座所有人是好消息，「大概只有我除外」——她的团队负责的正是 Composio 自家的 dashboard。立场先交代：Composio 卖的就是一层给 agent 用的接口，后面的演示与对比都出自厂商自己之手。→ 详细

▲ 图注：每行一个工具、一个语言标签、一条示例查询——jira 标 JQL，slack 标 MODIFIERS，neon、databricks、snowflake、clickhouse 四行都标 SQL，写法却各不相同。

• 她把这段叫复盘（postmortem）。2022 年有人在 Slack 上说搜 prod 会报错，她得立刻开五个窗口：Slack 读上下文、Datadog 写查询、PostHog 查这次 session（字幕只识别出 post，译稿推断为 PostHog，幻灯片的标签页上写的也是它）、VS Code 修 bug、GitHub 开 PR——五套界面，每次改版都得重学。→ 详细
• 更麻烦的是查询语言各自为政：Datadog 有自己的语法，Jira 有 JQL，Slack 有搜索修饰符，就算都号称讲 SQL 也「连 SQL 都谈不拢」（幻灯片上滚过 14 个工具各自的语言标签）。底层论断在这里：每个 dashboard、每种查询语言都只是夹在你和数据之间的「翻译装置」，因为另一头的机器听不懂你要什么——「你从来就不想要 dashboard，也不想要它那套该死的查询语言。你要的是答案」。→ 详细

▲ 图注：输入一句 Show me revenue by customer for Q4，点紫色的 Generate 按钮，得到 11 行 SQL；其中好几处字段被红色波浪线标出，第 1、5、6 行前有红点。

• 2023 年出现 sparkle button（产品角上那颗带星星的 AI 按钮）：点一下，LLM 替你写一条「有时候正确」的查询，前提是问题不需要两个以上的数据库 join（把多张表拼起来查）；很快这种按钮遍地都是，dashboard 号称「AI 原生」。→ 详细
• 2024 年 11 月 Anthropic 发布 MCP（让 AI 连上外部数据与工具的开放标准），你天天在用的 agent 可以自己生成查询、代你执行、直接给答案。但她说 MCP 只是协议、一条通道，怎么跟 agent 沟通由服务方自己决定，「差别全在这里」。→ 详细

▲ 图注：Context window 面板的表头是 784.6k / 1.0M（78%），第一行 MCP tools 占 690.6k、69.1%；四周是 10 个打了绿勾的应用图标。

• 她说真动手接过十来个 MCP server 的人都知道现实是一团乱，原因有三（口头只给第三条标了序号）。第一，agent 不会学习：每次对话都从零开始，昨天在 Slack 里把链接格式搞砸，今天照样再砸一次——幻灯片是标着 Yesterday 与 Today 的两个终端，同一条报错原样重演。→ 详细
• 业界拿 skill（写给 agent 的可复用操作说明）来补，她的判断是「skill 只是一块创可贴」：上下文给得越多 agent 越笨，而多加载工具、多加载 skill 本身就在吃上下文。→ 详细
• 第二，工具太多，把模型淹了。口述和幻灯片是两种口径，分开记。口述讲个数：server 接多了，等于把「几千条工具定义」直接倒进上下文窗口，「光是我们的 GitHub 这一个 toolkit 就有 200 多个工具」，模型会抓错工具、理不清依赖、搞不明白该先调哪个。幻灯片给的是上下文占用而不是工具个数：一个应用都没接时是 104.6k / 1.0M（10%），其中 MCP 工具定义 10.6k；接上 10 个应用后是 784.6k / 1.0M（78%），其中 MCP 工具定义 690.6k（69.1%），空闲只剩 215.4k——活还没开始干，近七成已经被工具说明书占掉。面板上另有两行标着 deferred（延迟加载）的工具定义，全程没变。→ 详细
• 第三，每个 app 都是孤岛：每个 MCP server 只了解它自己，任务一旦横跨两个 app（「而任务总是这样的」），把它们拼起来就成了你的活。她的比喻：MCP 给了 agent 一扇通往每个 app 的门，「却把它们丢在几千个互不相通的房间里，没有地图，也不记得自己曾经来过」。→ 详细

• 她说明这是 mockup（示意演示），演的是「2026 年我会怎么解决开头那条 bug 报告」：Claude 已连上 Composio 的 MCP，她只贴 Slack 那条消息的链接，说一句「请用 Sentry 和 Datadog 找出根因，起草一个 PR，不许出错」（画面上一闪而过的提示词写得更具体，且没有最后这句）。→ 详细
• agent 的第一步不是直接调工具，而是先调 Composio Search 声明它想完成的任务——拉 Slack 消息、搜 Sentry 的 issue、搜 Datadog 日志三项；每项拿回的不只是该用的工具，还有一份用法计划，比如查 Slack 消息之前得先找到频道 ID。随后它读 Slack 原消息，并行查 Datadog、Sentry 并扫描代码库，定位根因后提上带修复的 PR。她称全程不到五分钟，而且「不用搭什么工作流，也不用写一个 skill 去教它」；演示过程视频没给画面，只能依口述。→ 详细
• 她的体感：不管干什么先开 Claude 已成肌肉记忆，以前每天要开的 dashboard 越来越陌生。→ 详细
• 对比部分：她说为 agent 做设计的影响「可以量化」，提到一组「早期的、还没对外发布」的结果——拿 Composio 对比各个 app 在 Claude marketplace 上架的原生 MCP，同样的任务、同样的模型，「看到了明显的差距」。但口述没有报任何指标或数字，画面也始终没切到结果页；这是厂商自测，只能记成「她称差别明显」。→ 详细

▲ 图注：左边是 GitHub 的 Pull requests 接口文档和一串端点；右边五张卡片是 Composio 给 agent 的五个元工具，最大的一张 Search Tools 里是「怎么从功能分支开 PR」的三步计划和两条坑位提示。

• 她对「为什么比原生 MCP 好」的解释：Composio 在做一套专门为 agent 设计的接口，把各个 app「杂乱、文档稀缺、还一直在变」的 API 翻译成 agent 真正爱用的东西；它架在 MCP、CLI（命令行）与原生工具之上，让 agent 能顺畅地跨 app 完成复杂操作。→ 详细
• 幻灯片上交给 agent 的是 5 个元工具（自己不干活、帮 agent 找到并调度真正工具的工具），照页面列全：COMPOSIO_SEARCH_TOOLS（用英语提问，拿回该用的工具和一份带前置条件与坑位提示的计划）、COMPOSIO_MANAGE_CONNECTIONS（查连接状态，没连就给授权链接）、COMPOSIO_MULTI_EXECUTE_TOOL（并行执行多个工具；页上的上限数字读不稳，不引）、COMPOSIO_REMOTE_BASH_TOOL（在远程沙箱里跑 bash）、COMPOSIO_REMOTE_WORKBENCH（在持久的远程沙箱里跑 Python，处理大文件与批量调用）。口述只提到 Search 与 Remote Workbench，另外三个只在幻灯片上。→ 详细

▲ 图注：演示二唯一给了画面的一屏——终端里 agent 列出电商用户最常用的 toolkit 排名表，前几行是 outlook、composio、googledrive、gmail，表下方的 Note 提到 Shopify 只占调用的 0.5%；表内小字偏糊。

• 她说这更接近她每天的用法。先问「用户在 onboarding（新用户引导）时选的垂直行业怎么分布」：Claude 照例先跑 Composio Search，再到 PostHog 写查询、执行、出结果。再加难度：选了电商的那批用户最爱用哪些 toolkit（Composio 对 app 的叫法）——这得拿着 PostHog 里的用户 ID 去 Metabase 拉数据。→ 详细
• agent 先从 PostHog 查出这批用户的 ID 并存起来，「没有把完整结果加载进自己的上下文」；再到 Metabase 拿数据库 schema（表结构）、抽样摸清结构；最后用 Composio Remote Workbench 动态生成一条带 regex（正则）字符串的 SQL，把这些 ID 一次搜出来，同样不把整份数据读进上下文窗口。她称不到几分钟出结果，数据来自两个来源，并邀请大家去展位玩真实版本。→ 详细
• 过程没有画面，只有收尾一屏：排名表前几名依次是 outlook、composio、googledrive、gmail、instagram、googlesheets，agent 还附了一条自己的观察——Shopify 本身在画面上约只占调用的 0.5%，这批电商用户主要在做邮件、内容与广告这类围绕店铺的工作流。屏上的用户数、执行次数和百分比列字太小读不稳，不引；这些她一句也没念。→ 详细

• 她观察到很多创业公司已经为了 GEO（生成式引擎优化，释义为译稿所加）把落地页和网站做得对 AI 友好，「但真正把自己的应用准备好、能让 agent 来用的，少之又少」。→ 详细
• 需求信号：Composio 最初是帮开发者把热门 app 变成 agent 可用的工具；现在「人类已经受够了 dashboard，他们的 agent 也受够了设计糟糕的 MCP server」，开始有创业公司找上门，说客户在求一种通过自己的 agent 使用它们服务的办法。→ 详细
• 结论原话：「你们现在服务的是一个全新物种的用户。它们没有眼睛。它们不会去点你的 sparkle button。它带着一个目标和一套工具出现，评判你的标准只有一条：它能不能把事情办成。」过去十年做产品求的是人用起来容易，「下一个时代，属于那些让 agent 用起来容易的产品」。→ 详细
• 首尾呼应：僵在 Datadog 仪表盘前时她想的是「我要落伍了」，现在把那一刻看成预告。收尾页幻灯片只有一句「AX is the new UX.」（口述没念，也没解释 AX），并列署名 Sarah Simionescu（Member of Technical Staff）与 Malay Vasa（Composio 设计负责人）。配着看：见 ep209（Palantir 的 Chad Wahlquist 也谈过「仪表盘之死」，论证路径不同）、ep215、ep174；同批 268 同样从「dashboard 不给答案」出发。→ 详细