从一次诡异的“死循环”说起去年年底我在调试一个用于智能家居的Agent系统。任务很简单用户说“我到家了把客厅灯打开空调调到26度”。Agent收到指令后先调用语音识别模块然后执行设备控制。结果呢Agent在“打开客厅灯”这一步之后突然又去重新解析了一遍“我到家了”这句话然后再次开灯再解析再开灯……日志里出现了连续17次开灯指令直到我手动kill掉进程。排查了一下午问题出在哪儿Agent的“记忆”模块把“用户到家”这个事件写入了长期记忆然后它的“推理”模块在每次执行完动作后都会重新扫描记忆库把“到家”事件又当成了一条新指令。这就是典型的感知与记忆耦合错误——Agent不知道哪些信息是“已经处理过的”哪些是“需要响应的”。这个案例让我意识到很多人把Agent当成一个“黑盒”觉得给它一个大模型就能搞定一切。实际上一个能落地的Agent必须把五个核心能力拆清楚、搭明白。下面我用自己的工程笔记方式把这五个能力掰开揉碎讲一遍。感知不是“听见”是“听懂并过滤”感知层最容易犯的错误是“全收”。早期我做的一个客服Agent把用户所有输入都丢给大模型结果用户咳嗽了一声Agent回复“建议您多喝热水”。这不是智能这是智障。工程上感知要做三件事多模态输入的归一化。语音、文本、传感器数据、API回调这些输入格式千奇百怪。我习惯在感知层做一个统一的“事件总线”所有输入先转成标准的事件结构体。比如语音转文本后和直接输入的文本在总线里都是{type: text, content: ..., timestamp: ...}。别在感知层做语义理解那是推理层的事。噪声过滤。这里有个血泪教训别把“嗯”“啊”“哦”这种语气词直接传给推理模块。我写过一个过滤器用正则短文本长度阈值把小于3个字符且无关键词的输入直接丢弃。但注意别过滤掉“是”“不”这种关键应答——我后来加了一个白名单。上下文锚定。感知层需要标记“这条输入属于哪个会话”。很多Agent出问题就是因为把不同用户的输入混在了一起。我习惯在事件结构体里带一个session_id由感知层从请求头或语音流的元数据中提取。代码片段别这样写# 错误示范直接在感知层做语义理解defperceive(raw_input):if开灯inraw_input:return{action:turn_on_light}# 这里越界了推理层还没干活呢正确做法# 感知层只做格式化和过滤defperceive(raw_input,session_id):iflen(raw_input.strip())2andraw_inputnotin[是,不,好]:returnNone# 直接丢弃噪声return{type:text,content:raw_input.strip(),session_id:session_id,timestamp:time.time()}推理别让大模型“裸奔”推理是Agent的“大脑”但很多人直接把大模型API一调就完事。这会导致两个问题一是大模型会胡说八道二是推理结果不稳定——同一个问题两次调用可能给出不同答案。我的工程实践推理必须带约束。我写了一个“推理模板引擎”把大模型的输出限制在预定义的JSON schema里。比如用户说“开灯”推理模块必须输出{intent: device_control, device: light, action: on}。如果大模型输出格式不对就重试一次重试失败就走fallback比如“我没理解您的意思”。引入“推理缓存”。对于常见问题比如“现在几点了”没必要每次都调大模型。我维护了一个LRU缓存key是输入内容的embedding向量命中就直接返回历史推理结果。注意缓存要有过期时间否则用户说“关灯”后又说“开灯”缓存会给出错误结果。推理要分层次。别让大模型处理所有事。我习惯把推理拆成两步第一步用规则引擎比如正则、决策树快速判断意图如果规则能覆盖直接出结果规则覆盖不了的再调大模型。这样90%的简单请求可以在10ms内完成只有复杂请求才走大模型通常200ms。这里踩过坑有一次我把“打开窗户”误判为“打开网页”因为规则引擎里“打开”“窗户”的匹配优先级设低了。后来我把设备名做成一个动态加载的字典从智能家居的API实时拉取规则引擎优先匹配字典里的设备名。规划把“我要做A”拆成“先做B再做C”规划能力是Agent和普通聊天机器人的分水岭。用户说“帮我订一张明天去北京的机票然后通知小张去接我”Agent需要拆成查航班→选座位→下单→查小张联系方式→发通知。规划模块的工程实现我踩过三个大坑规划不能太“死”。早期我用的是静态任务图每个任务写死依赖关系。结果用户说“先订机票再通知小张”但小张的电话在订机票之后才拿到规划就卡死了。后来我改用动态规划器每个步骤执行完后根据实际返回结果动态调整下一步。规划要有“回退”机制。假设规划是步骤1查航班步骤2下单。如果步骤1查不到航班步骤2就不该执行。我写了一个“规划执行器”每个步骤执行前检查前置条件是否满足不满足就跳到错误处理分支。错误处理分支不是简单报错而是尝试替代方案——比如没航班就推荐高铁。规划结果要可解释。用户问“你为什么先开灯再开空调”Agent得能回答“因为开灯只需要0.1秒开空调需要30秒才能达到设定温度所以先开灯让你有光再开空调让你凉快”。这个解释不是大模型生成的而是规划器在生成步骤时给每个步骤打了一个“原因标签”。代码片段口语化注释defplan(intent,context):# 这里踩过坑别用递归Python递归深度有限而且不好调试# 用队列实现广度优先的任务展开task_queuedeque([intent])plan_steps[]whiletask_queue:tasktask_queue.popleft()ifis_primitive(task):# 原子任务可以直接执行plan_steps.append(task)else:sub_tasksdecompose(task,context)# 调用规划器拆解task_queue.extendleft(reversed(sub_tasks))# 注意顺序别反了returnplan_steps执行别让Agent“手滑”执行层是Agent和物理世界交互的接口。一个错误的执行指令可能让灯闪一下、空调乱转甚至让机器人撞墙。执行层的铁律执行前必须做“安全校验”。我写了一个“执行沙箱”每个执行指令在发出前都要经过一个校验器。比如“打开所有灯”这个指令校验器会检查当前时间——如果是凌晨3点就弹窗确认“您确定要在凌晨打开所有灯吗”如果用户不在家直接拒绝执行。执行结果必须反馈。很多Agent执行完就完了不检查结果。我习惯在执行后等待一个“确认信号”。比如控制智能灯执行后等待灯的API返回“on”状态如果3秒内没返回就重试一次重试失败就报错。别无限重试否则会出现文章开头那种死循环。执行要有“幂等性”。同一个指令执行两次结果应该和一次一样。比如“开灯”如果灯已经开了第二次执行应该什么都不做。这个逻辑最好在设备端实现但Agent端也要做一层检查——我维护了一个“设备状态缓存”执行前先查缓存如果状态已匹配直接跳过。别这样写# 错误示范不检查状态直接执行defexecute(action):device_api.send(action)# 如果灯已经开了再发一次开灯指令灯会闪一下正确做法defexecute(action,device_state_cache):current_statedevice_state_cache.get(action.device_id)ifcurrent_stateaction.target_state:log.info(f设备{action.device_id}已经是目标状态跳过执行)return{status:skipped,reason:already_in_target_state}resultdevice_api.send(action)device_state_cache.update(action.device_id,action.target_state)returnresult记忆别让Agent“失忆”也别让它“记仇”记忆模块是Agent的“持久层”但很多人把它做成了“日志系统”——只记录不查询或者全量查询。记忆的工程分类工作记忆当前会话的上下文比如用户刚才说了什么、Agent刚才做了什么。这个用内存里的字典就能搞定但要注意会话超时——我设置30分钟无交互就清空工作记忆。长期记忆用户偏好、历史行为、重要事件。这个我用向量数据库存但有个关键点记忆要有重要性评分。用户说“我喜欢暖色调”这个记忆重要性高存3年用户说“今天天气不错”这个记忆重要性低存24小时就过期。重要性评分由推理模块在写入时给出。记忆的检索别每次推理都把全部记忆丢给大模型。我写了一个“记忆检索器”根据当前输入和上下文只检索最相关的5-10条记忆。检索用embedding相似度但要注意用户说“开灯”时检索到的记忆应该是“用户上次开的是客厅灯”而不是“用户上次说了一句脏话”。这里踩过坑记忆的写入和读取要加锁。多线程环境下Agent一边在写记忆一边在读记忆读到了半条写入的记录导致推理出错。我用了一个读写锁写操作独占读操作可以并发。五个能力的协作一个真实案例我最近做了一个“会议助手Agent”它需要感知会议语音、推理用户意图、规划行动、执行操作比如发邮件、查日程、记忆用户习惯。一次完整的交互流程感知麦克风捕获到“帮我查一下下周二的会议安排”语音转文本后感知层过滤掉背景噪声比如键盘声生成事件{type: text, content: 帮我查一下下周二的会议安排, session_id: meeting_001}。推理规则引擎匹配到关键词“查”“会议安排”判定意图是“query_schedule”。大模型进一步提取参数时间下周二。推理结果{intent: query_schedule, params: {time: 2026-03-10}}。规划规划器拆解为步骤1-从日历API获取日程步骤2-格式化输出。注意这里没有步骤3因为用户没要求做其他事。执行执行器调用日历API获取到日程列表。安全校验器检查这个查询不涉及写操作直接放行。执行结果返回给规划器。记忆执行完成后记忆模块记录“用户查询了2026年3月10日的日程”。重要性评分设为中等保留7天。下次用户说“查一下下周的会议”记忆检索器会优先返回这个历史记录帮助推理模块更快理解用户习惯。个人经验性建议别追求“全大模型化”。我见过最失败的Agent所有能力都用大模型实现结果延迟高、成本高、不可控。规则引擎大模型的混合架构才是工程上最稳的。规则引擎处理80%的常规情况大模型处理20%的复杂情况。每个能力模块都要有“熔断”机制。感知层如果连续收到异常输入比如每秒100条请求直接丢弃并报警推理层如果大模型连续返回无效结果切换到规则引擎的兜底方案执行层如果设备连续无响应停止执行并通知用户。别让一个模块的故障拖垮整个Agent。日志要打全但别打太多。我习惯在每个能力模块的入口和出口打日志记录输入、输出、耗时。但别在循环里打日志——有一次我在规划器的任务拆解循环里打了详细日志结果一个复杂任务拆了200步日志文件瞬间爆了。用采样日志比如每10步打一次。测试要覆盖“边界情况”。比如用户说“把灯开到100%”但设备只支持0-80%用户说“关掉所有设备”但家里有冰箱不能关用户说“明天”但现在是凌晨0:01明天到底是今天还是明天这些边界情况写单元测试的时候就要覆盖到别等到上线了才发现。最后一条也是最重要的一条Agent的“可打断性”。用户说“停”Agent必须能立即停止当前动作。这个能力不是靠大模型实现的而是在执行层加一个“中断信号”监听器。我见过一个Agent用户说“别查了”它还在继续查因为大模型没理解“别查了”是中断指令。后来我在执行层加了一个独立的中断线程监听关键词“停”“取消”“别”一旦触发立即清空任务队列。Agent的五个核心能力说难不难说简单也不简单。关键是别把它们做成五个独立的“黑盒”而是要让它们通过标准接口协作。感知层输出事件推理层输出意图规划层输出步骤执行层输出结果记忆层输出上下文——每个模块只做自己的事但都知道其他模块在做什么。下次遇到Agent“死循环”或者“答非所问”别急着调大模型参数先看看这五个能力模块的协作链路问题大概率出在接口上。