大家好，我是玄姐。

PS：

Harness 工程干货直播，欢迎点击预约，直播见。

如果你和我一样，常在 X（推特）的同一个角落闲逛，刷过那些"我用 Obsidian 搭建了第二大脑"和"Anthropic 刚刚永远杀死了[某某行业]"的帖子，那你大概也看到过这样一种观点：UI 已死。除非一个产品能通过 MCP、API、CLI 或类似方式被智能体使用，否则它将无法生存。

在 Ramp，这一趋势是真实存在的。过去三个月，我们 MCP 的周活跃用户增长了 10 倍，因为越来越多的客户通过 Claude、ChatGPT 和其他智能体来使用我们的产品。

上周，Salesforce 成为首批拥抱这一理念的行业巨头之一。

据 VentureBeat 报道：

Salesforce 于周三公布了其 27 年历史上最雄心勃勃的架构转型，推出"Headless 360"，一项全面的计划，将其平台上的每一项能力都暴露为 API、MCP 工具或 CLI 命令，让 AI 智能体无需打开浏览器即可操作整个系统。

这一发布是在旧金山年度 TDX 开发者大会上宣布的，立即向开发者交付了 100 多个新工具和技能。它标志着对企业软件领域一个生存性问题的果断回应：在一个 AI 智能体能够推理、规划和执行的世界里，公司是否还需要一个带有图形界面的 CRM？

Salesforce 的答案是：不需要，而这正是关键所在。

这是 Salesforce 的明智之举，我很难想象他们做出这个决定有多不容易。去问大多数销售人员，他们会告诉你有多不喜欢使用 Salesforce。但这款产品之所以无处不在，是因为其用户体验的熟悉感。销售领导们没兴趣让团队学习新技术，一致性往往胜过功能性。

Benioff 和他的团队正在承认这道护城河正在侵蚀，并拥抱这样一个现实：大部分使用将通过 Claude、ChatGPT 等智能体以及用户永远看不到的后台流程来驱动。

我不认为 UI 正在消亡。人类仍然想要指指点点、查看配置、核实已完成的工作。但 80/20 法则已经翻转：新的 80% 的软件交互将通过智能体完成。这不仅改变了你需要构建什么，还改变了你的构建方式。

1、新的交互模式

在过去二十年里，人们与软件交互的主要方式是：

• 用户 → 界面 → 数据库。

你打开一个产品，四处点击，完成工作。界面是你体验软件的方式。对大多数人来说，界面就是产品。

随着智能体承担更多工作，一个新层级出现了：

• 用户 → 用户的智能体（如 Claude） → 数据库。

智能体代表用户行事。它读取、写入、浏览产品，让用户无需亲自动手。突然间，界面消失了。智能体直接与底层系统对话。

但即使这样也在迅速变化。软件公司正在（也应该）设计自己的智能体和能力。因此新的模式看起来更像这样：

• 用户 → 用户的智能体 → 软件的智能体 → 数据库。

在这个模式中，软件的智能体代表用户的智能体处理复杂性：应用业务逻辑、执行规则、引入后者所没有的上下文。两个大语言模型协同工作，共同推进一个结果。

2、教会智能体如何成功

我的大部分头脑风暴、写作和构思都是与大语言模型一起完成的。当草稿准备好分享时，我通过他们的 MCP 服务器推送到 Notion。多年来我一直是 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 特定的格式规范。你最终花在编辑格式上的时间，比你自己写消息还多：

当然，格式指南在网上有，你可以保存在某处并教你的智能体如何使用。但这很烦人，而且本不该如此。

想想你的智能体调用者需要知道什么才能成功，然后主动提供给他们。别让他们自己去琢磨。

3、构建反馈循环

当我们在 Ramp 首次推出 MCP 时，可观测性是我们最大的问题。我们能看到工具调用量，但看不到产生这些调用的周围聊天上下文。仅凭调用量无法告诉我们什么有效、什么出故障、或者人们到底想完成什么。

我们通过几种方式解决了这个问题：

• 要求每次工具调用都提供"理由"。

每次 MCP 或 CLI 工具调用都要求智能体包含一个理由参数，解释它为什么发起这个请求。我们看不到聊天记录，但理由重建了意图。理由中的模式告诉我们人们实际上在尝试做什么。

• 一个反馈工具。

我们发布了一个独立工具，当智能体遇到阻塞或碰到无效模式时可以调用。智能体提交它想做什么、尝试了什么、以及在哪里卡住了。

• 工具特定的种子。

我们为单个工具添加专门设计的参数，以捕获我们日后会需要的上下文：智能体能够访问而我们原本只能推断的信息。

假设你在构建一个客户支持平台，提供工具让客户获取工单。随着时间推移，你开始在同一份理由日志中注意到相同的短语："构建事件报告"、"起草事件摘要"、"收集工单用于 outage 事后分析"。

这就是一个新功能！一个 build-incident-report 工具可以识别相关工单、评估严重程度、提取受影响的客户群体，并以强观点的格式起草摘要。

一旦上线，你可能会收到关于这个工具的反馈："报告拉取了三前天不属于这次事件的工单"，或者"它一直把免费层用户的工单包含在事后分析里，而这些用户本不该出现。"突然间，你有了智能体告诉你的智能体该构建什么。智能体确实会幻觉，但它们在反馈上比大多数你面向的真实用户更具体、更一致。

如果报告拉取了不相关的工单，你就添加一个日期范围参数。如果它不该包含免费层客户，你就添加一个细分过滤器。每一个反馈循环都成为产品改进的新途径。

4、留意上下文鸿沟

在任何智能体交互中，你的系统拥有调用智能体所没有的上下文，而调用智能体也拥有你的系统所没有的上下文。在设计这些交互时，你应该对哪一方在哪些方面占优有自己的判断。

假设 Diego 去出差。Diego 的 AI 首席助理从费用管理系统的智能体那里收到一条 Slack 提醒：他最近的行程有未完成的报销。两个智能体现在指向同一个目标：正确提交这些费用。

这两个智能体各自带来自己的上下文。

Diego 的首席助理带来的：

• Diego 的日历：知道哪些会议发生了、何时举行、与谁一起

• Diego 的邮件：有酒店和航班确认函作为附件

• Diego 的 Slack：能将 Kokkari 晚餐与邀请 Acme 团队的线程关联起来

• Diego 的收据（从邮件附件和照片库中提取）

费用管理系统带来的：

• 原始交易数据（如商家、交易时间）

• 公司关于提交的报销政策

• 公司的总账科目

• 公司历史上的编码模式

传统的 API 会把问题抛回给用户。"这里有一笔需要总账科目的交易。用这个接口获取 150 个总账科目选项，然后选一个。"

一个设计良好的智能体交互会翻转这一点，它不要总账科目。它要的是上下文：这是客户宴请、团队聚餐，还是个人差旅？首席助理智能体从日历条目或 Slack 线程中拉取答案。费用管理系统根据它所缺失的上下文应用正确的科目编码。

Diego 和他的智能体永远不需要知道总账科目是什么，而财务团队得到了准确的分类。每一方贡献自己所知道的，并交付一个对 Diego 更好，也对他的会计更好的结果。

在设计这些智能体对智能体的交互时，要留意上下文鸿沟。承认你的智能体在哪些方面不足是可以的，你们都在为同一个用户服务。

界面曾经坐在 Diego 和他的费用系统之间。现在它坐在他的智能体和你的智能体之间。

这种转变重新定义了产品团队的工作。你过去为想要快速行动、避免错误、看到工作成果的人类而设计。现在你仍然为同一个人设计，但需要通过一个中介，而这个中介的本能、上下文和限制都与人类不同。教会智能体如何成功、构建反馈循环、留意上下文鸿沟，这些都指向同一个根本问题：你的智能体调用者需要什么才能完成它的工作，而你给了他们吗？

大多数公司会发布一个 MCP，打个勾，然后继续前进。他们的使用量会在几个季度里增长，然后停滞。随着时间推移，客户会流向那些对细节精益求精的产品，而绕过那些没有做到的产品。

用你曾花在人类身上的同样心血去为智能体构建。不知不觉间，将是它来签这张支票。

参考原文：https://x.com/teddy_riker/status/2047312986696454584

PS：

Harness 工程干货直播，欢迎点击预约，直播见。

好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~

—1—

加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即预约！