让 Agent 规划一次去上海的行程：见谁、几点、在哪个地方。它需要调用地图服务，于是任务在这里停住——用户要去开发者平台申请一个 API Key，复制、粘贴、配置，回来任务才能继续。这类一年可能只用一次的连接，准备成本远高于任务本身，而大多数人会在这里放弃。
授权应该在需要的时刻出现
另一些产品把这一步挪进了任务中间。一项录制时的体验里，Grok Bot 需要读取谷歌邮箱时，界面直接弹出授权卡片，点一下就完成；Muse 更靠前，用户说“帮我总结下该干什么”，它问要不要连接 Gmail，“点确定结束了”。两者共同点是渐进式：需要的时候才展现，需要的时候才授权。
与此相对的是清单式的设计：连接器集中在商店或设置页里，由用户预先挑选、预先配置。问题不只是多几步操作。一个被指出的缺陷是，有些 Agent 甚至不清楚自己有哪些连接器——没连上时只会回答“我没有这个”，而不是提示可以连接。授权入口出现在哪里，决定了用户是沿着任务走，还是先修一段路再出发。
授权一旦顺畅，任务的形态也会跟着变。一项录制时的体验里，用户让 Grok Bot 挨个测试 Product Hunt 排名前十的产品，它真的打开浏览器，在拿到谷歌账号授权之后，逐一登录各个网站去执行测试。这类任务在清单式的授权流程下几乎不会被发起——光是为此准备权限就足以让人放弃。授权嵌入任务，带来的不是省几步操作，而是一类“以前不会开口提”的任务变得可行。
连接这件事，本身可以是一项服务
回到行程规划的例子：申请 Key、配置、乃至向地图服务付费，都可以由产品承担，用户用积分或订阅来交换。一次讨论中的说法是，为此多耗一些积分完全可以接受，为结果付费是自然的交换。任务的价值在结果，让用户为基础设施付出注意力，等于把最难的部分留给了最没有能力处理它的人。多数外部服务一年也用不上几次，为此准备一套配置，无论如何不划算。
顺着这个逻辑往前推是一个更彻底的判断：未来的产品里，MCP、Skill、Connector、Key 这类概念不应该再暴露给用户。这是一种观点而非既成事实，但它指出了方向——普通用户需要的是“事情办成了”，而不是一套集成术语。能力的呈现方式也在此列：同样一项能力，有的产品把它深藏在菜单之下，有的产品给它名字和入口，可发现性完全不同。
减少步骤不等于减少知情
渐进式授权容易被误读成“少授权”或“自动授权”。上面的体验里没有一步省掉了确认：卡片仍然弹出，按钮仍然要点，用户仍然知道 Agent 将以什么身份访问哪个服务。被压缩的是准备成本和术语学习，不是决定权。
这一步恰恰不能省。授权越轻、越频繁地嵌入任务，每一次授权就越需要让人看清自己同意了什么。一个始终要点一下的流程，同时是一次始终可见的告知；把它简化成静默放行，省下的几秒钟会以信任为代价偿还。判断一个产品是否做对了这一段，标准不是步骤数，而是用户在授权时是否清楚发生了什么。
把连接成本计入完整服务
一次授权只是几秒钟的事，但它决定任务能否一口气完成。完整的个人 Agent 服务因此不止是模型能力加运行环境，还包括与外部世界的连接：用户说出一件事，产品负责打通途中所有的关口。评价这一段体验的标准也很具体——数一数一次任务被中断几次、中断后要多久才能继续。授权这一步的产品设计，最终就是用这个数字来计分的。