什么是系统提示？

Scrapeless MCP 服务器为 AI 客户端提供对 Scrapeless 网络工具的访问。

系统提示是一种在应用层面提供给生成式 AI 系统的指令文本，用于在交互过程中引导其行为。它可以描述助手的角色、任务边界、回复要求，以及对不同输入的处理方式。具体的消息角色和优先级规则取决于模型接口。

一个有用的系统提示为模型提供了稳定的行为契约。它本身不会强制实施访问控制、让不存在的工具可用，或保证答案正确。应将指令视为应用程序的一部分，而应用程序还会验证输入、限制操作并检查输出。

系统提示的用途

系统提示定义了应适用于应用程序所处理用户请求的行为。支持助手可能会被指示在产品范围内回答、区分缺失信息与否定性证据，并在进行特定查询前请求必需的账户标识符。这些要求应当足够具体，以便进行评估。

The system-prompt 定义 描述在上下文中提供的特定于应用的指令。这样的表述将这些指令与模型的已学习参数区分开来。更新系统提示会改变在使用过程中发送的指令；这与训练模型并不是同一种操作。

用可观测行为来撰写要求。与其要求助手“可靠”，不如具体规定当面对不被支持的论断或不完整信息来源时，它应如何处理。与其要求它“负责任”地行事，不如明确界定哪些工具操作需要事先批准。通过这些表述，评估者就有了可以具体测试的内容。

系统指令、用户请求和源内容

系统指令描述应用程序行为，而用户请求提供当前任务。检索到的源内容是关于任务环境的证据。保持这些类别的分离有助于防止将外部文档误认为是由应用程序或用户授权的指令。

对于一个假设的研究助手，系统指令可能要求基于来源的事实性回答。用户询问某个产品功能。一个被检索到的页面提供了相关的功能描述。如果该页面还包含让助手忽略其规则的文本，应用程序应将这些文本保留为不可信的源内容，而不是将其提升为控制指令。

研究关于 特权指令层级结构 研究用于训练模型按权威程度对指令进行优先级排序的方法。这是一个有用的设计原则，但不同界面之间的支持和行为存在差异。请验证所选模型的角色语义，并直接测试冲突情况，而不是假设每条被标记为 system 的消息在所有环境中都具有相同效果。

围绕决策撰写指令

有效指令规定了如何在应用程序中做出重复性决策。定义允许的主题范围、什么算作证据、何时使用工具，以及完整回答必须包含的内容。避免在提示中堆砌无法解决实际决策的宽泛形容词。

对于一个假设的文档助手，一个有用的规则可以是在提供配置建议之前检查适用的产品版本。另一个规则可以是在现有文档无法回答某个问题时必须说明。每条规则都针对评估案例中可能出现的一个具体失败场景。

组织指令时，应将相关要求归类在一起。用清晰的语言，将任务范围、证据规则、工具行为和响应格式分别说明。 如果两条要求存在冲突，应在设计阶段对其进行取舍或重写，以消除冲突，而不是要求模型同时满足二者。 例如，一个提示既要求“回答所有问题”，又禁止“给出缺乏依据的陈述”，这类设计必须显式提供在证据不足时的应对方式（如返回“证据不足”或类似结果），从而避免自相矛盾。

在稳定指令之外保持更改事实

系统提示通常应包含稳定的行为规则，而经常变化的事实应来自合适的数据源。将当前价格或发行细节放入一个长期存在的提示中，会创建一个可能变得陈旧的副本。通过检索或结构化查找可以在请求时提供这些事实。

研究关于 模型如何使用长上下文 还要提醒不要假设更多文本就意味着每条指令或事实都会被可靠地使用。保持提示聚焦，并测试你的应用程序实际发送的信息放置方式。

如果助手使用了网络工具， Scrapeless MCP 服务器工作流程 为外部观察提供连接。系统提示可以描述何时请求证据以及如何讨论空白。工具定义和运行时仍然决定可用的操作以及执行这些操作所需的权限。

提示不会替代运行时权限

运行时权限定义了应用程序可以执行哪些操作，而系统提示则描述了模型应该提出哪些操作。两者都很有用，但它们是不同的控制手段。即使被告知不要这样做，模型仍可能输出不被允许的请求，因此执行层必须独立验证该请求。

尽可能将机密信息排除在提示文本之外。凭证应位于受限的执行环境或连接器中，而不是出现在模型可能复述的源文本中。如果某项任务需要特权操作，请定义授权检查，并在该操作运行时强制执行。

请提供需要翻译的英文文本。 无抓取的 MCP 连接, 将连接设置和工具权限视为应用程序配置。提示中的一句话不能证明凭证已存在、工具调用已成功或状态更改操作已获批准。对于这些结论，需要可观察的工具结果和适当的策略检查。

使用存在冲突和缺失信息的提示进行测试

系统提示评估应涵盖规则最重要的情境。测试含糊不清的请求、缺失的证据、相互冲突的用户指令、格式错误的工具输出，以及试图重定向行为的外部文本。普通的顺利路径请求几乎不能反映边界规则的有效性。

使用稳定的评估集，并为每个案例定义预期行为。有些案例应以有用的回答结束；其他案例应给出明确的限制说明或对关键信息的请求。评估助手是否在不不必要放弃其余任务的前提下遵守相关规则。

保留一个基线提示，并一次只更改一小部分指令。如果某个更改修复了一个失败却造成了另一个失败，在添加更多措辞之前先检查这些示例。当每次问题都变成一句新话时，提示长度会迅速膨胀。合并重叠规则，移除不再反映应用程序行为的指令。

将指令与应用程序的其他部分一起版本化

系统提示是应用程序配置，应与模型、工具定义和评估结果一起进行版本管理。通过评估适用于这一组合。如果某个工具更改了返回格式，即使提示文本未改变，其解释规则也可能需要审查。

记录重要指令存在的原因。简短的设计说明可以将其与某项需求或失败示例关联起来，而无需暴露敏感的生产数据。这有助于维护者区分必要边界和在试验过程中堆积的措辞。

保持部署记录的具体性。标明是哪一个提示版本为某次请求提供服务，以及应用程序是否插入了额外指令。仅调试可见的用户消息可能会错过导致该响应的条件。使用范围合适的跟踪和留存控制，这样在分析提示时就不需要收集不必要的用户内容。

避免常见的提示设计失败

常见失败包括互相矛盾的规则、未定义的术语、不可用的工具引用，以及无法表达不确定性的响应格式。提示还可能通过不顾证据地强求回答来鼓励不受支持的确定性。给助手一条清晰路径，在完成其可以支持的部分的同时报告尚未解决的需求。

不要把润色过的角色描述当作任务规范的替代。把助手描述成某领域专家，并不能界定它涵盖哪些产品版本，或引用应如何核查。要直接陈述这些要求。确保示例能代表真实输入，而不是只展示简单案例。

对于连接到网络的应用，要区分模型行为与基础设施能力。 Agent Browser 界面 描述的是网页执行，而提示则约束模型如何使用观察结果。模型推理与 Scrapeless 服务使用 在记账上也彼此独立。要求节省开销的指令应有实际的限制和度量作为支撑。

要点

系统提示在上下文中定义应用程序行为。让指令具体、消除矛盾，并评估边界受到挑战时的情形。把会变化的事实放在合适的来源中，并在运行时强制执行权限，这样当模型提出出乎意料的操作时，应用程序依然容易理解。