发现
先确认有没有现成工具
你不需要第一天就从零做一套。先搜索别人已经发布好的工具，再决定缺口到底在哪里。
- 先搜再判断
- 避免凭想象重做一遍
为什么用 CLI
CLI 解决的是先用起来的门槛
不是先设计一套完整接入方案，而是先让 Agent 把真实任务跑通。搜索、查看、运行，这三步先在终端里完成。
使用
先在终端和 Agent 里直接跑起来
CLI 先把查看输入、调用和结果拿回来这条使用路径跑通，再决定是否要延伸到 API、MCP 或网页入口。
- 先把真实任务做完
- 有证据后再决定下一层
02 / Studio + Cloud
现成工具不够，再延伸到 Studio 和 Cloud
CLI 不是终点，而是起点。需要自定义时，就进入 Studio 生成和验证自己的工具；需要持续运行和交付时，再交给 Cloud 承接。
在 Studio 里生成和补全自己的工具
让 Agent 帮你生成代码、接依赖、补参数，本地先把真正需要的工具跑通。
在本地先验证，再决定是否交付
先验证真实任务和边界条件，不要在还没跑通之前就补交付层。
最后通过 Cloud 继续交付回 CLI
工具交付后，又能回到 oo-cli 里被搜索、查看和调用，路径是连起来的。
Cloud 控制台预览
当工具需要持续运行、配置和交付关系时，再把这层交给 Cloud。
Studio本地验证Cloud交付回 CLI
先用起来
先把使用面跑通，再决定要不要自己做
CLI 不要求你第一天就补齐 API、MCP、交付后台和运维体系。先用现成工具验证任务，再决定下一步投入。
先用
现成工具
搜索 / 查看 / 运行
CLI 默认路径
先从已发布工具开始
在终端里先搜索包、查看输入、直接运行，知道现成工具是不是已经够用。
适合先验证真实任务，而不是先设计完整接入。
再做
需要时再扩展
Studio / Cloud
下一步去向
不够时再进 Studio 和 Cloud
现成工具不够时，再去生成、验证并交付自己的工具。路径是连续的，不是重新来一遍。
先跑通，再决定要不要投入自定义开发。