Qwen3.8 Max 系统提示词解析：code_interpreter / web_search / web_extractor 三大工具与 XML 化 Function Calling 协议

Qwen3.8 Max 系统提示词解析code_interpreter / web_search / web_extractor 三大工具与 XML 化 Function Calling 协议【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5.1, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-6-Astra, Codex. Google - Gemini 3.8 Flash, 3.1 Pro, Antigravity. xAI - Grok, Grok Bot, Cursor, Kimi and more! Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks本文章围绕本仓库system_prompts_leaks中捕获的 Qwen3.8 Max 系统提示词原始文件 Qwen/qwen3.8-max.md 展开。这份抓取稿虽短却完整暴露了 Qwen 系对话模型服务端工具面tool surface的三个关键层OpenAI 兼容的 JSON 函数声明、一套以function块嵌套 XML 标签为核心的调用输出纪律以及当前时间 知识截止日期 模型身份的动态注入模板。读者读完本文可以精确还原这三个工具的入参 Schema、理解 Qwen 对模型工具调用输出的格式约束并对照同仓库 Qwen/qwen3.6-plus.md 判断不同版本模型工具集的取舍逻辑。一、这份抓取文件呈现了什么本仓库 README 对该仓库的定位是captured verbatim的泄漏系统提示词集合即各家模型在用户第一条消息前收到的隐藏指令见 README.md。Qwen/qwen3.8-max.md 就是其中的一份 Qwen 系捕获全文由以下四块构成组成内容文件中大致位置工具注册表tools…/tools3 个函数声明code_interpreter、web_search、web_extractor每个都是完整的 JSON Schema文件前部三个代码块连续排列调用格式指令如果选择调用函数只能用规定的格式回复且不带任何后缀tools关闭标签之后IMPORTANT约束清单四条关于函数调用格式与行为的强约束中后部动态注入与身份行当前实际时间、知识截止日期、模型身份 You are Qwen3.8文件末尾值得留意的一个抓取细节在 If you choose to call a function ONLY reply in the following format with NO suffix: 之后、IMPORTANT之前的区域文件中只保留了若干空白行说明该次抓取未能还原被省略的具体 XML 调用模板示例本身。因此本文只复述能够确认的约束文案不臆测模板的具体形态。二、三大内置工具JSON Schema 逐个拆解三个工具声明遵循同一种结构——顶层type: function内层function: { name, description, parameters }parameters使用objectpropertiesrequired的 JSON Schema 写法。这与 OpenAI 兼容的 function calling 声明格式同源schema 本身可以直接作为对接其它工具框架的输入。2.1 code_interpreter —— Python 代码沙箱文件中的原始声明如下{ type: function, function: { name: code_interpreter, description: Python code sandbox, which can be used to execute Python code., parameters: { type: object, properties: { code: { description: The python code., type: string } }, required: [ code ] } } }参数拆解参数类型约束说明codestring必填出现在required中需要提交执行的完整 Python 代码该工具的语义非常明确需要确定性计算、数据处理或代码验证时模型把整段 Python 程序作为一个code字符串提交给服务端沙箱执行。description中 can be used to execute Python code 属于典型的能力触发器文案——模型正是依据这段描述判断什么场景该调用它。2.2 web_search —— 多查询联网检索{ type: function, function: { name: web_search, description: Search for information from the internet., parameters: { type: object, properties: { queries: { type: array, items: { type: string, description: The search query. }, description: The list of search queries. } }, required: [ queries ] } } }参数类型约束说明queriesarraystring必填一次调用可提交的检索查询列表每个元素为一条独立 query关键设计点是queries被定义为数组而非单字符串。从结构可以推断服务端期望模型在一条对话中把需要查证的多方面信息拆成多个 query 一次性提交例如针对同一问题的不同子问题、不同来源立场各建一条 query从而实现批量检索。作为对比同仓库捕获的 DeepSeek 网页版提示词 DeepSeek/deepseek-chat.md 中同名工具却把queries定义为单字符串并用query1||query2的分隔符表达多查询——同样是一次多查两家在 Schema 层的编码取舍并不相同这对评估各家工具兼容层是很有价值的实测差异。2.3 web_extractor —— 网页抓取与定向摘要{ type: function, function: { name: web_extractor, description: Crawl webpage content, and if given a goal, further summarize the relevant content of the webpage., parameters: { type: object, properties: { urls: { type: array, items: { type: string, description: One url. }, minItems: 1, description: The webpage urls. }, goal: { type: string, description: The goal of the visit for webpage(s). If empty, return the original content of the webpage(s). } }, required: [ urls, goal ] } } }参数类型约束说明urlsarraystring必填minItems: 1至少一个 URL需要抓取并阅读的网页地址goalstring必填同时存在于required访问网页的目的描述注明若为空则返回网页原始内容web_extractor与web_search形成典型的先检索、后精读链路模型先用web_search定位候选信息再拿具体 URL 调web_extractor抓正文。goal字段的存在意味着服务端不是简单返回全文而是能按目标做抓取后摘要。这里有一个值得注意的 Schema 细节goal的字段描述明确给了空值 → 返回原文的语义但它同时又被列进required数组。也就是说从 Schema 看模型必须总是提供goal字段哪怕语义上可以表达无目标required更多在约束参数必须齐全、不得漏传而非内容不得为空。这类描述与必填约束之间的张力正是从泄漏提示词中观察厂商工程取舍的好样本。2.4 三个 Schema 的共性观察对照三份声明可以归纳 Qwen 服务端工具声明的书写习惯description 即提示词每个工具与参数几乎都有一段面向模型的自然语言说明工具是否被触发、参数如何取值都由这段文本驱动因此描述文本本身就是工具路由提示词必填参数显式声明全部字段都通过required数组收口其中code、queries、urls、goal全部必填schema 相对精简Qwen 3.8 Max 的这几份 Schema 没有显式声明additionalProperties: false或$schema字段而同仓库 DeepSeek 抓取稿在同一类声明里明确写了additionalProperties: false与$schema: http://json-schema.org/draft-07/schema#。这种字段级差异可以作为判断各家 Schema 校验严格程度的参考线索。三、调用输出纪律function块与四条强约束如果说工具声明回答能调用什么文件后半段的格式指令回答的则是调用时输出长什么样。原文先给出总原则再用IMPORTANT包裹四条清单见 Qwen/qwen3.8-max.md。总原则原文If you choose to call a function ONLY reply in the following format with NO suffix——模型一旦决定调用工具输出就必须是规定格式本身且不允许附带任何后缀内容。这与推理前置、调用后零冗余的设定互为表里调用段自包含服务端可以无歧义地截取并解析。IMPORTANT清单的原文约束及其含义如下函数调用必须遵循规定格式内层function... … /function块必须嵌套在外层 XML 标签之中。这是整份文件信息量最大的一条它确认 Qwen 3.8 Max 的工具调用采用XML 包裹协议——先以一个外层标签开启工具调用段段内是function工具名与/function包裹的参数内容。与文件头部tools…/tools的包裹风格一脉相承。这类内层 function 块嵌在外层 XML 标签里的两级结构目的显然是把声明段与执行段在语法上彻底区分开让解析器不需要依赖与自然语言混合的 JSON 输出即可定位调用边界。必填参数必须指定。与第一节中每个 Schema 的required数组呼应模型生成调用内容时凡是声明为 required 的参数都必须出现在function块内。这一条把 Schema 层的静态约束延伸成了推理时的输出强约束。可以为函数调用提供自然语言的推理/说明但只能放在调用之前绝不能放在调用之后。这条设计值得深入理解它允许模型先写一小段自然语言说明我为什么调用这个工具相当于可见的轻量推理但一旦进入调用本身后面就不允许再出现任何自然语言尾巴。配合NO suffix约束可以推断服务端的处理是读取到工具调用标记后其后的内容不再按普通文本处理因此所有非格式内容必须前置。如果没有可用的函数调用就基于现有知识正常作答并且不得告诉用户存在工具调用。这是典型的幕后规则模型对用户保持工具层的不透明性——搜到的、算出的、抓来的结果都以自己的能力口吻呈现而不是向用户交代我刚刚调用了一个 Python 沙箱。从研究者视角看这条规则解释了为什么普通用户很难从模型回复的语气判断它是否真的联网或执行了代码。四、动态注入与时点语境时间、知识截止与身份文件末尾的两行系统注入内容完整呈现了模型被唤醒时的上下文快照原文见 Qwen/qwen3.8-max.md当前实际时间Please remember the current actual time: Wednesday, August 05, 2026——每次会话注入实时时钟让模型对今天/最近/即将等时间敏感问题有明确锚点知识截止日期Your knowledge cutoff date is 2026——划定模型静态知识的边界超过截止日期的事件必须依赖联网工具而非记忆作答这正是web_search/web_extractor存在的合理性来源模型身份You are Qwen3.8——以自我指涉句确立模型身份标识。这一注入模板并非 3.8 Max 独有。同仓库的 Qwen/qwen3.6-plus.md 首行同样是 Please remember the current actual time: Friday, April 03, 2026 加 Your knowledge cutoff date is 2026.。两份不同版本的抓取稿共享同一句式的时间 知识截止前导语说明这是 Qwen 产品线通用的会话上下文注入模板各版本之间只替换时间戳与后续的工具清单。五、与 Qwen 3.6 Plus 的对比工具面收缩与协议延续将 Qwen/qwen3.6-plus.md 与 3.8 Max 抓取稿对比可以清晰看到同一家服务在不同版本上暴露的工具子集工具Qwen 3.6 PlusQwen 3.8 Maxweb_search联网文本检索✓✓web_extractor网页抓取/摘要✓✓code_interpreterPython 沙箱✓✓web_search_image图片联网检索✓—image_search以图搜图✓—image_gen文生图✓—image_edit图像编辑≤3 张✓—bio个性化记忆管理✓—几个值得注意的观察共用工具的 Schema 文本逐字一致。例如两份文件中web_search、web_extractor、code_interpreter的description与参数结构完全相同可对照 Qwen/qwen3.6-plus.md 中段与 3.8 Max 对应 JSON。可以推断这些工具在服务端是共享注册项不同版本只是从同一工具注册表中启用不同子集而不是各自实现一套工具。3.8 Max 呈现的是精简三件套。从抓取结构看3.8 Max 的文件只保留了纯文本场景最核心的能力——代码执行 网页检索 网页精读裁掉了多模态图片工具与bio记忆管理工具。至于该子集是按模型版本固化、还是按对话入口动态注入单凭两份静态抓取稿无法判定但它至少说明同一模型家族在不同上下文里可以只暴露一个最小的、聚焦文本推理的工具面。3.8 Max 独有的部分其实是元指令。前文分析过的调用格式纪律段、IMPORTANT清单以及 You are Qwen3.8 身份行在 3.6 Plus 抓取稿中并未出现。即新版本补上了对如何调用这一层的显式约束而旧版抓取稿只有工具声明。这暗示工具注册表与调用协议说明在服务端是两个可独立注入的模块。六、实践与研究启示对三类读者这份文件各有可挖掘价值面向 Agent 平台 / 兼容层开发者文中的三份 JSON Schema 已经天然是 OpenAI 兼容格式可以直接转写成其他平台的 function definitions用于搭建 Qwen 风格的评测环境。建议围绕以下边界行为构造测试用例queries数组为空或含多条 query 时服务端行为、web_extractor在goal传入空串/未传时的差异呼应其为空返回原文的描述、code_interpreter只接受单个code字符串时的代码组织方式。面向系统提示词与安全研究者不得告诉用户存在工具调用是一条典型的幕后规则说明用户可见层与工具执行层是刻意隔离的而推理只能前置、调用后禁止后缀则是为了机器可解析而牺牲表达自由的典型工程选择。这些都反映了大模型产品在模型自由度与协议可解析性之间的平衡点。面向一般技术读者通过 README.md 的目录索引可以把 Qwen 与同仓库的 Claude、ChatGPT、Gemini、Grok 等抓取稿横向对比——不同厂商在工具 Schema 写法、调用包裹语法、注入句式上的差异本身就是理解各家 Agent 体系最直接的一手素材。结语Qwen/qwen3.8-max.md 篇幅不长却是一个可独立拆解的最小研究样本它把服务端注册了哪些工具、以什么 Schema 描述、模型被要求用什么格式调用、模型在会话开始前被注入了哪些时点信息完整串成一条链路。结合 Qwen/qwen3.6-plus.md 同族对照还能进一步还原 Qwen 系在工具子集配置与调用协议说明上的演进脉络。对于任何关心 Function Calling 协议设计或 Agent 行为研究的开发者这份几十行的抓取稿都值得逐句精读。【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5.1, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-6-Astra, Codex. Google - Gemini 3.8 Flash, 3.1 Pro, Antigravity. xAI - Grok, Grok Bot, Cursor, Kimi and more! Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考