说实话，"Agent"这个词我听了快两年了。每次觉得搞懂了，过一阵又模糊。不是概念难，是这词被用得太泛——从"帮你补全代码的 Copilot"到"自己规划任务自己执行的全自动系统"，都叫 Agent。
所以我想从头理一遍：从一个最朴素的起点开始，看看 Agent 到底是怎么一步一步"长出来"的。不是为了下定义，是为了给自己一个能站得住的理解。
起点：模型只会说话
最早的 LLM 就是聊天——你问它答，它不会"做"任何事。你可以让它写文章、翻译、总结，但它没法帮你发一封邮件、查一个数据库、执行一段代码。
这时候的模型像一个非常聪明但被困在玻璃房子里的人。它能给你建议，但你得自己动手。
改变的第一步是 Function Calling。
Function Calling：模型第一次"伸出手"
2023 年 OpenAI 开放了 Function Calling。简单说，模型可以输出一个结构化的 JSON，告诉你"该调这个函数，参数是这些"。
比如你问"今天上海天气怎么样"，模型不再编造一个答案，而是输出：
{"name": "get_weather", "arguments": {"city": "上海"}}然后你的代码拿到这个 JSON，去调真正的天气 API，把结果再喂回模型，模型最后给你一句"上海今天 32 度，晴"。
第一次用的时候确实有点兴奋——模型终于能"动手"了。但很快我发现一个问题：这只是单轮的。模型调一个函数，拿到结果，回答，结束。如果任务需要连续调好几个工具呢？如果中间某步失败了需要调整呢？
Function Calling 解决了"模型能不能动手"的问题，但没解决"模型会不会规划"的问题。
ReAct：模型开始"边想边做"
然后是 ReAct（Reasoning + Acting）。这个模式的核心是一个循环：
- Thought：模型先想"我应该做什么"
- Action：调用一个工具
- Observation：看工具返回了什么
- 回到第一步，基于新的信息继续想
这个循环让模型变成了一个"逐步推理"的存在，而不是"一次性输出"。比如你让它"帮我查三家公司去年的营收并做个对比"，它会：
想到先查 A 公司 → 调用搜索工具 → 看到 A 的数据 → 想到再查 B → 调用搜索工具 → 看到 B 的数据 → 想到再查 C → …… → 最后综合三个结果生成报告。
用 ReAct 的时候有个感受特别明显：模型在"思考"这件事上是有韧性的。它不会因为一次工具调用失败就放弃，会换一种方式重试。这是第一次让我觉得"这东西有点像一个实习生"。
但也暴露了问题——循环越多，上下文越长。每一步的 Thought、Action、Observation 都要塞进上下文。跑个十几轮，窗口就满了。而且模型没有"记忆"——同一个会话里记得的东西，换个会话全忘。
ReAct 让模型从"一次出活"变成了"分步出活"。但它还是没有解决"记不住"和"不会自己定目标"这两个根本问题。
Agentic Loop：把循环完整地闭合
到了 2024 年下半年，各种 Agent 框架开始成熟。它们做的事本质一样——把 ReAct 的循环包装得更完整，加上了状态管理、错误恢复、记忆系统。
一个典型的 Agentic Loop 大概长这样：
- 接收目标（不是指令，是目标）
- 规划：拆成子步骤
- 执行每一步：调工具、处理结果
- 如果出错，反思并调整计划
- 完成或达到终止条件后输出结果
和 ReAct 的区别在于：它有"规划"和"反思"这两个元能力。ReAct 是被动循环——走到哪算哪。Agentic Loop 是主动规划——先想清楚要做什么，做的时候会调整。
这个差别看起来小，实际体验差别巨大。用 ReAct 的感觉是"推一下走一步"，用 Agentic Loop 的感觉是"给个目标它自己跑"。
拆开看：四个核心组件
看了很多框架之后，我发现不管哪个流派，Agent 的核心能力都可以拆成四块：
- 规划（Planning）：把"分析这份数据"拆成"读取文件 → 清洗 → 统计 → 生成图表 → 写结论"
- 记忆（Memory）：短期的——当前对话里说过什么；长期的——跨会话记住用户偏好
- 工具（Tools）：API、代码执行、数据库查询、文件操作
- 行动（Action）：实际调用工具、执行操作
OpenAI 的 Lilian Weng 在一篇经典博客里也是这么分的。这四块缺了哪块都不行——没有规划就是 Function Calling，没有记忆就是无状态 ReAct，没有工具就是个聊天机器人，没有行动就是个文档生成器。
框架对比：我试了几个之后的感受
主流框架我大致试过 LangChain、AutoGen、CrewAI、LangGraph。说实话感受差异挺大的：
LangChain 是我最早用的。文档多、组件全，但链（Chain）的概念对复杂任务来说太刚性了——一旦流程要动态调整，代码就变得很难维护。后来出了 LangGraph 才好一些。
LangGraph 我觉得是 LangChain 系里真正能用来做 Agent 的。它的核心是把 Agent 的流程画成一张状态图——节点是状态，边是转移条件。好处是流程可见、可调试，坏处是简单任务用它也显得重。
AutoGen 是微软出的，主打多 Agent 对话。但在我的实际使用中，Agent 之间的"对话"很容易空转——两个 Agent 来回说"你说得对""我同意"，好几轮不出实质结果。后来我加了强制"每轮必须输出新信息"的约束才好一点。
CrewAI 的角色分工模式比较直观——你定义"研究员""写作员""审校员"，给每个角色一个 prompt，然后让它们按流程协作。适合流程比较固定的场景，但灵活性不如 LangGraph。
我自己的结论是：没有"最好"的框架，只有"最适合你场景"的。如果你的任务流程相对固定、角色清晰，CrewAI 上手快；如果你需要复杂的动态流程和精细控制，LangGraph 更合适。不要被"功能最全"的框架绑架——维护成本和团队学习曲线比功能列表重要得多。
还没想明白的问题
写到这儿，有几个问题我其实还没想清楚：
1. Agent 的"规划"到底该多深？
有些框架让模型一次性规划完所有步骤再执行，有些让它边走边规划。前者结构清晰但缺乏灵活性，后者灵活但容易跑偏。实际中怎么平衡？我现在倾向于"粗规划 + 细调整"——先定大方向，执行中动态调整细节。但还没有足够的实践数据来确认这是不是最优的。
2. 记忆系统的边界在哪？
给 Agent 加长期记忆听起来很好，但什么该记、什么不该记？记太多，检索噪音大；记太少，又"健忘"。我现在用的是一个简单规则——"决策点和用户偏好"才记，过程细节不记。但这规则够不够好，我还不确定。
3. "Agent"和"带工具的 LLM 应用"的界限在哪？
说实话到今天我都不完全确定这个界限。一个能用 Function Calling 调工具的应用算 Agent 吗？如果不算，那加几轮 ReAct 算吗？再加规划算吗？这条线画在哪里，似乎更多取决于你问谁。
小结
如果非要用一句话总结"Agent 进化了什么"：
从"模型能回答问题"到"模型能解决问题"——从被动响应到主动推进。
这个变化不是某一个技术突破带来的，是 Function Calling（能动手）、ReAct（能分步思考）、记忆系统（能记住）、规划能力（能定策略）这些能力叠加起来的。
对传统行业来说，理解这个演进链路比追框架更有用。框架会变，但"规划-记忆-工具-行动"这个四元组不会很快变。想清楚你的场景缺哪一块，再去找对应的方案——比拿着一个框架往场景上套靠谱得多。