1. 先把“感知”这件事说清楚它到底在智能体里干什么很多人一上手做 AI智能体感知模块第一反应是“不就是把用户说的话塞给大模型吗”。我最早也是这么想的直到一个接客服工单的场景把我打醒用户发来一张截图、一段语音转写的错别字文本、外加一个被截断的订单号模型给出的结论看起来头头是道实际上订单号是错的图片里的关键信息一个字都没读到。那次之后我才明白智能体的能力上限往往不是被“大脑”卡住的而是被“眼睛和耳朵”卡住的。感知模块就是智能体的感官层它负责把外部世界里乱七八糟的信号转换成内部推理可以放心消费的结构化事实。这篇文章想讲清楚的就是这一层。它适合正在做智能体落地的工程同学也适合产品同学用来判断“这个需求到底该由感知层解决还是该由决策层解决”。我会从职责边界讲起讲到架构选型、参数计算、代码骨架、排查表尽量把能直接抄的部分写细。里面涉及的目录、代码、日志都是我自己搭的一套模拟项目里的东西不是某个线上系统但思路是可以直接搬的。1.1 感知模块的职责边界它不该做决策我见过最常见的架构错误是把“判断”塞进感知层。比如在解析用户消息时顺手让模型输出一个意图标签然后决策层直接拿这个标签去执行动作。短期看很省事长期一定出问题因为感知层的错误会被下游无限放大而且没法定位——你分不清是“没看清”还是“想错了”。我的做法是把边界划得很硬感知层只回答“世界现在是什么样”不回答“我该做什么”。具体到输出它只产出三类东西原始事实文本、图片描述、表格单元格、归一化结果时间、金额、编号、实体、不确定性标注哪些字段是猜的、置信度多少、缺了什么。意图判断、工具选择、回复措辞全部留给决策层。这样切的好处是感知层可以独立做回归测试可以用固定样本集衡量准确率出了问题也能一眼看出是“看错”还是“想错”。还有一个隐性好处成本可控。感知层的调用是高频且模式化的可以用小模型、规则、缓存去扛决策层才是低频高价值的地方用好模型才划算。混在一起写等于每次看一眼图片都要付一次推理的钱账算不过来。1.2 一个最小可用的感知流水线长什么样我习惯把感知拆成五段顺序固定任何一段都可以替换实现但不要随意调换顺序接入拿到原始输入判断类型文本、图片、音频转写、结构化回调、工具返回值。归一化统一编码、裁剪超长内容、修复格式、抽出可解析的时间与数字。抽取按预设 Schema 提取字段文本走抽取提示词图片走版面识别工具返回值走字段映射。校验做类型、范围、业务规则三重检查不合格的字段标成缺失而不是硬填。封装产出一条感知事件带时间戳、来源、置信度、原文引用写进上下文或记忆。这五段里最容易被忽略的是第 4 段校验。很多团队把抽取结果直接往下传模型输出一个“2024-13-45”也照单全收后面所有环节都在错误数据上跑。校验层的成本几乎为零收益却极大属于必须做的部分。1.3 为什么我坚持先做“输入归一化”再谈多模态多模态听起来很吸引人但我实际做下来八成的线上问题出在归一化而不是模态不够多。举个具体例子同一张发票手机拍的、扫描仪扫的、微信压缩过的三者清晰度差一大截同一段用户描述有的带全角标点有的带零宽字符有的把数字写成中文。这些差异不处理后面接再强的模型也是在赌运气。归一化要做的判断其实很朴素这段内容能不能被程序可靠地切分长度有没有超过上下文预算编码是不是统一里面的数字和日期有没有歧义我一般会在接入层做一次“体检”把体检结果作为元数据带下去。后面所有环节都能看到“这条输入是低质量图片”“这条文本被截断过”从而决定是重试、降级还是直接向用户要补充信息。这比在最后一步让模型自己猜“我可能没看清”要可靠得多。2. 感知模块的整体设计与选型考量2.1 三种常见架构的取舍直连式、网关式、事件式我前后试过三种组织方式各自适用面差别很大选错了后期改造成本很高。架构形态典型做法优点代价适合场景直连式每个智能体自己调解析逻辑起步快代码少逻辑重复难统一治理单场景 Demo、验证期网关式所有输入先过一层感知服务规则集中可观测好做缓存多一跳延迟需维护服务多智能体共用、要上线事件式输入变化触发感知事件流支持增量、支持异步复杂度高调试麻烦长任务、持续监听型智能体直连式我在做原型时用得最多一上午就能跑通。但只要场景超过两个你就会发现同一套“日期归一化”写了三遍而且三遍的规则还不一样问题排查时非常痛苦。网关式是我目前的主力选择它把归一化、校验、缓存收拢到一处代价是增加一跳延迟实测同一机房内这一跳通常在几十毫秒量级对绝大多数对话场景无感。事件式适合另一类需求智能体不是被用户一句话叫醒而是持续盯着某个数据源。这时候感知不再是“函数调用”而是“订阅 变更检测”。我一般会先用网关式把单次感知跑顺等确实出现“需要持续观察”的需求再把网关改造成可发布事件的形态而不是一上来就上事件流。2.2 为什么把“解析”和“理解”拆成两层解析是确定性的活切分、解码、提取字段、补全格式这些能用规则和轻量模型做结果可复现。理解是不确定性的活判断这段话在说什么、图里这个人有没有戴安全帽、这份合同的关键条款风险在哪必须用大模型。拆开的好处体现在三个地方。一是缓存同一张图片的解析结果可以按内容哈希缓存理解结果可以按“解析结果 提示词版本”缓存命中率很高。二是降级模型服务抖动时解析层照常工作只是理解层降级为返回“未识别”智能体至少能说一句“我收到了但暂时读不出内容”而不是整条链路断掉。三是评测解析层用精确匹配就能测理解层才需要人工标注和模糊评分两套评测体系分开维护谁退化了很清楚。注意拆分不是让你写两套完全独立的工程。解析层的输出必须是理解层的输入中间用一份明确的 Schema 交接别搞成两个团队各定义一套字段。2.3 Schema 优先让感知输出可被程序消费我现在的习惯是动手写抽取提示词之前先把 Schema 定死。Schema 不是给模型看的装饰它是感知层和决策层之间的合同。字段名、类型、是否必填、取值范围、缺失时怎么表示全部写清楚。一个够用的 Schema 大概长这样from typing import Literal, Optional from pydantic import BaseModel, Field class Entity(BaseModel): kind: Literal[order, person, product, time, amount] raw: str Field(description原文片段不做任何改写) normalized: Optional[str] Field(defaultNone, description归一化后的值) confidence: float Field(ge0, le1) source: Literal[text, image, audio, tool_result] class PerceptionEvent(BaseModel): event_id: str observed_at: str modality: list[str] entities: list[Entity] missing_fields: list[str] quality_flags: list[str] Field(default_factorylist) raw_excerpt: str这里有两个设计决定值得说。raw和normalized分开存是为了保留可追溯性归一化出错时能回看原文而不是只剩一个被改过的东西。missing_fields单独列出来比在字段里塞空字符串好得多决策层可以据此直接决定“要不要追问用户”不用去猜空值代表什么。2.4 成本和延迟的账先算清楚再动手感知层的调用量通常是决策层的好几倍钱主要烧在这里。我一般按下面的方式估假设单次对话平均产生 6 条感知输入用户消息、两次工具返回、一次图片、两次补充说明日活 5000 轮对话那就是每天 3 万次感知调用。如果每次都用大模型做全量抽取按输入 1200 token、输出 200 token 估算日 token 量约 4200 万成本很容易失控。我的优化顺序是这样的先用规则和正则吃掉能确定的部分编号、金额、日期这部分几乎零成本再用小模型做分类和字段定位只对必要的片段调大模型最后给理解层加缓存同一份解析结果在短时间内重复出现时直接复用。实际跑下来大模型调用量能压到原来的三分之一左右延迟也从秒级降到几百毫秒。这个账必须在设计阶段算等上线了再优化改动面会大很多。3. 核心环节的实现细节与实操要点3.1 输入归一化编码、格式、长度的三道过滤第一道是编码与字符。我会统一转 UTF-8去掉零宽字符和不可见控制符把全角数字、全角标点转成半角。这一步看起来琐碎但实测下来能明显减少抽取错误尤其是从聊天软件复制粘贴过来的文本经常夹带奇怪的空格和软连字符。第二道是格式修复。纯文本要处理换行混乱、列表符号丢失表格要还原行列关系图片要先判断分辨率和倾斜角度低于阈值的直接标为低质量进入降级分支而不是硬着头皮识别。我给图片定的下限是短边不低于 720 像素低于这个值就提示“图片过小请重拍或上传原图”比让模型去猜要诚实。第三道是长度裁剪。这里必须算清楚预算。假设模型上下文是 32K token我要留 8K 给系统提示词和输出感知层可用大约 20K。中文大致按 1 字约 1.5 token 估那正文上限大约 1.3 万字。超长文档必须分块分块策略我倾向于按语义边界切章节、段落、表格行而不是按固定字数硬切硬切最容易把一句话和它的主语切散。提示裁剪时一定要记录“被裁掉了多少”写进quality_flags。后面如果发现模型答非所问第一件事就是查这条标志而不是怀疑模型变笨了。3.2 文本感知抽取提示词骨架与校验闭环文本抽取的提示词我一般写成四段式角色与任务、字段定义、输出格式、边界规则。重点在第四段也就是“遇到什么情况该认输”。很多提示词只讲要什么不讲不要什么结果模型遇到缺字段时会自己编一个看起来合理的值这是最危险的失败模式。边界规则我会明确写原文没有的信息一律填 null不要推测数字必须原样抄录并在 normalized 里给出转换结果不确定的字段把 confidence 调低无法判断类型时归到unknown而不是硬套最像的那个。这些规则听起来啰嗦但确实能大幅降低“一本正经胡说”的比例。校验层是第二道保险我按三个层次做类型校验金额必须是数字时间必须能解析成时间戳编号必须符合业务格式比如长度和前缀。范围校验金额不能为负退款场景除外所以要按场景配置时间不能晚于当前时间太多。交叉校验如果文本里同时出现“共 3 件”和明细列表就数一下明细条数对不对如果不一致把冲突记进quality_flags让决策层知道这里有矛盾。交叉校验这一层是我认为最值钱的部分。它不需要额外模型调用纯粹靠逻辑比对却能抓住相当一部分抽取错误。尤其是票据、订单、清单这类有内部一致性的内容效果非常明显。3.3 图像与文档感知分块、版面还原、别迷信一次识别图片和 PDF 的处理思路跟纯文本完全不同。我的经验是先做版面分析再做内容识别最后做结构化归档。直接对整张图做识别遇到多栏排版、表格、页眉页脚混排时结果会乱成一锅粥。具体做法上我会先用轻量的版面检测把页面切成区域标题、正文、表格、图注、印章对每个区域单独识别最后按阅读顺序拼装。表格单独走一套流程先识别行列结构再把单元格内容填进去最后转成结构化数据。这一步多花的时间很值因为表格一旦按纯文本识别行列关系就彻底丢了后面再想还原基本不可能。文档类输入还有一个坑页码和页眉会被重复识别导致同一段话出现好几次。我会在归一化阶段做一次去重按段落哈希比对重复的直接丢掉。另外扫描件里的印章、手写批注经常被误识别成正文我的处理是把置信度低且位置异常的文本块单独隔离不并入主内容但保留在附件里供人工查看。注意不要为了让识别“看起来完整”而放宽阈值。宁可返回“这一块没认出来”也不要塞一段编造的内容进去。感知层说“不知道”是合格表现说错话才是事故。3.4 工具返回值的感知把接口响应也当成外部世界这一点经常被忽略。智能体调用工具拿回来的 JSON本质上也是“感知输入”同样需要归一化和校验。我见过太多情况是接口返回了 200 但 body 里是错误码或者字段名变了、类型从字符串变成数字智能体毫不知情地继续往下走。我的处理是把工具返回值也送进感知网关走一套轻量的映射规则先按 schema 校验字段缺失或类型不符就标为感知异常再把关键字段抽成实体附上来源标记tool_result最后把原始响应压缩后存档。这样一来决策层拿到的永远是统一的感知事件格式不需要为每个工具写一套解析逻辑。这里还有个小技巧给每个工具维护一份“契约快照”记录上次见到的字段结构。如果这次返回的结构跟快照差异超过阈值就触发告警。这个机制帮我提前发现过好几次上游接口悄悄改字段的情况比等到用户投诉要早得多。3.5 置信度和不确定性让智能体知道自己没看清置信度这个数值最怕变成摆设——所有字段都填 0.9等于没有。我的做法是把置信度分成三档而不是连续值确定原文直接可见规则或高置信识别得到、推测模型推断原文有间接依据、未知缺失或无法判断。三档足够决策层做分支判断也更容
