先讲一个最近让我印象很深的场景。有位同事跑过来一脸无奈地说我让Agent帮我订个会议室它连下午3点前结束这种明确条件都能无视直接给我订到了4点半这模型是不是不行我看了日志之后发现模型压根没收到3点前结束这个槽位——在感知层用户原话里的后半句就已经被静默吞掉了。这就是AI Agent类产品最典型的理解错需求大部分人不信但真正丢信息的环节往往不是推理能力不足不是规划链写得不够好而是最靠前的感知层出了问题。你可以把Agent想象成一个人大脑再聪明耳朵听岔了后面所有动作都白搭。本文就把感知层这件事彻底拆开聊清楚它到底做了什么、在哪些环节翻车、以及我实际排查时用的土办法。1. Agent的耳朵到底怎么工作的先把四段式流水线摆出来1.1 感知层、规划层、行动层和记忆各管一段主流的Agent架构一般拆成四块感知层、规划层、行动层和记忆系统。很多人把注意力放在规划层觉得只要让大模型多思考几步Agent就会变聪明这个方向不能说错但忽略了一个事实——规划层拿到的东西完全取决于感知层喂过来的东西长什么样。感知层的定义一句话概括就是把用户输入的原始信息文字、语音、图片、工具返回值、环境上下文转成Agent内部能用的结构化表示。所谓结构化表示不单单是意图识别而是包含三个部分用户想干什么意图、完成这件事需要的参数槽位、以及不能违背的约束条件边界。举个例子。用户说帮我订一家明天晚上7点的川菜馆别太辣人均别超150。感知层要做的是输出下面这种结构意图restaurant_booking槽位时间明天19:00、菜系川菜、人数未知约束辣度低、人均≤150元如果感知层漏掉了别太辣后面规划层和行动层再强订出来的馆子大概率就是个重麻重辣的火锅店。这就是理解错需求的第一层真相不是不理解是根本没听全。1.2 感知失败的三种典型表现锁词、猜默认值、静默截断我刚做Agent评测那段时间把几百个失败案例归了一下类发现感知层出问题基本就三种形态。第一种叫锁关键词。模型只记住了句子里的高信息量名词比如会议室川菜馆合同但把修饰性、限定性的成分丢了。用户说随便找家能打包的快餐Agent识别出快餐就去下单了根本没管能打包这个限定。第二种叫猜默认值。输入里某个关键槽位没给全感知层不标记为未知而是直接按常见值补一个。用户说下周找个时间开会系统直接默认成下周一上午十点结果用户周一根本不在。这里的问题不在于猜而在于感知层没有把猜测变成待确认直接把猜测当成事实传给了下游。第三种叫静默截断。长输入、多条件叠加时模型输出受长度或注意力限制把后半句的信息弄丢了。就像前面提到的下午3点前结束一样明明在原句里最后的结构化输出里却找不到。这类问题最坑因为它没有任何报错表面上流程照常跑但结果从一开始就是歪的。1.3 为什么感知层问题容易被误判成模型笨这个观察很关键。当Agent做错事用户和开发者第一反应往往是模型推理能力不行于是去调Prompt、换更强的模型、加请你仔细思考之类的咒语。但实际上如果结构化信息在感知层就错了后面怎么优化推理都没用因为推理器拿到的是一份错误地图。我后来养成了一个习惯接到理解错需求的反馈先不急着看规划链直接查感知层的输出。如果感知层的JSON里少了一个槽位、填错了一个值那结论就很明确了——问题出在耳朵而不是大脑。2. 五个最常被感知层吞掉的需求细节附真实Badcase拆解2.1 修饰关系被压平槽位和槽位之间的关联丢了语言里的信息不是平铺的是有修饰结构的。帮我把昨天开会录的60分钟音频转成文字稿去掉停顿和重复——这里昨天开会录的60分钟修饰的是音频去掉停顿和重复修饰的是转写结果。感知层如果只做简单的槽位抽取很容易把60分钟理解成转写时长上限甚至把重复理解成重复文件去重。根因在于通用大模型在处理口语时倾向于把句子里的名词性短语单独拎出来而忽略它们之间的修饰链。我在实际项目里见过最离谱的案例用户说查一下上个月华南区的销售额只要大客户的系统把上个月识别成了今天的日期把华南区识别成中国华南这个地理概念过滤条件只要大客户的直接消失。这个问题很难通过换模型解决因为它是语言理解层面的系统性偏差。需要的是在感知层加一层槽位关系校验比如给每一个槽位绑定它的修饰来源让60分钟和音频长度建立连接而不是孤零零地当成一个数字。2.2 代词指代翻车多轮对话里的那个它上次全都悬空多轮对话是Agent感知层的重灾区。用户先问我上个月提交的报销单处理到哪一步了Agent回答完用户紧接着说帮我撤回它——这个它到底指报销单还是指刚才某个流程如果感知层没有把对话历史里的核心实体做锚定它就会悬空最后撤回的可能是别的东西。还有更隐蔽的指代像上次那样帮我约一下。这个上次完全依赖记忆系统里的历史记录而记忆召回又是另一层不可控的因素。如果感知层只顾着解析当前这句话、不去主动关联历史实体这类需求必然丢。我踩过的坑是只把历史对话全文塞给模型以为上下文窗口大了就能解决指代问题。但实际上上下文越长模型对早期信息的注意力越弱与其全文塞入不如在感知层单独维护一个实体锚定表每一轮都把当前指代解析后的结果放进去这样下一轮就算用户说它也能第一时间知道指代对象。2.3 多模态输入不对齐截图里那张表格到底该看哪一列多模态感知是另一大坑。用户上传一张项目进度截图说把里面进度100%的任务挑出来整理成周报发我。感知层需要对图像做OCR、要理解表格结构、还要把进度100%这个条件定位到具体列上。这个过程中最经典的错误是视觉信息超载模型把截图上的标题、备注、水印、无关图表都当成有效信息结构化抽取时把进度100%和另一行的状态混在一起。更麻烦的是图片里表格的复杂表头比如完成百分比列下有实际完成和计划完成两个子列。感知层一旦选错列后面所有统计都对不上。我现在的处理方式是多模态场景强制要求感知层先输出我看到的内容清单再输出我抽取的数据项并且对表格类图像强制走专门的表格结果识别流程不直接让通用的视觉理解模型一次到位。2.4 工具返回信息被二次翻译成错误语义感知层不只感知用户输入还要感知工具返回的结果。很多Agent流程是这样用户问一个业务问题Agent调某个内部接口拿到一串JSON然后把JSON丢给模型解读。这中间容易出问题的是模型会把字段名的字面意思当成业务含义。举一个实际遇到的例子内部API返回的字段叫total语义是本次请求分页的总条数模型却把它理解成总金额直接回给用户总金额是328条——这会让用户直接懵掉。另一个常见情况是API返回的错误信息是一段带状态码的JSON感知层把它当成正常业务数据传给了规划层导致Agent一本正经地向用户道歉说查无此项。要堵住这类问题最有效的方法不是指望模型理解字段名而是给每一个工具返回值配一份字段语义字典在喂给模型前先做一次字段映射和类型校验。字段名叫total就明确翻译成总条数叫amount才翻译成金额。2.5 隐含约束被忽略预算别太离谱到底怎么量化最后这一类我认为是感知层最难解决的隐含约束。用户不会把所有限制条件都显式说出来而是用模糊表达暗示。比如帮我订个酒店预算别太离谱找个离地铁近点的尽量别选周末。别太离谱没有量化标准地铁近点没有具体距离尽量别选周末不是硬约束。感知层如果把这些过滤掉规划层就会按默认逻辑选酒店结果必然是用户觉得这Agent完全不懂我。我的处理方法分两步第一步在感知层识别出模糊量词并单独标记成待澄清项第二步把模糊量词映射成一组候选阈值让规划层做结果集排序而不是硬过滤。例如别太离谱可以映射为在同类需求历史均值附近浮动20%以内优先展示近地铁映射为步行10分钟内候选优先。这样既不打断用户体验又让模糊条件变成可执行的筛选逻辑。3. 从工程上堵住感知漏洞的七个实操手段3.1 用Schema把听懂变成填对感知层最忌讳的就是让模型自由发挥地理解然后拿一段自然语言文本传给下游。我强烈建议给感知层定义一个强制输出的JSON Schema让模型的结构化输出格式完全固定下来。一个设计良好的感知层Schema长这样{ 意图: restaurant_booking, 槽位: { 时间: 2025-06-02T19:00:00, 人数: null, 菜系: 川菜, 地点: null }, 约束: [ {类型: 辣度, 值: 低, 来源: 用户原话: 别太辣}, {类型: 人均预算, 值: 150, 操作: le, 来源: 用户原话: 人均别超150} ], 置信度: {意图: 0.97, 槽位时间: 0.89}, 待澄清项: [人数] }这个结构的重点是槽位缺失必须显式写成null而不是让模型自己补一个默认值约束条件必须带来源方便后续排查是哪个词触发的。模型输出不符合Schema时直接重试一次并在重试提示里给出上一次的具体错误位置这样能大幅降低格式错误率。3.2 意图识别和槽位抽取走双通道不要全指望大模型大模型做意图识别和槽位抽取已经很强了但它有个致命弱点不稳定。同一个表达这次给的意图和上次给的意图可能不同同一句话槽位的边界也可能漂移。所以我推荐在感知层做双通道用轻量级的规则或分类模型做第一道意图识别再用大模型做第二道槽位精修。第一道通道不复杂本质上是一个意图白名单加一批正则触发词比如订/约/预约触发预订类意图查/看看/找找触发查询类意图。它做不了精细理解但可以稳定给出意图候选。第二道通道拿到候选意图后再针对性地抽取对应槽位。两个通道结果一致就走正常流程不一致时把差异项放进待澄清列表而不是盲目相信某一个通道。这个方法虽然土但在生产环境里极其可靠能有效防止大模型偶尔抽风。3.3 主动澄清把猜变成问澄清机制是被很多人低估的感知层能力。现在市面上很多Agent的设计目标是一次到位用户提一个需求最好别追问直接干。这个目标本身没错但在槽位、约束不完整的情况下强行执行出错的代价反而更高。主动澄清的正确姿势不是简单说我没听懂请再说一遍而是把当前已识别到的信息完整展示给用户并列出缺失项。比如已为你记录明天19:00用餐、川菜、人均预算≤150元。还差两个信息就餐人数是否需要包间这段澄清同时做了三件事向用户确认已抽取的信息是否正确、给出缺失槽位的具体问题、暗示用户只需回答缺口成本很低。我经历过一个对比同一个会议室预订场景加了主动澄清之后用户满意度上升明显因为用户感觉系统有在认真记而没加澄清时系统订错后用户需要多轮手动纠正体验差远了。3.4 上下文锚定别把对话历史一股脑全塞进窗口前面说过多轮指代翻车的根因是实体没有锚定。工程上的解决办法是单独维护一个当前任务上下文结构每个新请求进来时只把和当前任务相关的历史摘录喂给模型。这个结构至少包含四块原始指令全文、已确认槽位集合、工具调用结果摘要、用户历史修正记录。举例用户上一轮说帮我查一下Q3的采购订单系统已经确认时间是Q3、对象是采购订单这一轮用户说把金额汇总一下那感知层只需要把查询对象采购订单、时间Q3、动作汇总金额组装起来不需要重新理解。这个方案比单纯扩大上下文窗口更可靠因为感知层不是被动地回忆所有内容而是主动地只提取与当前指令相关的锚点。3.5 输入侧归一化时间、数字、单位在进模型前先转一遍大模型在处理明早下周三一万二1.2w这类表达时直接输出的结果经常不统一。我建议在感知层之前加一个输入归一化模块专门处理时间、数字、金额、单位。归一化规则不复杂日期类短语统一转成YYYY-MM-DD或带时区的ISO格式数字类表达统一转成阿拉伯数字金额类统一成同一币种和单位。比如明早可以先用规则识别出明天再结合当天日期算出具体日期一万二统一转成12000。这一步的好处是把大模型最不擅长的格式化环节抽离出来让模型专注于理解语义而不是同时还要做数值转换。我在一个数据报表Agent里加上这一层之后涉及日期和金额的槽位错误率下降明显。3.6 感知层可观测性给Agent的耳朵装上录音笔感知层问题难排查很大的原因是它没有留下过程记录。很多团队只记录最终结果比如Agent最后执行的动作、最后的回复但中间用户原话是怎么变成结构化JSON的这一过程完全是黑盒。我强烈建议在感知层输出端打完整日志包括原始输入文本、归一化后的文本、NER抽取出的实体列表、最终结构化JSON、每个字段的置信度、被过滤掉的候选意图。这样任何一个badcase出现都能从日志里准确看出信息是在哪一步丢的。举个例子用户反馈我明明说了不要上午它还是给我订了上午。如果日志里显示结构化JSON中禁止时段[上午]这个字段存在那问题就在规划层如果日志里根本没有这个字段那就是感知层抽取丢了。有了日志问题归属瞬间清晰排查效率完全不一样。3.7 需求歧义题库把红队测试做成常态化机制感知层的bug不会一次性暴露而是随着用户表达方式的变化不断出现。所以需要建立一个需求歧义题库把历史上所有感知层翻车的用户原话收集起来按风险类型打标签比如隐含约束遗漏指代悬空修饰关系丢失模糊量词未量化。每次做模型升级、Prompt迭代时先拿这套题库跑一遍回归对比修复率。修复了一个旧case绝不能以破坏两个新case为代价。我当时建题库的时候很多人觉得工作量太大但后来发现它的价值不在于测试而在于迫使整个团队去理解感知层的失败模式。当你把50条badcase按类别整理出来你会发现感知层的错误根本不是随机的它有着非常强的规律性。4. 一次订会议室需求的全过程复盘从误判到修干净4.1 完整链路还原每个环节丢掉了什么为了更直观地展示感知层问题的全貌用一个真实的模拟案例走一遍。用户原话是下周想约合作方过一下方案帮我订个大点的会议室要能投屏别订太晚下午3点前结束。这句话在人类听来需求非常清楚。但放进Agent感知层我实际观察到的错误链路是这样的预期结构化结果意图room_booking槽位时间下周某工作日具体待定、容量大具体人数未知、设施[投屏]约束结束时间≤15:00、开始时间不宜太晚实际感知层输出意图room_booking槽位时间下周一09:00默认填充、容量12人默认填充、设施[投屏]约束无对比之下三个问题同时出现。第一下周被直接锁定成下周一没有把合作方时间待定这个不确定性保留下来。第二大点被猜成12人其实用户没说人数应该标为未知并澄清。第三别订太晚下午3点前结束这两个约束完全消失规划层根本不知道有这条限制所以最后订到一个14:00开始、16:30结束的时段完全符合这个错误链路。更麻烦的是用户看到结果后说我不是说了3点前结束吗此时Agent如果没有感知层日志可查只能把锅甩给模型然后重复一次原来的错误猜测过程。4.2 针对每个错误点的修复动作修复不能只改Prompt而是要改感知层的机制。针对默认填充问题要在Schema里把缺失字段设置为null并强制感知层输出待澄清项列表。对下周这类有歧义的时间表达感知层应输出time下周锚点日期2025-06-02精确日期待澄清而不是直接猜一个周一。针对大点这个模糊容量词建立容量映射表当人数槽位缺失时把大点映射为一个范围8~12人而不是硬编码成12人并且在执行预订前询问实际人数。针对约束丢失把约束条件从槽位中独立出来单独设计一个约束列表字段。感知层必须显式回答用户有没有提出任何时间、数量、偏好限制没有就输出空数组。这个设计会让模型被迫检查一遍约束而不是只顾着提取核心实体。修复后再看同一个输入感知层输出变成{ 意图: room_booking, 槽位: { 时间: {描述: 下周工作日, 精确日期: null}, 容量: {描述: 大, 人数: null}, 设施: [投屏] }, 约束: [ {类型: 结束时间, 值: 15:00, 操作: le}, {类型: 开始时间, 值: 不晚于14:00, 操作: le, 来源: 别订太晚} ], 待澄清项: [人数, 具体日期] }这时候规划层拿到的信息就完整了至少在感知层面不会再出现3点前结束被吞掉的情况。4.3 对这类场景的一个通用建议会议室这个案例其实非常有代表性一个需求里既有显式条件又有模糊条件还有隐含偏好。对这类复杂场景我建议所有的Agent产品都在感知层的下游设计一个用户意图复述动作在真正执行前把结构化理解用一句话展现给用户例如为你查找下周工作日下午、可容纳8~12人、支持投屏、15:00前结束的会议室可以吗这个过程表面上是确认实际上是把感知层的责任边界划清楚如果我理解错了你在这里纠正我而不是等我执行完再发现问题。这个机制比任何模型优化都更直接、更有效。5. 我日常排查感知问题的一套土办法5.1 拿到一个badcase先分聋还是瞎所谓聋是原始输入在感知层没有被正确转成结构化信息比如槽位丢失、约束被忽略。所谓瞎是感知层已经给出了正确的结构化信息但规划层和行动层没有照着执行。区分方法特别简单直接看感知层的输出JSON。如果JSON里信息齐全、值正确那问题就在后面如果JSON里缺字段、填错值那感知层就是根源。用这个方式我能在五分钟内把问题定位到具体环节而不是在和模型参数设置较劲。5.2 感知问题和规划问题用三个特征快速区分光看JSON还不够尤其是没有完整日志的时候。我用三个经验特征来快速判断第一看用户补充信息后的表现。用户说我不是说不要上午吗如果Agent听到补充后立刻修正了结果那大概率是感知层当初没抓到如果用户纠正后Agent仍然无动于衷可能是规划层或状态管理的问题。第二看不同说法是否指向同一语义。同一个需求换个说法Agent的表现如果天差地别说明感知层对表达方式过于敏感这是典型感知问题。比如找个安静的地方开会和会议室别太吵如果一种情况理解了、另一种完全没理解感知层大概率有问题。第三看最终结果的错误类型。感知层错误往往表现为做了一件用户没提过的事比如用户没让查天气突然推荐带伞规划层错误往往表现为知道该做什么但步骤错了比如想订会议室却选了视频会议。这个特征虽然不绝对但能提供快速的方向判断。5.3 每周给感知层做一次体检最后分享一个习惯我会每周抽半天把那段时间所有被标记为理解错需求的case拉出来重新跑一遍当前版本看看修复率的变化。不为别的就为了逼自己持续关注感知层这个环节而不是等着用户来投诉。做这件事不需要复杂工具一张表格就够了案例编号、用户原话、错误类型、感知层输出、规划层输出、当前修复状态、备注。跑两三个月之后你会很清楚地看到自己产品里感知层的高频问题类别也能判断出每一次Prompt迭代到底是真实改进了感知能力还是只是碰巧覆盖了几个badcase。我现在的感受是AI Agent能不能做好很多时候不取决于用了多大的模型而是取决于最前面那层耳朵有没有听清、听全、听懂。感知层这个环节值得每一个做Agent的人花最多的时间。