夜雨聆风
未来的软件,要先学会被智能体使用
这篇文章讨论的不是“UI 会不会消失”，而是产品入口正在变化：未来越来越多软件不再只被人点击使用，也会被 Claude、ChatGPT 这类智能体调用、理解和执行。作者用 Salesforce、Notion MCP 和费用报销系统几个例子说明，真正面向智能体设计的产品，不只是把功能暴露成 API 或 MCP 工具，还要主动告诉智能体怎么做才算成功、收集它遇到的问题，并补上双方之间的上下文缺口。对产品团队来说，这意味着设计对象没有从人变成机器，而是要学会通过智能体继续服务人。
原文：https://x.com/teddy_riker/status/2047312986696454584
如果你也常刷我所在的那个 X 信息圈，一边划过那些“我如何用 Obsidian 搭建第二大脑”和“Anthropic 刚刚永久杀死了某某行业”的帖子，你大概也见过一种说法：UI 已经死了。除非一个产品能通过 MCP、API、CLI，或者介于它们之间的某种方式被智能体使用，否则它就活不下去。
这个趋势在 Ramp 确实存在。过去三个月里，我们 MCP 的周活跃用户增长了 10 倍，因为越来越多客户开始通过 Claude、ChatGPT 和其他智能体来使用产品。
上周，Salesforce 成为最早拥抱这个判断的传统巨头之一。
VentureBeat 是这样报道的：
Salesforce 周三发布了其 27 年历史上最有野心的一次架构转型，推出“Headless 360”。这是一项全面计划，要把平台里的每一项能力都暴露为 API、MCP 工具或 CLI 命令，让 AI 智能体无需打开浏览器，也能操作整个系统。
这项发布是在 Salesforce 位于旧金山的年度 TDX 开发者大会上宣布的，首批上线超过 100 个可供开发者立即使用的新工具和技能。它也是对企业软件领域一个生死问题的明确回应：在 AI 智能体可以推理、计划和执行的世界里，公司还需要一个带图形界面的 CRM 吗？
Salesforce 的回答是：不需要。而这正是重点。
Salesforce 这一步很聪明，我也能想象这并不是一个容易做出的决定。你问大多数销售人员，他们都会告诉你自己有多不喜欢用 Salesforce。但这个产品之所以无处不在，是因为它的用户体验足够熟悉。销售负责人并不想花时间让团队适应新技术，而一致性常常比功能更重要。
Benioff 和他的团队正在接受一个现实：这条护城河正在被侵蚀。他们也在主动拥抱另一个现实：未来很大一部分使用量会来自 Claude、ChatGPT 这样的智能体，以及用户看不见的后台流程。
我并不认为 UI 正在死亡。人类仍然想要点击、查看配置、确认工作已经完成。但 80/20 已经反过来了：未来软件交互中新的 80%，会通过智能体完成。这不仅改变了你需要构建什么，也改变了你应该如何构建。
新的交互模式
过去二十年里，人们和软件交互的主要方式是：用户 → 界面 → 数据库
你打开一个产品，点来点去，把事情做完。界面就是你体验软件的方式。对大多数人来说，界面就是产品本身。
随着智能体承担越来越多工作，一个新的层级出现了：用户 → 用户的智能体（比如 Claude）→ 数据库
智能体代表用户行动。它读取、写入和导航产品，用户就不必亲自操作。突然之间，界面消失了。智能体开始直接和底层系统对话。
但这件事还在快速变化。软件公司正在，也应该，设计自己的智能体和能力。所以新的模式更像这样：用户 → 用户的智能体 → 软件的智能体 → 数据库
在这个模型里，软件自己的智能体会替用户的智能体处理复杂性：应用业务逻辑，执行规则，补充后者没有的上下文。两个大语言模型共同协作，推动事情走向一个结果。
教会智能体如何成功
我大部分头脑风暴、写作和构思都和大语言模型一起完成。当草稿准备好分享时，我会通过 Notion 的 MCP 服务器把它推到 Notion。我曾经是多年的 Google Docs 忠实用户，但 Notion 的 MCP 改变了我。
作为 Notion MCP 用户，我很欣赏的一点是：每次我让智能体写点东西，它都能写对。表格、项目符号、斜体、列表，所有格式都没问题，智能体从不失手。
这是有意设计出来的。
Notion 的 notion-create-pages 工具描述一开头就写着：“要获取完整 Markdown 规范，始终先获取 MCP 资源 notion://docs/enhanced-markdown-spec。不要猜测或编造 Markdown 语法。”当我让智能体写入页面时，它做的第一件事就是获取这份规范，然后再开始写。所有 Notion 特有的假设，都会被明确拿出来，与通用模型的默认认知对齐。
在旧世界里，这份规范会放在 API 文档里，由接入 Notion 的开发者阅读、理解，然后写一层转换逻辑。现在，Notion 会在智能体需要它的那一刻，直接把规范交给智能体。
如果你用过 Slack MCP，可能就体验过相反的一面。你的智能体会假设 Slack 使用标准 Markdown，但实际上 Slack 有自己的格式规则。最后你花在调整格式上的时间，可能比自己写那条消息还多：
当然，格式指南在网上可以找到，你也可以把它保存到某个地方，再教你的智能体怎么用。但这很烦，而且本不该有这个必要。
想清楚调用你智能体的人需要知道什么，才能把事情做好。然后主动把这些信息给它。不要让它自己猜。
建立反馈回路
我们刚在 Ramp 推出 MCP 时，最大的问题是可观测性。我们能看到工具调用量，但看不到触发这些调用的聊天上下文。只有调用量并不能告诉我们什么有效、什么坏了，或者用户到底想完成什么。
我们用几种方式解决了这个问题：
-
要求每次工具调用都提供“理由”。每个 MCP 或 CLI 工具调用，都要求智能体加入一个
rationale参数，说明它为什么要发起这个请求。我们看不到聊天内容，但这个理由可以重建意图。理由中的模式会告诉我们，人们到底在尝试做什么。 -
提供反馈工具。我们发布了一个独立工具，让智能体在受阻或遇到无效模式时可以调用。智能体会提交它想做什么、试了什么，以及卡在了哪里。
-
为特定工具加入种子参数。我们会给单个工具添加有目的的参数，用来捕捉以后会需要的上下文：这些上下文是智能体知道的，但如果不收集，我们之后只能靠猜。
想象你正在构建一个客服平台，并提供工具让客户获取工单。过了一段时间，你开始在理由日志里反复看到同样的表达：“正在构建事故报告”“正在起草事故总结”“正在为故障复盘收集工单”。
这就是一个新的产品功能。一个 build-incident-report 工具可以识别相关工单、评估严重程度、提取受影响的客户群体，并用一种强约束格式起草总结。
这个工具上线后，你可能又会开始收到关于它的反馈：“报告把三天前的工单也拉进来了，但它们并不属于这次事故”，或者“它总是把免费层级用户的工单也写进复盘，而这些用户不该出现在复盘里”。突然之间，你就有了智能体在告诉你的智能体：到底该构建什么。
智能体当然会幻觉。但在反馈这件事上，它们往往比大多数真实用户更具体，也更稳定。
如果报告拉进了无关工单，你就加一个日期范围参数。如果不应该包含免费层级客户，你就加一个客户分层过滤器。每一个反馈回路，都会变成产品改进的新方式。
注意上下文缺口
在任何智能体交互里，你的系统都掌握一些调用方智能体没有的上下文；调用方智能体也掌握一些你的系统没有的上下文。设计这类交互时，你应该对双方各自的优势有明确判断。
假设 Diego 出差了。Diego 的 AI 首席助理收到了费用管理系统智能体发来的一条 Slack 提醒：他最近出差还有未完成的报销。现在有两个智能体都指向同一个结果：正确提交这些费用。
这两个智能体各自带着不同的上下文。
Diego 的首席助理知道：
-
Diego 的日历：知道发生了哪些会议、什么时候发生、和谁一起参加
-
Diego 的邮件：有酒店和航班确认信息作为附件
-
Diego 的 Slack：可以把 Kokkari 餐厅的晚餐，关联到他邀请 Acme 团队的那条聊天
-
Diego 的收据：来自邮件附件和照片库
费用管理系统知道：
-
原始交易数据，比如商户和交易时间
-
公司的报销政策
-
公司的总账科目
-
公司历史上的费用编码模式
传统 API 会把问题丢回给用户：“这里有一笔交易需要总账科目代码。请用这个接口获取 150 个总账科目选项，然后选一个。”
设计良好的智能体交互会把这件事反过来。它不会要求对方提供总账科目代码，而是询问上下文：这是客户餐、团队餐，还是个人旅行费用？首席助理智能体可以从日历条目或 Slack 对话里找到答案。费用管理系统再根据自己缺失的这部分上下文，应用正确的科目代码。
Diego 和他的智能体永远不需要知道总账科目代码是什么，财务团队也能得到准确分类。双方各自贡献自己知道的东西，最终交付一个对 Diego 和他的会计都更好的结果。
设计这些智能体到智能体的交互时，要注意上下文缺口。承认你的智能体哪里不够强没关系，因为你们服务的是同一个用户。
过去，界面位于 Diego 和他的费用系统之间。现在，界面位于他的智能体和你的智能体之间。
这个变化重新定义了产品团队的工作。过去，你是在为一个想快速完成任务、避免犯错并看见自己工作成果的人设计。现在，你仍然是在为同一个人设计，但要通过一个中介来服务他。这个中介的本能、上下文和局限，都和人类不同。
教会智能体如何成功、建立反馈回路、注意上下文缺口，本质上都在问同一个问题：调用你的智能体的人需要什么，才能把它的工作做好？你有没有把这些东西给它？
大多数公司会发布一个 MCP，打个勾，然后继续往前走。它们的使用量会增长几个季度，然后停滞。随着时间推移，客户会流向那些认真打磨细节的产品，绕开那些没有这么做的产品。
用你当年为人类设计产品的那份认真，去为智能体设计。你还没反应过来，它可能就已经成了那个签支票的人。