Agent Loop：自主式 AI 的工作原理，从任务到结果的完整循环 | 葡萄城技术团队
一个任务是怎么被完成的
还是用前几篇里的例子。用户输入：
> 预计本季度果汁销售向好，调味料偏低，临时代理的华为手机暂停销售。给我拉一个采购补货方案，要具体到 SKU。
这个任务没有固定的执行步骤。用户没有说先查什么、再查什么、用哪个接口、怎么算补货量。这些都需要 Agent 自己判断。
Agent 的处理过程大致是这样的：
- 理解任务。Agent 分析用户意图，拆解出几个子目标：查当前库存、查各品类的近期销售记录、根据用户给出的销售预期调整补货量、排除华为手机、生成 Excel 文件。这个拆解本身就是一次推理，产出的是一个初始工作计划。
- 构建上下文。在执行第一个子目标之前，Agent 需要知道去哪里查库存、用什么接口、参数怎么传。这时候本体被加载进来，Agent 在本体里找到"物品表"对应的实体，找到查询物品表的 TableBinding，确认筛选参数的格式。
- 执行动作。Agent 调用 TableBinding，拿到库存数据。
- 分析执行结果。数据拿到了，格式对不对？字段含义和预期一致吗？"可用库存"和"库存"是两个字段，本体里有说明，Agent 知道应该用"可用库存"而不是"库存"来判断补货需求。子目标一完成，进入下一个子目标。
- 循环。用同样的过程查销售记录，再用同样的过程做数据分析，最后调用文件工具生成 Excel。每个子目标完成后，结果被加入上下文，作为下一步推理和重规划的输入。
这个"理解 / 重规划 → 构建上下文 → 执行动作 → 分析结果 → 循环"的过程，就是 Agent Loop。
为什么叫"循环"
Loop 这个词很重要，它指的不是线性的流水线，而是一个会反复迭代的过程。流水线的每个节点在设计阶段就已经确定，执行时按顺序走，没有分支，没有回头。Agent Loop 的每次迭代结束之后，Agent 判断任务是否完成，如果没完成，把当前结果加入上下文，更新工作计划，再进入下一次迭代。迭代多少次、每次做什么，是 Agent 在运行时根据上下文动态决定的。
这个动态决策能力，是"数字员工"和"软件工具"之间最根本的差异。一个 AI Workflow，它的每个节点在写好之后就固定了，遇到没有预见到的情况，要么走预设的错误处理分支，要么直接失败。Agent Loop 里的 Agent 遇到意外情况，可以重新推理，调整策略，尝试另一种路径。
代价是不可预测性。Agent 在运行时动态决策，意味着没有办法保证每次执行都走完全相同的路径。这对需要零容错的场景是不可接受的，对需要处理复杂、不确定任务的场景则是必要的。这也是 AI Workflow 和 AI 工作台的选型分水岭，留到后面的本章中细说。
上下文是怎么被管理的
Agent Loop 的每次迭代，上下文都在增长。第一轮查完库存，库存数据进入上下文；第二轮查完销售记录，销售数据也进入上下文；到第三轮做分析时，上下文里已经有了两批数据，Agent 在这个基础上推理。
但上下文窗口的容量是有限的。大模型能处理的 token 数量有上限，上下文太长会导致早期信息被截断，或者推理质量下降。这意味着 Agent 需要对上下文进行管理，而不是无限地往里堆数据。
这就引出了长短期记忆的概念。短期记忆是当前会话的上下文窗口，存放正在处理的任务所需的实时信息。长期记忆是持久化的存储，用于保存跨会话的信息：用户的偏好设置、历史任务的关键结论、常用数据的缓存。
对采购补货任务来说，本次查询的库存数据是短期记忆；"这个用户通常用 Excel 格式输出"、"上次的补货方案里华为手机被手动调整过"，这类信息如果被持久化，下次执行类似任务时可以直接使用，不需要重新从用户那里获取。
记忆管理策略的设计，是 Agent 框架里一个容易被低估的工程问题。过于激进的压缩会丢失关键信息，过于保守的保留会撑爆上下文窗口，中间的平衡点没有通用答案，依赖于具体任务的特征，这也是通用型 Agent 的“一生之敌”。
本体在循环的哪个位置发挥作用
回到补货方案的例子，把本体的介入时机标出来。
- 在"构建上下文"阶段，本体是最重要的输入来源之一。Agent 决定要查库存时，不是盲目地猜"可能有一个叫 inventory 的接口"，而是在本体里查找：有没有和"库存"语义相关的实体？找到"物品表"和"物品_库存"页面，再找对应的 TableBinding，确认参数格式。这个查找过程把接口选择收敛到结构化范围内，显著减少了对语言模型即兴发挥的依赖。
- 在"分析执行结果"阶段，本体同样参与。系统返回了一个 JSON，字段名叫"可用库存"、"库存下限"、"供应商 ID"，这些名称需要被正确解读。本体里有对这些字段的语义描述，Agent 知道"库存下限"是触发补货的阈值，知道"供应商 ID"指向哪个实体，能据此做出正确的业务判断，而不是把数字当作无意义的数值来处理。
- 在"执行动作"阶段，本体为调用提供结构依据：这个接口接受什么参数、参数类型和取值范围是什么。至于当前用户有没有权限调用、这次操作是否允许执行，则由运行时策略层校验，不由本体本身决定。
这三个介入点合在一起，覆盖了 Agent Loop 里可能出错的三个主要位置：选错接口、传错参数、误读返回结果。本体不是在 Agent Loop 之外发挥作用，而是深度嵌入在每次迭代的各个环节里。
人在哪里介入
Agent Loop 是自主运行的，但"自主"不等于"不需要人"。
最常见的有两类情况需要人介入。第一类是任务本身要求人工确认。采购补货方案涉及资金支出，AI 生成的方案需要采购主管审核签字才能执行，这是业务流程的要求，不是 AI 能力的限制。第二类是 Agent 在推理过程中遇到了不确定性，需要向用户澄清。"您说的'调味料偏低'，是指本季度的采购量减少，还是说市场预期销量下降？"这类问题，AI 自己做假设可能猜对也可能猜错，主动提问是更安全的选择。
再往上还有一类常见介入：风险“门禁”或异常兜底。比如操作金额超阈值、连续调用失败、命中了高风险命令，这时系统会要求人工接管或确认，而不是让 Agent 自行继续。
这两类介入在架构上叫做"人在回路"（Human in the Loop）。在实现上，Agent 在需要人工介入时暂停执行，向用户发出请求，等待响应，然后把响应加入上下文，继续循环。
人在回路不是 AI 能力不足的补偿措施，而是高价值业务场景的必要设计。一个永远不需要人确认的 AI，在企业环境里通常意味着它做的事情要么风险极低，要么没有人认真审计。真正重要的业务决策，需要人在关键节点上签字确认，这既是责任归属的问题，也是建立用户信任的过程。
循环什么时候结束
Agent 怎么知道任务完成了？这不是一个简单的问题。
在 AI Workflow 里，结束条件是人工设定的：走到最后一个节点就结束。Agent Loop 里，结束条件主要由 Agent 自己判断。简单的理解，Agent 维护了一个工作清单，每完成一个子目标就打一个勾，当所有子目标都完成，或者用户确认结果满意，循环结束。
但在工程实现上，通常还会叠加几个硬条件：最大步数、超时时间、成本预算、连续失败次数。它们不是任务意义上的"完成"，而是为了防止循环失控的运行边界。
但 Agent 的判断可能是错的。它认为任务完成了，但实际上漏掉了某个子目标，或者某一步的结果不符合要求但 Agent 没有发现。这是 Agent Loop 相比 AI Workflow 更难测试和验证的原因。结束条件不是程序写死的，是推理出来的，推理质量的好坏直接影响任务完成的质量。
现在需要记住的是：Agent Loop 是一个由 LLM 的推理能力驱动的动态过程，本体为这个过程提供结构化约束，尽量减少接口选择、参数组装、结果解释时的猜测空间，两者共同决定了 Agent 的可靠程度。去掉本体，Agent 的推理更容易失去约束；去掉 LLM 的动态推理，Agent 退化成固定流水线。两者缺一不可。
本文先解释 Agent Loop 的主路径，不展开工具失败、重试、回滚、超时中止等异常控制细节。