常驻 Agent 是现在聊得最多的方向之一但真正能把它讲明白的内容反而不多。最近听了一场内部技术讲座主题就是“拆解常驻 Agent 的四层内部构造”讲师把看似玄乎的常驻式智能体分成接入感知、规划调度、工具执行、记忆状态四层一层一层往下拆听完之后我对整个体系的边界感清晰了很多。我自己之前用不同方式搭过类似系统踩过不少坑结合讲座的框架我把完整拆解和实操过程整理成这份笔记希望给你做常驻 Agent 提供一份能直接上手的参考。1. 整体设计思路常驻 Agent 到底难在哪1.1 常驻和单次问答是两种完全不同的形态很多团队刚开始做常驻 Agent容易把它当成“套了壳的聊天机器人”觉得把模型 API 接上、丢一句话进去就能跑。但真实做下来会发现常驻和单次问答差得非常远。单次问答是典型的请求-响应模型用户发一条消息系统交给大模型大模型生成回答返回后整个交互就结束了。状态是临时的上下文是一次性的出问题重试一次就行。常驻 Agent 不一样。它需要长期运行在某个环境里可能是企业群、运营后台、智能硬件甚至是一台无人值守的服务器。它不能等着用户每次来敲它而是要主动监听事件、按规则唤醒、跨会话记住状态、在无人干预的情况下连续执行多步操作。讲座里有一句话我印象很深常驻 Agent 本质上是一个“有状态的生命周期管理”问题而不是一个“提示词优化”问题。这带来三个必须处理的难点状态不能丢。Agent 干活干到一半进程重启了它必须能恢复之前的任务进度而不是像个失忆的人一样重新开始。成本必须可控。常驻意味着它可能每秒钟都在接收事件如果每个事件都丢给大模型处理账单会瞬间爆炸。唤醒必须克制。不是所有信号都值得响应常驻 Agent 必须有能力区分“真正需要它出现”和“只是路过打了个招呼”。我在早期项目里就吃过亏把所有消息都无脑转发给模型结果一周下来大量消耗都花在“你好”“在吗”这种消息上真正有用的任务反而被淹没。听完讲座再回头看问题就出在少了一层“接入感知”的过滤。1.2 为什么要把内部拆成四层常驻 Agent 如果只是一个死循环加一个模型调用代码结构会非常混乱。今天加个消息来源明天加个定时任务后天再调一个外部接口很快所有逻辑都会缠绕在一起改一处崩三处。讲座给出的思路是分层把不同职责拆到四个独立的层级里层与层之间通过定义好的接口通信。这样做有几个直接好处故障定位快。哪一层出问题直接看哪一层的日志不用在一坨代码里翻。能力替换灵活。今天用一个模型明天换另一个模型只要规划层的接口不变替换成本就很小。权限边界清楚。工具层统一管理外部操作读文件和发消息的权限能分开控制安全方面更好交代。四层之间的依赖关系是单向的接入感知层拿到原始事件转成内部结构化的任务交给规划调度层规划调度层拆解任务生成步骤交给工具执行层去落地执行过程中产生的中间结果和最终结论统一沉淀到记忆状态层。下次再触发任务时记忆层会把相关上下文送还给接入层和规划层形成一个闭环。这个闭环最核心的设计点在于每一层都不需要知道其他层的内部细节。感知层不关心规划层用什么模型执行层不关心记忆层存的向量是什么格式这样团队才能并行开发也方便在不同场景里只抽取其中两层来用。2. 常驻 Agent 四层构造逐一拆解2.1 第一层接入感知层解决“听得到、听得清”接入感知层是常驻 Agent 的入口也是最容易被低估的一层。很多人以为入口就是一个消息接口实际上常驻场景里的输入源极其多样群聊消息、私聊消息、定时任务、外部系统回调、邮件、甚至硬件上报的事件都需要在这一层汇合。讲座里强调了一个关键动作叫“事件归一化”。不同输入源的格式完全不一样群聊消息可能是带sender、group_id的 JSON定时任务是{type: cron, schedule: ...}外部接口回调可能是{action: user_created, payload: {...}}。如果让上层直接面对这些五花八门的格式规划层就没法写通用逻辑。所以这一层要做的事就是把这些来源全部解析成统一的事件对象。事件对象大概长这样{ event_id: msg_20250101_001, source: group_chat, trigger_time: 1735689600, session_id: group_123, user_id: user_456, intent_hint: query, content: 帮我查一下这个订单的状态, raw: {} }有了统一事件对象上层逻辑就不需要关心消息到底从哪个渠道来的。除了归一化这一层的另一个关键是“唤醒判断”。常驻 Agent 不可能每个事件都触发一次完整的大模型调用否则成本会失控。比较务实的做法是做一个多级唤醒机制先走规则过滤比如消息里是否含有关键词、是不是被 、事件类型是不是任务类规则兜不住的再走一个轻量级小模型做意图预判小模型只输出“唤醒/不唤醒/不确定”三类结果。讲座里特别提醒了一个平衡问题唤醒策略不能太灵敏否则 Agent 会天天被无效消息吵醒也不能太迟钝否则用户会觉得它像个摆设。我的经验是初期尽量用保守的唤醒规则宁可多漏几次先把成本和稳定性跑通再逐步加小模型预判把召回率提上去。2.2 第二层规划调度层解决“先做什么、后做什么”接入层把事件交给规划层之后常驻 Agent 才真正开始“动脑”。规划层的职责不是直接回答用户而是把目标拆解成可执行的步骤。举个例子用户发来一句“帮我汇总本周的销售数据并发我邮箱”。如果直接丢给大模型生成文本模型可能会“假装”调用了某个工具但实际上什么也没发生。正确做法是让模型先理解目标然后输出一个步骤序列读取本周销售数据按渠道和品类做汇总计算生成报告内容调用邮件工具发送。规划层要专门维护一个“行动列表”数据结构每个步骤包含工具名、参数、状态和依赖关系。讲座里把这种模式叫做“边做边计划”不是让模型一次性把所有步骤都列完而是每执行完一步把结果喂回规划层让它根据实际结果决定下一步怎么走。这个设计有一个很现实的考量外部系统的返回是不可预测的。你以为第一步能顺利拿到数据结果权限没开、接口超时如果不根据中间结果重新规划后面的步骤全得白跑。我记得自己第一次做的时候偷懒让模型一次性生成完整 JSON 计划结果十次里有四次第一步就失败整个任务直接卡死。后来改成边做边计划失败率降了很多。规划层还涉及一个特别实际的问题模型路由。常驻 Agent 不是只用一个大模型而是要根据任务复杂度做分流。简单的“查天气”“设置提醒”走轻量级模型响应快、成本低复杂的“分析报表”“写周报”再走能力更强的大模型。这个路由判断通常也放在规划层通过任务类型、上下文长度、预估难度来选路。还有一点很关键规划层必须设置“终止条件”。常驻 Agent 在无人值守时最怕陷入无限循环。比如模型觉得“上一步结果不够好”一遍遍重试重试到资源耗尽。常见的做法是限制最大执行步数跑完步数还没成功就直接停止或者设置一个“置信度阈值”只有结果评分超过阈值才认为任务完成。2.3 第三层工具执行层解决“真正把事做了”规划层拆出步骤之后真正干活的是工具执行层。这一层本质上是常驻 Agent 的“手和脚”它连接着所有外部系统发消息、查数据库、操作文件、调用业务接口。工具执行层在设计上有一个核心原则工具的调用权限和执行逻辑必须集中管理不能散落在各种提示词里。什么意思呢如果工具描述是写在系统提示词里的一段文字模型理解可能出错如果每次执行都要通过模型“自由发挥”来构造 API 请求那出错率会高得离谱。更稳的做法是把每个工具定义成一个结构化条目包含名称、功能描述、入参格式、权限级别、回调函数type Tool { name: string; description: string; schema: Recordstring, any; riskLevel: read | write | dangerous; execute: (args: any, context: RuntimeContext) Promiseany; };模型在规划层只负责输出“我要调query_sales这个工具参数是date_from: 2025-01-01”真正的参数校验和请求构造在工具层用代码完成。这样即使模型对参数的描述不够精确工具层也能用规则去补全或二次校验。讲座里特别强调了三个工具执行层的工程化细节幂等。外部操作最怕重复执行。发邮件也好、下工单也好如果因为网络超时导致重试很可能会重复创建记录。所以每个执行任务都要带一个唯一请求 ID外部系统要支持按这个 ID 去重。超时控制。每个工具调用必须有超时时间不能让它无限挂起。一个外部接口如果 10 秒没返回直接按失败处理回传给规划层去决定是否重试或换方案。结果提炼。工具返回的原始结果可能很大比如查询返回一万行数据。不能把这一万行全丢回给模型而应该在工具层先做摘要、统计或过滤只把关键结论反馈给规划层。这样做既省 token又能减少模型被无关信息干扰。权限管理也是工具层的重点。不同的工具应该分成只读、写操作、危险操作三个级别危险操作比如删除数据、对外发送敏感内容必须走二次确认机制。我在实际项目中还加了一个“人工审批通道”遇到危险工具调用先把工单推给负责人审批通过后才真正执行效果很好。2.4 第四层记忆与状态层解决“下次还能接上”前几层解决的是“当前这个任务怎么完成”记忆层解决的则是“下一次我还记得你是谁、你之前干什么”。没有记忆层的常驻 Agent就像一个每次见面都假装不认识你的客服体验非常差。讲座把记忆分成了三类我觉得这个划分特别实用短期记忆。指当前会话的上下文比如这一轮对话里的最新几条消息、当前正在执行任务的时间线。这通常直接放在工作内存里拼接给规划层用。工作记忆。指当前任务的状态数据比如“任务进行到第三步第一、二步已完成”这个必须实时维护并且支持持久化。长期记忆。指跨会话的持久化事实比如用户的偏好、历史订单、很久以前的决定这些会用向量数据库存储检索时按相关性取回。长期记忆的写入和检索都有讲究。写入方面不能每轮对话都往长期记忆里写那会存下大量垃圾信息。比较稳妥的触发时机是任务完成时、发现新事实时或者明确收到“记住/以后都这样”的指令时。写入之前最好做一个压缩把对话记录提炼成简短的陈述句再存进向量库。检索方面核心是“按需取回不搞全量大杂烩”。每次唤醒 Agent 时根据当前事件提取关键词和实体去向量数据库里检索相关记忆最多取回十几条就够了。取回的旧记忆会和当前上下文拼在一起再交给规划层。要注意防止一个陷阱如果旧记忆和当前任务没有关系宁可不要强行拼接否则模型会被陈年旧账干扰输出质量直线下降。记忆层还有一个稍微冷门但很重要的工作状态恢复。常驻 Agent 被杀进程、重启、重新拉起后工作记忆要能从持久化存储里恢复继续执行到一半的任务。实现上其实不复杂每隔一段时间把工作记忆序列化存到 Redis 或数据库里启动时检查一下有没有 un finish task有就接着跑。但就是这步最容易被漏而我第一次上线时恰恰就漏了导致 Agent 重启后完全失忆被用户吐槽了整整一个下午。3. 实操过程搭建一个精简的四层常驻 Agent3.1 极简运行循环先跑通理论归理论真正动手时我建议别一上来就追求完美架构。先拿一个极简的主循环跑通全链路再逐层完善。核心循环用伪代码表示大概是这样async function mainLoop() { while (true) { const event await eventSource.waitEvent(); if (!shouldWake(event)) continue; const context await memory.buildContext(event); const plan await planner.createPlan(context); for (let i 0; i plan.steps.length; i) { const step plan.steps[i]; const result await executor.run(step.tool, step.args); const feedback executor.summarizeResult(result); const revised await planner.observe(feedback); if (revised.isDone) break; plan.steps revised.steps ?? plan.steps; } await memory.commit(context.sessionId, plan); } }这个循环的骨架非常精简但已经包含了常驻 Agent 最核心的四层动作等待事件对应接入感知层唤醒过滤避免无脑消耗调用规划层生成任务序列逐步执行并随时把中间结果反馈回去最后把任务结果写入记忆层。我第一版跑通花了不到一天因为每一层都只做最基础的事事件源用轮询规划层直接用现成模型接口做文本输出工具层只有一个发消息函数记忆层甚至只是临时文件。全链路再怎么简陋先把“循环能转起来”这个目标实现后面优化才有锚点。实际在部署时主循环还必须考虑并发问题。常驻 Agent 处理的往往不是一个会话而是同时几十个会话。如果只有一个循环某个慢工具调用会卡住所有会话。所以生产环境里更合理的做法是每个会话或任务一个轻量级协程前端统一接入后端轮询各自的状态。3.2 事件归一化和上下文构造接入感知层最值得先写的是“事件归一化”因为它是所有逻辑的入口基础。我把事件源抽象成一个统一的EventSource接口这样后续加新的数据源只需要新写一个实现不用动主循环。interface EventSource { listen(callback: (rawEvent: any) Promisevoid): void; } class WebhookSource implements EventSource { listen(callback) { httpServer.on(request, async (req, res) { const raw await parseBody(req); await callback(raw); res.end(ok); }); } } class CronSource implements EventSource { listen(callback) { cron.schedule(*/5 * * * *, async () { await callback({ type: cron_tick, ts: Date.now() }); }); } }归一化逻辑会在回调里完成字段映射把不同来源的消息统一成同一个事件对象。这一步看起来像纯粹的体力活但很容易踩坑某个来源的字段名可能不是sender而是from_user某个来源的时间戳可能是字符串而不是数字。所以归一化不只要改字段名还要做类型强转、字段缺失兜底和异常事件丢弃。在做上下文构造时我会从记忆层取三类信息当前会话最近几轮消息、当前任务的中间状态、长期记忆里的相关事实。拼接成一块上下文传给规划层。这里需要注意一个点不要在上下文里堆太多和当前事件无关的内容。拼接原则是“宁缺毋滥”每多一条无关记忆模型被干扰的概率就大一分。3.3 工具注册表与执行流程工具层的实现核心是注册表模式。把所有工具注册到一个 Map 里规划层要用哪个直接按名字取。const tools new Mapstring, Tool(); tools.set(send_message, { name: send_message, description: 发送一条消息给指定用户或群, schema: { to: string, content: string }, riskLevel: write, execute: async (args) callIMApi(args.to, args.content) }); function findTool(name: string): Tool | undefined { return tools.get(name); }执行器要解决的问题主要是三块参数校验、权限核验、重试策略。参数校验根据 schema 检查类型和必填项权限核验看风险级别是 read 还是 write 还是 dangerous重试策略则分成幂等重试和不可重试两类只有带唯一请求 ID 的操作才允许重试避免重复执行带来的脏数据。我自己项目里常用的权限配置方式是工具描述里标准化riskLevel在“执行前”统一经过一个permissionGuard这个守卫会检查当前会话是否已获得使用该工具的授权。没有授权时危险工具直接转到审批队列等待人工在管理界面确认。结果提炼也在这里做比如查询库存接口返回了 500 行数据我先在代码里统计出“总量、库存紧张品类、前五缺货清单”再把这几条摘要回传给规划层。模型看到的是经过加工的信息而不是原始数据流生成的能力才会更精准。3.4 部署时容易忽略的三个工程事项日志结构化。常驻 Agent 运行时间长跨层调用多日志一定要带event_id、session_id、tool_name否则出了问题想追链路根本没处下手。进程守护和优雅退出。系统要支持在收到终止信号时先保存工作记忆再停止监听避免正在进行的任务被硬砍。状态持久化间隔。不能每执行一步都写盘也不能完全不写。按任务阶段来写比较合理任务开始、每个工具执行结束、整个任务完成时各写一次。这些在演示项目里可以偷懒但一旦放到线上跑每一项都决定你能不能睡个安稳觉。4. 常见问题与排查技巧实录4.1 Agent 一直不响应怎么回事最常见的排查方向是接入感知层的唤醒判断把真正该处理的消息过滤掉了。比如我项目里某次只响应带特定前缀的消息结果用户发了一句非常自然的“帮我查下订单”没带前缀Agent 毫无反应。另一个隐蔽原因是事件归一化时时间戳解析出错事件被当成“过期事件”丢弃。排查这类问题我会先在接入层打一条包含event_id的日志再看是否进入shouldWake的命中分支。用这个方法可以区分是“事件没进来”还是“事件被过滤”。4.2 Agent 反复执行同一个工具这个问题我看到过太多次。场景是调用外部接口时超时了规划层判断“没成功”然后重试但其实外部那边已经执行成功只是响应没回来。重复下工单、重复发通知、重复扣款都是这么来的。解决办法分两层执行层加幂等键每次调用生成request_id外部系统按这个 ID 去重规划层则要设置单步最大重试次数比如同一个工具最多重试两轮两轮还没拿到明确结果就放弃而不是无限循环。不要相信模型自己会“发现已经执行过了”模型根本没这个判断力。4.3 上下文被记忆污染模型总是跑偏这个坑也很典型。Agent 本来在处理用户查订单的请求结果从长期记忆里捞了一条两个月前的闲聊记录拼进上下文后模型忽然开始回答和订单无关的内容让人哭笑不得。排查思路是把所有拼进上下文的记忆都打上“来源标记”比如memory_source: long_term。一旦发现模型跑偏马上检查来源标记看是不是有劣质记忆混进来。更彻底的治理方法是在记忆写入侧做质量门槛太短的、信息含量低的、和已有记忆重复的直接不写入。宁可长期记忆少一点也不要脏一点。4.4 排查速查表现象可能原因排查方法Agent 不响应唤醒策略过严/事件源未接入检查shouldWake分支日志执行结果和外部实际不一致超时但外部已成功查看外部接口调用记录核对request_id模型重复尝试相同操作缺少终止条件检查最大步数和重试次数限制回答内容偏离主题记忆上下文污染检查上下文里的来源标记进程重启后任务丢失工作记忆未持久化查看启动时是否恢复未完成任务某次调用导致整个 Agent 卡死缺少工具超时控制给所有工具调用统一设置超时排查这种事最忌讳靠猜。所有问题都要落到日志和调用记录上每次调外部接口都要记录入参、出参、耗时、结果这样出问题时才能快速定位到哪一层。5. 不同场景下的四层取舍并不是所有常驻 Agent 都需要完整实现四层。讲座里有一句话说得非常准确架构是选择题不是必选题。不同场景要重点投入的层不一样。如果是个人助理类常驻 Agent比如帮你定时整理待办、汇总邮件、提醒日程最重要的层是接入感知层和记忆层。感知层要把邮件、日历、聊天各种来源统一收进来记忆层要长期保存你的习惯和偏好规划和工具都相对简单。如果是运维巡检类 Agent它每天半夜自动检查系统状态、发现问题、尝试修复最重要的层是规划调度层和工具执行层。规划层要能根据异常类型生成不同的处置方案工具层要能把各种运维命令封装成安全可控的动作权限和幂等是重中之重。如果是客服问答类 Agent它常驻在客服工作台里帮人查数据、写工单那记忆层和规划层需要重点做。客服场景里面临大量相似但不同的历史案例记忆检索能力直接决定回答质量规划层则要能判断“这个问题是直接答还是先查系统”。我给不同场景总结了一个简单的侧重表场景第一优先层第二优先层主要取舍个人助理记忆层接入层偏重个性化容错要求中等运维巡检工具层规划层偏重稳定性错误容忍度低客服工作台记忆层规划层偏重准确率需快速定位历史记录运营日报机器人接入层工具层偏重数据汇总流程轻松固定如果你刚起步我的建议是不要一上来就完整上四层。先从你可能最痛的那一层开始做跑上一周你就会发现其他层的瓶颈在哪儿。比如你现在最痛的是“每天收到太多无关消息”那就先做接入感知层的唤醒过滤最痛的是“第二天完全想不起昨天聊了什么”那就先做记忆层的长期存储。按需推进比一开始画一个宏大架构要实际得多。最后再分享一个个人经验不要迷信某一种分层方案也不要把讲座里的四层当成教条。架构的目的是让系统可控、可扩展、可维护只要能达到这些目标你这方案完不完美并不重要。我最后做出来的版本严格说也不是纯四层而是在接入层前面加了一个清洗模块在记忆层后面多了一个报表模块但骨架依然是那四条线。有了这四条线项目里每个人都知道出了问题该去哪一层找原因这就已经值回票价。