原文：Designing for Agents：
本文章由我自己 Notion Agent「翻译家 Prompt」翻译完成，使用 GPT 5.5。
人类没有任何介入。你可以对比 AI KOL 宝玉翻译的作品，看看效果怎么样：
如果你和我一样，常在 X 的同一个角落里刷帖，一边划过「我是如何用 Obsidian 搭建第二大脑」之类的分享，一边又看到「Anthropic 刚刚彻底杀死了【某个行业】」这样的惊悚标题，那你大概也见过一种说法：UI 已经死了。
除非一个产品能通过 MCP、API、CLI，或介于其间的某种方式被代理（Agent）使用，否则它就活不下去。
这个趋势在 Ramp 身上是真实存在的。过去三个月里，我们 MCP 的周活跃用户增长了 10 倍。越来越多客户开始通过 Claude、ChatGPT 和其他代理进入产品。
上周，Salesforce 成为最早正面拥抱这一判断的老牌巨头之一。
来自 VentureBeat：
Salesforce 于周三宣布了其 27 年历史中最雄心勃勃的一次架构转型，推出「Headless 360」。这是一项大规模计划，旨在把 Salesforce 平台中的每一种能力，都暴露为 API、MCP 工具，或 CLI 命令。这样一来，AI 代理就能操作整个系统，而不必打开浏览器。*
这项公告发布于 Salesforce 在旧金山举行的年度 TDX 开发者大会。Salesforce 立刻向开发者开放了 100 多个新工具和技能。这也标志着它对企业软件头顶那个存在主义问题，给出了一个明确回应：在一个 AI 代理能够推理、规划和执行的世界里，一家公司还需要带图形界面的 CRM 吗？
Salesforce 的回答是：不需要。而这正是重点所在。
Salesforce 这一步很聪明，而且我几乎可以想象，这个决定并不容易。问问大多数销售人员，他们大概都会告诉你，自己有多不喜欢用 Salesforce。但这个产品之所以无处不在，靠的正是那套用户体验带来的熟悉感。销售负责人并不热衷于让团队重新学习一套新技术。很多时候，一致性胜过功能性。
Benioff 和他的团队正在承认，这条护城河正在被侵蚀。他们选择顺势而为，接受一个现实：未来大多数使用，都将由 Claude、ChatGPT 和其他用户看不见的后台进程来驱动。
我并不认为 UI 正在死亡。人类仍然想要点击，想要看见自己的配置，也想要核对工作是否完成。但 80/20 的比例已经翻转。未来与软件互动的新 80%，将通过代理发生。这不仅改变了你需要构建什么，也改变了你该如何构建。
新的交互模式
过去二十年里，人们与软件互动的主要方式大致是：
用户 → 界面 → 数据库
你打开一个产品，到处点击，然后完成任务。界面就是你体验软件的方式。对大多数人来说，界面就是产品本身。
随着代理接手越来越多工作，一个新的层级出现了：
用户 → 用户的代理（例如 Claude） → 数据库
代理代表用户行动。它读取、写入、穿行于产品之中，于是用户不必亲自操作。忽然之间，界面消失了。代理直接在和底层系统对话。
但连这一点也正在迅速变化。软件公司正在，也应该，设计自己的代理与能力。因此，新的模式更像是：
用户 → 用户的代理 → 软件自身的代理 → 数据库
在这个模型里，软件自身的代理会替用户的代理处理复杂性：执行业务逻辑，落实规则，调取后者没有掌握的上下文。两个大语言模型（LLM）彼此协作，一起向结果推进。
教会代理如何成功
我的大多数头脑风暴、写作和构思，都和 LLM 一起完成。等一篇草稿准备好分享时，我会通过 Notion 的 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 自己的格式要求。最后，你花在修改格式上的时间，可能比自己写一遍还多：
当然，那些格式指南也许在线上能找到。你也可以把它们存到某个地方，再教你的代理如何使用。但这很麻烦，而且本不该如此。
想清楚调用你代理的人需要知道什么，才能顺利完成任务。然后，主动把这些东西交给它。不要让它自己摸索。
建立反馈回路
我们刚在 Ramp 推出 MCP 时，最大的难题是可观测性（Observability）。我们能看见工具调用量，却看不见触发这些调用的聊天上下文。单看数量，并不能告诉我们什么奏效了，什么坏掉了，也不能告诉我们用户到底想完成什么。
我们用几种方式处理了这个问题：
要求每一次工具调用都带上「理由」。 每一次 MCP 或 CLI 工具调用，都要求代理提供一个
rationale参数，说明它为什么发起这个请求。我们看不见聊天本身，但理由可以重建意图。理由中的模式，会告诉我们，人们究竟在试图做什么。一个反馈工具。 我们发布了一个独立工具。当代理卡住，或遇到某种行不通的模式时，它可以调用这个工具。代理会提交自己原本想做什么，尝试过什么，又卡在了哪里。
面向具体工具的上下文种子。 我们会给单个工具加入专门设计的参数，用来捕捉未来可能需要的上下文。这些信息是代理已经掌握的，但如果不提前收集，我们之后只能靠猜。
想象你正在构建一个客户支持平台，并提供一些工具，让客户获取工单。过了一段时间，你开始在理由日志里反复看见类似短语：「正在构建事故报告」「正在起草事故摘要」「正在收集宕机复盘所需工单」。
这就是一个新的产品功能！一个 build-incident-report 工具，可以识别相关工单，评估严重程度，拉取受影响的客户群体，并按照一套强主张的格式起草摘要。
等这个工具上线之后，你也许会开始收到关于它的反馈：「这份报告拉入了三天前的工单，它们并不属于这次事故」，或者「它总是把免费层用户的工单也放进复盘，而这些用户不该出现在里面」。突然之间，你的代理正在告诉你的代理，接下来到底该做什么。代理当然会幻觉。但它们给出的反馈，往往比大多数真人用户更具体，也更稳定。
如果报告拉入了无关工单，你就加入日期范围参数。如果不该包含免费层客户，你就加入客户分层过滤器。每一个反馈回路，都会变成产品继续进化的新路径。
留意上下文缺口
在任何代理互动中，你的系统掌握着调用方代理没有的上下文，而调用方代理也掌握着你的系统没有的上下文。设计这类互动时，你应该清楚判断，哪一边在哪些地方更有优势。
假设 Diego 去出差。Diego 的 AI 首席助理从费用管理系统的代理那里收到一条 Slack 提醒：他最近这趟旅行还有未完成的报销。现在，两个代理都指向同一个结果：正确提交这些报销。
这两个代理各自带着自己的上下文。
Diego 的首席助理掌握：
Diego 的日历：知道哪些会议发生了，发生在什么时候，和谁一起。
Diego 的邮件：有酒店和航班确认函，也有对应附件。
Diego 的 Slack：可以把 Kokkari 那顿晚餐，关联到他邀请 Acme 团队的某个讨论串。
Diego 的收据：来自邮件附件和照片图库。
费用管理系统掌握：
原始交易数据，例如商户和交易时间。
公司关于提交报销的政策。
公司的总账账户（GL accounts）。
公司历史上的费用编码模式。
传统 API 会把问题重新丢回给用户。「这里有一笔交易，需要一个总账代码。请使用这个端点，获取 150 个总账代码选项，然后自己挑一个。」
设计良好的代理互动，会把这个过程翻转过来。它不要求用户提供总账代码，而是询问上下文：这是一顿客户餐，团队餐，还是个人旅行？首席助理代理会从日历条目或 Slack 讨论串中找出答案。费用管理系统则基于它缺失的那部分上下文，应用正确代码。
Diego 和他的代理都不需要知道总账代码是什么。财务团队仍然得到准确分类。双方各自贡献自己知道的东西，最终交付一个对 Diego 更好，也对他的会计更好的结果。
当你设计这些代理与代理之间的互动时，要留意上下文缺口。承认自己的代理在哪里力有不逮，并没有关系。毕竟，你们服务的是同一个用户。
过去，界面夹在 Diego 和费用系统之间。现在，它夹在 Diego 的代理和你的代理之间。
这个转变重新定义了产品团队的工作。过去，你是在为一个想要快速行动、避免错误、看见成果的人设计产品。现在，你仍然在为同一个人设计，只是要通过一个中介来触达这个人。而这个中介的本能、上下文和局限，都与人不同。
教会代理如何成功，建立反馈回路，留意上下文缺口。这三件事，其实都在追问同一个底层问题：你的代理调用者需要什么，才能把自己的工作做好？你是否已经把这些东西交给它？
大多数公司会发布一个 MCP，打个勾，然后继续往前走。它们的使用量也许会增长几个季度，随后停滞。随着时间推移，客户会流向那些认真打磨细节的产品，也会绕开那些没有这样做的产品。
像当初为人类打磨产品一样，认真为代理构建产品。也许不久之后，真正签下支票的，就是它。