Agent 控制新思路：BrainLoop 如何把模型推理变成可控的状态迁移-拓冰建站

1. 问题的本质：从“能不能做”到“能不能控”

讨论 Agent 时，大量注意力会放在规划能力上：模型如何拆解目标、编排步骤、调用工具。规划解决的是“想做什么”，这在 Demo 阶段通常表现良好。然而一旦进入 2B 生产环境，更棘手的问题会浮出水面：即便模型给出了一个语义合理的计划，系统是否允许它直接执行？

以办案辅助场景为例，模型建议“下一步生成处罚建议”，这个建议在语义上完全成立。但系统必须继续追问：证据链是否已经闭合？裁量基准是否命中？输出结果应作为草稿还是正式文书？是否需要触发人工确认？如果缺少一层系统级的控制，模型的建议很容易从“替人出主意”滑向“替人做决定”。在 B 端业务中，这种滑动意味着责任边界模糊、过程不可审计、异常无法接管。

Demo 可以只关心最终结果，但生产环境必须关心每一步的过程。判断依据、状态变化、风险边界、人工介入点——这些要素如果只是隐式地混杂在模型输出的自然语言中，整个 Agent 的运行就是不可追溯的。因此，Agent 工程化真正要解决的问题，不是在模型外面再套一层循环让它多走几步，而是在模型与执行之间，构建一层可治理的控制平面。

2. BrainLoop 的设计哲学：以状态迁移为核心

BrainLoop 正是基于上述问题提出的一种 Agent 控制结构。它的名称容易让人直觉联想到“让大脑循环推理”，但其核心内涵更具体：把模型的推理过程，转化为系统可控制的任务状态迁移。

这个定位源于对 Agent 本质的重新审视。Agent 完成一项任务的过程，本质上是在进行一系列状态迁移——从初始状态出发，经过若干中间节点，最终抵达目标状态。沿用办案的例子：从“用户上传笔录和现场照片”，到“系统生成补证清单并经确认形成取证指引”，中间必然经历案件类型确认、证据完整性判断、缺口识别、建议可靠性评估、人工确认等关键阶段。每一步的实质，都是任务状态的切换。

问题在于，这些状态切换如果仅仅发生在模型输出的自然语言层面，系统就没有治理的抓手。只有当每一次迁移被显式地表达出来，系统才能真正知晓：当前处于哪个阶段，为什么可以向前推进，依据是否充分，风险是否可控。

由此，BrainLoop 的核心定义可以表述为：不将模型输出直接等同于执行过程，而是要求模型在每一步生成可验证的状态迁移判断，再由系统据此决定推进、暂停、确认、重试还是结束。模型不再直接驱动任务执行，而是作为状态迁移的“提案方”；系统则作为“决策方”，对提案进行验证和批准。

3. 核心机制：StepDecision 与模型-系统契约

将上述哲学落实到具体机制，BrainLoop 最关键的组件是StepDecision——模型在每一步必须产出的结构化迁移判断。

传统的 Agent 循环中，模型的输出往往是自然语言描述：“我认为下一步应该补充取证。”这种表述过于含混，系统无从验证其合理性，只能选择信任并执行。StepDecision 的设计目标，就是将这种隐性判断契约化。模型不能只说“应该做什么”，而必须系统性地回答以下问题：

当前处于哪个任务阶段？
推进到下一步的理由是什么？
判断依据来自哪些上下文、证据或规则？
下一步的具体类型是什么（继续推理、调用工具、等待人工、结束任务）？
这一步是否存在风险？是否需要人工确认？
失败后的处理策略是什么？
如何判断这一步是否成功？

通过这种结构化的输出，StepDecision 成为模型推理与系统执行之间的契约。模型负责提出迁移建议并提供完整的理由和依据，系统则负责检查建议的合理性与前置条件是否满足，再决定是否批准执行。这彻底改变了 Agent 的运行模式：从“模型自说自话、系统盲目跟随”，转变为“模型提议、系统决策”。

4. Brain 与 Loop 的职责分离

在 BrainLoop 架构下，Brain和Loop分别承担不同的职责，这一分离是控制结构得以成立的基础。

Brain 的职责被严格限定：它只做一件事——基于当前的任务意图、状态、上下文、证据和约束，生成下一步的迁移判断。Brain 可以进行规划推理，但规划必须收敛为当前这一步的具体决策；可以建议执行某个动作，但动作的实际执行必须交给系统和 Harness；可以判断是否需要人工介入，但不能绕过人工确认机制；可以提出状态修正建议，但不能直接写入持久化的检查点。Brain 的价值在于提供动态的语义决策能力，它是一个任务状态迁移的“决策器”，而非“执行者”。

Loop 则承担完全不同的使命：它是一个任务生命周期状态机，而不是简单的while true推理循环。Loop 关心的不是“模型还能不能继续输出”，而是“当前任务是否允许继续推进”。一个任务在生命周期中可能经历运行中、等待外部结果、等待人工确认、需要补充信息、需要重试、需要回退、已完成、已失败、已取消等多种状态。Loop 的核心职责是维护这些状态之间的合法转换，并保证每一次转换都有明确的 StepDecision 作为依据。模型建议“进入下一步”，Loop 必须检查前置条件；模型声称“任务完成”，Loop 必须验证完成标准；模型要求人工确认，Loop 必须将任务转入等待状态而非让模型继续生成结果。

两者的关系可以概括为：Brain 负责提出迁移方案，Loop 负责接受、拒绝、暂停或提交迁移。这种分离确保了智能判断与流程控制的解耦。

5. 工程边界的明确：Intent、Step 与 Harness

BrainLoop 提供了任务推进的控制骨架，但仅有骨架还不够。在工程落地时，必须明确几个关键边界，否则结构容易被实际运行中的模糊地带逐渐侵蚀。

第一，Agent 的中心是 Intent，而非 Prompt。Prompt 是一次性的输入，会随着对话流转而不断变化；Intent 是持续存在的任务目标。在 2B 业务中，即使用户中途补充信息、工具调用失败、人工给出修改意见、任务暂停后又恢复，系统仍然需要知道最初要完成什么、当前距离目标还有多远、哪些约束条件不可突破。BrainLoop 围绕 Intent 运行：Loop 管理 Intent 的完整生命周期，Brain 在每一次循环中只判断当前状态下如何推进这一 Intent，StepDecision 记录每一次推进判断，Action 仅是某一步需要执行的具体动作。

第二，Step 是语义进度单位，而非工具调用单位。将 Step 等同于一次 Tool Call 是一个常见误区，这会导致任务进度的粒度过细、结构过碎。有意义的任务推进，有时不需要工具调用（如“等待人工确认”），有时则需要多个工具协同（如“确认案件类型”内部可能调用 RAG、规则引擎）。将 Step 定义为语义进度单位，系统记录的便是“任务为何从这个阶段进入下一个阶段”，这正是业务审计真正需要的信息。

第三，Harness 是执行边界，动作不可由模型自由发挥。BrainLoop 负责解决“任务如何推进”，Harness 负责解决“动作如何执行”。Brain 可以建议执行某个动作，但绝不能直接执行，因为动作背后涉及权限、成本、副作用和审计。低风险动作（如读取材料、调用 OCR）可以自动执行；有副作用的动作（如生成正式文书、写入业务系统、变更案件状态）必须经过 Harness 的边界治理。更重要的是，允许的动作类型应由 Harness 或系统预定义，模型只能在预设的动作空间内选择，不能自行发明新动作。BrainLoop 允许动态判断，但执行边界是不可突破的硬约束。

6. 设计原则与本质总结

综合以上讨论，BrainLoop 的设计理念可以凝结为一句话：把模型的隐性判断显性化，把自由推理契约化，把任务推进状态化。这句话拆解为具体的设计原则，包括：

Brain 只提出迁移判断，不直接写入最终状态；
Loop 管理生命周期，不介入复杂语义推理；
Step 记录语义进度，不记录零散的工具调用；
Action 必须在预定义的动作空间内选择，不可由模型自由创造；
具有副作用的动作，必须经由 Harness 执行；
每一次推进都需要说明依据、理由和完成条件；
人工确认不是异常分支，而是任务生命周期的组成部分；
失败、暂停、恢复、回退必须作为一等状态被显式管理，而非沦为日志中的事后补丁。

这些原则的目的，并非让系统变得更复杂，而是让 Agent 的行为不再依赖于“模型这次表现不错”这种脆弱的前提。

归根结底，BrainLoop 试图解决的是 2B Agent 最核心的结构性问题：模型可以动态判断，但任务必须被系统控制。它将 Agent 从模型驱动的工具调用过程，升级为系统控制的任务状态迁移过程。Brain 负责判断迁移的合理性，Loop 管理生命周期与迁移提交，StepDecision 充当模型与系统之间的契约，Step 是审计的基本单位，Intent 是整个流程的锚点，Harness 是执行的最终边界。有了这套控制骨架，Agent 才真正开始具备业务环境所要求的关键能力：知道目标，知道状态，知道边界，知道依据，知道何时继续，何时停止，也知道如何被人接管和复盘。