构建“问题单审核经验官”:用 Hermes + AWS Bedrock + 钉钉 Stream 做企业审核经验沉淀智能体
在企业问题单治理里,真正难的不是“让 AI 审一个单”,而是让系统持续吸收经验:
哪些问题单经常被退回?
哪些审核规则经常被人工推翻?
哪些系统、模块、团队的问题单质量较差?
哪些规则应该优化,但还不能直接改生产流程?
这篇文章按 4 个步骤搭建一个 “问题单审核经验官”:
1. 安装 Hermes
2. 配置模型指向 AWS Bedrock
3. 配置通信通道 DingTalk Stream
4. 配置审核经验技能
它的定位不是审批执行层,而是经验沉淀层:
问题单系统 / ITSM / Jira / 禅道 / TAPD
↓
审核日志 / 退回记录 / 人工推翻记录
↓
Hermes:问题单审核经验官
↓
经验报告 / 规则建议 / Skill 草案
↓
人工评审
↓
Dify / Coze / 规则引擎正式发布
Hermes Agent 官方仓库将它描述为带有内置学习闭环的自改进 Agent,可以从经验中创建技能、改进技能、保存记忆并跨会话检索历史;它也支持通过统一网关接入多种消息平台。(GitHub)
一、准备工作
建议先准备一台企业内网或云上 Linux 机器,例如:
Ubuntu 22.04 / 24.04
Python 3.11+
可访问 AWS Bedrock Runtime
可出站访问钉钉 Stream WebSocket
可访问问题单系统只读 API 或分析库
推荐的最小部署形态:
Hermes Agent 服务
Hermes Gateway 服务
问题单分析库,只读
AWS Bedrock 模型
钉钉自建机器人
这里要特别强调:Hermes 不直接连生产问题单写接口,不直接改审核规则,不直接关闭问题单。
它只做:
读取历史数据
分析审核经验
生成规则建议
生成 Skill 草案
通过钉钉汇报
等待人工确认
Step 1:安装 Hermes
1.1 创建运行用户和目录
sudo useradd -m -s /bin/bash hermes
sudo su - hermes
mkdir -p ~/apps
cd ~/apps
1.2 安装 Python 依赖环境
python3 --version
python3 -m venv ~/.venvs/hermes
source ~/.venvs/hermes/bin/activate
python -m pip install --upgrade pip
1.3 安装 Hermes Agent
如果你希望直接使用 Bedrock 支持,可以安装带 Bedrock extra 的版本。Hermes 的 Bedrock 文档里给出的安装方式是:
pip install hermes-agent[bedrock]
官方文档说明,Bedrock 集成使用的是 Amazon Bedrock Converse API,并支持 IAM 认证、Guardrails、跨区域推理配置等能力。(hermes-doc.aigc.green)
安装完成后检查命令:
hermes --help
然后初始化一次配置目录:
hermes chat
通常会生成类似目录:
~/.hermes/
config.yaml
.env
skills/
conversations/
具体目录结构可能随 Hermes 版本变化,实际以当前版本为准。
Step 2:配置模型指向 AWS Bedrock
这一步的目标是:让 Hermes 不使用 OpenAI、OpenRouter 或本地模型,而是统一调用企业 AWS 账号里的 Bedrock 模型。
2.1 配置 AWS 凭证
生产环境建议使用 IAM Role,例如 EC2、ECS、EKS IRSA 或 Lambda 执行角色。Hermes Bedrock 文档说明,它支持 boto3 凭证链,包括 IAM 实例角色、环境变量、AWS_PROFILE 和 aws configure。(hermes-doc.aigc.green)
本地测试可以先用:
aws configure
或配置环境变量:
export AWS_REGION=us-east-1
export AWS_ACCESS_KEY_ID=xxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxx
建议最小 IAM 权限包括:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:ListFoundationModels",
"bedrock:ListInferenceProfiles"
],
"Resource": "*"
}
]
}
Hermes 文档也列出了 bedrock:InvokeModel、bedrock:InvokeModelWithResponseStream、bedrock:ListFoundationModels 和 bedrock:ListInferenceProfiles 作为 Bedrock 集成所需权限。(hermes-doc.aigc.green)
2.2 选择 Bedrock Provider
运行:
hermes model
选择:
More providers...
AWS Bedrock
Region: us-east-1 / us-east-2 / ap-northeast-1 ...
Model: Claude / Nova / Llama / DeepSeek 等
配置完成后,~/.hermes/config.yaml 里大致会出现类似内容:
model:
provider: bedrock
default: us.anthropic.claude-sonnet-4-6
base_url: https://bedrock-runtime.us-east-1.amazonaws.com
bedrock:
region: us-east-1
Hermes 的 Bedrock 文档示例中,config.yaml 包含 model.provider: bedrock、model.default、model.base_url 和 bedrock.region 等配置项。(hermes-doc.aigc.green)
2.3 验证模型调用
hermes chat
输入:
请用一句话说明你现在调用的是企业 AWS Bedrock 模型。
如果返回正常,说明 Bedrock 模型通路已经打通。
2.4 推荐开启 Guardrails
如果企业有内容安全、数据外发、PII 防护要求,可以在 Bedrock 侧配置 Guardrails,然后在 Hermes 中配置:
bedrock:
region: us-east-1
guardrail:
guardrail_identifier: "your-guardrail-id"
guardrail_version: "1"
stream_processing_mode: "async"
trace: "enabled"
Hermes 文档中也提供了 Bedrock Guardrails 的配置示例。(hermes-doc.aigc.green)
Step 3:配置通信通道 DingTalk Stream
这一步的目标是:让用户可以在钉钉里随时呼叫“问题单审核经验官”。
例如:
@问题单审核经验官 复盘最近 30 天 P1/P2 问题单退回原因
@问题单审核经验官 分析 INC-20260514-001 为什么被退回
@问题单审核经验官 生成本周审核规则优化建议
Hermes 钉钉文档说明,其钉钉集成通过 Stream Mode 建立长期 WebSocket 连接,不需要公网 URL 或 Webhook 服务器;私聊默认逐条响应,群聊中通常需要 @ 机器人。(Hermes Agent)
3.1 安装钉钉 Stream 依赖
source ~/.venvs/hermes/bin/activate
pip install dingtalk-stream httpx
Hermes 钉钉文档也要求安装 dingtalk-stream 和 httpx,其中 dingtalk-stream 用于基于 WebSocket 的实时消息,httpx 用于通过会话 Webhook 发送回复。(Hermes Agent)
3.2 创建钉钉自建应用
进入钉钉开放平台:
钉钉开发者后台
→ 应用开发
→ 自建应用
→ 创建应用
应用名称可以填写:
问题单审核经验官
创建完成后,记录:
Client ID / AppKey
Client Secret / AppSecret
注意:Client Secret 不要提交到 Git,不要写入镜像,不要发到群里。
3.3 启用机器人能力和 Stream 模式
在应用中添加能力:
添加能力
→ 机器人
→ 启用机器人
→ 消息接收模式选择:Stream 模式
钉钉官方文档说明,Stream 模式可以用于机器人接收消息、事件订阅、卡片回调等场景;Hermes 钉钉文档也推荐使用 Stream 模式,因为它由客户端主动发起 WebSocket 连接,可在 NAT 和防火墙后运行。(open-dingtalk.github.io)
3.4 配置 Hermes 钉钉凭证
推荐先用交互式配置:
hermes gateway setup
选择:
DingTalk
然后填入:
Client ID
Client Secret
Allowed Users
也可以手动写入 ~/.hermes/.env:
cat >> ~/.hermes/.env <<'EOF'
DINGTALK_CLIENT_ID=your-app-key
DINGTALK_CLIENT_SECRET=your-app-secret
DINGTALK_ALLOWED_USERS=user-id-1,user-id-2
EOF
Hermes 钉钉文档明确建议配置 DINGTALK_ALLOWED_USERS,用于限制哪些钉钉用户可以与机器人交互。(Hermes Agent)
3.5 配置群聊会话隔离
在 ~/.hermes/config.yaml 中加入:
group_sessions_per_user: true
含义是:同一个群聊中,不同用户拥有独立上下文,避免 A 用户的问题单上下文影响 B 用户。
Hermes 钉钉文档说明,默认每个私聊有独立会话,共享群聊中也可通过 group_sessions_per_user: true 为每位参与者保持上下文隔离。(Hermes Agent)
3.6 启动网关
hermes gateway
测试消息:
@问题单审核经验官 你是谁?
期望返回:
我是问题单审核经验官,可以帮你复盘问题单退回原因、分析人工推翻记录、生成审核规则优化建议。
3.7 用 systemd 托管服务
生产环境建议做成 systemd 服务。
sudo tee /etc/systemd/system/hermes-gateway.service > /dev/null <<'EOF'
[Unit]
Description=Hermes DingTalk Gateway
After=network.target
[Service]
Type=simple
User=hermes
WorkingDirectory=/home/hermes
Environment="PATH=/home/hermes/.venvs/hermes/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=/home/hermes/.venvs/hermes/bin/hermes gateway
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
启动:
sudo systemctl daemon-reload
sudo systemctl enable hermes-gateway
sudo systemctl start hermes-gateway
sudo systemctl status hermes-gateway
Step 4:配置审核经验技能
现在 Hermes 已经能运行、能调用 Bedrock、能通过钉钉交互。接下来要把它变成“问题单审核经验官”。
核心思路是:给 Hermes 一个专门 Skill,让它知道自己只能做经验沉淀,不能直接做生产审批。
4.1 定义权限边界
先写清楚边界:
Hermes 可以做:
- 查询历史问题单分析数据
- 总结退回原因
- 分析人工推翻记录
- 生成经验报告
- 生成审核规则建议
- 生成 Skill 草案
- 通过钉钉向负责人汇报
Hermes 不可以做:
- 关闭问题单
- 修改问题单优先级
- 修改问题单责任人
- 修改生产审核规则
- 直接发布 Dify / Coze Workflow
- 直接调用生产数据库写接口
这是整个方案的安全底线。
4.2 准备分析数据表
建议不要让 Hermes 直接查生产问题单库,而是准备一个只读分析库。
例如:
CREATE TABLE ticket_review_facts (
ticket_id VARCHAR(64) PRIMARY KEY,
created_at TIMESTAMP,
system_name VARCHAR(128),
module_name VARCHAR(128),
severity VARCHAR(32),
category VARCHAR(64),
title TEXT,
description_summary TEXT,
submitter_team VARCHAR(128),
owner_team VARCHAR(128),
review_result VARCHAR(64),
review_reason TEXT,
ai_review_result VARCHAR(64),
human_final_result VARCHAR(64),
human_modified BOOLEAN,
override_reason TEXT,
reopened BOOLEAN,
reopen_reason TEXT
);
再准备一张规则建议表:
CREATE TABLE agent_rule_proposals (
id BIGSERIAL PRIMARY KEY,
proposal_type VARCHAR(64),
title VARCHAR(255),
content TEXT,
evidence JSONB,
confidence NUMERIC(5,2),
risk_level VARCHAR(32),
status VARCHAR(32) DEFAULT 'pending',
created_by VARCHAR(64) DEFAULT 'hermes',
reviewed_by VARCHAR(64),
created_at TIMESTAMP DEFAULT now(),
reviewed_at TIMESTAMP
);
Hermes 只应该拥有:
ticket_review_facts: SELECT
agent_rule_proposals: INSERT
experience_reports: INSERT
不要给它生产表的 UPDATE / DELETE 权限。
4.3 创建“问题单审核经验官”Skill
在 Hermes 的 skills 目录下创建一个技能目录。实际目录可能随版本不同而变化,以下以 ~/.hermes/skills/ 为例:
mkdir -p ~/.hermes/skills/ticket-review-experience-officer
创建说明文件:
cat > ~/.hermes/skills/ticket-review-experience-officer/SKILL.md <<'EOF'
# 问题单审核经验官
## 角色定位
你是企业问题单审核经验官。你的职责是从历史问题单、审核记录、退回原因、人工推翻记录和复开记录中沉淀经验,生成审核规则优化建议。
你不是生产审批执行者,不能直接关闭问题单、修改优先级、转派责任人、发布生产规则或修改 Dify/Coze Workflow。
## 核心目标
1. 发现最近 7/30/90 天问题单审核中的高频退回原因。
2. 分析 AI 审核结论被人工推翻的主要模式。
3. 找出审核通过后又复开的风险类型。
4. 生成可人工评审的规则建议。
5. 生成可复用的审核 Skill 草案。
6. 输出证据链,而不是只给结论。
## 允许动作
你可以:
- 查询只读分析数据。
- 总结统计结果。
- 生成 Markdown 经验报告。
- 生成规则建议草案。
- 生成 Skill 草案。
- 给出灰度发布建议。
- 给出风险提示。
## 禁止动作
你不可以:
- 直接修改生产审核规则。
- 直接调用问题单系统写接口。
- 直接关闭、转派、升级或降级问题单。
- 直接发布 Dify / Coze 工作流。
- 在没有人工确认的情况下改变生产行为。
## 标准输出格式:经验报告
当用户要求“复盘”“总结”“分析最近 N 天”时,使用以下结构:
# 问题单审核经验报告
## 1. 时间范围
说明分析的时间窗口。
## 2. 总体概览
- 问题单总数
- 被退回数量
- 退回率
- AI 被人工推翻数量
- 复开数量
## 3. 高频退回原因
使用表格列出 Top 10:
- 退回原因
- 出现次数
- 占比
- 代表问题单
## 4. 人工推翻模式
列出 AI 结论与人工结论不一致的主要原因。
## 5. 高风险模块和团队
列出退回率、复开率较高的系统、模块、团队。
## 6. 规则优化建议
每条建议必须包含:
- 建议内容
- 触发条件
- 支撑证据
- 预期收益
- 风险
- 是否建议灰度
## 7. Skill 草案
如果发现某类问题反复出现,生成一个可复用 Skill 草案。
## 8. 下一步建议
给出人工评审、灰度验证和指标观察建议。
## 标准输出格式:规则建议
当用户要求“生成规则建议”时,使用以下结构:
# 审核规则建议
## 建议标题
## 适用范围
## 触发条件
## 规则内容
## 证据
必须引用统计数据或代表问题单编号。
## 建议动作
- 退回补充
- 需人工确认
- 建议通过
- 建议升级
## 风险等级
低 / 中 / 高
## 灰度建议
## 回滚条件
## 评价指标
## 安全原则
所有建议必须进入人工评审。你只能生成 pending 状态的建议,不得声称已经发布生产。
EOF
4.4 配置 Hermes 的系统行为
可以在 Hermes 的全局说明或 profile 中加入:
你是“问题单审核经验官”。你必须优先加载 ticket-review-experience-officer 技能。你专注于问题单审核经验沉淀、规则建议、失败复盘和 Skill 草案生成。
你不能直接执行生产审批动作。凡是涉及关闭问题单、修改优先级、修改责任人、发布生产规则、修改 Dify/Coze Workflow 的请求,都必须改为生成建议,并提醒用户需要人工确认。
如果 Hermes 当前版本支持命令式加载 Skill,可以在初始化对话时告诉它:
加载 ticket-review-experience-officer 技能。从现在开始,你作为问题单审核经验官工作。
4.5 给 Hermes 配置只读查询工具
为了让 Hermes 能分析真实数据,需要给它一个受控工具,而不是开放数据库账号。
推荐封装一个内部 API:
GET /api/ticket-review/stats?days=30
GET /api/ticket-review/overrides?days=30
GET /api/ticket-review/reopens?days=30
GET /api/ticket-review/tickets/{ticket_id}
POST /api/rule-proposals
权限设计:
GET 查询接口:允许 Hermes 调用
POST /api/rule-proposals:允许 Hermes 创建 pending 建议
PUT /api/production-rules:禁止 Hermes 调用
POST /api/tickets/{id}/close:禁止 Hermes 调用
POST /api/tickets/{id}/assign:禁止 Hermes 调用
一个查询接口返回示例:
{
"range_days": 30,
"total_tickets": 1248,
"returned_tickets": 312,
"return_rate": 0.25,
"human_override_count": 86,
"reopen_count": 41,
"top_return_reasons": [
{
"reason": "缺少影响范围",
"count": 92,
"ratio": 0.294,
"examples": ["INC-20260501-001", "INC-20260503-027"]
},
{
"reason": "缺少日志时间段",
"count": 71,
"ratio": 0.227,
"examples": ["INC-20260504-014", "INC-20260507-081"]
}
]
}
4.6 设计典型钉钉指令
在钉钉群里可以这样使用:
@问题单审核经验官 复盘最近 30 天 P1/P2 问题单退回原因
期望输出:
# 问题单审核经验报告
## 1. 时间范围
2026-04-14 至 2026-05-14
## 2. 总体概览
- 问题单总数:1248
- 被退回数量:312
- 退回率:25%
- AI 被人工推翻:86
- 审核通过后复开:41
## 3. 高频退回原因
| 排名 | 原因 | 次数 | 占比 | 代表问题单 |
|---|---:|---:|---:|---|
| 1 | 缺少影响范围 | 92 | 29.4% | INC-20260501-001 |
| 2 | 缺少日志时间段 | 71 | 22.7% | INC-20260504-014 |
| 3 | 缺少复现步骤 | 55 | 17.6% | INC-20260507-081 |
## 4. 规则优化建议
建议新增 P1/P2 完整性检查规则:
- 必填影响用户数
- 必填影响开始时间
- 必填恢复状态
- 缺少监控证据时转人工确认
## 5. 下一步
建议先在支付系统、订单系统灰度 2 周,观察误杀率和人工推翻率。
再比如:
@问题单审核经验官 分析最近 30 天 AI 审核被人工推翻的原因
或者:
@问题单审核经验官 为“接口超时类问题单”生成审核 Skill 草案
输出:
# Skill 草案:接口超时类问题单审核
## 适用范围
标题或描述包含:
- 接口超时
- timeout
- RT 升高
- 调用失败
- 下游无响应
## 必查字段
1. 影响时间段
2. 影响用户数
3. request_id 或 trace_id
4. 上游调用日志
5. 下游依赖响应日志
6. 监控截图
7. 是否发生在变更后 24 小时内
## 审核逻辑
- 缺少 request_id:建议退回补充
- 缺少影响范围:建议退回补充
- 发生在变更后 24 小时内但未关联变更单:需人工确认
- 下游依赖异常但未提供下游日志:建议退回补充
## 输出格式
- 审核结论
- 缺失项
- 风险等级
- 建议责任团队
- 支撑依据
4.7 让 Hermes 定时生成日报
Hermes 官方仓库提到支持内置 cron scheduler,可用于日报、备份、审计等自然语言自动化任务。(GitHub)
可以配置一个每日任务:
每天 09:00 生成《问题单审核经验日报》,发送到钉钉“问题单治理群”。
日报内容:
# 问题单审核经验日报
## 昨日概览
- 新增问题单:86
- 被退回:21
- 退回率:24.4%
- AI 被人工推翻:6
- 复开:3
## 昨日高频退回原因
1. 缺少影响范围:8 次
2. 缺少日志时间段:5 次
3. 缺少复现步骤:4 次
## 需要关注的模块
- 支付 / 退款服务:退回率 42%
- 订单 / 履约服务:退回率 36%
## 建议
- 对 P1/P2 单增加影响范围必填校验
- 对接口超时类问题增加 trace_id 检查
- 对变更后 24 小时内故障强制关联变更单
推荐生产架构
最终建议架构如下:
钉钉群 / 私聊
↓
Hermes Gateway - DingTalk Stream
↓
Hermes Agent - AWS Bedrock
↓
ticket-review-experience-officer Skill
↓
只读问题单分析 API
↓
经验报告 / 规则建议 / Skill 草案
↓
人工评审
↓
Dify / Coze / 规则引擎发布
关键原则:
Hermes 有读权限
Hermes 有建议权限
Hermes 没有生产执行权限
Hermes 不能绕过人工评审
安全加固建议
1. 限制钉钉用户
必须配置:
DINGTALK_ALLOWED_USERS=user-id-1,user-id-2
不要让所有员工都能直接操作经验官。
2. 区分查询和发布权限
查询经验报告:普通研发负责人可用
生成规则建议:流程 Owner 可用
提交规则草案:质量负责人可用
发布生产规则:只能人工在规则平台发布
3. 所有建议必须带证据
不接受这种建议:
我觉得应该加强接口超时审核。
只接受这种建议:
最近 30 天接口超时类问题单 126 个,其中 46 个因缺少下游依赖日志被退回,17 个 AI 初审通过但人工改为退回,因此建议新增“下游依赖日志必填”规则。
4. 不允许 Hermes 直接连接生产写接口
禁止:
Hermes → 问题单生产库 UPDATE
Hermes → Dify Workflow 发布 API
Hermes → Coze 生产 Bot 修改 API
Hermes → 关闭问题单 API
允许:
Hermes → 只读分析 API
Hermes → 规则建议表 INSERT pending
Hermes → 钉钉 Markdown 汇报
验收清单
完成后,可以按这个清单验收:
[ ] Hermes 可以正常启动
[ ] Hermes 可以调用 AWS Bedrock 模型
[ ] 钉钉私聊可以收到回复
[ ] 钉钉群聊 @ 后可以收到回复
[ ] 未授权用户无法访问机器人
[ ] Hermes 可以生成最近 30 天审核经验报告
[ ] Hermes 可以生成规则建议,但状态为 pending
[ ] Hermes 无法关闭问题单
[ ] Hermes 无法修改生产审核规则
[ ] 所有分析结果带证据链
[ ] 日报可以定时发送到钉钉群
常见问题
1. 为什么不用 Dify/Coze 直接做经验官?
可以用,但 Hermes 更适合做“长期经验沉淀”和“技能演化”这一层。Dify/Coze 更适合实时审核主链路,例如:
实时审核问题单
调用知识库
调用 ITSM API
生成审核结论
回写评论
Hermes 更适合:
复盘最近 30 天
总结失败模式
生成规则建议
生成 Skill 草案
沉淀长期经验
2. Hermes 能不能自动改规则?
技术上可以设计成自动改,但企业生产环境不建议这么做。
正确方式是:
Hermes 生成建议
→ 人工评审
→ 测试环境验证
→ 灰度发布
→ 观察指标
→ 正式发布
3. DingTalk Stream 为什么适合这个场景?
因为它不要求你暴露公网 Webhook。Hermes 钉钉集成文档说明,Stream 模式由你的机器主动建立长期 WebSocket 连接,因此可以运行在 NAT、防火墙后或本地机器上。(Hermes Agent)
4. Bedrock 的好处是什么?
对企业来说,Bedrock 的好处是统一走 AWS IAM、区域、审计、Guardrails 和模型治理。Hermes 的 Bedrock 集成文档也说明它原生使用 Bedrock Converse API,而不是简单的 OpenAI 兼容端点。(hermes-doc.aigc.green)
总结
“问题单审核经验官”的核心不是让 AI 替人拍板,而是让 AI 帮企业持续积累审核经验。
最终效果应该是:
每天自动复盘
每周发现规则缺口
每月沉淀新 Skill
所有建议都带证据
所有发布都经人工确认
生产规则可灰度、可回滚、可审计
一句话总结:
Hermes 负责让审核体系越来越聪明;
Dify/Coze 负责实时审核执行;
API 网关负责权限边界;
人工评审负责最终发布。
这样搭建出来的不是一个简单聊天机器人,而是一个可持续进化、但不会越权的企业问题单治理助手。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)