人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载本文基于 TaskingAI 开源仓库中的模型推理代码模板文档系统讲解如何通过官方 Python SDKtaskingai调用chat_completion完成单轮与多轮对话并结合仓库源码深入剖析消息结构、模型配置参数、流式输出与函数调用能力帮助开发者在 AI 原生应用开发中快速落地大模型对话能力。一、Chat Completion 是什么Chat Completion对话补全是大模型应用开发中最基础、最高频的推理能力。它接收一段以角色role为标识的对话消息列表让模型基于上下文继续生成内容。在 TaskingAI 中chat_completion是对模型执行推理的统一入口无论是文本对话、多轮追问、带上下文的助手问答还是携带工具function call的自动化任务最终都汇聚到这一核心接口。TaskingAI 的代码模板文档位于 backend/resources/code_templates/model/1_python/1_inference/1_chat_completion.md它给出了 Python SDK 最直接的两种用法单轮对话与多轮对话。本文将以该文档为主线把示例代码逐段拆解并补充仓库中对应的请求模型、消息类型、配置参数与底层调用链让你不仅会调还知道为什么这样调。二、前置准备安装 SDK 与确定模型 ID在使用taskingai之前需要完成两件事安装官方 Python SDK执行pip install taskingai准备可用的模型 ID在项目中创建一个 Chat Completion 类型的模型chat_completion获得形如$$MODEL_ID$$的模型标识。模板中的$$MODEL_ID$$是占位符实际使用时替换为你项目中的真实模型 ID。模板文档中所有 Python 示例均以taskingai包为入口import taskingai from taskingai.inference import chat_completion, SystemMessage, UserMessage其中chat_completion是同步调用函数SystemMessage与UserMessage是消息构造器。关于消息类型的定义与约束下文会结合源码详细说明。三、单轮对话最小可用示例单轮对话是最简单的调用形态一条系统指令SystemMessage加上一条用户提问UserMessage一次调用即可获得模型回复。import taskingai from taskingai.inference import chat_completion, SystemMessage, UserMessage # 从你的项目中选择一个可用的 chat_completion 模型 model_id $$MODEL_ID$$ # 创建一次 chat_completion 任务 chat_completion_result taskingai.inference.chat_completion( model_idmodel_id, messages[ SystemMessage(You are a health advisor providing nutritional advice. You should always reply with a professional, kind, and patient tone.), UserMessage(How much sugar can a woman take in a day?), ] )3.1 两条消息的职责划分SystemMessage设定模型的角色与行为边界。示例中要求模型扮演营养健康顾问语气专业、友善、耐心。系统消息通常放在消息列表第一位用于约束整段对话的风格与范围UserMessage用户的真实提问。模型将基于系统指令和用户问题生成回复。3.2 从源码看消息模型模板中使用的SystemMessage、UserMessage并非临时拼装的字典而是有严格的 Pydantic 模型约束。在推理服务端消息的底层定义位于 inference/app/models/chat_completion/chat_completion.pyclass ChatCompletionRole(str, Enum): system system assistant assistant user user function function消息基类ChatCompletionMessage允许content为普通字符串对于支持视觉vision的大模型content还可以是text与image_url组成的多模态内容列表见ChatCompletionMultimodalContent定义chat_completion.py。而在后端 API 层请求体ChatCompletionRequest对messages做了强校验——messages不能为空且每条消息的role必须是system/user/assistant/function之一否则直接抛出校验错误参考 backend/app/schemas/model/chat_completion.py。这意味着 SDK 端构造消息时会话角色是严格受控的不会出现非法角色混入的情况。四、多轮对话携带上下文继续追问真实业务场景中对话往往是多轮的用户会基于上一轮的答案继续追问。多轮对话的关键在于把历史消息完整回传给模型让模型记得之前的对话内容。from taskingai.inference import AssistantMessage # 多轮对话 chat_completion_result taskingai.inference.chat_completion( model_id$$MODEL_ID$$, messages[ SystemMessage(You are a health advisor providing nutritional advice. You should always reply with a professional, kind, and patient tone.), UserMessage(How much sugar can a woman take in a day?), AssistantMessage(The AHA suggests a added-sugar limit of no more than 100 calories per day (about 6 teaspoons or 24 grams) for woman.), # 示例中 UserMessage 和 AssistantMessage 通过构造函数手动创建 # 实际场景中这些消息应通过 taskingai.assistant.list_messages 获取 UserMessage(What about man?), ] )4.1 消息顺序即上下文多轮对话中消息必须按时间顺序排列system → user → assistant → user → ...。模型通过完整的消息序列感知上下文从而回答那男性呢这类依赖前文的追问。4.2 手动构造 vs 会话历史模板注释特别强调了两种消息来源的差异手动构造示例中的AssistantMessage(The AHA suggests ...)是开发者自行书写的上一轮回答。这种方式适用于演示、测试或需要精确控制上下文内容的场景真实场景在 TaskingAI 的 Assistant 体系中历史消息应当通过taskingai.assistant.list_messages从会话chat中读取以保证消息的真实性与完整性。4.3 AssistantMessage 的扩展字段从源码看ChatCompletionAssistantMessage除了content之外还带有一个可选字段function_calls类型为List[ChatCompletionFunctionCall]用于承载助手在函数调用场景下发起的工具调用请求参考 backend/app/models/inference/chat_completion.py。因此AssistantMessage既可以是纯文本回复也可以是请求调用某个函数的中间消息这一点在多轮工具编排中至关重要。五、掌握 configs模型生成参数详解模板的 REST API 示例中出现了configs参数configs: { temperature: 0.5 }configs是每次调用可选的模型配置字典。从推理服务的配置模型定义看TaskingAI 支持以下标准生成参数见 inference/app/models/chat_completion/model_config.py参数类型作用temperaturefloat采样温度控制输出随机性取值通常在 0~1 之间top_pfloat核采样阈值只从累积概率达到 top_p 的候选词中采样top_kint仅从前 k 个概率最高的候选词中采样max_tokensint生成的最大 token 数控制回答长度stopstr / List[str]停止词命中即终止生成presence_penaltyfloat存在惩罚鼓励谈论新话题frequency_penaltyfloat频率惩罚抑制重复用词seedint随机种子用于复现确定性输出response_formatstr输出格式约束如 JSON 模式关键机制configs并非随意填写。在推理服务端validate_chat_completion_model会根据模型 schema 中声明的config_schemas约束逐项校验 configs——不在白名单内的参数会被置空非 verify 模式或直接报错verify 模式不满足类型约束的值也会被拒绝参考 model_config.py。也就是说不同模型允许的 configs 集合由该模型自身的 schema 决定这也解释了为何不同厂商模型需要差异化配置。5.1 模型默认配置与请求配置的合并在后端路由层请求中的configs会与模型自身保存的默认configs合并模型默认配置为基底请求配置按 key 覆盖configs {**model_configs, **input_configs}见 backend/app/routes/inference/chat_completion.py。因此你可以在模型上预设常用参数单次调用时只传需要覆盖的项。六、理解响应结构一次非流式调用成功后返回的chat_completion_result对应ChatCompletion对象其核心字段定义于 inference/app/models/chat_completion/chat_completion.py字段类型说明objectstr固定为ChatCompletionfinish_reasonenum结束原因stop正常结束、length达到长度上限、function_calls请求调用函数、error、recitation、unknownmessageChatCompletionAssistantMessage模型生成的消息含content与可选的function_callscreated_timestampint响应创建时间戳毫秒usageChatCompletionUsage计费信息input_tokens与output_tokensfallback_indexOptional[int]命中的回退模型序号启用模型 fallback 时出现其中finish_reason是判断调用意图的关键若为function_calls说明模型没有直接回答而是请求调用某个函数这是工具调用流程的信号。七、从单轮到流式与函数调用能力延伸模板末尾提到关于 chat completion 的流式模式stream mode与函数调用function calls的更多信息请参考官方文档。这两项能力在仓库源码中有完整实现这里从代码层面给出关键支撑便于你按需扩展。7.1 流式输出Streaming / SSE非流式调用会阻塞直到完整结果生成流式模式则通过 Server-Sent EventsSSE逐块返回增量内容。请求体中的stream字段默认False控制该行为见 backend/app/schemas/model/chat_completion.py。在服务端流式结果由ChatCompletionChunk表示每个 chunk 包含index块序号、delta增量文本与created_timestamp见 inference/app/models/chat_completion/chat_completion.py。后端以text/event-stream媒体类型返回每个数据块以data: {json}\n\n格式输出并以SSE_DONE_MSG结束见 backend/app/routes/inference/chat_completion.py。从源码看流式能力并非所有模型都具备——模型 schema 中有streaming属性路由层在流式请求前会检查model.allow_streaming()不支持则返回校验错误backend/app/routes/inference/chat_completion.py。7.2 函数调用Function Call函数调用让模型在需要时请求调用工具而不是直接给出文本答案是实现 Agent 与工具编排的基石。请求侧通过两个参数控制functions函数定义列表JSON Schema 格式描述函数名、描述与参数结构function_call调用策略可选none不调用、auto模型自行决定或指定具体函数名强制调用见 backend/app/schemas/model/chat_completion.py。函数定义模型ChatCompletionFunction中参数部分支持string、number、integer、boolean、array、object等类型array类型可声明itemsstring类型可声明enum每个参数描述最长 512 字符见 backend/app/models/inference/chat_completion_function.py。当模型决定调用函数时响应中的message.function_calls会携带id、name与arguments结构化参数字典。推理服务端还有专门的build_function_call逻辑解析模型返回的参数字符串并将其转换为结构化字典见 inference/app/models/chat_completion/model.py。与流式一样函数调用也需要模型本身支持——请求携带functions时会检查model.allow_function_call()不支持则报错backend/app/routes/inference/chat_completion.py。八、进阶调用形态REST API 与 OpenAI 兼容 API除 Python SDK 外TaskingAI 还提供 REST API 与 OpenAI 兼容 API 两种调用形态代码模板分别位于backend/resources/code_templates/model/3_rest_api/1_inference/1_chat_completion.md原生 RESTbackend/resources/code_templates/model/4_openai_compatible_api/1_stateless_invocation/1_chat_completion.mdOpenAI 兼容8.1 原生 REST API原生接口为POST /v1/inference/chat_completion请求体结构与 SDK 对应curl -X POST $$SERVICE_HOST$$/v1/inference/chat_completion \ -H Authorization: Bearer $$API_KEY$$ \ -H Content-Type: application/json \ -d { model_id: $$MODEL_ID$$, configs: {temperature: 0.5}, stream: false, messages: [ {content: What is the sum of 12 23?, role: user} ] }多轮场景只需把历史消息按顺序加入messages数组user → assistant → user。model_id字段同时支持模型 ID 与 Assistant ID——传入 Assistant ID 时后端会走StatelessNormalSession/StatelessStreamSession会话流程由 Assistant 编排模型、检索与工具见 backend/app/routes/inference/chat_completion.py。8.2 OpenAI 兼容 API若你的代码已基于 OpenAI SDK可直接将base_url指向 TaskingAI 服务、api_key换成 TaskingAI API Keyfrom openai import OpenAI client OpenAI( api_key$$TASKINGAI_API_KEY$$, base_url$$SERVICE_HOST$$/v1, ) response client.chat.completions.create( model$$MODEL_ID$$, messages[ {role: user, content: What is the sum of 12 23?}, ], ) print(response)后端将 OpenAI 格式的请求适配为内部ChatCompletionRequest后统一处理见 backend/app/routes/openai/chat_completion.py 中的adapt_openai_chat_completion_input调用从而以极低迁移成本复用既有 OpenAI 生态工具链。九、底层调用链一次 chat_completion 的完整旅程从模板中的 SDK 调用到最终模型响应一条完整的链路如下SDK 层taskingai.inference.chat_completion构造消息对象并发起 HTTP 请求后端 API 层POST /v1/inference/chat_completion接收ChatCompletionRequest校验消息角色、函数调用能力与流式能力合并模型默认配置与请求配置backend/app/routes/inference/chat_completion.py服务层chat_completion/stream_chat_completion将请求转发至独立的推理服务TASKINGAI_INFERENCE_URL/v1/chat_completion携带model_schema_id、provider_model_id、加密后的凭证encrypted_credentials、模型属性与配置backend/app/services/inference/chat_completion.py推理服务层validate_chat_completion_model校验配置合法性随后由对应厂商的 Provider 适配器完成真实推理响应回传非流式直接返回ChatCompletion流式则按 SSE 协议逐块推送ChatCompletionChunk。值得注意的细节是模型回退fallback机制当主模型调用失败时后端会按base_model.fallbacks.model_list依次尝试备用模型全部失败才统一抛出 Provider 错误并将主模型的错误信息附带在响应中见 backend/app/routes/inference/chat_completion.py。这一机制大幅提升了线上推理的可用性也是生产环境中值得重点使用的特性。十、写在最后从模板到生产的建议消息顺序是上下文的关键多轮对话务必按system → user → assistant → ...的时间顺序传递完整历史configs 与模型 schema 强绑定并非所有参数对所有模型生效填写前先确认目标模型的config_schemas约束流式与函数调用需要模型能力支撑调用前可通过模型属性streaming、function_call确认能力边界善用 fallback 与 OpenAI 兼容层前者保障稳定性后者降低既有代码的迁移成本。如需深入了解流式模式与函数调用的完整示例可继续阅读仓库中的 REST API 模板 与 OpenAI 兼容 API 模板若你使用异步代码还可参考 异步 Python 模板其中使用await taskingai.inference.a_chat_completion(...)完成同样的单轮与多轮对话。赞分享人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载相关推荐BG3ModManager深度解析打造完美博德之门3模组体验的专业指南BG3ModManager深度解析打造完美博德之门3模组体验的专业指南 BG3ModManager作为《博德之门3》玩家必备的模组管理神器凭借其直观的操作界人工智能大模型AI AgentRAG后端前端TaskingAI 实战指南使用 Python SDK 的 get_chat 获取指定对话Chat完整解析TaskingAI 实战指南使用 Python SDK 的 get_chat 获取指定对话Chat完整解析 本文聚焦 TaskingAI 后端 Assis人工智能大模型AI AgentRAG后端前端Apache Artemis安全配置实战从认证授权到SSL/TLS加密全流程Apache Artemis安全配置实战从认证授权到SSL/TLS加密全流程 Apache Artemis是一款高性能、可扩展的开源消息中间件在企业级消息队消息队列后端网络与通信上一篇SQLite3绑定类型错误分析与修复Duix-Avatar数据库操作优化方案下一篇r2modmanPlus 错误处理与调试技巧常见问题排查与解决方案大全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考