ClawNative 是什么：从 Agent 使用产品的过程理解

ClawNative 在杨天润的产品讨论中，指从设计起点就考虑 Agent 如何发现、理解和使用产品。它是一种产品主张，并非行业认证，也不是一个统一的技术标准。

理解这个概念，可以先看一个具体问题：当使用者希望 Agent 帮自己完成一项工作时，产品能否让它正确操作，并让人检查和控制结果？

区分产品里有 AI 与产品能被 Agent 使用

一个笔记应用内置摘要功能，属于产品使用了 AI。另一个应用提供清楚的读写接口，让授权的 Agent 查找笔记、提交修改并取得结果，两者关注的设计问题不同。

它们可以同时存在。AI Native 的用法在不同讨论中也并不统一，因此不适合给所有产品划出唯一边界。这里采用一个工作定义：ClawNative 特别关注 Agent 作为直接使用者时的操作路径与责任边界。

以会议室预约为例

下面是虚构的设计练习。人提出“找一个周三下午可用的房间”，产品需要支持的不只是搜索。

Agent 要知道有哪些房间、时间使用什么时区、人数限制是什么。提交预约前，应能看到将创建的记录；提交后，应取得可查询的结果。遇到冲突，需要返回明确原因，而不是只有一句“失败了”。

如果网络中断导致结果未知，还要能检查原预约是否已经创建。否则再次提交可能产生重复记录。这些都是实际操作能力的一部分。

用五个问题审视产品

1. 发现：Agent 怎样知道这个产品能做什么？
2. 理解：输入、输出和错误是否有清楚的说明？
3. 授权：它能访问哪个账号、哪些数据和哪些操作？
4. 执行：能否观察进度、识别失败并避免重复副作用？
5. 追溯：人能否查明发生过什么，并在可能时撤销？

可以用 API、命令行或其他适合场景的接口实现。仅仅增加一个接口，并不意味着上述问题已经解决。

人的界面仍有任务

人需要设置权限、检查重要操作、处理异常和理解账单。因此面向 Agent 设计不意味着删掉所有界面，而是重新安排界面负责的环节。

评估一个原型时，让一项具体任务从开始跑到结束，同时记录权限不足、输入无效和结果未知三种失败情况。哪个环节需要人工猜测产品状态，就把它列为下一轮设计问题。

ClawNative 是否对某个产品有帮助，最终应由这种具体任务检验。它不自动意味着所有软件都会消失，也不意味着产品只要贴上 Agent 标签就具备新的价值。