目标与成功标准
这些问题，对应目标、环境、观察、动作与反馈。
名称看起来抽象，但不必先背定义。我们继续看已经熟悉的任务：
查清下一次项目例会的日期、时间和地点，把通知保存成草稿。
这段话首先说明了希望得到的结果，也就是目标。对于这个任务，“生成一段文字”还不够：系统需要找到正确会议，使用有依据的信息，并完成文件保存。
目标描述希望实现什么；成功标准把它进一步变成可以检查的结果。
例如，草稿里是否包含日期、时间和地点，内容是否对应同一场会议，文件是否确实保存到了指定位置。这些检查可以帮助系统和用户判断任务做到哪一步。
目标还需要与限制一起理解。如果用户要求的是保存草稿，发送通知就不在这次要求之内。若用户指定了文件夹，系统也不能只因为另一个位置更方便，就擅自把结果放到那里。
限制有时影响行动范围，有时影响结果形式。例如，只读取指定项目的资料、保留原会议安排、不改动日历记录，都可以是任务设计中的约束。描述这些条件，可以减少“表面上做完了，却不是用户要的结果”的情况。
环境与当前可见信息
接下来是环境。
环境可以理解为 Agent 与之交互、并受到其影响的外部系统和事物。在会议任务中，日历服务、项目资料、文件存储，以及提供补充说明的用户，都可以是任务环境的一部分。
软件也有环境，并不需要先连接机器人、摄像头或传感器。程序读取文件、接收输入、获取网络响应，都是从外部取得信息的方式。软件 Agent 与环境的关系
环境与模型的上下文不是同一个范围。日历服务中可能有成千上万条记录，但这次模型计算只接收到了查询返回的几条。文件夹可能真实存在，模型却还没有得到它的目录信息。
环境中实际有什么，与系统当前已经获得了什么信息，需要分开。
观察及其不完整性
这就引出了“观察”。
观察是系统通过相应渠道得到的信息。在本例中，日历工具返回的一条会议记录，是一次观察；读取文件得到的正文，是一次观察；用户回答“我指的是产品组例会”，也是新获得的信息。
“感知”可以用来描述获取这些信息的过程，“观察”可以指已经获得的具体内容。不同资料的用词会有差异，这里先把注意力放在实际输入：系统究竟收到了什么，它能从中知道什么。
假设系统查询以后，没有找到项目例会。这份结果只说明，在这次查询的范围、条件和权限下，没有返回匹配记录。它不能单独证明所有日历里都不存在这场会议。
也许查询的日期范围不对，也许会议换了名称，也许当前账号无权读取那份日历。对后续决策有用的，是连同查询条件一起理解结果，而不是把“没查到”直接写成“会议取消”。
这也说明，观察可能不完整。系统能看到的只是相关环境的一部分，还可能受到数据延迟、工具错误或字段缺失影响。经典 Agent 理论把无法获得完整相关状态的情况，称为部分可观察环境。完整状态与部分观察
动作与实际执行
下一项是动作，也常被称为行动。
动作是系统对环境发起的操作。在本例中，查询日历、读取会议详情、保存通知、向用户提出问题，都可以是动作。它们有不同的效果。
查询和读取主要用于获取信息，通常不改变原记录；保存草稿会创建或修改文件；向用户提问则打开了一次新的交互。动作不必都改变数据库，获取信息的操作也会影响后续可以作出的判断。
模型可以参与选择动作，但动作能否执行，还取决于程序提供了什么工具、参数是否有效，以及当前是否具有相应权限。一个系统没有接入日历工具，就不能只靠在输出中写一句“开始查询”，取得真实会议记录。
把动作讲清楚时，还需要区分“准备执行”和“已经执行”。模型生成工具请求，是提出操作；程序或工具服务实际运行，才进入执行过程。后续需要依据返回结果，确认执行到了哪一步。
反馈支持什么结论
再来看反馈。
反馈是前面的动作产生并返回给系统的信息。例如，查询动作得到“找到两条记录”，保存动作得到“文件写入成功”，网络请求得到“连接超时”。这些结果会影响接下来怎样处理。
因此，一份工具返回值可以同时具有两个身份：对系统来说，它是刚收到的一次观察；相对于刚才的动作来说，它是执行反馈。两种说法着眼于不同关系，并不矛盾。
反馈也不一定直接给出好坏评价。“找到两条记录”没有说任务成功或失败，但提示系统还需要判断哪条符合要求。“已接收保存请求”只表示请求已被接收，也不必然表示文件已经写入完成。
这类区别会影响实际判断。如果保存功能采用后台处理，系统可能还需要查询保存状态，才能确认最终结果。不能因为看到了“接收成功”，就把整个任务记成已经完成。
有时人们一听“反馈”，就想到强化学习中的奖励。对于本篇讨论的任务执行，反馈可以只是资料、状态或错误信息，不要求转换成分数。强化学习中的观察与奖励则承担不同角色，后面会单独学习。观察、奖励与结束信号的区分
同样，收到反馈以后改变下一步做法，也不一定意味着重新训练模型。系统可以把错误信息交给模型，调整这次任务中的操作；是否更新模型参数，是另一项需要明确实现的机制。
把五个要素连起来
现在把这五个词放回同一次会议任务。
用户希望得到可靠的通知草稿，这是目标。日历、项目文档和文件存储构成相关环境。工具返回候选会议记录，是系统获得的观察。根据已有信息，系统选择读取某场会议的详情，这是新的动作。
动作执行后返回具体日期、时间和地点，又形成新的观察与反馈。系统据此生成通知并请求保存，随后利用保存结果，判断目标是否已经实现。
目标引导处理方向 → 通过观察了解环境 → 选择并执行动作 → 接收反馈 → 更新认识与进展 → 决定下一步
工作状态与证据
这里还有一个经常被省略的环节：系统需要维护自己对当前情况的记录。
例如，“已经确认是哪场会议”“地点仍未核实”“文件保存请求已发出，但还没有最终结果”，这些是当前任务的工作状态。程序保存这些状态，再把与下一步有关的部分提供给模型，可以减少重复操作或过早结束。
状态记录也需要尊重证据。把“模型推测会议可能在线上举行”记录成“地点已确认”，就会把不确定的信息变成后续处理的错误前提。记录不仅要有值，还要知道信息来自哪里、是否已经核实。
从这个角度看，Agent 做任务，就是在有限信息下不断获取依据、采取动作并检查结果。相关研究也通过让语言模型结合外部动作及返回信息，探索怎样利用交互继续处理问题；具体模式会在后面学习。ReAct 原始论文
但“不断交互”并不是越多越好。已经有足够依据，就可以完成任务；缺少必要权限，就应说明受限环节；已经确认某种查询没有帮助，就需要重新判断是否值得继续。
以后学习工具调用、记忆、规划和评估时，仍然可以回到这五个问题：目标是什么，环境包含什么，实际观察到了什么，采取了什么动作，反馈又支持什么结论。它们能帮助我们把一个看似复杂的系统，拆成可以理解和检查的交互过程。
下一篇进入 01.09：Agent 循环与终止条件，进一步理解这些过程怎样重复，以及系统怎样区分完成、等待、失败和停止。
当前学习编号：01.08 目标、环境、观察、动作与反馈。
下一学习编号：01.09 Agent 循环与终止条件。后续还有其他学习编号。
关联分支：交互原理对应 18.01 感知、决策、执行与观察循环、18.02 ReAct 模式、28.01 马尔可夫决策过程 MDP、28.02 部分可观察决策过程 POMDP。
状态、动作与验证对应 16.05 工具调用请求与实际执行的区别、16.07 工具结果结构与错误格式、16.09 只读操作与有副作用操作、19.02 工作状态与业务状态、19.11 记忆来源与时间信息、23.02 任务成功标准与评测集、26.02 成功标准与验收条件。奖励及训练的关联知识见 04.04 强化学习、28.03 策略、价值函数与奖励。