Agent 运行机制：从感知、决策到停止的完整循环

Agent 不是“一次提示词调用”，而是一个受约束的运行时循环：它读取当前状态，决定下一步动作，执行动作，把结果写回状态，再判断继续还是停止。工程上真正需要控制的不是模型能否回答，而是每轮输入、动作权限、状态变化和停止条件能否被验证、追踪与恢复。

先说结论

一个最小 Agent 运行时可以概括为五个状态：

1. 感知（Perceive）：收集用户目标、历史消息、工具结果和运行约束。
2. 决策（Decide）：让模型在“回答、调用工具、请求澄清、停止”之间选择下一步。
3. 执行（Act）：由程序校验并执行模型提出的动作，而不是让模型直接操作外部系统。
4. 观察（Observe）：把结构化执行结果、错误和环境变化写回状态。
5. 停止（Stop）：满足成功、失败、预算耗尽或需要人工接管等条件后退出循环。

这篇文章只回答“Agent 在一次任务中如何运转”。如果你要判断应使用固定 Workflow、单 Agent 还是多 Agent，请阅读Workflow、Agent 与多 Agent 怎么选；如果你要区分 Tool Calling 与 MCP 的职责，请阅读Tool Calling、MCP 与 Agent 的关系。

适合谁，不适合谁

本文适合：

• 已会调用大模型 API，准备实现带工具能力的 Agent 的开发者；
• 需要排查 Agent 死循环、重复调用、状态污染或错误恢复问题的工程师；
• 面试中需要解释 Agent 运行机制，而不只会说“模型会自主规划”的求职者。

已有经验可以直接迁移：后端开发者关注权限、幂等和状态；前端与客户端开发者关注流式交互、人工确认和任务进度；测试开发者关注验收条件、失败样本和回归；运维开发者关注预算、观测、限流和恢复。

本文不适合：

• 只想比较 Workflow、单 Agent、多 Agent 架构成本的人；
• 只想学习 MCP Server 配置或某个框架 API 的人；
• 需要模型训练、微调或推理引擎原理的人。

边界要先说清：**运行时提供循环和约束，模型提供有概率的决策，工具提供外部能力。**三者不能互相替代。换一个更强的模型，不能自动补上权限校验、幂等、超时和停止条件。

核心判断：五状态循环如何工作

1. 感知：把事实组织成可决策状态

感知不是把所有信息都塞进上下文。运行时应将输入分为四类：

输入	示例	运行时责任
目标	“汇总本周异常订单并通知负责人”	保存原始目标与成功标准
环境事实	当前时间、用户身份、租户	标记来源，禁止模型自行改写
历史状态	已完成步骤、已尝试参数	压缩但不丢失关键决策
工具观察	查询结果、错误码、变更编号	结构化记录，限制长度和敏感字段

只保留对下一步决策有用的信息。长文档可以先检索，历史对话可以摘要，但权限、金额、资源 ID、已执行副作用等关键事实不能只存在于模型生成的摘要中。

2. 决策：模型提出候选动作

每一轮决策的输出应是有限集合，而不是任意自然语言。一个常见动作协议如下：

Action =
  FinalAnswer(content)
  | CallTool(name, arguments)
  | AskUser(question)
  | Stop(reason)

模型负责提出“想做什么”，运行时负责判断“是否允许做”。决策前应提供可用工具、参数结构、剩余预算和禁止事项；决策后应校验动作类型、参数 Schema、调用权限和业务前置条件。

不要把模型写出的“已发送成功”当成执行事实。只有工具返回的成功结果，才能进入事实状态。

3. 执行：将意图变成受控副作用

执行层是模型与真实世界之间的隔离带。至少处理：

• 参数校验：类型、必填项、枚举、长度和资源归属；
• 授权：当前用户能否读取、写入或审批目标资源；
• 幂等：重试发送消息、创建订单时不会重复产生副作用；
• 超时与取消：单工具超时不拖死整个任务；
• 高风险确认：付款、删除、发布、批量写入等动作先由人确认；
• 结果规范化：把不同工具错误转换为稳定的观察结构。

模型选择了工具，不等于模型获得了工具底层凭证。凭证应由执行层托管，并按用户、租户、工具和动作范围授权。

4. 观察：把结果转成下一轮证据

观察结果至少要区分四类：

success    动作成功，返回可引用事实
retryable  临时失败，可在限制内重试
rejected   参数或权限不允许，需要改计划或请求确认
fatal      无法恢复，结束并说明原因

观察不是简单拼接工具原始输出。运行时要过滤提示注入内容、截断超长结果、标明数据来源，并保留 toolCallId、耗时、状态码和副作用标识。这样下一轮模型有证据可用，工程人员也能重放问题。

5. 停止：结束是运行时能力，不是模型的一句话

可靠 Agent 必须有多种停止路径：

停止类型	条件	输出
成功停止	验收条件已满足	结果、证据、已执行动作
澄清停止	缺少不可推断的信息	一个明确问题
人工接管	高风险动作或冲突无法自动解决	待确认项和影响范围
预算停止	达到轮次、Token、时间或费用上限	当前进度和未完成项
失败停止	致命错误或连续失败	错误原因和恢复建议

“模型输出 final”只能是候选停止信号。运行时仍要检查必需结果是否存在。例如任务要求“创建卡片并返回卡片号”，模型即使声称完成，只要状态中没有工具返回的卡片号，就不能判定成功。

一个最小可控运行时

下面的语言无关伪代码刻意把模型决策与工具执行分开：

state = initialize(goal, identity, constraints)

while true:
  if budget.exhausted(state):
    return stop("budget_exhausted", state.progress)

  context = perceive(state)
  proposedAction = model.decide(context, allowedActions)
  validation = policy.validate(proposedAction, state.identity)

  if validation.type == "rejected":
    state = observe(state, "rejected", validation.reason)
    if retryPolicy.canRetry(state, validation.reason):
      continue
    return stop("policy_rejected", validation.reason)

  action = validation.action

  if action.requiresHumanConfirmation:
    return stop("human_confirmation_required", action)

  if action.type == "final":
    if acceptance.passed(state):
      return stop("success", action.content)
    state = observe(state, "rejected", "acceptance_not_met")
    if retryPolicy.canRetry(state, "acceptance_not_met"):
      continue
    return stop("acceptance_failed", state.progress)

  if action.type == "ask_user":
    return stop("clarification_required", action.question)

  result = tools.execute(action, timeout, idempotencyKey)
  state = observe(state, normalize(result))

生产实现还应持久化检查点。进程重启后从最后一个已确认状态恢复，而不是重新执行全部动作。

状态、记忆与上下文不是一回事

• 状态是当前任务的权威事实，例如完成步骤、工具结果、预算和审批状态。
• 上下文是本轮发送给模型的有限视图，可以由状态裁剪生成。
• 记忆是跨轮次或跨任务保存的信息，必须有写入条件、有效期和删除机制。

反例：把整段聊天记录称为“记忆”，并在每轮完整发送。它既不保证事实正确，又会增加成本，还可能让过期指令覆盖当前约束。更可靠的做法是把业务事实存入结构化状态，只把本轮所需部分投影到上下文。

常见误区与失败边界

误区一：能调用工具就是 Agent

一次模型调用选择一个工具，可能只是带路由能力的 Workflow。Agent 的关键是工具结果会改变状态，并驱动后续决策循环。是否应该使用 Agent 属于架构选择问题，不由“有没有 Tool Calling”决定。

误区二：只靠提示词防止越权

“不要删除数据”不是权限系统。模型可能误解指令，也可能受到外部内容的提示注入。写操作必须在执行层鉴权，高风险动作必须增加确认和审计。

误区三：失败后无限让模型重试

同一参数、同一错误的重复调用不会自然变好。重试只适用于明确的临时故障，并设置次数、退避和总预算；参数错误应修正，权限错误应停止，业务冲突应交给用户。

失败边界

以下情况不应让 Agent 自主闭环：

• 成功标准无法被程序或人明确判断；
• 单次错误会造成不可逆的高额损失；
• 数据源不可信且无法隔离其中的指令；
• 工具没有幂等、审计或权限边界；
• 任务依赖未提供的关键事实，却要求模型猜测。

可执行检查清单

状态与决策

• [ ] 原始目标、成功标准和非目标已进入权威状态
• [ ] 模型只能从有限动作集合中选择
• [ ] 工具结果与模型陈述被明确区分
• [ ] 上下文裁剪不会丢失权限、资源 ID 和副作用记录

工具执行

• [ ] 参数经过 Schema 与业务规则双重校验
• [ ] 凭证不进入模型上下文
• [ ] 写操作具备鉴权、幂等键和审计记录
• [ ] 高风险动作要求人工确认
• [ ] 超时、取消、重试和错误分类有确定规则

停止与恢复

• [ ] 成功条件可验证，而不是只检查模型说“完成”
• [ ] 设置最大轮次、总耗时和成本预算
• [ ] 连续失败与重复动作会触发停止
• [ ] 每次停止都返回进度、证据和未完成项
• [ ] 进程中断后可从检查点恢复，且不会重复副作用

下一步

先回到 Agent 专题 Hub 建立完整知识地图。理解运行时之后，下一步阅读Workflow、Agent 与多 Agent 怎么选，用任务确定性、风险和协作成本判断是否真的需要这套循环。