这道题问的是大模型[[智能体]]怎么工作,说白了,就是怎么让LLM不只是一个聊天机器人,而是能自己规划、调用工具、根据反馈调整,最后完成一个复杂任务。它的本质是一个感知-规划-行动-反馈的闭环,LLM是大脑,其他模块是手和脚。
先说规划模块。这里最核心的是怎么把一个大目标拆成可执行的子任务。我常用的几个范式:[[Chain-of-Thought]]就是一步一步推理,适合数学题或者逻辑题,比如算个折扣,模型一步步算,不容易出错。[[ReAct]]呢,是推理和行动交替,模型想一步,做一步,观察结果再想下一步,适合需要跟外部交互的场景,比如查完天气再决定要不要提醒。还有[[Tree-of-Thoughts]],它会同时探索多条路径,最后选最优的,适合开放式的规划问题,比如写一个旅行计划,但代价也大。实际落地,我一般不会只用一种,而是根据任务复杂度混合着来。简单任务CoT就够了,复杂一点用ReAct,如果任务容错率低,比如金融交易,我会考虑ToT,但得控制分支数,不然延迟受不了。
再一个,记忆和工具调用。记忆分短期和长期。短期就是当前对话上下文,用[[Sliding Window]]或者摘要压缩,保证模型知道刚才说了什么。长期记忆存用户偏好、历史经验,我一般用[[向量数据库]],比如Milvus,把用户画像、常见问题都[[embedding]]进去,需要的时候检索出来。工具调用这块,关键是[[Function Calling]]机制,模型得学会什么时候调用、传什么参数。这里有个常见失败场景:模型乱调用,比如用户问“今天天气怎么样”,它去调了订外卖的API。所以上线我会特别关注两点,一是给工具的description写清楚,二是加一层校验,检查参数合法性,不然很容易翻车。
举个例子,用户说“查一下北京明天天气,如果下雨提醒我带伞”。模型先规划,拆成查天气、判断降雨、生成提醒三步。从短期记忆里知道用户在北京,长期记忆可能存了用户偏好微信提醒。然后调天气API,参数传北京和明天日期。API返回降雨概率80%,模型判断需要提醒,再调微信通知接口。如果API超时了,反思机制就触发,重试或者换备用源。这就是一个完整的闭环。
落地时有个关键点:Agent不是单次调用,而是多轮决策循环。每轮根据环境反馈调整策略,这才是智能所在。但这里有个风险:循环次数多了,累积错误和延迟都会上升。我一般会设最大轮数,比如5轮,超过就报错。另外,我会特别关注[[Reflexion]]框架,让模型在失败时回溯原因,重新规划,而不是硬着头皮继续。
还有一个有意思的点是,如果任务涉及多个工具协同,比如先查天气再订外卖,工具调用的顺序和依赖怎么管理。我倾向用有向无环图来建模工具流,而不是让模型自由发挥,这样可控性更高。
所以,我更愿意把Agent看作一个带反馈的决策系统,而不是单纯的LLM调用链。核心是规划、记忆、工具、反思四个模块的协作,但落地时一定要考虑失败场景和边界,比如乱调用、超时、累积错误,这些才是真正考验工程能力的地方。