一、定位与设计目标

OpenClaw 六层提示词组合是配套配置分离、上下文管理、深度推理自适应、三层Tool治理、SubAgent安全约束、Context Compaction构建的标准化 Prompt 组装范式，属于 UpClaw「提示词工程」改造板块核心落地形态。
底层依托 ContextEngine 上下文引擎，在 before_prompt_build 生命周期钩子完成自动拼装；严格遵循刚性约束在前、柔性引导在后、静态基线在前、动态运行时内容在后的优先级原则。

核心痛点（扁平单段提示词的缺陷）

1. 所有规则、角色、工具混写在同一个System Prompt，边界混乱，模型容易忽略安全红线；
2. 无法分层独立迭代，修改业务描述有可能误删安全规则；
3. 压缩、记忆注入、子代理场景难以动态增删片段；
4. 缺少标准化优先级，模型对约束权重感知不稳定；
5. 审计困难，无法区分哪一段配置导致Agent行为异常。

六层自上而下固定顺序，越上层优先级越高，模型越优先遵守：

1. 第1层：全局刚性安全约束层（rules.md）
2. 第2层：代理身份与基线行为层（IDENTITY.md + SOUL.md）
3. 第3层：多代理通信与任务调度层（AGENTS.md）
4. 第4层：工具契约与技能流程层（TOOLS.md + SKILL.md）
5. 第5层：记忆与上下文使用规范层（MEMORY.md）
6. 第6层：运行时动态注入层（动态可变内容）

关键约定

• 1～5层：静态基线，由独立MD文件承载；会话初始化完成解析；
• 第6层：纯运行时动态数据，每一轮推理动态重建；
• Context Compaction、深度推理自适应、子代理结果回流全部作用在第6层；
• 所有层级支持独立开关（ConditionalOnProperty），可按租户/Agent/环境按需启用。

---

二、六层逐层详细拆解

第1层：全局刚性安全约束层｜rules.md（最高优先级）

承载载体

rules.md，由 SecurityPolicy 插件解析，同时生成规则引擎用于运行时拦截。

写入时机

会话初始化加载，Prompt拼装最顶端。

内容边界（只允许写红线，禁止写入业务流程、语气、场景话术）

1. 工具黑白名单、高危操作限制；
2. 推理预算上限、单轮工具调用最大次数；
3. 子代理委派约束：最大深度、禁止递归、权限收缩要求；
4. 输出强制规范：禁止编造数据、敏感信息脱敏、不能越权回答；
5. 熔断规则：遇到哪些场景必须拒绝执行；
6. 合规、隐私、数据隔离要求。

特征

• 不可被下层内容覆盖；
• 不仅作为文本提示词，同时编译为运行时规则引擎（三层Tool治理、SubAgent安全拦截复用同一套规则）；
• 命中违规时，运行时可以直接阻断执行，不需要依赖模型自觉遵守。

生命周期联动

onSessionCreate 预加载；before_prompt_build 最先拼接；on_llm_output 再次独立校验模型输出行为。

第2层：代理身份与基线行为层｜IDENTITY.md + SOUL.md

承载载体

IDENTITY.md + SOUL.md
顺序：IDENTITY → SOUL

写入时机

紧随rules.md之后。

IDENTITY.md

代理唯一身份标识：名称、职责边界、归属业务线、对外身份名片；回答的基础定位。

示例：你是企业订单查询智能体，仅负责订单相关咨询。

SOUL.md

人格、价值观、表达范式、诚实性原则、输出格式基线：

• 说话语气、行文风格；
• 禁止主观臆断，无数据必须如实说明；
• 长回答分段规范、输出模板约定；
• 基础行为底线（柔性约束，低于rules.md）。

边界区分

• rules：不能做什么（红线，禁止类）
• IDENTITY+SOUL：你是谁、应该怎么做事（基线规范）

第3层：多代理通信与任务调度层｜AGENTS.md

承载载体

AGENTS.md

核心内容

1. SFA2A 子代理委派协议规范；
2. 允许创建哪些子代理、委派时机判断标准；
3. 父子代理消息格式、结果回流解析规则；
4. 任务拆分原则：什么场景需要拆分任务派发给子代理；
5. 子代理返回摘要如何整合、不能直接原样输出子代理原始日志。

联动模块

SubAgent三层安全约束（黑白名单、防递归、防污染）；SubAgentDispatchSpan 追踪。

无多代理场景时，可通过条件开关直接剔除本层，减少Token消耗。

第4层：工具契约与技能流程层｜TOOLS.md + SKILL.md

承载载体

全局 TOOLS.md + skills/*/SKILL.md
顺序：TOOLS.md（原子工具清单）→ 各SKILL.md（组合业务流程）

TOOLS.md

所有底层原子Tool标准化契约：工具名称、入参、返回结构、调用前提；告诉模型“系统有哪些基础能力”。

SKILL.md

业务技能流程：多工具串行/并行调用步骤、触发条件、参数填写规范、失败重试逻辑。
对应三层Tool治理第一层【业务引导层】。

重要约束

SKILL仅引导模型行为；最终是否允许执行，仍然由第1层rules.md + ToolAdapter沙箱双层防护兜底。

第5层：记忆与上下文使用规范层｜MEMORY.md

承载载体

MEMORY.md

内容定义

1. LongTermMemory什么时候检索、如何使用召回历史记忆；
2. 哪些对话内容需要写入长期记忆；
3. 记忆摘要解读规则；
4. 上下文压缩后的摘要如何理解、不能忽略摘要信息；
5. 跨会话历史信息使用边界，禁止滥用无关记忆。

联动组件

Context Compaction四阶段压缩、CJK优化、LongTermMemory存储插件。

第6层：运行时动态注入层（无静态MD，每轮动态构建）

唯一每一轮推理都会重建、动态变化的层级。
包含五大类动态片段，拼接顺序固定：

1. 当前会话有效长期记忆召回片段（向量检索实时获取）
2. 最近N轮未被压缩保护窗口内的原始对话历史
3. 子代理执行返回结构化摘要结果（如有委派）
4. 工具执行返回结果（本轮已完成的tool_result）
5. 用户本轮最新输入消息

关键特性

1. 受Context Compaction管控：老旧历史会被摘要替换，降低Token占用；
2. 深度推理自适应读取本层复杂度，计算thinking预算；
3. 子代理防污染机制：只回流摘要，不回灌子代理完整中间日志；
4. CJK优化、反抖动压缩全部作用在这一层；
5. 会话之间完全隔离，不存在跨会话污染。

六层完整拼装顺序文本示例（逻辑视图）

===== 【第1层 rules.md 刚性安全规则】
# 全局不可突破红线
1. 禁止调用删除类工具
2. 单轮最多调用3次工具
3. 不得编造不存在订单数据

===== 【第2层 IDENTITY + SOUL.md】
# 身份
你是企业订单客服智能体
# 人格
回答简洁客观，缺少信息主动向用户询问，不主观猜测

===== 【第3层 AGENTS.md】
# 子代理委派规则
需要退款审批时，调用spawn_subagent发起审批子任务；
子代理返回结果仅提取结论，不直接输出原始日志

===== 【第4层 TOOLS.md + SKILL.md】
# 可用工具
query_order(order_id) 查询订单信息
# 技能流程
用户提供订单号 → 调用query_order → 根据订单状态回复用户

===== 【第5层 MEMORY.md】
# 记忆使用规范
优先参考召回历史对话；久远历史经摘要压缩，以摘要结论为准

===== 【第6层 动态运行时内容】
【历史记忆摘要】
用户上一轮咨询订单10001，未完成退款申请
【近期对话】
用户：我想查订单
助手：请提供订单编号
【用户最新输入】
订单号10001，申请退款

三、六大配套运行时机制（与六层体系深度绑定）

1. 分层独立开关（基于 12+ ConditionalOnProperty）

每一层支持独立启用/禁用，实现精细化Token成本控制：

• 无子代理场景 → 关闭第3层 AGENTS.md；
• 临时不需要长期记忆 → 关闭第5层MEMORY.md；
• 简单问答Agent → 精简第4层SKILL集合。

2. 分层快照与Langfuse四层追踪

每一轮Prompt构建完成后：

• ContextEngineSpan 记录每层MD版本、是否启用；
• Generation节点挂载完整分层Prompt快照，便于问题复盘；
  可以直接定位：是规则缺失、身份描述错误，还是技能流程写错导致Agent异常。

3. Context Compaction交互逻辑

压缩只作用在第6层动态内容；
1～5层静态基线永久保留、不参与摘要压缩；
避免关键规则、身份、工具契约被压缩丢失，防止模型失忆。

4. 深度推理自适应联动

复杂度打分器读取第6层动态内容：

• 是否存在大量历史记忆；
• 是否包含子代理结果；
• 是否需要多轮工具调用；
  自动计算任务复杂度，分配对应思考预算。

5. SubAgent父子Prompt隔离

父代理完整六层Prompt不会复制传递给子代理：

1. 子代理加载自身独立一套六层MD配置；
2. 仅把必要任务指令放入子代理第6层动态上下文；
   实现防污染，避免父代理庞大提示词、大量上下文膨胀子代理窗口。

6. 冷热分层加载优化

• 1～5层MD：onSessionCreate一次性解析缓存，会话生命周期复用；
• 第6层：每一轮 before_prompt_build 实时组装；
  大幅减少磁盘IO与文本重复序列化开销。

四、六层提示词体系完整生命周期介入点

1. onSessionCreate
   加载、解析、缓存1～5层全部MD文本；执行条件开关判断是否启用某一层。
2. before_prompt_build（核心卡点）
   按固定顺序拼接1~5层基线；准备第6层动态素材（召回记忆、读取对话历史、收集子代理/工具结果）；组装完整System+上下文；生成ContextEngineSpan埋点。
3. onReasoningStart
   完整Prompt传入ModelProvider，同时触发深度推理自适应打分。
4. LLM推理执行
   模型自上而下读取六层文本，优先遵守上层约束。
5. after_agent_turn
   更新对话历史，写入长期记忆，为下一轮第6层动态内容准备素材。

五、六层提示词体系 优缺点

优势

1. 权责清晰，分层迭代安全
   修改业务技能只改动第4层；调整安全红线只改动第1层；互不干扰，不会误删关键约束。
2. 权重稳定可控
   固定自上而下优先级，模型行为可复现；不会因为文本排版顺序随机波动。
3. 灵活裁剪，控制Token开销
   根据场景开关不需要的层级（多代理、记忆、复杂技能），轻量化简易Agent。
4. 和整套企业能力原生联动
   与安全规则引擎、沙箱防护、子代理、上下文压缩、观测追踪形成闭环。
5. 问题可观测、易排障
   通过Langfuse查看每层生效内容，快速定位：规则缺失 / 身份描述错误 / 技能流程缺陷。

短板

1. 分层越多，静态基线基础Token越高，极简闲聊Agent会有基础开销；可通过条件开关关闭多层进行优化；
2. 需要规范MD写作边界，如果把业务流程写到rules.md或者把安全红线写到SKILL.md，会破坏优先级设计；
3. 初次搭建需要标准化规范，团队需要统一约定各MD文件写作范围。

六、横向对比：原生AgentScope / Codex / Claude Code

1. 原生 AgentScope
   无分层体系，大多采用单段硬编码System Prompt；无法分层开关、独立迭代；缺少刚性规则与业务引导分层隔离。
2. OpenAI Codex
   扁平提示词结构，内置代码能力基线；不支持多层MD配置分离；没有独立安全规则层，无法区分红线约束与业务流程。
3. Claude Code
   支持外部文件导入提示词，但没有标准化六层优先级规范；无配套运行时规则引擎，提示词仅作为文本，不存在运行时拦截兜底。
4. OpenClaw 六层提示词组合
   文本提示词 + 运行时规则引擎双轨并行；分层固化优先级；配套全套可插拔运行时、安全、观测、上下文治理体系，面向企业持续迭代的多Agent中台设计。

七、落地最佳实践（MD写作边界禁令）

✅ rules.md：只写禁止、上限、权限、熔断规则
✅ IDENTITY.md：只写身份、职责边界
✅ SOUL.md：只写人格、输出范式、诚实性要求
✅ AGENTS.md：只写子代理委派协议、任务拆分逻辑
✅ TOOLS+SKILL：只写工具能力、业务执行步骤
✅ MEMORY.md：只写记忆读写与解读规则

❌ 禁止在下层MD写入安全红线；
❌ 禁止在rules.md写业务闲聊话术、流程描述；
❌ 禁止将动态会话历史写入1～5层静态MD；

八、典型落地场景示例

场景：企业售后多子代理客服Agent

1. 第一层rules：禁止删除工单、限制工具调用次数、禁止内网越权查询；
2. 第二层身份：售后客服，语气礼貌，不承诺超出权限政策；
3. 第三层AGENTS：需要工单创建、退款审批时派生子代理；
4. 第四层SKILL：查询客户信息→查询工单→回复客户标准化流程；
5. 第五层MEMORY：记住客户历史诉求，优先召回近7天对话；
6. 第六层动态：召回历史记忆 + 当前轮对话 + 用户最新提问。