为 Agent 设计软件:当 UI 退居幕后,交互范式如何被重构

原文：Designing for Agents

作者：Teddy Riker

如果你经常混迹于科技圈，看腻了“如何用 Obsidian 构建第二大脑”或者“Anthropic 刚刚颠覆了XX行业”这类帖子，你大概率也刷到过这种观点：UI 已死。现在的论调是：如果一个产品不能通过 MCP、API、CLI 或类似机制被 AI Agent直接使用，它就注定会被淘汰。

这并非危言耸听。在 Ramp（硅谷独角兽企业支出管理平台），我们在过去三个月里见证了 MCP 周活跃用户的 10 倍增长。越来越多的客户不再打开网页，而是通过 Claude、ChatGPT 等 Agent 直接“伸手”到我们的产品里完成操作。

就在上周，传统企业服务巨头 Salesforce 也率先拥抱了这一趋势。

Salesforce 的“无头”革命：在年度 TDX 开发者大会上，Salesforce 发布了其 27 年历史上最具野心的架构重组计划——“Headless 360″（无头 360）。该计划将其平台的所有功能全部转化为 API、MCP 工具或 CLI 命令。这意味着，AI Agent 可以完全绕过浏览器图形界面，直接操控整个 CRM 系统。

这标志着企业级软件对当前悬而未决的生存危机做出了果断回应：在一个 AI Agent 可以自主推理、规划和执行的世界里，公司还需要带有图形界面的 CRM 吗？Salesforce 的答案是：不需要，而这正是未来的方向。

对于 Salesforce 来说，这是一个聪明但绝对艰难的决定。很多销售人员其实都不喜欢 Salesforce 繁琐的 UI，但它之所以能称霸市场，靠的就是用户对其 UX 的“路径依赖”——销售主管们不愿意让团队去学习新系统，一致性往往战胜了功能性。

但创始人 Benioff 和他的团队承认这道“护城河”正在瓦解。他们正在接受一个现实：未来绝大部分的产品使用量，将由 Claude、ChatGPT 等在后台运行、用户根本看不见的 Agent 来驱动。

当然，我认为 UI 并不会彻底消亡。人类依然需要点按、查看配置、核对完成的工作。但 80/20 法则已经反转：未来 80% 的软件交互将由 Agent 完成。这不仅改变了我们需要“做”什么样的产品，更改变了我们“如何”做产品。

全新的交互范式

在过去的二十年里，人与软件交互的主流模式非常简单：

• 过去：用户 ➔ 界面 (UI) ➔ 数据库
• 用户打开产品，点击操作，完成任务。界面就是你体验软件的唯一途径。对大多数人来说，界面就是产品本身。

随着 Agent 承担起更多工作，一个新中间层诞生了，界面消失了，Agent 直接与底层系统对话：

• 过渡期：用户 ➔ 用户的 Agent (如 Claude) ➔ 数据库

但连这种模式也在快速迭代。优秀的软件公司正在（也理应）设计属于自己的原生 Agent 和能力。因此，最终的范式长这样：

• 现在与未来：用户 ➔ 用户的 Agent ➔ 软件的 Agent ➔ 数据库

在这种双 Agent 协同的模型中，软件的 Agent 替用户的 Agent 处理了所有业务复杂度：它负责应用业务逻辑、执行合规规则、并补充外部 Agent 缺失的系统上下文。两个 LLM紧密协作，共同交付结果。

如何为 Agent 做设计？三大核心原则

当你不再为“人”的点击做设计，而是为另一个“AI”的调用做设计时，你需要转变思路：

1. 授人以渔：主动为 Agent 提供成功所需的上下文

我日常的大部分头脑风暴和写作都是和 LLM 一起完成的。写完后，我会通过 Notion 的 MCP 服务器把草稿推送到 Notion。作为多年的 Google Docs 忠实粉丝，Notion 的 MCP 体验直接让我倒戈了。

Notion MCP 最让人惊艳的一点是：无论我让 Agent 写什么（表格、列表、斜体），它从来不出错。

这是精心设计的结果。 Notion 的 notion-create-pages 工具在描述说明中直接写道：

“要获取完整的 Markdown 规范，请始终先拉取 MCP 资源 notion://docs/enhanced-markdown-spec。绝对不要猜测或幻觉（Hallucinate）Markdown 语法。”

每次我让 Agent 写文档时，它做的第一件事就是去读取这份规范，然后才开始动笔。Notion 特有的排版规则被明确地告知给通用大模型，覆盖了模型原本的默认设置。

在旧时代，这种规范会躺在 API 文档里，开发者需要自己阅读、理解并编写代码来转换格式。现在，Notion 在 Agent 需要的那一刻，直接把说明书“递”到了它手里。

反面教材是 Slack 的 MCP：你的 Agent 会默认使用标准 Markdown，结果发出来的消息完全不符合 Slack 的特殊排版规则。最后你花在修改格式上的时间，比你自己手敲一条消息还长。

核心启发： 想想调用你的 Agent 需要知道什么才能成功，然后主动喂给它，不要让它去猜。

2. 构建可观测的反馈闭环 (Feedback Loops)

我们在 Ramp 刚推出 MCP 时，最大的痛点是可观测性（Observability）。我们能看到工具被调用的次数，但看不到触发这些调用的聊天上下文（Chat context）。光看调用量，我们根本不知道哪些功能好用、哪里出了 Bug，或者用户到底想干嘛。

我们通过以下三种方式解决了这个问题：

• 强制要求“意图说明 (Rationale)”： 每当 Agent 调用 MCP 或 CLI 工具时，都必须传入一个 rationale 参数，解释它为什么要发这个请求。虽然我们看不到用户的完整聊天记录，但这些说明拼凑出了用户的真实意图。
• 专属的“反馈工具”： 我们做了一个独立的接口，当 Agent 卡住或频繁报错时可以调用它。Agent 会自动上报“我本来想干嘛”、“我尝试了什么操作”、“我在哪一步卡住了”。
• 工具专属的埋点参数： 在工具内增加特定参数，用来捕获 Agent 拥有的、但我们系统后续排查时需要用到的上下文信息。

把 Agent 变成你的产品经理：假设你在做一个客服系统，提供了“拉取工单”的工具。慢慢地，你发现日志的 rationale 里频繁出现：“正在生成故障报告”、“起草故障摘要”、“收集宕机事故相关的工单”。 这说明你需要开发一个新功能了！你可以直接做一个 build-incident-report（生成事故报告）的工具，让它自动识别关联工单、评估严重程度并输出标准化报告。 上线后，如果 Agent 反馈：“这个报告把三天前的无关工单也抓进去了”，你就可以加个“日期范围”参数。

Agent 虽然会产生幻觉，但它们在提供反馈方面，比你见过的任何人类用户都要具体和一致。 每一个反馈闭环，都是产品自动进化的养料。

3. 弥合上下文鸿沟 (Mind the Context Gap)

在任何 Agent 到 Agent 的交互中，双方都存在信息差：你的系统掌握着对方没有的上下文，反之亦然。优秀的设计需要明确知道双方各自的优势在哪里。

案例：迪亚哥的出差报销

迪亚哥刚出差回来，他的个人 Agent收到了公司费用管理系统 Agent 的 Slack 提醒：有一笔费用信息不全。现在，两个 Agent 都在为了同一个目标努力：正确提交报销。

双方掌握的上下文完全不同：

• 迪亚哥的个人 Agent 掌握： 他的日历（知道他和谁开了会）、邮件（有酒店和航班确认单）、Slack（知道那顿 Kokkari 餐厅的晚宴是请了 Acme 公司的客户）、照片库里的收据截图。
• 费用系统的 Agent 掌握： 原始交易流水数据、公司报销合规政策、公司财务总账 (GL) 科目代码、历史报销归类习惯。

传统的 API 逻辑： 把问题甩给用户。“这是一笔需要 GL 代码的交易，请调用接口获取 150 个 GL 代码选项，然后自己选一个。”优秀的 Agent 交互逻辑： 不问 GL 代码，只问业务上下文。费用系统 Agent 问：“这是一次客户宴请、团队聚餐还是个人差旅？” 迪亚哥的个人 Agent 通过查阅日历或 Slack 聊天记录给出答案。随后，费用系统根据这个答案，自动匹配正确的财务 GL 代码。

在这个过程中，迪亚哥和他的个人 Agent 根本不需要知道什么是“GL 代码”，而财务团队却得到了100%准确的分类。双方各司其职，贡献自己掌握的信息，最终为用户（和会计）交付了完美的体验。

结语：为谁设计，谁来买单？

过去，用户界面（UI）横亘在用户和系统之间；现在，这个界面横亘在用户的 Agent 和你的 Agent 之间。

这种转变彻底重塑了产品团队的职责。你曾经是为那些追求效率、不想犯错、需要视觉反馈的人类设计软件。现在，你是通过一个中间层——AI Agent 来服务同一个人，而这个 Agent 的直觉、上下文和局限性与人类截然不同。

教 Agent 如何成功、建立反馈闭环、填补上下文鸿沟，这三点本质上都在问同一个问题：调用你的 Agent 需要什么才能把工作做好？你给它了吗？

大多数公司只会敷衍地开发一个 MCP 接口，完成 KPI，然后不再过问。这类接口的使用量可能在几个季度内有所增长，然后便会停滞。随着时间的推移，用户和他们的 Agent 会自动转向那些“在 Agent 交互细节上死磕”的产品，而抛弃那些敷衍了事的产品。

像曾经关心人类体验一样，去细心打磨 Agent 的体验吧。因为用不了多久，决定为你这款产品买单的，可能就是这些 Agent 了。