摘要：作者认为 80% 的软件交互即将通过 agent 完成，产品需重新为「人通过 agent」而设计。三个实操原则：把使用说明写进 tool description、用 rationale 与反馈机制让看不见的 chat 漏出用户意图、双方各贡献独有 context 而非把决策推回上游。
如果你和我刷的是 X 上同一个角落——一路划过「How I built a second brain with Obsidian」和「Anthropic just KILLED [某个行业] FOREVER」这类帖——你大概也见过这个判断：UI 已死。除非一个产品能被 agent 通过 MCP、API、CLI 或介于其间的什么东西用上，否则它撑不下去。
这个趋势在 Ramp 是真的。过去三个月，我们 MCP 的周活用户涨了 10 倍——越来越多客户通过 Claude、ChatGPT 和其他 agent 在使用产品。
上周，Salesforce 成了最早开始押注这个判断的老牌厂商之一。
引自 VentureBeat ：
Salesforce 周三公布了它 27 年历史上最雄心的架构变革，推出「Headless 360 」——一项覆盖全栈的举措，把它平台上的每一项能力都暴露为 API、MCP tool 或 CLI 命令，好让 AI agent 不打开浏览器就能操作整个系统。
这则消息是在 Salesforce 在旧金山举办的年度 TDX 开发者大会 上发布的，一次性发布了 100 多个新 tool 和 skill，开发者立即可用。这是对悬在企业软件头顶那个生死攸关的问题的一次决断性回应：在 AI agent 能推理、能规划、能执行的世界里，一家公司还需不需要一套带 GUI 的 CRM？
Salesforce 的回答：不需要——而这恰恰就是要点。
这是 Salesforce 一次聪明的动作，我难以想象做这个决定有多不容易。问大多数销售，他们会告诉你他们有多不想用 Salesforce。但这个产品之所以无处不在，是因为它的 UX 大家都用熟了。销售老大们没兴趣让团队上手新技术——一致性常常压过功能性。
Benioff 和他的团队正在承认这条护城河在被侵蚀，并接纳一个现实：未来大多数使用量会由 Claude、ChatGPT 这类 agent，以及其他用户根本看不到的后台进程驱动。
我不认为 UI 在死掉。人类仍然想去点击、想看自己的配置、想验证已经完成的工作。但 80/20 已经翻转了：新的那 80% 的软件交互会通过 agent 完成。这不仅改变了你要造什么，也改变了你怎么造。
新的交互模式
过去二十年，人们与软件交互的主要方式一直是：
User → Interface → Database
你打开一个产品、到处点点、把事做完。界面就是你对软件的体验。对大多数人来说，界面 就是 产品。
随着 agent 接手更多工作，一个新的层出现了：
User → User’s Agent (e.g. Claude) → Database
Agent 代表用户行动。它替用户去读、去写、在产品里跳转。突然之间，界面消失了——agent 直接和底下的系统对话。
但这一层也在快速变。软件公司正在（也应该）设计自己的 agent 与能力。所以新的模式更像是这样：
User → User’s Agent → Software’s Agent → Database
在这个模式里，软件方的 agent 替用户方的 agent 处理复杂性：应用业务逻辑、强制执行规则、补上对方没有的 context。两个 LLM 协作推动一个结果落地。
教 agent 怎么把事做成
我大多数头脑风暴、写作和构思都是和 LLM 一起完成的。一份草稿到了可以拿出来分享的状态，我就通过 Notion 的 MCP server 推过去。多年来我都是 Google Docs 死忠；Notion 的 MCP 把我策反了。
作为 Notion MCP 的用户，我特别欣赏的一点是：每次让 agent 写点什么，它都能搞定。表格、要点、斜体、列表——你说得出的格式，agent 从不翻车。
这是有意为之的。
notion-create-pages 这个 tool 的描述开头就写着：「For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax.」当我让 agent 往一个 page 写东西时，它第一件做的就是这个：先取规范，再写。每一个 Notion 自家的约定都被明确标出来，盖过通用模型的默认行为。
在旧的世界里，这份规范本来会躺在 API 文档里，做集成的开发者会去读、消化、再写一个转换层。现在 Notion 把规范直接交给 agent，正好在它需要的时候。
如果你用过 Slack 的 MCP，你大概体验过相反的情形。你的 agent 默认按标准 markdown 来写，根本不知道要遵守 Slack 自家的格式约定。最后你花在改格式上的时间，比你直接写正文还多：
当然，那些格式规范都在网上能查到，你可以存下来再教 agent 怎么用。但这太烦了——这本就不该是必要的事。
想想你的 agent 的调用方需要知道什么才能把事做成，然后主动给到它。不要让它自己摸索。
建反馈回路
我们在 Ramp 第一次上线 MCP 的时候，可观测性是我们最大的问题。我们能看到 tool call 的总量，但看不到产生这些 call 的 chat context。只看总量，根本说不清什么在 work、什么在 break、人们到底想达成什么。
我们用几种方式解决了这个问题：
- 每次 tool call 都强制带一个 rationale。所有 MCP 或 CLI 的 tool call 都要求 agent 带一个 rationale 参数，解释它为什么发起这个请求。我们看不到 chat，但 rationale 把意图重建了出来。rationale 里反复出现的模式会告诉我们人们到底想做什么。
- 一个 feedback tool。我们上线了一个独立的 tool，agent 卡住了或者撞上一个跑不通的模式时可以调用它。agent 提交它想做什么、试过什么、卡在哪。
- Tool 级别的 seed 参数。我们在单个 tool 上加了一些专门设计的参数，用来抓住后面会想要的 context：那些 agent 本来就有、但我们之后只能靠推断才能拿到的信息。
想象你在做一个客户支持平台，对外提供 tool 让客户拉取 ticket。慢慢地，你在 rationale 日志里看到同一些短语反复出现：「building an incident report」、「drafting incident summary」、「gathering tickets for an outage postmortem」。
这就是一个新的产品功能！一个 build-incident-report 的 tool 可以识别相关 ticket、评估严重程度、拉出受影响的客户群、再按一种强约束的格式起草摘要。
一旦它上线，你可能开始收到关于它的反馈：「the report pulled in tickets from three days ago that weren’t part of this incident」，或「it keeps including tickets from free-tier users who don’t belong in postmortems」。突然之间，你拥有了一群 agent 在告诉你的 agent 该建什么。Agent 会出现幻觉，没错。但它们的反馈也比你曾经面向过的大多数人类更具体、更稳定。
报告拉了无关的 ticket？加一个时间范围参数。不该包含免费版客户？加一个客户分段过滤。每一个反馈回路都成了产品改进的新通道。
留心 context gap
任何 agent 间的交互里，你的系统拥有调用方 agent 没有的 context，调用方 agent 也拥有你的系统没有的 context。设计这类交互时，你应该对「谁在哪一块占优」有自己的判断。
假设 Diego 出差去了。Diego 的 AI chief of staff 在 Slack 上收到差旅报销系统 agent 的提醒：他这趟出差还有报销没填完。现在两个 agent 同时指向同一个目标：把这些报销正确地提交。
这两个 agent 各自带了自己的 context。
Diego 的 chief of staff 带来的：
- Diego 的日程：知道哪些会议发生过、在什么时候、跟谁
- Diego 的邮箱：附件里有酒店和航班的确认信
- Diego 的 Slack：可以把 Kokkari 那顿饭和他邀请 Acme 团队的某条 thread 关联起来
- Diego 的发票（从邮件附件和相册里拉来）
报销系统带来的：
- 原始交易数据（商户、交易时间等）
- 公司关于提交的政策
- 公司的 GL 账户
- 公司历史上的入账模式
传统的 API 会把问题甩回给用户：「这有一笔交易需要一个 GL code。用这个 endpoint 去拉那 150 个 GL code 选项，然后挑一个。」
一个设计得好的 agent 交互把这翻过来——它不要 GL code。它要 context：这是客户餐、团队餐，还是个人出行？chief of staff agent 从一条日历条目或一条 Slack thread 里把答案拉出来。报销系统拿到它原本缺的 context，自己套上正确的 code。
Diego 和他的 agent 从头到尾不需要知道 GL code 是什么，财务团队拿到的也是准确的归类。两边各贡献自己知道的，交付一个对 Diego——也对他会计——都更好的结果。
当你在设计这种 agent-to-agent 的交互时，留心那个 context gap。承认你的 agent 在哪些地方差点意思是没问题的——你们两边在服务同一个用户。
界面以前坐在 Diego 和他的报销系统中间。现在它坐在他的 agent 和你的 agent 中间。
这一个转变重新定义了产品团队的工作。你过去是在为这样的人设计：他想跑得快、想避免出错、想亲眼看见自己的工作。现在你还在为同一个人设计，但隔着一个中间人——这个中间人的直觉、context 和限制都和那个人不一样。教 agent 怎么把事做成、建反馈回路、留心 context gap，问的都是同一个底层问题：你 agent 的调用方需要什么才能把它的活干好，你给到它了吗？
多数公司会发一个 MCP、把那一栏打个勾、然后就走了。它们的使用量会涨几个季度，然后停滞。时间一长，客户会绕到那些把细节做扎实了的产品上去，绕开没做的。
用你曾经对待人类的那份用心去为 agent 设计。等你回过神来，签支票的就是它了。
