工具调用过于麻烦

[sudoby]

Ai每次调用工具的时候,只能一个一个调用，无法多线程使用,希望添加多线程功能,同时有一个包太依赖shizuku了,用了root权限就不识别

[AAswordman]

Ai每次调用工具的时候,只能一个一个调用，无法多线程使用,希望添加多线程功能,同时有一个包太依赖shizuku了,用了root权限就不识别

多个调用的话会造成不可控的严重后果。如果希望ai能够执行批量工具，那我觉得也应该是通过某个单独的包去控制批量执行。

哪个包不识别root，理论来说不应该啊，我做了一个兼容层，除非你是root启动shizuku

[AAswordman]

你可以看到我已经给予了root权限,但是还是无法执行shell,与此同时，在工具箱内的命令终端也无法执行shell

权限组啊，你在软件里面需要直接选root权限组，不能选debugger

[sudoby]

我给予的就是完整的root权限,它里面包括root权限组,但是当我在那个终端执行 su -c "groups"会出现错误,这是shell工具的问题,他太依赖shizuku的api了,root给他完整的权限时他无法识别使用,反而使用Python编译器执行su的时候却没有问题.

[AAswordman]

我给予的就是完整的root权限,它里面包括root权限组,但是当我在那个终端执行 su -c "groups"会出现错误,这是shell工具的问题,他太依赖shizuku的api了,root给他完整的权限时他无法识别使用,反而使用Python编译器执行su的时候却没有问题.

不是，shell是做了封装，只要直接执行就行，不需要su去开头。但是ai好像不知道这件事(

[sudoby]

问题是直接执行，他也无法执行,每次都得靠Python执行shell命令,你可能是一直用shizuku测试,但是root一般来讲先得执行su,才能继续执行

[sudoby]

不然的话呢，他就是没有shell权限

[AAswordman]

ai的调用是需要反馈的，举个例子，ai查询车票，连续查3次，但是都是使用了错误的参数，结果三个都炸了。

那如果是删除文件呢？连续删5个文件，这种操作应该是被监控和制止的。

当ai只能调用一个工具的时候，他可以根据前面的调用反馈去执行接下来的工具，尤其是对于一条链长任务执行的时候。

[AAswordman]

当然，这不意味着我彻底反对多个工具并行。只是我暂时没有一个好的思路，在确保可控的大前提下实现效率最大化。

有一种思路是分工，给ai分角色然后一个下达任务，三个并行获取信息，最后汇总。理论而言这样是可以确保每个ai一条线执行，但是这几个ai之间存在信息差。

[AAswordman]

用一种形象化的方式就是:

假设你需要完成一个复杂的任务，现在你把任务进行了分解，其中涉及到多个步骤。

这个时候就会有时序的问题出现。

已知步骤可能是并行的，也有可能是顺序的。当我们去执行这个顺序的步骤的时候，肯定需要确保上一个完成，再去做下一个，不然就会出现严重的问题。

但是当步骤是并行的时候，可能就会遇到你期待的多线程情况了。我们同时执行步骤1 步骤2 步骤3，这显然没问题，一口气执行完了。这个时候，突然有个人对你说，你做错了！回过神发现，三个事情里面每个事情都有一小部分是错误的，然后我们就需要重新去做。
但是问题就在这里。我们无法确定三个事情重新做后是否是好的，会不会再次出现问题，甚至更严重的，事情是不可逆转的，做错了就只能做错了，甚至是三个一起。

[AAswordman]

然后我们可能会有一个新的点子出现:自己要做错，那么就不能找三个人，每个人做一件事嘛，这样就不会出现手忙脚乱了。

没错，这样当然是没问题的，假设人力不考虑的话。
但是又有了新的问题:信息传递有信息熵。

再回到这个假设，我们雇佣了三个人，并且告诉他们要分别完成三个任务。

第一个人叫做ds，他听了我们的话后没有听懂，稍作理解，"哦，原来我是要xxxxx啊"，但是这或许不是我们想要的，有可能是我们(聊天的ai)向执行者传递的信息不够清楚。结果就是，第一个人忙活了大半天，回来汇报，结果我们臭骂了他一顿。

那么继续假设，第二个人和第三个人的两件事情有点相似，他们应该用差不多的方法处理这件事。结果他俩不懂得沟通，采取的方案完全不一样。汇报回来的结果，单独看都是没问题的，对比着看，两两冲突。于是乎，执行失败。

[AAswordman]

这个时候就得回到下达任务的人本身身上了。执行顺序任务，那没的说，这种东西必须只能顺序下来，雇佣别人也是三个人轮着卡着进度。
执行并行任务，那只能是几件事情一起处理。如果是我们，可能会考虑先做一件事，看起来没问题，剩下两个一起。

但是但是但是ai没那么聪明啊！他根本不懂得什么样是风险的，有时候真的能气死人。

[AAswordman]

说了那么多，这都是我对工具多个执行的一些想法，也是有感而发(毕竟讨论区不是issue区)。这也是我们软件目前面临的一个技术坎。可能我见识不够，希望上面我说的这些能给人有所启发，给出一些解决方案吧。

[sudoby]

我认为有一个ai专门用来提出与审查,用户提出的要求本质是在跟他说.他听完用户的邀求后给出方法,用户在进行判断,正确无误后他拉起剩下的ai,对他们提出要求,每个ai再将自己的想法交给这个专门的ai进行审查,有明显错误的要求再交一份方案直到正确,当自己判断正确后，交给用户再进行一次判断,这样的话应该没有问题，但是会浪费大量的token

[AAswordman]

我认为有一个ai专门用来提出与审查,用户提出的要求本质是在跟他说.他听完用户的邀求后给出方法,用户在进行判断,正确无误后他拉起剩下的ai,对他们提出要求,每个ai再将自己的想法交给这个专门的ai进行审查,有明显错误的要求再交一份方案直到正确,当自己判断正确后，交给用户再进行一次判断,这样的话应该没有问题，但是会浪费大量的token

这个方案似乎就是目前很多主流的
比如Coze好像是这么做的

[AAswordman]

虽然确实会消耗大量的token

[sudoby]

其实我认为我们可以用多种ai来节省token,例如审查就用v3而且代码一类的就用R1,这个需要单独配置,我们还可以限制审查的token让他只找关键的地方,具体流程是:用户提出请求,被限制的模型总结并拉起剩下ai,编写与执行的ai给出方案之后交于审查,此时被限制的ai询问用户关键的地方,询问得地方之后进行审查,同时写代码的ai必须要加上"你只负责写代码，不需要其他"之类的关键词,来做到节流的目的,最好给用户一个警告表示这种方法会消耗大量的token,当然用户还是嫌这样太耗费token的话,那让审查ai总结,用户负责审查是否正确.

[kjmjh]

我觉得设几个特定的工具，ai可以同时多次调用特定的工具。或者就是把ai同时调用多个工具做成一个测试功能放在设置里，加上免责声明，用户可以开启或关闭