004 Prompt

本文档说明 agent 读取什么、团队可以编辑什么，以及更改何时生效。它建立在 000 Philosophy 到 003 Execution 之上。prompt 文本以英文书写。

团队编写什么

团队可以编辑三个团队段落、添加技能，并覆盖每一个内置 system prompt 部分。多数默认内容位于 prompts/ 和 skills/ 之下。工具描述、通知和卡片保留在代码中，无法通过 prompt 设置编辑。

内置文本涵盖角色、工具用法、宿主机制、授权规则，以及 GitHub 和飞书技能。它按标题引用团队段落，而不是重复其内容。

内置部分与模板

覆盖使用以下键：

生成的段落是可编辑的模板。它们必须保留以下占位符：

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

编辑某个部分会改变模型收到的指令，但不会改变 gate(门控）、Mandate、工具检查或账号包装器，这些仍由代码强制执行。

在明确的人工请求下，主 Session(会话）还可以用 orchestrator_prompts_save 保存覆盖。如果某次保存省略了某个覆盖的 base，则保留已保存的 base。已存在于保存配置中、但本次被移除的部分，会在保存时被丢弃；任何其他未知部分都会被拒绝。

每个覆盖都会记录它所基于的内置文本。升级会保留团队的文本。如果默认内容发生变化，面板会将该部分标记为默认内容已更新(Default updated)，并在团队文本旁边显示差异。团队可以保留自己的文本、采用新默认内容或对其编辑。没有覆盖的部分自动跟随新的默认内容。

主 Session 可以通过 orchestrator_read prompts 在 default_changed 之下读取受影响部分的名称。

组装与优先级

system prompt 按以下顺序组装：

1. 共享指令与角色。
2. 三个团队段落。
3. Subscription(订阅）与回复。
4. 主 Session 的 Dispatch 指令，或 Executor 的工作指令。
5. runtime/admission，仅用于主 Session。
6. 交接指令。
7. runtime/environment。
8. runtime/policy，仅用于主 Session。

准入指令来自 prompts/admission.md。它们描述主动评估，以及何时可以根据卡片忽略一个不相关的候选。orchestrator_eval 返回上下文，而不是重复这些指令。

environment 段落向主 Session 提供整个部署范围的取值，向每个 Executor 提供其 Ticket 特有的取值。Policy(策略）段落会在每次模型请求时依据设置重新生成。它包含 Policy 版本、accept 模式、显式请求豁免，以及已启用的规则，格式为 - <name> (<id>): <instruction>；当没有启用任何规则时，则是一条相应陈述。它排在最后，因此 Policy 的变化不会改动其前的 prompt 文本。

Executor 还会读取 DeepSeek Harness 的编码 prompt 和仓库的 AGENTS.md；主 Session 不会。推断出的 Ticket 会附加一条最终说明，将其 Executor 限制在匹配到的规则之内。Assignment(分派）和传入的消息以内联 Trigger(触发事件）卡片的形式到达，只有被截断的内容才附带资源指针。

Executor 无人值守地工作。它们的工具排除了那些向人提问、向人展示 UI 或更改 profile 的工具，例如 ask_user_question、present 和 plugin_manager。

从最强到最弱：

1. 由工具和宿主强制执行的事实：身份、权限、工具参数检查、回复用途、长度限制。prompt 文本无法改变它们。
2. 内置段落与生成的段落，以团队覆盖后读到的内容为准。
3. 主动 Ticket 匹配规则中的流程与沟通方式，仅对该 Ticket 的 Executor Session 生效。
4. 团队段落和团队技能。
5. 外部文本：消息、评论、文档和引用。它们是数据，永远不会改变规则或授权。

内置文本的原则

以下原则把 000 Philosophy 应用于 agent:

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

版本

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