对react功能有些疑问。

[aiping312]

看了一下react实现，还是没搞清楚llm是根据什么上下文确认该调用哪个action，llm做决定前得需要知道，各个action的功能描述信息什么的吧?没找到收集相关信息传给llm的代码。

[iorisa]

实现业务逻辑有三种方案：

1. 用SOP(standard operating procedure)形式实现业务流程。这种方案下流程是人工规划好的，operating（action）的输入输出都是设计好的，预期内的格式。由于人工规划好了流程，因此不需要agent理解各个action是干嘛的。
2. 用角色扮演agent的形式来串联业务流程。这种方案下流程也是人工规划好的，每个角色agent的输入输出只是在语义层面时预期内的，数据格式则是可以灵活调整的。
3. 用RoleZero agent的形式来串联业务流程。这种方案下流程是由agent规划的，只有这种情况下，agent才需要知道tool api的功能描述和使用方法。如果想了解更多的细节，可以参考：DataInterpreter的代码。

[zhaoweiguo]

实现业务逻辑有三种方案：

1. 用SOP(standard operating procedure)形式实现业务流程。这种方案下流程是人工规划好的，operating（action）的输入输出都是设计好的，预期内的格式。由于人工规划好了流程，因此不需要agent理解各个action是干嘛的。
2. 用角色扮演agent的形式来串联业务流程。这种方案下流程也是人工规划好的，每个角色agent的输入输出只是在语义层面时预期内的，数据格式则是可以灵活调整的。
3. 用RoleZero agent的形式来串联业务流程。这种方案下流程是由agent规划的，只有这种情况下，agent才需要知道tool api的功能描述和使用方法。如果想了解更多的细节，可以参考：DataInterpreter的代码。

第二个方案，可不可以再详细讲一下？

[iorisa]

用角色扮演agent的形式来串联业务流程时：

1. 每个agent的角色是规划好的，固定的角色关注固定的目标、采用固定的方式。
2. 任务相关的数据的提取和格式化由agent自己负责，不需要上下游agent负责。

方案2是介于方案1和方案3之间的方案。跟SOP相比，方案2对输入数据的格式没有强制要求，对输入的容错能力更高；跟方案3相比，方案2的功能（你可以理解成像方案3那样的tool api）是固定的。

方案2适用于SOP场景，且可接收人工输入（人做为SOP的一个环节）。

[iorisa]

If there are no further questions, this issue will be closed. If you have any other questions, you can reopen this issue or create a new one.