ByteNoteByteNote
字

字节笔记本

2026年5月16日

Hermes Agent Teams Meeting Pipeline：Microsoft Teams 会议自动化

#AI 前沿
API中转
¥120

本文介绍如何使用 Hermes Agent 自动化 Microsoft Teams 会议流程，包括会议调度、纪要生成和后续任务管理。在完成 Teams Meetings 功能启用后，请参照本指南进行操作。

本页涵盖以下内容：

  • 运维人员 CLI 操作流程
  • 日常订阅维护
  • 故障排查
  • 上线检查清单
  • 部署工作表

核心运维命令

验证配置快照

bash
hermes teams-pipeline validate

在任何配置变更后，优先执行此命令。

检查 Token 健康状态

bash
hermes teams-pipeline token-health
hermes teams-pipeline token-health --force-refresh

当你怀疑认证状态过期时，使用 --force-refresh 参数。

检查订阅状态

bash
hermes teams-pipeline subscriptions

续订即将过期的订阅

bash
hermes teams-pipeline maintain-subscriptions
hermes teams-pipeline maintain-subscriptions --dry-run

自动化订阅续订（生产环境必须配置）

Microsoft Graph 订阅最长有效期为 72 小时。 如果没有任何机制续订它们，会议通知将在 3 天后静默停止，流水线看起来就像"坏了"。这是所有基于 Graph 集成的头号运维故障模式。

你必须在定时任务中运行 maintain-subscriptions。从以下三种方案中选择一种：

方案一：Hermes cron（推荐：已运行 Hermes gateway 的场景）

Hermes 内置了 cron 调度器。--no-agent 模式以脚本方式运行任务（而非使用 LLM），--script 必须指向 ~/.hermes/scripts/ 目录下的文件。首先创建脚本：

bash
mkdir -p ~/.hermes/scripts
cat > ~/.hermes/scripts/maintain-teams-subscriptions.sh <<'EOF'
#!/usr/bin/env bash
exec hermes teams-pipeline maintain-subscriptions
EOF
chmod +x ~/.hermes/scripts/maintain-teams-subscriptions.sh

然后注册一个每 12 小时运行一次的脚本 cron 任务（为 72 小时过期窗口提供 6 倍余量）：

bash
hermes cron create "0 */12 * * *" \
  --name "teams-pipeline-maintain-subscriptions" \
  --no-agent \
  --script maintain-teams-subscriptions.sh \
  --deliver local

验证注册成功并查看下次运行时间：

bash
hermes cron list
hermes cron status        # 调度器状态

方案二：systemd timer（推荐：Linux 生产环境部署）

创建 /etc/systemd/system/hermes-teams-pipeline-maintain.service：

ini
[Unit]
Description=Hermes Teams pipeline subscription maintenance
After=network-online.target

[Service]
Type=oneshot
User=hermes
EnvironmentFile=/etc/hermes/env
ExecStart=/usr/local/bin/hermes teams-pipeline maintain-subscriptions

创建 /etc/systemd/system/hermes-teams-pipeline-maintain.timer：

ini
[Unit]
Description=Run Hermes Teams pipeline subscription maintenance every 12 hours

[Timer]
OnBootSec=5min
OnUnitActiveSec=12h
Persistent=true

[Install]
WantedBy=timers.target

启用定时器：

bash
sudo systemctl daemon-reload
sudo systemctl enable --now hermes-teams-pipeline-maintain.timer
systemctl list-timers hermes-teams-pipeline-maintain.timer

方案三：原生 crontab

cron
0 */12 * * * /usr/local/bin/hermes teams-pipeline maintain-subscriptions >> /var/log/hermes/teams-pipeline-maintain.log 2>&1

确保 cron 环境中包含 MSGRAPH_* 凭证。最简单的做法：在 crontab 调用的包装脚本顶部 source ~/.hermes/.env。

验证续订是否正常工作

设置定时任务后，在首次定时运行后检查续订情况：

bash
hermes teams-pipeline subscriptions   # expirationDateTime 应已更新
hermes teams-pipeline maintain-subscriptions --dry-run   # 大多数时候应显示 "0 expiring soon"

如果你发现 Graph webhook 恰好在约 72 小时后神秘地"停止工作"，首先要检查的就是：续订任务是否真正执行了？

查看最近的任务

bash
hermes teams-pipeline list
hermes teams-pipeline list --status failed
hermes teams-pipeline show <job-id>

重放已存储的任务

bash
hermes teams-pipeline run <job-id>

试运行会议资源获取

bash
hermes teams-pipeline fetch --meeting-id <meeting-id>
hermes teams-pipeline fetch --join-web-url "<join-url>"

日常运维手册

首次设置后

按顺序执行：

bash
hermes teams-pipeline validate
hermes teams-pipeline token-health --force-refresh
hermes teams-pipeline subscriptions

然后触发或等待一次真实的会议事件，确认：

bash
hermes teams-pipeline list
hermes teams-pipeline show <job-id>

日常或周期性检查

  • 运行 hermes teams-pipeline maintain-subscriptions --dry-run
  • 检查 hermes teams-pipeline list --status failed
  • 验证 Teams 投递目标是否仍为正确的聊天或频道

更改 Webhook URL 或投递目标前

  • 更新公共通知 URL 或 Teams 目标配置
  • 运行 hermes teams-pipeline validate
  • 续订或重建受影响的订阅
  • 确认新事件能到达预期的接收端

故障排查

没有任务被创建

检查：

  • msgraph_webhook 是否已启用
  • 公共通知 URL 是否指向 /msgraph/webhook
  • 订阅中的 client state 是否与 MSGRAPH_WEBHOOK_CLIENT_STATE 匹配
  • 远程订阅是否仍然存在且未过期

任务持续重试或在摘要生成前失败

检查：

  • 转录文本权限和可用性
  • 录制权限和资源可用性
  • 如果启用了录制回退，检查 ffmpeg 是否可用
  • Graph token 健康状态

摘要已生成但未投递到 Teams

检查：

  • platforms.teams.enabled: true
  • delivery_mode 配置
  • webhook 模式下的 incoming_webhook_url
  • Graph 模式下的 chat_id 或 team_id 加 channel_id
  • 使用 Graph 发帖时的 Teams 认证配置

重复或意外的重放

检查：

  • 是否手动执行了 hermes teams-pipeline run 重放了任务
  • 该会议的接收记录是否已存在
  • 是否在本地配置中故意启用了重发路径

上线检查清单

  • Graph 凭证已正确配置
  • msgraph_webhook 已启用且可从公网访问
  • MSGRAPH_WEBHOOK_CLIENT_STATE 已设置且与订阅匹配
  • 转录文本订阅已创建
  • 如需 STT 回退，录制订阅已创建
  • 如启用录制回退，ffmpeg 已安装
  • Teams 出站投递目标已配置并验证
  • Notion 和 Linear 接收端仅在确实需要时配置
  • hermes teams-pipeline validate 返回正常快照
  • hermes teams-pipeline token-health --force-refresh 成功
  • maintain-subscriptions 已设置定时任务（Hermes cron、systemd timer 或 crontab — 参见自动化订阅续订）。未设置此项，Graph 订阅将在 72 小时内静默过期。
  • 一次真实的端到端会议事件已生成存储的任务
  • 至少一份摘要已到达预期的投递目标

投递模式决策指南

模式适用场景权衡
incoming_webhook只需简单向 Teams 发送消息配置最简单，控制力较弱
graph需要通过 Graph 向频道或聊天发送消息控制力更强，需要更多认证和目标配置

运维工作表

在部署前填写：

项目值
公共通知 URL
Graph tenant ID
Graph client ID
Webhook client state
转录文本资源订阅
录制资源订阅
Teams 投递模式
Teams chat ID 或 team/channel
Notion database ID
Linear team ID
Store path 覆盖（如有）
日常检查负责人

变更审查工作表

在更改部署前使用：

问题回答
是否要更改公共 webhook URL？
是否要轮换 Graph 凭证？
是否要更改 Teams 投递模式？
是否要迁移到新的 Teams 聊天或频道？
订阅是否需要重建或续订？
是否需要一次全新的端到端验证运行？

相关文档

AI 前沿
上一篇

Hermes Agent Microsoft Graph 注册：Azure AD 应用配置指南

下一篇

Hermes Agent Teams Meeting Pipeline：Microsoft Teams 会议自动化

分享: