emotion-state

核心用法

Emotion State 是一个 OpenClaw 工作区 Hook，用于为 AI 对话系统注入情感感知能力。安装后，它会自动分析用户与代理的对话内容，提取自然语言形式的情感标签（如 "frustrated about slow response"、"excited about new feature"），并将这些状态以结构化格式注入系统提示词。该 Hook 采用半衰期衰减算法计算情感趋势，支持跨会话持久化存储，最多保留 100 条历史记录，默认展示最近 3 条用户情感和 2 条代理情感条目。

配置过程需将 Hook 文件复制到工作区 hooks// 目录，通过 openclaw hooks enable 启用，并在 ~/.openclaw/openclaw.json 中配置环境变量。核心配置包括：OpenAI API 密钥、情感分类模型（默认 gpt-4o-mini）、置信度阈值（0.35）、历史窗口大小及半衰期时间（12 小时）。支持自定义分类器 URL 以实现完全离线部署。

显著优点

架构设计优秀：纯 Node.js 内置模块实现，零第三方依赖，彻底规避 npm 供应链攻击风险。采用文件锁 + 原子写入机制保障并发安全，SHA-256 哈希去重避免冗余存储。

隐私保护到位：原始对话文本不落盘，仅存储模型推断的情感标签及原因摘要；数据严格隔离于 ~/.openclaw/agents/<agentId>/ 目录下，按 userKey 分片存储，支持多租户场景。

容错机制完善：分类服务故障时自动降级为 "neutral/low/unsure" 默认值，5 秒超时设置防止阻塞主流程，JSON 解析异常均有 try-catch 保护。

配置灵活性高：除 OpenAI 外，可对接任意兼容 OpenAI 接口格式的本地或私有分类器服务，满足合规敏感场景的完全离线需求。

潜在缺点与局限性

外部依赖刚性：必须配置有效 API Key 或自建分类器才能工作，开箱即用性受限；默认依赖 OpenAI 服务，存在网络延迟（典型 500-2000ms）和成本开销。

情感推断黑盒：基于 LLM 的情感分类缺乏可解释性，同一对话可能因模型版本、温度参数产生不一致结果；0.35 的默认置信度阈值可能过滤掉细微情感变化。

存储容量瓶颈：单代理默认最多 50 用户 × 100 条记录，高并发场景下需手动调优；本地 JSON 文件存储在超大规模部署时可能成为 I/O 瓶颈。

时区与同步问题：情感时间戳依赖配置的 EMOTION_TIMEZONE，分布式部署时若节点时区不一致会导致趋势计算偏差；无内置集群状态同步机制。

适合的目标群体

• 对话式 AI 产品经理：需要为客服机器人、虚拟伴侣等产品增加情感记忆能力
• 多轮对话系统开发者：构建需要长期用户关系维护的代理应用（如心理健康助手、教育辅导 AI）
• OpenClaw 框架用户：已采用该框架的开发者可零成本集成情感层
• 隐私合规要求中等的企业：接受本地存储 + 可选外部 API 调用模式，但需评估 OpenAI 数据处理协议

使用风险

性能风险：每次对话触发同步 HTTP 请求，高 QPS 场景需部署本地分类器或增加缓存层；情感趋势计算涉及历史数据遍历，历史记录膨胀时延迟线性增长。

成本风险：按 token 计费的分类调用在大流量场景下成本显著，建议设置 EMOTION_CONFIDENCE_MIN 过滤低价值请求，或采用批量异步处理架构。

模型漂移风险：OpenAI 模型更新可能导致情感标签格式变化，破坏下游解析逻辑；建议锁定模型版本或实施输出模式校验。

数据残留风险：卸载 Hook 后历史情感文件不会自动清理，需手动删除 ~/.openclaw/agents// 下相关目录以符合 GDPR 等删除权要求。

Emotion State (NL) Skill 综合评估

核心用法

Emotion State 是一个面向 OpenClaw 生态的 agent 钩子 (hook)，旨在为 AI agent 注入自然语言情绪感知能力。该技能通过分析用户和 agent 的对话内容，以简短的自然语言短语评估双方的情绪状态，并将这些情绪画像跨会话持久化存储在本地。其核心功能包括：触发时将最新的情绪评估注入系统提示词，以调整 agent 的交互语调；使用衰减算法对历史情绪进行趋势分析，使情绪状态呈现更连贯的印象。

显著优点

• 零外部依赖，架构简洁：Skill 仅使用 Node.js 内置模块，无任何第三方 npm 依赖，完全规避了供应链攻击和已知 CVE 漏洞风险，代码库非常干净。
• 安全性设计考究：采用文件锁机制防止并发写入冲突，分类失败时优雅回退至安全的默认值（neutral/low/unsure），并通过 SHA-256 内容哈希对消息进行去重，避免重复处理，体现了成熟的服务端开发素养。
• 功能声明透明：SKILL.md 清晰地说明了数据存储路径、不存储原始用户文本的隐私设计原则，以及完整的环境变量配置清单，便于用户理解和审计。

潜在缺点或局限性

• 隐私合规存在明显短板：Skill 会将对话内容发送至第三方 AI 服务（如 OpenAI）进行情绪分类，并在本地构建跨会话的情绪画像，但全程缺乏显式的用户同意机制，也无任何数据删除接口或配置项，对于受 GDPR 等隐私法规约束的场景而言风险较高。
• 端点配置带来重定向风险：OPENAI_BASE_URL 和 EMOTION_CLASSIFIER_URL 环境变量可被设置为任意 URL。若遭恶意配置，对话内容存在被静默引流至攻击者服务器的可能。
• 类型安全性较弱：代码中广泛使用 TypeScript any 类型来解析消息容器，这种宽松的输入校验虽增强了兼容性，但也降低了面对异常或恶意构造输入时的健壮性。

适合的目标群体

• OpenClaw 生态的深度用户和开发者：希望在自有 agent 中实现带记忆的情绪交互体验，提升对话的连贯性和亲和力。
• 注重交互体验的 AI 应用构建者：那些正在开发客户服务、心理陪伴、教育引导等需要情感感知的 AI 场景，且对项目代码质量有较高要求的团队。
• 实验性或内部工具场景：不适合处理高度敏感数据（如医疗或金融对话），但在非敏感或已获用户充分授权的内部工具中，能有效增加 agent 的拟人化程度。

使用风险及注意事项

• 性能与成本：每次 agent 启动都会调用外部 LLM API 进行情绪分类，将增加少量延迟和 API 调用成本。在大规模并发场景下需评估对响应时间和费用的影响。
• 隐私合规风险：启用该技能意味着接受将对话数据上传至外部 AI 服务，并可能创建情绪“影子画像”。在正式环境中部署前，需取得用户的明确知情同意，并向用户说明数据流向、保留策略及清除方式。
• 依赖外部服务可用性：技能的情绪分类功能强依赖于所配置的 LLM 端点可用性。若端点宕机或变更，情绪评估功能将中断（尽管会安全降级），直接影响到 agent 的交互一致性。