引言：AI Agent 解决的究竟是什么问题
Agent正在成为继 Web 应用、移动应用之后新的软件形态。未来，越来越多的软件不会只是被用户操作，而会主动帮助用户完成目标。因此，理解并掌握 Agent 的开发方式，将成为开发者面对下一阶段 AI 浪潮的重要能力。
学习开发自己的 Agent，并不是重复造一个 ChatGPT，而是为了理解AI 技术变革背后的核心逻辑。掌握 Agent 开发能力后，我们可以根据自己的业务需求和流程，构建属于自己的智能助手。
那么，在学习如何开发 AI Agent 之前，我们首先需要弄清楚，Agent 为什么会出现。
如果只是为了让程序能够调用大语言模型，那么我们只需要接入一个模型 API，再做一个聊天界面，并不需要引入 Agent 这个概念。如果只是为了自动执行一系列操作，脚本、工作流引擎和 RPA 也早已能够完成大量任务。
AI Agent 真正试图解决的，是一个更基础的问题：
当用户只知道自己想要什么，却无法提前说明每一步应该怎样执行时，软件能否根据目标和当前环境，自己找到一条可行的完成路径？
传统软件稳定，但不够灵活
传统软件的基本工作方式，是开发者先定义规则和流程，程序再根据输入执行这些流程。
以用户登录为例，程序会依次检查参数、查询用户、校验密码、判断账户状态，最后生成登录凭证。每一步都由开发者提前写好。程序不需要理解“登录”是什么，也不需要思考接下来应该做什么，只需要严格执行已有逻辑。
这种模式非常可靠。因为流程是确定的，所以程序可以被测试、审计和复现。我们显然不希望一个支付程序临时思考应该扣多少钱，也不希望一个权限系统根据语言模型的自由判断决定谁可以访问数据库。
当任务能够被明确拆成固定步骤时，传统程序往往是最好的选择。但如果任务变成：
阅读最近三个月的经营数据，找出最值得关注的问题，分析可能原因，并整理成一份适合管理层阅读的报告。
程序面对的就不再是一个确定流程。“最值得关注”没有唯一标准，“可能原因”也无法仅靠一个固定公式得到。系统需要根据数据特征判断重点，可能还要查询外部信息，并根据分析结果决定下一步调查方向。
这类任务可以称为开放性任务。它们通常有相对明确的目标，却没有唯一、固定的执行路径。任务的下一步往往取决于上一步得到的结果。这时传统软件就无法很好的处理了。
第一次演化：专家系统
早期人工智能研究尝试解决的一个核心问题，是如何把人的知识和推理过程转化为计算机可以执行的形式。
专家系统就是这一思路的代表。开发者和领域专家把专业知识写成事实和规则，再由推理程序根据输入寻找符合条件的结论。
例如，一个简单的故障诊断系统可能包含这样的规则：
if 设备无法启动: 检查电源else if 无法进入系统: 检查内存条与普通顺序程序相比，专家系统已经表现出一定的“决策能力”。程序不再只是沿着一条固定路径执行，而是可以根据当前条件选择不同规则。
但这种智能依然来自人提前写好的知识。系统能够处理哪些问题，取决于知识库里是否存在相应规则。一旦现实情况超出规则覆盖范围，程序就很难自行推断。
更麻烦的是，现实中的知识并不总能被整理成清晰规则。经验丰富的医生、工程师或程序员，常常能够根据多个模糊迹象作出判断，却不一定能把自己的完整思考过程写成一组没有冲突的“如果—那么”规则。
随着规则数量增加，规则之间还可能出现重叠、冲突和例外。知识库越庞大，维护成本就越高。
专家系统证明了一件事：程序可以根据环境作出选择。但它也暴露了一个限制——如果所有知识和判断方式都必须由人提前编码，系统很难适应开放而不断变化的现实世界。
第二次演化：机器学习
机器学习改变了知识进入程序的方式。
在传统规则系统中，人需要告诉程序如何判断；机器学习则通过大量数据，让模型自己学习输入与结果之间的统计关系。
例如，开发者不必逐条规定垃圾邮件一定包含哪些词，而是可以向模型提供大量正常邮件和垃圾邮件。模型会从数据中学习哪些特征更常出现在垃圾邮件中，并据此判断新的邮件。
深度学习进一步增强了这种能力。模型开始能够从图片、语音和文本中自动提取复杂特征，图像识别、语音识别和机器翻译因此获得了显著进步。
这一阶段解决的是传统规则系统最困难的问题之一：许多复杂规律不再需要由人手工写出，而可以从数据中学习。
但是，机器学习模型通常仍然只完成一个预先定义好的任务。图像分类模型负责判断图片中的对象，语音识别模型负责把声音转换成文字，推荐模型负责预测用户可能感兴趣的内容。
它们可能非常准确，却通常不知道自己的输出接下来应该被怎样使用。
一个模型可以判断图片中有一辆汽车，但它不会因此主动查询车牌、检查车辆权限、生成异常记录并通知管理员。除非开发者提前把这些步骤连接起来，否则模型的工作到“输出预测结果”就结束了。
因此，机器学习主要解决了感知和预测问题，却没有直接解决复杂任务中的连续决策问题。
第三次演化：大语言模型
早期机器学习模型往往针对单一任务训练，不同任务需要不同模型和接口。大语言模型带来的关键变化，是同一个模型开始能够通过自然语言处理多种不同任务。
用户可以要求模型总结文章、解释代码、提取信息、生成计划或者分析错误，而不必为每一种任务重新训练一个独立模型。任务本身可以直接通过语言描述。
自然语言因此不再只是模型处理的数据，也逐渐成为控制软件的一种通用接口。
过去，程序通常接收明确参数：
summarize(document_id=123, max_length=500)现在，用户可以直接说：
请阅读这份文档，提炼主要观点，并重点说明其中可能影响项目进度的风险。后者包含的不只是参数，还有任务目标、关注重点和输出要求。大语言模型能够从这些自然表达中提取意图，并生成与任务相关的结果。
这使软件第一次能够较自然地处理模糊目标。用户不再需要准确了解系统内部有哪些功能，也不必把需求翻译成严格的操作步骤。
不过，此时的大语言模型仍然主要是一个文本生成系统。
它可以告诉你怎样排查项目错误，却不能自动读取项目文件；可以建议你查询天气，却不知道此刻的真实天气；可以生成一段代码，却不会主动写入项目并运行测试。
语言模型获得了较强的理解和生成能力，但它仍然缺少两样关键能力：接触真实环境，以及根据环境反馈继续行动。
第四次演化：调用工具
要让大语言模型从“回答问题”走向“完成任务”，首先要给它提供可以执行的工具。
对于一个开发助理，这些工具可能包括：
- 读取文件；
- 搜索项目代码；
- 修改文件；
- 执行终端命令；
- 运行测试；
- 查询技术文档。
对于一个办公助理，工具则可能包括邮件、日历、文档和数据库接口。
模型本身通常不会直接执行这些操作。更准确的工作方式是：程序先向模型说明当前有哪些工具，以及每个工具需要什么参数；模型根据任务选择工具并生成参数；外部程序完成参数校验和权限检查后，真正执行操作。
例如，用户要求读取项目配置文件时，模型可能生成类似这样的结构化请求：
{
”tool”: ”read_file”, ”arguments”: {
”path”: ”package.json” }
}Agent 程序收到请求后，不应该立刻无条件执行。它需要判断 read_file 是否是允许使用的工具，文件路径是否处于授权目录中，以及参数格式是否正确。检查通过后，普通代码才会读取文件，并把结果重新交给模型。
因此，工具调用不是模型获得了某种神秘的执行能力，而是建立了一座连接语言决策和程序操作的桥梁。
模型负责回答：
现在应该调用哪个工具，以及传入什么参数？
程序负责回答：
这个操作是否允许，以及具体应该怎样安全地执行？
这种分工非常重要。大语言模型擅长理解模糊意图和选择操作，但它的输出并不总是可靠；传统代码不擅长开放推理，却擅长严格执行和权限控制。Agent 系统需要同时利用两者的优势。
第五次演化：反馈循环
仅仅能够调用一次工具，还不足以构成完整的 Agent。
假设用户要求：
找出这个前端项目为什么无法启动。
模型第一次可能决定读取 package.json。读取结果表明这是一个 Vite 项目，但这还没有解决问题。下一步可能需要执行启动命令。
启动命令返回端口占用错误后，模型需要重新分析结果，再决定检查端口占用情况。如果发现有旧进程运行，它还要判断是建议用户关闭进程，还是在获得授权后主动结束进程。
整个任务路径不是在一开始就完全确定的，而是在执行过程中逐步形成：
理解目标 ↓决定读取配置 ↓获得项目配置 ↓决定执行启动命令 ↓获得错误信息 ↓决定检查端口 ↓定位问题 ↓给出处理方案或继续执行这里出现了 Agent 最核心的结构：行动和反馈之间的循环。
模型根据当前信息决定行动，工具执行后产生新的环境信息，模型再根据这些信息决定下一步。这个过程持续到任务完成、达到安全限制，或者需要用户介入。
我们可以把最小 Agent 抽象为：
如果只有模型回答，没有行动，它是聊天系统；如果只有固定步骤，没有动态决策，它更接近工作流；如果模型能够在目标、行动和反馈之间持续循环，它才具备 Agent 的基本形态。
从第一性原理理解 AI Agent
现在，我们可以不依赖某个具体框架，给 AI Agent 一个工程上的定义：
AI Agent 是一个围绕目标运行的软件系统。它能够获取当前环境信息，借助模型判断下一步行动，通过工具影响环境，并根据行动结果持续更新任务状态。
这个定义中包含五个不可缺少的部分。
1. 目标
Agent 需要知道最终要解决什么问题。目标通常由自然语言表达，可能并不包含完整步骤。
例如：
分析这个项目启动失败的原因，并在不破坏现有功能的前提下尝试修复。
这里既包含任务目标，也包含约束条件。
2. 环境
Agent 必须能够获得与任务相关的真实信息。对于代码 Agent，环境包括文件、代码、终端输出和测试结果；对于知识助理，环境包括文档、数据库和搜索结果。
3. 决策
模型需要根据目标、当前状态和环境信息，判断下一步应该执行什么动作。决策可能是调用工具，也可能是向用户询问，或者判断任务已经完成。
4. 行动
行动由工具完成。工具是 Agent 与外部世界交互的接口，也是能力边界和安全边界所在。
Agent 能做什么，不仅取决于模型能力，还取决于我们提供了哪些工具。
5. 反馈与状态
工具执行结果必须被记录，并用于后续判断。Agent 还需要知道已经完成了什么、当前处于哪个阶段、是否发生错误，以及是否应该继续执行。
这五部分组合起来，才构成一个完整的 Agent 系统。大语言模型只是其中的决策组件。它非常重要，但并不等于 Agent 本身。
我们将要构建的 MyAgent
经过前面的推导，现在可以明确这套教程最终要做的是什么。
MyAgent 将是一个本地优先的个人开发助理。用户可以通过自然语言给它一个开发任务，它会在授权范围内读取项目、调用工具、记录执行结果，并根据当前情况继续推进任务。
但我们不会一开始就构建一个庞大的“全能 Agent”。第一阶段只实现最小闭环：
用户提出目标 ↓模型选择一个工具 ↓程序安全执行工具 ↓模型读取工具结果 ↓生成答复或决定下一步在这个基础上，我们再逐步增加连续对话、短期状态、长期记忆、知识库、任务规划和人工审批。
每一步都对应一个真实问题。例如，上下文越来越长时，我们才引入记忆管理；任务需要查询私人资料时，我们才引入 RAG；步骤越来越复杂时，我们才讨论规划；关键操作存在风险时，我们再增加审批和权限系统。
这套学习方式的核心不是尽快堆出最多功能，而是理解每一种能力为什么出现，以及它在 Agent 系统中承担什么职责。
