根据对项目代码和配置文件的全面分析我将从以下三个方面回答你的问题一、硬编码规则Java代码中直接写死的逻辑以下规则在代码中明确硬编码不依赖 LLM 或配置文件动态调整1. 强制状态推进规则在StrictSalesEngine中赠品领取强制若用户消息包含“扫码”、“领取”、“要赠品”等关键词无论当前阶段如何nextState强制设为GIFT_CLAIM_GUIDE且action为SPEAK。代码位置StrictSalesEngine.buildStateTransitionPrompt中明确写入强制规则并在parseStateMachineDecision中再次修正。皮肤问题强制推进若当前状态为GREETING_GIFT_INTRO且用户消息包含“斑”、“痘”、“敏感”、“干燥”等皮肤问题关键词强制将nextState设为ASKING_FOR_PHOTO。置信度阈值当 LLM 判定stageComplete true但置信度 0.7 时强制改为false避免错误推进。2. 消息去重与防重放在RedisSessionManager和StrictSalesEngine.process中使用 Redis 锁和消息哈希对同一会话的重复消息2秒内相同内容进行丢弃。3. 社交规则主动联系限制SocialRuleEngine中硬编码深夜22:00 – 8:00不主动发消息。客户情绪负面时24 小时内最多主动联系 1 次。信任度低的客户联系更谨慎但仅作为提示决策仍由 LLM 做。4. RAG 混合检索优先级HybridRetriever.retrieve中硬编码检索顺序话术最高权重SOP 相关内容产品知识向量检索普通话术库数据库关键词检索5. 消息后处理MessagePostProcessor按中文标点。拆分长消息超过 50 字且无标点才切碎。负面情绪时不添加表情符号且不切太碎。6. 客户即时画像提取的降级规则ContextBuilder.extractCustomerInstantProfile中若 LLM 提取失败会回退到硬编码关键词匹配如“熬夜”、“过敏”、“价格”等。7. 阶段停留计数与超时SessionInfo中sameStageCount由代码维护在StrictSalesEngine.process中根据stageComplete递增或重置但重试逻辑仍由 LLM 决定何时放弃。8. 价格异议处理的硬编码策略模板SalesPolicyEngine中getHandlingStrategyByType方法内为 PRICE、EFFECT、SUITABILITY、TIME 等异议类型提供固定的文字策略如“先共情再强调价值”这些文字会作为 Prompt 的一部分但策略本身是硬编码的。二、通过 LLM 判断的规则动态、依赖模型推理几乎所有核心业务逻辑都通过 LLM 完成包括1. 意图识别与多意图分析BeautyIntentClassifier调用 LLM 进行意图预测支持多意图输出predictMulti。不再使用规则回退完全由 LLM 判定。2. 情绪分析与细粒度情感维度EnhancedEmotionAnalyzer调用 LLM 分析情绪类型愤怒/怀疑/兴趣/中性/兴奋及强度并返回情绪子类型、触发原因、建议响应等。3. 阶段决策SOP 推进StrictSalesEngine每次处理消息时将当前阶段、阶段目标、完成条件、对话历史等组装成 Prompt由 LLM 输出下一个状态 (nextState)是否完成当前阶段 (stageComplete)要发送的消息 (messages)置信度 (confidence)LLM 负责判断客户是否完成了当前阶段目标如“用户已发送照片”从而决定是否推进。4. 回复生成最终发给客户的话MessageGenerator、ConversationManagerService等组件均通过 LLM 生成最终回复且 Prompt 中会注入当前阶段目标与禁止话题客户画像与长期记忆RAG 检索结果产品知识、话术模板话术 Few‑shot 示例所有回复都经过 LLM 润色避免生硬模板。5. 异议类型识别与处理流程SalesPolicyEngine.ruleMatch直接调用 LLM 识别异议类型PRICE、EFFECT、SUITABILITY、TIME、OTHER。根据 LLM 返回的异议类型再调用 LLM 生成具体的异议处理回复。6. 主动跟进决策ProactiveDecisionService.decide将当前时间、客户状态、对话历史等提交给 LLM由 LLM 判断是否应主动联系并生成消息内容。硬编码的社交规则仅作为提示输入 LLM最终决定权在 LLM。7. 身份询问识别与自我介绍StrictSalesEngine.checkAndRespondToIdentity调用 LLM 判断用户是否在询问身份“你是谁”、“你是AI吗”等然后由 LLM 生成一句自我介绍。8. 策略生成ContextBuilder.addSalesStageAndStrategy调用 LLM 根据当前阶段、用户消息、情绪、档案生成阶段目标、执行策略、注意事项和推荐话术。三、系统是否会按照prompt.yaml中的 SOP 流程执行会且严格遵循。证据如下SOP 阶段配置已加载StrictSalesEngine.init()读取prompt.yaml中的templates.stageConfigs将其映射为StageConfig对象并存储到stageConfigs中。每个阶段的goal、completionCondition、forbiddenTopics、nextStage均从配置中获取。LLM 的 Prompt 中完整包含了 SOP 规则在StrictSalesEngine.buildStateTransitionPrompt中动态注入当前阶段名称、阶段目标阶段完成条件completionCondition禁止内容forbiddenTopics强制优先级规则赠品优先、皮肤问题优先这些内容直接来自prompt.yaml因此 LLM 的决策严格基于配置的 SOP。状态模板话术同样来自配置StageStateMachine中的话术模板如GREETING_GIFT_INTRO、GIFT_CLAIM_GUIDE等在prompt.yaml的templates.stageStateMachine中定义。当 LLM 决策返回的messages为空时StrictSalesEngine.parseStateMachineDecision会从stageStateMachine中获取默认话术作为兜底。强制覆盖保证关键节点不偏离尽管 LLM 负责判断但代码中仍有硬编码的强制推进如皮肤问题必须进入ASKING_FOR_PHOTO这确保了即使 LLM 出现偏差SOP 的关键步骤也不会被跳过。阶段计划与目标明确StageGoalResolver通过 LLM 再次确认阶段是否完成但其判断依据同样是prompt.yaml中配置的完成条件形成双重校验。实际执行流程示例用户进入会话 → 系统处于GREETING_GIFT_INTRO阶段。用户说“我脸上有斑”。StrictSalesEngine.process被调用构建 Prompt包含阶段目标“建立信任引导用户领取赠品”和完成条件“用户明确表示愿意领取赠品”等。LLM 返回stageComplete: true, nextState: ASKING_FOR_PHOTO, messages: [亲爱的为了更精准地判断您的色斑情况麻烦拍一张无滤镜的面部特写...]。系统更新状态为ASKING_FOR_PHOTO并发送消息。后续当用户发送照片后LLM 又会根据prompt.yaml中PHOTO_REQUEST阶段的完成条件“用户已经发送了面部照片”判定阶段完成并推进到INITIAL_DIAGNOSIS。总结类别占比说明硬编码规则约 20%主要包括安全机制去重、限流、社交规则、强制推进兜底、RAG 检索顺序、消息切分等。LLM 判断约 80%意图、情绪、阶段决策、回复生成、异议处理、主动跟进等所有核心业务逻辑。SOP 执行严格遵循prompt.yaml中的阶段配置、完成条件、禁止话题、话术模板均被完整加载并作为 LLM 决策依据同时有硬编码强制规则确保关键节点不丢失。系统已实现“重 LLM 判断、轻硬编码规则”的架构SOP 流程通过配置驱动LLM 负责理解并执行。我们被要求分析代码库找出哪些规则是硬编码的哪些是通过LLM判断的以及系统是否会按照prompt.yaml中的SOP流程执行。需要全面理解代码和业务流程。首先代码库是一个Agent系统集成了企业微信、WebSocket、LLM、向量数据库等。重点在于agent flow特别是StrictSalesEngine和StageStateMachine以及prompt.yaml中的SOP流程。需要分析哪些规则是硬编码的哪些规则是通过LLM判断的系统是否会按照prompt.yaml中的SOP流程执行我们将逐项分析。一、整体架构核心流程用户消息 → MessageReceiver → ConversationOrchestrator / StreamingThinkEngine → AgentRouter → Agent (CustomerServiceAgent) → StrictSalesEngine 或 LLM生成回复。关键组件StrictSalesEngine: 负责状态机基于SOP流程推进。StageStateMachine: 定义阶段状态。prompt.yaml: 定义了SOP的各个阶段、目标、完成条件、话术模板等。AgentThinkingEngine, MessageGenerator, ConversationManagerService等用于生成回复。二、硬编码规则分析硬编码规则指在Java代码中直接写死的逻辑不依赖配置或LLM。阶段定义和转换逻辑在StrictSalesEngine和StageStateMachine中有状态枚举StrictSalesState如GREETING_GIFT_INTRO, GIFT_CLAIM_GUIDE, ASKING_FOR_PHOTO等。阶段之间的转换主要依赖LLM决策但也有一些硬编码的强制规则在StrictSalesEngine的process方法中有强制优先级规则如果用户明确赠品领取意愿则必须转到GIFT_CLAIM_GUIDE。这是硬编码的。皮肤问题处理规则如果用户消息涉及皮肤问题必须转到ASKING_FOR_PHOTO。这也是硬编码的。在buildStateTransitionPrompt中这些规则被写入prompt但最终由LLM决定实际上在StrictSalesEngine的process方法中会先调用LLM决策然后在parseStateMachineDecision中有强制修正逻辑如果当前是GREETING_GIFT_INTRO且用户消息包含皮肤问题则强制设置nextState为ASKING_FOR_PHOTO。这部分是硬编码的后处理。身份询问检测在StreamingThinkEngine的triggerThink中先调用strictSalesEngine.checkAndRespondToIdentity该方法使用LLM判断是否为身份询问然后生成自我介绍。但checkAndRespondToIdentity内部有LLM判断不是硬编码。不过身份回复的优先级最高如果检测到身份询问会直接发送回复并return不再继续后续流程。这个调度逻辑是硬编码的。消息去重在RedisSessionManager和StrictSalesEngine中有消息去重逻辑基于hash和时间窗口硬编码。用户情绪分析在ContextBuilder中有硬编码的关键词匹配情绪分析作为降级但主要使用LLM分析。阶段完成条件判断在StrictSalesEngine中LLM决策会返回stageComplete并在parseStateMachineDecision中解析。但有置信度判断如果stageComplete为true但置信度低于0.7会强制设为false。这是硬编码的规则。拒绝拍照的处理在StrictSalesEngine中有PHOTO_RESIST_FIRST和PHOTO_RESIST_SECOND状态但处理逻辑主要依赖LLM。但硬编码了最大重试次数来自prompt.yaml的配置但代码中从配置读取不是硬编码。然而在StageStateMachine中有一些子状态处理但实际逻辑在StrictSalesEngine中。状态超时/重试计数SessionInfo中记录了sameStageCount在StrictSalesEngine中根据stageComplete更新。但重试逻辑主要由LLM决策控制。主动跟进的社交规则在SocialRuleEngine中有硬编码的规则例如深夜不主动发消息、情绪负面时24小时内最多主动联系1次等。这些规则是硬编码的但SocialRuleEngine在ProactiveDecisionService中被调用最终决策仍由LLM决定实际上ProactiveDecisionService中的decide方法会调用LLM生成决策但SocialRuleEngine提供的规则信息会作为prompt的一部分所以规则是作为提示词提供给LLM的而不是强制。但SocialRuleEngine本身的方法如isGoodTimeToContact是硬编码的。价格异议处理在SalesPolicyEngine中有硬编码的异议处理策略如价格异议强调价值、效果异议用特证等但实际回复生成仍通过LLM。常见问题缓存CommonQuestionCacheService有简单的关键词匹配硬编码。RAG检索的混合检索器HybridRetriever有硬编码的优先级话术 SOP 产品知识 话术库 关键词检索。这是硬编码的。消息分割MessagePostProcessor中按标点拆分消息硬编码。人设管理PersonaEngine中有基于客户类型调整人设的硬编码规则根据profile字符串包含“年长”、“年轻”等。但这部分是通过配置加载的prompt.yaml中personaEngine部分不过配置中定义了customerTypeAdjustments代码中读取配置并应用所以不是完全硬编码而是配置驱动的。三、LLM判断的规则大多数决策都通过LLM完成包括意图识别BeautyIntentClassifier使用LLM情绪分析EnhancedEmotionAnalyzer使用LLM阶段决策StrictSalesEngine调用LLM决定下一个状态和是否完成阶段回复生成MessageGenerator、ConversationManagerService等使用LLM异议类型识别SalesPolicyEngine使用LLM身份询问检测StrictSalesEngine.checkAndRespondToIdentity使用LLM主动跟进决策ProactiveDecisionService使用LLM策略选择StrategyRouter使用LLM策略生成ContextBuilder中的addSalesStageAndStrategy使用LLM等等LLM的prompt从prompt.yaml中读取包括系统角色、阶段配置、话术模板等。四、是否按照prompt.yaml中的SOP流程执行prompt.yaml中定义了详细的SOP流程包括阶段配置stageConfigs、状态模板stageStateMachine、主动消息proactiveMessages等。系统通过以下方式执行SOPStrictSalesEngine是核心SOP执行引擎。它在process方法中获取当前状态从SessionInfo的conversationStage。构建包含SOP阶段目标、完成条件、禁止话题等信息的prompt。调用LLM决策返回下一个状态、动作和消息。根据LLM决策更新状态。如果LLM决策的stageComplete为true且置信度足够则推进到下一阶段。SOP的完成条件在prompt.yaml的stageConfigs中每个阶段都有completionCondition如“用户明确表示愿意领取赠品”、“用户已经提供了完整的收货地址和联系方式”等。这些条件被注入到LLM的prompt中由LLM判断是否满足。因此SOP的推进是LLM判断的但条件是配置的。话术模板prompt.yaml中的stageStateMachine和proactiveMessages定义了各阶段的标准话术。在StrictSalesEngine中如果LLM决策的messages为空会从stageStateMachine中获取对应状态的话术作为默认。但实际回复生成时MessageGenerator会使用这些模板并结合上下文润色。阶段转移规则prompt.yaml的stageConfigs中定义了每个阶段的nextStage但实际LLM决策会输出nextState。LLM的决策会参考这些配置通过prompt提示但最终由LLM决定是否按照配置的nextStage推进。强制规则尽管大部分由LLM判断但代码中有一些硬编码的强制覆盖如用户提到皮肤问题时的强制推进。这些强制规则可能会覆盖LLM的决策但也是为了保证SOP流程不被偏离。阶段配置加载在StrictSalesEngine的init方法中会从prompt.yaml加载stageConfigs并映射到StrictSalesState枚举。这确保SOP阶段与代码状态对应。因此系统会按照prompt.yaml中的SOP流程执行但具体执行如判断完成条件、选择下一个阶段依赖于LLM的推理。由于LLM的prompt中包含了SOP的详细规则因此LLM能够理解并遵循流程。同时硬编码的强制规则作为兜底确保关键节点不会被跳过。总结硬编码规则消息去重、部分强制状态推进皮肤问题、赠品领取、置信度阈值、社交规则时间、频率的硬编码检查、RAG检索优先级、消息分割等。LLM判断几乎所有意图、情绪、阶段决策、回复生成、异议处理、身份识别等核心业务逻辑。SOP执行系统会严格按照prompt.yaml定义的阶段、目标、完成条件来推进但判断由LLM完成同时有硬编码强制规则作为辅助。回答时需要详细说明并给出示例。