深入解析 SurfSense 主 Agent 的 DeepSeek 供应商提示词：推理卫生、工具并行与引用纪律-港品优选

深入解析 SurfSense 主 Agent 的 DeepSeek 供应商提示词：推理卫生、工具并行与引用纪律

【免费下载链接】SurfSenseOpen-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok, Indeed, Google Search, Maps etc) through one platform, API or MCP server. Join our Discord: https://discord.gg/ejRNvftDp9项目地址: https://gitcode.com/GitHub_Trending/su/SurfSense

SurfSense 是一个开源的 NotebookLM 替代品，支持通过统一平台、API 或 MCP 服务器检索 Reddit、YouTube、Instagram、TikTok、Indeed、Google 搜索与地图等公开网络实时数据。为了让不同供应商的模型都能以一致的风格驱动"主 Agent"（main agent），SurfSense 在仓库中为每家模型供应商维护了一份独立的提示词片段——provider_hints。本文以 DeepSeek 专用提示词 deepseek.md 为核心，结合其背后的组装器、加载器与配套提示词，逐条拆解这份提示词如何约束模型行为，并剖析它在 SurfSense 多 Agent 系统中的真实落地方式。

一、导读：这份提示词文件解决什么问题

在多 Agent 系统中，同一个"主 Agent"可能被配置运行在不同供应商的模型上：DeepSeek、Kimi、Anthropic Claude、Google Gemini、OpenAI 系列等。不同模型在推理风格、工具调用能力、输出偏好上差异巨大——例如 DeepSeek 的推理模型（R1 系列）会在内部生成思考链，而经典对话模型则不会。如果不做区分，一套通用的系统提示词很难让每个模型都发挥出最佳行为。

SurfSense 的解法是：为每家供应商准备一份轻量的<provider_hints>提示词，在系统提示词组装时按当前运行的模型动态注入。deepseek.md就是其中面向 DeepSeek 系列模型的专属配置，全文仅 18 行，却覆盖了四个关键行为域：推理卫生、输出风格、引用纪律、工具调用。

阅读完本文，你将掌握：

SurfSense 主 Agent 系统提示词的分层组装机制，以及供应商提示词在其中的插入位置；
DeepSeek 提示词中每一条规则的意图，以及它们在多 Agent 检索场景中的实际作用；
引用开关（citations on/off）如何与供应商提示词协同，避免模型误用[citation:…]标记；
如何扩展新的供应商提示词，让主 Agent 适配更多模型。

二、供应商提示词在系统提示词中的位置与加载机制

2.1 分层的提示词架构

主 Agent 的系统提示词并非一个巨型文件，而是由若干片段按固定顺序拼装而成。组装逻辑集中在 compose.py，文件头部的注释给出了完整的默认组装顺序：

<agent_identity> [user's custom_system_instructions, if any] <core_behavior> # 默认主体 <knowledge_base_first> # 默认主体 <dynamic_context> # 总是注入 <routing> # 默认主体 <specialists> # 总是注入（动态专家名单） <tools> # 总是注入（纵向切片） <memory_protocol> # 默认主体 <citations> # 总是注入 <output_format> # 总是注入 <refusal_and_limits> # 总是注入 <reminder> # 总是注入

对应地，prompts/ 目录下按类别组织了一组 Markdown 片段：core_behavior.md、kb_first.md、routing.md、output_format.md、refusal_and_limits.md、reminder.md等。其中citations/on.md与citations/off.md根据引用开关二选一注入，而providers/目录则存放按模型供应商区分的提示词。

2.2 提示词加载器

片段加载由 load_md.py 完成。它通过 Python 标准库的importlib.resources定位prompts/包内的资源文件，读取后去掉末尾换行返回：

_PROMPTS_PACKAGE = "app.agents.chat.multi_agent_chat.main_agent.system_prompt.prompts" def read_prompt_md(filename: str) -> str: ref = resources.files(_PROMPTS_PACKAGE).joinpath(filename) if not ref.is_file(): return "" text = ref.read_text(encoding="utf-8") return text[:-1] if text.endswith("\n") else text

值得注意的两点设计：

文件缺失不报错：read_prompt_md在目标文件不存在时返回空字符串，随后compose.py中的_wrap会把它过滤掉（return "".join(p for p in parts if p)）。这意味着某类提示词片段缺失时系统依然可以正常工作，具备容错性。
custom_system_instructions是叠加而非替换：compose.py的 docstring 明确说明用户自定义指令"additive, not a replacement"，它插在身份区段与默认主体之间，因此 KB 优先、路由、引用、输出格式、拒绝规则等平台安全网始终生效。

从代码结构看，providers/目录与compose.py中展示的组装顺序提示：供应商提示词是在"默认主体"（core behavior、kb_first 等）基础上按需追加的行为微调层，身份、工具、引用、输出格式等平台级约束对所有供应商一视同仁。

三、DeepSeek 供应商提示词逐条解读

deepseek.md 的完整内容以<provider_hints>标签包裹，正文分四个部分：

3.1 推理卫生（Reasoning hygiene，R1-aware）

Keep internal scratch separate from the user-facing answer; don't leak chain-of-thought into tool arguments.

这条规则专门针对 DeepSeek 的推理模型（R1 系列）设计。"R1-aware" 意味着提示词作者意识到：推理模型会在内部生成思考过程，如果不加约束，模型可能把思考链内容泄露到工具调用的参数里（例如把内部推理写进搜索 query，或把 scratch 内容当作最终回答的一部分）。

在 SurfSense 的多 Agent 检索场景中，主 Agent 需要把子任务分发给 knowledge_base、research 等专家 Agent（<specialists>区段动态生成专家名单），并调用 web_search、scraper 等工具。如果思考链污染了工具参数，会直接影响检索质量和结果可解释性。因此这条规则要求：内部草稿与面向用户的答案严格分离，工具参数只放真正需要的内容。

值得注意的是，model_list_fallback.json 中收录了deepseek/deepseek-r1、deepseek/deepseek-v3.1等多款 DeepSeek 模型，其中 R1 系列被标注为 671B 参数、37B 激活的推理模型。这印证了deepseek.md针对推理模型的约束并非无的放矢——仓库确实可能把 R1 这类推理模型接入主 Agent。

3.2 输出风格：直接、精炼、不谄媚

Concise; lead with the answer or the next action; avoid sycophantic openers.

这条约束与 openai_reasoning.md 中"Don't begin with conversational openers"的意图一致：在检索型 Agent 场景中，用户要的是答案本身，而不是"这是一个很好的问题"之类的寒暄。要求"以答案或下一步动作开头"，是为了让回答更高效、更适合后续被引用或呈现。

3.3 引用纪律：跟随引用块，绝不越界

When citations areenabledand facts come from chunk-tagged context, follow the citation block above. When citations aredisabled, do not use[citation:…].

这是deepseek.md中最需要与平台提示词协同的规则。<citations>区段（组装顺序中"总是注入"）决定引用格式的最终形态：

开启引用时，注入 citations/on.md：要求用单一 token 形式的方括号标签[n]引用，多个来源堆叠成[1][2]，严禁改写编号、自行发明标签或使用[citation:...]标记，也禁止输出 "References" 章节。
关闭引用时，注入 citations/off.md：明确禁止任何[n]标签和[citation:…]标记，即使工具输出（<retrieved_context>、<web_results>）或工具描述中出现了引用格式示例，也要忽略；要求以纯文本回答，不得向用户暴露原始 chunk id、文档 id 或内部 id。

供应商提示词在这里扮演的角色是提醒层：它不定义引用格式（那是 citations 区段的职责），而是确保模型"知道"当前引用开关状态，从而在工具输出自带[citation:…]示例时不会机械模仿。组装顺序中<citations>总是注入且位于供应商提示词之后，从结构上看，供应商提示词是对平台引用块的再确认与强化。

3.4 工具调用：并行化与防幻觉

Parallelise independent calls. For SurfSense docs/product questions, point the user to https://www.surfsense.com/docs. Don't invent paths, chunk ids, or URLs — only values from tools or the user.

最后三条构成工具调用的行为约束：

并行调用：多 Agent 场景下，主 Agent 可能同时需要多个数据源（Reddit、YouTube、Google 搜索等）。提示词要求对相互独立的调用并行发起，这与 Kimi 提示词 kimi.md 中"Output multiple non-interfering tool calls in a SINGLE response"的思路一脉相承——并行是检索效率的关键。
产品问题引导官方文档：对 SurfSense 自身文档/产品类问题，指向官方文档站点。这避免了模型用工具猜测或编造产品信息。
防幻觉：禁止编造路径、chunk id 或 URL，只允许使用来自工具或用户的真实值。这条与引用纪律形成组合拳——citations/on.md要求"Only label claims the sources support"，两者共同保证检索结果可溯源、可验证。

四、与其他供应商提示词的横向对比

providers/目录下共存放 9 份提示词：anthropic.md、deepseek.md、default.md、google.md、grok.md、kimi.md、openai_classic.md、openai_codex.md、openai_reasoning.md。

对比可见供应商提示词的差异化设计思路：

提示词	关注点	特色约束
deepseek.md	推理卫生、输出风格、引用、工具并行	R1-aware 思考链隔离；引用开关跟随；防幻觉
kimi.md	行动偏好、工具并行、语言、纪律	"以工具行动为默认"，`task`工具委派子任务，同语言回复
openai_reasoning.md	输出风格、渠道、工具并行、自主性	禁寒暄开头、列表扁平化、commentary/final 渠道、不征求许可
openai_codex.md	代码风格	面向 Codex 的工程化约束

从这些差异可以推断：SurfSense 的供应商提示词遵循"只声明该模型特有/敏感的行为约束，通用行为交给平台区段"的原则。例如工具并行是所有推理型/代理型模型都需要的，但各供应商提示词会以各自的措辞强调；引用格式、输出格式、拒绝规则等则统一在平台层，避免重复维护。

五、从源码结构看扩展方式

如果你想把主 Agent 适配一个新的模型供应商，从现有结构可以推断出清晰的扩展路径：

在 providers/ 目录下新建<vendor>.md，以<provider_hints>标签包裹，声明模型身份与专属行为约束；
参考deepseek.md的结构：先声明"你运行在哪个模型上"（模型身份），再按"推理卫生/输出风格/引用/工具调用"等维度列出约束；
保持平台区段（identity、tools、citations、output_format、refusal_and_limits、reminder）不变，供应商提示词只做叠加微调；
若供应商模型对推理链或输出格式有特殊偏好（如推理模型的思考链隔离、代码模型的工程化风格），在该文件中显式声明。

需要说明的是，从当前compose.py的公开组装逻辑看，供应商提示词片段的具体注入位置与触发条件（例如按model_name匹配的精确规则）未在该文件内直接体现，以上为基于目录结构与代码风格的推断，实际接入时建议查阅主 Agent 的运行时调用链。

六、总结

deepseek.md虽然只有 18 行，却是 SurfSense 多 Agent 系统中"供应商适配层"的典型样本。它用最精简的规则解决了四类实际问题：推理模型思考链隔离（R1-aware）、高效输出风格、与平台引用开关严格协同的引用纪律、以及并行工具调用与防幻觉。它与 compose.py 的分层组装机制、load_md.py 的容错加载、以及citations/on.md与citations/off.md的引用开关共同构成了一个可扩展的提示词工程架构——让同一个主 Agent 在 DeepSeek、Kimi、OpenAI、Anthropic、Google 等不同模型上都能保持一致的平台行为，同时发挥各自模型的特性。对于希望理解"如何在多模型 Agent 系统中优雅管理提示词"的开发者，这份文件是一个小而完整的范本。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析