人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载List Chats 是 TaskingAI Assistant Chat 管理体系中用于**分页查询某个 Assistant 下全部会话Chat**的核心 REST 接口。本文以仓库中 4_list_chats.md 模板为骨架结合后端路由、Pydantic 请求/响应模型、PostgreSQL 分页实现与自动化测试完整讲解该接口的调用方式、每个参数的取值语义以及before/after游标分页在数据库层面的真实工作原理。读完本文你将能够正确编写带分页、排序的会话列表查询请求并读懂其响应中的fetched_count与has_more字段。1. 接口概览与 curl 调用List Chats 使用GET方法路径为GET /v1/assistants/{assistant_id}/chats模板中给出的最简调用如下占位符$$SERVICE_HOST$$、$$API_KEY$$、$$ASSISTANT_ID$$需替换为实际服务地址、Bearer 密钥与目标 Assistant 的 IDcurl -X GET $$SERVICE_HOST$$/v1/assistants/$$ASSISTANT_ID$$/chats \ -H Authorization: Bearer $$API_KEY$$ \ -H Content-Type: application/json认证方式为 HTTP Bearer Token。请求无需携带请求体查询条件全部通过URL 查询参数query string传递。1.1 路由在源码中的定义该端点由自动生成的 FastAPI 路由注册见 backend/app/routes/auto/chat.py。其operation_id为list_chat并声明了请求模型ChatListRequest与响应模型ChatListResponserouter.get( path/assistants/{assistant_id}/chats, tags[Assistant - Chat], summaryList Chats, operation_idlist_chat, response_modelChatListResponse, responses{422: {description: Unprocessable Entity}}, ) async def api_list( request: Request, data: ChatListRequest Depends(), path_params: Dict Depends(path_params_required), auth_info: Dict Depends(auth_info_required), ): ... entities, has_more await ops.list( limitdata.limit, orderdata.order, after_iddata.after, before_iddata.before, prefix_filtersprefix_filter_dict, equal_filtersequal_filter_dict, **path_params, ) return ChatListResponse( data[entity.to_response_dict() for entity in entities], fetched_countlen(entities), has_morehas_more, )注意limit、order、after、before四个查询参数通过ChatListRequest Depends()自动解析其中assistant_id来自路径参数并在调用ops.list时作为equal_filter等值过滤条件一并传入确保查询被严格限定在指定的 Assistant 之下。2. 请求参数详解模板文档说明了三个核心参数limit、order、before/after。结合请求模型 chat_list_request.py 的字段定义各参数的完整语义与约束如下。2.1limit单页返回条数上限作用限制本次列表返回的 Chat 对象最大数量。默认值20。取值范围1 ~ 100ge1, le100超出范围会返回 422 校验错误。limit: int Field(20, ge1, le100)2.2order排序方向作用决定列表的排序方向取值为desc降序默认或asc升序。排序键Chat 的created_timestamp字段创建时间戳毫秒精度。模板中特别强调 The sort key is thecreated_timestampfield of the chat。类型定义SortOrderEnum见 backend/tkhelper/models/type.pyclass SortOrderEnum(str, Enum): DESC desc ASC ascorder: Optional[SortOrderEnum] Field(SortOrderEnum.DESC)2.3before/after游标式分页作用指定取数的游标点。after表示返回排在游标之后的下一页before表示返回排在游标之前的上一页。游标的值是某一 Chat 的chat_id。约束长度为1 ~ 50的可选字符串两者可以单独使用语义上不应同时传入。与limit/order组合使用分页请求应携带limit与order保持一致避免翻页过程中结果错乱。after: Optional[str] Field(None, min_length1, max_length50) before: Optional[str] Field(None, min_length1, max_length50)2.4 组合请求示例# 按创建时间降序每页 20 条 curl -X GET $SERVICE_HOST/v1/assistants/$ASSISTANT_ID/chats?limit20orderdesc \ -H Authorization: Bearer $API_KEY # 使用 after 游标获取下一页游标为上一页最后一条 chat_id curl -X GET $SERVICE_HOST/v1/assistants/$ASSISTANT_ID/chats?limit20orderdescafter$CHAT_ID \ -H Authorization: Bearer $API_KEY # 使用 before 游标回翻上一页 curl -X GET $SERVICE_HOST/v1/assistants/$ASSISTANT_ID/chats?limit20orderascbefore$CHAT_ID \ -H Authorization: Bearer $API_KEY3. 响应结构与 Chat 对象字段响应模型见 chat_list_response.py包含四个字段字段类型说明statusstring固定为successdataarrayChat 对象列表即本页返回的会话fetched_countint本次实际返回的对象数量即len(data)has_morebool是否还有更多数据可供继续翻页{ status: success, data: [ { object: Chat, assistant_id: ast_..., chat_id: SdEL..., metadata: {}, memory: { ... }, name: Name, created_timestamp: 1720000000000, updated_timestamp: 1720000000000 } ], fetched_count: 1, has_more: false }data中每个元素都是一个完整的 Chat 对象。其字段定义见 backend/app/models/assistant/chat.pyobject固定为Chatassistant_id所属 Assistant 的 ID24 位前缀ast_chat_id会话 ID24 位前缀SdELmetadata创建会话时关联的任意键值信息memory该会话的对话记忆配置对象name会话名称created_timestamp/updated_timestamp创建与最近更新的毫秒级时间戳created_timestamp即列表排序键。staticmethod def generate_random_id(**kwargs) - str: return SdEL generate_random_id(20)4. 游标分页的源码级原理before/after不是传统的offset分页而是基于排序键的keyset游标分页。其完整实现位于 backend/app/database_ops/utils.py 的list_objects函数上层调用链为api_list路由→ chat_ops.list → PostgresModelOperator.list → postgres_ops.list_objects调用链中的 PostgresModelOperator.list 先根据传入的after_id/before_id查出对应的游标对象再取出该对象的created_timestamp作为after_value/before_value连同 ID 一起交给list_objects。4.1 元组比较构造 WHERE 条件list_objects使用 PostgreSQL 的元组比较语法构造条件backend/app/database_ops/utils.pysql_order ASC if order SortOrderEnum.ASC else DESC if after_value is not None and after_secondary_value is not None: operator if order SortOrderEnum.ASC else where_clauses.append( f({sort_field}, {secondary_sort_field}) {operator} (${len(params) 1}, ${len(params) 2}) ) params.extend([after_value, after_secondary_value])即升序翻页时取(created_timestamp, chat_id) (游标时间戳, 游标ID)的记录降序时取的记录。以(created_timestamp, chat_id)二元组作为分页键可保证即使多条记录时间戳相同分页依然稳定、不重不漏——这正是 keyset 分页优于 offset 分页的关键。4.2has_more的判定方式list_objects查询时实际多取一条limit 1再判断是否超出backend/app/database_ops/utils.pyextended_limit limit 1 limit_clause fLIMIT ${len(params) 1} params.append(extended_limit) ... has_more len(objs) limit if limit else False随后截断到limit条返回。因此调用方可以通过has_more判断是否还有下一页。4.3before翻页的方向反转使用before时代码先按与order相反的方向查出一批记录再反转回正确顺序backend/app/database_ops/utils.pyif before_value is not None and before_secondary_value is not None: operator if order SortOrderEnum.ASC else ... sql_order DESC if order SortOrderEnum.ASC else ASC ... objs objs[:limit] if limit else objs objs.reverse() # 反转回用户请求的 asc/desc 顺序SQL 层面则以ORDER BY created_timestamp DESC/ASC, chat_id DESC/ASC双键排序backend/app/database_ops/utils.py保证返回顺序稳定可预期。4.4 过滤与归属约束assistant_id会被并入equal_filters等值过滤作为 SQL 的WHERE assistant_id $n条件backend/app/database_ops/utils.py同时 Chat 模型 将assistant_id、chat_id声明为主键字段list前还会执行_check_kwargs校验主键是否齐全。这保证了 List Chats 永远只返回指定 Assistant 名下的会话。5. 测试用例佐证接口行为验证仓库自动化测试对 List Chats 做了直接验证可作为调用该接口的行为基准。5.1 测试客户端backend/tests/api_services/assistant/chat.py 封装了 aiohttp 请求async def list_chats(assistant_id: str, params: Dict None): headers get_headers(CONFIG.Authentication) async with aiohttp.ClientSession(headersheaders) as session: request_url f{ASSISTANT_BASE_URL}/{assistant_id}/chats response await session.get(request_url, paramsparams) return ResponseWrapper(response.status, await response.json())5.2 分页测试backend/tests/services_tests/assistant/test_chat.py 中的test_list_chats使用limit10, orderdesc加上afterchat_id游标断言返回恰好 1 条、fetched_count 1、has_more is Falseasync def test_list_chats(self): list_chats_data { limit: 10, order: desc, after: Assistant.chat_id, } res await list_chats(Assistant.assistant_id, list_chats_data) assert res.status_code 200, res.json() assert res.json().get(status) success assert len(res.json().get(data)) 1 assert res.json().get(fetched_count) 1 assert res.json().get(has_more) is False删除会话前测试还会用{limit: 100}一次拉取全部会话 ID 再逐一删除backend/tests/services_tests/assistant/test_chat.py也印证了limit上限为 100 的实际用法。6. 与其他 Chat 端点的衔接List Chats 是 Chat CRUD 闭环中的一环与同目录下的其他模板共同组成完整的会话管理能力均注册于 backend/app/routes/auto/chat.py方法路径operation_id对应模板POST/v1/assistants/{assistant_id}/chatscreate_chat1_create_a_chat.mdGET/v1/assistants/{assistant_id}/chatslist_chat本文4_list_chats.mdGET/v1/assistants/{assistant_id}/chats/{chat_id}get_chat3_get_a_chat.mdPOST/v1/assistants/{assistant_id}/chats/{chat_id}update_chat2_update_a_chat.mdDELETE/v1/assistants/{assistant_id}/chats/{chat_id}delete_chat5_delete_a_chat.md典型使用流程先list_chats拿到会话列表与chat_id再对选中的会话执行get_chat获取详情、update_chat修改名称/元数据或使用delete_chat清理历史会话。每次创建会话时后端还会同时初始化该会话的 memory 并同步更新 Assistant 的num_chats计数见 backend/app/operators/assistant/chat.py。7. 同步补充Python SDK 等价调用同一主题的 Python 模板见 backend/resources/code_templates/assistant/1_python/2_chat/4_list_chats.md参数语义与 REST 完全一致适用于非 curl 场景import taskingai chats taskingai.assistant.list_chats( assistant_id$$ASSISTANT_ID$$, orderdesc, limit20 )总结List Chats 是一个简单但设计严谨的列表接口limit默认 20上限 100控制页大小order以created_timestamp为排序键控制升降序before/after通过(created_timestamp, chat_id)二元组的 keyset 比较实现稳定游标分页响应中的fetched_count与has_more让客户端可以可靠地驱动下一页循环。理解其底层 SQL 构造元组比较、limit1探活、before方向反转有助于你在高并发、大列表场景下写出正确的翻页逻辑并避免 offset 分页常见的数据偏移与重复问题。赞分享人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载相关推荐3 步跑通大麦自动抢票Selenium Appium 双通道实现深度解析3 步跑通大麦自动抢票Selenium Appium 双通道实现深度解析 热门演出开票后已售罄往往几秒内就刷上屏幕手动点击很难跟得上。本文拆解基于人工智能大模型AI AgentRAG后端前端Kata Containers 与 Cloud Hypervisor 的 ConsoleConfig串口/控制台配置模型与源码实现解析Kata Containers 与 Cloud Hypervisor 的 ConsoleConfig串口/控制台配置模型与源码实现解析 Kata Contai人工智能大模型AI AgentRAG后端前端JSqlParser源码解析Expression接口设计与实现原理JSqlParser源码解析Expression接口设计与实现原理 引言SQL解析的核心挑战 在现代数据处理系统中SQL语句的解析与处理是核心功能之一。无数据库上一篇pgvectorscale核心架构深度解析StreamingDiskANN与SBQ的完美结合下一篇用频率数据精准定刷题优先级字节跳动 6 个月 83 道题的难度分布与 30 天刷题路线创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考