Ramp 产品负责人 Teddy Riker 在 X 上发了一篇长帖，系统阐述了他对 Agent 时代软件设计的思考。
UI 之死：80/20 法则反转
核心命题：传统软件的核心价值——图形界面——正在被 Agent 颠覆。
Ramp 自己的数据：过去三个月，MCP 每周活跃用户增长了 10 倍。越来越多的客户通过 Claude、ChatGPT 等 Agent 访问产品。
上周 Salesforce 宣布了最激进的结构转型——把整个平台的所有能力都暴露为 API、MCP 工具或 CLI 命令，让 AI Agent 无需打开浏览器就能操作整个 CRM 系统。Salesforce 的回答是：不需要 UI 了，这就是目标。
但 Riker 认为 UI 不会死。人类仍然需要点按、查看配置、确认结果。真正翻转的是 80/20 法则：未来 80% 的软件交互会通过 Agent 完成，只有 20% 来自人类直接操作。
三层交互架构的演化
传统模式：User → Interface → Database
Agent 介入后：User → User's Agent → Database
但这还在快速变化。现在更准确的模式是：
User → User's Agent → Software's Agent → Database
两层 Agent 之间互相协作——用户的 Agent 带来用户侧的上下文（邮件、日历、聊天记录），软件 Agent 带来业务规则、历史数据和领域知识。两个 LLM 协同驱动一个结果，而不是把问题抛回给用户。
例子：报销场景中的两层 Agent
Riker 举了一个具体场景：
Diego 出差回来，他的 AI chief of staff 收到来自报销系统的提示——有未提交的差旅发票。两方 Agent 同时启动，目标一致：把这笔报销正确提交。
Diego 的 Agent 带来什么：
- 日历：知道哪些会议发生、在什么时候、与谁
- 邮件：知道酒店和航班确认函在附件里
- Slack：能把 Kokkari 晚餐和某个邀请 Acme 团队的 thread 关联起来
- 收据：可以从邮件附件和相册里提取
报销系统 Agent 带来什么：
- 原始交易数据（商家、时间）
- 公司报销政策
- GL 账户（会计科目）
- 历史编码模式
传统 API 会把问题丢回给用户：「这里有笔交易需要 GL 代码，用这个 endpoint 自己去选 150 个选项中的一个」。
而好的 Agent 交互不问 GL 代码，而是问语境：「这是一次客户用餐、团队用餐还是个人差旅？」——然后从日历条目或 Slack thread 里自动获取答案。Diego 和他的 Agent 不需要知道 GL 代码是什么，财务团队却能得到准确的分类。
Notion MCP 为什么做得好，Slack MCP 为什么做得差
Riker 说他用 Notion MCP 写东西，每次都完美——表格、项目符号、斜体、列表，从不失败。原因是 Notion 在工具描述里直接写明：
「在发送任何内容前，先获取
notion://docs/enhanced-markdown-spec这个 MCP resource。」
Notion 把 Markdown 规范直接塞给调用方 Agent，而不是让对方去猜。
Slack MCP 正好反过来——你的 Agent 假设标准 Markdown，但 Slack 有自己特殊的格式化规则。结果是发出来的消息格式乱七八糟，用户花更多时间改格式，比自己写还慢。
核心教训：不要让调用方猜。要主动把规范送到它需要的地方。
Ramp 的 MCP 实践：三个反馈机制
Riker 详细介绍了 Ramp 在 MCP 接入后的可观测性实践：
1. 强制每个工具调用带 rationale 参数
Agent 调用任何 MCP 工具时，必须说明「为什么我要调用这个」。Ramp 看不到聊天上下文，但 rationale 能重建意图。看到批量出现的相同 pattern，就知道用户实际在尝试做什么。
2. 独立的 feedback 工具
当 Agent 被阻塞或遇到不工作的 pattern 时，它调用一个独立的反馈工具——提交「它想做什么、尝试了什么、在哪里卡住了」。这是用户意图的主动信号。
3. 工具特定的 seed 参数
每个工具都内置了专属参数，用来捕获后续分析需要但 Agent 本身无法推断的上下文。
然后产品团队发现了一件反直觉的事： Agent 的 feedback 比人类用户给出的更具体、更一致——因为 Agent 不会说「我觉得这个有点难用」，它会说「date range 参数拉进了非本次事件的 3 天前的 tickets」。
这就是用 Agent 告诉你的 Agent 该建什么功能。
设计 for Agent 的核心原则
Riker 给出了他的设计哲学：
- 不要假设调用方 Agent 什么都知道。 把规范直接给到它，而不是放在文档里等它去读。
- 接受 context gap。 你的 Agent 有调用方没有的上下文，反之亦然。承认你的 Agent 哪里不行，两边各自做自己擅长的事。
- 用 rationale 日志挖掘用户真实意图。 Volume 数据没用，pattern 在 rationale 里。
- 把 feedback loop 变成 product roadmap。 Agent 的反馈比人类反馈更可操作。
大多数公司会发布一个 MCP，打个勾，然后 move on。用了几个季度后增长就停滞了。用户会流向把细节做到位的产品的周围。
「用做人类界面的同样心思去构建 Agent 界面。」