这道题其实是在问,如果我们想让一个系统自主完成复杂任务,它需要具备哪些底层能力,以及这些能力怎么协同工作。我的理解是,可以拆成五个模块,形成一个从感知到反思的闭环。
先说感知,它是决策的天花板。如果感知错了,后面全错。比如用户说“给我退钱”,但没说哪个订单,系统就得主动追问或从上下文推断。规划呢,更像导航仪,把目标拆成子任务。但环境会变,所以规划必须支持动态重规划。比如用户中途改主意,系统要能回溯调整。这里我倾向用 [[ReAct]] 范式,把推理和行动交织起来,而不是先规划再执行。
再一个就是记忆。记忆分三层:工作记忆就是当前窗口,短期记忆存会话上下文,长期记忆存用户画像和历史偏好。比如用户是金卡会员,那系统在推荐航班时就要优先考虑东航。但长期记忆不能无限制存,得靠[[向量库]]加过期策略。如果记忆太杂,反而会干扰决策。
工具调用是让系统突破模型本身知识边界的关键。通过 [[Function Calling]] 调用外部API,比如查航班、比价、下单。这里有个坑,工具描述必须标准化,不然模型可能选错工具。而且调用失败要有重试机制,不能直接报错。
执行和反思形成闭环。执行后观察结果,评估进度,失败了要反思。比如系统查完价格发现超预算,就得反思是不是规划错了,然后回退修改条件。
举个例子,订单退款场景。用户说“我买错了,要退款”,系统先感知意图和订单号,然后调记忆看用户历史退款情况,再规划子任务:查订单状态、检查退款规则、执行退款。如果退款失败,比如订单已发货,系统就得反思,然后规划替代方案,比如转退货流程。
落地时有个前提:工具调用的错误处理必须健壮,否则系统容易卡死。我上线会特别关注重试次数和超时设置,避免死循环。如果感知不充分,比如用户没说订单号,系统得主动追问,而不是瞎猜。
所以我的取舍是,记忆和规划是核心。记忆决定了系统有没有“记性”,规划决定了它能不能灵活应对变化。但两者有冲突,规划越深,记忆消耗越大。实际中我会根据任务复杂度做权衡,简单任务用轻量规划,复杂任务用分层规划加长短期记忆。
另外,如果任务涉及多轮交互,比如用户中途改需求,那系统的记忆管理就特别关键。怎么在保持上下文的同时避免信息过载,这是个值得深挖的点。