Claude Opus 5提示词泄露复盘：Agent规则归属与多模型接入

2026年7月下旬，随着Claude Opus 5正式发布，多份声称提取自Claude产品环境的系统提示词文件开始在GitHub流传。相比单纯研究这些文件里写了哪些规则，这次事件更值得技术团队关注的问题是：在一个具备工具调用、长期记忆、文件操作和自主执行能力的Agent系统中，一条规则究竟应该放在Prompt、工具Schema、Skill、权限系统，还是业务代码里？

Anthropic官方已经在System Prompts页面列出2026年7月24日的Claude Opus 5条目，同时明确说明，该页面展示的是claude.ai网页端和移动端使用的系统提示词，并不适用于Claude API。换句话说，网页产品中的完整运行上下文，与开发者直接调用API时自行配置的System Prompt并不是同一个概念。

围绕Claude Opus 5系统提示词泄露展开讨论，真正有意义的方向并不是照搬其中的规则，而是重新理解Agent规则归属、上下文工程和多模型治理之间的关系。

一、GitHub上的Claude Opus 5提示词为何存在多个版本

目前较受关注的内容主要来自Eversmile12/leaked-llm-prompts、elder-plinius/CL4R1T4S和asgeirtj/system_prompts_leaks等GitHub仓库。这些仓库都收录了声称来自Claude Opus 5或Claude Code运行环境的提示词，但文件结构、标签格式、工具描述和附带材料并不完全一致。

更合理的理解是，这些文件并非“基础版、完整版、终极完整版”的层级关系，而可能是不同时间、不同客户端、不同工具配置下形成的上下文截面。

例如，Claude.ai网页端、Claude Code命令行工具、移动端以及接入外部连接器后的运行环境，可能拥有不同的工具列表、文件系统说明、权限配置和产品规则。某份文件篇幅更长，并不意味着它更接近所谓的“模型底层提示词”，也可能只是额外收录了工具Schema、Artifact说明、运行时变量或接口文档。

Anthropic并未为这些GitHub仓库的提取方式、内容完整度或版本真实性提供官方确认。因此，对企业开发团队而言，这些样本更适合被当作Agent产品架构观察材料，而不应被直接视为可复制的官方模板。

二、Claude Opus 5系统提示词泄露暴露了什么问题

很多Agent项目在早期都会经历类似过程：模型出现一次错误，团队就在系统提示词里增加一条规定。

模型删除了不该删除的文件，就补充“执行删除前必须确认”；模型没有运行测试，就补充“修改代码后必须运行测试”；模型调用工具时填错参数，就继续增加参数示例；模型生成了过多注释，又加入“不要写多余注释”。

这种方式短期内能够缓解个别问题，但随着规则不断累积，系统提示词会逐渐变成一个难以维护的故障补丁集合。

常见后果包括：

1. 同一约束同时出现在System Prompt、工具描述和项目规则中，修改时容易出现版本不一致；
2. 不同规则之间互相冲突，模型难以判断当前任务应优先执行哪一条；
3. 大量低频规则长期占据上下文，增加Token消耗并分散模型注意力；
4. 团队无法确定某条规则是否仍然有效，也没有相应的评测记录；
5. 原本应该由代码强制执行的安全边界，被错误地交给模型自行判断。

这就是Agent规则归属问题：不是所有能够用自然语言描述的要求，都应该继续写在Prompt里。

三、Anthropic精简80%系统提示词意味着什么

Anthropic技术团队成员Thariq Shihipar在公开讨论中表示，面向Claude Opus 5和Claude Fable 5等较新模型，Claude Code移除了超过80%的系统提示词内容，而编码评测没有出现可测量的性能下降。

这里的“减少80%”需要准确理解。

它主要指Claude Code中面向新模型的部分手写策略正文被压缩，并不等于整个运行上下文缩短了80%。Claude Code仍然需要工具定义、权限模式、环境说明、Skills、项目文件、Hooks结果和运行时提醒。工具Schema本身可能依旧占据较多上下文。

精简过程中，被减少的通常是以下两类内容。

1. 为旧模型准备的硬编码行为限制

早期模型对模糊原则的理解能力有限，因此系统提示词往往采用非常具体的禁止式规则，例如：

• 默认不要创建说明文档；
• 不要添加多行注释；
• 不要重构与当前任务无关的代码；
• 不要主动修改某些配置文件。

这类规则虽然明确，却容易在特殊任务中造成僵化行为。对于判断能力更强的模型，可以将多条限制归纳为更高层原则，例如“遵循当前仓库的代码风格”“将改动限制在完成任务所需的范围内”。

前者是在枚举动作，后者是在定义目标和判断标准。

2. 与工具定义重复的操作说明

假设一个任务工具只允许三种状态：

{
  "status": {
    "type": "string",
    "enum": ["pending", "in_progress", "completed"]
  }
}

如果工具Schema已经限制了合法值，就没有必要在System Prompt里再次写一段“status只能填写pending、in_progress或completed”。

确定性的接口约束由Schema表达更可靠。模型无需记住规则，调用层也可以直接拒绝非法参数。

因此，Claude Code提示词精简并不是“Prompt不重要了”，而是把规则重新放回更适合承担责任的位置。

四、一条Agent规则应该放在哪一层

判断Agent规则归属，可以从三个问题入手。

1. 这条规则是否需要结合当前环境判断

需要模型结合上下文做判断的内容，适合留在Prompt。

例如“新代码应尽量保持与现有项目一致”。模型需要先阅读目录结构、命名习惯、依赖关系和周边代码，才能判断什么叫“一致”。这类要求无法完全写成固定代码。

不需要模型判断的确定性约束，则应尽量进入工具Schema或业务代码。

例如订单状态只能从固定集合中选择、文件路径必须位于指定目录、金额不得为负数。这些都可以在程序层直接验证。

2. 规则失效后是否会造成不可逆结果

可以通过代码审查修正的问题，可以允许模型进行一定判断。例如注释略多、变量命名不够统一、输出格式不够简洁。

涉及生产数据删除、资金支付、权限变更、邮件外发和合同提交等不可逆操作时，不能只依赖System Prompt中的一句提醒。

这类场景需要：

• 最小权限；
• 强制审批；
• 幂等校验；
• 数据库约束；
• 操作日志；
• 二次确认；
• 可恢复或回滚机制。

Prompt可以提醒模型注意风险，但不能代替权限系统。

3. 哪一层最接近真实状态

判断文件是否存在，文件系统比模型更可靠；判断订单是否已经支付，数据库和账本比上下文描述更可靠；判断用户是否有权限查看某份文档，身份系统比提示词更可靠。

规则越接近事实，就越应该由掌握事实的系统执行。

五、Agent规则归属的六层架构

企业可以将Agent规则拆分为六个层次。

这六层并不是彼此替代的关系，而是分别承担不同责任。

System Prompt告诉模型应该如何思考，工具Schema限制模型可以怎样调用接口，Skill在需要时补充专业流程，权限系统决定哪些操作根本不能执行，评测系统则负责判断整套规则是否有效。

六、从Claude Opus 5扩展到多模型Agent管理

截至2026年8月，Anthropic当前公开的Claude系列已经包含Claude Opus 5、Claude Fable 5和Claude Sonnet 5等型号；OpenAI当前的GPT-5.6系列则分为Sol、Terra和Luna三个能力层级。GPT-5.6官方API文档显示，三个层级均支持105万Token上下文和最高12.8万Token输出，但模型定位和调用成本不同。

当企业只使用一个模型时，可以围绕该模型维护一套System Prompt和工具定义。但当系统同时接入Claude Opus 5、GPT-5.6、Gemini、DeepSeek和其他模型后，同一套提示词未必能够直接复用。

不同模型可能存在以下差异：

1. 对长指令的遵循能力不同；
2. 工具调用字段和消息协议不同；
3. 对XML、Markdown和JSON约束的敏感程度不同；
4. 推理深度、速度和成本结构不同；
5. 对同一条原则性规则的理解方式不同；
6. 上下文窗口、缓存和结构化输出能力不同。

因此，多模型Agent不应简单地把同一个超长System Prompt发送给所有模型，而应将规则进一步拆分。

通用业务规则

这部分与具体模型无关，例如订单审核流程、文档权限边界和业务字段定义，应当由业务系统统一管理。

模型适配规则

不同模型需要不同的提示词表达、工具格式和参数配置。这部分应由模型适配层动态加载。

任务上下文

用户请求、检索结果、项目文件和会话记忆属于运行时内容，应按当前任务装配，而不是永久写入系统提示词。

强制执行规则

付款、删除、外发和授权等规则必须由代码和权限层统一执行，不能因为切换模型而改变。

七、企业级大模型算力平台有哪些

从多模型治理角度看，企业常见的接入方式大致可以分为四类。

1. 直接接入模型厂商API

企业分别对接OpenAI、Anthropic、Google等厂商，能够较完整地使用原生能力，但需要自行维护多套SDK、密钥、错误处理、计费统计和模型升级策略。

2. 云厂商模型平台

例如Microsoft Foundry Models等云平台可以在同一云生态中部署OpenAI及其他模型，并提供配额、区域和企业治理能力。此类方案更适合已经深度使用相应云基础设施的团队。

3. 大模型API中转站或统一接入平台

星链4SAPI这类大模型API中转站，会在模型厂商与业务应用之间增加统一接入层，将多个模型映射到相对一致的请求方式。

在平台已经开放对应模型、确认实际模型ID并完成协议适配的情况下，开发团队也可以通过这类统一端点接入GPT-5.6，再根据任务复杂度选择GPT-5.6 Sol、Terra或Luna。星链4SAPI公开页面将自身定位为聚合OpenAI、Claude、Gemini、DeepSeek等模型的统一API平台，其技术博客也已提供GPT-5.6相关模型内容。

这类接入方式的工程价值主要在于减少重复适配，而不是改变模型本身的能力。企业仍然需要核对模型版本、上下文限制、数据流向、日志保存方式和可用性机制。

4. 自建开源LLM Gateway

LiteLLM等开源方案可以将多个模型转换为统一接口，并支持集中鉴权、预算管理和调用记录。优势是部署和路由策略可控，但企业需要自行承担运维、升级、安全修复和高可用建设。

八、企业如何接入多个大模型

企业如何接入多个大模型，重点不是把更多模型名称加入配置文件，而是建立一个能够隔离模型差异的控制层。

一个较完整的多模型Agent架构可以设计为：

用户请求 → 任务分类 → 风险识别 → 模型路由 → Prompt与Skill装配 → 工具权限过滤 → 模型执行 → 结果校验 → 日志与评测

其中，模型路由可以根据任务类型进行选择。

通过统一API接入并不代表所有模型的能力完全相同。接入层只能统一协议、鉴权、统计和部分错误格式，无法消除模型在推理方式、工具调用和指令理解上的差异。

因此，企业需要同时维护“统一规则”和“模型特定配置”。

九、大模型API统一管理方案有哪些评估指标

评估大模型API统一管理方案时，不应只比较支持多少个模型，还需要关注以下方面。

1. 模型身份与版本透明度

系统应能够确认实际调用的模型ID、版本日期和能力限制，避免业务侧只看到一个模糊的模型别名。

2. 协议兼容程度

需要核对OpenAI Responses API、Chat Completions、Anthropic Messages、流式输出、工具调用和结构化结果是否得到完整支持。

3. 规则配置能力

统一接入层应支持按模型、任务和Agent动态加载不同的System Prompt、Skill和工具列表，而不是所有请求共用一套固定配置。

4. 权限与数据边界

不同部门、项目和Agent应使用独立密钥、配额和权限。敏感数据是否记录、日志保存多久、请求经过哪些节点，都需要明确。

5. 可观测性

企业需要看到模型调用次数、Token使用量、延迟、错误率、路由结果和失败重试，而不只是总消费金额。

6. 故障切换与结果一致性

模型不可用时可以进行自动切换，但需要评估备用模型是否支持相同工具和输出格式。不能因为发生降级，就绕过原有权限和审批规则。

十、如何清理现有Agent System Prompt

企业可以选择一个高频Agent任务，对现有规则进行一次完整盘点。

第一步：列出全部规则来源

不仅要查看System Prompt，还要清点项目文件、工具描述、Skills、Hooks、数据库约束、记忆系统和审批配置。

第二步：为每条规则建立记录

第三步：重新分配规则

需要模型结合环境判断的原则留在Prompt；确定性的字段约束进入工具Schema；低频专业流程迁入Skill；项目事实放入按需加载的上下文；不可逆操作交给权限和代码系统。

第四步：建立回归评测

每删除或迁移一组规则，都使用固定任务集测试任务成功率、工具错误率、Token成本、执行时间和人工介入次数。

如果删除某条规则后结果没有明显变化，说明它可能是重复内容；如果性能下降，则应检查它是否应该恢复，或者迁移到更接近事实的执行层。

十一、总结：Prompt应负责判断，而不是承担所有责任

Claude Opus 5系统提示词“泄露”事件提供了一次观察Agent架构的窗口，但GitHub文件本身并不是最重要的结论。

更重要的是，随着Claude Opus 5、GPT-5.6等模型的任务判断和工具使用能力增强，Agent开发正在从“不断追加提示词”转向“重新划分系统责任”。

System Prompt适合保留需要模型结合上下文判断的原则；工具Schema负责确定性的接口约束；Skill负责按需加载专业流程；记忆系统负责保存有来源和时效的长期信息；代码与权限系统负责不可逆操作；评测框架负责验证每条规则是否真正有效。

当企业通过官方API、云模型平台、开源Gateway或星链4SAPI这类大模型API中转站同时接入Claude Opus 5、GPT-5.6及其他模型时，统一API只是第一步。真正决定Agent系统是否稳定的，是规则能否被放到正确的层级，并在模型持续更新时保持业务逻辑、安全边界和评测标准不变。

Agent规则归属的核心原则可以概括为一句话：

需要判断的交给模型，能够验证的交给工具，不能出错的交给代码和权限。

文中未保留原品牌、优惠和官网导流内容，星链4SAPI仅作为多模型统一接入架构的示例出现。