Feature: Execute command outside session

[Hieuzest]

Describe the problem related to the feature request

目前我们有一些（管理类的）指令，如alias，plugin，command, shorturl等。这些指令或没有对应的service，或其service偏向internal不易使用。而这些指令本身，除了用于控制执行权限的authority/permissions外，与bot/session并无耦合，理应通过session.execute来执行以实现类似service的效果

但这其中存在以下几点问题：

• 要执行session.execute，首先必须有session，进一步的，必须先有一个特定的bot。而根据上述讨论，这些指令的执行过程是与bot/session完全无关的。
• 如果我们虚构/任意指定一个bot，那么bot.session()直接获得的session由于缺少event，在后续流程中会存在一些问题，例如isDirect的判断中会报错，此外，authority/permission的嵌入也需在此考虑。
• sessuib,execute的二参数next用于指定execute的emit行为，当next=true时execute会将原本要send的内容作为函数返回值返回，这是与我们的期望一致的。但是，next属性并不会被传递，当存在execute嵌套时（事实上，即使没有嵌套，传入string而不是Argv这一行为本身就会导致内部的嵌套），emit行为就可能被重置，这取决于其内部逻辑的行为。稍微展开一下这部分，在koishi的command执行栈中，大部分位置都可以直接返回Fragment来中止后续并发送输出的，此时则不需要显式session.send。而在官方插件help中，executeHelp函数调用session.execute却没有设置next，即此处可以设置next=true来返回，却显示调用了send，我认为此处存在问题，即导致了指令<cmd> -h的执行过程总无法与session解耦，应当优化。

command作为koishi三种跨插件调用之一（event，service，command），应当拥有更广泛的使用场景。基于此，我认为我们可以：

• 提供获取独立的空session的方法用于执行command
• 优化整个执行过程中的问题，（对官方插件）优化next的一致性以明确解耦性的传递性。

对部分设计插件的一个显见的好处是，我们无需重复性的实现同一功能的command/service版本

Describe the solution you'd like

/

Describe alternatives you've considered

No response

Additional context

No response

[ilharp]

这些指令或没有对应的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() 更好的呈现方式。

因此，

1. 对于「用于控制执行权限的authority/permissions」指令，由于其需要 Session 信息或消息内容来选择对象，本身几乎不可能由其他插件使用 session.execute() 调用；
2. 对于这之外的「（管理类的）指令，如alias，plugin，command, shorturl等」，由这些插件提供 Service 后，调用方将会获得更优质的，与 JavaScript 更一致的体验，同时也能享受到必须/可选服务、服务隔离等 Service 的专属特性，从而不会出现在使用 session.execute() 时为指令的存在及可用性等问题烦恼。

综上，我认为 session.execute() 足够作为指令间重定向及临时触发其他插件逻辑的方法，但不足以作为插件互操作（Interop）的方式。将精力更多地放在 Service 生态的推广上可以使终端插件拥有更多 JavaScript 风格的、可选加载和可隔离的 API 可供使用，并最终使整个生态从中获益。

[CyanChanges]

字符串操作很好玩吗，而且也不一定只有一个消息，也不一定是 retuen 的,你就说你想怎么处理吧，
你说你只是执行指令不管输出那你参数还得字符串拼接，如果包含特殊字符/用户输入，会不会出现bug或注入？