1. 重点

• KeOnes 自动化从 2026-05-26 左右开始折腾，到 2026-06-12 决定删掉。
• 中间做了 CLI、skill、command、配置和默认路由，最后几乎没怎么用起来。
• 这不是工具做坏了，是这个场景没有撑起长期维护的价值。
• 不要为了一个低频动作，把它包装成一套需要长期维护的体系。

2. 旧判断

• 旧文章是 把工作环境塞进Codex、Cursor 中：连接公司研发平台。
• 当时觉得复制 curl 的半自动方案 ROI 够高：
  • 人负责登录和授权。
  • 工具负责读取、筛选、展示和附件落地。
• 现在看，复制 curl 这个方法是对的。
• 错的是继续把它做成长期入口、CLI、skill 和跨 Agent 命令。

3. 唯一留下来的方法

• 老系统访问不了、不提供稳定 MCP、CLI 或 OpenAPI，就不要先追求漂亮接入。
• 页面能跑，接口就已经存在。
• 从 Network 复制已经成功的 curl，直接复用 headers、payload 和 cookie。
• 把鉴权、内网、Cookie 和历史系统复杂度压回浏览器，把当前任务交给 Agent 做完。

4. 启示

• 工具化之前先问使用频率。
  • 低频任务优先做一次性脚本和当前任务适配。
  • 其实就是为了做而做，还有做了带来了一些认知上的迭代
• 判断 ROI 的方式不是“这个工具能不能做出来”
  • 而是“我真的会用它吗，是刚需吗，真的提效吗”。

5. 最后、curl 大法、跑通才是一切，自己用的，跑通就行，野路子才有出路

以后遇到类似系统，先复制 curl 做一次任务；连续多次自然复用后，再考虑沉淀成工具。