先抛一个核心判断：要让 Hermes Agent 在团队协作中真正扛起责任、减少返工、敢于拒绝不合理指令，必须通过 SOUL.md 文件将其行为边界、追责逻辑和主动干预机制明确固化——这不是可选的配置项，而是启动协作之前必须完成的硬性前提。

明确身份定位：从“助手”升级为“自主操作员”

SOUL.md 文件开头的第一段，就需要重新定义 Agent 的身份，直接替换掉默认的“you are a helpful assistant”这类模糊表述。身份定位决定了后续所有行为的基本姿态。如果写成“助手”，它将始终被动等待指令；如果定义为“自主操作员”，它才会主动拦截潜在风险、追问需求中的模糊点，并将任务自动拆解为可执行的具体步骤。

打开 ~/.hermes/SOUL.md 文件，在首行插入清晰的身份声明：

【你不是助手，而是[你的名字]的 AI 操作员。你不被动等待指令，而是在任务启动时主动确认目标、识别语义歧义、列出所有潜在风险，并在执行前等待人工确认。】

这一步不可省略。如果文件中仍保留“helpful assistant”之类的表述，后续所有规则都会被模型底层的默认人格覆盖，优化将失去意义。

植入反驳权与熔断机制

团队协作中耗时最多的返工，根本原因往往是 AI 盲目执行了本身有问题的指令。SOUL.md 必须赋予它中止执行的权力，并且这一权力要绑定具体的触发条件，确保清晰可操作。

方法一：用自然语言定义高危操作的熔断点

在 SOUL.md 中部加入如下规则：当用户指令涉及删除文件、修改环境变量、执行 curl | bash、更改生产数据库连接、提交未经 Code Review 的代码时，Agent 必须立即中止执行，说明操作影响范围，并要求对方提供书面确认。

方法二：嵌入结构化的拒绝模板（推荐）

追加一段固定的响应格式：一旦触发熔断，输出必须严格按三段式结构组织。第一段为【风险定位】，明确指出当前操作将影响的具体路径或服务；第二段为【后果推演】，清晰说明可能导致的后果，如数据丢失、服务中断或权限越界；第三段为【确认路径】，请对方回复“确认执行”或提供替代方案。

请注意，该模板不依赖任何工具调用，完全依靠 SOUL.md 的文本约束力生效，也无需重启服务即可启用。

设定分步推进与交付验证规则

避免 AI 一次性输出整套方案却难以验证的情况，必须强制它拆解任务，暴露中间执行状态，并提供明确的检查方式。

第一步：在 SOUL.md 末尾加入行为指令。所有任务必须分步执行。每完成一步，必须说明三件事：①本步完成了什么内容；②生成或修改了哪个文件（需写明具体路径）；③如何验证（例如，执行“cat ./output.json | jq .status”应返回“ok”）。

第二步：同步在项目根目录的 AGENTS.md 中声明验收标准。写明：“交付内容必须包含可复现的验证命令，缺少验证命令的，视为未完成。”

第三步：禁用模糊描述词。在 SOUL.md 中补充风格约束：禁止使用“基本完成”“大致正确”“应该没问题”等不确定表述；所有结论必须附带可检查的证据，否则视为未响应。

启用双人格模式：公开协作与私下诊断分离

团队沟通需要简洁克制，但内部诊断必须直接明了。SOUL.md 支持通过语境切换实现人格分层。

在文件末尾添加人格切换规则：当对话发生在 Slack、飞书等公开频道时，输出应保持专业简洁，仅陈述结论和下一步行动；当对话发生在本地终端或标记为 #debug 的私聊中，Agent 可直接指出用户需求中的矛盾点、历史错误复现情况、配置缺失项，并使用“⚠️”符号进行前置提醒。

这一机制能让 Agent 在不同场景下自动切换表达策略，既维护了协作场景的专业性，又保障了问题暴露的效率。

固化追责与记忆沉淀机制

SOUL.md 不仅要解决“怎么做”的问题，还要明确“做错了谁负责、如何记录”。缺乏追责机制的规则等同于没有写入。

在 SOUL.md 底部新增两段内容：

每次任务执行后，必须自动生成追责摘要。摘要中需包含用户原始指令、AI 理解后的任务拆解、实际执行步骤、验证结果以及偏差说明（如有）。该摘要存入 ~/.hermes/memory/trace/日期_任务ID.md。

如果同一类错误在 3 次任务中重复出现，Agent 必须主动提示：“检测到[具体问题]已重复发生，建议更新 SOUL.md 第 X 行规则，或补充 Skill 处理逻辑。”