发布时间2026-07-07标签AI AgentLLMClaude Code工程实践Prompt 工程导航上一篇AI Agent 工程实践01AI Engineering OS 整体架构设计下一篇AI Agent 工程实践03Memory 设计——Agent 到底应该记住什么当规则只有 3 条时一个CLAUDE.md足够。当规则增长到 50 条时问题开始出现响应变慢、规则冲突、关键约束被淹没。我踩了一个月坑后发现问题不是规则太多而是所有规则始终在场。于是有了今天的core/heavy双层设计。问题背景在系列第 00 篇里我讲到自己搭了一套 AI Engineering OS开始把 Agent 的行为规则系统化地管理起来。所有教程都在教写一个超长的规则文件我也照做了——把所有规则都塞进CLAUDE.md。但随着项目变复杂问题来了响应变慢、成本上升。每次对话模型一上来要读几百行规则token 消耗肉眼可见地涨。规则互相打架。一条说优先简洁输出另一条说必须详细解释每一步。模型在同一个上下文里收到矛盾的指令输出质量飘忽不定。关键约束被淹没。真正重要的规则比如安全边界夹在几十条常规指令里模型经常忘记最关键的那条。维护成本高。改一条规则要通读整个大文件生怕动了别处的逻辑。绝大多数教程只告诉你要有规则没人告诉你当规则从几条涨到几十条时该怎么办。这是规模问题不是有无问题。错误尝试第一次猜测拆成多个文件每次全加载我把规则按主题拆成多个 markdown 文件review.md、test.md、security.md……然后在CLAUDE.md里用 include 指令全部加载。结果文件是清楚了但每次对话的总 context 一点没少。结构清晰 ≠ 轻量。第二次尝试按主题分文件默认全开我进一步优化——按主题分好但仍然是默认全部加载。想着反正我文件结构好了以后再说。结果和第一次没有本质区别——只要不改变默认全开的策略规则总数没有降膨胀依旧。关键观察我翻了近一个月的使用历史发现一个明显规律任务类型实际需要的规则占全部规则比例代码审查review core~15%写单元测试test core~12%架构设计architecture core~10%安全审计security core~8%日常编码core 仅 3 条~5%pie title 实际规则使用比例 当前任务相关 : 10 无关规则噪声 : 9090% 的规则对 90% 的具体任务都是噪声。让模型每次对话都通读全部规则等于让每个候选人都答完整套试卷不管他面试什么岗位。定位真正原因问题不在于规则多而在于所有规则始终在场。正确思路是常驻最小底线 按需加载能力。把该加载哪条规则的判断从模型在一堆规则里自己找提前到加载阶段按任务筛选——相当于给 Agent 做了一层规则检索Rule RAG。Rule RAG 这个类比值得展开传统 RAG 是 问题 → 检索知识 → 生成回答。Rule RAG 是 任务 → 检索规则 → 执行动作。两者本质上都是同一个模式不在推理时把所有信息硬塞给模型而是在需要时把对的信息送进去。这个模式在 AI Engineering 里会越来越常见。如果你理解了 Rule RAG你也就理解了未来很多 Agent 系统的设计方向。最终方案core / heavy 双层core/3 条最小常驻规则行为底线任何任务都生效不可妥协heavy/20 个能力文件按任务类型加载代码审查、架构设计、测试、安全……实际收益指标重构前单文件重构后core/heavy默认加载的规则数50 条3 条core平均每条指令的响应时间~8s~3s非科学测算主观感受规则冲突概率高所有规则平等并列低core 优先于 heavyheavy 互斥修改单条规则的耗时~15min需通读全文避险~2min直奔文件无副作用新增一条规则的顾虑高——怕动到已有规则低——加一个新 heavy/ 文件即可这些数据来自经验估算不是严格的 A/B Test。但它们反映了分层前后的量级差异。架构图 / 流程图加载逻辑core 始终生效heavy 文件根据任务类型按需注入互不干扰。代码或配置示例目录结构D:\.claude-data\ ├── core\ # 常驻层 - 任何任务都加载 │ └── 00-must.md # 3 条最小行为底线 ├── heavy\ # 能力层 - 按任务类型加载 │ ├── 10-review.md # 代码审查规范 │ ├── 20-test.md # 测试规范 │ ├── 30-architecture.md │ ├── 40-security.md │ └── ... └── README.mdcore/ 常驻规则实际内容# core/00-must.md — 行为底线 core: - 始终使用中文回复 - 修改文件前先 Read 原始内容 - 提出架构方案时必须说明 trade-offheavy/ 能力文件示例# heavy/10-review.md — 代码审查规范 trigger: 用户要求代码审查或提交变更 max_lines: 300 priority: - 设计问题 - 正确性 - 可读性 - 性能 rules: - 每个问题必须有「描述 反例 改进建议」 - 不指出缺少文档/注释等非功能性建议加载逻辑伪代码def build_agent_context(task_type: str) - list[str]: 根据任务类型构建 Agent 上下文 context [] # 1. 常驻永远加载 context load_file(core/00-must.md) # 2. 按需根据任务类型加载 task_rules { review: [heavy/10-review.md], test: [heavy/20-test.md], arch: [heavy/30-architecture.md], security:[heavy/40-security.md], } for rule in task_rules.get(task_type, []): context load_file(rule) return context设计权衡方案优点缺点为什么不选全部塞一个文件最简单零学习成本context 爆炸、规则互相干扰、关键约束被淹没短期省事长期灾难。规则20 条后维护成本指数上升分文件但全加载结构清晰职责单一总 context 没降token 浪费依旧只解决了组织问题没解决膨胀问题core/heavy 分层常驻 3 条、按需加载、互不打架需设计加载触发逻辑选择理由把规则是否出现变成动态决策。唯一能随规则增长而保持轻量的方案分层不是银弹。如果规则本就很少≤10 条或任务无法分类一个文件就够了。不要在不需要分层的地方强行分层。总结✅ 规则不是越多越好是在需要时出现才好。✅ 常驻只放不可妥协的底线其余一律按需。✅ 每个heavy/文件要单一职责方便按需组合。✅ 给每个能力文件定义清晰的触发条件否则还是会变成全开。✅ 设计权衡要诚实——该用单文件时就用不要为了技术而技术。参考资料Lost in the Middle 论文→ 为什么关键指令不能放中间直接影响了 Rules 的放置策略Claude Code 官方文档 — Rules Project 配置→ heavy 按需加载的工程基础Hermes Agent — Skills Rules 管理→ 另一套验证此模式的实践上一篇AI Agent 工程实践01AI Engineering OS 整体架构设计下一篇AI Agent 工程实践03Memory 设计——Agent 到底应该记住什么