从完整任务认识 Agent
这一篇就接着这个例子，看看大模型 Agent 怎样完成一件事。
在前置文章中，我们已经认识了 Agent：它从环境中获取信息、选择行动，再根据结果继续处理任务。大模型 Agent 是其中一类实现，使用大语言模型来理解要求、分析已有信息，并参与选择下一步行动。
在这组学习文章中，大模型 Agent 指围绕任务运行的一套系统：大语言模型在允许的范围内，根据目标和执行中获得的信息，动态参与决定接下来做什么。 不同资料对 Agent 的范围有不同界定，这里沿用前置文章的区分方式，帮助我们看清系统怎样工作。Agent 与工作流的工程区分
下面用一个假设的应用来说明。用户提出：
帮我查一下日历，确认下一次项目例会的日期、时间和地点，写一份通知，保存到“会议草稿”文件夹。
这段要求里包含一个最终目标：得到一份信息准确、已经保存的通知草稿。为了完成它，系统需要找到对应会议，取得会议详情，组织通知内容，再完成文件保存。
假设这个应用已经接入了查询日历、读取会议详情、保存文件等工具。这里的“工具”，可以先理解为程序提供给系统使用的具体功能。例如，日历查询工具负责向日历服务查询记录，文件工具负责把指定内容写到指定位置。
工具请求与实际执行
工具接入以后，程序还需要把工具名称、用途和所需输入告诉模型。比如，日历查询需要提供查询范围和关键词，保存文件需要提供位置、文件名和内容。模型只有得到这些说明，才有条件生成合适的调用请求。
在任务开始时，模型接收到的内容，可以包括用户要求、可用工具说明，以及必要的日期等背景信息。它据此判断，目前还没有会议详情，需要先获取资料。
于是，模型可以生成一个工具调用请求，大意是：查询接下来一段时间内与“项目例会”有关的日历记录。
这个请求说明模型准备使用哪个工具、传入哪些信息。真正查询日历，需要由应用程序或提供工具的服务执行。 程序会按设计检查输入和访问权限，再运行相应操作。生成了一个调用请求，并不等于日历已经查询成功。工具调用请求与实际执行
假设查询执行成功，工具返回几条会议记录。程序再把这些结果与任务要求等信息一起提供给模型，让它继续处理。
这里容易产生一个误解：似乎模型发起查询以后，就能一直看着日历，自己知道后来发生了什么。实际系统通常需要明确地把查询结果送回模型。在这种运行方式中，任务会经历多次模型调用，前一次操作取得的结果，成为后一次计算可以利用的信息。
如果查询结果里只有一场明显符合要求的项目例会，系统就可以继续读取它的详情。如果有两场名称相近的会议，模型可以根据已有的项目名称、参与人等信息进一步核对；如果现有资料仍无法区分，再向用户询问具体是哪一场。
这些后续动作，会受到中间结果影响。开始时，开发者不一定知道要查询几次、是否需要查看第二条记录，或者是否需要用户补充信息。模型会在程序允许的范围内，参与选择后续路径。
再假设系统找到了正确会议，取得了具体日期、开始时间和会议地点。模型便可以根据这些资料撰写通知。日历没有提供的信息，需要继续核实，不能为了让通知看起来完整，就自行补充一个地点。
保存结果与执行循环
通知内容生成以后，还要完成保存。模型可以提出保存文件的请求，其中包含目标文件夹、文件名和通知正文。程序实际写入文件，再把成功、失败或需要处理的问题返回给系统。
如果文件没有写入成功，任务就还缺少“已保存”这个结果。系统应当根据具体原因处理，例如核对保存位置，或说明当前无法完成的环节。如果保存成功，再结合必要的内容核对，才有依据告诉用户草稿已经生成，并给出文件位置。
模型说“已完成”是一段输出；任务是否真的完成，需要看实际结果是否满足用户要求。
沿着这个例子，可以把主要运行过程连起来看：
接收任务 → 获取当前可用信息 → 模型参与选择下一步 → 程序执行操作 → 返回执行结果 → 更新任务进展 → 继续处理或结束
这个过程可以重复多次，通常称为 Agent 的执行循环。一次循环可能带来新的资料，也可能带来一个错误，或者发现任务已经满足要求。循环的作用，是让后续处理能够利用前面操作的实际结果。工具执行结果怎样进入下一轮处理
感知、行动与反馈
现在再回头看“感知”“行动”和“反馈”，这些词就有了具体对应。
在这个软件任务里，系统接收到用户输入、读到日历记录、获得文件保存结果，都属于从环境中取得信息，可以从“感知”或“观察”的角度理解。这里的环境，是系统正在与之交互的日历服务、文件存储和用户等，并不要求有摄像头或其他实体传感器。
发起日历查询、读取会议详情、保存文件、向用户提问，则是系统采取的行动。查询虽然通常不修改日历，也仍然是一次与外部服务交互的操作。
工具返回的结果，又构成对刚才行动的反馈。例如，“找到两条记录”帮助系统决定是否继续核对，“保存失败”告诉系统目标尚未实现。反馈可以是文本、数据或错误信息，并不一定是一个分数。
同一份工具结果，既可以看作系统新获得的观察，也可以看作前一次行动的反馈。这些词是在描述交互过程中的关系，不必把它们想成三个互不相干的零件。后面的 01.08 会专门展开目标、环境、观察、动作与反馈之间的关系。
状态、记忆与执行边界
那么，系统怎样知道已经做到哪一步？这就涉及“任务状态”。
在这个例子中，状态可以包括：用户要找哪场会议、已经读过哪些记录、会议时间是否核实、通知正文是什么、文件是否保存成功。程序可以保存这些信息，并在需要时把相关部分提供给模型，让下一步接着已有进展继续。
这与上一篇介绍的上下文衔接起来了。上下文是当前这次模型计算能够使用的信息；系统保存的任务状态，则可能比一次送入模型的内容更多。程序需要选择哪些要求、资料和执行结果与下一步有关，再把它们组织进上下文。Agent 怎样管理不断变化的上下文
这也说明，“Agent 有记忆”需要进一步问清楚是哪一种记忆。
当前任务中记住“文件已经保存”，是在维持任务进展。跨越多次任务，持续保存用户偏好的通知语气，则属于另一类需求，可能需要外部存储以及后续的读取机制。每个 Agent 是否需要长期记忆，要由任务决定；这些信息也不会因为被保存下来，就自动变成模型参数。
还有一个很实际的问题：让模型参与选择下一步，是不是意味着所有事情都由模型说了算？
系统可以明确规定可用工具、可访问的数据范围、文件保存位置，以及哪些操作需要额外授权。这些边界需要由程序和工具落实。例如，本例用户要求保存草稿，系统的操作范围就到草稿为止；发送通知是另一个动作，需要相应的工具能力与授权。
具体日期格式、文件是否写入成功等检查，也可以由普通程序完成。模型适合参与解释任务、比较信息和选择后续动作，但系统可以同时使用明确的规则来约束执行。
因此，不能仅凭“接了几个工具”就认定一个系统具有我们这里讨论的 Agent 特征。模型和工具也可以被安排在固定流程中，例如每次都按照“查询一场指定会议 → 生成通知 → 保存文件”的路径运行。
本文关注的大模型 Agent，则允许模型根据执行结果动态参与后续过程。它也可以与固定流程组合使用。观察一个具体系统时，要看模型参与决定了哪些事情，以及这些选择受到哪些程序规则限制。预定义工作流与模型参与控制的区别
停止条件与完成验证
执行循环还需要一个结束方式。
对于这项任务，成功可以对应明确的结果：找到正确会议，确认所需信息，生成与资料一致的通知，并确认文件保存成功。如果关键信息缺失，系统可以先完成已有依据支持的部分，再清楚说明还需要什么，不能把未核实的信息当作已经确认。
程序还可以设置执行次数、时间或费用上限，避免系统在没有进展时不断继续。因为达到限制而停止，只能说明这次运行结束了，不代表任务已经成功。 完成、失败、等待补充信息，都应当让用户能够区分。
大模型 Agent 也会出错。它可能选择了错误会议，误读了工具结果，或者在保存失败后仍然报告成功。所以，评价它时，需要同时看生成内容、操作过程和最终结果。接入工具带来了获取依据和执行操作的能力，实际可靠性仍需要检查。
回到上一篇介绍的生成机制，会发现它仍然适用：模型根据输入生成回答或工具请求，程序把能够执行的请求转换成实际操作，再将结果送回来。Agent 的连续处理能力，来自这些环节被组织起来运行，并不意味着每完成一步，就重新训练了一次模型。
以后学习 RAG、工具调用、任务状态、规划和记忆时，我们会继续认识这套系统的不同部分。现在先理解这一次完整的配合过程，就能知道那些技术分别是在解决什么问题。
下一篇进入 01.06：模型、Agent 与完整应用的区别。我们会从正在使用的软件出发，看清模型提供的能力、Agent 负责的任务过程，以及完整应用还需要承担哪些工作。
当前学习编号：01.05 大模型 Agent。
下一学习编号：01.06 模型、Agent 与完整应用的区别。后续还有其他学习编号。
关联分支：本篇中的交互过程，对应 01.07 工作流与自主 Agent 的区别、01.08 目标、环境、观察、动作与反馈、01.09 Agent 循环与终止条件、18.01 感知、决策、执行与观察循环；模型提出操作、程序实际执行，对应 16.01 Function Calling 与 Tool Calling、16.05 工具调用请求与实际执行的区别、16.08 工具结果验证。
状态与记忆，对应 13.16 提示词、上下文与记忆的区别、19.02 工作状态与业务状态、19.03 短期工作记忆、19.04 长期记忆、19.12 外部记忆与模型权重知识的区别。
任务运行与结果检查，对应 18.08 计划修订与失败重规划、18.10 停止条件与完成判定、18.11 步数、时间与费用预算、23.01 模型评估与完整系统评估；执行范围对应 22.06 最小权限与能力范围、22.07 用户意图、授权与操作审批。这些支系会在各自编号中单独解释。