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 与 HarnessBrainLoop 提供了任务推进的控制骨架但仅有骨架还不够。在工程落地时必须明确几个关键边界否则结构容易被实际运行中的模糊地带逐渐侵蚀。第一Agent 的中心是 Intent而非 Prompt。Prompt 是一次性的输入会随着对话流转而不断变化Intent 是持续存在的任务目标。在 2B 业务中即使用户中途补充信息、工具调用失败、人工给出修改意见、任务暂停后又恢复系统仍然需要知道最初要完成什么、当前距离目标还有多远、哪些约束条件不可突破。BrainLoop 围绕 Intent 运行Loop 管理 Intent 的完整生命周期Brain 在每一次循环中只判断当前状态下如何推进这一 IntentStepDecision 记录每一次推进判断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 才真正开始具备业务环境所要求的关键能力知道目标知道状态知道边界知道依据知道何时继续何时停止也知道如何被人接管和复盘。
