ilharp
commented
11 months ago 这些指令或没有对应的service，或其service偏向internal不易使用
理应通过session.execute来执行以实现类似service的效果
为什么不是让这些插件提供对应的 Service，或将 Service 封装变得更易于使用，之后直接使用 Service 实现需求，同时插件本身的指令 Action 也调用 Service 实现需求而非在 Session 中直接实现？
command作为koishi三种跨插件调用之一（event，service，command），应当拥有更广泛的使用场景。
Command 之所以能独立于 Service，正是因为 Command 于 Service 的差异导致的，而差异的关键恰恰在于 Session 的存在，而 Session 的存在正是由于 Session 默认提供了包括 Bot、Guild 和 User 在内的多种信息。在没有这些信息需求的情况下，Service 无疑是比 session.execute() 更好的呈现方式。
因此，
- 对于「用于控制执行权限的authority/permissions」指令，由于其需要 Session 信息或消息内容来选择对象，本身几乎不可能由其他插件使用
session.execute()调用； - 对于这之外的「（管理类的）指令，如alias，plugin，command, shorturl等」，由这些插件提供 Service 后，调用方将会获得更优质的，与 JavaScript 更一致的体验，同时也能享受到必须/可选服务、服务隔离等 Service 的专属特性，从而不会出现在使用
session.execute()时为指令的存在及可用性等问题烦恼。
综上，我认为 session.execute() 足够作为指令间重定向及临时触发其他插件逻辑的方法，但不足以作为插件互操作（Interop）的方式。将精力更多地放在 Service 生态的推广上可以使终端插件拥有更多 JavaScript 风格的、可选加载和可隔离的 API 可供使用，并最终使整个生态从中获益。
CyanChanges
Describe the problem related to the feature request
目前我们有一些（管理类的）指令，如alias，plugin，command, shorturl等。这些指令或没有对应的service，或其service偏向internal不易使用。而这些指令本身，除了用于控制执行权限的authority/permissions外，与bot/session并无耦合，理应通过session.execute来执行以实现类似service的效果
但这其中存在以下几点问题：
<cmd> -h的执行过程总无法与session解耦，应当优化。command作为koishi三种跨插件调用之一（event，service，command），应当拥有更广泛的使用场景。基于此，我认为我们可以：
对部分设计插件的一个显见的好处是，我们无需重复性的实现同一功能的command/service版本
Describe the solution you'd like
/
Describe alternatives you've considered
No response
Additional context
No response