最近 Salesforce 走了一步很大胆的棋。在旧金山的年度大会上，这家 27 年的老牌厂商宣布了史上最激进的架构转型——Headless 360 计划：把平台里的每一项能力都暴露成 API、MCP 工具或 CLI 命令，让 AI Agent 可以在完全不打开浏览器的情况下操作整个系统。开发者第一天就能用上 100 多个新工具和技能。

这件事的潜台词是：当 AI Agent 已经能推理、规划、执行，企业还需要一个带 GUI 的 CRM 吗？Salesforce 的回答是：不需要——而这正是重点。

Salesforce 这步很聪明，但绝不是容易的决定。你去问大多数销售，他们大概率会告诉你他们并不喜欢 Salesforce。它无处不在的原因之一，恰恰是 UX 足够熟悉——销售负责人不想让团队再去适应新工具，一致性比功能强大更重要。Benioff 是在主动承认这条护城河正在被侵蚀，未来大量交互会通过 Claude、ChatGPT 以及用户根本看不见的后台流程发生。

UI 不会死。人类还是想点按钮、看配置、确认任务完成。但二八法则反过来了——人和软件之间 80% 的交互，会通过 Agent 完成。这不仅改变你要构建什么，也改变你怎么构建。

交互模式的迁移

过去二十年，软件交互的主线是：

用户 → 界面 → 数据库

打开产品，点来点去，把事做完。界面就是产品本身。

随着 Agent 接手越来越多工作，中间多了一层：

用户 → 用户的 Agent（比如 Claude）→ 数据库

Agent 替用户读、写、浏览，界面消失了，Agent 直接和底层系统对话。

但这个模式在快速演化。软件公司正在——也应该——设计自己的 Agent 和能力。所以更准确的模型是：

用户 → 用户的 Agent → 软件自己的 Agent → 数据库

软件自己的 Agent 替对方处理复杂性：执行业务逻辑、落实规则、补充对方拿不到的上下文。两个 LLM 协作完成同一个目标。

教 Agent 怎么干成事

我现在大部分头脑风暴、写作、构思都是和 LLM 一起做的。草稿成型后，我用 Notion 的 MCP server 推到 Notion。我以前是 Google Docs 重度用户很多年，Notion 的 MCP 让我换了习惯。

让我意外的是：每次我让 Agent 写东西，几乎都能一次到位。表格、项目符号、斜体、列表，格式从不出错。

这不是巧合，是设计出来的。

Notion 的 notion-create-pages 工具描述开头就写着：「如需完整 Markdown 规范，必须先获取 MCP 资源 notion://docs/enhanced-markdown-spec。不要猜测或幻觉 Markdown 语法。」每次写入页面前，Agent 第一件事就是去拉这份规范。先读规则再动笔，所有 Notion 特有的假设都被显式声明，不依赖通用模型的默认理解。

旧世界里，这类规范躺在 API 文档里。开发者读文档、理解规则、写一层转换。现在 Notion 在 Agent 真正需要的时刻直接把规范塞到它手里。

反例是 Slack MCP。Agent 默认用标准 Markdown，根本没遵守 Slack 自己那套格式规则，结果你花在改格式上的时间比手写消息还多。Slack 的格式指南网上能查到，你也可以保存下来再喂给 Agent，但这很烦——本来就不该是用户操心的事。

问题应该这样问：调用你家 Agent 的人，需要知道什么才能成功？把这些东西主动交到它手里，别让它自己摸索。

把反馈循环建起来

Ramp 刚发 MCP 的时候，最大的痛点是可观测性。我们能看到工具调用量，但看不到触发调用的对话上下文。光有调用量数据，根本判断不出什么有用、什么坏掉、用户到底想干什么。

后来我们用三种方式解决了：

  • 每次工具调用都要求带 rationale。每次 MCP 或 CLI 调用，都强制 Agent 附一个 rationale 参数，解释它为什么发起这次请求。我们看不到聊天内容，但理由能重建意图。理由里的模式会告诉我们用户在干什么。
  • 专门做一个反馈工具。Agent 撞到墙、发现某种模式跑不通时，可以调用这个工具，提交它原本想做什么、试了什么、卡在哪。
  • 给特定工具加上下文种子参数。专门设计一些参数，捕捉之后会有用的上下文——这些信息 Agent 当下能拿到，如果不主动收集，事后只能靠猜。

举个场景：你做一个客服平台，提供工具让客户拉工单。一段时间后，你在 rationale 日志里反复看到「正在生成事故报告」「正在起草事故摘要」「正在收集停机复盘工单」这类表达。

这就是产品信号。你可以做一个 build-incident-report 工具，识别相关工单、评估严重程度、拉受影响客户群、用强约束格式起草摘要。

工具上线后，反馈循环又会跟上：「报告把三天前的工单也拉进来了，那些不属于这次事故」「它把免费套餐用户的工单放进复盘了，但这些用户不该出现在事故复盘里」。你的 Agent 开始告诉你的 Agent 接下来要构建什么。

Agent 当然会幻觉。但在反馈这件事上，它们往往比真实人类用户更具体、更一致。报告拉了无关工单，加日期范围参数；不该包含免费套餐，加客户分组筛选器。每个反馈循环都是新的产品入口。

留意上下文缺口

任何 Agent 交互里，你的系统知道一些对方不知道的事，对方也知道一些你不知道的事。设计交互时要清楚判断：哪一方在哪些信息上更有优势。

举个例子：Diego 出了一趟差，他的 AI 首席幕僚收到费用管理系统 Agent 的 Slack 提醒——这趟差还有未提交的报销。两个 Agent 现在指向同一个目标：把这些报销正确提交。

它们各自掌握不同的上下文。

Diego 的 AI 幕僚知道：

  • 日历：哪些会议、什么时候、和谁
  • 邮箱：酒店和航班确认邮件
  • Slack：Kokkari 那顿晚餐关联到他邀请 Acme 团队的对话线程
  • 收据：邮件附件和相册里的照片

费用管理系统知道：

  • 原始交易数据（商户、交易时间）
  • 公司报销提交政策
  • 公司总账科目（GL accounts，General Ledger 总账分类）
  • 公司过往的费用归类习惯

传统 API 会把问题甩回给用户：「这笔交易要填 GL code，调这个接口拿 150 个选项，自己选一个。」

设计良好的 Agent 交互反过来做——它不要 GL code，要的是上下文：这是客户餐、团队餐，还是个人旅行支出？AI 幕僚能从日历条目或 Slack 对话里找到答案。费用管理系统拿到自己缺失的那块上下文后，自动套用正确科目。

Diego 和他的 Agent 都不需要知道 GL code 是什么，财务团队也能拿到准确分类。两边各贡献自己知道的，最终对 Diego 和他的会计都更好。

设计这种 Agent 到 Agent 的交互时，承认你的 Agent 在哪些地方不擅长是完全 OK 的——你们其实在服务同一个用户。

写给产品团队

过去界面夹在 Diego 和费用系统之间，现在界面夹在他的 Agent 和你的 Agent 之间。

这件事重新定义了产品团队的工作。以前你是在为一个想快速完成任务、避免犯错、能看见自己工作进展的真人设计。现在你还在服务同一个人，只是中间多了一个代理者，它的直觉、上下文、局限都和人类不一样。

教 Agent 干成事、建反馈循环、留意上下文缺口——这三件事其实都在问同一个问题：调用你家 Agent 的那一方，到底需要什么才能把活儿做好？你交给它了吗？

大多数公司会发布一个 MCP，勾上「我们支持 Agent 了」这个框，然后继续往前走。使用量可能涨几个季度，然后停滞。时间一长，客户会流向真正打磨细节的产品，绕开敷衍了事的。

像当年为人类用户设计产品一样，认真为 Agent 设计。最后签支票的，可能正是它。