如果你刷到过那些"如何用 Obsidian 打造第二大脑"和"Anthropic 刚刚杀死了某个行业"的帖子，你大概也看过这个观点：UI 已死。
除非一个产品能通过 MCP、API、CLI 或其他中间层被智能体使用，否则它无法存活。
Ramp 最近的数字很说明问题。过去三个月，MCP 周活跃用户增长了 10 倍，越来越多客户开始通过 Claude、ChatGPT 和其他智能体来操作产品。
上周，Salesforce 发布了"Headless 360"，将平台的每一个能力都暴露为 API、MCP 工具或 CLI 命令，让 AI 智能体无需打开浏览器就能操作整个系统。这是 Salesforce 成立 27 年 以来最大的一次架构调整。CLI新交互范式
80/20 已经反转
Benioff 和团队承认了眼前的现实：护城河正在消失，大部分使用量将很快由智能体驱动。
UI 不会消亡。人类仍然需要点击、配置、验证。但 80/20 已经反转：软件的新交互里，80% 将由智能体完成。
这不仅改变了你做的是什么，也改变了怎么做。
新的交互模式
过去二十年，人们与软件交互的主要方式是：
用户 → 界面 → 数据库
你打开一个产品，点击操作，完成任务。对大多数人来说，界面就是产品本身。
智能体开始承担更多工作之后，一个新层级出现了：
用户 → 用户的智能体 → 数据库
智能体代替用户阅读、写入、在产品里导航，用户不用亲自动手。突然之间，界面消失了------智能体直接和底层系统对话。
但这套模式也在快速演变。软件公司正在（也应该）给自己的产品配上智能体。所以更新的架构更像是：
用户 → 用户的智能体 → 软件的智能体 → 数据库
在这个模型里，软件的智能体替用户的智能体处理复杂性：执行规则、提取后者没有的上下文。两个 LLM 协同，给出一个结果。
教智能体如何成功
如果你是 Notion MCP 的用户，应该会注意到一件事：每次让智能体写页面，它总能胜任。表格、项目符号、斜体、列表，要什么格式就不出错。
这不是偶然，是有意设计的。
notion-create-pages 工具的描述开头是这样的：
智能体在写入页面之前，先去把规范拿过来。每个 Notion 特有的假设都与通用模型的默认行为明确对照。
以前，这份规范放在 API 文档里，开发者读了，内化，再写一层转换。现在 Notion 在智能体需要的时刻直接把规范给它。
如果你用过 Slack MCP，可能体验过糟糕的情况。智能体默认标准 markdown，不遵守 Slack 特有的格式。你花在改格式上的时间往往比直接写消息的时间还多。
把智能体需要的规范主动给到它们，而不是让它们自己琢磨。
建立反馈循环
Ramp 刚启动 MCP 时，最头疼的是可观测性。能看到的只有工具调用量，看不到这些调用背后的意图。单独的数字没法告诉他们什么在起作用、什么在崩溃、人们实际在做什么。
他们后来用三个办法解决这个问题：
1. rationale 参数。 每个 MCP 或 CLI 调用都要求智能体附上一个理由，说明为什么提出这个请求。理由能重建意图，理由里的模式告诉团队人们实际在做什么。
2. 反馈工具。 一个独立工具，智能体遇到阻碍时可以调用，提交它尝试了什么、在哪里卡住了。
3. 工具特定的种子。 给各个工具加上精心设计的参数，捕获智能体有访问权限但团队无法推断的上下文。
想象你在构建客户支持平台。半年后，你在 rationale 日志里开始看到同一个短语："正在构建事件报告"、"正在起草事件摘要"。
这是一个新功能的机会。一个 build-incident-report 工具可以识别相关工单、评估严重性、拉取受影响的客户群，并以特定格式起草摘要。
功能上线后，你会开始收到这类反馈："报告拉入了三天前不属于这次事件的工单"。你的智能体在告诉你具体要修什么。
智能体会幻觉，但它们在反馈里的一致性和具体程度，往往超过你能从大多数真实用户那里得到的。
反馈循环每一次都成了产品改进的新入口。
全"信息差"：让 AI 智能体自己对话
任何 AI 智能体都不是全知全能的。你的系统掌握一部分信息，对方的智能体掌握另一部分。设计交互时，关键要搞清楚：谁更擅长知道什么？把信息缺口交给更懂的那一方来补。
员工 D 出差回来，他的 AI 助理收到费用系统的提醒："有笔报销还没提交"。两个 AI 需要协作完成这件事。D 的 AI 助理知道他的行程日历、邮件附件里的酒店和航班确认、Slack 聊天里那顿晚餐是为什么请客、以及收据照片。费用系统知道每一笔刷卡流水、公司报销政策、历史报销习惯，以及底层的财务科目代码。
传统做法是让员工自己填坑------系统直接问他："这笔消费对应哪个财务科目？请从 150 个代码里选一个。" 员工得懂财务才能完成一次报销。
AI 协作的做法把这个逻辑翻了过来。费用系统不问专业代码，问一个自然场景："这是客户招待、团队聚餐，还是个人差旅？" D 的 AI 助理从日历或聊天里提炼出答案，费用系统拿到"场景标签"后自动匹配正确的财务科目。
D 不需要懂财务分类，财务团队拿到了精准合规的数据。过去的界面是"人 ↔ 系统"，现在的交互变成了"人的智能体 ↔ 系统的智能体"。
重新定义产品团队的工作
这种转变改写了产品团队的工作方式。过去你为想要快速行动、避免错误、看到工作成果的人类设计。现在你为同一个人 ------ 但通过一个本能、上下文和局限都与他不同的中介 ------ 设计。
教智能体如何成功、建立反馈循环、关注上下文缺口 ------ 这几个问题本质上都在问同一件事：你的智能体的调用者需要什么才能做好它的活儿，你有没有给到它？
大多数公司发布一个 MCP、打个勾、然后转向下一个。增长会持续几个季度，然后停滞。客户会慢慢转向那些在细节上精雕细琢的产品，回避那些没有的。
用你曾经花在人类身上的同样细心来为智能体构建。很快，它将为你付费。
这对我们意味着什么
这场范式转移对每一位创作者、设计师、开发者意味着什么？
首先，我们正在从"让人适应工具"转向"让工具适应人" ------ 不是通过更复杂的 UI，而是通过更智能的中间层。
其次，Salesforce 这样的巨头都在转向 Agent-first 架构，说明这不是小众极客的玩具，而是下一代计算平台的信号。
第三，以前我们共建的是代码和文档，现在我们共建的是 Agent 可以理解、可以调用、可以协同工作的协议和接口。
如果你在探索怎么让你的工具、作品、工作流变得"智能体友好"，欢迎来 MixLab 无界社区。我们是最先触达未来的那一小部分人，一起把想法跑成实践。
参考
1\] Designing for Agents --- @teddy_riker / Ramp 产品负责人 \[2\] Salesforce Headless 360 发布 --- VentureBeat TDX 开发者大会 \[3\] Notion MCP 文档 --- Notion 官方 