先解释一下 MCP（Model Context Protocol，模型上下文协议）：可以理解为一种让 AI 智能体调用外部工具和数据的标准接口。
Salesforce 这一步并不容易。问大多数销售，他们大概率会告诉你并不喜欢用 Salesforce，但 Salesforce 之所以无处不在，恰恰是因为它的 UX 足够熟悉——销售负责人通常不想让团队重新适应新工具，一致性比功能强大更重要。Benioff 和他的团队是在主动承认：这条护城河正在被侵蚀。未来大量的使用行为，会通过 Claude、ChatGPT 以及用户根本看不见的后台流程完成。
UI 不会死。人类仍然要点按钮、看配置、确认任务完成。但 80/20 法则反过来了——未来人与软件之间 80% 的交互，会通过 AI 智能体完成。这件事不只改变你要构建什么，也改变你怎么构建它。
一种新的交互模式
过去二十年，人和软件交互的方式一直是这样：
用户 → 界面 → 数据库
你打开产品，点来点去，把事做完。界面就是产品本身。
随着 AI 智能体接手越来越多工作，一个新的中间层出现了：
用户 → 用户的 AI 智能体（如 Claude）→ 数据库
智能体代表用户行动。它读、写、浏览产品，用户不必亲自操作。界面消失了，智能体直接和底层系统对话。
但这个模式还在变化。软件公司正在——也应该——设计自己的 AI 智能体和能力。所以更准确的模式是：
用户 → 用户的 AI 智能体 → 软件自己的 AI 智能体 → 数据库
软件方的 AI 智能体替用户的智能体处理复杂性：执行业务逻辑、落实规则、补上对方不知道的上下文。两个 LLM 协作，朝同一个结果推进。
那么问题来了：作为产品设计者，你怎么让这种协作真的有效？我觉得有三件事必须想清楚。
教会智能体如何成功
我现在大部分头脑风暴、写作、构思都是和 LLM 一起完成的。草稿可以分享时，我会通过 Notion 的 MCP 服务器把它推到 Notion 里。我曾经是 Google Docs 多年的忠实用户，Notion 的 MCP 改变了我的习惯。
让我欣赏 Notion MCP 的一点是：每次让智能体写东西，它几乎都能一次到位。表格、项目符号、斜体、列表，格式从不出错。
这不是偶然，是设计出来的。
Notion 的 notion-create-pages 工具的描述开头就写着：「如需完整 Markdown 规范，必须先获取 MCP 资源 notion://docs/enhanced-markdown-spec。不要猜测或幻觉 Markdown 语法。」当我让智能体写入页面时，它做的第一件事就是去拿这份规范。先读规范，再动笔。所有 Notion 特有的假设都被明确告知，而不是依赖通用模型的默认理解。
旧世界里，这种规范会放在 API 文档里。开发者读文档、理解规则、写一个转换层。现在，Notion 在智能体真正需要的时候，把规范直接交到它手里。
反例呢？如果你用过 Slack 的 MCP，可能有过相反的体验。你的智能体默认用标准 Markdown，却没遵守 Slack 自己那套格式规则。结果是，你花在改格式上的时间比自己手写还多。
当然，Slack 的格式指南网上能找到，你可以保存下来，再教智能体怎么用。但这很烦——本来就不该是用户操心的事。
应该问的问题是：调用你家智能体的人，需要知道什么才能成功？然后主动把这些信息交给它，不要让它自己摸索。
建立反馈循环
我们刚在 Ramp 发布 MCP 时，最大的问题是可观测性（observability）。我们能看到工具调用量，但看不到触发这些调用的聊天上下文。仅仅知道调用量，并不能告诉我们什么有效、什么坏了、用户到底想干什么。
后来我们用三种方式解决了这件事：
- 每次工具调用都要求填写「理由」。 每次 MCP 或 CLI 调用，都要求智能体带上一个
rationale参数解释发起请求的原因。我们看不到聊天内容，但理由可以重建意图。理由里的模式，会告诉我们用户到底想做什么。 - 提供一个反馈工具。 我们发布了一个独立工具，当智能体遇到阻碍或发现某种模式行不通时，它可以调用这个工具，提交自己原本想做什么、尝试了什么、卡在哪里。
- 给特定工具加入上下文种子。 我们会在单个工具上加专门设计的参数，捕捉之后可能有用的上下文：智能体能拿到的信息，如果不主动收集，事后只能靠猜。
举个例子。假设你做的是一个客户支持平台，提供工具让客户抓取工单。一段时间之后，你开始在理由日志里反复看到类似表达：「正在生成事故报告」「正在起草事故摘要」「正在收集停机复盘相关工单」。
这就是一个新功能的信号。你可以做一个 build-incident-report 工具，自动识别相关工单、评估严重程度、拉取受影响客户群体，并以一种强约束的格式起草摘要。
工具上线后，你可能又会收到反馈：「报告拉进了三天前的工单，但那些不属于这次事故」，或者「它总是把免费套餐用户的工单也放进复盘里，但这些用户不应该出现在事故复盘中」。突然之间，你的 AI 智能体在告诉你的 AI 智能体：接下来该做什么。
智能体当然会幻觉。但在反馈这件事上，它们往往比真正发邮件给你的多数人类用户更具体、更一致。报告拉进了无关工单？加一个日期范围参数。不该包含免费套餐？加一个客户分组筛选器。每一个反馈循环，都是产品改进的新入口。
留意上下文缺口
任何一次智能体到智能体的交互里，你的系统掌握一些对方不知道的上下文，对方也掌握一些你的系统不知道的上下文。设计这种交互时，关键是判断：哪一方在哪些信息上更有优势。
举个具体场景。Diego 出了一趟差，他的 AI 首席幕僚收到一条来自费用管理系统智能体的 Slack 提醒：他这次出差还有未提交的报销。两个智能体现在对齐到同一个目标：把这些报销提交对。
它们带的上下文完全不同。
Diego 的 AI 首席幕僚知道：
- 日历：哪些会议发生了、什么时间、和谁
- 邮箱：酒店和航班的确认邮件
- Slack：能把 Kokkari 那顿晚餐关联到他邀请 Acme 团队的对话线程
- 收据：邮件附件和照片图库里的图
费用管理系统知道：
- 原始交易数据：商户、交易时间
- 公司的报销政策
- 公司的总账科目（GL accounts，General Ledger，财务记账里的总账分类）
- 公司过往的费用归类习惯
传统 API 的做法是把问题甩回给用户：「这里有一笔交易需要 GL code。请调用这个接口拿到 150 个选项，自己选一个。」
设计良好的智能体交互会反过来——它不要 GL code，它要上下文：这是一顿客户餐、团队餐，还是个人旅行支出？AI 首席幕僚可以从日历或 Slack 里找到答案。然后费用管理系统根据自己原本缺失的那部分，自动套用正确的科目。
Diego 和他的智能体都不需要知道 GL code 是什么。财务团队也能拿到准确的分类。双方各自贡献自己知道的，最终对 Diego 和会计都更好。
设计这种交互时，要主动留意上下文缺口。承认你的智能体在哪些事上不擅长是完全可以的——你们其实在服务同一个用户。
产品团队的角色变了
过去，界面夹在 Diego 和他的费用系统之间。现在，界面夹在他的智能体和你的智能体之间。
这件事重新定义了产品团队的工作。过去你为一个想快速完成任务、避免犯错、看得见自己工作的真人设计产品。现在你仍然在服务同一个人，只是中间多了一个代理者，它的直觉、上下文和局限都和人类不同。
教会智能体如何成功、建立反馈循环、留意上下文缺口——这三件事其实在问同一个问题：调用你家智能体的一方，需要什么才能把事做好？你给了它吗？
大多数公司会发布一个 MCP，勾上「我们也支持 AI 智能体了」这个框，然后继续往前走。它们的使用量可能涨几个季度，然后停滞。客户最终会流向那些真正打磨细节的产品，绕开那些敷衍了事的。
像当初为人类用户认真设计产品那样，认真为 AI 智能体设计产品。因为你很快会发现，签支票的可能就是它。
那么下一个问题是：如果你的产品现在被一个 AI 智能体调用，它能在不向用户求助的情况下，把事情做对吗？