小语言模型 Agent 设计模式

可视化演示

展示SLM Agent核心架构：任务分解策略（顺序/层级/DAG）、工具调用编排与双层记忆管理、ReAct多轮规划循环及端侧量化部署优化。

架构总览

小餐馆没有专职服务员、没有大厨、没有库管，只有一个老板。他一会儿站在门口迎宾，一转身又去炒菜，抽空还要打电话给菜贩子订货。一个人，顶起了所有角色。SLM Agent 的架构，就是这样一个“一个人撑起整家店”的精巧安排——我们不用又大又重的模型，而是让一个小模型在几个角色之间来回切换。

技术上讲，一个基于 SLM 的 Agent 在架构上通常由四个核心角色组成：规划器（Planner）负责把用户需求拆成步骤；执行器（Executor）负责调用工具、执行动作；记忆模块（Memory）负责记录任务进度和用户偏好；观察与反思器（Observer）负责读取工具返回的结果，判断下一步。SLM 自身只做“思考”这一件事，行动全交给工具与代码。这是它的职责边界：模型是大脑，不是手脚，更不是仓库。

由于 SLM 的上下文窗口小、推理能力有限，设计上要把握三条原则：一是轻量优先，先搭一个“最小可用”的闭环——规划、行动、记忆三件套跑通即可，每加一个组件都要算算开销；二是高内聚低耦合，每个角色各管一摊，老板不会一边炒菜一边记账导致手忙脚乱；三是可降级，模型拿不准时就调用工具或规则兜底，而不是硬猜。所以记住，SLM Agent 的本质不是“一个更聪明的小模型”，而是一套“让不聪明的模型做聪明事”的流程设计。

任务分解

一天，婚宴的订单来了：三十桌酒席。小老板不会站在灶台前发懵，他翻开菜单，把宴席拆成“凉菜、热菜、汤品、点心、酒水”几道工序，每一道再拆成更细的操作：先切配、再烹制、后装盘。任务分解，就是老板的那本“拆单本”。

技术上的任务分解（Task Decomposition），是让 SLM 把一个高层目标改写成一串有顺序的子任务序列。子任务要满足三个要求：可执行（每一步 SLM 或工具都能完成）、有依赖（前一步的输出喂给后一步）、粒度适中（步骤太多容易累积错误，太少则单步难度过高）。与此同时，每完成一个子任务就对进度做一次追踪和记录，这样任务中断后可以从断点续跑，而不是从头再来。

从概率视角看，整件任务的成功概率是各子任务成功概率的条件乘积：

因此，好的任务分解会在“步骤数量”和“单步难度”之间找平衡：步骤太多，概率越乘越小；步骤太少，每一步都超出 SLM 的能力范围。小老板的智慧，在于把大订单切成一口能吃下的分量。

工具调用

小老板再能干，也变不出食材。他要靠菜刀切菜、靠灶火加热、靠电话向菜贩子订货。这些“外挂”就是他的工具。SLM 也一样——小模型不懂时间、算不准数学、查不了实时天气，但它知道该找谁帮忙。

技术上的工具调用（Tool Calling / Function Calling），包括四个环节：工具注册（告诉模型“我有哪些工具可用，参数长什么样”）、参数解析（把自然语言中的信息翻译成工具要求的结构化参数）、调用映射（从众多工具中选出正确的那把“刀”）、结果校验（检查工具返回的内容是否合理，为下一步规划提供依据）。

SLM 如何决定用哪个工具？模型会为每个候选工具算出一个匹配分 z_k，再通过 softmax 转换成一个概率分布：

聪明的小老板不会亲手剁每根葱，他把刀磨快、把电话本备齐，然后吩咐工具去干。工具调用，就是 SLM 的“手和脚”，替它完成那些它不擅长、却能准确描述的力气活。

记忆管理

小老板的记性其实很差，但他口袋里有一本皱巴巴的笔记本：正面记着今天做了哪些菜、做到哪一步，反面记着隔壁王先生不要香菜、李太太喜欢少油。这本笔记本，就是他的“外挂大脑”。

技术上的记忆管理（Memory Management）分为四层：工作记忆存当前任务的上下文（比如正在烹饪哪道菜）；长期存储保存跨会话的用户偏好；状态缓存记录子任务的执行进度与中间结果；记忆衰减意味着长期不用的记忆逐渐模糊，避免笔记本越写越厚却全都没用。

记忆的“模糊”，在形式上可以用指数衰减来描述。一条记忆的强度，会随着时间推移按固定速率衰减：

记忆让 SLM Agent 从“每次都从零开始”变成“越用越顺手”。老板的笔记本越记越聪明，Agent 的记忆越攒越贴身——这正是端侧智能体最打动用户的温情之处。

多轮规划

炒菜不是把菜倒进锅就完事。小老板要边炒边尝，咸了加水，淡了加盐，火大了赶紧关小——计划永远在给现实让路。这就是多轮规划：不是一次想清楚所有动作，而是边做边看、边看边改。

技术上的多轮规划，最经典的落地方式是 ReAct 循环：规划一条行动，执行这个行动，观察返回结果，再基于新观察到的情况规划下一步。SLM 每走一轮，都在更新自己对任务状态的认知。形式上，每一轮的内部状态可以写成迭代更新公式：

多轮规划还有两个关键：动态调整——如果观察结果与计划不符，就修订后续步骤；终止条件——要么目标达成，要么轮数或预算达到上限，避免一个任务无限空转。老板不可能永远站在灶台前翻滚，菜熟了就得出锅。

端侧部署

小餐馆的厨房只有两个平方，塞不下大饭店那种三层炉灶。老板的全部家当，必须在这公小的空间里安排得明明白白。SLM 的端侧部署，就是这么一间“袖珍厨房”。

技术上的端侧部署要面对三重约束：资源预算（手机、音箱的内存通常在 1-2GB 内，模型和运行时只能占一个小头）；模型量化（把 FP32 的权重压缩成 INT8 甚至 INT4，用精度换体积与速度）；延迟约束（单步推理要控制在几十毫秒量级，否则用户等不起）。此外还要考虑离线兜底——没网的时候，用规则系统完成基础应答。

端到端的延迟可以建模为每一步推理延迟与工具调用延迟的总和，它必须落在预算 B 之内：

端侧部署的精髓是“小厨房里也要出大菜”——通过量化把模型塞进设备，通过流水线把延迟压到最低，让 SLM Agent 在没有云端的角落里也能操持起一桌好饭。

优化评估

生意做得好不好，老板心里得有一本账：回头客比例高不高？一道菜平均多久能上桌？每桌的食材成本超不超支？同样，SLM Agent 的好坏，也要靠指标和实验来度量，而不是凭感觉。

技术上的评估指标主要有三类：成功率（任务完成率，即成功任务数除以总任务数）；延迟（P95 延迟，衡量最差情况下的用户等待）；成本（token 消耗量与工具调用次数，直接影响端侧的电量和流量）。综合起来，可以设计一个加权综合评分：

评估不是终点，迭代才是。老板每周都要翻账本：哪些菜客人常点？哪道工序老出岔子？Agent 团队也一样——收集失败样本，针对高频错误做提示词调优或模型微调，让这本“生意经”越翻越亮。

AI 应用场景

Python 演示

import jsonfrom datetime import datetime  def mini_slm(request: str, memory: list, observation: str = "") -> list:    """超小模型模拟器: 把用户请求规划成动作序列(ReAct).    真实SLM用权重做推理, 这里用规则模拟其规划输出.    """    text = request.lower()    if observation and "带伞" in observation:        return [{"action": "add_event", "param": {"title": "带伞提醒", "slot": "明日早上"}}]    if "天气" in text:        return [{"action": "query_weather", "param": {"city": "local"}}]    if "闹钟" in text or "提醒" in text:        return [{"action": "set_alarm", "param": {"hour": 7, "minute": 30}}]    return [{"action": "add_event", "param": {"title": text, "slot": "明日"}}]  def query_weather(city: str) -> str:    return "多云, 早晨降水概率65%, 建议带伞"  def set_alarm(hour: int, minute: int) -> str:    return "已设置闹钟 %02d:%02d" % (hour, minute)  def add_event(title: str, slot: str) -> str:    return "已记录日程[%s]: %s" % (slot, title)  TOOL_MAP = {    "query_weather": query_weather,    "set_alarm": set_alarm,    "add_event": add_event,}  class SlmAgent:    def __init__(self):        self.memory = []      # 记忆列表: 每条含text, strength, time        self.max_steps = 4     def _decay(self):        for item in self.memory:            item["strength"] *= 0.9     def _remember(self, text: str):        self._decay()        self.memory.append({            "text": text,            "strength": 1.0,            "time": datetime.now().isoformat(),        })     def run(self, request: str):        print("[用户] " + request)        observation = ""        for step in range(1, self.max_steps + 1):            plan = mini_slm(request, self.memory, observation)            if not plan:                break            last_result = ""            for item in plan:                action = item["action"]                param = item["param"]                if action in TOOL_MAP:                    last_result = TOOL_MAP[action](**param)                    self._remember(last_result)                    print("[第%d轮][动作] %s -> %s" % (step, action, last_result))                else:                    print("[第%d轮][兜底] 未知工具%s" % (step, action))            if "带伞提醒" in last_result:                print("[第%d轮][完成] 天气已查, 带伞提醒已设" % step)                break            observation = last_result        strong = len([m for m in self.memory if m["strength"] >= 0.5])        print("[记忆] 条数=%d, 强度>=0.5条数=%d" % (len(self.memory), strong))  if __name__ == "__main__":    agent = SlmAgent()    agent.run("明天早上去公园, 看看天气并提醒我带伞")

1. plan = mini_slm(request, self.memory, observation)小模型输出本轮规划的动作序列，对应任务分解
2. return [{"action": "query_weather", "param": {"city": "local"}}]把“查天气”拆成一个可执行的子任务
3. if observation and "带伞" in observation:基于上一轮观察结果规划本轮动作，即多轮反馈
4. last_result = TOOL_MAP[action](**param)工具调用映射，按注册表把动作名换成真实函数并展开参数
5. self._remember(last_result)记忆写入，保存工具返回结果
6. item["strength"] *= 0.9记忆衰减，旧的记忆强度每轮乘 0.9
7. if "带伞提醒" in last_result:观察判断任务目标已达成，提前终止循环

常见误区

面试题