为 Agent 设计产品 ✍ 宝玉🕐 2026-04-26📦 13.1 KB 🟢 已读 𝕏 文章列表 本文探讨了软件交互模式的根本性转变,指出未来 80% 的交互将由 AI 智能体完成。文章以 Salesforce 和 Ramp 为例,阐述了如何通过 API、MCP 和 CLI 将产品能力暴露给智能体。作者提出了为智能体设计的三个关键原则:明确规范以教会智能体成功、建立反馈循环以优化产品、以及填补上下文缺口以实现智能体间的协作。 AI Agent产品设计MCPUXLLMAPI智能体交互模式产品经理Salesforce # 为 Agent 设计产品 **作者**: 宝玉 **日期**: 2026-04-23T13:53:47.000Z **来源**: [https://x.com/dotey/status/2048135262606393777](https://x.com/dotey/status/2048135262606393777) ---  原文:Designing for Agents 作者:Teddy Riker 如果你和我一样,经常混在 X 上同一个信息圈里刷动态,那么你大概也见过这种说法:用户界面已经死了。 你会一边刷到“我如何用 Obsidian 搭建第二大脑”,一边刷到“Anthropic 彻底杀死了某某行业”这类帖子。然后很快,你就会看到有人说:一个产品如果不能被 AI 智能体(AI Agent)通过 MCP、API、CLI,或者介于它们之间的方式使用,那它就活不下去。 这个趋势在 Ramp 已经很明显。过去三个月里,随着越来越多客户开始通过 Claude、ChatGPT 和其他 AI 智能体进入我们的产品,我们 MCP 上的每周活跃用户增长了 10 倍。(MCP,Model Context Protocol,模型上下文协议,可以理解为一种让 AI 智能体调用外部工具和数据的标准方式。) 上周,Salesforce 成了最早主动拥抱这个判断的传统软件巨头之一。 来自 https://venturebeat.com/ai/salesforce-launches-headless-360-to-turn-its-entire-platform-into-infrastructure-for-ai-agents: > https://www.salesforce.com/ 周三宣布了这家公司 27 年历史上最激进的一次架构转型,推出了“https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/”——这是一项覆盖整个平台的大计划:把平台里的每一项能力都暴露成 API、MCP 工具或 CLI 命令,让 AI 智能体可以在完全不打开浏览器的情况下操作整个系统。 > 这项发布是在 Salesforce 于旧金山举办的年度 https://www.salesforce.com/tdx/ 大会上宣布的,并且立刻向开发者开放了 100 多个新工具和技能。它也正面回应了一个悬在企业软件头顶的生死问题:当 AI 智能体已经能够推理、规划和执行时,一家公司还需要一个带图形界面的 CRM 吗? > Salesforce 的回答是:不需要——而这正是重点。 Salesforce 这一步很聪明,而且我很难想象这会是一个容易做出的决定。你问大多数销售,他们大概率会告诉你,他们并不喜欢用 Salesforce。但 Salesforce 之所以无处不在,很大一部分原因正是它的用户体验(UX)足够熟悉。销售负责人通常并不想让整个团队重新适应一套新技术;在很多时候,一致性比功能强大更重要。 Benioff 和他的团队正在承认:这条护城河正在被侵蚀。他们也开始主动拥抱一个现实——未来大量使用行为会通过 Claude、ChatGPT 以及其他用户根本看不见的后台流程来完成。 我并不认为用户界面(UI)正在死亡。人类仍然想要点击按钮、查看配置、确认任务已经完成。但二八法则已经反过来了:未来人与软件之间 80% 的交互,都会通过 AI 智能体完成。这不仅会改变你需要构建什么,也会改变你构建它的方式。 ## 新的交互模式 过去二十年里,人们和软件交互的主要方式是: 用户 → 界面 → 数据库 你打开一个产品,点来点去,把事情做完。界面就是你体验软件的方式。对大多数人来说,界面本身就是产品。 但随着 AI 智能体接手越来越多工作,一个新的中间层出现了: 用户 → 用户的 AI 智能体(比如 Claude)→ 数据库 AI 智能体代表用户行动。它读取、写入、浏览产品,这样用户就不用亲自操作。突然之间,界面消失了。智能体开始直接和底层系统对话。  不过,这个模式也在迅速变化。软件公司正在——而且也应该——设计自己的 AI 智能体和能力。所以新的模式更像这样: 用户 → 用户的 AI 智能体 → 软件自己的 AI 智能体 → 数据库 在这个模型里,软件自己的 AI 智能体会替用户的智能体处理复杂性:执行业务逻辑、落实规则、补充后者没有的上下文。两个大语言模型(LLM)一起协作,朝着同一个结果推进。 ## 教会 AI 智能体如何成功 我现在大部分头脑风暴、写作和构思,都是和大语言模型一起完成的。当一篇草稿准备好分享时,我会通过 Notion 的 MCP 服务器把它推到 Notion 里。我曾经是 Google Docs 的忠实用户很多年,但 Notion 的 MCP 改变了我的习惯。 作为 Notion MCP 的用户,我很欣赏的一点是:每次我让 AI 智能体写点什么,它几乎都能一次到位。表格、项目符号、斜体、列表,你能想到的格式,它都不会出错。 这不是偶然,而是设计出来的。 Notion 的 notion-create-pages 工具描述一开始就写着:“如需完整 Markdown 规范,必须先获取 MCP 资源 notion://docs/enhanced-markdown-spec。不要猜测或幻觉 Markdown 语法。”当我让智能体写入一个页面时,它做的第一件事就是获取这份规范。先读规范,再动笔。所有 Notion 特有的假设,都会被明确指出,而不是依赖通用模型的默认理解。 在旧世界里,这类规范会放在 API 文档里。接入 Notion 的开发者会读文档、理解规则,然后写一个转换层。现在,Notion 会在 AI 智能体真正需要的时候,直接把规范交到它手里。 如果你用过 Slack MCP,可能就体验过相反的情况。你的 AI 智能体会默认使用标准 Markdown,却没有遵守 Slack 自己那套特定格式。结果是,你花在修改格式上的时间,可能比自己手写消息还多:  当然,Slack 的格式指南在网上能找到,你也可以把它保存下来,再教你的智能体怎么用。但这很烦,而且本来就不该是用户需要操心的事。 你应该思考:调用你家智能体的人,需要知道什么才能成功?然后主动把这些信息交给它。不要让它自己摸索。  ## 建立反馈循环 当我们刚在 Ramp 发布 MCP 时,最大的问题是可观测性(observability)。我们能看到工具调用量,但看不到触发这些调用的聊天上下文。仅仅知道调用量,并不能告诉我们什么有效、什么坏了、用户到底想完成什么。 后来我们用几种方式解决了这个问题: 每次工具调用都要求填写“理由”。 每一次 MCP 或 CLI 工具调用,都要求 AI 智能体带上一个 rationale 参数,解释它为什么要发起这个请求。我们看不到聊天内容,但这个理由可以重建意图。理由里的模式,会告诉我们用户到底想做什么。 提供一个反馈工具。 我们发布了一个独立工具。当 AI 智能体遇到阻碍,或者发现某种模式行不通时,它可以调用这个工具。它会提交自己原本想做什么、尝试了什么、卡在了哪里。 给特定工具加入上下文种子。 我们会给单个工具加入专门设计的参数,用来捕捉之后会有用的上下文:这些信息智能体能拿到,但如果不主动收集,我们之后只能靠猜。 想象一下,你正在做一个客户支持平台,并提供工具让客户抓取工单。过了一段时间,你开始在理由日志里反复看到类似表达:“正在生成事故报告”“正在起草事故摘要”“正在收集停机复盘相关工单”。 这就是一个新产品功能的信号!你可以做一个 build-incident-report 工具,用来识别相关工单、评估严重程度、拉取受影响的客户群体,并用一种强约束的格式起草摘要。 这个工具上线后,你可能又会开始收到反馈:“报告拉进了三天前的工单,但那些不属于这次事故”,或者“它总是把免费套餐用户的工单也放进复盘里,但这些用户不应该出现在事故复盘中”。突然之间,你的 AI 智能体开始告诉你的 AI 智能体:接下来到底该构建什么。 AI 智能体当然会幻觉。但在反馈这件事上,它们往往比你真正发给产品的多数人类用户更具体,也更一致。 如果报告拉进了无关工单,你就增加一个日期范围参数。如果不该包含免费套餐客户,你就增加一个客户分组筛选器。每一个反馈循环,都会变成产品改进的新入口。  ## 留意上下文缺口 在任何 AI 智能体交互中,你的系统掌握一些调用方智能体不知道的上下文;而调用方智能体也掌握一些你的系统不知道的上下文。设计这些交互时,你应该清楚地判断:哪一方在哪些信息上更有优势。 比如 Diego 去出了一趟差。他的 AI 首席幕僚收到一条来自费用管理系统智能体的 Slack 提醒:他最近这趟出差还有未完成的报销。现在,两个 AI 智能体都指向同一个目标:正确提交这些报销。 这两个智能体各自带着不同的上下文。 Diego 的 AI 首席幕僚知道: - Diego 的日历:知道哪些会议发生了、在什么时候、和谁一起 - Diego 的邮箱:有酒店和航班确认邮件附件 - Diego 的 Slack:能把 Kokkari 那顿晚餐关联到一个他邀请 Acme 团队的对话线程 - Diego 的收据:来自邮件附件和照片图库 费用管理系统知道: - 原始交易数据,比如商户、交易时间 - 公司关于报销提交的政策 - 公司的总账科目(GL accounts)(GL 通常指 General Ledger,也就是财务记账里的总账分类) - 公司过往的费用归类习惯 传统 API 会把问题丢回给用户:“这里有一笔交易需要填写 GL code。请调用这个接口获取 150 个 GL code 选项,然后自己选一个。” 设计得好的 AI 智能体交互会反过来处理这件事——它不会直接索要 GL code,而是索要上下文:这是一顿客户餐、团队餐,还是个人旅行支出?AI 首席幕僚可以从日历条目或 Slack 对话里找到答案。然后费用管理系统根据自己原本缺失的那部分上下文,自动套用正确的科目。 Diego 和他的智能体都不需要知道 GL code 到底是什么。财务团队也能得到准确的分类。双方各自贡献自己知道的信息,最终交付一个对 Diego——也对他的会计——都更好的结果。  当你设计这种智能体到智能体的交互时,一定要留意上下文缺口。承认你的智能体在哪些地方不擅长,是完全可以的——因为你们其实是在服务同一个用户。 过去,界面夹在 Diego 和他的费用系统之间。现在,界面夹在他的智能体和你的智能体之间。 这个变化重新定义了产品团队的工作。过去,你是在为一个想快速完成任务、避免犯错、看得见自己工作的真人设计产品。现在,你仍然是在服务同一个人,只不过中间多了一个代理者。它的直觉、上下文和局限,都和人类不同。 教会 AI 智能体如何成功、建立反馈循环、留意上下文缺口,这三件事背后其实都在问同一个问题:调用你家智能体的一方,到底需要什么才能把工作做好?你有没有把这些东西交给它? 大多数公司会发布一个 MCP,勾上“我们也支持 AI 智能体了”这个框,然后继续往前走。它们的使用量可能会增长几个季度,然后停滞。随着时间推移,客户会流向那些真正打磨细节的产品,也会绕开那些只是敷衍了事的产品。 像当初为人类用户设计产品一样,认真为 AI 智能体设计产品。因为你很快就会发现,最后签支票的,可能正是它。 ## 相关链接 - [@dotey](https://x.com/dotey) - [28K](https://x.com/dotey/status/2048135262606393777/analytics) - [Designing for Agents](https://x.com/teddy_riker/status/2047312986696454584) - [Apr 23](https://x.com/teddy_riker/status/2047312986696454584) - [701K](https://x.com/teddy_riker/status/2047312986696454584/analytics) - [https://www.salesforce.com/](https://www.salesforce.com/) - [https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/”——这是一项覆盖整个平台的大计划:把平台里的每一项能力都暴露成](https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/%E2%80%9D%E2%80%94%E2%80%94%E8%BF%99%E6%98%AF%E4%B8%80%E9%A1%B9%E8%A6%86%E7%9B%96%E6%95%B4%E4%B8%AA%E5%B9%B3%E5%8F%B0%E7%9A%84%E5%A4%A7%E8%AE%A1%E5%88%92%EF%BC%9A%E6%8A%8A%E5%B9%B3%E5%8F%B0%E9%87%8C%E7%9A%84%E6%AF%8F%E4%B8%80%E9%A1%B9%E8%83%BD%E5%8A%9B%E9%83%BD%E6%9A%B4%E9%9C%B2%E6%88%90) - [https://www.salesforce.com/tdx/](https://www.salesforce.com/tdx/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [4:21 AM · Apr 26, 2026](https://x.com/dotey/status/2048135262606393777) - [28.3K Views](https://x.com/dotey/status/2048135262606393777/analytics) - [View quotes](https://x.com/dotey/status/2048135262606393777/quotes) --- *导出时间: 2026/4/26 11:01:59*
为 为 Agent 而设计:交互模式的新演变 文章探讨了在 AI Agent 兴起的背景下,软件交互模式的根本性转变。作者指出,虽然 UI 不会完全消失,但 80% 的交互将转向 Agent。文章以 Salesforce、Notion 和 Ramp 为例,阐述了企业应如何通过提供明确规范、建立反馈机制以及处理上下文差异来设计适应 Agent 时代的软件。 技术 › Agent ✍ Teddy Riker🕐 2026-04-24 Agent设计MCPUI/UXLLM交互模式产品经理SalesforceNotion反馈循环上下文
如 如何构建在你睡觉时管理整个业务的 Claude Agent 文章详细介绍了如何构建一个基于 Claude 的全自动业务管理 Agent,用于在用户休息时自动处理邮件、生成报告、追踪项目和客户线索。核心架构由 Claude(智能层)、CLAUDE.md(业务上下文层)、MCP Servers(连接层)和 N8N(自动化层)组成。教程包含了具体的上下文配置模板(CLAUDE.md)、MCP 服务器配置(Gmail, Notion, Calendar 等)以及六个核心自动化工作流的实施步骤,旨在将业务运营从个人依赖转变为系统化智能运行。 技术 › Agent ✍ CyrilXBT🕐 2026-05-18 ClaudeAI Agent自动化业务管理MCPN8N工作流LLM生产力工具
如 如何构建价值万美元的定制 MCP 服务器:完整课程 本文是一份关于如何从零开始构建并销售定制 MCP(模型上下文协议)服务器的完整指南。文章指出,当前市场对能解决实际业务问题的 MCP 服务器需求巨大,自由职业者单次开发收入可达 5000 至 15000 美元。内容分为三个月的学习路径:首月掌握协议并搭建首个服务器;次月聚焦解决企业内部工具、数据管道等痛点;第三月通过自由职业、产品化销售或企业合同实现变现。文章强调这不仅是技术开发,更是高价值的商业解决方案。 技术 › Agent ✍ Khairallah AL-Awady🕐 2026-05-06 MCPClaudeAI Agent商业模式副业PythonTypeScriptAnthropicAPI自动化
如 如何构建替代首批 3 名员工的 AI 智能体团队 本文为独立创业者提供了一份详细的实操指南,介绍如何利用 Claude、MCP 服务器和智能工作流构建三个 AI 智能体(研究、内容、运营),以低成本替代早期企业所需的全职员工,从而解决人力资源瓶颈并提升效率。 技术 › Agent ✍ Khairallah AL-Awady🕐 2026-05-06 AI AgentClaudeMCP创业自动化工作流提示工程LLM效率工具商业应用
如 如何在 AI Agents 中正确使用 MCP 服务器 文章讨论了 MCP 服务器在 AI Agents 中的应用。盲目启用 MCP 会导致上下文膨胀、成本增加和性能下降。文章提出了两种有效的使用模式:一是显式 MCP 服务器(内联工具注入),通过 @mention 按需加载工具,适合用户驱动的临时需求;二是子代理 MCP 服务器,将 MCP 服务器声明在子代理定义中,利用 allowed_tools 进行最小权限范围限定,适合代码审查或支持代理等特定场景。 技术 › Agent ✍ Philipp Schmid🕐 2026-04-28 MCPAI AgentTool UseLLM架构设计开发指南SubagentClaude
H Hermes Agent 完全上手指南:会自己进化的 AI Agent 这是一份关于 Hermes Agent 的深度上手教程。文章介绍了 Hermes 相比 OpenClaw 的核心优势:具备自我进化能力,能从任务中自动创建和优化 Skills,以及拥有强大的 SQLite 全文搜索记忆系统。教程涵盖从环境准备、安装配置、基础对话,到进阶的消息网关配置、定时任务、记忆训练,再到高级的 MCP 服务器集成、多 Profile 管理、浏览器自动化及语音交互等 15 个实践任务,帮助用户全面掌握这一开源 AI Agent 框架。 技术 › Hermes ✍ OneHopeA9🕐 2026-04-22 AI AgentHermesOpenClaw自我进化记忆系统MCP教程自动化SQLiteLLM
为 为什么 BestBlogs 开始按 Agent Native 来设计开放能力 文章阐述了阅读产品 BestBlogs 重新设计开放能力的核心理念——Agent Native。作者认为未来的阅读不应局限于单一 App,而应融入用户的完整工作流,支持被智能体(Agent)调用与组合。为此,BestBlogs 开放了 OpenAPI、CLI 和 Skills 三层能力,致力于将阅读过程拆解为可复用的“原语”,从而让内容消费变得更加灵活、可解释且可编程。 技术 › Agent ✍ ginobefun🕐 2026-04-20 Agent NativeAPI开放能力工作流CLISkills产品设计智能体BestBlogs原语化
如 如何设计 AI Agent:思维模型与实体化 文章提出 AI Agent 应被视为“思维与身体”的结合。单纯依赖大模型能力的 Agent 难以体现价值,唯有通过构建包含身份、资产、感知和限制的“身体”结构,将无界的智能具象化,才能解决用户痛点,避免沦为单纯的套壳聊天机器人。 技术 › Agent ✍ Will Chen🕐 2026-07-25 AI Agent产品设计思维模型大模型应用SaaS
V Video Agent:基于 HeyGen 的视频生成智能体 文章介绍了 HeyGen 推出的 Video Agent 产品。这是一个无需代码、通过自然语言交互即可自动生成完整视频的智能体。用户只需描述需求,Agent 便会自动规划、编剧、选角并生成视频,支持风格定义和后期精细编辑。 技术 › Agent ✍ HeyGen🕐 2026-07-24 HeyGen视频生成AIGC智能体自动化视频编辑产品设计
6 60个AI黑话,一次性翻译成人类语言 文章将60个AI行业专业术语进行了通俗易懂的翻译和解释,涵盖基础概念、训练调优、推理交互、工具扩展、评估安全及前沿趋势六个方面,帮助读者快速理解AI技术地图。 技术 › LLM ✍ 概率鹿梦|AI Wealth Edge🕐 2026-07-22 AI术语大模型智能体AgentLLM科普翻译基础知识
C Claude + Obsidian,你数百条死笔记,瞬间变成帮你思考的第二大脑 本文介绍了一种结合 Claude 和 Obsidian 的知识管理方案,通过自动化提取、链接和归档,将死笔记转化为可交互的第二大脑,支持全文检索和引用,帮助知识复利增长。 技术 › 工具与效率 ✍ 老白(每日 AI 干货)🕐 2026-07-22 ClaudeObsidian知识管理第二大脑笔记MCP自动化LLMMarkdown效率
C Claude Skills: 如何通过 Anthropic 的新功能节省 Token 并提升效率 文章介绍了 Anthropic 推出的 Claude Skills 功能,通过文件夹和 YAML 配置实现渐进式披露,显著减少 Token 消耗和重复解释。详细说明了技能的构建规则、命名规范、测试方法及分发策略,帮助用户将聊天机器人转化为高效的专业工程团队。 技术 › Skill ✍ Mr. Buzzoni🕐 2026-07-17 ClaudeSkillTokenAnthropicDevOps工具与效率LLMMCPAgent