这道题其实是在问,我们怎么让大模型从被动回答问题变成主动解决问题。传统LLM你问一句它答一句,但[[Agent]]不一样,它是一个自主决策的循环:规划、推理、行动、观察,然后根据观察结果再规划,直到任务完成。这个循环里最关键的,一个是推理范式,一个是工具调用。
先说推理范式,最常用的是 [[ReAct]],就是让模型边想边做。你问它一个复杂问题,它会先想一个计划,然后调用工具去查,看结果,再想下一步。这和[[Chain-of-Thought]]不一样,CoT是纯思考,适用于数学题那种封闭问题;而ReAct更适合开放场景,因为它的思考会指导行动,行动的结果又会修正思考。实际落地时,我通常会把两者结合,简单推理用CoT,涉及工具交互的用ReAct。
再一个就是工具调用,也就是 [[Function Calling]]。模型生成一个结构化的调用指令,比如search_order(order_id),系统执行这个函数,把结果返回给模型,模型再综合回答。这个机制依赖模型本身的能力,如果模型不支持原生Function Calling,就得靠Prompt工程来模拟,但稳定性会差不少。这里有个坑:工具调用的参数很容易出错,比如订单号传错格式,或者工具返回的结果太长把上下文撑爆了。所以上线前我会特别关注参数校验和结果截断。
说到架构,现在主流是单Agent和多Agent两种。单Agent适合简单任务,比如查个天气。复杂任务我会倾向多Agent分工,一个负责规划,一个负责执行,一个负责验证。比如Devin那种,它内部有多个Agent合作完成软件开发。但多Agent的挑战是协调和成本,每个Agent都要消耗token,而且Agent之间沟通可能有信息丢失。所以我的取舍是:任务够复杂才用多Agent,否则单Agent加ReAct循环就够了。
典型场景我重点讲智能客服。传统客服是人工查订单,或者用关键词匹配。用Agent之后,用户说“我退款没到账”,Agent可以自动调用订单查询工具,查退款状态,如果显示已处理,再调用支付工具查流水,最后定位到银行延迟,然后给用户解释。这个过程中Agent的价值在于端到端自主处理,不用人工介入。但前提是工具接口稳定,而且Agent有清晰的权限边界,不能让它调用删除订单这种危险操作。常见失败场景是Agent在工具调用循环里出不来,比如查一次失败就反复查,白白浪费token。我会给循环加一个最大步数限制,超时就让步给人工。
还有一个方向,就是Agent的记忆管理,尤其长期记忆。现在很多方案用[[向量数据库]]存历史经验,但怎么在记忆里检索到最相关的信息,同时避免记忆污染,这是个值得深入的问题。
所以整体来说,我会把Agent看作大模型从知识问答走向任务执行的关键一步。它不是万能的,稳定性、成本和安全性都是落地必须解决的问题。我的选择是,先在小场景里跑通ReAct加单Agent,验证价值,再逐步扩展。