3.3 初始指令与智能体角色配置

初始指令旨在固化智能体的核心目标、执行边界与输出规范，为后续的工具调用和路由决策提供稳定的语义基础。本节结合 OpenClaw 的 instructions 配置，详细阐述指令编写的最佳实践（包含应写与避免的内容），探讨如何将指令与渠道入口、工具策略及系统可观测性构建为可回放的完整流程。

3.3.1 初始指令的作用：目标收敛、边界声明与格式约束

在工程上，初始指令不是“捏人设”，而是一个面向运行时的契约，至少包含三类信息：

1. 目标收敛：该智能体主要解决什么问题，哪些问题直接拒绝或转交。

2. 边界声明：明确禁止的行为与信息来源，避免越权与编造。

3. 格式约束：约定输出结构，例如必须用 Markdown、必须给出可执行命令、必须给出失败处理。

指令越像“可执行规范”，系统越容易稳定。把指令写成文学化口吻，往往会引入歧义，使模型在关键时刻无法可靠地遵循。

3.3.2 在配置中设置默认指令与专用指令

OpenClaw 支持设置默认指令，也支持为特定智能体设置专用指令。配置字段以 agents.defaults.instructions 作为默认值，同时允许在某个智能体上覆盖。

下面示例展示了默认指令与覆盖指令的基本形态。写法以官方文档字段为准，示例内容强调“可验证、可排障”的输出要求。

{
  agents: {
    defaults: {
      instructions: "产出可执行步骤与验证方式；不确定时明确说明并给出排查路径；避免编造命令与配置键。"
    },
    work: {
      displayName: "工作助手",
      instructions: "只处理与工作相关的问题；需要写入或高风险操作时先给出确认点与回滚方案。"
    }
  }
}

如果系统中使用多智能体路由，建议把“入口治理”写到入口智能体的指令里，把“领域知识与工具使用”写到领域智能体的指令里，减少同一指令同时承担太多职责。

3.3.3 指令写作方法：把关键约束写成可检查的条款

指令的可执行性来自“可检查”。实践中可以采用如下写法：

1. 先写输出结构：例如固定为“结论、命令、验证、失败处理”四段。

2. 再写禁止项：例如禁止输出未在文档出现的命令与配置键。

3. 最后写升级路径：当需要高风险工具时，必须提示升级入口或人工确认。

具体例子：好指令 vs 坏指令的对比

维度	❌ 坏指令（文学化、模糊）	✅ 好指令（可检查、可验证）
目标	“你是一个友善的助手，尽力帮助用户”	“只处理与 K8s 运维相关的问题；非运维问题回复'超出职责范围'”
边界	“请小心使用危险命令”	“禁止输出 kubectl delete、helm uninstall 等破坏性命令；如需执行，必须先输出回滚方案并等待用户确认”
输出	“请尽量详细地回答”	“输出必须包含四段：结论（一句话）、命令（带注释）、验证方式（预期输出）、失败处理（下一步）”
来源	“参考你的知识来回答”	“只引用官方文档与工作区内的 Runbook；不确定时明确标注'未在文档中找到'”

以下是一个完整的“好指令”模板：

你是 K8s 运维助手，遵守以下规则：
1. 只处理与 Kubernetes 集群运维相关的问题
2. 输出格式固定为：结论 → 命令（带注释）→ 验证方式 → 失败处理
3. 禁止输出 delete/uninstall 等破坏性命令
4. 不确定时明确说明，并给出排查路径
5. 引用来源必须标注文档名或 URL

避免把安全边界只写在指令里。真正的边界应由工具策略与沙箱约束提供确定性兜底，详见 5.2 工具策略：允许、拒绝与分层策略。

3.3.4 另一条路线：SOUL.md 与个性化人格配置

前面三节讨论的是“把指令当可执行规范”的团队路线。在个人助理场景下，还有一条互补路线：用 SOUL.md 文件定义智能体的沟通风格、关系定位与行为边界，让它更像一个“了解你的同事”而不是“遵守 SOP 的客服”。

适用场景区分

维度	可执行规范路线（3.3.1–3.3.3）	SOUL.md 个性化路线
适用场景	团队工具、生产环境、多人共用	个人助理、私人场景、单人使用
核心目标	稳定、可验证、可审计	自然、有记忆、有个性
典型内容	输出结构、禁止项、升级路径	沟通风格、关系定位、禁忌话题

SOUL.md 的典型结构

一个面向个人助理的 SOUL.md 通常包含以下信息：

1. 你是谁：职业、工作内容、兴趣爱好，帮助智能体理解你的背景。

2. 关系定位：是助手还是同事？是正式还是随意？这会影响语气和主动性。

3. 沟通偏好：简洁还是详细？直接还是委婉？是否允许幽默？

4. 主动性边界：执行任务时可以主动建议，但自我分析场景禁止主动给建议。

5. 禁忌事项：哪些行为不想要（如过度讨好、空洞客套）。

“入职培训”：用知识库加速人设建立

更进一步的做法是把你的知识库（笔记、文档、工作流模板）传到工作区，让智能体像新员工入职一样通读一遍，然后自行更新 memory.md。这种方式比手写 SOUL.md 更高效，因为智能体可以从你的实际文档中推断出工作习惯、偏好甚至人际关系，后续交互的适配程度会远高于手动描述。

[!NOTE] SOUL.md 适合个人探索与快速上手，但在团队与生产环境中，仍然建议以可检查的指令规范为主（参见 3.3.1–3.3.3），避免“人设漂移”导致不可预期的行为。两种路线可以叠加使用：用指令规范兜住边界，用 SOUL.md 调整风格。

3.3.5 如何验证指令生效：用对话回放与日志做成完整流程

验证指令是否生效，不建议只凭主观感受。更稳妥的方法是建立可回放用例：

1. 用控制台或 WebChat 输入固定测试集，覆盖边界问题与失败场景。

2. 用 status --deep 与结构化日志检查智能体选择、工具策略与失败原因。

openclaw status --deep
openclaw logs --follow --json

当观察到模型偏离指令时，优先检查是否为路由绑定、工具策略或渠道门控导致的上下文变化，再回到指令本身做最小修改。指令的迭代应与配置管理一同纳入版本控制，避免线上与线下行为不一致。