情感智能嵌入Agent Harness：下一代Agent系统的核心工程

做Agent系统这行做得久了你会发现一个很有意思的现象模型本身越来越会“说话”了但Agent整体给人的感觉还是“聪明有余温度不足”。尤其是涉及到客服、教育、医疗这些需要对用户情绪做出反馈的场景用户明明已经着急上火了Agent还在冷冰冰地报菜单。这个问题我琢磨了很久结论是问题往往不在模型而在Agent外面的那层运行时框架——也就是Agent Harness。我一直在想下一代Agent Harness的核心竞争力到底是什么。现在比较明确的答案是情感智能。这不是指给模型加几句“你要温柔一点”的提示词而是把情绪信号的感知、理解、表达和反馈作为像上下文管理、记忆读写一样的底层能力直接嵌进Harness里。这篇文章我就从工程落地的角度拆一拆情感智能为什么必须进入Harness、进去了之后该怎么设计以及我在实际项目里踩过的坑。1. 为什么情感智能必须进 Harness而不是贴在对话层1.1 Agent 的“情商”瓶颈不在模型在运行时先澄清一个常见误区很多人觉得让Agent有情商就是在提示词里写“请用温和友善的语气回复用户”或者在模型层换成更大的底座。这两招不是完全没用但都解决不了核心问题。我自己做过一个客服场景的Agent项目一开始也是这么干的。业务方说用户反馈“Agent太生硬”我们就让大模型把回复写得更委婉结果上线之后效果确实好了一点但很快暴露了新问题用户说“我快崩溃了”Agent确实用很温柔的话去安慰了但安慰完还在走标准流程、问“请问您还有什么其他问题”完全没判断出用户情绪已经到了需要特事特办的级别。这就是典型的“语气对了判断错了”。问题出在哪出在运行时。模型是一个纯粹的文本生成器它能在生成每一句话时考虑语气但它没有一个稳定的机制去回答一个问题用户当前处于什么情绪状态这个情绪状态在整段对话里是怎么变化的这次的负面情绪是因为什么事件触发的没有这个机制Agent表现出来的“高情商”就全靠临场发挥时灵时不灵。打个比方模型是发动机Harness是整车的底盘和控制系统。发动机性能再强没有一套好的悬架和转向系统过弯的时候照样翻车。情感智能就应该是悬架和转向的一部分而不是贴在外面的一个装饰件。1.2 Harness 是情绪信号的“高速公路”那Agent Harness到底是什么你可以把它理解成Agent的“驾驶舱”和“总控台”——模型之外的那一层代码逻辑负责会话状态管理、上下文组织、工具调用调度、记忆读写、策略路由。大模型本身是不保留对话状态的它每一次生成都是“一次性”的让Agent表现出跨轮次记忆、会调用工具、能做出复杂决策的就是Harness。这一层框架天然就是情绪信号流通的“高速公路”。用户的情绪必须经过这里才能被记录下来、被跨轮次追踪、被用来调整后续策略。如果情感智能不放在这一层而是放在对话层做一次性判断那么会话状态管理不知道用户情绪在持续恶化仍然按正常流程走记忆系统不会把“这次不愉快的经历”标注成影响未来互动的负面事件策略路由不会因为用户处于愤怒状态就减少不必要的确认环节工具调度不会在高压力场景下优先选择低摩擦的解决路径。所以我的观点很明确下一代Agent系统和上一代的区别不是模型更强而是Harness把情感智能内化成了基础设施。就好像智能手机和功能机的区别不只是多了个触摸屏而是整个操作系统都围绕触摸交互重构了。2. 情感智能在 Harness 里的四层解剖2.1 感知层情绪信号的结构化捕捉情感智能进Harness第一步是感知。感知层要回答的问题是用户当前的对话内容、交互行为中包含哪些情绪信号信号的强度有多大。我建议不要把情绪简单地分成“正面的”“负面的”“中性的”这个粒度太粗对策略选择的指导意义很弱。更实用的做法是采用“效价-唤醒度”两个维度来描述情绪状态效价表示情绪的积极程度范围可能是-1到1唤醒度表示情绪的强烈程度范围是0到1。比如“有点不满”可能是效价-0.3、唤醒度0.4“愤怒”则是效价-0.8、唤醒度0.9。加上具体的情绪标签比如“困惑”“沮丧”“焦急”“失望”就足够支撑后续的策略路由了。感知层的输入不只有文本。用户连续输入“这到底怎么回事”“怎么又不行了”输入速度、重复次数、停顿时长这些都是高唤醒度的信号。在多模态场景下语音的语调、语速、音量也能提供很丰富的信息。具体落地的时候不建议一开始就上多模态成本太高。先做文本维度就够用在Harness的请求入口加一个异步的情绪识别服务把当前用户消息和最近几轮上下文一起送进去输出情绪标签、效价、唤醒度、置信度。这里有一个关键点情绪信号不要写死在数据库里就完事而是要作为当前会话请求的元数据在Harness内部流转供后续所有模块使用。2.2 认知层情绪到策略的映射感知层告诉我们用户“是什么情绪”但没告诉我们“为什么会有这个情绪”更没告诉我们“接下来该怎么办”。这个就交给认知层处理。我见过不少团队在做情感智能的时候直接把“情绪识别结果”映射到“回复模板”检测到用户生气就回复“非常抱歉给您带来了不好的体验”。这种做法的问题非常大因为同样的情绪在不同场景下对应的处理策略天差地别。举个例子用户说“你们这个功能怎么这么难用”如果是从没使用过的新手那他的“愤怒”其实是对自己的“沮丧”需要的是引导和鼓励如果是用了很久的老用户那他的“愤怒”是对产品设计本身的不满需要的是共情和转给产品团队如果用户正赶着处理一个重要任务他的“愤怒”是对时间损耗的抗拒这个时候你跟他道歉、共情他只会更加烦躁他最需要的是“快速解决方案”。所以认知层的核心工作叫“情绪归因”。它要结合当前的任务状态、用户历史画像、该轮对话的触发事件判断情绪的来源然后输出一个“策略意图”。认知层的产物不再是一个情绪标签而是一个类似“用户因操作失败而产生沮丧需要优先恢复其完成任务的信心并提供低门槛的行动入口”这样的结构化判断结果。从实现上讲认知层可以做成一套规则引擎加一个轻量分类模型规则引擎负责处理常见的、明确的场景比如用户连续遇到报错分类模型负责处理更复杂的、需要语义理解的场景比如用户反讽、暗示。两者结合比单靠大模型硬猜要稳定得多。2.3 表达层策略的生成与抑制有了策略意图表达层负责把它变成真正的回复约束。这里说的“约束”不等于具体的回复话术而是给生成模型限定的一组条件比如共情深度是简单表达理解还是需要深入承认用户的挫折感解释密度尽量少用术语用大白话讲清楚行动项数量给用户提供的下一步操作选项不要超过多少个道歉频次整段回复中道歉最多出现几次结构优先级先给解决方案还是先给予情绪支持。为什么强调“约束”而不是“话术模板”因为话术模板是死的容易显得机械而且不同场景的组合是无限的。生成约束则是在不牺牲自然度的前提下把大模型的输出往正确的方向引导。有一个点很容易被忽略表达层不只是“生成”还要负责“抑制”。在某些场景下用户需要的不是安慰而是方案过度共情反而会拉长对话、消耗耐心。比如用户发了一句“帮我查下订单号快点”这个时候你说“我完全理解您现在焦急的心情非常抱歉让您久等了”然后再慢慢引导操作用户大概率会更烦。合理的策略应当是用半句话表达理解立刻进入查单过程。这个“少说话”的动作也必须由表达层通过约束来控制。2.4 反馈层闭环调节情感智能落地到最后一定要形成闭环。用户的情绪被识别、被处理、得到回复之后其后续行为本身就是最好的反馈信号。如果收到安抚后用户语气变得缓和说明策略有效如果用户仍然重复同样的问题或者直接要求转人工说明策略没打准。这些反馈信号要回到Harness用来做三件事一是实时调整当前会话的情绪状态槽二是离线记录策略效果为后续优化提供数据三是在策略置信度较低或者负面情绪持续升级时触发升级机制比如转人工。反馈层让我感触最深的一点是不要指望一次判断就能做对。情感其实是动态的用户的情绪会在对话过程中波动可能从平静变成不满再从不满变成接受。Harness如果能跟踪这个变化曲线比单独一次准确的判断有价值得多。3. 把情感智能真正装进 Harness实操设计3.1 在既有 Harness 流程中插入情感节点聊完理论说点能直接动手做的。假设你已经有一个可运行的Agent Harness里面包含请求解析、上下文管理、策略路由、模型调用这几个基本模块现在要把情感智能插进去。我比较推荐的做法是在请求解析之后增加一个“情感感知节点”这个节点不是阻塞式的而是异步并行地调用情绪识别服务拿到结果后回写到会话状态。主流程继续往下走等到需要选择回复策略时从会话状态里读取情绪信息传递给策略路由。async def handle_user_message(harness, user_input, session): # 1. 情感感知异步不阻塞主流程 emotion_feature await harness.emotion_service.analyze( user_input, session.recent_context() ) # 2. 更新会话状态中的情绪状态槽 session.emotion_state.update(emotion_feature) # 3. 结合任务状态和场景进行策略选择 context harness.context_builder.build(session) strategy harness.strategy_router.select( emotionemotion_feature, task_statesession.task_state, scenariosession.scenario, user_profilesession.user_profile ) # 4. 在生成约束下调用大模型 reply harness.llm.generate( user_input, contextcontext, generation_constraintsstrategy.generation_constraints ) # 5. 反馈追踪放入异步队列不影响响应 harness.task_queue.submit(feedback_trace, session.id, reply) return reply提示情绪识别服务要做好超时和降级。如果这个服务挂了或者超时不能让整个Agent的回复卡住。合理的做法是设置一个极短的超时时间比如200毫秒超时就返回“中性情绪”默认值主流程照常执行。这个设计的好处是侵入性很小不需要推翻原有架构只需要在策略路由处接收一个新的信号。而且因为情绪信息被写入了会话状态所有下游模块都能读得到。3.2 情绪识别服务怎么搭情绪识别服务是感知层的具体实现这个服务的搭建质量直接决定上层效果。我建议的方案是“轻量模型为主大模型兜底”而不是一刀切全部用大模型。全部用大模型做情绪识别效果确实不错但成本高、延迟不可控。尤其在对话高频场景下每个请求都多一次大模型调用整体开销翻倍都不止。轻量文本分类模型比如基于预训练模型微调的小模型可以处理大部分常见情绪标签的识别延迟在几十毫秒级别成本也低得多。只有当轻量模型的置信度低于阈值时才上报给大模型做更细致的判断。我建议的情绪标签体系可以包含八个基础类别平静、愉悦、期待、困惑、沮丧、失望、愤怒、焦虑。每个类别输出一个概率取最高概率作为情绪标签同时保留效价和唤醒度两个数值。这套体系覆盖了绝大多数服务场景又不至于细碎到难以标注。训练数据的获取有一个捷径先跑一版规则版情绪识别基于关键词和表情符号把规则版判出来的情绪和上下文存成候选样本再让人工基于对话历史做标注。这样人工只需要改“规则判错了”的样本标注效率会高不少。如果你有历史客服对话记录这一步是很好的资源和起点。识别结果怎么用也要有明确的策略。当置信度低于阈值比如小于0.6时宁可不触发任何情绪策略也不要用一个大概率错误的情感判断去影响回复。我管这个原则叫“宁缺毋滥”。3.3 策略库怎么设计策略库是认知层和表达层的中间载体。每一条策略描述的是当某个情绪状态和某个场景条件匹配时生成回复应该遵循什么样的约束。我的做法是把策略写成结构化的配置项由Harness在运行时加载。举个例子{ scenario: task_failure, emotion: frustrated, intensity: high, strategy: { type: comfort_then_action, priority: task_completion, constraints: { empathy_level: 2, apology_max_count: 1, solution_first: true, jargon_density: low, max_steps: 2 }, fallback: escalate_to_human } }这条策略的含义是当用户处于“任务失败”场景且情绪是“高强度的沮丧”时优先采用“先安抚再行动”的方式回复中最多道歉一次、必须尽快给出解决方案、减少术语、把后续操作压缩到两步以内如果用户仍然情绪强烈就转人工。策略库不需要一开始就很庞大先把最常见的几个场景覆盖掉比如“操作失败”“等待过久”“诉求被拒绝”“信息难以理解”。每个场景配合两到三种情绪状态总共也就二三十条策略。上线之后根据真实数据持续扩充。策略库的设计过程中有一条原则值得反复强调策略是给Harness和生成模型的约束不是给用户的文案。你不需要把策略写得像人话你需要把它写得像一份明确的行动指令。4. Harness 架构如何被情感智能“重塑”4.1 会话状态管理要新增“情绪状态槽”传统Harness的会话状态里存的是对话历史、槽位信息、任务进度。情感智能落地之后我强烈建议增加一个“情绪状态槽”专门用来存放当前会话的情绪状态。情绪状态槽不能只是一个字符串“frustrated”那么简单它应该是一个结构化的对象至少包含四项内容当前情绪标签及其强度效价和唤醒度数值情绪趋势是恶化、缓解还是平稳最近一次情绪变迁的触发事件。{ user_id: u_10023, session_id: s_89012, emotion: frustrated, valence: -0.6, arousal: 0.7, trend: rising, trigger_event: user_failed_step_3, confidence: 0.82, update_time: 2025-06-18T10:23:41Z }有了这个状态槽跨轮次追踪才可以实现。比如用户在第一轮表现出“困惑”第二轮变成“沮丧”第三轮已经接近“愤怒”这个趋势信号会让策略路由知道普通的安抚话术已经不够了需要直接转换处理方式或者尽快转人工。如果没有情绪状态槽每一轮的情绪识别就都是孤立的相当于每次都重新认识一个用户情绪积累和爆发这个过程就完全察觉不到。很多同学说“Agent感觉不灵敏”其实不是不灵敏是根本没把情绪连起来看。4.2 记忆层要增加情绪标注与衰减长期记忆系统是另一个必须被情感智能改造的模块。让Agent记住“用户A曾经在某个功能上遇到过问题”这很重要但如果记成“用户A很讨厌这个功能”这就危险了。我建议在长期记忆里给每条关键事件加上情绪标注但情绪标注必须和事实分开存并且加上时间衰减。比如用户在某次会话里表达过强烈不满这条记忆可以标记为“包含负面情绪事件”但它在未来决策中的权重应该随时间自然衰减。一周后衰减到一半一个月后衰减到接近零。不然就会出现一种很尴尬的情况用户半年前发过一次火此后每次正常使用Agent都会被特殊对待对方体验反而很差。衰减机制也不需要搞太复杂一个简单的公式就能用记忆权重 初始权重 × 衰减系数 ^距今天数 / 半衰期天数。把半衰期设成7天负面情绪的记忆在两周后影响力就很弱了这样既能保护“用户曾经受挫所以要更小心”的信息又不会让用户被一张旧标签永远贴住。还有一个细节情绪标注不要写“用户是攻击型人格”这种对人的评价而要写“当前主题在用户侧曾触发强烈负面反馈”。前者是归因于人后者是归因于事件。这不仅是工程问题也是产品价值观问题。4.3 工具调用与延迟策略情感智能还会影响Harness里的工具调度逻辑。传统Harness判断要不要调用某个工具主要看任务是否需要。但加入情感维度之后还需要考虑用户当前的情绪状态是否适合进行某一类操作。高唤醒度的负面情绪比如愤怒、焦虑下用户的耐心非常有限。这时候Harness应该自动切换到“快速通道”模式减少不必要的二次确认、合并操作步骤、优先展示直接结果。比如用户在售卖系统里发起退款申请但一直失败系统提示“您确定要申请退款吗退款会需要1-3个工作日”这个确认动作在平静状态下是合理设计在愤怒状态下就是火上浇油。更合理的做法是识别到高唤醒负面情绪后Harness将工具调用策略调整为“直达目标”直接给出退款入口自动预填已通过校验的信息把需要用户确认的内容压缩到一项并同时提示人工客服通道。用“减少摩擦”来应对“情绪升级”这个思路在很多场景下都验证有效。5. 常见问题与踩坑记录5.1 操作误区过度共情导致“假温情”这是我见过最多的问题。情绪识别上线后Agent开始对用户每一句话都表现得很关心用户随便说一句“头晕”它就说“很抱歉听到您不舒服要不要休息一下”用户说“功能太复杂”它就“非常理解您的感受这个设计确实不够友好”。时间一长用户会觉得“这个助手太假了。”问题出在两个地方一是没有区分情绪强度轻微不满也被当作强烈负面情绪处理二是共情动作没有分级所有情绪触发同一档位的安慰。我建议对情绪强度和共情动作都做分级低强度的负面情绪只做最低限度的共情重心放在任务推进上只有高强度的负面情绪才启用完整的情绪策略。真实的人和人交流也是这个逻辑没有人会对朋友一句轻飘飘的抱怨每次都郑重道歉。5.2 记忆层踩坑情绪标签污染了事实记忆有一次测试我们的Agent在用户提了一个敏感操作后变得异常保守连正常操作都不敢推荐排查后发现记忆系统里有一条负面情绪事件和当前操作主题关联在一起。本来只是一次独立的失败经历但在记忆检索时被当成了“这类操作都会让用户不满”的泛化结论。后来我把“情绪事件记忆”和“事实偏好记忆”分成两个独立的存储空间和检索通道主题重叠时情绪事件只作为策略参考不影响事实判断。这个拆分很关键。你可以把它理解成知道用户上次在这个环节受挫过但不要预设他这次还会受挫。5.3 性能陷阱情绪识别拖慢了主流程早期版本里我把情绪识别做成了主流程的同步调用结果平均响应时间增加了差不多一位数用户等得心焦负面情绪更严重形成一种恶性循环。后来把所有情绪识别服务改成异步并行并设置超时降级主链路完全不被拖累。这个改动上线后整个系统就稳了。如果要再进一步优化还可以做两层缓存同一用户如果连续几条消息情绪稳定就复用最近一次的情绪判断结果不必每条消息都调用模型。多轮对话里用户往往是会连续说几句话的中间的情绪没有突变复用是合理的。5.4 评测维度的缺失只追识别准确率不追策略效果很多团队做情感智能第一反应是先堆“情绪识别准确率”在测试集上刷到很高但上线之后业务指标没变化。原因很简单情绪识别准确率高不等于后续应对有效。我建议建立两层评测体系。第一层是离线层评估“策略路由准确率”——构造一批带标注的情绪对话场景标注里写清楚“这种情况下应该采用什么样的应对策略”然后看Harness选出来的策略和标注的一致性。第二层是在线层看业务指标——用户满意度、问题解决率、因情绪问题升级人工的比例。在线层的效果才是最终标准。情感智能做得好的直接体现应该是用户能更顺利地完成自己想做的事而不是Agent说话说得多么动听。最后再分享一个小技巧我自己的习惯是在正式做情感策略之前先给Harness加一个“旁路情绪日志”通道。这个通道只做记录不干预任何决策——每条用户消息进来异步记录一下情绪识别结果、当时的策略选择、用户的后续行为。跑上一到两周你手里就有了第一批真实数据再基于这些数据去做策略思路就会清晰很多也不会凭空设计出一堆用不上的方案。另一个经验是情感智能的迭代不能只看对话记录还要看产品本身能不能消化这个能力。用户情绪是在具体产品流程里产生的如果流程本身太虐人Agent再怎么安抚也只是缓兵之计。一个负责任的技术方案应当既让Agent察觉情绪又让产品能根据情绪信号把流程改顺。这两条腿并行情感智能才真正能成为下一代Agent Harness的核心竞争力。