agent-chat-openai 更新

[lilongxian]

openai参数完全对齐，功能齐备，两种模型兼容，申请合入，谢谢了！

[lilongxian]

这版添加了模式二的agent控制器环境变量。

[lilongxian]

辛苦了！

[chenhaoqiang]

这个请求参数好像和OpenAI官网API不符合，导致我调用接口报错了，我是按照OpenAI接口标准传的

[chenhaoqiang]

@lilongxian @zRzRzRzRzRzRzR 能帮忙看下是否有这个问题不，还是我哪里理解错了

[lilongxian]

上面的tool["name"]也可以写成 get("name"), 但改成get看是不报错了，但是可能会有新的问题，因为name表示的是工具的名称，这个参数在system指令工具描述中是必须要有的，当tool描述中遗漏这个参数时候，或定义不对时，这里如果get的话虽然不报错，但实际就会引发后面智能体找不到实际存在的工具这种更严重的错误，并且这种错误也不会报错，而是直接悄悄的让模型失去了一个某个工具能力。所以在接口接收参数时候检查参数是又必要的，参数正确情况下，这里两个路径必走一个，否则返回False.

[lilongxian]

以前传的是我自研的长任务链的链式任务规划调度的流推理算法的一小部分，可能有些地方关联到我更大的算法，所以上传有时候不是很好。我搞那个长任务链的链式任务规划调度的流推理算法，没有用openai的接口技术，就是自己写的一个长链任务生成器的递归算法，支持openai、非openai两种接口模式，非openai模式算法也支持本地私有化部署，无需联网，无需openai key，支持用户问一个复杂问题，agent告诉用户开始后，自行规划第一步（自主调度运行得到结果）总结 自动规划下一步 总结 ...... 每一步都会自主纠正寻址并执行和总结思考，。。。一次类推，指导得到最后答案，再给用户返回。

[lilongxian]

以上那个name，建议还是先看一下工具描述看输入的对不对. 只有在chat而非agent-chat时候tool是空的[ ]，但是如果是[ ]，那程序是走不到这里的。在for的时候就已经停止了，返回False

[chenhaoqiang]

以上那个name，建议还是先看一下工具描述看输入的对不对. 只有在chat而非agent-chat时候tool是空的[ ]，但是如果是[ ]，那程序是走不到这里的。在for的时候就已经停止了，返回False

我使用的请求参数调用openai接口是没问题的，调用ChatGLM3报上面的错。看我上面openai官方接口的截图，我的理解是tools下面还是个对象，name在tools.function节点下，而不是目前ChatGLM3推理脚本中的tools节点下，少了一个function节点

[lilongxian]

@chenhaoqiang 上面那个tool的校验是有点不妥，这是两个版本代码耦合在同一套代码中，这块的设计传入的tools是来自system中的tools字典列表，安全起见，这里可以简单检验，用字符串更保险些，如下： if value and 'get_' in value: # 标准openai接口部署 return True
elif value and 'python\ntool_call' in value: # 非openai接口无外网部署，函数调度实现 return True