工具不是收藏品
我以前很容易把“发现工具”理解成一件兴奋的事：看到一个项目，装起来，跑通，记下端口，放进导航页。短时间内这会带来很强的进展感，好像系统突然变得丰富了。
但一段时间之后，真正有价值的不是装过多少工具，而是哪一些工具进入了日常动作。
有些工具会变成每天都在运行的服务，比如 Git、监控、金融数据日报和知识检索接口；有些工具只适合短期试用，确认不合适之后就应该被删除；还有一些工具本身不重要，重要的是它留下了一条规则，比如“部署后必须端到端测试”，或者“Docker DNS 先看 /etc/resolv.conf 权限”。
所以 OBS-0005 记录的不是某一个工具项目，而是一套长期项目：观察工具如何进入我的工作流，又如何被保留、淘汰或转化成规则。
一个工具进入工作流之前
一个工具刚被发现时，通常会有很多诱人的理由：功能完整、界面好看、别人推荐、能解决一个当下的痛点，或者只是看起来很有趣。
但真正决定它能不能留下来的，不是第一眼的功能列表，而是它是否能接上已有流程。
比如一个私有 Git 服务只有在代码、配置、脚本和站点内容都能被稳定提交时才有意义；一个运维面板只有在它能降低日常维护成本时才有意义；一个金融数据仪表盘只有在它能自动生成、推送并被真正阅读时才有意义；一个 MCP Knowledge Server 只有在它能被 Agent 可靠调用时才有意义。
工具进入工作流之前，至少要经过几层检查：它解决什么问题，维护成本是多少，数据放在哪里，失败时如何恢复，是否能和现有服务、脚本、定时任务或 Agent 接上。
如果这些问题答不出来，它最多只是“试过”，还不能算进入工作流。
被保留的理由
一个工具被保留下来，通常不是因为它最复杂，而是因为它减少了某种摩擦。
有的工具让入口更稳定。导航页、远程桌面、私有 Git 服务这类东西，本身不一定新奇，但它们让之后的操作少走很多弯路。
有的工具让信息自动抵达。金融数据日报、全球资讯速递、DeepSeek 用量日报、知乎关注监控这些定时任务，价值不在于“自动化”三个字，而在于它们把需要反复打开的页面，变成了会主动抵达的消息。
有的工具让系统更早暴露问题。CPU 异常检测、systemd 服务、访问日志和监控脚本的意义，是在问题变成事故之前留下信号。
还有一些工具的价值不是它自己，而是它迫使我形成检查清单。部署、代理、DNS、端口、权限、资源占用、定时任务验证，这些规则一旦沉淀下来，就比单个工具更有长期价值。
被淘汰也是结果
工具被删除，不等于浪费。
有些项目部署起来很重，维护成本超过收益；有些工具看起来强大，但进入真实流程后发现不适合；有些服务会留下残余容器、日志、卷和 systemd 单元，反而增加系统噪音。Dify、PentAGI、仙途这类被完整清理掉的项目，恰恰说明“淘汰”也是工作流的一部分。
一个工具如果无法稳定运行、无法被日常使用、无法解释它占用的资源，或者无法在失败后被快速恢复，就应该离开。
这件事带来的经验很朴素：不要把“装上了”当成完成。真正的完成至少包括验证、记录、监控、回滚和清理路径。
工具最后会变成什么
最理想的情况，不是工具越攒越多，而是有些动作慢慢不用再重新想一遍。
一开始只是临时敲的一条命令，后来可能会被写成脚本；一个脚本跑顺了，可能会被放进定时任务；一次排查走过弯路，下一次就会变成检查清单。还有一些被删掉的项目，也不是完全没有留下东西。它们至少让我知道：这种工具以后不用再试了，或者至少不要用同样的方式试。
工具真正留下来的，往往不是它自己的界面，也不是某个端口上的服务，而是它改变了我处理问题的顺序。
以前遇到一个需求，我可能会先找工具。现在我会多问几句：这个动作会重复吗？失败了能不能恢复？结果会不会被记录下来？以后还能不能交给脚本、定时任务或 Agent 去做？
以后我肯定还会继续试很多工具。只是我不太想再把“装上了”当成成果。真正值得留下来的，是那些让我下次更快、更稳、更少重复自己的东西。