大模型人工智能微调本地部署AI AgentRAG【免费下载链接】ChatGLM3ChatGLM3 series: Open Bilingual Chat LLMs | 开源双语对话语言模型项目地址https://gitcode.com/gh_mirrors/ch/ChatGLM3点击查看免费下载本篇文章完整解读 ChatGLM3 系列开源模型所采用的全新对话格式Chat Format。该格式是 ChatGLM3 在项目仓库中统一多轮对话、工具调用Tool Agent与代码解释器Code Interpreter三类任务的输入骨架其规范定义见 PROMPT.md。读完本文你将掌握|system|、|user|、|assistant|、|observation|四种角色的拼接规则与防注入设计原理理解仓库中 conversation.py、demo_tool.py、demo_ci.py 等示例是如何逐 token 解析这套格式的并能在自己的应用中正确构造与解析 ChatGLM3 的对话输入。为什么 ChatGLM3 需要一套全新的对话格式传统对话模型通常用用户/ 助手之类的纯文本拼接来组织上下文且代码执行、工具调用等任务往往各自有独立的 prompt 模板彼此之间难以互通。ChatGLM3 设计全新对话格式主要有两个目标见 PROMPT.md 开篇说明避免用户输入的注入攻击对话头中的角色标记如|user|使用special token表示无法从文本形式被 tokenizer 编码因此用户即使把|user|、|assistant|之类字符串写进自己的输入也不会被模型误解为角色切换指令。统一 Code Interpreter、Tool Agent 等任务的输入无论是普通闲聊、让模型调用天气工具还是让它写 Python 代码并执行都采用同一套角色框架降低上层应用接入成本。整体结构对话 对话头 内容ChatGLM3 的对话由若干对话conversation组成每个对话包含对话头与内容两部分。一个典型的多轮对话结构如下|system| You are ChatGLM3, a large language model trained by Zhipu.AI. Follow the users instructions carefully. Respond using markdown. |user| Hello |assistant| Hello, Im ChatGLM3. What can I assist you today?需要说明的是实际中每轮对话内容并不一定以换行符结尾示例中的换行只是为了美观。在仓库的流式输出实现中client.py 将每轮对话经由tokenizer.build_chat_input(query, historyhistory, rolerole)编码为模型输入即历史列表中的每条记录最终都会按这套结构拼进输入序列。对话头规范|role|{metadata}对话头占完整的一行格式为|role|{metadata}其中|role|部分使用special token表示无法从文本形式被 tokenizer 编码以此防止注入攻击metadata部分采用纯文本表示是可选内容。四种角色及其约束如下引自 PROMPT.md|system|系统信息。设计上可穿插于对话中但目前规定仅可以出现在开头|user|用户。不会连续出现多个来自|user|的信息|assistant|AI 助手。在出现之前必须有一个来自|user|的信息|observation|外部的返回结果如工具调用返回值、代码执行结果。必须在|assistant|的信息之后。从源码结构看这四种角色在仓库中有明确映射在 conversation.py 中定义了Role枚举Role.SYSTEM / USER / ASSISTANT / TOOL / INTERPRETER / OBSERVATION的字符串表示分别为|system|、|user|、|assistant|其中 TOOL 与 INTERPRETER 也归为|assistant|、|observation|——这与TOOL、INTERPRETER都通过|assistant|的 metadata 来区分的格式设计一一对应。metadata 的作用区分普通回复与动作metadata 是对话头中紧随角色名之后的纯文本是判断当前|assistant|是在说话还是在执行动作的关键工具调用时|assistant|的 metadata 为工具名如|assistant|get_current_weather代码执行时|assistant|的 metadata 只有interpreter即|assistant|interpreter。openai_api_demo/utils.py 中的process_response正是按此规则解析它把模型输出按|assistant|分割若 metadata 为空则为普通文本回复若 metadata 非空且启用了工具则识别为一次函数调用返回形如{name: 工具名, arguments: JSON 参数}的结构。样例场景一多轮对话基础格式多轮对话是最简单的场景有且仅有|user|、|assistant|、|system|三种 role不允许出现|observation||system| You are ChatGLM3, a large language model trained by Zhipu.AI. Follow the users instructions carefully. Respond using markdown. |user| Hello |assistant| Hello, Im ChatGLM3. What can I assist you today?在仓库的 basic_demo/cli_demo.py 中构建历史 prompt 时把用户输入与模型回复按顺序追加到对话历史再由model.stream_chat(...)维护多轮上下文而 basic_demo/web_demo_gradio.py 与 web_demo_streamlit.py 则展示了 Web 界面下的同格式多轮交互。样例场景二工具调用Tool Agent工具调用在基础多轮对话之上引入了工具描述tools 列表、动作发起与观察结果回填三个新要素。完整示例见 PROMPT.md|system| Answer the following questions as best as you can. You have access to the following tools: [ { name: get_current_weather, description: Get the current weather in a given location, parameters: { type: object, properties: { location: { type: string, description: The city and state, e.g. San Francisco, CA, }, unit: {type: string}, }, required: [location], }, } ] |user| 今天北京的天气怎么样 |assistant| 好的让我们来查看今天的天气 |assistant|get_current_weather python tool_call(locationbeijing, unitcelsius) |observation| {temperature: 22} |assistant| 根据查询结果今天北京的气温为 22 摄氏度。解析这段完整流程系统消息携带工具清单|system|后紧跟固定引导语Answer the following questions as best as you can. You have access to the following tools:以及 JSON Schema 风格的工具定义数组。工具定义包含name、description、parameters含type、properties、required等字段。模型发起工具调用第二个|assistant|的 metadata 是工具名get_current_weather其内容是一个 Python 代码块通过tool_call(locationbeijing, unitcelsius)表达需要传给工具的参数。外部返回结果|observation|承载真实工具执行的返回如{temperature: 22}模型据此生成最终回复。工具调用在仓库中的真实实现工具定义与注册tools_using_demo/tool_register.py 提供register_tool装饰器从 Python 函数的签名、docstring 与typing.Annotated类型标注自动生成上述 JSON 工具描述保证定义格式与示例一致以获得最优性能。工具调用 Demotools_using_demo/cli_demo_tool.py 展示了以roleobservation把工具返回值喂回模型、并依据response是str还是dict判断继续对话还是继续调用工具的完整循环。注意官方文档明确目前 ChatGLM3-6B 的工具调用只支持通过chat方法不支持stream_chat方法见 tools_using_demo/README.md。流式解析工具调用composite_demo/demo_tool.py 逐 token 消费生成流遇到|assistant|特殊 token 即认为开始工具调用遇到|observation|则把输出文本按行拆分首行是工具名剩余内容用正则extract_code提取代码块、以eval(code, {tool_call: tool_call}, {})解析出参数随后调用dispatch_tool(tool, args)执行并把结果回填为Role.OBSERVATION。多轮历史构造composite_demo/conversation.py 的preprocess_text按|system|\n 系统提示有工具时替换为TOOL_PROMPT 工具 JSON 历史对话 |assistant|\n的顺序拼装最终 prompt并在 client.py 中把Conversation列表转成带role/metadata/content的 chat history 提交给stream_chat。样例场景三代码执行Code Interpreter代码执行场景允许出现全部四种 role|user|、|assistant|、|system|、|observation|其中|assistant|的metadata 只有 interpreter。完整示例见 PROMPT.md这里摘录关键流程|system| 你是一位智能AI助手你叫ChatGLM3你连接着一台电脑但请注意不能联网。在使用Python解决任务时你可以运行代码并得到结果如果运行结果有错误你需要尽可能对代码进行改进。你可以处理用户上传到电脑上的文件文件默认存储路径是/mnt/data/。 |user| #File: /mnt/data/metadata.jsonl #Size: 35380 #File uploaded 文件中是否存在缺失值或异常值 |assistant| 首先我将读取您提供的文件并查看其内容以确定是否存在缺失值或异常值。 我们从加载文件开始 |assistant|interpreter python import json # Load the uploaded file data [] with open(/mnt/data/metadata.jsonl, r) as file: for line in file: data.append(json.loads(line)) # Display the first few records to get a sense of the data data[:5] |observation| result [{file_name: aceinthehole.png, ...}] |assistant| 该文件看起来包含有关某些条目的元数据……该示例展示了代码执行的三段式循环模型先用普通|assistant|文字说明思路 → 再用|assistant|interpreter附带 Python 代码块 → 代码在沙箱/内核中执行后以|observation|中包裹result ... 的形式返回输出文本或[Image]。此后模型可继续写代码如检查缺失值、统计 type 分布、用 matplotlib 画爱心直到完成回答。代码执行在仓库中的真实实现系统提示一致composite_demo/demo_ci.py 中定义的SYSTEM_PROMPT与 PROMPT.md 代码执行示例的系统消息完全一致你是一位智能AI助手你叫ChatGLM…文件默认存储路径是/mnt/data/。执行内核composite_demo/demo_ci.py 的CodeKernel基于jupyter_client启动 IPython 内核可通过环境变量IPYKERNEL指定内核名默认chatglm3-demoexecute(code)同步提交代码并轮询消息直到内核空闲返回标准输出或image/png结果。输出清洗composite_demo/demo_ci.py 在执行前会剥除输出文本中残留的|observation|、|assistant|interpreter、|assistant|等特殊 tokenconversation.py 的postprocess_text同样会把|assistant|、|observation|、|system|、|user|从展示文本中剔除避免角色 token 泄漏到用户界面。从源码看对话格式的底层机制1. 特殊 token 参与停止条件在 composite_demo/client.py 与 openai_api_demo/utils.py 中eos_token_id均被设置为[tokenizer.eos_token_id, tokenizer.get_command(|user|), tokenizer.get_command(|observation|)]。这意味着模型生成到|user|或|observation|时就会停止——与格式规定中|assistant|之后要么轮到用户、要么轮到外部 observation的结构约束完全呼应从生成侧保证了对话不会越界。2. 角色 token 参与停止序列composite_demo/demo_tool.py 与 demo_ci.py 都把stop_sequences设置为|user|与|observation|的字符串形式流式生成时一旦命中即截断并进入相应的角色分支处理。3. 防注入的具体落地对话头中的角色标记是 special token用户文本无论怎么写都无法被编码成这些 token这是从 tokenizer 层面杜绝注入而postprocess_text/process_response等工具函数则在展示层进一步清洗这些标记防止其被当作普通文本展示或二次注入如 openai_api_demo/utils.py 的process_chatglm_messages会把 OpenAI 风格消息转换为 ChatGLM3 角色其中function角色的返回被转换为observation。实际使用中的注意事项换行符为提升可读性示例中角色 special token 前额外添加了换行符实际使用及 tokenizer 实现中均无需额外添加这一换行见 PROMPT.md 说明。角色顺序约束|system|目前只能出现在开头|user|不能连续出现|assistant|之前必须有|user||observation|必须紧跟|assistant|或其后续动作之后。违反这些约束会破坏模型对上下文的解析。工具调用与流式ChatGLM3-6B 的工具调用目前仅支持chat方法见 tools_using_demo/README.mdroleobservation参数在回填工具结果时不可省略。多次工具调用复杂问题模型可能连续发起多次工具调用可通过判断返回的response是str还是dict来区分最终回复与新一轮工具调用请求。超长输入与截断composite_demo/client.py 对输入序列长度与max_new_tokens之和做了上限检查超限时给出调整生成参数的提示工具/代码执行结果也可通过truncate_length截断demo_tool.py。小结ChatGLM3 的对话格式以四种角色|system|、|user|、|assistant|、|observation| 可选 metadata 为核心既用 special token 从编码层面杜绝注入又把多轮对话、工具调用metadata工具名与代码执行metadatainterpreter统一在同一个输入框架内。仓库中的 composite_demo含 conversation.py、demo_tool.py、demo_ci.py、client.py、tools_using_demo、openai_api_demo 与 langchain_demo 提供了从拼装、解析到执行的完整参考实现是深入理解并二次开发这套对话格式的最佳起点。赞分享大模型人工智能微调本地部署AI AgentRAG【免费下载链接】ChatGLM3ChatGLM3 series: Open Bilingual Chat LLMs | 开源双语对话语言模型项目地址https://gitcode.com/gh_mirrors/ch/ChatGLM3点击查看免费下载相关推荐Claude Sonnet 4 系统提示词深度解析基于 leaked-system-prompts 泄露文档的行为规范拆解与演化对比Claude Sonnet 4 系统提示词深度解析基于 leaked system prompts 泄露文档的行为规范拆解与演化对比 本文以开源仓库 leak人工智能大模型提示工程ChatGPT 语音助手系统提示词全解析GPT-4o-mini Voice Mode 的人格设定与对话规范剖析ChatGPT 语音助手系统提示词全解析GPT 4o mini Voice Mode 的人格设定与对话规范剖析 导读 本文基于本仓库中泄露的 openai c人工智能大模型提示工程ChatGPT-5 系统提示词全解来自 leaked-system-prompts 的完整工具链与人格规范分析ChatGPT 5 系统提示词全解来自 leaked system prompts 的完整工具链与人格规范分析 本文基于开源仓库 leaked system人工智能大模型提示工程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考