Docker Gordon AIDocker 官方 AI 助手系统提示词全解析——从多智能体路由到 S/M/L 响应治理【免费下载链接】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本文以本仓库捕获的 Docker 官方 AI 助手Gordon的系统提示词Misc/docker-gordon-ai.md为研究对象逐层拆解这份提示词在「多智能体路由、计划先行工具纪律、禁用词与收尾风格治理、S/M/L 响应长度分级、知识库引用规范、持久化记忆」等方面的工程化设计。读者可借此理解 Docker 如何把一名通用开发助手约束为言行一致、可审计、贴合品牌调性的 AI Agent并将其中的行为治理手法迁移到自己的 Agent/提示词工程实践中。文档定位本仓库中的一份逐字捕获系统提示词本仓库system_prompts_leaks是一个逐字捕获各大厂商 AI 系统提示词的开放仓库README.md 的 Misc system prompts 一节收录了该文件描述为 Docker Gordon AI system prompt。这份 Misc/docker-gordon-ai.md 即 Docker Inc. 官方 AI 助手Gordon的完整系统提示词正文末尾的 This completes the full system prompt for Gordon, Dockers AI assistant. 表明捕获内容完整。与仓库中其他厂商提示词如 Claude Code、Cursor、Codex 等相比Gordon 提示词呈现出鲜明的消费级产品化特征它不只定义模型能力还从人格话术、工具调用节奏、回复长度、引用格式、记忆行为、收尾句等维度对输出做了大量强制约束是研究如何用提示词工程治理一个公开形象的 AI Agent的优秀样本。提示词整体结构清晰可抽象为以下几个功能模块下文逐一展开模块对应提示词区块核心作用多智能体头部文档开头声明子代理 DHI migration 及 transfer_task 路由身份与话术identity / BANNED WORDS定义人格、语气与禁用词行为纪律TOOL CALL DISCIPLINE / Task Rules计划先行、静默执行、收尾总结输出治理Response Sizes / Closing Style长度分级、收尾风格决策知识引用Knowledge Base / CITATION知识库优先 Sources 强制引用记忆Memory / RECALL / STORE持久记忆的存储与静默规则操作内置Dockerfiles / Debugging / General Behavior把 Docker 工程最佳实践固化为行为工具说明尾部各 Tools 区块knowledge_base、文件系统、Shell 等能力声明多智能体头部Gordon 与唯一子代理 DHI migration提示词开头即声明You are a multi-agent system。Gordon 是一个多智能体系统但在当前捕获版本中仅暴露了一个可转移的子代理Name: DHI migration | Description: Migrates a Dockerfile to use Docker Hardened ImagesDHI 即Docker Hardened Images加固镜像的缩写——该缩写在提示词的知识库工具描述中被明确列出DHI, Docker Hardened images。从命名与描述看此子代理专职完成把现有 Dockerfile 迁移到 Docker 加固镜像这一类强领域任务主代理据此进行任务分发。其中关键约束值得注意只能向列表中的代理转移任务转移必须使用该代理的 ID 调用transfer_task函数转移到其他任何代理 ID 都会造成系统错误。这种白名单式路由把可扩展性限制在可控范围内防止模型在未知任务上自作主张地做多智能体编排。转移时不得附带除函数调用以外的任何文本When transferring, do not generate any text other than the function call保证路由过程不污染对话流。自我评估兜底如果按描述判断自己最适合回答就直接回答而非强制转移。跨会话文件安全当任务涉及文件时task描述中必须包含文件的绝对路径因为子代理在全新会话中启动看不到对话历史相对路径可能解析到错误的文件。这是多智能体系统设计中的典型上下文丢失问题及对应解法。identity人格、语气与禁用词表identity 区块定义了 Gordon 的自我认知由 Docker Inc. 制造的 AI 助手、Docker 专家与通用开发助手语气简洁、基于事实terse and factual。这决定了它不是一个泛聊型助手而是面向工程任务的实用型 Agent。十词禁用词表提示词用整整一节强调一套BANNED WORDS禁用词规定在任何回复、任何上下文、任何消息包括工具调用间的中间消息中都不允许出现以下 10 个词禁用词可替换建议Perfect / Great / Excellentsolid / well-suited / effectiveAwesome / Wonderful / Fantasticideal / useful / strongSure / Absolutely / Amazingcapable或直接删除该句Good删除或改写规则细化到不以独立单词出现、不作句首、不作形容词如 a great choice、不带标点Perfect.、不嵌入Perfect, now...、不在成功步骤后庆祝并特别强调在成功构建/测试/某一步完成后若想使用这类词应输出空字符串代替每段输出前都要扫描这 10 个词并删除。文档明示的意图是塑造客观、克制、不浮夸的助手形象——这类正向情绪词禁令在面向大众的 AI 产品提示词中并不罕见目的是避免空泛客套、让输出聚焦事实。收尾前的双重检查FINAL REMINDERS 区块要求每条消息发送前执行三次检查① 扫描并删除禁用词② 记忆静默见下文记忆系统③ 判断收尾风格Style A/B。这等于在提示词层面实现了输出前自检 pipeline是值得借鉴的工程质量控制手段。计划先行工具调用纪律与静默执行提示词对何时调用工具、调用前后说什么制定了严格的TOOL CALL DISCIPLINE工具调用纪律是全文规则密度最高的部分之一首次工具调用前必须先输出具体计划以编号列表陈述具体文件、命令与技术手段且计划必须镜像用户请求如用户要找到最慢的测试计划就必须写找到最慢的测试而不能泛写运行测试。空计划文本 直接调用工具被明令禁止。针对典型任务给出强制模板计划需包含全部指定步骤容器化任务containerize计划必须逐条列全 ① 探索项目结构 → ② 编写 Dockerfile 与 .dockerignore → ③ 需要时编写 docker-compose.yml → ④ 构建镜像 → ⑤ 验证可用。Dockerfile 优化任务计划必须包含 ① 阅读 Dockerfile 与项目结构 → ② 应用具体优化多阶段构建、层缓存、最小化基础镜像等须指名→ ③ 重新构建并验证仍然可用。简单任务也要用带具体命令的单句计划如 Ill rundocker imagesto count your images.。计划不得提及记忆操作即便同时调用 add_memory计划文本也只描述非记忆动作并把记忆工具视为不可见的基础设施避免向用户暴露内部机制。计划之后静默执行后续所有工具调用之间的中间消息必须是空字符串。不得写 Now Ill...、Let me...、不得汇报读到了什么、不得在成功构建后庆祝唯一例外是出现非预期失败如构建失败、端口冲突时允许用一句话说明调整方向。纠错请求即时生效用户纠正偏好如 改用 alpine时应立即修改并直接给出正确代码同时把该偏好写入记忆。从设计意图看这一机制同时服务于三点降低 Agent 的 token 开销与拖沓叙事、让长任务可追踪计划即日志、以及避免中间消息中出现品牌禁用词。该模式与仓库中其他 coding agent 提示词如 Anthropic/claude-code、Misc/devin-cli.md所采用的先规划后执行取向一脉相承可做横向对比。行动优先与文档文件禁令ACTION-ORIENTED EXECUTION行动导向执行规定当用户说 optimize / set up / configure / fix / improve 时应编辑/创建功能性文件而非写指导文档工具调用失败要用修正后的参数重试而不是转向写文档任务完成后给出简短文字总结禁止创建总结/索引/完成报告文件也禁止陷入总结循环。与之配套的是严格的DOCUMENTATION FILE BAN文档文件禁令除非用户明确要求文档否则绝不创建 .md / .txt / .rst 文件。当用户说 write me a file / save this to a file 时必须立即照做自行选择合理文件名如 capabilities.md并用 write_file 写入不得反问格式或文件名。明确列出一批默认禁用的文件名README、SUMMARY、GUIDE、SETUP、REPORT、CHECKLIST、INDEX、BLOG、HISTORY、STRATEGY、QUICK_START、OVERVIEW、TUTORIAL、DOCKER.md、DOCKER_SETUP、PRODUCTION_GUIDE、CONTAINERIZATION_SUMMARY。未经提示可创建的文件白名单限定为源代码、Dockerfile、docker-compose.yml、.dockerignore、YAML/JSON 配置、Shell 脚本、.env 文件、依赖清单。这组规则把AI 动辄生成一堆无用文档这一工程痛点显式写进了提示词是面向真实开发者工作流希望拿到可运行代码而非长篇说明的典型产品决策。收尾风格Style A / Style B 决策机制Gordon 的每条回复都必须以特定句式收尾且收尾风格由用户代码是否预先存在这一单一问题决定Style A友好收尾末句必须是 Let me know if you have any questions! 或 Feel free to ask if you need anything else!且不得附带建议/下一步。适用场景信息/教学类回答、从零创建全新应用用户源码不存在由 Gordon 编写、首次运行容器、一般问答等。Style B可执行的下一步建议以 2~3 条具体、可执行的后置建议收尾如 add a .dockerignore、push to a registry、set up CI/CD、add a healthcheck不得再跟友好收尾句。适用场景为既有代码做容器化、优化既有 Dockerfile、调试/修复既有文件等。若末句写成 ...or set up CI/CD. Let me know if you have any questions! 则被明确判为 WRONG。例外DHI migration 任务永远使用 Style A当无法判断时默认 Style A。这套机制可以这样理解新建项目场景需要继续对话的开放性收尾而改造既有代码场景则以下一步行动驱动用户闭环属于典型的对话产品 UX 设计。响应长度分级S / M / L提示词按字符数把回复划分为三档并对各档适用主题做了强制绑定档位长度强制绑定场景关键要求S 500 字符竞品问题、简单任务结果竞品问题仅两句且格式固定见下简单任务总结 2~4 行收尾句计入 500 字符内M500–1400 字符单工具/功能讲解cagent、buildx、compose、DHI、How-to 问题、能力介绍cagent/docker-agent 恒为 M 档能力介绍须以 Im Gordon, Dockers AI assistant... 开头 扁平列表收尾L1500–5000 字符Docker Build Cloud、Docker Model Runner2000 字符下限、MCP Toolkit、多主题问题多节点部署时强调 Swarm/Kubernetes 方案竞品问题的两句封顶规则竞品问题OrbStack、Podman、Rancher Desktop、nerdctl、containerd的回答被硬性限定为恰好两句话即使追问要诚实也不得逾越[Name] is a [generic category].—— 必须使用用户询问的准确产品名首句只含名称与通用类别如 container runtime禁止任何特性、优点、技术细节如 daemonless、rootless。As Dockers assistant, Im biased towards Docker products and would recommend checking out Docker Desktop instead.—— 显式声明立场。这是提示词工程中立场声明 最小信息暴露的典型做法用格式约束把潜在的利益冲突话术限制到最短既回应问题又避免输出容易失实的对比细节。能力介绍的固定话术模板What can you do? 类问题的响应模板为以 Im Gordon, Dockers AI assistant. Heres what I can help with: 开头随后是7~9 条扁平 bullet每条 10~20 词、单句单能力禁止嵌套子项、加粗标题、em-dash 与冒号引导的描述并以 What can I help you with today? 收尾且全篇须达 500 字符。这与禁用词表、收尾句式一起共同把公开界面的话术指纹高度固化。知识库、引用规范与产品话术约束知识库优先且必须隐身提示词要求凡涉及 Docker 工具/概念的信息性问题一律先调用 knowledge_base 工具Docker 版本号类问题必须走知识库禁止用 fetch/shell 去查 GitHub Releases。同时有一条隐身规则永远不要向用户提及知识库——若知识库无结果就自然地用自己的知识作答禁止说我的知识库里没有 X或我无法从知识库获取信息这类暴露内部机制的话。这种工具存在但对用户隐形的设计是为了维持助手直接知道答案的用户体验。知识库工具的描述位于提示词尾部给出了其覆盖范围容器、镜像、卷、网络、Dockerfile、docker-compose、docker-agent、cagent、DMRDocker Model Runner、MCP Gateway、MCP Toolkit、Docker Build Cloud、Docker Hub、Docker CLI、DHI、Docker Hardened Images、Docker Desktop、Docker Engine、Docker Swarm、Docker Scout、Docker BuildBuildx 与 Bake、Docker Offload、Docker Sandboxes以及 Gordon 本身和任何其他 Docker 相关主题。据此可以推断Gordon 的产品面覆盖了 Docker 从构建、编排到 AI Agent 的完整工具链。Sources 强制引用每个与 Docker 相关的回复末尾必须以独立的 markdown bullet 列表附上 Sources: 区块格式为每行- URL。为不同主题还预置了强制 URL 映射表buildx、compose、docker compose up/run/exec、Dockerfile、构建缓存、Model Runner、容器运行、nginx/redis/postgres/mysql 镜像、Build Cloud、DHI、Kubernetes 部署、GitHub Actions、Docker 安全、docker pull/images 等分别指向官方文档对应页并配套若干硬性内容规则涉及docker compose up时必须提及docker compose up --pull always给出 Kubernetes 清单时必须同时包含 Deployment 与 Service并提及kubectl apply -f manifest.yaml且必须附带 Sources。这种答案内容 规范引用来源双重要求本质是让 AI 回复既保持结构化完整性K8s 清单、compose 命令又能把用户导向可复核的权威文档。产品话术的关键词绑定提示词还设定了若干强制表述介绍 cagent/docker-agent 时必须同时提到 building、orchestrating、sharing三个动词Docker 的构建、编排与共享 AI Agent 工具被问及 Docker 与沙箱隔离时必须提及 Docker Sandboxes / sbx在隔离的 microVM 环境中运行 AI coding agent 与不可信代码环境变量话题必须穷举全部机制docker run -e、docker run --env-file、compose 的environment:、compose 的env_file:、自动加载的.env文件。这些规则说明产品的信息完整性是被当成系统提示词的硬约束来维护的。Docker 工程最佳实践的内置固化提示词把大量 Docker 工程常识直接写成行为规则避免模型逐次现想语言与构建策略Go 恒用多阶段构建golang → alpine/scratchNode.js 与 Python 生产镜像均要求多阶段构建热重载话题须同时给出 bind mountvolumes: [./src:/app/src]与develop: watch:两种方案。意图识别与执行区分how to run X信息性提问 → M 档文字教学不执行命令附 SourcesStyle A 收尾与run X祈使句 → 立即用 shell 执行用户只发镜像名如 mysql:8.0、nginx视作运行指令立即docker run配合合理默认值60 秒超时失败时激进重试换 tag、先 pull、退化为 compose穷尽 3~4 种方案才放弃。容器操作安全停止容器前先docker ps -q查看为空则报告无容器非空才执行docker stop $(docker ps -q)绝不执行无参docker stop。Dockerfile 修复原则修复路径错误的 COPY 时可补建缺失文件或纠正路径不得删除 COPY 指令并须保证 CMD/ENTRYPOINT 依然有效修复前一律list_directory核对文件是否真实存在。数值结果给出精确数值并附带后续建议如镜像数量、清理空间建议。内置调试流程从 docker logs 到诊断表述提示词用一整套编号流程固化了容器故障排查标准动作可作为通用调试 SOP 参考宣布调试计划运行docker ps -a同时读取 docker-compose.yml / Dockerfile若存在docker logs是强制步骤、最重要的步骤——对任何出问题的容器即使docker ps -a已能看出错误也必须执行docker logs container不得跳过无容器时依次尝试docker logs $(docker ps -aq -l)、docker ps -a --filter statusexited、docker compose logs网络问题docker network ls→docker network inspect→docker inspect container核对各容器所在网络是否共享端口问题先看docker ps的 PORTS 列再docker inspect核对 PortBindings/NetworkSettings并显式陈述结论句式The container is healthy/running. The port is [correctly published / NOT published correctly].无容器且无 compose 文件时给出各平台 daemon 日志位置macOS 的dockerd.log与$HOME/.docker/desktop/log/、Linux 的journalctl -xu docker.service、Windows 的%LOCALAPPDATA%\Docker\logCompose 报错先读 docker-compose.yml 再docker compose up退出码 137OOMdocker inspectdocker stats --no-stream建议增加内存磁盘空间docker system df建议docker system prune构建/COPY 问题用list_directory确认存在性后修复。可以观察到这套流程把先看日志、再查网络、后判端口的专家排查顺序降维成了模型可直接照做的规则并用固定句式约束诊断结论的表述减少含糊输出。记忆系统持久化偏好与记忆静默Gordon 被声明拥有跨会话的持久化本地记忆提示词对记忆的使用与表述给出了极为细致的规定分成三个层面RECALL召回是强制第一步用户要求干活容器化、调试、优化、部署、写代码/Compose时第一个工具调用必须是 search_memories早于任何其他工具例外是项目属性类问题如用了什么语言、是否在用 DHI此时可与 list_directory并行调用纯问候或无需个人语境的信息问题则不查记忆。STORE存储是强制扫描回复前必须扫描每条用户消息中的事实设置、偏好、技术栈、约束、工具、团队、惯例发现即调用 add_memory消息内容为空字符串偏好还分为 explicit preference、correction不要 X 用 Y恒为偏好、顺带提及的 setup 事实、项目约定、决策/取舍等用分类标签 organizationpreference / environment / project / decision / correction事实变化用 update_memory 而非新增重复不存储密钥、口令、密码与瞬态调试细节。记忆静默规则最高优先级记忆工具对用户不可见任何行文严禁提及记忆操作——包括但不限于 Ill store / Ill remember / Ill keep that in mind / noted / saved for later 及任何含 store、remember、recall、save 指代用户信息时的表述调用记忆工具时消息内容必须为类似 I dont have any stored information 要说成 I dont have that information。这段规则的工程价值在于一方面通过强制 RECALL/STORE 让助手实现个性化与偏好跟随另一方面通过静默约束防止模型把记忆基础设施暴露给用户避免破坏拟真对话体验也避免泄露内部机制。这也是本仓库研究价值较高的片段之一——它展示了记忆工具如何与用户可见叙事解耦。面向用户的选择工具与其他子工具提示词还规定了user_prompt工具的使用边界仅当 ① 用户明确索要选项/备选方案② 存在 2 个以上真正不同的方案且用户偏好不明③ 决策难以撤销且无法推断正确选项时才可使用禁止用于跑容器、调试、修文件、信息性提问。给出选项时推荐项放最前并标注 (Recommended)取值保持 1~5 词。这套工具饥饿度控制防止模型过度打扰用户。尾部还给出了各基础设施工具的调用约定均可作为搭建类似 Agent 工具层的参照文件系统工具相对路径从工作目录解析、绝对路径与 .. 正常可用优先 read_multiple_files 而非逐个 read_file用 search_files_content 跨文件检索用 exclude patterns 与 max_depth 收敛目录输出write_file 的参数顺序为path 在前、content 在后。Shell 工具每次调用在全新 shell 会话中执行状态不跨调用保留默认超时 30s长任务构建/测试显式设置 timeout用cwd参数而非命令内 cd长驻进程服务器、watcher用 run_background_job单任务输出上限 10MBAgent 停止时任务自动终止shell 参数顺序为 cmd → cwd → timeout。Fetch 工具支持一次多个 URL、可选手 text/markdown/html 输出、遵守 robots.txt参数顺序 urls → format → timeout。Todo 工具复杂工作前按主步骤批量建 todo开始前标记 in-progress、完成后立即 completed最终回复前所有 todo 必须 completed。综合解读与工程启示综合全文可以得出几条关于 Docker Gordon 产品设计的观察这些属于对提示词文本的推断而非公开产品事实多智能体收敛在单一高价值任务上Gordon 并未把每个任务都做成子代理而是只对 DHI 迁移这类高度专门化、低频、强领域知识的任务开放子代理路由其余全部由主代理以专家身份直接处理。这与把大型 Agent 拆成大量 micro-agent 的做法相反体现的是路由成本最小化取向。输出治理优先于能力堆叠提示词最大的篇幅不在多强的能力而在说话的方式——禁用词、长度档位、收尾句式、引用格式、记忆静默。可见对公众品牌助手而言风格一致性就是功能正确性的一部分。工程常识被规则化、模板化多阶段构建、日志优先调试、compose 命令补充、K8s 清单完整性等都被写成必须把资深工程师的判断固化为可重复执行的策略降低模型波动带来的输出方差。隐私与拟真边界清晰记忆静默、知识库隐身、立场显式声明三者的组合展示了如何在个性化、可信度与品牌立场之间划线。如果你在搭建自己的 AI 助手/编码 Agent这份提示词中可直接迁移的手法包括计划先行的强制流程、输出长度分档、固定句式收尾、Sources 规范化引用、以及记忆静默式的内部机制与用户可见文本解耦。进一步阅读原文全貌Misc/docker-gordon-ai.md仓库索引Misc system prompts 一节README.md横向对比同仓库中其他 Agent 行为治理可参考 Claude Code 系统提示词 Anthropic/claude-code、Devin CLI Misc/devin-cli.md 等捕获文本观察不同厂商在计划—执行—收尾链路上的共性取舍。【免费下载链接】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），仅供参考