📌 先简单看一下AI Agent的定义
✍️ AI Agent（人工智能代理）是一种能够自主感知环境、理解信息**、** 规划决策**、** 调用外部工具执行复杂任务的智能实体。它不仅能告诉你"如何做"，更能主动帮你完成任务，类似于一个具备自主行动能力的智能助手。
上面这段话来自AI总结，不过也基本上是业界对于AI Agent的定义
🚗 先看一个具体的问题
🤔 今年国庆（10.1 - 10.10）我打算带家人（两大一小）去新疆自驾10天，打算10.1先从北京乘坐飞机到达伊犁，然后在当地租车自驾。请帮我规划一个具体的行程及攻略，希望玩的开心、轻松，整体预算¥ xx
🤔️ 思考一下
面对上面这个大家在生活中几乎都会遇到的头疼问题我们是怎么去处理的？
结论：结合[上述第一部分](#结论：结合上述第一部分AI Agent的定义可以很明显的看出来，AI Agent的本质其实就是模拟（或者说取代）人类在物理世界中对问题的处理，从而达到解放人类生产力的目标 "#q5ySb")AI Agent的定义可以很明显的看出来，AI Agent的本质其实就是模拟（或者说取代）人类在物理世界中对问题的处理，从而达到解放人类生产力的目标。
🤝 Agent vs Human
此时大家可以想第二个问题：上述人类对行程任务进行规划的过程分别对应Agent的哪些动作呢？
🧐 有这些就够了吗？
上述从一个现实世界具体的例子将人类和Agent做了一个类比，然而大家可以想一下，作为人类的我们在处理类似于上述行程规划任务的时候背后运用的知识以及所做的隐藏工作远不止此。
🔭 TopDown视角来拆解Agent
有了上面的铺垫，我们终于可以引出AI Agent的完整的结构以及运行机制了 Agent = Perception + Planning/Decision + Tool calling
⚠️ 但是请注意，本章节主要是介绍我们现在常规理解上的一类Agent（也是最复杂的那一种），本质上现在业界对于Agent并没有所谓的标准定义。
上图比较详细详细展示了一个Agent的架构，可以看出一个Agent主要包含几个核心的点：
- Perception（感知）
- Planning/Decision（规划/决策）
- Tools Calling（工具调用）
⚠️需要特别注意的是 ：本质上_Perception与Planning/Decision_都是依赖于LLM的能力（推理&总结等能力），在技术架构上两者并没有一个所谓的清晰界定【大部分Agent的实现在架构以及技术实现上可能并不会区分两者（即当成两个节点）】，但为了区分介绍上图以及下文才做了区分。
👓 Perception（感知）
指Agent从环境中收集信息并从中提取相关知识的能力，这里核心是依赖于LLM的CoT。
从上图可以明显看到，Perception的输入来源包含两部分
- 原始输入：即人类给到Agent最初始的任务
- Observation：基于Environment中的Feedback
所以Perception的核心能力用更加准确的描述就是两部分：
- 理解人类自然语言描述的初始问题，提取关键信息
- 感知后续Tool calling环节中的结果，并进行自我修正
🎬 ReAct（Reasoning + Act）
上图表达的流程其实就是ReAct框架 的核心思想。ReAct框架是2023年Google等研究团队提出的一种通用范式。ReAct通过引入一种通用的范式，允许大型语言模型在生成特定任务行动的同时，也生成语言形式的思维（推理轨迹），并将这两者交织起来。 这种方式扩展了LLM的行动空间，包含了不影响外部环境但有助于组织信息和更新上下文的"思想"或"推理轨迹"。这使得模型能够进行动态推理，创建、维护和调整行动计划，同时通过与外部环境交互来收集额外信息，并将这些信息整合到推理过程中。主要机制如下图：
论文中给出了几个详细的例子，分别展示了标准大模型、仅有CoT、仅有Act（即：Tool calling）以及 CoT + Tool calling的效果。
ReAct中也给出了如何在实际工程中落地，实际上就是进行 Prompt Engineering，如下：
📝 Planning/Decision（规划/决策）
指Agent为了某一目标而作出的决策过程及结果。这其实也是一个思考的过程（CoT），Planning/Decision依赖于LLM的知识源，这个知识源主要有如下几部分：
- 知识：LLM自身已经具备的世界知识
- short-term memory：短期记忆，例如：当前任务的Context
- long-term memory：长期记忆，观察环境的feedback不断总结精炼的知识
Memory 特别是long-term memory 在Agent智能化上其实特别重要，前面说了它其实是**Agent基于过往任务自我反思（Reflection）后的总结精炼，**类比于人类自我进化学习的过程。
📭 Reflection
那么到底该如何做反思呢？这里介绍一篇2023年发布的论文Reflexion: Language Agents with Verbal Reinforcement Learning。Reflexion 是一种为大型语言模型 (LLMs) 设计的通用范式，旨在通过语言形式的反馈 （即口头强化 或自我反思）来帮助智能体从过去的尝试和错误中学习，从而提升其在各种任务上的表现。
⚙️ Tools Calling（工具调用）
Agent相对于传统的LLM最明显的不同点就是Agent能够调用外部工具。
🎰 它是如何工作的
看一下上面关于天气预报的问题解决过程，大家有没有疑问如下疑问🤔️：
- Agent面对一个问题时 它怎么知道它要使用工具 、它要使用哪些工具 ？（即：这个问题，应该 需要查 才能得出结果）
- Agent怎么知道 有哪些可以用的工具 ？（即：查这个问题，我可以 用天气预报）
- Agent怎么知道它该 如何使用这些工具（如：入参、出参等） ？（即：用天气预报，我要 输入北京关键词）
要解决上面两个问题使用的方式分别是使用 Prompt Engineering 让Agent知道它有哪些工具可以用，以及 使用SFT来训练模型 来让LM具备使用工具的能力，两者缺一不可。
🧠 教会LM 使用工具
Agent面对一个问题时 它怎么知道它要使用工具 、它要使用哪些工具 ？要做到这一点本身就要教会LM具备这个能力。所以这也就是为什么不是所有LM都适合来构建Agent。
本小节主要的内容来自Toolformer: Language Models Can Teach Themselves to Use Tools，文中主要介绍了如何使用SFT的方式来训练模型，使其具备良好的工具使用能力。
*关键技术点：用模型训练模型，无需大量人工标注，旨在将原始的纯文本数据集 (X) 转化为一个包含 API 调用的增强数据集 (X)，然后使用这个增强数据集来微调语言模型 (M)。**
💡SFT：全称为监督微调（Supervised Fine-Tuning），是机器学习和自然语言处理领域中一种常用的技术。它指的是在一个已经预训练好的模型（如BERT、GPT等大型语言模型）基础上，利用带有明确标签的标注数据对模型进行进一步训练，从而使模型在特定任务或领域上表现得更好。
总而言之，Toolformer 的核心是这三个自监督的步骤：采样潜在的 API 调用 ，执行这些调用获取结果 ，然后基于API调用结果对后续文本预测的帮助程度（通过损失函数衡量）来过滤掉无用的调用。最终的模型通过在包含这些"有用"调用的数据上进行微调，学会了工具的使用。
📞 告诉Agent它有哪些工具
要解决下面两个问题，自然就要告诉Agent相关信息，这里使用的方式就是大家所熟知的 Prompt Engineering
- Agent怎么知道 有哪些可以用的工具？
- Agent怎么知道它该 如何使用这些工具（如：入参、出参等）？
💻 vs function calling
大家可能还听到一个和Tool-calling相似的词function calling。那么它又究竟是什么，它与Tool-calling的关系是什么？
Tool Calling 是Function Calling的高阶封装 ，强调多工具协作与自动化执行。模型不仅生成调用参数，还可_自主规划_多步骤任务（如先查天气再推荐行程），开发者只需定义工具接口。
Function Calling早期由OpenAI提出，但因各厂商实现差异（如参数格式不统一）导致碎片化问题。Tool Calling通过引入MCP协议（Model Context Protocol）统一工具调用接口，解决兼容性问题
总而言之，在Agent领域，一般不再谈论function calling，更多的依赖Tool-calling。
🔐 别漏了安全问题（Guardrails）
在Agent里面安全是极其重要的一个基础模块，主要是为了防止非法的输入造成一些风险，如：数据泄漏、违背公序良俗以及法律的输出等。AI Agent 的安全护栏（Guardrails）是一套 多层次 的技术与策略体系，旨在确保 Agent 在自主执行任务时保持安全、可靠、合规。
Guardrails主要从三个层次进行安全防护：输入、工具调用、输出。
🫨 一些其他的思考
通过上面较为详细的剖析，你会不会觉得一个Agent还是很复杂的。那我们不禁要问几个问题：
- Agent都必须遵循一套固定的开发范式吗？
- Agent是不是银蛋，任何可以用Agent解决的问题都应该让它来解决？
- 作为一个开发者，我们开发Agent时除了场景、技术本身之外还需要考虑哪些因素？
本节内容基本参考自： Building effective agents、 How We Build Effective Agents
文章中的主要内容是Anthropic团队基于在过去与数十个行业构建Agent的事件过程中总结归纳的一些常见架构范式及思考，他们对应着不同的场景，是一份不错的指导性建议（但不是金科玉律）。
🫷不是所有的场景都需要Agent
下面是一个checklist，当你不能很好的判断是否需要一个agent时，可以用以下checklist做一个基本的判 断
📏 保持简单（Keep simple）
虽然前面我们完整的剖析了一个复杂Agent具备的构件，但如果我们进一步精简就会发现如上图所示，一个Agent最最基本的构件就三个：env（环境：Agent运行的环境，如操作系统）、tools（工具）、sys_prompt。
所以，不管从实践还是理论角度，只需要不断对这三部分进行优化建设，Agent就会越来越符合我们的能力要求。
💡 Think like your agents
这里有点哲学的意思，前面我们在讲Agent的时候是把Agent拟人化（用人类的思维和工作方式去建设Agent），但这里又提到了一个有意思的观点就是：LLM/Agent其实有自己的世界观（或者说处理方式）当它的输出不符合我们的设计要求或者人类的直观感受时，不要一味的用人类的经验或者要求去调试解决，应该站在对方的世界去理解，它为什么会这样做决策？
例如：你可以用LLM/Agent去理解LLM/Agent（大白话就是：当你不理解或者不认可一个AI的输出时，你可以把它的结果扔给另一个AI，问它为什么会是这样？）
🎨 Agentic systems
文章 Building effective agents 中提到了一些典型的场景，它们统一被称为agentic systems。
🎙️总结
本文介绍了Agent的一些基础概念以及行业内的一些好的思考建议，其实核心想表达两个点：
- AI及Agent在快速发展，我们对于其本质要有一些了解，这样未来我们自己建设Agent时碰到了性能瓶颈（如：稳定性）也知道该从何处入手优化；
- Agent并不是万能的，还是要基于场景出发，选择最适合自己的场景的方式解决问题。