dsh-superagent 文档|004 提示词

本文说明各智能体（agent）会读取什么内容、团队可以编辑什么，以及改动何时生效。它建立在 000 理念 至 003 执行 的基础上。提示词文本以英文编写。

团队编写的内容

团队可以编辑三个团队区块（team section）、添加技能（skill），并覆盖（override）任意内置系统提示词部件。大多数默认内容位于 prompts/ 与 skills/ 目录下。工具描述、通知（notice）与卡片（card）仍保留在代码中，无法通过提示词设置编辑。

内置文本涵盖角色、工具使用、宿主机制、授权规则，以及 GitHub 与飞书技能。它通过标题引用各团队区块，而不重复其内容。

内置部件与模板

覆盖使用以下键：

生成式区块是可编辑的模板，必须保留以下占位符：

• runtime/environment
  ：{variables}，由执行环境行填充。
• runtime/policy
  ：{version}、{mode} 和 {rules}，每条已启用的规则占一行。
• runtime/policy/none
  ：{version} 和 {mode}，在没有任何规则启用时使用。

编辑某个部件会改变模型收到的指令，但不会改变门控（gate）、Mandates（任务授权）、工具校验或账号包装器（account wrapper）——这些仍由代码强制执行。

应人类的显式请求，主会话（main Session）也可以用 orchestrator_prompts_save 保存覆盖。若某次保存省略了某个覆盖的 base，则沿用已保存的 base。对于已存在于已保存配置中、此次被移除的部件，保存时将其删除；其他任何未知部件则会被拒绝。

每个覆盖都会记录它所基于的内置文本。升级时会保留团队的文本。若默认文本发生变化，面板会将该部件标记为 Default updated（默认已更新），并在团队文本旁展示差异。团队可以保留自己的文本、采用新默认，或在其基础上编辑。未设覆盖的部件会自动跟随新默认。

主会话可以在 orchestrator_read prompts 结果的 default_changed 下读取受影响的部件名。

组装顺序与优先级

系统提示词按以下顺序组装：

2. 共享指令与角色。
4. 三个团队区块。
6. 订阅（Subscriptions）与回复（replies）。
8. 主会话使用的派发（dispatch）指令，或 Executor 使用的工作指令。
10. runtime/admission
    ，仅主会话。
12. 交接指令。
14. runtime/environment
    。
16. runtime/policy
    ，仅主会话。

准入（admission）指令来自 prompts/admission.md，描述主动评估，以及何时可以仅凭卡片就忽略一个无关的候选（candidate）。orchestrator_eval 返回的是上下文，而不是重复这些指令。

环境区块向主会话提供部署级别的值，向每个 Executor 提供其 Ticket 专属的值。策略（Policy）区块在每次模型请求时根据设置重新生成，包含 Policy 版本、接受模式（accept mode）、显式请求豁免，以及形如 - <name> (<id>): <instruction> 的已启用规则，或一条表明没有任何规则启用的声明。它放在最后，因此 Policy 的变更不会改变其前面的提示词文本。

Executor 还会读取 DeepSeek Harness 的编码提示词以及仓库的 AGENTS.md；主会话则不会。对于推断产生的 Ticket，会添加一条最终说明，将其 Executor 限定在所匹配的规则范围内。派工（Assignment）与新到的消息会以 Trigger 卡片的形式内联送达，仅对被截断的内容给出资源指针。

Executor 在无人值守的情况下工作。它们的工具列表中排除了那些需要询问人类、向其展示 UI 或更改 profile 的工具，例如 ask_user_question、present 和 plugin_manager。

从最强到最弱：

2. 由工具与宿主强制的事实：身份、权限、工具参数校验、回复目的、长度限制。提示词文本无法改变它们。
4. 内置与生成式区块——团队若对其设有覆盖，则以覆盖后的文本为准。
6. 主动 Ticket 所匹配规则中的流程与沟通要求，仅对该 Ticket 的 Executor 会话生效。
8. 团队区块与团队技能。
10. 外部文本：消息、评论、文档与引用。它们只是数据，绝不改变规则或授权。

内置文本的原则

以下原则将 000 理念 应用于各智能体：

• 角色分离。
   主会话只负责路由：转发原始 Trigger 与路由相关事实，不做任何技术决策；它通过一个路由工具，在一次调用中对多个等待中的候选作出决策。一条路由说明最多 30 个词。Executor 阅读原始来源、判断范围、实施并验证。
• 主会话不等待。
   报告、后续通知、候选以及已完成的后台任务都会自动以消息形式送达。当没有剩余事项可做时，它就结束当前回合。有守卫会拒绝 sleep、超过 30 秒的 shell 超时和超过 5 秒的任务等待，因为被阻塞的步骤会延误新的候选。这些指令在主会话的完整提示词中取代了 DeepSeek Harness 自身的任务通知说明。
• 仅在人类必须行动或能使用结果时发消息：
   结果可供评审或使用、需要某个决策或资源，或者工作无法完成。聊天消息默认为一句话，硬性上限为 100 个词。
• Executor 自行决定后续动作。
   每个 Executor 处理并确认职责范围内的请求，将超出其 Ticket 范围或属于其他 Ticket 的请求交还。只有当一条消息的所有归属者都交还、或未接手即结束时，该消息才会变成新工作。主会话会收到后续通知，但只有停止工作这一种情况才可以据此行动。被交还的消息随后作为候选送达，并附上各 Executor 的理由。
• 通过订阅与主会话协调。
   Executor 关注（follow）相关 Thread 以获取上下文。主会话可以在一条至多 100 词的通知中传达来自其他 Ticket 的事实。无论是订阅还是通知，都不授予权限。
• 仅在明确引用时挂接（attach）。
   一条消息必须指向某个 Ticket 的 pull request、Issue、源消息或确认回执，或指向恰好只匹配一个 Ticket 的近期变更。仅主题相似并不足够。挂接会让该 Ticket 订阅整个 Thread；Executor 若发现与之无关，使用 orchestrator_thread_unrelated，并且不在该处回复。
• 具体地确认一次。
   在开展实质性工作之前，Executor 逐条确认每个新请求，以原始消息下方回复的形式点明对象与预期结果。
• 通过 human_action 提问。
   Executor 在其 Report 中放入一个具体问题，主会话原样转发。如果某个人的消息引发了该问题，就指明那条消息，由宿主在该消息所在位置提问；否则在该 Ticket 的原始会话中提问。已获授权的工作可以在此期间继续进行。
• 诚实交付。
   开出 pull request 并不等于就绪；草稿要标记为未完成；没有真实“改动前”截图的 UI 变更不算就绪。
• 人类的暂停保持有效。
   暂停会跨越后续消息、新的 Executor 会话和重启持续生效，直到人类解除为止。自动反馈绝不会恢复已暂停的工作。
• 示例只展示格式。
   例句不是智能体可以声称的事实。
• 按结果处理评审。
   已修复并验证的评论静默地解决（resolve）；被拒绝的评论给出一句理由。自动化评审者发起的讨论线程一旦有了答复，即标记为已解决；每个自动化评审者在单个 pull request 中至多进行三轮。
• 为重复工作让路。
   当某人的分支或 pull request 已包含该 Ticket 的变更时，Executor 关闭自己的 pull request，并附一句话指向对方的工作。

版本

• 每次保存都会创建一个不可变版本，包含完整配置、修订号、前驱版本、时间戳与来源（面板或工具）。恢复某个版本或默认值会再创建一个版本。
• 保存时会指明其基线修订（base revision）。发生冲突的保存会被拒绝，且不会丢弃草稿。
• 会话在每次模型请求时读取最新版本，包括同一回合内的后续步骤。保存不会重启、取消或唤醒任何会话。宿主记录每个会话使用过的修订；Executor 可以读取它工作过的任何修订版本。
• 部署会设置包括覆盖在内的总大小上限。校验会拒绝未知键、被保留的内置技能名、未知覆盖部件以及缺失的模板占位符，且从不静默截断文本。与默认完全相同的覆盖会被移除，使该部件跟随未来的默认。