一个任务是怎么被完成的还是用前几篇里的例子。用户输入 预计本季度果汁销售向好调味料偏低临时代理的华为手机暂停销售。给我拉一个采购补货方案要具体到 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 的主路径不展开工具失败、重试、回滚、超时中止等异常控制细节。
