1. 感知系统到底是什么为什么它是智能体的大脑入口而不是传感器做了几年智能体项目我越来越觉得多数团队对感知系统的理解是模糊的。大家一上来就调模型、写工具、接API结果第一版demo经常是用户丢过来一段话直接拼进Prompt模型输出一段答案——看起来能跑但只要对话稍微长一点、输入稍微复杂一点系统就开始失忆答非所问甚至把前面几轮的信息当成当前问题处理。问题的根源往往不在模型而在感知层的设计。1.1 智能体与传统程序的决定性差异藏在感知而不是推理里传统软件是确定性的输入结构清晰走完流程就有输出。智能体不是这样它面对的是开放、非结构化、随时可能中断的输入——用户会打错字会突然改口会一次性上传十张图片会追问我说过的那个事情你记得吗。这时候智能体必须做的事不是生成回答而是先把原始输入转化为自己能理解、能决策、能追溯的结构化信息。这就是感知系统。它决定了智能体看到的世界长什么样。你给模型的上下文如果是一堆未经整理的聊天记录、日志、工具返回块那模型看到的不是世界是一团噪音。我习惯把感知系统类比成人体的眼睛和内耳前庭——它不仅是接收外界信息还要负责把信息变成身体的平衡感。没有感知层的智能体就算模型再强也像一个蒙着眼做手术的医生。1.2 感知链路的五个环节采集、清洗、结构化、组装、复盘我在自己项目里给感知层拆了五个环节缺一个都会出问题。采集Ingestion从消息队列、Webhook、文件上传、定时任务、数据库变更里把原始数据拉进来。清洗Cleansing去掉乱码、去重、过滤异常值把那些来自不同渠道的字段统一格式。结构化Structuring把文本变成带角色、时间戳、类型、事件ID的JSON把图片转成可被模型读到的Base64或URL。组装Context Assembly按当前任务决定哪些历史信息进上下文哪些压缩哪些丢弃。这一步直接决定模型能不能想起来。复盘Post-hoc Review跑完一轮后把感知到了什么和真实发生了什么做对照。这个环节很少有人做但它是感知系统持续进化的唯一途径。你可能会觉得这像数据工程。对感知层本质上就是面向大模型的数据工程只不过它的下游不是数仓报表而是模型推理。1.3 感知质量直接决定智能体的上限我在上一个项目里被一句话刺激到了。客户方负责人看了我们的Demo问了一个特别扎心的问题你们的智能体连用户在上一句已经说过的城市名称都不记得我凭什么信它能完成销售跟单那个瞬间我意识到推理模型再强也只是想法好而感知系统负责看得清、记得住。两者叠加才是可信赖的智能体。感知拉胯后面所有的规划、工具调用、行动决策都会跟着错。这就好比开车方向盘和油门没问题但前挡风玻璃是花的你怎么踩油门都到不了目的地。所以这一章我聊的就是感知系统怎么搭、怎么用、怎么避坑。内容适用于实际做智能体开发的工程师、产品经理也适合准备做Agent项目的技术负责人。2. 感知输入的三条主线消息、事件与同步调用先分清再动手如果我只能给感知系统提一条建议那就是代码写得丑没关系但数据流一定要理清楚。我用一个真实项目的例子来说明。那是一个销售跟单智能体要处理客户在各个渠道的咨询、订单变更、物流异常还要在需要时主动给客户发消息。刚开始我天真地把所有感知源都接成一种消息格式结果没多久就翻车了——定时任务触发的库存预警和客户正常提问混在一起模型分不清谁该优先响应甚至闹过客户问A产品能不能开发票模型拿库存预警的信息去回答的笑话。2.1 消息、事件、调用三种感知源三种处理语义我最终把感知输入分成三类用完全不同的数据结构和处理逻辑来对待。感知源类型典型来源语义特征处理方式消息型用户聊天、IM消息、邮件有明确发送者与接收者通常期望回应进入对话上下文参与模型当前推理事件型定时任务、Webhook回调、系统告警无明确对话方代表系统或外部世界的状态变化进入状态管理模块由智能体判断是否需要行动不直接进入上下文同步调用型工具调用返回、数据库查询结果、API响应由智能体主动发起结果必须被消费作为当前推理步骤的一部分临时注入上下文任务完成后归档这个分类不是拍脑袋它对应着智能体三种不同的注意力需求。消息型需要长期跟踪因为用户可能在五分钟后说我刚说的那个价格你能再确认下吗事件型只关心当前窗口比如库存预警过了三小时就没意义同步调用型是即时性的用完就丢长期保留反而污染上下文。2.2 事件驱动还是轮询在智能体场景里我一般选混合有人喜欢把一切感知都做成Webhook事件驱动也有人习惯定时轮询数据库。我在实际项目中是混合用的。举一个具体例子物流状态查询。轮询每五分钟跑一次大部分时候返回运输中纯属浪费但如果订单物流状态真的变了又希望智能体能第一时间感知到。我的做法是Webhook负责关键节点变更的实时通知比如已签收、派送失败轮询只做兜底两小时一次检查那些Webhook漏掉的静默变更。这样既控制了成本又保证了感知完整性。如果你把轮询频率调得太高感知层会变成性能瓶颈智能体的响应速度反而会下降。感知层的职责是在需要的时候提供需要的信息不是把所有信息都拿到手里。2.3 内部感知与外部感知的归并让模型清楚谁在说话除了用户的公开消息智能体系统里还有一类容易被忽略的感知源——内部状态。比如智能体自己刚刚执行了哪个工具上一次行动的结果是什么当前任务进行到第几步。如果这些信息不从感知层统一管理模型会经常把自己做过的事误认为是用户说的话。这在多轮工具调用的场景里特别致命。我在数据上给每个感知条目加了一个source字段取值有user、system_notice、tool_result、agent_internal四种。模型拿到Prompt时能清楚看到每一条信息来自哪里就不会再把工具返回的库存不足当成用户的自述。这一步说起来简单但它是整个感知层结构化设计里最容易被低估的一环。3. 感知管线的核心实践从原始数据到模型能理解的状态有了分类下一步就是把感知的过程工程化。我带的小团队里有个默认规矩任何感知输入在进入模型上下文之前必须经过一个明确的转换管线。没有这个管线直接拼原始文本的一律打回重写。3.1 输入归一化先别管内容把格式统一成四条元数据每一条感知信息进入系统后不管来自哪个渠道我都会先归一化成四条元数据再加上载荷payload。{ source: user, type: text_message, timestamp: 1739260800, session_id: cust_order_8823, payload: { text: 我想把订单里那件蓝色外套换成L码, attachments: [] } }source来源见上文分类type消息子类型比如text_message、order_update、image_inputtimestamp事件发生的服务器UTC时间不是接收时间session_id会话归属用于上下文按会话隔离这四条元数据的重要性我在后面讲上下文组装时会反复提到。特别是timestamp很多智能体翻车都是因为忽略了时间属性模型把昨天的事务当成当前状态导致给出错误判断。这里顺便给新手一个补充所有时间戳一律用UTC时间戳存储展示层再转本地时区。我见过太多团队存本地时间多时区跑起来全是坑。3.2 上下文组装三层滑动窗口比把所有历史全塞进去强十倍上下文窗口一直是智能体感知层的硬约束。哪怕是128K的模型也不能把所有历史都无脑塞进去——信息密度和干扰信号是并存的。我在实际项目里使用的是三层上下文结构当前窗口最近10轮对话或当前任务快照约3000~4000字包含本轮用户输入、上一个已完成的工具返回、当前活跃目标。模型做下一次推理时主要依靠这一层。近期摘要最近30轮约1500~2000字对中间历史做摘要保留关键事实、已确认信息、待办项。摘要不是逐条翻译而是提炼用户说了什么决定系统完成了什么动作。长期存储超过30轮或跨会话进向量数据库不直接注入上下文。只有在检测到当前话题与历史话题明显相关时才触发检索召回。这三层不是固定比例而是要时刻守住当前窗口足够具体、近期摘要足够精炼、长期存储足够出有感召力的原则。一个我在踩坑后总结的经验不要在Prompt里把所有工具返回都一五一十保留。举个例子智能体调天气接口返回了几百字的JSON但模型其实只需要明天上海多云 22~28度这几个字。感知层要做语义压缩把工具返回压成一句话再进上下文模型推理速度会改善很多准确率往往也会提升因为噪音少了。3.3 状态跟踪器让智能体始终知道自己干到哪了感知系统不仅仅是被动接收信息它还要主动维护一个世界状态。我会在内存里放一个轻量的状态跟踪器保存当前会话的关键状态{ session_id: cust_order_8823, current_task: 处理换货申请, step: 3, collected_facts: { customer_city: 上海, order_id: ORD202602130028, exchange_size: L }, pending_questions: [是否需要补差价], last_verified_at: 1739261050 }这个状态跟踪器的存在价值是模型是无状态的每次调用都只有上下文而智能体作为系统必须有一个地方把关键事实沉淀下来。每完成一轮交互我就用一轮新的推理结果去更新状态跟踪器然后把更新后的状态摘要放进当前窗口。状态跟踪器可以简单也可以复杂。复杂一点的会加上一个不确定性队列记录智能体还没确认的信息等下次感知到相关输入时优先确认。这个设计让我在做客服智能体时特别省心——模型不会因为用户没有直接回答某个问题就遗忘它系统会一直追着这个没闭合的问题。4. 多模态感知的工程落地别让图片和音频成为系统的短板如果说文本感知是地基那多模态感知就是智能体的视力和听力。这两年做智能体遇到多模态输入已经是常态了。客服智能体要接收用户发的商品照片、截图销售智能体要读取合同PDF里的关键字段运维智能体要看监控面板的截图判断异常。这部分的构建经验值得专门拿出来聊。4.1 先判断场景是否需要真多模态还是伪多模态很多团队把接收图片和多模态感知能力画了等号这是个误区。我用过一个项目里最开始的方案用户发一张商品实拍图系统拿到图片后先调OCR模型抽文字再把文字塞进Prompt。这种方案在识别商品名称、订单编号这种场景下是够用的成本低响应快。但换到判断商品是否有瑕疵这类场景就彻底不行了。文字描述不出来几张图片里产品外观的细微差别必须把图片本身送给视觉模型。所以我现在会先做能力矩阵分析场景推荐方案原因识别票据编号/订单号OCR 文本注入快、便宜、准确率足够识别商品外观/瑕疵/场景图片直传视觉模型需要像素级理解识别谈话中的情绪/指令语音识别 音频特征或许需要视觉模型端到端或管线看场景一句话总结能用文本完成的感知不要上多模态模型必须上多模态的时候要把它当成一条独立的感知链路来处理而不是在文本链路里打个补丁。4.2 多模态感知的时延控制是工程上最容易被忽视的坑你如果让视觉模型直接处理一张4K原图一次推理可能要8~10秒这个时延在客服对话场景里会直接造成用户等待超时的体验灾难。我的做法是感知层先统一把图片降到模型可用但成本可控的尺寸比如最长边2560px。对超长图片做切片比如一张长截图分成多块分别走视觉模型再合并结果。给多模态感知单独设定超时上限超过5秒就降级为告知用户图片正在分析中稍后回复不阻塞主流程。我在一个项目里实测过同样的视觉任务把图片从4K缩到1080P模型准确率只下降了不到2%但推理时间从8秒降到2秒。这个性价比很多人没有意识到。多模态感知的关键不是追求信息无损而是追求在业务容忍的时延和成本内拿到足够准确的感知结果。4.3 把多模态输出重新注入上下文不是所有模型都原生支持还有一个常见误区——你用的主模型可能不支持图片输入但感知层拿到了图片信息。这时候需要做一个模态桥接用一个视觉模型把图片翻译成结构化文本描述再把这描述作为感知结果给主模型。# 伪代码示例多模态感知桥接 def perception_pipeline(image_bytes): # 降质与尺寸统一 processed_image image_preprocess(image_bytes, max_edge2560) # 视觉模型提取结构化描述 vision_prompt 请从图片中提取商品类型、品牌、瑕疵描述、图片背景信息 perception_result vision_model.generate(processed_image, vision_prompt) # 把视觉感知结果转为文本注入主模型上下文 return context_block(rolevision_perception, contentperception_result, timestampnow())这套设计的经验是感知层越早把高维信息翻译成语义信息后续所有组件就越省事。视觉模型负责看懂主模型负责想明白各司其职。如果主模型本身支持图片那可以直接把处理后图片交给主模型否则就走桥接方案反正不能让图片信息卡在感知层出不去。5. 记忆感知让智能体虽然每次都是新模型但看起来像记着你如果把感知系统只理解成当前输入的获取又错了。对智能体来说历史本身就是一种感知对象。用户说我之前问过你那个事如果感知层不能把之前捞回来这个对话就断了。我在前文提过三层上下文窗口这里展开讲记忆与感知的结合。5.1 短期记忆与长期记忆的边界取决于会话而非时间有人按时间划分记忆比如一天内算短期一天外算长期。我的经验是按会话切。一次跟单任务可能持续三周三周内的状态都应该视为短期记忆每次推理都要带上关键事实而某个客户去年提过的偏好可以算长期记忆不需要每次加载但要在相关时刻被检索出来。所以我在实现里短期记忆就是当前session的状态跟踪器 近期摘要长期记忆是向量数据库里跨session沉淀的用户画像、历史任务结论、偏好标签。5.2 向量存储踩过的坑切片粒度、相似度阈值与增量索引第一个坑是切片粒度。切片太大检索召回时容易命中一段无意义的长文本切片太小又丢了上下文。我最终把文本切片控制在200~400个汉字重叠50~100字。像客服对话这种结构化数据我建议按单个完整语义单元切比如一次完整的客户提问智能体回答而不是机械按字符切。第二个坑是相似度阈值。默认的0.7阈值在很多场景下根本不适用。我做了一轮标注实验最终对我们的客服场景把阈值定在0.78左右。低于这个分数的召回基本都是噪音。而且不同业务域的相似度分布不同建议你每次接新项目时都找几组正负样本重新标定一次别偷懒沿用上个项目的阈值。第三个坑是增量更新。用户在一通对话中改了三次收货地址向量库里可能存了三个版本。我的做法是长期记忆只存最新确认状态并且每次更新时先按session_id把旧条目标记失效。不这样处理智能体就会把用户已经改掉的旧地址误以为是当前地址后果在真实业务里很严重。5.3 主动召回与被动注入记忆也要讲时机记忆不是越多越好。我把记忆感知分为两种时机被动注入在系统启动或每轮对话开始时自动拉取当前session的短期记忆放进入口上下文。主动召回当模型在当前轮推理里发现信息不足时由系统触发一次检索调用把相关长期记忆临时注入下一轮上下文。主动召回的前提是感知层能够输出信息不足的信号。我在状态跟踪器里加了一个confident_score字段模型对某个关键事实没有把握时就把分数调低触发记忆检索。这个机制让我的智能体不再一本正经胡说八道——它知道自己不确定然后去翻记忆而不是硬答。6. 感知层必须提前做对的四件脏活容错、时序、同步与隐私讲到这里感知系统的主干已经清楚了。但真正决定系统在生产环境能不能活的往往是四件不起眼的细节。6.1 感知输入的超时与重放不能让外部服务把智能体拖死感知不只是从用户那里拿输入很多时候是从外部API、数据库、文件系统里拿数据。这些外部依赖都可能超时或失败。我定的规则是所有感知调用必须有超时上限默认3秒最长不超过5秒。失败后区分可重试和不可重试。网络超时、限流返回可重试业务校验失败不可重试。重试必须带backoff策略比如1秒、2秒、4秒最多重试三次。重试期间不能让主流程一直等待。先把感知失败作为上下文里的一个fact告诉模型让它决定是继续等、换个路径、还是向用户解释。这套容错逻辑让我的智能体在外部服务不稳定时依然保持可用。感知层的核心KPI不是成功率100%而是失败时可优雅降级。6.2 时间戳对齐LLM没有与生俱来的时序感时序靠感知层给大模型内部的注意力机制并不天然理解先后顺序。如果你的感知层不强制给每条信息带上时间戳模型很可能把今天的库存数据和昨天的订单请求混在一起推理。我在感知层做了一件所有人看起来有点笨的事在给模型的上下文文本里每条感知信息前面都会加上一个自然语言的时间前缀比如12秒前上午10:23来自用户。这让模型在推理时能直接感知到谁先谁后。另外状态跟踪器里维护的last_verified_at也很关键。如果某条关键事实已经很久没被验证过系统会在推理前主动触发一次确认型感知去数据库或外部系统核对一下避免用过期信息做决策。6.3 感知与行动的数据一致性读写不同库迟早出问题感知层必须把数据落库行动层工具执行也会更新数据。这两部分如果跨库操作一致性问题迟早爆雷。我的方案很简单感知状态全部走Redis缓存加速读关键业务状态以MySQL为准写入走事务读优先走缓存但必须在修改时双写并设置过期。说人话感知层快速读缓存确认信息够新就继续不够新或修改后一定回到主库。这个读写路径分离设计在智能体这种高频读、低频写、但对实时性有要求的场景里算是性价比最高的方案。6.4 别把敏感信息全塞进感知上下文感知层会接触到身份证号、手机号、地址、甚至聊天记录里的隐私信息。我见过有团队把这些明文数据一股脑全放Prompt里一个人工审计就炸了。我的方案是分级脱敏感知层内置一个脱敏引擎凡是匹配手机号、银行卡、身份证的片段默认用***替换。只有在某个工具确实需要这些字段时才按权限临时解密一次用完即焚。另外长期记忆存储前统一做隐私字段的归一化和脱敏向量库里只存打标后的描述。做智能体感知系统先想好哪些数据能进模型上下文、哪些绝不能进这个边界定得越早后面越省事。7. 我记忆深刻的几个感知层翻车案例以及它们如何改变我的设计原则理论知识再多没有一次翻车经历来得深刻。这里记录三个让我印象深刻的感知层事故每个背后都对应一条我现在严守的设计原则。7.1 翻车一图片被感知层降质得太过分视觉识别直接崩溃项目背景是让智能体识别用户上传的订单截图提取订单号和金额。一开始为了省成本我把图片压到最低分辨率结果视觉模型连续三天把8721识别成872l把金额的千分位看丢。那次我意识到多模态感知在做压缩时不能只看体积和时延还要关注关键信息的保真度。后来我调整为两级策略初次识别用低分辨率图敏感字段识别用高分辨率图双重校验。准确率从86%提升到了98.5%。代价是多了一次视觉调用但换来的是客户不投诉。7.2 翻车二上下文里垃圾信息太多模型跟用户吵起来了这是我最丢人的一次事故。我们的销售智能体在一次测试里莫名其妙对用户说出了您刚才的方案已经被否了请不要再问这种话。查了很久才发现原因是有条历史工具返回记录里包含方案被上级驳回的负面情绪词这条记录本来应该属于另一个session的因为感知层会话隔离没做好混到了当前上下文。从那以后我写了两个硬性规矩一是session_id必须作为感知条目的强制字段二是上下文组装器在拼接前先做一次session过滤。你永远要假设模型会把上下文中看到的任何一句话都当成事实所以感知层必须在根源上保证只给模型看该看的东西。7.3 翻车三感知盲区——系统不知道自己不知道有段时间智能体在处理订单问题时表现很怪客户问在吗它直接回复了一大段您好我这边查不到订单信息请提供订单号。事后分析智能体并没有觉得信息缺失它只是在没有上下文的情况下盲目生成了回复。这就是典型的感知盲区——系统没有机制感知到当前信息不足以回答。后来我引入了前文提到的confident_score机制。每当模型输出的置信度低于某个阈值状态跟踪器就标记一条pending_question下一轮感知优先去补齐而不是让模型硬答。这个简单的改动把答非所问率从8.3%降到了1.7%。8. 一点没有写在教科书里的体会回看这些经验感知系统构建的核心其实不是某个具体技术而是一套把世界变成模型能理解的上下文的思维方式。模型每一次生成都只有一次机会感知系统负责让这次机会不被浪费。如果你正准备搭建智能体我建议不要先把Prompt调得天花乱坠而是先把感知层的数据模型设计好理清三类感知源的语义设计好元数据字段规划好上下文组装策略再考虑多模态和记忆。这样就算后面换模型、换框架感知层依然可以稳定复用。最后分享一个我常用的验证方法每个月抽查二十条真实对话比对模型回复依据的上下文和真实发生的事实凡是有偏差的追到感知层去找原因。坚持三个月你的感知系统会比绝大多数公开Demo里的实现更扎实。智能体做得越久越会理解那句话看得清才想得对。感知不是开始而是整个智能体项目的地基。