夜雨聆风最近这两年,如果你关注 AI 领域,一定绕不开一个词——Agent(智能体)。从最早的聊天机器人,到现在能够自主规划、调用工具、完成复杂任务的智能体系统,大模型的应用范式正在发生一次根本性跃迁。
但"Agent"这个词被用得太泛滥了,以至于很多人分不清:一个套了循环的 Prompt 和真正的 Agent 系统,区别到底在哪?这篇文章想聊聊 Agent 背后真正的技术架构。
一、Agent 和普通的 LLM 调用,差在哪?
先明确一个核心区别。普通的 LLM 调用是"一问一答"式的:给一个输入,模型给一个输出,结束。而 Agent 的核心特征是自主的多步骤决策循环——它需要自己判断"下一步该做什么",而不是完全依赖人类在每一步给出指令。
一个真正意义上的 Agent,通常具备这几个能力:
规划(Planning):把一个复杂目标拆解成可执行的子任务
工具调用(Tool Use):能够调用外部 API、执行代码、查询数据库
记忆(Memory):记住之前做过什么、学到了什么
自我反思(Reflection):判断当前结果是否达到预期,决定是否要调整策略
换句话说,如果一个系统只是"LLM + if-else 判断",那它算不上 Agent;如果它能根据环境反馈动态调整自己的行动路径,这才是 Agent 的核心价值所在。
二、三种主流架构模式
1. ReAct:思考与行动交替
ReAct(Reasoning + Acting)是目前最基础也最经典的 Agent 架构模式。核心思路很简单:让模型在每一步都显式地"思考",再决定"行动",行动完之后观察结果,进入下一轮思考。
这种模式的好处是**可解释性强**——每一步思考都被显式记录,出问题很容易排查是哪一环出错。缺点是步骤多、延迟高、Token 消耗大。
2. Plan-and-Execute:先规划再执行
和 ReAct 边想边做不同,Plan-and-Execute 会先让模型一次性生成完整任务计划,再逐步执行每个子任务。
优势是减少了反复调用大模型做决策的开销,整体执行效率更高;代价是如果一开始的计划有误,后面很难灵活纠偏,除非引入"重新规划"机制。
3. 多 Agent 协作
任务足够复杂时,单个 Agent 很难兼顾所有角色。常见做法是拆分出多个专职 Agent——比如一个负责规划的"指挥官"、几个负责具体执行的"执行者"、一个负责校验结果的"审核者"——通过消息传递协作完成任务。
这种架构在处理需要多领域知识的复合任务(比如"调研 + 写代码 + 测试")时效果显著,但也带来了协调开销和调试复杂度的显著上升。
三、让 Agent "能干活" 的三个关键组件
Tool Calling(工具调用)
这是 Agent 区别于纯聊天模型最直接的能力——识别"什么时候该调用工具",并生成结构化的调用参数。现在主流大模型都原生支持 Function Calling / Tool Use 接口,模型输出不再只是自然语言,而是可以被程序直接解析执行的结构化指令。
值得一提的是,像 Anthropic 推出的MCP(Model Context Protocol)这类协议,本质上是在解决"工具接入标准化"的问题——让 Agent 不需要为每个工具单独写适配代码,而是通过统一协议连接各种数据源和服务。
Memory(记忆管理)
Agent 的"记忆"通常分两层:
短期记忆:当前任务执行过程中的上下文,受限于模型的上下文窗口长度
长期记忆:跨会话保留的知识,一般借助向量数据库做语义检索实现
工程上一个容易被忽视但很关键的问题是:任务执行越长,上下文越容易膨胀甚至超人类。所以很多生产级 Agent 系统会引入"上下文压缩"机制——比如定期把历史步骤总结成摘要,只保留关键信息。
Context Engineering(上下文工程)
这是最近一年被反复提及的概念。相比早期"写好一个 Prompt"就够用的阶段,现在工程师需要更系统地思考:每一步推理时,应该给模型喂进去哪些信息——任务描述、工具定义、历史记录、检索到的外部知识……如何组织和裁剪这些信息,直接决定了 Agent 表现的上限。
四、一个简化的 Agent Loop 实现
抛开具体框架,一个最基础的 Agent 循环大致长这样(伪代码示意):
defrun_agent(user_goal, tools, max_steps=10):
context = [{"role": "user", "content": user_goal}]
for step inrange(max_steps):
1. 让模型基于当前上下文,决定下一步该做什么
response = llm.call(context, tools=tools)
2. 如果模型认为任务已经完成,直接返回结果
if response.is_final_answer:
return response.content
3. 否则执行模型选择的工具调用
tool_result = execute_tool(
response.tool_name,
response.tool_args
)
4. 把这一步的思考和观察结果都加入上下文,进入下一轮循环
context.append({"role": "assistant", "content": response.content})
context.append({"role": "tool", "content": tool_result})
return"任务未能在规定步数内完成"
真实的生产系统当然复杂得多——需要处理工具调用失败重试、上下文超长截断、并发调用、异常兜底等等,但核心循环逻辑基本就是这几步。
五、工程实践中容易踩的坑
写过 Agent 系统的同学应该都有体会:理论简单,落地全是细节。
1步数失控:没设置合理的 max_steps 上限,Agent 可能陷入死循环,反复尝试同一个失败的操作
2.成本爆炸:每一步都是一次完整的 LLM 调用,复杂任务动辄几十次调用,Token 成本和延迟都会显著上升
3.工具调用参数出错:模型偶尔会生成格式不对或语义错误的工具参数,需要做好校验和容错重试
4.缺乏可观测性:如果没记录每一步的思考、行动、观察日志,出问题之后基本无从排查
5.上下文管理不当:任务一长,上下文迅速膨胀,既浪费成本又可能让模型"注意力"被无关信息稀释
写在最后
从"一问一答"的聊天机器人,到能够自主规划、调用工具、多步执行的 Agent 系统,这不只是一次产品形态升级,更是大模型应用工程范式的转变——工程师需要开始像设计一个"具备决策能力的系统"一样去设计 Prompt、工具、记忆和上下文,而不只是写好一段指令。
这条路还远没有走到终点,评估方法、安全边界、成本控制,每个方向都还有大量工程问题等待解决。但可以肯定的是,"能干活"的 Agent,才刚刚开始展现它的潜力。
*如果这篇文章对你有帮助,欢迎转发给同样在做 AI 应用开发的朋友。