我的Agent服务是否应该使用Responses API?
功能性考量——你的Agent需要什么功能
判断是否应该选择Responses API,最基本的一点,是要看你的服务目前或未来是否需要responses api的功能特性。
如果不需要,那么继续使用更为简单的chat completions接口,性能会比response api更佳。
对比Response API,Chat Completions是一个更单纯的接口。可以说Response API涵盖了Chat Completions。
Chat Completions = 开启非store模式 + 不使用任何内置工具(只使用function call)+ 不使用audio/file input 的 Response API
如果需要使用Responses API的功能,也不一定必须要使用Responses API,因为Bella的其他能力,比如Bella-Workflow同样可以很方便地使用这些工具。我们还要继续思考以下问题。
智能性考量——考虑用户问题的复杂性
从智能性的角度,所谓“不复杂的问题”,指问题是否具有“确定性”,可能 解决一个问题的步骤很繁琐,但是只要是可以抽象出既定程序和确定步骤来解决的问题,即视为“不复杂的问题”。
与之相对,“复杂的问题”,是指需要依赖模型的多步推理以及与用户的多轮交互来决策如何处理的问题。
对于功能单一纯粹的Agent来说,用户对其的诉求是可确定的,那么大概率是可以抽象出设定好的流程编排,那么推荐使用Chat Completions + Bella Workflow实现Agent。效果最稳定,实现也最简单。
可是,如果一个Agent的目标用户的诉求没那么强的确定性,比如一个房地产领域的知识专家。 这个Agent可能面临的用户的问题种类数不胜数,无法罗列归类,此时就不可能去枚举分类各种场景,再为每个场景定制流程了。
且解决这些问题可能需要与用户进行多轮交互,不断地修正答案。 此时就应该给模型更大的选择权,通过提示词的引导让模型自主决策下一步该做什么。
举例:
- 为Bella Openapi服务实现一个为用户查询账单的Agent,流程非常固定,只需要使用LLM提取用户信息以及用户问题中的查询信息,再调用查询账单的接口。这个场景肯定是使用
Chat Completions + Bella Workflow最简单,不需要考虑Responses API。 - 上文举例的房地产领域的知识专家,就可以考虑使用Responses API。再比如实现一个Code Agent,它所需面临的问题可想而知,更不可能使用既定流程解决问题,需要高度的智能化,此时就可以考虑使用Responses API来实现。