内容
如果你和我一样，在 X 的同一个角落花时间刷帖，翻过那些"如何用 Obsidian 打造第二大脑"和"Anthropic 刚刚永远干掉了[某个行业]"之类的帖子，你大概也见过"UI 已死"这种论调。除非一个产品能通过 MCP、API、CLI 或某种中间形式被智能体使用，否则它活不过去。
这个趋势在 Ramp 是真实存在的。过去三个月，随着更多客户通过 Claude、ChatGPT 及其他智能体来使用我们的产品，我们 MCP 的周活跃用户增长了 10 倍。
上周，Salesforce 成为首批拥抱这一理念的巨头之一。
来自 VentureBeat：
Salesforce 周三公布了其 27 年历史上最雄心勃勃的架构转型，推出了"Headless 360"——一项全面计划，将其平台的每一项能力以 API、MCP 工具或 CLI 命令的形式暴露出来，让 AI 智能体无需打开浏览器即可操控整个系统。
该发布在公司于旧金山举办的年度 TDX 开发者大会上宣布，立即向开发者提供了超过 100 种新工具和技能。这是对悬在企业软件头上的存在主义问题的果断回应：在一个 AI 智能体能够推理、规划和执行的世界里，公司还需要一个带图形界面的 CRM 吗？
Salesforce 的回答是：不需要——而这恰恰就是重点。
Salesforce 这一步走得很聪明，而且我很难想象做出这个决定有多难。问问大多数销售员，他们会告诉你自己有多讨厌使用 Salesforce。但这款产品之所以无处不在，正是因为其 UX 的熟悉度。销售主管们对让团队学习新技术毫无兴趣，一致性往往胜过功能性。
Benioff 和他的团队正在接受这一护城河正在被侵蚀的现实，并拥抱一个事实：大部分使用将通过 Claude、ChatGPT 及其他用户永远看不到的后台智能体来驱动。
我不认为 UI 正在消亡。人类仍然想要点击操作、查看自己的配置、验证已完成的工作。但 80/20 法则已经翻转：软件交互中新的 80% 将通过智能体完成。这不仅改变了你需要构建什么，还改变了你如何构建它。
新的交互模式
过去二十年来，人们与软件交互的主要方式是：
用户 → 界面 → 数据库
你打开一个产品，四处点击，把事情搞定。界面是你体验软件的方式。对大多数人来说，界面就是产品。
随着智能体承担越来越多的工作，一个新的层级出现了：
用户 → 用户的智能体（如 Claude） → 数据库
智能体代表用户行事。它替你读取、写入和导航产品。突然间，界面消失了。智能体直接与底层系统对话。
但即便是这个模式也在快速演变。软件公司正在（也应该）设计自己的智能体和能力。所以新模式看起来更像这样：
用户 → 用户的智能体 → 软件的智能体 → 数据库
在这个模型中，软件的智能体代表用户的智能体处理复杂性：执行业务逻辑、强制规则、拉取后者所没有的上下文。两个 LLM 协同工作以达成目标。
教会智能体如何成功
我的大部分头脑风暴、写作和创意构思都是和 LLM 一起完成的。当草稿准备好分享时，我会通过 Notion 的 MCP 服务器推送到 Notion。多年来我一直是 Google Docs 的忠实用户；Notion 的 MCP 把我争取了过来。
作为 Notion MCP 用户，我欣赏的一点是：每次我让智能体写点什么，它都能完美搞定。表格、项目符号、斜体、列表，随便你叫什么——智能体从未失手。
这是有意为之的设计。
notion-create-pages 工具的描述开头写道："关于完整的 Markdown 规范，务必首先获取 MCP 资源 notion://docs/enhanced-markdown-spec。不要猜测或捏造 Markdown 语法。"当我让智能体写入页面时，它做的第一件事就是这个。它先获取规范，然后才动笔。每一个 Notion 特有的假设都会对照通用模型的默认值被明确标注出来。
在旧世界里，那份规范会放在 API 文档里，与 Notion 集成的开发者会阅读它、消化它，然后写一个转换层。现在 Notion 在需要的时刻直接把规范交给智能体。
如果你用过 Slack MCP，可能体验过相反的情况。你的智能体假设标准 Markdown，却不遵循 Slack 特有的格式。你最终花在编辑格式上的时间比直接写消息还多：
当然，格式指南在网上能找到，你可以把它们保存在某个地方，然后教你的智能体如何使用。但这很烦人，而且不应该这么麻烦。
想想你的智能体的调用者需要知道什么才能成功，然后主动提供给他们。别让他们自己去摸索。
构建反馈回路
当我们在 Ramp 刚推出 MCP 时，可观测性是我们最大的问题。我们能看到工具调用量，但看不到产生这些调用的聊天上下文。仅凭调用量无法告诉我们什么在正常工作、什么出了问题，或者用户实际想做什么。
我们通过几种方式解决了这个问题：
- 每次工具调用都要求附带"理由"（rationale）。每个 MCP 或 CLI 工具调用都要求智能体包含一个 rationale 参数，解释它为什么发起请求。我们看不到聊天内容，但 rationale 能还原意图。rationale 中的模式告诉我们用户实际在尝试做什么。
- 反馈工具。我们上线了一个独立工具，智能体在遇到阻塞或碰到无法正常工作的模式时可以调用。智能体提交它想做什么、尝试了什么、在哪里卡住了。
- 工具特定的种子参数。我们在单个工具上添加了专门构建的参数，以捕获我们日后需要的上下文：智能体可以获取到的、否则我们不得不去推断的信息。
假设你在构建一个客户支持平台，你为客户提供了获取工单的工具。随着时间推移，你开始在 rationale 日志中注意到相同的短语："构建事件报告"、"起草事件摘要"、"收集工单用于故障复盘"。
这就是一个新产品功能！一个 build-incident-report 工具可以识别相关工单、评分严重程度、拉取受影响的客户群，并以一种强观点化的格式起草摘要。
一旦上线，你可能开始收到关于该工具的反馈："报告拉入了三天前的工单，那些不属于这次事件"或"它总是包含免费层用户的工单，那些人不应该出现在复盘中。"突然间，你的智能体在告诉你的智能体该构建什么。智能体确实会胡编乱造，没错。但它们的反馈也比你交付给的大多数用户更具体、更一致。
如果报告拉入了无关的工单，你就添加一个日期范围参数。如果它不应该包含免费层客户，你就添加一个分群过滤器。每个反馈回路都成为产品改进的新途径。
注意上下文鸿沟
在任何智能体交互中，你的系统拥有调用智能体所没有的上下文，而调用智能体也拥有你的系统所没有的上下文。在设计这些交互时，你应该对各自的优势所在有自己的判断。
假设 Diego 出差了。Diego 的 AI 幕僚长收到了费用管理系统智能体的 Slack 提醒：他最近的出差有未完成的费用报销。现在两个智能体指向同一个目标：正确提交这些费用。
这两个智能体各自带来自己的上下文。
Diego 的幕僚长带来：
- Diego 的日历：知道哪些会议发生了、什么时候、和谁开的
- Diego 的邮件：有酒店和航班确认函作为附件
- Diego 的 Slack：能把 Kokkari 晚餐和他邀请 Acme 团队的线程关联起来
- Diego 的收据（从邮件附件和相册中提取）
费用管理系统带来：
- 原始交易数据（如商户、交易时间）
- 公司的报销政策
- 公司的总账科目（GL accounts）
- 公司的历史编码模式
传统 API 会把问题抛回给用户。"这里有一笔需要 GL 代码的交易。用这个端点获取 150 个 GL 代码选项，然后选一个。"
一个设计良好的智能体交互会翻转这一点——它不要求 GL 代码。它要求上下文：这是客户聚餐、团队聚餐还是个人出差？幕僚长智能体从日历条目或 Slack 线程中提取答案。费用管理系统根据它所缺失的上下文应用正确的代码。
Diego 和他的智能体永远不需要知道 GL 代码是什么，财务团队也能获得准确的分类。双方各贡献所知，交付一个对 Diego 和他的会计师都更好的结果。
当你设计这些智能体对智能体的交互时，要注意上下文鸿沟。承认你的智能体在哪里有短板是可以的——你们都在服务同一个用户。
界面曾经位于 Diego 和他的费用系统之间。现在它位于他的智能体和你的智能体之间。
这一转变重新定义了产品团队的工作。你过去为一个想要快速操作、避免错误、查看自己工作成果的人设计。现在你通过一个中间人为同一个人设计，而这个中间人的直觉、上下文和局限性与用户不同。教会智能体如何成功、构建反馈回路、注意上下文鸿沟，都在问同一个根本问题：你的智能体的调用者需要什么才能做好它的工作，而你有没有提供？
大多数公司会发布一个 MCP，打个勾，然后继续前进。它们的使用量会增长几个季度，然后停滞。随着时间推移，客户会流向那些在细节上精益求精的产品，绕过那些没有的。
像对待人类用户一样用心为智能体构建产品。不知不觉间，签支票的就是它们了。