作者简介
陈良洪，系统架构师兼AI应用高级工程师，同时具备区块链技术背景。在AI编程实践中，深入应用代码智能补全、行间对话调试、Zulu（Agent）、Rules与Spec等范式，将AI深度集成于系统设计、开发、验证与优化的全流程，持续推动开发效率与代码质量的系统化提升。作品「Eme0情绪引擎」入围"CCF程序员大会码力全开：AI加速营"活动决赛，并获得"最佳创意奖" 。
「Eme0情绪引擎」------一个完全由百度Comate IDE生成的AI情绪引擎，从想法到上线，我没有手写任何一行代码。
1 一个被忽视的痛点：AI为什么总是「冷冰冰」？
我的创意来源：在深入研究AI对话系统时，我发现了一个有趣的现象：
大多数AI系统都有「记忆」，但很少有AI真正理解「情绪」。
想象一下，你和朋友聊天时：
朋友会记得你昨天心情不好，朋友会理解你今天的开心是因为昨天的困扰解决了，朋友会根据你的情绪状态调整说话的语气。
但现在的AI呢？它们能记住对话历史（记忆引擎），但它们无法理解情绪的变化规律，每次开发都要重新写情绪识别代码，而且很简陋。这就是我发现的痛点：情绪处理总是被当作临时功能，而不是一个专业的系统。
灵感来源： 为什么不能有一个「情绪引擎」？就像记忆引擎一样，我想到：能不能把情绪处理也做成一个独立的、专业的引擎？这个引擎应该：可以被任何AI系统调用（就像插件一样），能够存储短期和长期的情绪记忆，理解情绪会随时间衰减（就像人类会慢慢忘记不愉快），能够生成个性化的情绪画像。于是，Eme0情绪引擎的想法诞生了。
2 技术蓝图：如何让AI拥有「情感大脑」？
系统架构图⬇️⬇️
数据流转逻辑图⬇️⬇️
3 实现过程：0手写代码的「神奇之旅」
重要声明：整个项目，我没有手写任何一行代码。全部由百度Comate IDE自动生成。
3.1 编写开发文档
我的操作：向Gemini描述项目需求
Gemini做了什么：自动生成完整的技术文档，规划模块结构。
Prompt：
参照Agent中间件记忆引擎，设计一个情绪引擎。情绪引擎也是Agent中间件，提供对话中情绪的上下文支持。按照标准的MCP Server实现，提供Tools，支持Agent配置MCP即插即用。情绪引擎名字叫Eme0。请编写AI能理解的开发文档，我将使用这份文档给AI开发实现。注意，给出开发文档即可，不需要实现。注意：从0设计情绪引擎，支持长短期记忆，设计情绪推理模型。如果需要使用LLM，对接百度千帆的最新模型。
Gemini编写开发文档
后来经过实践发现，Comate也有Spec能力-即辅助澄清需求并生成专业的技术规格文档，因为这是我第一次使用Comate，所以在最初规划时，使用了自己最熟悉的Gemini。
3.2 初版实现
我的操作：告诉Comate「按照文档实现代码」
Comate做了什么：自动生成所有核心模块代码，实现MCP Server标准接口，完成情绪识别、记忆管理等核心功能。
Prompt：
markdown
基于下面的开发文档，使用Python语言，编写实现Eme0记忆引擎。需要反复调试，直到运行无问题，能正常使用为止。
这是一份为AI开发者设计的、基于Agent中间件记忆引擎（MCP Server标准）的**情绪引擎 (Eme0)** 开发文档。
-----
# 🤖 Eme0 情绪引擎 (Emotion Engine) 开发文档
## 🚀 概述 (Overview)
Eme0是一个Agent中间件，旨在为对话系统提供**情绪上下文支持**。它遵循标准的MCP Server架构实现，通过提供Tools接口，允许任何Agent实例进行即插即用配置，实现对话中的情绪感知、记忆和推理。
Eme0的核心目标是：
1. **情绪感知 (Perception):** 从对话文本中实时提取当前情绪。
2. **情绪记忆 (Memory):** 管理对话历史中的长期和短期情绪状态。
3. **情绪推理 (Inference):** 基于历史和当前情绪，推断用户或Agent的深层情绪状态和潜在意图。
4. **上下文支持 (Context):** 将推理后的情绪信息作为上下文，喂给Agent的LLM，指导其生成更具情商和连贯性的回复。
## ⚙️ MCP Server 实现标准
Eme0将实现为一个独立的微服务（Microservice），完全符合**Agent中间件（MCP Server）** 规范。
### 1. Tools 接口定义
Eme0的核心功能通过标准的MCP Tool接口暴露，供Agent配置使用。
| Tool Name | Method Signature (伪代码) | 功能描述 |
| :--- | :--- | :--- |
| `eme0_analyze_emotion` | `analyze(dialogue_turn: str, user_id: str, session_id: str) -> EmotionResult` | **实时情绪分析**。对当前的对话回合（文本）进行情绪识别，并更新短期记忆。 |
| `eme0_get_context` | `get_context(user_id: str, session_id: str) -> EmotionContext` | **获取情绪上下文**。基于短/长期记忆和推理模型，生成当前最相关的情绪描述，供LLM作为Prompt输入。 |
| `eme0_update_long_term` | `update_long_term(user_id: str, summary: EmotionSummary)` | **更新长期情绪记忆**。在Session结束或特定时间点，将短期情绪总结归档到长期记忆。 |
### 2. 数据结构定义
#### A. EmotionResult (实时分析结果)
{
"primary_emotion": "sadness", // 主要情绪 (如：高兴, 愤怒, 悲伤, 惊讶, 恐惧, 平静)
"emotion_intensity": 0.85, // 情绪强度 (0.0 - 1.0)
"emotion_keywords": ["失落", "不顺利"], // 提取出的情绪关键词
"raw_llm_response": "..." // LLM分析的原始输出（用于调试）
}
#### B. EmotionContext (提供给LLM的上下文)
{
"short_term_summary": "用户在过去3句话中，情绪从'平静'逐渐转为'轻微不满'。",
"long_term_profile": "根据历史记录，用户近期情绪波动较大，尤其容易在讨论工作时表现出'焦虑'。",
"inferred_intention": "当前的不满可能源于对之前某个问题的未解决。",
"suggested_agent_tone": "**共情且温柔地**（使用指令格式，方便LLM理解）"
}
## 🧠 核心模块设计
Eme0由三个核心模块构成：情绪识别模块、情绪记忆管理模块和情绪推理模型。
### 1. 情绪识别模块 (Emotion Recognition Module)
* **目标：** 实现 `eme0_analyze_emotion` Tool。
* **技术栈：** **百度千帆 LLM**。
* **实现细节：**
* **Prompt 设计：** 将当前的 `dialogue_turn` 作为输入，要求LLM执行**中文情绪分类**和**强度评估**。
* **输出格式：** 严格要求LLM输出符合 **EmotionResult** 的 JSON 格式。
* **LLM 对接：** 使用百度千帆的最新中文理解模型（如ERNIE 4.0或其他推荐的对话模型）进行零样本（Zero-Shot）或少样本（Few-Shot）情绪分类。
### 2. 情绪记忆管理模块 (Emotion Memory Management)
此模块负责管理长短期情绪记忆，是情绪上下文支持的基石。
#### A. 短期情绪记忆 (Short-Term Memory, STM)
* **存储内容：** 存储当前Session中每个对话回合的 `EmotionResult`。
* **机制：** 采用**滑动窗口**或**有限长度列表**（推荐存储最近 $N=10$ 个回合的情绪记录）。
* **更新：** 每次调用 `eme0_analyze_emotion` 后立即更新。
* **用途：** 用于捕捉情绪的**瞬时变化**和**连贯性**。
#### B. 长期情绪记忆 (Long-Term Memory, LTM)
* **存储内容：** 存储过去Session的情绪总结 (`EmotionSummary`) 和用户的情绪画像 (`Emotional Profile`)。
* **机制：** 采用**向量数据库**或**键值存储 (Key-Value Store)**。`Key` 为 `user_id`，`Value` 为用户情绪画像的结构化数据或总结文本。
* **更新：** 通过 `eme0_update_long_term` Tool 调用，通常在Session结束后，对STM进行总结并归档。
* **用途：** 用于捕捉用户情绪的**个性化倾向**、**敏感话题**和**周期性模式**。
### 3. 情绪推理模型 (Emotion Inference Model)
* **目标：** 实现 `eme0_get_context` Tool。这是Eme0的**核心价值**。
* **技术栈：** **百度千帆 LLM** (作为推理核心)。
* **推理逻辑：**
1. **输入整合：** 将STM的原始情绪序列 + LTM的长期情绪画像，整合成一个Prompt。
2. **Prompt 结构：**
> **[系统指令]** 你是一个高级情感分析模型。请根据用户短期对话历史和长期情绪画像，推断用户当前的情绪状态、深层意图，并建议Agent的回复语气。
> **[短期历史]** (最近 $N$ 个回合的情绪记录，如：`T-3: 平静(0.2) -> T-2: 略有不满(0.5) -> T-1: 愤怒(0.9)`)
> **[长期画像]** (从LTM获取的总结文本，如：`用户对工作相关话题敏感，近期焦虑。`)
> **[要求]** 输出符合 **EmotionContext** 的 JSON 格式。
3. **输出：** LLM推断出 `short_term_summary`, `long_term_profile`, `inferred_intention`, `suggested_agent_tone`，然后封装成 `EmotionContext` 返回。
## 🛠️ Agent 配置与使用流程
一个Agent (如 `Agent_A`) 集成Eme0的流程如下：
1. **配置：** `Agent_A` 在其MCP配置文件中声明依赖并配置Eme0的Tool。
2. **对话开始：** 用户说出 $Turn_k$。
3. **情绪分析 (Perception):** `Agent_A` 调用 `eme0_analyze_emotion(Turn_k, user_id, session_id)`。
* Eme0返回 $EmotionResult_k$，并更新STM。
4. **上下文获取 (Context Retrieval):** `Agent_A` 调用 `eme0_get_context(user_id, session_id)`。
* Eme0触发**情绪推理模型**，返回 $EmotionContext$。
5. **LLM 生成回复：** `Agent_A` 将 $Turn_k$ 和 $EmotionContext$ (尤其是 `suggested_agent_tone`) 一起喂给自己的主LLM，生成回复。
* **Prompt 示例：** `[EmotionContext.suggested_agent_tone] + 请根据对话历史，回复用户: [Turn_k]`
6. **Session 结束：** `Agent_A` 调用 `eme0_update_long_term(user_id, STM_Summary)`，归档情绪记忆。
-----
## 🔒 约束与注意事项
1. **Latency (延迟):** 由于情绪分析和推理均依赖LLM，**性能是关键**。需要优化对百度千帆API的调用频率和处理速度。建议在实时对话中，只对关键回合进行完整的推理。
2. **Cost (成本):** 频繁调用LLM进行推理会产生费用。需要设计缓存机制，或对推理级别进行分级。
3. **情绪标准化:** 确保情绪分类体系（如"高兴"、"愤怒"等）在情绪识别模块和推理模型中保持**一致性**。
4. **并发性:** Eme0作为一个中间件服务，必须具备高并发处理能力，能同时处理多个Agent的请求。
请使用这份文档来指导您的AI开发者团队，实现这个情绪引擎。
Comate初版实现
3.3 自运行改Bug
我的操作：运行代码，发现问题
Comate做了什么：自动分析运行日志，定位Bug位置，生成修复方案，自动修复代码。
结果：实时调试，无需手动排查
Prompt：
调用mcp client，修改到能正常运行。
Comate自动分析运营日志，修复Bug
3.4 自主编写测试case
我的操作：要求Comate「编写测试用例
Comate做了什么：自动生成5个真实场景的测试用例，包括工作压力、喜悦分享、失落恢复等场景，验证情绪识别准确率达到91%以上
结果：全面测试，确保功能可靠性
Prompt：
python main.py 把项目运行起来，修改所有的问题和Bug。能运行之后，编写测试文件，使用MCP Client的方式调用，写5个测试case，每个case要求连续对话，充分体现情绪引擎的优点。
自主编写case测试
3.5 增加MCP Server日志
我的操作：要求「增加日志系统」
Comate做了什么：自动在关键节点添加日志，实现错误追踪机制，优化调试体验
结果：完善的监控和调试能力
Prompt：
给MCP-server增加输入、输出、耗时的日志打印
增加MCP Server日志
3.6 情绪衰减模型优化
我的操作：描述衰减模型的需求
Comate做了什么：设计衰减算法公式，实现时间权重计算，优化参数配置。
关键描述：
「情绪会随时间衰减，就像人类会慢慢忘记不愉快」「3小时前的情绪比24小时前的更重要」
结果：实现了符合人类心理特征的衰减模型
Prompt：
优化情绪衰减模型，针对长期情绪画像的建立。增加内存记忆，实现长期情绪画像建立。
情绪衰减模型优化
3.7 最终测试效果
经过完整测试，情绪引擎表现优异
最终测试效果
3.7.1 测试逻辑
根据AI编写的Case测试，Case覆盖多类情绪识别、情绪变化、情绪融合、情绪记忆、情绪画像等。运行 python test_eme0_client.py 执行测试，查看输出的对话内容、情绪识别等，判断情绪引擎表现效果。
3.7.2 测试表现
1.情绪识别精准度 (Accuracy & Consistency)
系统对用户表达的正面情绪捕捉极其敏锐，且具备高置信度。
- 识别准确率： 在连续三轮高强度正面情绪（面试通过、面试官满意、梦寐以求的公司）输入下，系统均准确识别为 happiness。
- 情绪强度监测： 识别出的情绪强度（intensity）稳定维持在 0.90，准确反映了用户"太棒了"、"太开心了"的强烈情感。
- 关键词提取逻辑： 系统能精准提取出 [太棒了, 通过, 重要]、[满意, 开心]、[梦寐以求, 做梦一样] 等核心情感词汇，证明了其底层语义理解的深度。
2.系统性能耗时 (Latency & Performance)
在复杂的推理链（包括情绪分析、上下文检索、意图推断）下，系统表现出了优秀的响应速度。
- 单次情绪推理耗时： 平均约为 2.97s（第一轮 3.203s，随后的第二、三轮优化至 2.8s 左右）。
- 工具调用总延迟： 包含 analyze_emotion 逻辑在内的总响应时间稳定在 3.0s 左右，满足实时交互的基础需求。
3.用户情绪画像与记忆管理 (Memory & Profiling)
日志显示系统不仅在"听"，更在"记"，成功构建了动态的用户画像。
- 长期画像更新： 系统成功将"面试"这一核心事件记录进 long_term_profile，并实时生成了"暂无历史情绪挑战数据"的背景评估。
- 短期策略适配： 基于当前 happiness 的情绪状态，系统自动推断出用户意图为 "用户分享积极体验或寻求认可"。
- 话术风格建议： 引擎给出的 suggested_agent_tone（建议语气）为 "热情洋溢地分享喜悦"，实现了从识别到行动建议的闭环。
想要运行「Eme0情绪引擎」，请参考产品Github文档 github.com/wohunlfry/E... "快速开始"部分。
4 Comate清退开发路上的「拦路虎」
问题1：工程不能运行
问题描述：AI编写出来的工程无法正常运行，或者运行后调用时出现bug。
解决方案：给AI下达循环命令，要求AI运行并修复错误，直到无错误为止。要求AI编写调用示例，跟踪错误日志，修改到无错误为止。
Comate的帮助：自动运行，自动修改错误和异常，解放人力。交付的结果一定能运行。
问题2：MCP实现的协议不对
问题描述：MCP按照RESTful API实现，没有走MCP的专用协议。
解决方案：提供stdio协议的标准示例，让AI修改。
Comate的帮助：按照协议模板，直接升级协议，无需人工修改。
问题3：修改位置不对
问题描述：AI修改代码时，修改的位置不正确。
解决方案：明确指出需要修改的代码和引用文件，强调修改范围，要求重新修改。
Comate的帮助：按照要求实现，仅修改指定部分。
问题4：不是最优方案就执行，要回退
问题描述：AI在未确认最优方案的情况下就执行修改，导致需要回退。
解决方案：明确要求提供多个方案，确认方案之后，才可以执行修改动作。
Comate的帮助：提供多方案选择，节省返工时间。SPEC模式，拆解流程，分步骤执行。
问题5：对接千帆失败
问题描述：对接的千帆API无法正确调用。
解决方案：提供千帆官方示例Python代码。
Comate的帮助：按照对接方式，快速完成修改。
问题6：核心逻辑太简单
问题描述：核心的情绪衰减算法设计过于简单。
解决方案：提供详细的衰减算法、原理和要求，要求升级。
Comate的帮助：按照要求实现算法升级。
问题7：测试用例未覆盖全场景
问题描述：测试用例未覆盖全部场景。
解决方案：提供未覆盖的场景，让AI增加测试用例。
Comate的帮助：按照要求实现新的测试用例。
问题8：README文档结构问题
问题描述：README文档结构不合理。
解决方案：提供结构大纲，重新编写README，并编写英文版。
Comate的帮助：按照要求实现新文档。
5 Comate亮点：AI给我的帮助
在整个开发过程中，Comate展现出了惊艳的能力。以下是我感受最深的几个亮点：
系统架构设计：专业级的模块划分
- 传统方式：需要资深架构师，反复讨论
- Comate方式：自动设计模块结构，符合最佳实践
- 我的体验：Comate深刻理解MCP Server标准，自动划分功能模块，设计清晰的数据流。
细节实现完善：边界条件和异常处理
- 传统方式：容易遗漏边界情况，后期bug多
- Comate方式：自动补充边界条件处理、异常捕获
- 我的体验：代码健壮性大幅提升，减少后期维护成本，系统稳定性更好。
自主问题修复：智能调试助手
- 传统方式：需要手动分析日志，定位Bug
- Comate方式：运行后自动分析，定位并修复问题
- 我的体验：大幅缩短调试周期，减少重复性工作，提升开发效率。
测试用例生成：全面的质量保障
- 传统方式：需要手动编写测试用例，容易遗漏场景
- Comate方式：自动生成全面的测试用例
- 我的体验：覆盖5个真实场景，验证功能可靠性，确保系统质量。
日志系统优化：完善的监控能力
- 传统方式：需要手动添加日志，容易遗漏关键节点
- Comate方式：自动完善日志记录机制
- 我的体验：关键节点都有日志，方便错误溯源，提升可维护性。
核心算法设计：情绪衰减模型
- 传统方式：需要数学建模，反复验证
- Comate方式：描述需求，自动设计算法
- 我的体验：描述「情绪会随时间衰减」，Comate自动设计衰减公式，实现符合人类心理特征的算法
提示语工程：高质量的情绪识别
- 传统方式：需要反复试验，调整提示语
- Comate方式：自动生成高质量提示语
- 我的体验：初始提示语就很准确，持续优化提升精度，情绪识别准确率达91%。
提示语迭代优化：持续改进
- 传统方式：需要人工分析结果，手动优化
- Comate方式：基于测试反馈自动优化
- 我的体验：自动分析识别错误，生成优化方案，持续提升准确率。
6 经验分享：如何用好Comate的Prompt
经过这次开发，我总结了一些使用Comate的Prompt经验，希望对大家有帮助：
7 总结：AI开发的新时代
我的最大感受：
使用Comate后，我的工作重心从「怎么写代码」转变为「要什么功能」。使用Comate，就像拥有一个资深架构师 + 全栈工程师的团队随时待命：提出需求，它立即实现代码；发现Bug，它快速定位并修复；需要测试，它自动生成用例；需要文档，它一键生成说明。当然，这也意味着我需要将更多精力投入到技术栈管理、测试验收和产品体验优化上。
给开发者的建议：
如果你也是：AI应用开发者，Agent系统构建者，对效率有极致追求的工程师，强烈建议体验百度Comate。它不仅仅是编码工具，更是你技术团队的「能力倍增器」。在AI编码时代，掌握Comate这样的智能工具，比掌握任何单一编程语言更重要。