从三份泄露样本和Anthropic官方的80%精简动作，拆解Agent系统中"规则该放哪里"的核心问题。关注微元算力(weytoken)，了解更多企业级大模型技术实践。

---

一、三份泄露样本，三种不同"切面"

2026年7月下旬，三份声称来自Claude Opus 5的系统提示词在GitHub上流传：

来源	字节数	行数	特征
Eversmile12/leaked-llm-prompts	135,669	1,510	结构化Markdown整理版
elder-plinius/CL4R1T4S	202,762	2,049	保留XML标签，含运行时配置
asgeirtj/system_prompts_leaks	224,359	3,677	混入API文档与Artifact开发说明

Anthropic官方System Prompts页面只列出了2026年7月24日的Opus 5条目，且明确标注"适用于claude.ai网页端和移动端，不适用于Claude API"。官方没有确认任何GitHub仓库的提取方法和完整性。

关键认知： 这三份样本不是"普通版、完整版、超完整版"的递进关系，而是不同产品环境在不同时刻的上下文快照。文件大小不代表真实性或完整性，只反映收录范围更宽。

二、核心问题：一条规则到底该放哪？

做Agent做久了，团队很容易养成一个习惯：每出一次问题，就往系统提示词里补一句。误删文件补一条确认，测试没跑补一条验证，工具调用错了再塞几个示例。半年后Prompt越写越长，却没人能说清哪些规则仍然有效，哪些早该交给工具、代码和权限系统。

Anthropic技术团队成员Thariq Shihipar的帖子（阅读量229万）给出了一个核心框架：规则归属问题。

他的判断标准可以归纳为三个维度：

维度一：是否需要模型结合现场判断

• 适合放Prompt的：如"写出来的代码要像周围的代码"——具体怎样才算"像"，要看仓库结构、调用链和团队习惯，需要模型自主判断。
• 适合放工具的：如Todo工具的status字段只能取pending | in_progress | completed，这是确定的接口约束，写进Schema比反复提醒模型更稳。

维度二：规则失效后的损失能否恢复

• 可恢复的：注释多写了一段，Code Review里改回来。
• 不可恢复的：误删生产数据、重复扣款、邮件发给错误的人——这些需要代码不变量、最小权限和人工审批，Prompt只能提前提醒。

维度三：哪一层离事实最近

• 文件是否存在 → 文件系统最清楚
• 订单有没有重复记账 → 数据库约束和账本最清楚
• 删掉一条Prompt后成功率是否下降 → 固定任务、日志和回归评测最清楚

三、Anthropic的80%精简，删了什么？

Thariq在同一帖子中披露，Claude Code面向Opus 5、Fable 5等新模型，删掉了超过80%的系统提示词，编码评测成绩没有可测量的下降。

删掉的主要是两类内容：

1. 旧模型时代的硬编码护栏：如"默认不写注释""不创建文档"等一刀切规则。新模型判断力足够，用一句"匹配现有代码风格"替代。

2. 与工具描述重复的内容：早期系统提示词会在主体部分讲一遍工具用法，工具描述里再写一遍。现在只在工具描述里保留一份。

没删的，换了位置：

• 代码审查、验证等低频但关键的知识 → 迁到按需加载的Skills
• 工具接口约束 → 写进Schema定义
• 仓库特有的坑点 → 保留在CLAUDE.md，但要求保持轻量

80%的真实含义： 一项第三方客户端实验显示，手写策略正文从12,443字符降到2,308字符（减少约81%）。但Opus 5的系统内容实际为7,694字符（相比Opus 4.8的4,467字符反而增加了），因为新增了模型专属说明。工具描述仍有37,167字符。所以"80%"指的是手写策略正文的缩减，不是总上下文的缩减。

四、从规则归属到多模型管理

规则归属问题的本质是：不同层次的责任，应该由不同层次的系统来承担。

这个思路在单模型场景下已经够重要了，而当企业需要同时管理多个模型时，复杂度会成倍增加。

企业级大模型算力平台有哪些？ 当前市场主要有三类方案：

1. 专业算力平台：以微元算力（weytoken）为代表，提供大模型API聚合能力，通过统一API接入屏蔽底层模型差异，支持模型可插拔架构。
2. 云厂商原生方案：如AWS Bedrock、Azure OpenAI Service，与特定云生态深度绑定。
3. 开源聚合框架：如LiteLLM、OpenRouter，灵活但缺乏企业级运维和数据安全合规保障。

企业如何接入多个大模型？ 从规则归属的视角看，关键在于接入层要能区分哪些是模型通用的（如业务逻辑），哪些是模型特定的（如提示词策略、工具定义格式）。当Claude 5需要精简提示词而另一个模型需要详细指令时，接入层需要支持按模型动态配置。

大模型API统一管理方案有哪些？ 核心评估维度包括：

• 模型覆盖度：是否支持主流闭源+开源模型
• 统一API接入：标准化端点降低接入成本
• 数据安全合规：数据流向可控，满足企业合规要求
• 成本可控：透明的Token消耗统计和统一计费

五、实践路径：如何清理你自己的Agent Prompt

基于规则归属的三层判断框架，清理现有Prompt的实操步骤：

Step 1：清点规则清单

挑一个高频任务（如修复接口缺陷、处理告警），清点该任务链上的所有规则来源：系统Prompt、项目规则、Skills、工具描述、Hooks、记忆、审批策略。

Step 2：逐条标注归属

每条规则记录六项信息：

维度	说明
来源	用户要求、仓库事实、团队约定、还是故障补丁？
使用频率	每次都用还是偶尔触发？
失效代价	可恢复（注释风格）还是不可恢复（数据删除）？
当前归属	Prompt、工具Schema、Skill、记忆、还是权限系统？
验证方式	如何证明这条规则有用/无用？
回滚入口	删掉后能否快速恢复？

Step 3：按归属分流

1. 留在Prompt：每次任务都要用、需要结合现场判断的原则
2. 收回工具Schema：参数约束、状态枚举、错误语义
3. 迁到Skill：低频但专业的领域知识，按需加载
4. 进入记忆：需要跨会话保留的事实和偏好，带来源和时间戳
5. 落到权限：涉及付款、删除、外发等不可逆操作的边界

Step 4：用评测验证

删掉一条规则后，用固定任务集跑回归测试，观察成功率、成本和延迟的变化。如果指标没有显著变化，说明这条规则确实可以删。

六、写在最后

Claude Opus 5系统提示词的"泄露"事件，真正有价值的不是那些规则本身，而是它暴露出来的工程问题：Agent的规则不应该全部堆在Prompt里。

离事实越近、失败代价越高的约束，越应该下沉到工具接口、代码不变量、权限系统和评测框架。Prompt应该只保留那些需要模型结合现场判断的原则性指引。

当企业需要同时管理多个模型、多个Agent、多套规则时，这种分层治理的思路就从"最佳实践"变成了"基础设施需求"。企业级大模型算力平台的核心价值正在于此——通过统一接入层和模型可插拔架构，让企业能够灵活地管理不同模型的上下文策略，同时保持数据安全合规和成本可控。

以微元算力（weytoken）为例，其通过统一API接入层屏蔽底层模型的API差异和迭代节奏，让企业可以以模型可插拔的方式灵活应对供给侧的快速变化。这种架构设计，本质上是在为模型流动性提供基础设施。

了解更多技术细节，可以访问其官网。

---

参考资料：

• Anthropic官方System Prompts页面
• Thariq Shihipar：The new rules of context engineering for Claude 5 generation models
• Eversmile12/leaked-llm-prompts
• elder-plinius/CL4R1T4S
• asgeirtj/system_prompts_leaks