Agent-First:给 AI 造软件,而不是给人

你有没有发现，自己越来越不打开某些软件的网页了？

我上个月统计了一下，Ramp（报销工具）、Linear（项目管理）、Notion（文档）——这三个我每天都在用的工具，我打开网页的次数加起来不超过 5 次。

不是我不想用，是没必要了。

Ramp 我直接让 Claude 帮我操作，一句话搞定报销。Linear 我用 Agent 查进度、更新状态。Notion 更不用说，写文档、查资料全靠 AI。

软件的主要用户，正在从人变成 Agent。

这不是我的错觉。Ramp 的 MCP 周活跃用户，3 个月涨了 10 倍。大家都这么干。

一个简单的事实

过去 20 年，软件设计的核心公式是：

用户 → 界面 → 数据库

所有的工作——产品经理画原型、设计师调像素、前端工程师写组件——都是在优化中间那层"界面"。

现在这个公式变了：

用户 → 用户的 Agent → 软件 → 数据库

再往前走一步：

用户 → 用户的 Agent → 软件的 Agent → 数据库

界面还在吗？在。但 80% 的交互不再经过界面了。

Agent 不需要漂亮的按钮，不需要流畅的动画，不需要精心设计的引导流程。它需要的是清晰的接口、准确的信息、可预测的行为。

为 Agent 设计，到底在设计什么

Ramp 的产品经理 Teddy Riker 写了一篇文章，分享他们面向 Agent 设计产品的思考。三条原则，挺实在的。

第一条：主动告诉 Agent 怎么成功。

不要让 Agent 猜。它不知道你的系统有什么潜规则、什么隐藏约束。你需要在接口设计里把这些信息显式地暴露出来。

Notion 的 MCP 工具做得不错——它的 create-pages 工具描述开头就要求 Agent 先获取 Markdown 规范，再开始创建。Slack 的 MCP 就差一些，Agent 假设标准 Markdown 格式，结果格式全乱了。

区别在于：Notion 主动教 Agent 怎么成功，Slack 让 Agent 自己摸索。

第二条：构建反馈循环。

要求每个工具调用附带一个 rationale 参数——解释为什么发起这个请求。这不是为了限制 Agent，而是为了重建意图。Agent 的行为是黑盒，但 rationale 让你知道它在想什么。

更好的做法是提供反馈工具：Agent 受阻时，可以提交遇到的问题、尝试过的方法、卡住的位置。从这些反馈日志里，你能发现新产品的功能需求。

第三条：注意上下文差距。

Agent 交互中存在双向的上下文差距。你的系统有调用方不知道的上下文（比如公司的报销政策），调用方有你系统不知道的上下文（比如用户的日程、邮件、Slack 对话）。

好的设计不是让 Agent 填表，而是让双方各贡献自己所知的，交付更好的结果。

比如报销系统不应该问 Agent "GL 代码是什么"，而应该问"这笔费用是客户餐、团队餐还是个人旅行"——这是 Agent 能回答的上下文问题。

没有 API 的软件，对 Agent 是"不存在"的

有个说法挺尖锐：

GUI 对 Agent 来说简直 very rude.

人类看到一个漂亮的界面，觉得方便。Agent 看到一个界面，看到的是：我需要模拟鼠标点击、解析 DOM 结构、处理弹窗、应对反爬机制。

这不是交互，这是障碍赛。

更极端一点：没有 API 的软件，对 Agent 来说就是"不在场"的。 它无法操作你的系统，就像一个人不会开门，就永远进不了这个房间。

互联网流量里，人已经是少数派了。越来越多的请求来自 Agent、来自爬虫、来自自动化脚本。如果你的软件只为人设计，你就放弃了大部分潜在用户。

这意味着什么

几个具体的变化，我最近感受很深。

接口优先于界面。 过去产品竞争力在于 UX——界面好用、用户习惯了就离不开。现在这个护城河正在消退。Agent 不关心你的界面好不好看，它只关心你的接口好不好用。

文档变得比设计更重要。 人类可以靠直觉探索界面，Agent 靠文档。你的 API 文档、工具描述、错误信息，就是 Agent 的"界面"。写得清楚，Agent 就能成功；写得含糊，Agent 就会犯错。

可预测性比灵活性更重要。 人类能处理意外情况——弹窗出来了关掉就行。Agent 不行。它需要可预测的输入输出、稳定的接口行为、清晰的错误码。一个行为不稳定的 API，对 Agent 来说就是灾难。

一个类比

过去软件设计像建筑设计——你设计一个商场，顾客自己进来逛。

现在软件设计像交通系统设计——你不只是设计目的地，还要设计通往目的地的路线、信号灯、导航系统。

Agent 就是那些自动驾驶的车。它们不需要漂亮的商场门面，需要的是清晰的道路标识和可靠的导航数据。

写在最后

Salesforce 想明白了。上个月他们搞了个"Headless 360"，把平台的每个能力都拆成 API、MCP 工具和 CLI 命令。翻译一下：他们要把自己变成一个没有界面的软件。

这不是自杀，是自救。

Agent-First 不是说界面不重要了。人类仍然需要界面，仍然需要好看的、好用的、有情感的设计。

但软件的主要用户正在变。如果你的产品还只为人设计，你正在失去一大片"用户"——那些帮你完成工作的 Agent。

下一个想明白的，可能是你。

参考资料： - Ramp: Designing for Agents — Teddy Riker 产品设计方法论 - Salesforce Headless 360 公告 - MCP（Model Context Protocol）官方文档