思考上的欠缺必然导致行动上的缓慢
近日，在处理 agent 插件时，我使用 Fission 服务来发布 function 功能。开发之初，仅简单地了解了一下 Fission 的功能与用法，就急匆匆地开始了开发任务。当时虽然对一些问题有些疑惑，但并未在意，心想还有 Plan B 作为兜底方案，就做了个思考上的“懒人”。
经过几天的开发，功能虽然完成了，但多个 function 如何更优雅高效地管理成了困扰。Plan B 的思路是：每一个 function 插件都打一个镜像，用作运行时的基础镜像。但问题在于：
- 随着越来越多的 function 插件需要开发，是不是仍旧每个插件都打一个镜像？
- 这么多镜像如何维护与管理？
- 每个 function 在实例化时都需要一个独立的 env 环境，这对资源是不是一种浪费？
在 function 较少时，打镜像的方式可以满足快速上线的需求。但从发展的眼光来看，这种方法并不是一个明智的“快”。眼前的“快”需要后期的“慢”来弥补。管理和维护复杂的镜像库，以及资源浪费的问题，最终会拖累整个系统的效率。
于是，我们采纳了龙哥的方案：创建一个统一的 env 环境，其余的 function 则打成 .whl 包，按需安装。这样的方案不仅解决了镜像管理的复杂性，还能降低资源开销，实现资源的复用性。
反思与收获
如果当初仅仅是为了快速完成任务，Plan B 确实是可行的。但在开发过程中，我能够学到什么呢？
反思自己的开发过程：
- 在设计之初，未能从全局和长远的角度考虑问题，而是局限于眼前的“快”。
- 忽视了对工具（如 Fission）深入学习的重要性，仅凭表面的理解就进入开发。
改进后的收获：
- 学会了如何高效管理多个 function，通过统一的 env 和按需安装的机制，大幅提升了开发和部署效率。
- 体会到“慢即是快”的道理：前期充分思考和设计，能够避免后期重复劳动和资源浪费。
- 深入了解了 Fission 的功能和用法，为后续的开发提供了更好的基础。
总结
技术开发中，追求眼前的“快”，往往会导致后期的“慢”。有计划 B 作为兜底方案并不是坏事，但也不能因此放弃对问题的深入思考。正如龙哥的方案所展示的那样，从发展的角度设计架构，能够让整个系统在后期的维护和扩展中更加高效。
希望这次经历能提醒自己，思考上的懒惰可能会延缓行动上的效率。只有不断学习和优化设计，才能在技术道路上走得更远。
