OpenClaw的火热引发了产品经理对Agent时代的深度思考。本文犀利指出强行将Agent嵌入产品的两大陷阱：场景错配与系统排斥，并提出更优解——打造Agent友好的交互设计。从UX到AX的范式转变、原子化技能重构到三层架构设计，揭示了未来产品竞争将从界面体验转向被Agent理解的能力。

26年以来，”龙虾”（OpenClaw）绝对是一个毫无疑问的热门话题。从民间个人到政府组织，所有人都在尝试和探讨”养龙虾”。笔者本人对于OpenClaw的火热实际上抱有一种谨慎态度——毕竟OpenClaw作为一个开源的私人助理框架，本身还多有不成熟之处（包括安全问题、框架本身的效率问题等等），是否值得大家如此All In地去追逐，确实令人有所疑虑。

但毋庸置疑的是，用户与Agent共生的时代确实被开启了。随着各种大厂推出桌面端、免部署的各种新的产品形态，Agent可能会以前所未有的速度被迅速推开。

那么从一个产品经理角度，我们如何看待新时代的产品设计？这将成为每个从业者都需要深刻思考的话题。

反思：为什么”把Agent做进产品”可能是陷阱

我想很多产品实际上在过去几年里，都是在不断尝试把Agent加入系统中。这是最直观的一种产品设计思路：既然Agent这么强大，是不是它可以帮助我们的产品提供更强的服务呢？

这当然会为用户提供一些帮助，但是这个实现路径上我们不得不面对两个致命问题：

1. 场景错配：你的瓶颈真的需要Agent吗？

很多产品实际上提供的服务，体验的瓶颈并不在Agent所擅长的领域（搜集并总结复杂信息、编排流程并自动执行、批量操作大量重复工作）。那么加上Agent往往产生的结果只是锦上添花（甚至画蛇添足）。

这里的典型例子就是我一直不能理解的滴滴一直尝试加入AI帮忙叫车。很显然滴滴提供的主要服务是一个撮合标准服务交易的平台，而叫车是一个既不需要了解太多信息，也不存在复杂操作流程的动作。用户原本就只需要输入目的地、点击一下叫车就完成的事情，Agent加入之后反而增加了模糊性和操作时长。除了强行增加了AI的元素之外，我实在不知道它为用户提供了什么价值。

Agent不是万能调料。在简单确定性场景中引入Agent，本质上是把”确定性体验”降级为”概率性体验”，这是用户体验的倒退。

2. 系统排斥：Agent与遗留系统的兼容性危机

在传统的软件产品中，我们为了支持复杂的业务流程，已经构建了庞大的软件工程，其中环环相扣、精密而难以理解（所谓屎山）。那么把Agent这么一个具有模糊性以及不可控成本的东西加入到这个系统里，会更好吗？

至少到目前为止，大部分产品的尝试还是将Agent放在交互层，给用户提供方便和情绪价值为主。真正的融入流程做出决定，似乎还有一定难度。这背后的本质是范式的冲突：Agent代表着即兴、模糊、意图驱动；而遗留系统代表着预设、精确、流程驱动。

转向：Agent Readiness > Agent Inside

返回到本源的问题，我们希望让产品与Agent进行融合，或者说跟上Agent时代的步伐，还有一个可能看起来没那么Fancy，但是非常简单有效的方向往往被我们忽略了——面向用户私人Agent的交互设计。

很多产品已经有能力解决很复杂的问题，在它们的流程、功能中融入一个Agent是非常大的挑战。但是对于用户来说，用户永远不会只操作某一个产品，他的生活场景天然就是需要复杂信息搜集和编排的。他们天然就需要一个私人的Agent（这也是为什么”龙虾”这么有魅力的原因）。

但是Agent遇到一个复杂应用的内部操作时候，往往只能停下来，告诉用户：”你得自己操作”。当用户开始广泛地使用Agent作为自己生活和工作的助手，这种体验越来越糟糕。如果这时候一个应用非常流畅地支持Agent调用自己的服务，可想而知用户会由于这种便捷性大量地迁移到这些Agent友好的应用中。

因此相较于强行把Agent融入你已有的产品里，可能更好的（商业上和用户体验上都更好）的一个方向是：尽快推进你的产品的Agent交互友好化，让你的产品不仅仅是个能力孤岛，而是成为用户可编排的能力的一部分。

这就引出了一个更深层的问题：当用户不再打开你的App，而是通过他们的私人Agent（OpenClaw、Claude Desktop或其他）来访问服务时，什么构成了你的竞争壁垒？

答案正在从”精美的UI/UX”转向“被Agent理解的能力”（Agent Readiness）。在传统范式中，护城河建立在精心设计的界面和流畅的交互上；但在Agent中心主义的新秩序中，“被发现的便利性”将取代“被使用的愉悦感”成为核心价值主张。

如何构建：Agent原生产品的设计原则

那么，How we build new app?

如果你认同未来的用户将通过他们的私人Agent来访问服务，而非打开你的App界面，那么产品设计逻辑需要根本性重构：

1. 从”用户体验”到”Agent体验”（AX）

传统UX的核心是”引导用户按我们想的做”——通过精美的界面、流畅的动效、精心设计的导航路径来引导用户行为。但Agent没有眼睛（不看界面），没有情感（不需要动效），也没有耐心（不需要引导）。

新的设计对象是Agent。你需要提供的是：

• 完整的能力契约：清晰声明你能做什么、不能做什么、需要什么条件、会出什么错
• 结构化自我描述：不是给人类看的API文档，而是给Agent看的”说明书”——包含语义化的API描述、业务约束、前置条件、失败模式
• 可验证的行为预期：Agent需要能够预测你的行为，而不是被你的”智能”惊喜到

这要求设计师摒弃”控制冲动”，转而采用”契约思维”：完整性优先于简洁性，精确性优先于友好性，可组合性优先于完整性。

2. 设计”原子化技能”而非”完整工作流”

不要试图预测用户会如何使用你的产品，也不要试图在内部做一个”小Agent”来包办一切。相反，把你的能力拆解为最小可组合单元（Atomic Skills）：

• ❌ 旧思维：“预订会议室”是一个完整功能，包含查空闲、选时间、订会议室、发邀请，用户必须按照你预设的流程走
• ✅ 新思维：拆分为 check_availability、hold_room、send_invite 等独立技能，让Agent根据用户意图动态编排

这种“即兴智能”（Improvisational Intelligence）是范式转移的核心——Agent像爵士乐手一样实时协调多方的原子贡献，而非按照固定乐谱演奏。你的服务不需要理解”如何组织一场会议”，只需要诚实暴露”我能提供房间查询”和”我能锁定时段”，Agent会即兴组合。

3. 实现渐进式交互的三层架构

为了让Agent能够安全、高效地使用你的服务，建议按照以下三层设计：

发现层（Discovery）：让你的服务可被Agent找到

• 提供机器可读的语义描述（超越传统API的技术层面描述，纳入业务语义——比如“创建订单”应该描述为“在库存充足且用户信用达标的前提下，创建可履约的商品订单”）
• 支持基于意图的搜索，而非关键词匹配
• 暴露成本模型、性能特征（如“p99 < 200ms”）、SLA等决策信息

契约层（Contract Parsing）：让Agent理解如何使用你

• 使用语义API：不仅描述端点参数，还要显式声明业务约束（”仅工作日可处理”、”国际配送需海关编码”）、前置条件（”需先完成身份验证”）、后置效果（”库存锁定”、”触发邮件通知”）
• 提供丰富的示例（Few-shot Examples）：展示典型调用模式和边界情况处理
• 显式声明失败模式：区分“库存不足”、“信用拒绝”、“区域限制”，并附带建议的Agent响应策略，使Agent能够自主恢复而非简单报错

执行层（Sandboxed Execution）：让Agent安全地试错

• 支持询价模式（Quote Mode）：对于涉及成本的操作，Agent可先请求”报价”而非直接执行
• 支持空运行模式（Dry Run）：允许Agent验证理解是否正确，返回将执行的操作明细和预期结果，但不实际提交
• 提供渐进式披露：复杂操作分阶段暴露，降低一次性理解成本

4. 建立渐进式信任协议

Agent与服务之间不能默认信任，需要建立“认知谦逊”的机制：

• 首次接触限制：新Agent首次使用你的服务时，仅开放低风险操作（查询类），限制高风险操作（支付、删除、数据修改）
• 信誉分积累：根据历史交互质量（成功率、响应及时性、契约遵守度）动态调整权限。好Agent获得更高配额、更低验证门槛、更优惠定价；违约行为则快速降级
• 双向澄清：关键操作前，Agent生成”执行摘要”供用户或服务方确认，避免”价格可议”这类语义歧义导致的预期错配

5. 商业模式的重构：从”争夺注意力”到”满足意图”

这是最艰难的转变。传统App通过注意力经济变现：用户停留越久，广告曝光越多，价值越大。但在Agent时代，用户可能根本不会”打开”你的App——Agent的目标是尽快、尽可能准确地满足用户意图，任何不必要的步骤都会被优化掉。

你需要转向意图经济：

• 价值与结果挂钩：服务的价值不再与”用户在我这里花了多少时间”相关，而是与”我成功帮助用户实现了多少意图”相关
• 按贡献计费：Agent完成复杂任务时，你的服务按实际提供的价值分成，而非按展示或点击
• 成为透明的基础设施：最佳的服务是用户甚至不会意识到其存在，只是在任务完成时感受到顺畅和满意

给产品经理的行动清单

如果你负责一个现有产品：

1. Agent兼容性审计：检查你的核心API是否已经可以被主流Agent框架调用，是否提供了机器可读的语义描述
2. 原子化拆解：梳理你的功能，看看哪些是”必须按固定流程走”的，哪些可以拆分为独立可调用的能力单元
3. 沙箱环境搭建：提供测试环境让Agent可以安全地试错（询价、空运行），支持试探性交互

如果你要设计新产品：

1. Agent-First假设：从设计第一天起，假设用户永远不会看到你的UI，你的API契约是否足够自解释？执行”如果用户从不打开我的App，我的服务还能被使用吗？”的思想实验
2. 诚实暴露边界：与其用营销话术包装能力，不如精确声明你不能做什么、在什么条件下会失败
3. 参与开放生态：主动接入主流Agent平台，推动开放标准建设，防止市场过早锁定在专有生态中

结语：成为”技能”而非”应用”

回顾互联网历史，20世纪90年代中期，每个主要网站都试图构建自己的专属客户端软件（AOL、CompuServe），认为只有这样才能提供”最佳用户体验”。但最终，浏览器的统一界面终结了这种碎片化——Mosaic和Netscape提供了一个中立的、通用的、可扩展的访问层。

今天的”每个App都在做自己的AI Agent”正是同一模式的重演。当用户需要与数十个不同的”智能助手”分别交互时，所谓的”智能”反而成为了负担的倍增器。

我们正在等待的是那个能够统一访问、动态编排的”Agent浏览器”的出现。而那些率先为”被Agent理解”而非”拥有Agent”而设计的服务，将在新范式中占据类似早期网站相对于桌面软件的优势。

未来的用户不会说“帮我打开滴滴叫车”，而是说“帮我安排今天的出行”——至于调度了多少个后台服务，用户既不知道，也不关心。

你的目标不是成为用户注意力争夺战的胜利者，而是成为用户Agent首选调用的能力提供者。这就是Agent Readiness的真正含义。

Kimi 作为共同作者