要为智能体设计产品而非人:论软件交互新范式

这波儿人工智能浪潮正在改变着我们周围的许多事情，如：“SaaS已死？！！”，“AI时代下，互联网ToC那一套玩不转了，要从ToB里找机会，开始推进！”，“Anthropic公司每发布一个产品或者一个功能，都颠覆一个行业”。。。这类声音不绝于耳。

这里，先问大家一个问题或习惯的改变，看是否这一转变小伙伴们跟我一样：

大家是不是和我一样：不像之前，频繁使用，如百度，必应和谷歌等搜索引擎了！？转而都提交自己的问题给豆包，Deepseek等这类网页为入口的智能体，以及工具类智能体如OpenClaw&Hermes,和Claude Code&OpenCode等(提一嘴：别再找借口说你是非技术人员不学着用它们，尤其是公司领导们 🙂 ) !？？？

是的，入口变了！不仅是搜索引擎，还有软件，服务等也是。它们的入口都或多或少被统一到Claude Code这类智能体上去了。那进一步想想看，这背后肯定涉及到相关联的其他变化。

这不，这两天逛X平台关注到，AIGC大佬-宝玉(应该有一部分小伙伴用过他的技能包或者受益过他写的blog吧！？如下截图)，他转发评论并长文翻译了Teddy Riker一篇文章《Design for Agents》，对的，咱们的系统和产品的设计也要变，也要往上面“靠”了！

宝玉评语：如果你花时间在我所在的X那个角落，划过那些「我是如何用 Obsidian 构建第二大脑」和「Anthropic 刚刚杀死了 [某个行业]」的帖子，你大概也看到过这个观点：UI 已死。除非一个产品可以通过 MCP、API、CLI 或其他方式被 Agent 使用，否则它无法生存。

这个趋势在 Ramp 已经很明显。过去三个月里，随着越来越多客户开始通过 Claude、ChatGPT 和其他 AI 智能体进入我们的产品，我们 MCP 上的每周活跃用户增长了 10 倍。

上周，Salesforce 成了最早主动拥抱这个判断的传统软件巨头之一。。。

Teddy Riker:从「为人设计」到「为 Agent 设计」— 软件产品的下一个范式转变

这是Teddy Riker在X平台上发布的一篇关于「为 Agent 设计产品」的长文。Teddy Riker 是谁？他之前分享过一篇关于「Agentic 软件工程」的深度文章（在之前的博文里我们也整理过相关内容），这次他把视角从「工程师怎么用 Agent」转向了「产品经理和创始人该怎么为 Agent 设计产品」。

这篇文章的核心命题是：当软件的主要使用者从人类变成智能体，产品的设计逻辑需要彻底重建。而大多数公司只会「发布一个 MCP，打个勾，然后继续」——他们的用量会在几个季度后停滞。只有那些真正在细节上投入的产品，才会最终赢得 Agent 的「选票」。

下面是我分享给大家的本人对Teddy Riker这篇文章内容的整理以及深度解读！

一、趋势已经来了，而且比你想象的更快

Teddy分享了一个来自Ramp（他所在的公司的真实数据）：

在过去的三个月里，我们 MCP 的周活跃用户增长了 10 倍——越来越多的客户通过 Claude、ChatGPT 和其他 Agent 来接入产品。

这个数字本身就说明了问题：当用户开始习惯于「让 Agent 帮我做事」，他们不再自己打开浏览器操作软件，而是让 Agent 去连接 API 和 MCP。

更重磅的例子来自 Salesforce。

Salesforce 在上周发布了「Headless 360」计划——这是他们 27 年历史上最雄心勃勃的架构转型。他们把平台上的每一项能力都暴露为 API、MCP 工具或 CLI 命令，让 AI Agent 可以在不需要打开浏览器的情况下操作整个系统。首批上线了 100 多个新工具和技能。

Salesforce 的回答很直接：是的，图形界面不再需要——这正是重点。

Teddy 评价说这是 Salesforce 的聪明之举，而且他很难想象这个决定做起来有多容易。大多数销售人员会告诉你他们有多讨厌使用 Salesforce——但这个产品之所以无处不在，是因为 UX 带来的熟悉感。销售负责人对让团队学习新技术没有兴趣，一致性往往胜过功能性。

但现在，Salesforce 承认这个护城河正在被侵蚀，他们接受了一个现实：未来的大部分使用量将由 Agent 驱动，用户甚至永远不会看到浏览器里发生了什么。

二、交互模式的演变：从三层到五层

Teddy给出了过去20年软件交互的基础模式，然后展示了它正在如何演变。

旧的模式：三层

用户 → 界面 → 数据库

你打开一个产品，点来点去，把事情做完。界面就是你体验软件的方式。对大多数人来说，界面就是产品本身。

过渡模式：用户 Agent 加入

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

Agent 代表用户行动。它阅读、写入、在产品中导航，用户不需要自己做这些事。突然间，界面消失了——Agent 正在直接和系统底层对话。

新的模式：双 Agent 层

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

这是正在快速出现的新模式。软件公司（也应该）在设计自己的 Agent 和能力。在这个模型里，软件的 Agent 代表用户的 Agent 处理复杂性：应用业务逻辑、执行规则、获取用户 Agent 没有的上下文。两个 LLM 协同工作，推进一个结果。

这意味着产品经理的 job description 需要被重新定义。

三、核心原则一：教会 Agent 如何成功

Teddy用Notion的MCP作为正面例子。

他自己是 Google Docs 的忠实用户很多年，但 Notion 的 MCP 让他彻底转换了：

当我让 Agent 写东西时，每次都完美——表格、项目符号、斜体、列表，要什么有什么，从不出错。

这不是偶然，这是 Notion 的有意设计。

notion-create-pages 工具的描述，开篇就是：

「要获取完整的 Markdown 规范，请首先获取位于 notion://docs/enhanced-markdown-spec 的 MCP 资源。不要猜测或臆造 Markdown 语法。」

当Agent被要求写入一个页面，它第一件事就是获取规范，然后才写作。每个 Notion 特定的假设都会对照通用模型的默认值被明确标注出来。

Teddy 把这个原则总结为：

主动提供给你的 Agent 的调用者需要知道成功所需的信息。不要让他们自己去搞明白。

相比之下，如果你用过Slack MCP，你大概经历过相反的情况：Agent 默认使用标准Markdown，而不是 Slack 的特定格式。你最后花在编辑格式上的时间比你自己写消息的时间还多。

这说明什么？

Slack 的格式指南是在线的，你可以保存它们并教你的 Agent 怎么用。但这是烦人的，而且不应该是必要的。好的设计不需要用户额外学习。

四、核心原则二：建立反馈循环

这是 Teddy 分享的最有见地的部分——他来自 Ramp 的真实实践。

Ramp 在 MCP 刚上线时，最大的问题是可观测性。他们能看到工具调用量，但看不到产生这些调用的对话上下文。光看调用量，无法知道什么在运作，什么在出问题，人们真正试图完成什么。

他们通过三种方式解决：

方式一：每个工具调用都要求填写「理由」（Rationale）

每个 MCP 或 CLI 工具调用都要求 Agent 包含一个 rationale 参数，解释它为什么提出这个请求。Ramp 看不到对话，但 rationale 可以重建意图。

rationale 里的模式，就是用户真正在试图做什么。

方式二：一个反馈工具

他们发布了一个独立的工具，Agent 在被阻塞或遇到不工作的模式时可以调用。Agent 提交它尝试做什么、它尝试了什么，以及在哪里卡住了。

这提供了一个系统性的「我知道我搞不定」信号。

方式三：工具特定种子参数

他们在每个单独的工具上添加了专门设计的参数，用来捕获他们之后会想要的上下文——那些 Agent 有访问权限但 Ramp 原本无法推断的东西。

反馈循环如何驱动产品开发

Teddy 举了一个具体的例子：

想象你正在构建一个客户支持平台，你提供了让客户获取工单的工具。慢慢地，你开始在 rationale 日志里注意到同一个短语反复出现——「构建事故报告」「起草事故摘要」「收集停电复盘的相关工单」。

这是一个新产品的功能信号！

一个 build-incident-report 工具可以识别相关工单、评估严重性、提取受影响的客户群，并起草一份带有强烈观点的摘要格式。一旦这个工具上线，你可能开始收到关于它的反馈——「报告拉进了三天前的工单，不属于这次事故」「它一直包含免费层用户，不应该出现在复盘里」。

突然之间，你有了 Agent 在告诉你的 Agent 应该构建什么。

Agent 会产生幻觉，没错。但比起大多数你可能会发布功能时收到的人类反馈，Agent 的反馈更具体、更一致。

如果你训练 Agent 在创建报告时加入日期范围参数（排除不相关的工单），以及客户群过滤（排除免费层用户），每一个反馈循环都变成了产品改进的新路径。

五、核心原则三：注意上下文鸿沟

这是整篇文章最精彩的概念框架。

Teddy 描述了一个典型的双 Agent 交互场景：

Diego 要去出差。他的 AI 首席助理收到了来自差旅管理系统的 Agent 发来的 Slack 提醒：他最近那次出差有未提交的报销。现在两个 Agent 都指向同一个目标：把这些费用正确提交。

两个 Agent 各有各的上下文：

Diego 首席助理 Agent 带来的：

Diego 的日历：知道哪些会议发生、何时、与谁
Diego 的邮件：有酒店和航班确认单作为附件
Diego 的 Slack：可以把 Kokkari 的晚餐关联到一个他邀请了 Acme 团队的 thread
Diego 的收据（从邮件附件和照片库中提取）

差旅管理系统带来的：

原始交易数据（商户、交易时间）
公司关于提交的政策
公司的 GL 代码（总账科目）
公司历史编码模式

传统 API 会把问题丢回给用户：

「这里有一笔需要 GL 代码的交易。使用这个端点获取 150 个 GL 代码选项，然后选一个。」

设计良好的 Agent 交互反过来了——它不要求 GL 代码，而是要求上下文：

「这是一次客户用餐、团队用餐，还是个人旅行？」

首席助理 Agent 从日历条目或 Slack thread 中获取答案。差旅管理系统根据它所缺少的上下文应用正确的代码。

Diego 和他的 Agent 永远不需要知道 GL 代码是什么，而财务团队得到了准确的分类。 每一方贡献它所知道的，交付一个对 Diego（和他的会计师）都更好的结果。

Teddy 把这个原则总结为：

在设计 Agent 与 Agent 的交互时，要注意上下文鸿沟。在你的 Agent 不擅长的地方承认它是可以的——你们都在为同一个用户服务。

六、旧的界面曾经隔在Diego和他的差旅系统之间。现在它隔在他的Agent和你的Agent之间。

这个重新表述改变了产品团队的工作定义。

过去：为一个想要快速行动、避免错误、看到工作成果的人设计现在：为同一个人通过一个中介来设计        ——这个中介的直觉、上下文和局限都与用户不同

这意味着产品经理现在需要思考的不只是「用户需要什么」，还要思考「用户的 Agent 需要什么才能把事情做好」——并主动提供给它。

七、那些会失败的公司，和那些会赢的公司

Teddy 在文章结尾给出了一个清晰的预测：

大多数公司会发布一个 MCP，打个勾，然后继续。他们的用量会增长几个季度，然后停滞。随着时间推移，客户会把流量导向那些在细节上精雕细刻的产品，而不是那些没有的。

所以他的最后一句话是：

用你曾经在人类身上投入的同样细致来为 Agent 构建产品。不用多久，它就会成为那个写支票的人。

附：三个核心设计原则速查

原则一：Teach agents how to succeed（教会 Agent 如何成功）  → 在工具描述里主动提供 Agent 需要知道的所有假设  → 不要让 Agent 去猜或去读 API 文档才理解  → 例子：Notion 的 MCP：「先获取规范，再写，不要猜」原则二：Build feedback loops（建立反馈循环）  → 要求每个工具调用填写 rationale（重建意图）  → 提供反馈工具让 Agent 被阻塞时可以报告  → 用 rationale 日志里的重复短语驱动新功能开发  → 每个反馈循环都是一个产品改进的输入原则三：Mind the context gap（注意上下文鸿沟）  → 承认你的 Agent 有哪些上下文是它没有的  → 不要要求用户知道那些你系统里才有的术语（GL代码等）  → 设计从「要求输入」变成「要求上下文」  → 两个 Agent 各贡献自己有的东西，交付对用户更好的结果

欢迎点赞，转发，推荐，评论，加关注！！

参考资料

原文来自 Teddy Riker @teddy_riker Note Tweet《Designing for Agents》，2026 年，获 73 万次浏览、1569 赞。Teddy Riker 是Ramp的产品经理，专注于 AI Agent 产品设计和开发者体验。