夜雨聆风
【早说】为智能体而设计:当软件的＂用户＂不再是人
前言
当 Salesforce 宣告 “Headless 化”、Ramp 的 MCP 周活三月暴涨十倍，一场静默的范式更迭已然展开：未来八成的软件交互，将由智能体代劳。产品团队的使命也随之改写 —— 你不再只为那个想点选、想核验的人而设计，而要为他身后那位直觉、上下文与局限皆迥异的 “中间人” 而设计。教会智能体如何成事、搭建反馈闭环、弥合上下文落差，方能在这场变局中立于不败之地。
本文来自 5 分钟新知精选。今日前端早读课文章由 @Teddy Riker 分享，@飘飘编译。
译文从这开始～～
如果你和我一样，常常流连于 X（推特）的某个角落，刷过那些 “我如何用 Obsidian 打造第二大脑”、”Anthropic 刚刚彻底终结了某某行业” 之类的帖子，那你大概也见过这样一种论调：UI 已死。任何产品，若不能通过 MCP、API、CLI 或其他类似方式供智能体调用，便难逃被淘汰的命运。
【第3681期】拆解编程智能体：让大模型真正会写代码的六大核心组件
这股趋势在 Ramp 已然显现。过去三个月间，我们 MCP 上的周活跃用户增长了十倍 —— 越来越多的客户正通过 Claude、ChatGPT 等各类智能体与我们的产品打交道。
就在上周，Salesforce 成为首批拥抱这一理念的行业巨头之一。
VentureBeat 报道称：
周三，Salesforce 发布了其 27 年历史上最具野心的架构变革 ——”Headless 360″。这一宏大计划将平台的每一项能力都以 API、MCP 工具或 CLI 命令的形式开放出来，让 AI 智能体无需打开浏览器，便能驾驭整个系统。
此番宣告于旧金山召开的年度 TDX 开发者大会上揭晓，一举向开发者推出了逾百款全新工具与技能。它正面回应了悬于企业级软件头顶的那个终极之问：在一个 AI 智能体能够推理、规划并执行的世界里，企业还需要一个带图形界面的 CRM 吗？
Salesforce 的回答是：不需要 —— 而这恰恰是关键所在。
这是 Salesforce 的一招妙棋，且我想绝非易于决断之举。随便问问销售人员，他们多半会向你倾诉自己有多么不待见 Salesforce。但这款产品之所以无处不在，正是仰仗其用户体验所积淀的熟悉感。销售主管们无意让团队从头适应新技术 —— 一致性，往往比功能本身更受推崇。
贝尼奥夫和他的团队坦然承认：这道护城河正在崩塌。他们顺势而为，接受了一个事实 —— 未来绝大多数的产品使用，将由 Claude、ChatGPT 以及其他用户从未谋面的后台程序所驱动。
我并不认为 UI 行将就木。人们依然想要点选操作，想要亲眼看见自己的配置，想要核验工作是否完成。但二八格局已然倒转：未来与软件交互的那 “八成”，将经由智能体来完成。这不仅改变了我们要构建什么，更重塑了我们该如何去构建。
全新的交互范式
过去二十年间，人们与软件交互的主要路径一直是：
用户 → 界面 → 数据库
打开产品，点点选选，把事办成。界面，就是你感知软件的方式。对大多数人而言，界面即产品。
而随着智能体承担起越来越多的工作，一个新的层级悄然浮现：
用户 → 用户的智能体（如 Claude）→ 数据库
智能体代用户行事。它替你读取、写入、操控产品，省去你亲力亲为之劳。倏忽之间，界面消失了，智能体径直与底层系统对话。
但即便如此，格局仍在飞速演变。软件公司正在（也理应）设计属于自己的智能体与能力。于是，新的范式更近乎这样：
用户 → 用户的智能体 → 软件的智能体 → 数据库
在这一模式下，软件方的智能体替用户方的智能体处理复杂事务：套用业务逻辑、执行规则约束、补足对方所欠缺的上下文。两个大语言模型协同作战，共同推动结果落地。
教会智能体如何把事做成
我大部分的头脑风暴、写作与构思都是与大语言模型一同完成的。一份草稿写就待发时，我便通过 Notion 的 MCP 服务器将其推送过去。多年来我一直是 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 那套独有的格式规则。结果你花在调整格式上的工夫，比自己动手写这条消息还要多：
诚然，格式指引就摆在网上，你也可以将其存档，再教你的智能体如何取用。可这未免太麻烦了，本不该如此。
想一想，调用你智能体的那一方需要知道些什么才能把事办成，然后主动奉上。别让他们自己去摸索。
【第3589期】写好工具，智能体才更聪明：Claude 的自我优化实践
搭建反馈闭环
Ramp 的 MCP 初次上线时，可观测性是我们最棘手的难题。我们能看到工具调用的总量，却看不见催生这些调用的对话上下文。光有数字，无从知晓什么奏效了、什么出岔子了，乃至用户究竟想做成什么。
我们从几个方向破局：
1、强制每次调用附带 “调用缘由”。
每一次 MCP 或 CLI 工具调用，都要求智能体附上一个 rationale 参数，说明为何发起此次请求。我们看不到对话本身，但凭借这些缘由便能还原其意图。归纳缘由中的规律，便能洞悉用户真正想要做的事。
2、一个反馈工具。
我们专门发布了一款独立工具，供智能体在受阻或遭遇行不通的模式时调用。智能体会上报：它原本想做什么、试过哪些办法、又卡在了何处。
3、因工具而异的 “种子参数”。
我们为各个工具量身添加专门的参数，捕捉日后可能用得上的上下文 —— 那些智能体本就掌握、否则我们只能靠揣测的信息。
设想你正在打造一款客服平台，向客户提供拉取工单的工具。日子一久，你在缘由日志里反复瞥见同一类措辞：”撰写故障报告”、”起草事故纪要”、”为故障复盘汇总工单”。
这不就是一个全新的产品功能吗！一款 “故障报告生成” 工具大可应运而生：识别相关工单、评估严重程度、定位受影响的客户群，再以一种立场鲜明的格式起草摘要。
待此功能上线，你或许会陆续收到针对它的反馈：”报告把三天前的工单也一并拉了进来，那些跟本次故障无关”，或是 “它老把免费用户的工单算进来，可这些不该出现在复盘里”。一转眼，你竟有智能体在向你的智能体精准地指点开发方向。智能体诚然会出现幻觉，可在反馈这件事上，它们往往比绝大多数你能交付服务的人类用户还要具体、还要前后如一。
报告若拉来无关工单，便添个日期范围参数；若不该收录免费用户，便加个客群筛选项。每一道反馈闭环，都化作产品进化的一个新阶梯。
留意上下文落差
在任何智能体交互中，你的系统握有调用方智能体所不知的上下文，而调用方智能体也握有你的系统所不知的上下文。设计这类交互时，你应当对双方各自的优势心中有数。
假设 Diego 出了一趟差。Diego 的 AI 幕僚长在 Slack 上接到了费用管理系统智能体的提醒：他这趟差旅有几笔开销尚未报销。此刻，两个智能体的目标同时锁定同一件事：把这些开销妥帖地报上去。
它们各自携来的上下文截然不同。
Diego 的幕僚长所掌握的：
-
Diego 的日历：清楚哪些会议何时、与谁召开 -
Diego 的邮箱：酒店与航班的确认邮件就附在其中 -
Diego 的 Slack：能将那顿 Kokkari 的晚餐与他邀请 Acme 团队的某条对话串联起来 -
Diego 的票据（从邮件附件与相册中提取）
费用管理系统所掌握的：
-
原始交易数据（如商家、交易时间） -
公司的报销政策 -
公司的总账科目 -
公司过往的归类规律
传统 API 的做法，是把皮球一脚踢回给用户：”这里有一笔交易需要总账编码。请调用此接口获取 150 个总账科目选项，然后挑一个。”
而精心设计的智能体交互恰恰反其道而行之 —— 它不索要总账编码，它索要的是上下文：这是客户餐叙、团队聚餐，还是私人行程？幕僚长智能体便能从某条日历记录或某段 Slack 对话中觅得答案。费用管理系统再据此填上正确的编码 —— 它原先所欠缺的那块上下文。
Diego 和他的智能体始终无需操心总账编码为何物，而财务团队则得到了准确的归类。双方各贡献其所知，共同交付一个对 Diego—— 以及他的会计 —— 皆有裨益的结果。
设计这种智能体之间的交互时，请务必留意上下文落差。坦承你的智能体力有不逮之处，并无不妥 —— 你们本就在服务同一位用户。
界面，曾经横亘在 Diego 与他的费用系统之间；如今，它横亘在他的智能体与你的智能体之间。
这一转变，重新定义了产品团队的使命。你过去为之设计的是一个想要事半功倍、规避差错、亲眼见证成果的人；如今你仍在为同一个人设计，却隔着一位中间人 —— 其直觉、上下文与局限，都与那个人迥异。教会智能体如何把事做成、搭建反馈闭环、留意上下文落差 —— 这三件事追问的其实是同一个根本命题：调用你智能体的那一方，需要什么才能把活干漂亮？而这些，你都奉上了吗？
大多数公司会推出一个 MCP、打个勾、然后翻篇了事。他们的使用量会增长几个季度，随后陷入停滞。日子一久，客户会涌向那些在细节上下足了功夫的产品，绕开那些没有的。
请以你昔日伺候人类用户的那份用心，去伺候智能体。不知不觉间，签字付钱的那一位，将会是它。
关于本文译者：@飘飘作者：@Teddy Riker原文：https://x.com/teddy_riker/status/2047312986696454584