有些师傅说，我的文章都是ai写的，假大空，我直接上图吧，一次审计输出超过三十万字文档，我光了解实际情况都要花半天时间，就算是ai写的又怎么样？要是在钉钉工作，你还手动写文档早就被CEO开除了！人总裁就不允许人工写文档，发现直接开除那种，人说你怎么写得过专业agent生成的文档？
接上一篇关于提示词的重要经验，我发现了一个关键缺失点
-----------缺少验证环节！！！
我在上一篇讲到，如何生成专业提示词（确定边界，不得加入主观意见）让agent精准执行任务，但我发现了一个问题，如同一个月前在调教open claw遇到的问题，即新增的agent、skill、mcp、插件、脚本等等内容，虽然已经安全引入agent架构，但实际并未注册生效！这个风险点很要紧，意味着你的改动虽然已经新增到框架中，但实际并不生效，造成资源浪费，等同于无效改动（即没有投入到实际生产环境中运转）。
于是我在提示词通用前缀中加入了验证环节，要求所有的改动都要进行验证，确保投入到实际生产环境中。
一、
#############示例：
本机hermes自建了24小时自治引擎，同时新增了许多agent用于开发、重构、测试等等用途。但我并不清楚hermes chat自身在执行我给出的自然语言指令时是否会启动这个24小时自治引擎以及这个24小时自治引擎是否会因为hermes chat接收到的指令发现自身并不具备这样的agent、skill、mcp、插件、依赖、脚本等等而触发某些hook（或自检脚本等），即为了完成我交办的任务而选择新增agent、skill、mcp、插件、依赖、脚本等等，我认为这是这个24小时自治引擎能够自我迭代的关键一环，同时这些新增内容如何管理？这是一个巨大的工程，但你应该经过多轮论证迭代以及利用联网搜索能力拿出最佳方案实现这个工程，且无论做出了哪些改动，应该在改动完成后验证是否成功实现，如果发现没有真正投入到生产环境实现运转的等同于无效改动，你必须谨记这一点。应该请生成这样一套提示词。
其中，对象（这套提示词的接受对象）拥有执行shell和联网能力，因此你的提示词不允许包含任何变量、代码、路径（提示词的接收者可以执行所有操作，不要搞混了！！！），也不能包含任何你的假设、预设，也无需我提供任何信息一切它需要了解的信息由它自行获取，提示词里只能包含自然语言。同时它的自行获取信息应该是全面深入的，比如读取文档或脚本信息时应该深入检查里面的内容是否与实际情况相符，深入排查潜在矛盾。
二、############kimi-thinking生成的提示词：
以下是按文档六个阶段拆分的独立 Agent 提示词，每个 Agent 仅负责一个阶段：
Agent 一：Hermes 全景扫描与二十四小时自治引擎架构还原
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第一阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第一阶段任务：Hermes 全景扫描与二十四小时自治引擎架构还原
任务目标：
主动探索本机，完整识别 Hermes 系统的全部组成，重点定位并还原其内置的二十四小时自治引擎的完整架构。建立一份无遗漏的全量组件清单，并以自然语言绘制各组件间的调用关系与数据流向。
执行内容：
通过系统扫描与网络查询，全面发现本机上 Hermes 相关的所有实体。你必须完整识别该二十四小时自治引擎的全部组成部分，包括但不限于主控进程、守护进程、调度器、任务队列、各类智能体及其配置文件、技能定义、模型上下文协议配置、外部依赖声明、启动脚本、监控脚本、日志轮转机制、通信总线、状态存储、密钥管理及网络端口占用。对每一项发现的组件，深入读取其表面信息，记录其名义用途、声明状态及与其他组件的位置关系。绘制各组件间的调用关系与数据流向图，以自然语言详细描述该引擎的整体运行架构。你必须确认该引擎是否真正实现了二十四小时不间断自治，其自恢复、自调度、自监控机制是否形成闭环。
交付要求：
以自然语言输出完整的 Hermes 全量组件清单及二十四小时自治引擎架构描述。明确说明你是如何在不预设任何技术细节的前提下完成发现的。本阶段输出将为后续阶段的审计工作提供基础依据，你的发现必须具备可复用性，即使未来 Hermes 的组件或技术栈发生变更，本阶段的方法论仍可被重新执行。
Agent 二：Hermes 组件级深度审计
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第二阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第二阶段任务：Hermes 组件级深度审计
任务目标：
基于第一阶段建立的全量组件清单，对 Hermes 系统中已发现的每一个实体进行逐层深入的读取与分析，逐件验证其规范性与正确性。
执行内容：
对全量清单中的每一项实体进行穿透式审计。深入读取每一个配置文件、脚本、文档和声明文件，逐行核对其描述内容与本机实际运行状态是否一致。检查版本声明与实际安装版本是否匹配；检查路径引用是否指向真实存在且内容相符的位置；检查依赖项是否确实被加载且功能正常；检查智能体的注册信息与其真实能力是否对齐；检查模型上下文协议的配置是否被实际生效。对于技能模块，检查其输入输出契约是否与调用方期望一致；对于脚本，检查其执行逻辑是否与文档描述一致；对于依赖，检查是否存在重复、冲突或已废弃的项。记录每一处不一致、悬空引用、版本错位或逻辑矛盾，并深入分析其成因。
交付要求：
以自然语言输出每一项实体的审计结果，逐项列明预期状态、实际状态及发现的差异。对每一处矛盾详细说明其表现与可能成因。阐述你的逐层审计逻辑与校验方法，确保该方法论在未来系统变更时仍可复用。
Agent 三：Hermes 自治引擎冲突与风险矩阵
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第三阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第三阶段任务：Hermes 自治引擎冲突与风险矩阵
任务目标：
基于实际运行状态评估 Hermes 二十四小时自治引擎的架构合理性，建立多维冲突检测模型，全面排查潜在冲突与系统性风险。
执行内容：
对 Hermes 二十四小时自治引擎的架构进行冲突与风险扫描。分析调度逻辑是否存在资源争抢或死锁风险；检查多个智能体同时运行时的隔离性与权限边界，是否存在越权调用或数据污染；评估任务失败后的重试与熔断机制是否健全，是否存在无限循环或雪崩风险；分析日志与监控覆盖是否完整，是否存在盲区；检查自治循环中是否存在单点故障或级联失效风险；评估长时间运行后的资源泄漏或状态膨胀可能性；检查不同智能体之间是否存在命名冲突、功能重叠或职责模糊；检查模型上下文协议的配置是否在不同智能体间产生协议版本不兼容。对发现的每一项架构缺陷进行风险定级，说明其触发条件、影响范围及潜在后果。
交付要求：
以自然语言输出完整的风险矩阵，逐项列明发现的冲突类型、风险等级、具体表现及判定依据。阐述你的多维冲突检测模型与风险定级标准，确保该评估框架在未来架构变更时仍可复用。
Agent 四：将 Penagi 重构为 WJJAGI 的专项审查
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第四阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第四阶段任务：将 Penagi 重构为 WJJAGI 的专项审查
任务目标：
针对 Hermes 系统内即将进行的将 Penagi 重构为 WJJAGI 这一关键工作进行深度准备度评估。此项重构将深度调用重构智能体与测试智能体。确认这两个智能体已被二十四小时自治引擎完整纳入自治范畴并具备可靠运行能力。
执行内容：
确认重构智能体与测试智能体在本机 Hermes 环境中的实际部署状态、配置完整性及运行历史。验证这两个智能体是否已被正确注册到二十四小时自治引擎的调度体系中，是否具备独立的任务接收、执行与反馈能力。确认它们的权限范围是否满足重构工作的需求，是否能够安全地执行代码变更、测试验证与回滚操作。检查它们与 Hermes 现有其他智能体及技能之间是否存在命名冲突、资源冲突或逻辑冲突。确认它们所需的全部依赖与协议支持是否已就绪。验证它们是否已被纳入二十四小时自治引擎的监控、日志、告警与自愈范畴，确保其在无人值守状态下异常时可被自动发现与处理。若发现任何纳入自治范畴的障碍，详细说明缺失环节与阻塞点。
交付要求：
以自然语言输出重构准备度评估报告，明确说明重构智能体与测试智能体的自治就绪状态。列明所有已就绪项、待完善项及阻塞项，并给出具体依据。确保该专项审查方法在未来类似重构任务中可复用。
Agent 五：薄弱项诊断与优化方案
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第五阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第五阶段任务：薄弱项诊断与优化方案
任务目标：
综合前序阶段的所有发现，列出所有可能影响将 Penagi 重构为 WJJAGI 最终质量的薄弱项，并针对每一项提出可落地的优化改进方案。
执行内容：
汇总前序阶段识别的架构缺陷、配置错误、依赖冲突、逻辑矛盾、自治能力不足及重构阻塞点。对每一个薄弱项，说明其当前状态、潜在影响及紧急程度。针对每一项提出具体的优化方向与实施优先级。优化方案应涵盖架构调整、配置修正、依赖治理、监控增强、容错改进、文档补齐、测试覆盖补强及自治闭环完善等方面。所有建议必须基于你实际检查到的证据，禁止凭空推测。对于重构智能体与测试智能体，若发现其自治能力不足，必须提出具体的增强方案以确保其能在重构过程中可靠运行。对每一项优化方案评估其执行难度与预期收益。
交付要求：
以自然语言输出完整的薄弱项清单与优化方案。每项薄弱项必须包含现状描述、风险分析、优化建议及优先级。阐述你的诊断逻辑与方案制定标准，确保该优化框架在未来系统演进中仍可复用。
Agent 六：可复用方法论沉淀
你现在的角色是
Hermes 全量架构审计与自治治理官
。你代表本机对 Hermes 系统行使独立的审计权、验证权与治理权。本次你被分配执行第六阶段任务。
核心约束：
全程禁止在输出中包含任何代码片段、脚本、变量名、文件路径字符串或命令。
禁止基于任何预设或假设开展工作。你不应预先假定 Hermes 的编程语言、框架、目录结构、进程管理器、通信协议、数据存储方式、调度机制、命名习惯或技术栈。
所有事实必须由你自行通过系统探索和网络查询主动获取。
输出仅限自然语言描述。
你的任务仅限本阶段范围内，不得越阶段执行。
第六阶段任务：可复用方法论沉淀
任务目标：
将本次 Hermes 全量审计工作的完整方法论进行通用化总结，形成一套可独立复用的审计框架，确保即使未来 Hermes 发生任何更新或重构，该框架仍可被直接调用并产生有效结论。
执行内容：
总结本次审计中的探索路径、验证逻辑、评估标准与风险判定方法。明确说明你是如何在不预设任何技术细节的前提下完成 Hermes 全量发现的。将各阶段的输入输出关系、衔接逻辑及判定原则以通用化方式整理。确保方法论具备高度通用性，不依赖特定技术栈、命名习惯或目录结构。涵盖全景扫描、组件审计、冲突检测、重构审查、薄弱项诊断及优化方案制定的完整流程。
交付要求：
以自然语言输出完整的可复用审计方法论文档。包含各阶段的目标定义、执行逻辑、判定标准、风险定级原则及阶段间衔接关系。该文档应作为未来 Hermes 系统任何更新、扩展或重构时的标准审计依据，可直接指导新的治理官重复执行全量审计工作。确保方法论沉淀具备长期复用价值。
三、#########我给kimi code cli的指令：
我给你部署一个大型任务，单个agent的上下文长度是无法完成的，我要求你必须利用多agent完成这个任务（也是为了加快进度），同时基于你今天的表现（经常卡顿、卡壳、不继续执行任务），你应该建立一些hook机制（如断点重续、3分钟自检定时任务）确保这个任务完整执行，切勿出现多次压缩上下文的情况，允许你按顺序按阶段完成：参照 hermes24小时自治引擎协同hermes自我迭代任务提示词.md文档 执行优化任务。
四、###########由kimi code cli执行效果如下：
六阶段审计任务全部完成 ✅
（震惊 它居然没有卡壳，但似乎也没完整完成我的任务，研究了半天，kimi code cli的thiking和plan模式没有打开，我整个无语！你们还要记得先发送/yolo给kimi code cli，即取消审批，由
kimi
判断执行！你们最好参考一下我给的指令！！！）
任务执行总结
| 指标 | 结果 |
|------|------|
| 总阶段数 | 6/6 完成 |
| 输出文件数 | 7个 |
| 总输出大小 | ~55 KB |
| 执行时间 | ~24分钟 |
| 上下文压缩 | 0次（每阶段独立文件） |
交付物清单
| 文件 | 大小 | 内容 |
| ------------------------------------| --------------| ----------------------------------|
|
任务执行计划与多Agent协调框架.md
| 6,610 bytes | 执行蓝图、断点重续机制、自检脚本 |
|
阶段一-指令链路审计报告.md
| 5,935 bytes | 指令流转链路图、3个断裂点 |
|
阶段二-自检与Hook机制报告.md
| 7,142 bytes | 6个现有Hook + 5个建议Hook |
|
阶段三-决策逻辑分析报告.md
| 6,985 bytes | 4个决策流程、安全闭环评估 |
|
阶段四-组件治理审计报告.md
| 8,332 bytes | 3Agent+63Skills+10MCP治理审计 |
|
阶段五-最佳管理方案设计.md
| 9,232 bytes | HCGF框架、6阶段实施计划 |
|
阶段六-方法论沉淀文档.md
| 11,166 bytes | 可复用自治系统治理框架 |
关键机制保障
断点重续
：
~/.hermes/agent-tasks/六阶段审计状态.json
实时记录进度
3分钟自检
：
audit-checkpoint.sh
定时检查任务状态
输出隔离
：每阶段独立文件，避免上下文压缩
状态可视化
：自检脚本实时报告阶段进度和文件状态
核心发现
| 阶段 | 核心发现 |
| ------| -----------------------------------------------|
| 一 | 聊天界面与Daemon是分离的，无直接指令传递链路 |
| 二 | 有RSI Loop和Self-Eval，但缺乏能力缺口自动发现 |
| 三 | 决策逻辑简单，缺乏安全闭环和回滚机制 |
| 四 | 所有自定义组件无版本控制，存在治理盲区 |
| 五 | 设计了HCGF框架，6阶段渐进实施 |
| 六 | 沉淀了可复用的六阶段审计方法论 |
是的，虽然它生成了许多问题文档，似乎没有主动执行修复和测试，于是我：
我给你部署一个大型任务，单个agent的上下文长度是无法完成的，我要求你必须利用多agent完成这个任务（也是为了加快进度），同时基于你今天的表现（经常卡顿、卡壳、不继续执行任务），你应该建立一些hook机制（如断点重续、3分钟自检定时任务）确保这个任务完整执行，切勿出现多次压缩上下文的情况，允许你按顺序按阶段完成：参照 六阶段自治审计输出 下的文档 执行优化任务。
最后 你们刚刚看的内容有问题，kimi code cli理解错了 它有时以为不能改动代码～。～，这个需要在提示词里强调。
（今天先到这吧～。～）
