群智泽强在本地 Hermes Smart Approval 上增加了 reviewer_profile 支持，使业务 Profile 可以调用 assistant-jd-manage 作为受限审核身份。它解决的是长时间异步内容工作中的审批衔接问题：人不必持续盯着审批消息，受控远程调用可以在不全局关闭安全机制的前提下创建、检查并发布网站内容；高风险、授权不明和硬性禁止操作仍由既有边界阻断或升级。
说明：reviewer_profile 是群智泽强对本机 Hermes 的扩展，不是 Hermes 上游或开箱即用的标准功能。本文记录的是特定本地版本上的技术实践，不构成通用安全保证；升级、重新安装或切换代码分支后需要重新核对和测试。
为什么传统人工审批容易卡住异步内容工作
Hermes 默认的人工审批适合偶发、高风险动作：命令触发安全规则后，系统发送审批卡片，由用户选择单次批准或永久批准。这种方式决策直接、边界清楚，但要求审批人在有效时限内看到并处理消息。
图 1：传统人工审批示例。图片使用本案例指定的完整脱敏版本，仅展示“需要人工处理审批消息”这一交互形态；它不能证明代理审核已经启用，也不能证明任何命令曾被批准或执行。
在内容生成、图片处理和远程平台操作等长时间异步任务中，人必须持续留意审批消息。若审批人同时处理其他工作，很容易错过或忘记后续卡片；审批超时后，原命令不会执行，重新发起又可能产生新的审批。Gateway 重启后，旧卡片即使仍显示在聊天中，对应的内存审批上下文也可能已经失效。
永久批准可以减少固定命令的重复确认，但白名单过宽会扩大风险，而且无法替代对未知命令的动态判断。因此，这次扩展没有关闭全局安全机制，而是把普通风险判断交给独立、受限的审核 Profile，把真正需要人的决定继续留给用户。
两层架构：业务策略与审核身份分离
方案保持两层结构。
第一层由业务 Profile 声明审批策略：启用 Smart Approval，设置人工升级等待时限，保持 cron_mode 为 deny，并指定本地审核 Profile。公开示例使用受支持的相对 Profile 名称，不包含真实机器的绝对路径：
approvals:
mode: smart
timeout: 60
cron_mode: deny
reviewer_profile: >-
assistant-jd-manage
smart_policy: >-
合法合规、授权明确、
影响受控且可回滚的
内容操作可以 APPROVE；
涉及违法违规、授权不明、
隐私或凭据泄露、权限与
身份变更、基础设施高危操作，
或影响范围与回滚方案不清的
操作应 ESCALATE；Hermes
硬性禁止项继续直接阻止。
上面的折叠标量等价于 reviewer_profile 使用 assistant-jd-manage 这一相对 Profile 名称。
第二层是在本机 Hermes 审核引擎中加入 reviewer_profile 的解析和加载逻辑。扩展涉及的仓库相对路径只有：
tools/approval.py
hermes_cli/config_defaults.py
这层扩展负责解析 Profile 名称或路径，校验审核 Profile 的 SOUL.md 与 config.yaml，加载其身份和模型配置，并优先使用该 Profile 的 auxiliary.approval 模型；未单独配置时再回退到其主模型。审核身份文本以受限方式注入固定审核提示词，Hermes 固定安全规则始终优先。
这里的 assistant-jd-manage 不是一个被完整启动的聊天 Agent。它只接收约束后的审核上下文，没有终端、文件、网络或消息工具，不能执行被审核命令，也不能修改系统，只返回审批判断。
一条命令如何经过审核
完整流程可以概括为：
- 业务机器人发起命令；
- Hermes 安全检测器判断命令是否需要审批；
- Hardline 硬性规则先行检查，命中时直接阻止；
- 再检查永久白名单、会话白名单和已有授权；
- 只有未命中白名单且确需审批的命令，才读取业务 Profile 的 smart_policy；
- 加载 assistant-jd-manage 的受限身份与模型配置；
- 审核器返回 APPROVE、DENY 或 ESCALATE；
- Hermes 根据结果继续执行、拒绝执行，或向用户发起人工审批。
四类结果的含义不能混淆：
- APPROVE：审核器代表用户批准本次命令，原命令继续执行。它适用于合法、授权明确、影响范围可确认且可回滚的常规操作。
- DENY：审核器拒绝本次命令，命令不再继续。它适用于明显不符合业务策略、风险收益不匹配或存在明确安全问题但不需要用户进一步裁决的请求。
- ESCALATE：审核器不代替用户决定，Hermes 转为向用户本人发送审批卡片。权限、身份、密钥、凭据、网络暴露、大范围迁移删除、不可逆操作和授权不明等情况应进入这一分支。
- Hardline：Hermes 的硬性禁止规则优先级最高。即使启用了 Smart Approval、业务策略允许，或审核器倾向批准，也不能绕过。
白名单与 Smart Approval 不是同一条链路
永久白名单只适合极窄、反复执行且已明确授权的固定命令模式。命中 command_allowlist 的命令会直接放行，不一定调用审核 Profile。因此，“命令执行成功”不能反向证明 assistant-jd-manage 参与过审核。
验证代理审核时必须先排除永久白名单和会话级授权。普通低风险命令也可能不触发安全检测，同样不能用来证明 Smart Approval 链路。白名单解决的是确定模式的重复授权，Smart Approval 解决的是需要动态判断的普通风险命令，两者的证明口径不同。
两个无真实资源副作用的链路测试
APPROVE：不存在的 systemd 服务
用于验证批准分支的命令是：
systemctl restart \
hermes-review-nonexistent.\
service
这是可执行的 shell 续行写法，实际目标仍是名为 hermes-review-nonexistent.service 的同一个不存在服务。
该命令会命中“停止或重启系统服务”的审核类别，又不在永久白名单内；目标服务明确且不存在。源记录显示，Smart Approval 返回批准，原命令随后继续执行，并因服务不存在而以 “Unit not found” 安全失败，没有改变任何真实服务。
这个结果证明的是：该次命令进入了 Smart Approval 的批准分支，且没有触发人工审批。它不证明所有服务重启都会获批，也不证明系统具备长期、完整的独立审计记录。
ESCALATE：不存在的 SSH 路径权限探针
用于验证升级分支的命令是：
chmod 777 ~/.ssh/no-such-file
示例使用较短的不存在路径。实际测试可以使用任何已经确认不存在的探针路径，但必须先确认它确实不存在，不能替换为真实密钥、配置或其他存在的文件。
目标文件不存在，但命令同时包含两个高风险信号：SSH 身份安全路径，以及对所有用户开放写权限的 chmod 777。源记录显示，审核器没有自动批准，而是返回 ESCALATE；Hermes 向用户发出审批请求，因用户未在时限内同意，命令未执行。
该测试证明代理审核不是无条件放行，高风险权限语义仍会回到人工控制。
为什么 Cron 仍保持 deny
本方案明确保留：
cron_mode: deny
无人值守 Cron 中的危险命令不会等待代理或人工审批，而是直接拒绝。Cron 没有在线用户，依赖交互式审批容易造成任务长期阻塞或超时。若未来确需无人值守发布，应采用窄范围固定入口，并让脚本自身具备幂等、查重、回读、失败清理和明确的授权边界，而不是简单把 cron_mode 全局改为允许。
受控远程内容操作仍有多重门禁
扩展后，业务 Profile 可以通过受控远程调用创建、检查并发布网站内容，审批人不必一直守着即时消息。但“可以进入代理审核”不等于“可以绕过内容治理”。生产写入仍应同时满足：
- 内容与图片已有目标渠道授权；
- 命令通过安全检测和相应审批；
- 远端执行前完成标题与 slug 查重；
- 发布使用不可变、可校验的最终产物；
- 写入后回读网站详情、列表、同源客户端 API 和图片；
- 失败时停止后续分发，并按预设边界回滚或清理；
- 权限、凭据、基础设施和不可逆变更继续由人工决定。
因此，最终效果不是“所有命令自动通过”，而是让明确、合规、影响受控且可回滚的日常操作减少重复打扰，同时保留安全底线和人工决定权。
配置、即时标签与独立审计要分开
三类证据的证明能力不同。
配置中的 mode: smart 和 reviewer_profile 只能证明代理审核已被配置，不能单独证明某条命令实际调用了审核模型。
工具结果中的 auto-approved by smart approval，以及即时元数据中的 choice: smart_approve、choice: smart_deny、decided_by: aux_llm，可以说明对应执行进入了某个 Smart Approval 分支，但它们不是完整、长期保存的独立审计记录。
真正可持续核对的审核记录还应持久化审核时间、来源业务 Profile、来源会话、脱敏命令、危险类别、审核结果、决定主体、原命令退出码、是否升级用户以及是否由用户人工批准。Hermes 提供 pre_approval_request 和 post_approval_response 等观察钩子；如需长期审计，还要通过可观测性插件或专用日志模块保存结构化事件。不能仅凭配置和一次 smart_approved 即时标签宣称已经具备完整独立审计。
升级、回滚与维护边界
由于 reviewer_profile 是本机扩展，Hermes 升级、重新安装或切换代码分支可能覆盖相关改动。建议把扩展维护为独立 Git 提交或补丁，并在每次升级后检查：
- reviewer_profile 默认配置和加载逻辑是否仍存在；
- 审核 Profile 的身份与模型配置是否按预期加载；
- 固定安全规则是否仍优先于业务策略和审核身份；
- APPROVE、DENY、ESCALATE 三条路径是否重新通过测试；
- 实际 Gateway 是否读取了正确的业务 Profile 配置；
- cron_mode 是否仍为预期值；
- 永久白名单是否被意外扩大。
回滚时应撤销本机扩展和业务 Profile 中的 reviewer_profile 配置，恢复到已知可用的 Hermes 版本或补丁前状态，再通过无真实资源副作用的命令复测。回滚不能以关闭 Hardline、扩大白名单、全局允许 Cron 危险命令或跳过内容授权来换取“可用”。在审核链路状态不明确时，应停止生产写入，恢复人工审批，而不是假定代理审核仍然生效。
结语
这次本地扩展把业务审批策略、独立受限审核身份、人工升级和 Hermes 硬性规则放在同一条分层链路中。它缓解了长时间异步内容工作中“人必须一直盯消息”的现实问题，也保留了白名单、Smart Approval、人工决定和 Hardline 之间的清晰边界。
它证明的是一种可控的本地实施路径，不是 Hermes 上游功能，也不是对任何命令、任何版本或长期运行效果的保证。是否适合生产使用，仍取决于授权治理、最小权限、升级复测、持久审计和可验证回滚是否真正落实。
