之前一个朋友在做一个 AI 助手类项目时遇到一个很典型的问题助手能聊、能查资料、能写代码但没办法替他处理“每天会被问很多遍”的固定消息场景。比如陌陌上经常有人问“在吗”“做什么工作的”“能不能加微信”每次都是同样的话术手动回复又浪费时间于是他开始研究 Hermes Agent 的 Skills 机制想用一套“技能”把这类回复自动化。这篇文章就是把那套思路完整整理出来从 Hermes Agent 和 Skills 的概念讲起到写一个“陌陌回复信息技能”的完整流程再到常见报错排查和工程化建议。文章不会教你绕过任何平台限制而是把“技能开发”这件事本身讲透让你能迁移到微信、企业微信、短信、邮件等其它消息场景。适用读者正在用 Hermes Agent、Claude Code、Codex 等 Agent 工具做自动化的人或者准备系统学习 Agent Skills 开发的开发者。1. 为什么需要给 Hermes Agent 添加“陌陌回复”技能1.1 先搞清楚 Hermes Agent 是什么Hermes Agent 属于最近很热的一类“AI Agent”应用。你可以把它理解成一个跑在本地或服务器上的智能代理程序它不只是简单聊天而是能调用工具、读取文件、执行命令、完成多步任务。比较常见的形态是终端助手也就是你在命令行里输入自然语言请求它帮你拆解任务、调用各种能力、最终给出结果。这类工具让“写一套固定逻辑”变成了“用自然语言发指令就能安排任务”。不过在真实业务里光有“能理解指令”还不够。不同用户有不同场景有人要处理陌陌消息有人要自动回复微信有人要让 Agent 做周报。这些高度个性化的需求不可能全部内置在 Agent 里于是就需要一种“插件化”的能力也就是本文要讲的 Skills。1.2 Skills 机制解决了什么问题Skills 在汉化语境里常被称为“技能”可以理解为一组带描述、带参数、带执行逻辑的功能模块。给 Agent 安装一个 Skill 之后它就知道在什么场景下调用这个技能、需要哪些输入、产出的结果是什么。和普通脚本相比Skills 有几个明显区别第一Skills 带有机器可读的描述。Agent 会通过描述判断“这个技能适不适合当前任务”。第二Skills 有参数约束。你想让技能回复什么、发给谁、用什么话术都是通过参数传递而不是把逻辑写死。第三Skills 的加载和卸载是动态的不改 Agent 主程序就能扩展功能。所以与其说 Skills 是“写了一个脚本”不如说是在 Agent 上注册了一个“可被动态调用的能力”。1.3 陌陌消息自动化回复的业务场景以一个常见的个人使用场景为例你平时会收到很多陌陌好友发来的招呼、提问、或者重复性咨询。如果每条都手动回复一天会打断好几次工作节奏。给 Hermes Agent 做一个“陌陌回复信息技能”之后可以实现这些能力自动识别消息类型问候、提问、广告、骚扰。根据消息内容匹配预设话术例如“在吗”回复“在的有什么可以帮你”。对包含敏感词或骚扰意图的消息不回复或仅标记。把无法自动处理的消息统一收集延迟提醒人工处理。这里要特别说明个人消息自动回复和批量营销是完全不同的两件事。前者服务于“减少重复劳动”后者属于平台高压线。本文所有示例都基于个人账号的辅助管理场景绝对不涉及群发、骚扰、伪装等行为。1.4 一个容易被忽视的边界合规性在开始之前必须先强调合规问题。陌陌这类即时通讯软件在用户协议里通常明确禁止使用非官方接口进行消息自动化。因此接入前请务必确认你只对自己有权限管理的账号操作。自动化逻辑不会绕过平台安全机制。不影响正常用户不构成骚扰。本地测试时使用小号避免影响真实社交关系。接入通道必须遵守平台规则法律风险由使用者自行评估。即使是做技术研究也建议先在小范围、测试账号上验证不要把脚本直接跑在核心账号上。文章的核心是 Skill 开发工程方法不是教你如何“破解”某个 App。所以后面的代码示例会把“消息获取”和“消息发送”这两层做成可替换的适配器你只需要关注 Skill 本身的逻辑。2. 环境准备与运行框架2.1 运行环境说明Hermes Agent 目前在不同系统上的安装方式有差异本文不会替你把特定版本的安装命令写死因为社区版本更新比较快。更推荐的做法是先根据官方文档把 Agent 本体装好再做 Skills 开发。一个常见的最小环境是这样操作系统macOS 或 Linux 均可社区反馈 mac 上跑 Hermes Agent 的案例比较多。运行时Python 3.10 或更高版本Node.js 看项目需要。Agent 主体Hermes Agent以你从官方渠道获取的版本为准。代码编辑器VS Code 或任意支持 Python 的编辑器。如果你在安装 Agent 本体时遇到需要登录、需要配置 API Key 等情况属于正常现象。这类 Agent 通常需要调用大模型接口所以需要准备模型服务的 API Key配置方法在官方 README 里一般都写得很清楚。2.2 工具链准备除了 Agent 本体建议准备以下工具Git拉取 Skills 示例仓库或管理自己的技能代码。Python 虚拟环境避免依赖冲突。HTTP 调试工具如 curl、Postman如果 Skill 里要请求模型服务或外部 API。日志查看工具终端本身即可。本文示例代码以 Python 为主因为这个生态处理文本规则、消息队列、HTTP 请求都比较方便。2.3 项目目录设计一个规范的 Skills 项目建议这样组织目录hermes-skills/ ├── skills/ │ └── momo-reply/ │ ├── SKILL.md │ ├── skill.py │ ├── config.yaml │ └── rules/ │ └── reply_rules.json ├── logs/ └── tests/ └── test_reply_rules.py简单说明每个文件的作用SKILL.md技能描述文件给 Agent 看的“说明书”。skill.py技能核心逻辑。config.yaml配置参数包括回复开关、冷却时间、关键词文件路径等。reply_rules.json消息匹配规则和回复话术。tests/自动化测试用来保证改规则时不破坏原有功能。下面会按照这个目录结构逐步实现。3. Hermes Agent 与 Skills 机制拆解3.1 Skills 是什么和普通脚本有什么区别可以把 Skills 理解成给 Agent 准备的“能力卡片”。每张卡片包含两部分描述和实现。描述部分告诉 Agent“这个技能能做什么、什么时候用”实现部分告诉 Agent“具体怎么做”。举一个很简单的比喻普通脚本就像一台没有说明书的外设只有你自己知道怎么用Skill 则像一台带标准说明书的设备任何会读说明书的 Agent 都能接上。因此写 Skill 的第一个重点是写清楚描述而不是只写代码。3.2 Skill 文件的标准结构大多数 Agent 框架对 Skill 有一个约定使用一个SKILL.md文件来描述技能元信息再通过引用文件路径或函数名来加载实现。下面给出一个通用的SKILL.md示例它不是一个特定框架的严格模板但思路是通用的--- name: momo-reply description: 自动处理陌陌消息回复。当收到重复性提问、常见问候时根据规则匹配并返回回复内容。 version: 1.0.0 author: your-name license: MIT parameters: - name: message type: string required: true description: 收到的原始消息文本 - name: session_id type: string required: false description: 会话标识用于上下文去重和冷却判断 entrypoint: skill.py ---这段 YAML 格式的元信息里name技能名称Agent 用它来识别技能。description极其重要。Agent 判断是否调用这个技能主要靠这段描述。parameters声明调用技能时需要传入哪些参数有没有默认值。entrypoint指明实现入口文件。写描述时不要写“这是一个关于消息回复的技能”而要写清“在什么场景下、收到什么输入、输出什么结果”。例如description: 当用户收到陌陌好友发来的问候、常见提问或重复咨询时根据预设话术生成自动回复内容。这样的描述Agent 在决策时更容易命中。3.3 Agent 如何调度一个 SkillAgent 调用 Skill 的过程大致可以拆成四步Agent 接收用户的一条指令。Agent 根据指令语义结合 Skill 的description决定要不要调用这个技能。如果决定调用Agent 会按照parameters的定义提取必要信息。Agent 执行entrypoint里的逻辑拿到返回结果再组织成自然语言回复给用户。也就是说写 Skill 时你不一定“亲自触发逻辑”而是要确保 Agent 能正确识别“什么时候该用它”。这也就是为什么描述写得越精确Skill 使用率越高。3.4 对外挂知识库和 API Key 的理解从最近社区讨论的热词来看很多人还在研究“外挂知识库”和“修改 API Key”。这两个其实都属于 Agent 的扩展能力外挂知识库把业务资料放在本地或向量数据库里Agent 在回答时先检索再组织答案。写 Skills 时如果你的回复规则比较复杂也可以把规则文件放在知识库目录中让 Skill 动态读取。API KeyAgent 调用大模型或第三方服务时需要的身份凭证。修改方式一般在配置文件中而不是在 Skill 里写死。在下面的实战案例里我们会把回复话术放在独立 JSON 文件中而不是硬编码在 Python 代码里这样后续调整话术不需要改代码对新手更友好也方便 Agent 在运行时读取外部配置。4. 完整实战开发一个陌陌自动回复 Skill4.1 需求拆分先别急着写代码。我们把需求拆成几个明确的功能点接收一条消息文本。判断消息类型问候、咨询、广告、骚扰、其他。根据类型匹配回复话术。对广告和骚扰消息不做回复只返回一个标记。记录处理日志方便事后查看。提供一个模拟入口可以在命令行里输入消息观察输出结果。整个 Skill 保持“规则驱动”不依赖大模型处理每一条消息这样速度快、成本低也更稳定。只有遇到无法匹配的消息时才可选的交给模型生成回复。4.2 自动回复策略设计在设计回复策略时要注意几点对“在吗”“你好”这类高频问候统一走“自然问候”规则。对“做什么的”“多大年龄”这类隐私问题策略上不直接回答话术可以设置为“关于我可以在合适的时候聊聊先说说你吧”。对广告、赌博、诈骗等敏感词直接走“不回复”分支并记录风险。对同一会话短时间内的重复消息要触发冷却机制避免被误判为机器循环响应。策略上要优先保证“不打扰”和“不违法”其次才是“回复得好”。4.3 编写 Skill 定义文件先创建项目目录mkdir -p hermes-skills/skills/momo-reply cd hermes-skills/skills/momo-reply然后创建SKILL.md--- name: momo-reply description: 用于处理陌陌消息的自动回复。当收到常见问候、重复提问、咨询类消息时按预设规则返回回复内容对广告、骚扰消息不回复。 version: 1.0.0 author: your-name parameters: - name: message type: string required: true description: 收到的原始消息文本 - name: session_id type: string required: false description: 会话标识用于冷却和去重判断 entrypoint: skill.py ---接下来创建config.yaml# 文件路径hermes-skills/skills/momo-reply/config.yaml reply_enabled: true # 总开关false 时技能不产生任何回复 cooling_seconds: 30 # 同一会话冷却时间 max_reply_length: 200 # 回复内容最大长度 risk_action: ignore # 风险消息动作ignore / log / review rules_file: ./rules/reply_rules.json这里的cooling_seconds很重要它可以防止同一个会话里短时间收到大量消息时技能每次都去回复造成过度响应。4.4 编写核心逻辑代码下面编写skill.py。这里先给一个不依赖任何特定 Agent SDK 的版本方便你理解核心流程。# 文件路径hermes-skills/skills/momo-reply/skill.py import json import time import re from pathlib import Path class MomoReplySkill: def __init__(self, config_path: str ./config.yaml, rules_path: str ./rules/reply_rules.json): self.config self._load_config(config_path) self.rules self._load_rules(rules_path) self._last_reply_time: dict[str, float] {} def _load_config(self, path: str): try: import yaml with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) except Exception: return {reply_enabled: True, cooling_seconds: 30} def _load_rules(self, path: str): with open(path, r, encodingutf-8) as f: return json.load(f) def _classify(self, message: str) - str: 根据规则文件将消息分类 for rule in self.rules[rules]: for keyword in rule[keywords]: if keyword in message: return rule[type] return other def _respect_cooling(self, session_id: str) - bool: 判断是否处于冷却期 now time.time() last self._last_reply_time.get(session_id, 0) if now - last self.config.get(cooling_seconds, 30): return False self._last_reply_time[session_id] now return True def handle(self, message: str, session_id: str default) - dict: if not self.config.get(reply_enabled, True): return {should_reply: False, reason: reply_disabled} if not self._respect_cooling(session_id): return {should_reply: False, reason: cooling} msg_type self._classify(message) if msg_type risk: return {should_reply: False, reason: risk_message} reply self._get_reply_by_type(msg_type) return { should_reply: True, message_type: msg_type, reply: reply, } def _get_reply_by_type(self, msg_type: str) - str: for rule in self.rules[rules]: if rule[type] msg_type: replies rule.get(replies, []) if replies: return replies[0] return 你好收到你的消息了。 if __name__ __main__: skill MomoReplySkill() while True: text input(请输入消息输入 q 退出) if text.lower() q: break result skill.handle(text, session_idtest) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码的职责很清晰_load_config读取 yaml 配置。_load_rules读取 JSON 规则。_classify根据关键词对消息分类。_respect_cooling实现冷却机制。handle是外部调用的入口Agent 会调用这个方法。4.5 消息发送适配层上面的skill.py只负责“生成回复内容”不负责“把消息真正发出去”。这么设计是有意的。因为陌陌没有开放公共的开发者 API不同接入方式差异很大而且存在合规风险。所以更稳妥的做法是把发送逻辑独立成适配层由你自己选择一个合法、可控的通道。下面是一个发送适配器的接口示例# 文件路径hermes-skills/skills/momo-reply/sender.py from abc import ABC, abstractmethod class MessageSender(ABC): 消息发送适配器接口。请根据你实际可用的通道实现。 abstractmethod def send(self, session_id: str, content: str) - bool: 发送消息到指定会话 abstractmethod def receive(self, session_id: str) - str: 从指定会话接收最新消息比如你有一个内部桥接服务可以通过 HTTP 接口接收和发送消息那么可以这样做# 文件路径hermes-skills/skills/momo-reply/sender.py import requests class HttpSender(MessageSender): def __init__(self, base_url: str, token: str): self.base_url base_url self.token token def send(self, session_id: str, content: str) - bool: resp requests.post( f{self.base_url}/send, json{session_id: session_id, content: content}, headers{Authorization: fBearer {self.token}}, timeout5, ) return resp.status_code 200 def receive(self, session_id: str) - str: resp requests.get( f{self.base_url}/receive, params{session_id: session_id}, headers{Authorization: fBearer {self.token}}, timeout5, ) return resp.json().get(message, )注意这里的HttpSender只是演示适配器模式不是让你去搭一个“绕过陌陌协议”的服务。实际项目中请使用“用户自己可控且合规”的消息通道。4.6 将 Skill 注册到 Hermes AgentSkill 开发完成后如何让 Hermes Agent 加载它不同版本的 Agent 加载方式不一样常见做法有两种把整个momo-reply目录放进 Agent 的skills目录Agent 启动时扫描目录并读取SKILL.md。在 Agent 配置文件中声明技能路径例如# 示例配置片段具体字段以你的 Agent 版本为准 skills: - path: ./skills/momo-reply enabled: true建议先把核心逻辑用一个main()入口封装好再根据实际 Agent 框架的扩展点接入。例如如果 Hermes Agent 允许自定义工具函数那么只需要在对应位置 importMomoReplySkill然后调用handle()方法即可。为了让 Agent 能在拿到回复后继续对话handle()返回结构化结果比返回纯文本更友好# 示例把结果转为 Agent 可读字符串 def format_result(result: dict) - str: if result[should_reply]: return f建议回复{result[reply]} return f不回复原因{result[reason]}5. 运行与验证5.1 本地启动先安装依赖cd hermes-skills python -m venv .venv source .venv/bin/activate pip install pyyaml requests然后运行模块python skills/momo-reply/skill.py运行时你会进入一个交互式命令行可以输入消息来观察分类和回复结果。5.2 功能验证流程设计一组测试输入覆盖每个分支输入消息期望类型是否回复在吗greeting是你好greeting是你是做什么工作的info_question是加个微信吧contact是免费领取红包risk否今晚有空一起吃饭吗other是用q退出测试。还可以把测试写进脚本方便回归# 文件路径hermes-skills/tests/test_reply_rules.py from skills.momo_reply.skill import MomoReplySkill def test_risk_message_not_reply(): skill MomoReplySkill() result skill.handle(免费领取红包, session_idtest1) assert result[should_reply] is False assert result[reason] risk_message def test_greeting_reply_exists(): skill MomoReplySkill() result skill.handle(在吗, session_idtest2) assert result[should_reply] is True assert len(result[reply]) 0 if __name__ __main__: test_risk_message_not_reply() test_greeting_reply_exists() print(所有测试通过)5.3 日志与告警自动回复最怕“机器失控”。所以 Skill 每次处理消息都应该记录结构化日志至少要包含时间戳会话 ID原始消息分类结果是否回复回复内容建议使用 Python 自带的logging模块输出到文件# 文件路径hermes-skills/skills/momo-reply/skill.py import logging logging.basicConfig( filenamelogs/momo_reply.log, levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s, ) # 在 handle() 中记录日志 def handle(self, message: str, session_id: str default) - dict: result self._process(message, session_id) logging.info( session%s message%s result%s, session_id, message, json.dumps(result, ensure_asciiFalse) ) return result如果长时间没有日志产生说明消息接收链路可能断了这种告警可以交给外部监控。6. 常见问题与排查思路无论是自己开发还是在社区里看别人的踩坑记录下面几个问题出现的频率最高。问题现象常见原因解决思路Agent 没有调用这个 SkillSKILL.md 里的 description 写得太模糊或者命名和触发词不匹配把描述改成“当用户收到陌陌消息、需要自动回复时”并在回复中示例触发场景回复时总是命中“other”分类关键词规则覆盖不全或用户消息变体太多扩充关键词和匹配规则尽量用子串匹配 归一化处理统一全半角、小写化出现连续自动回复造成骚扰缺少冷却机制或者冷却时间设置太短启用冷却逻辑同一会话 30 秒内只允许触发一次敏感词消息被回复了风险分类优先级不够规则文件里 risk 类型的顺序排在 greeting 之后调整规则顺序让风险关键词优先匹配必要时在分类逻辑中单独做一次危险判断本地能跑Agent 调用时找不到文件相对路径问题Agent 启动目录和 Skill 目录不一致使用Path(__file__).parent构造绝对路径或者把路径写到 Agent 的环境变量中安装 Agent 时一直卡在登录或 API Key 配置不同版本对模型服务商有不同要求检查官方文档确认需要配置的模型服务商、API Key 配置项不要使用来源不明的安装包修改了回复话术但没生效JSON 文件被缓存或者修改了非当前加载路径重启 Agent 或 Skill 进程确认rules_file指向的是修改后的文件7. 最佳实践与工程建议7.1 规则优先于全量 AI 接管在消息回复场景下规则匹配的优势是快、可控、零成本。AI 生成回复的优势是灵活但有延迟和不确定性。最佳实践是“规则优先AI 兜底”高频简单消息走规则匹配。只有规则没覆盖、且你判断需要回复的消息才交给大模型生成候选回复。模型生成的回复最好经过人工审核或者加上明显的“自动回复”标识。这样可以避免出现不可控的回复内容也方便事后追责和调整。7.2 频率控制与冷却机制这是最容易踩坑的地方。自动回复不是越快越好频率过高会导致被平台判定为营销机器人。在真实社交关系里显得很突兀。一旦循环触发可能在短时间内产生大量消息。因此冷却机制必须有而且建议设置为“同一会话 30 秒到 5 分钟不等”。如果消息量很大还可以引入全局限速比如“每分钟最多处理 10 条消息”。7.3 敏感信息与隐私安全消息自动回复会接触到大量的隐私内容。开发时要注意不要把原始消息日志长期明文保存。日志中不要打印完整的手机号、微信号等敏感信息。配置文件和 API Key 不要提交到 Git 仓库使用环境变量注入。如果消息内容包含收货地址、身份证号等信息应立即停止自动回复转入人工处理。实用做法是把日志写入带权限控制的目录并定期清理。7.4 消息幂等与去重接收消息时同一个会话可能因为网络重试导致同一条消息被处理两次。建议在 Skill 中维护一个message_id去重集合用消息的唯一 ID 做幂等判断# 伪代码示例消息去重 seen_ids set() def handle_message(message_id: str, message: str, session_id: str): if message_id in seen_ids: return {should_reply: False, reason: duplicate} seen_ids.add(message_id) # 继续处理不过要注意内存去重在进程重启后会丢失。如果对可靠性要求高可以把seen_ids持久化到 SQLite 或 Redis。7.5 便于维护的设计一句话总结把“决策逻辑”和“话术内容”分离。关键词、话术放 JSON 文件。流程控制放 Python 代码。发送通道走适配器接口。配置参数放 YAML。这样改话术不用改代码换发送通道不影响核心逻辑测试也更容易。8. 总结与学习路线这篇教程围绕“Hermes Agent Skills 开发”和“陌陌自动回复”两个主题完整拆解了一个 Skill 从设计、编码、运行到排错的全过程。核心掌握点可以总结为四个Skills 本质上是给 Agent 提供“带描述的能力模块”描述写得好Skill 才会被正确调用。自动回复逻辑推荐“规则优先、AI 兜底”不要一上来就让大模型接管所有消息。无论接哪个消息平台都必须做频率控制、冷却、去重、日志和风险过滤。发送通道要解耦成适配器既为了合规也为了以后能迁移到微信、企业微信、短信等其它场景。如果你之前完全没接触过 Agent 开发下一步可以继续研究如何用 Hermes Agent 连接不同的大模型 API。如何给 Agent 挂载本地知识库让回复更贴合业务。如何把 Skill 发布成可分享的模块让团队其他人也能直接安装使用。如果你的 Skills 已经能稳定处理消息建议接着做两件事一是给日志加一个简单的统计面板看看哪些话术命中率高、哪些场景被误判二是写一套更完整的离线测试用例防止改规则时把原有的行为改坏。工具会一直更新但“把能力抽象成技能、把流程拆成可替换模块”这套开发思路是通用的。先用小场景跑通一条链路再逐步放大比一开始就想做一个大而全的自动化系统要靠谱得多。如果你在配置中文路径、规则匹配或者 Agent 加载时遇到奇怪问题可以把具体报错和目录结构发出来一起讨论。