一条用户反馈，往往包含几件不同的事。
“这次活动奖励挺好，但更新后老是登录失败，能不能先帮我解决？”
这是一条用来说明问题的示意反馈。如果只给它贴上“正向”或“负向”的标签，运营团队仍然不知道下一步该怎么处理：用户认可的是活动奖励，遇到的是登录问题，眼下需要的是帮助。将这些信号分别识别出来，才有机会把反馈送到合适的流程里。
最近受到关注的Jev，让我们进一步思考：AI Agent工作中的这些具体判断，能否由更适合的模型来承担？
1. Jev提供了什么能力
Jev是TypeSafe推出的System One模型。给它业务上下文和定义清楚的问题，它会返回程序可以直接使用的判断结果和概率，例如从候选项中选择一项、判断某个条件是否成立，或按设定等级进行评分。
这样的输出适合接入软件流程。面对同一条反馈，可以分别询问“用户在谈什么”“对哪个对象不满”“是否明确提出求助”，再由程序组合答案。涉及多个话题时，也可以逐个判断哪些话题成立，保留“其他”或“不确定”的出口。
GPT等通用大模型继续负责理解复杂任务、组织分析、生成内容和解释结果。Jev则可以承担其中范围明确、反复出现的判断。Agentic Engine提供企业数据、业务知识、Skills 和执行流程，把不同模型的结果接起来。
2. Agentic Engine全域洞察：让每条反馈留下更有用的信号
看用户反馈时，业务团队需要知道的不只有情绪好坏。同一条帖子，可能既认可活动，也对某个具体问题不满。把这些态度压成一个总分，后续处理就容易丢掉信息。
我们准备了6条反馈样本，让Jev对每条反馈分别回答四个问题：是否包含正面评价、是否反映产品问题、是否明确求助、是否涉及付费。同一条反馈可以同时符合多项，不必只归入一个类别。
例如，输入“这次活动奖励挺好，但更新后老是登录失败，能不能先帮我解决？”，Jev对前三项给出了较高分数，对“付费相关”给出了较低分数。对应到这句话，就是既认可奖励，也遇到了登录故障，并希望得到帮助，没有提到付费。这些分数表示模型对各项判断的支持程度，不是准确率。
我们再将输出与事先设定的标签逐项比较，24项判断中有21项一致。其余3项存在分歧，也暴露了标签定义需要进一步明确的问题。
随后，我们又选了两条正文更完整的真实社区帖子。一条在找游戏搭子，正文主要描述玩法偏好和组队条件，Jev给出了“组队与社交”的分类，并识别出组队招募、休闲玩法偏好等信号。
另一条讨论娱乐赛事：用户觉得赛制“有点意思”，同时希望多邀请一些选手。Jev将它判断为“正负并存”，进一步拆出了赛制兴趣和阵容诉求。
对运营团队，这种拆分的价值在于能继续往下处理：按具体话题追踪反馈，区分用户在认可什么、希望改变什么，再结合版本、活动和用户行为决定是否跟进。通用大模型可以据此归纳问题、解释变化；Jev则承担其中边界明确的标签判断。
3. Agentic Engine智能运营：给流程画布增加语义条件
传统的人群圈选可以根据行为和业务规则，找到近期活跃下降、尚未完成某个关键步骤的用户。但进入同一个人群，未必意味着他们需要同一种帮助。
在手游流失召回的验证中，我们让语义分流读取玩家最近的反馈，并从已经定义好的处理路径中选择。需要操作指导的玩家进入攻略引导；遇到报错的玩家进入客诉处理，再按业务规则决定是否补偿；明确表示不希望收到消息的玩家进入免打扰路径；无法匹配召回目的的表达交给人工复核。
测试时，我们把8条玩家反馈交给Jev，并提供四种可选处理路径：攻略引导、客诉处理、免打扰和人工复核，要求它为每条反馈选择一项。对于“这个功能我还不会用”，Jev返回“攻略引导”；对于“操作到这里就报错”，返回“客诉处理”；对于“最近没有需求，别再给我发消息了”，返回“免打扰”。8条反馈的分类结果均与事先设定的预期一致。
其中一条反馈是“下个赛季什么时候开？满级了没事做”。它既没有提出操作或故障问题，也没有要求停止接收消息。按照本次提供的分类规则，Jev返回了“人工复核”，对于当前处理路径未覆盖的诉求，Jev选择同样精准。
在这套协作中，Agentic Engine的规则决定哪些用户进入流程，Jev辅助判断表达更符合哪条路径，通用大模型参与策略说明和内容生成。实际触达、补偿与执行仍受企业配置的权限、频控和审批约束，模型的分类结果本身不会授权一次业务动作。
策略是否有效，还要观察执行后的点击、转化、留存和用户打扰，并通过实验比较。模型把一条反馈分到某条路径的概率，不能直接当作该策略提升转化的概率。
4. Agentic Engine语义层：在查数之前，把口径选清楚
自然语言查数同样包含大量需要明确的判断。
“最近新用户的付费率怎么样？”看起来是一个简单的问题，但“新用户”按注册还是首次登录定义？“最近”是哪段时间？付费率看当天，还是注册后七天？不同口径都可能算出一个数字，业务含义却不同。
我们正在建设的项目语义层，着眼于把指标定义、业务术语、数据来源和使用规则整理成 Agent 能复用的上下文。围绕这个问题，小样本验证分成两步：查询之前选择口径、识别缺失条件，查询之后检查文字结论是否得到给定数据支持。
第一步，我们提供了来自真实项目的4个事件候选：注册账号、应用安装、完成引导和用户登录。Jev选中了“注册账号”作为本例的新用户口径，同时识别到“最近”没有明确时间范围，需要继续向用户确认。这个结果说明它可以辅助候选选择，但企业对“新用户”的正式定义，仍然应由语义层提供。
第二步，测试给定了本周4.2%、上周 4.4%两个周期的结果，再要求核验一句话：“付费率约4.2%，过去四周持续下降。”Jev保留了与输入一致的4.2%，同时否定“四周持续下降”的说法：只有两周数据，不能推出四周趋势。这里的百分比是核验样例中的输入，不是Jev带来的业务提升。
这提供了一个具体的结合方向：在有权限使用、经过治理的候选指标与资产中辅助选择；条件不完整时先补问；得到结果后，再检查时间范围、指标含义和文字结论是否对应。
一次样例核验不能证明模型能可靠验算。数值计算、日期比较、数值一致性校验与查询执行，仍由数据引擎和确定性程序负责；Jev辅助检查的是口径和文字含义是否匹配。减少选错指标、遗漏条件和结论超出证据范围，是我们接下来要在更多真实问题上验证的目标。
对ThinkingAI而言，这次检验Jev的重点是把模型判断接到企业已有的数据、知识和业务流程中，让关键步骤可以检查和复核。小样本验证已经帮助我们明确了可继续推进的场景，也暴露出标签口径和边界判断的问题。接下来需要扩大业务样本、完善复核机制，并在实际流程中检验效果。
如果你的团队也在处理大量用户反馈、设计更细的运营分支，或希望减少自然语言查数中的口径歧义，欢迎带上一个具体业务场景与我们交流。
