从“会干活”到“懂人心”我为什么开始重看 Agent Harness 的情感能力过去两年我一直在折腾 Agent 相关的基础设施。最初关注的是工具调用、记忆管理、任务编排这些“硬能力”总觉得把工具链做扎实了Agent 自然就好用。直到有一次做客服场景的模拟项目用户连续两次表达不满Agent 都正确识别了意图、调用了售后接口、给出了补偿方案但用户最后还是丢下一句“算了不跟你说了”直接退出。复盘时我发现流程上每一步都是对的唯一缺的是“对用户当下状态的理解”。那一刻我才意识到任务成功率再高也替代不了交互体验里的情绪信号。这个标题——“情感智能下一代 Agent Harness 的核心”——真正打动我的地方是把情感能力从“装饰层”提升到了“基础设施层”。它不是在对话界面加两句安慰话术而是在 Agent 的调度、记忆、决策链路里把用户的情绪状态当作一等公民来处理。这篇文章我不打算讲太虚的概念主要想拆解几个实际问题情感智能在 Harness 架构里到底承担什么角色、核心模块怎么落地、调参和评测有哪些坑以及我自己实测下来比较靠谱的工程路线。如果你是做 Agent 应用开发、对话系统、或者正在设计智能客服/陪伴类产品这篇文章应该能给你一个相对完整的参考。基础的东西我也会带一下但重点放在可以直接复现的模块设计和踩坑经验上。1. 传统 Agent 为什么总在“关键节点”上掉链子Harness 缺的不只是情商1.1 先聊清楚 Agent Harness 到底是干嘛的很多刚接触 Agent 的同学会把 Harness 理解成“一个跑模型的框架”其实不太准确。Harness 更像是一个承载 Agent 运行时所需的全部基础设施的容器它管理大模型的调用、工具的注册与调度、短期与长期记忆的读写、任务状态的流转、上下文窗口的组装以及外部系统的对接。你可以把 Harness 比作一个公司的中后台模型是前台员工Harness 决定这个员工能调用哪些资源、按什么流程办事、怎么记录每一次服务过程。传统 Harness 的设计核心是“正确完成任务”。它的状态机里只有用户意图、工具调用结果、任务进度、错误处理这些结构化信息。模型在这个框架下思考的是用户想干什么——我有什么工具可用——怎么拆解步骤——执行并返回结果。这套逻辑在信息查询、表单填写、流程办理类场景下非常够用因为任务目标明确成败标准清晰。1.2 一个让我印象深刻的失败样本我做过一个内部 Demo模拟的是“理财产品的提前赎回”场景。用户输入“这个产品我买了三个月现在急用钱能不能赎回手续费多少”Agent 正确检索了产品规则发现未满期限有手续费于是照本宣科地回复了费率和到账时间。用户接着问“那亏了怎么办当时你们客服可不是这么说的。”Agent 继续执行意图识别判断这是一个“投诉/纠纷”类请求自动升级到人工工单然后回复“已经为您转接人工请稍候。”看起来没毛病。但用户实际的情绪状态是着急、后悔、对平台信任感下降。如果 Harness 能捕捉到这些信号应该做的是先表达对用户处境的理解简要解释规则的同时给出替代方案比如部分赎回、短期周转功能、或豁免申请入口而不是冷冰冰地转人工。问题出在哪不是模型能力不够而是 Harness 根本没有为“情绪状态”留出位置。对话模型中每一次交互都是独立的即便前一轮检测到了愤怒情绪下一轮的状态变量里也没有地方存储这个信号。情绪只能被当前一轮的提示词隐式利用一旦轮次切换就丢了。1.3 下一代 Harness 的“情感智能”指什么我理解的情感智能不是指 Agent 要表现得像心理医生而是在 Harness 层面构建一整套“情感的感知—建模—决策—表达”闭环感知从用户的语言、语气、行为节奏中识别情绪信号建模用结构化的方式记录情绪的瞬时状态与演变轨迹决策让情绪状态参与任务规划、工具选择、回复策略的生成表达在生成侧控制语气的温度既不冷漠也不过度共情。这套能力被放进 Harness 而不是放在业务应用层关键原因是它可以被复用。客服、教育、陪伴、办公助理所有场景都需要这个闭环。如果每个业务都自己搞一套情绪识别那既浪费资源也无法形成跨场景的状态积累。Harness 是 Agent 运行时的共同底座情感智能放在这里才能形成通用能力。这一节我的核心观点是传统 Harness 的短板不是不会“说话”而是不会“听”跟“记”。情感智能解决的是 Agent 对人的整体状态感知问题它是架构层面的补课不是话术层面的包装。2. 情感智能在 Harness 中的定位一条跨模块的横切数据流2.1 情绪状态应该放在哪个环我在设计时参考过几种做法最常见的是把情绪识别结果塞进对话提示词里比如在 system prompt 中加入“用户情绪愤怒请以温和语气回复”。这种做法改动最小但问题很多。最主要的是情绪状态只存在于当前轮次的上下文中无法跨轮次积累也无法参与工具调用链路的决策。更合理的方式是在 Harness 内部维护一个“用户情感状态Emotional State”模块它独立于对话记忆但又与对话记忆、任务状态、上下文管理相互关联。这个模块的本质是一个时序状态库记录的是当前主导情绪类别如沮丧、焦虑、满意情绪强度0到1之间的浮点数情感轨迹最近N轮的情绪变化触发情境是哪类事件触发了情绪波动。这个模块由 Harness 统一管理业务层通过标准接口读写。这样做的好处是所有 Agent 都能共享同一套情感上下文。比如用户在客服场景里已经积累了愤怒情绪再转到售前咨询时这个状态可以被新的任务上下文读取从而调整后续交互策略。2.2 情感状态如何参与核心决策链路我建议不要在 Harness 里把情感智能做成一个孤立的“情感识别插件”而是要把它设计成一条贯穿感知、决策、执行、记忆的横切数据流。具体来说Harness 模块情感数据的输入情感数据的输出感知层用户原始文本/语音/行为序列情绪标签、强度、置信度状态层情绪时序数据实时情感画像决策层情感画像 任务目标回复策略是否降级/升级任务执行层策略信号语气、措辞、行为节奏的调整记忆层情感事件记录用户长期情感偏好这张表的意思是情感数据不能只在“感知”阶段出现一次然后就被丢掉。它要像一条河流一样流经所有模块。比如决策层看到用户的高强度愤怒可以选择暂缓解释性内容、先做情绪安抚记忆层看到用户近期反复出现“不满”情绪可以在下次交互时自动调整默认应答策略避免再次触发同类问题。2.3 情感状态与任务状态的优先级博弈这里有一个值得深入讨论的问题当情感信号和任务目标冲突时Harness 应该听谁的我的经验是没有一个固定答案但可以设置优先级规则。比如用户情绪强度高于0.7且主导情绪为愤怒/焦虑时情绪处置优先于任务推进用户情绪强度低于0.4即使存在轻微负面情绪也优先推进任务任务本身具备强时效性如账户异常登录则不受情绪优先级影响。这个优先级规则可以做成可配置的策略模板不同产品形态可以调节参数。Harness 不替业务做决定但提供情感状态与任务状态统一决策的机制。我在实践中的体会是没有这套机制的话靠模型自己临场判断效果非常不稳定尤其是复杂多轮对话中模型很容易被用户情绪带跑忘记原本任务。这一节的核心收获是情感智能在 Harness 中不是“加个识别接口”而是一条跨模块的数据流和一套优先级决策机制。设计对了位置后面接什么场景都顺。3. 核心模块拆解识别、建模、调节与表达四段式落地3.1 情感识别的三层分类策略我落地情感识别时没有直接上大模型来做自由文本情绪分类而是采用了“多级分类”的思路稳定性明显好很多。第一层是粗粒度情绪分类我一般用6到8个基础类别开心、满意、中性、困惑、沮丧、愤怒、焦虑、失望。这层的目的不是捕捉细腻的情感差异而是给决策层一个大致方向。第二层是强度评估。这里我不用分类模型而是用一个回归头输出0到1的强度值。比如“你们这什么破网”和“网络好像有点不稳”可能都归为沮丧但前者强度可能是0.85后者只有0.45。这个强度值直接参与优先级决策很关键。第三层是触发事件检测。也就是定位“是什么引发了用户情绪”通常用一个小的文本分类模型区分事件类型比如等待过久、操作失败、费用争议、信息不透明等。这一步对后续调节策略很重要因为同样的愤怒起因是“等待过久”还是“收费不透明”处理方式完全不同。3.2 情绪状态的时序建模从单帧识别到动态追踪很多人容易忽略一个问题单轮识别准确率再高也只是孤立的快照。用户的情绪是流动的上一轮平静、这一轮被客服气得发抖、下一轮可能因为解决方案得当而缓和。如果 Harness 只保存最新分类结果就丢了“变化趋势”这个宝贵信息。我的做法是在状态层维护一个长度为20轮的环形队列每一轮推入当轮的“情绪类别强度”。然后在其上计算几个派生特征情绪漂移速度最近5轮强度变化率的均值情绪持续性当前主导情绪连续出现的轮数触发事件热度最近10轮中同一触发事件出现的频次。这几个特征会一起写入情感画像。实际效果是Agent 能识别出“用户已经忍耐了4轮强度持续攀升”这类模式从而提前触发干预策略而不是等用户爆发后才响应。3.3 调节策略的分级响应不要一上来就“安慰”在调节策略这块我踩过不少坑。最典型的错误是一检测到负面情绪就马上进入“共情模式”一大堆“我理解您的感受”之类的车轱辘话。实测下来用户非常反感会觉得你在敷衍。我最终采用的是一套分级响应策略强度0.3以下不需要特殊干预保持正常应答但语气不能冷强度0.3到0.6启用语气温度调整在回复开头增加一句简短理解性反馈然后正常处理问题强度0.6到0.8进入“先安抚后处理”模式主动放慢节奏先给出共情再提供明确的下一步动作强度0.8以上触发人工兜底同时在人工接管的引导语中加入用户情绪上下文摘要帮助人工快速了解情况。这套分级的逻辑是情绪干预的次数越少权重越大。如果每次检测到轻微的负面情绪都要大动干戈用户很快会对 Agent 的“共情”免疫甚至产生反感。3.4 表达端的克制原则温度不等于话术堆砌最后一环是表达生成。这里我有一个始终坚持的“克制原则”Agent 的语气调整应该体现在句式选择和内容组织上而不是靠堆砌情感词汇。比如同样表达理解我会让 Harness 引导模型优先输出“我明白您现在比较着急我们按这个步骤来处理最快2分钟内能查到结果。”而不是“亲爱的用户我真的非常理解您现在焦急万分的心情请您先消消气我马上为您处理哦。”前者是“有温度地推进事”后者是“没营养的表演”。在实现上我会在生成侧注入一个“语气风格参数”它不是一个固定的 prompt 模板而是几个维度的控制指令句式长度偏好、是否使用缓解性用语、是否提供替代方案、是否主动推进下一步。Harness 根据情感模块的输出决定这些维度的取值然后交给大模型生成。这样既保留了大模型的自然语言能力又不会让情感表达失控。4. 真实项目的实测效果与调参心得别让情感模块帮倒忙4.1 一个金融客服场景的实测对比为了验证这套设计我搭建了一个模拟的理财客服 Agent就叫模拟项目X吧对比了两套 Harness一套没有情感模块一套按我上面的方案接入。评测集是150条真实客服对话改写而来的测试样本覆盖了情绪平稳、轻微不满、强烈不满、多次投诉后转人工等场景。结果很有意思。无情感模块的版本任务完成率是78%有情感模块的版本是76%反而低了2个百分点。但如果看“用户情绪缓和率”对话结束时用户情绪强度较开始时下降的样本占比无情感模块是31%有情感模块是68%翻了一倍多。另外因用户情绪激烈而强制转人工的比例从无情感模块的22%下降到有情感模块的9%。这个结果指向一个结论情感模块在短期会影响一点任务推进效率因为多轮安抚占了轮次但它在降低冲突升级、提升用户情绪体验上的收益非常显著。把“任务完成率”作为唯一指标来评估情感模块是不公平的一定要搭配情绪缓和率、转人工率、用户满意度综合看。4.2 几个容易踩的调参坑调参过程中我遇到三个印象比较深的坑写出来给各位参考。第一个坑是需求强度阈值设得太低。最开始我把0.5设为进入情绪干预的阈值结果线上效果非常糟糕因为客服场景里用户说话普遍带一点情绪0.5这个阈值把大量轻度负面情绪都识别成了“需要干预”导致很多正常对话被“共情话术”拖慢节奏用户反而觉得 Agent 磨叽。后来我把阈值调高到0.65同时增加了一个“持续性”条件必须连续两轮强度都大于阈值才触发干预。这一改干预次数少了一半以上但用户情绪缓和率反而提升了。第二个坑是情绪衰减设计。如果不加衰减一次愤怒情绪会在情感画像里保留很久导致后续多轮对话都偏向“过度安抚”很影响推进。后来我引入了一个半衰期机制每一轮结束时强度乘以一个衰减系数我实验下来0.85到0.9之间比较好同时如果当轮出现了新的正向情绪强度会被更快压低。这样既能保留情绪记忆又不让它主导所有后续交互。第三个坑是触发事件误判。有一轮我把用户的“这个按钮到底在哪”识别成了“困惑”进而触发了解释性引导语。但实际上用户是在吐槽设计不合理需要的是快速解决问题而不是教学式指引。后来我在触发事件检测的 prompt 里专门加了一条规则如果用户问句中的核心目标是定位/操作类动词优先归为“操作受阻”而不是“认知困惑”。这个细微的区别在调节策略的选择上影响非常大。4.3 评测指标的工程化建议情感模块的评测我强烈建议不要只看离线指标一定要做在线评测因为情绪体验这个东西离线打分和真实交互差距很大。我常用的评测方法是在对话结束后让用户做一个极简的情绪自评非常好/一般/有点不满/非常不满同时记录模型侧的预测情绪算一个“情绪对齐率”。这个指标能直观反映 Agent 对用户状态感知的准确度。此外我还会统计一个“过度共情率”在用户情绪平稳的样本中Agent 仍然额外使用安抚性用语或降低任务推进效率的比例。这个指标用来防止情感模块“帮倒忙”。我见过不少团队把情绪识别准确率刷到95%以上但实际用户满意度没有提升就是因为过度共情刷低了任务效率。5. 工程化路线的取舍与避坑建议坦白讲没有银弹5.1 三条实现路线的对比做情感智能这块目前市场上大致有三条路线我都有过不同程度的尝试。第一条是纯提示词方案。也就是说不引入任何专用模型直接靠大模型的上下文理解能力在每轮对话前让模型输出一个情绪判断再据此生成回复。优势是接入成本极低适合快速验证劣势是情绪状态不持久跨轮次积累能力弱而且模型在情绪判断上受上下文影响较大时好时坏。第二条是外接情感分析API或独立小模型。我自己最常用的是在 Harness 侧部署一个微调过的小模型专门做情绪分类和强度回归模型参数量在亿级以内推理成本很低延迟可以控制在几十毫秒内。优势是稳定性好可以独立评测和调优劣势是多了一次网络或进程间调用需要处理好时序与缓冲。第三条是多模态融合路线比如同时分析文本、语音语气、甚至用户操作行为。这一条是最完整的但工程复杂度是前两条的好几倍适合对体验要求极高的场景。我的建议是起步阶段不要一上来就做多模态先把文本这条路跑通再逐步扩展。5.2 模块化设计的三个要点基于我的实操如果想让情感模块真正在 Harness 里稳定运转有三个工程要点值得留意。第一情绪模块的输入输出必须做成标准化接口不要跟具体业务耦合太深。我用的接口大致是这样一个 JSON 结构{ emotion_label: frustrated, intensity: 0.72, trigger_event: operation_failure, confidence: 0.88, duration_rounds: 3 }业务层不需要关心情绪模型是怎么算出来的只需要消费这个数据结构。这就保证了情感模块可以独立升级、替换而不影响上层业务逻辑。第二情绪状态存储一定要和对话记忆分开但要有指针关联。对话记忆管的是“发生了什么”情绪状态管的是“用户状态如何”。分开存储的好处是情感画像的生命周期可以与单次会话解耦。比如我在做长期用户画像时会把每次会话结束时的最终情绪状态写入用户档案用于下次会话的初始状态参考。这样同一个用户的多轮跨会话交互情绪状态是连贯的。第三一定要设置“情感干预开关”和“情绪数据采样开关”。这两个开关在灰度发布和 A/B 测试时是保命用的。我曾经在一次灰度中因为情感模块推理异常导致部分用户响应变慢最终靠实时关闭干预开关才止损。采样开关则用于随机留存部分用户的情绪数据用于离线分析没有它的话后面的模型优化就没有数据基础。5.3 落地时容易被忽视的三个配套细节说完模块本身的工程要点再聊三个容易被忽视但实际影响很大的配套细节。第一个是超时处理。情感模块每次推理都要花时间如果它阻塞了主对话链路用户体验会明显变差。我的做法是给情感推理设一个150毫秒的预算超时就跳过情绪更新沿用上一轮的情绪状态绝不阻塞主流程。对于时序要求高的场景可以改成异步更新但决策层读取的始终是最近一次可用的状态。第二个是隐私与数据合规。情绪状态属于敏感个人信息存储和传输都要做限制。我的经验是在 Harness 层面统一做去标识化处理不直接把原始对话文本和情绪画像关联保存只在内存中维护临时状态需要写长期档案时只存情绪标签和事件类别不存句子原文。这个策略能有效降低合规压力。第三个是模型输出的情绪倾向漂移。大模型在长时间运行的场景下它的“语气温度”会漂移有时候越跑越冷淡有时候越跑越热情很不稳定。我会在生成端加一个温度控制的校准机制每10轮对话做一次语气质量抽检由规则模型判断回复是否偏离了预设的风格区间一旦偏离就触发 prompt 重置或调整。这一步对维持体验一致性很重要。5.4 我的落地顺序建议如果现在让我从零开始给一个团队做情感智能接入我会建议按这个顺序推进第1步先做情绪识别线上日志采样用无干预模式跑两周积累真实情绪分布数据同时确定情绪类别体系是否需要调整第2步只在决策层接入情绪状态不做任何生成层语气调整先验证情绪识别准确率和状态流转的稳定性第3步加入分级干预策略我前面说的四级响应用小流量验证情绪缓和率是不是真的有提升第4步确认收益后再放开生成层的语气动态调整第5步最后才做长期情感画像和跨会话状态复用。这个顺序的关键思路是先让情绪模块“只读”跑稳再让它“辅助决策”最后才让它“参与生成”。每一步都有明确的验证指标不会出现一次性接太多导致问题定位困难的情况。我在几个模拟项目中反复测试下来最稳的组合是“小模型做识别打分 规则做状态管理 大模型做受控表达”。这种组合规避了大模型情绪标注不稳定、规则系统缺乏灵活性这两个极端工程上可控体验上也细腻。未来我倾向于继续往这个方向沉淀把情感状态这把“尺子”做成 Agent 基础设施里一个默认存在的维度而不是某个场景的选配项。