引言在智能体系统中我们通常默认 只要模型足够强、上下文足够多推理就可以在系统内部完成。但在实际工程中这个假设并不总是成立。当推理需要依赖尚未被明确表示的信息、需要更精确的结构化输入或需要与真实世界保持一致时继续内部推理反而会降低系统质量。本文讨论一种实践路径 在智能体的推理流程中引入一个显式的外部决策步骤Externalized Cognitive Step并将其作为执行模型的一部分而不是交互层的补丁。以下内容基于 Wenko 的真实实现。Wenko 是一个基于 LangGraph 构建的桌面智能体系统其执行图execution graph中包含了一个可暂停、可恢复的外部决策节点。本文将以该实现为例说明这一设计如何在工程上落地。Wenko 项目仓库地址https://github.com/daijinru/wenkoexample一、为什么内部推理并不总是最优选择智能体推理失败通常不是因为模型不聪明而是因为以下几类信息缺失模糊但关键的参数时间、范围、偏好隐含但未表达的约束条件需要结构化表示而非自然语言理解的内容系统需要与外部世界保持一致的状态在这些场景下继续让模型猜会带来两个问题推理结果高度不稳定错误往往在后续步骤中被放大工程上更理性的做法不是强化猜测能力而是中断推理转而获取更可靠的信息来源。二、什么是外部决策步骤所谓外部决策步骤并不是指让系统放弃智能而是在推理链条中将一个无法在当前上下文中完成的决策 显式外包为一个独立、可暂停、可恢复的步骤。它具有几个关键特征由系统主动触发而非用户随意插入以结构化请求的形式表达而非自然语言追问会中断当前推理流程只有在获得外部输入后才继续从系统角度看这是一次受控的推理暂停。在 Wenko 中的对应结构这个受控的推理暂停在 Wenko 中被实现为GraphState上的一次状态转移。GraphState是整个执行图的单一状态源Single Source of Truth其中与外部决策相关的核心字段如下# workflow/core/state.py class GraphState(BaseModel): status: Literal[idle, processing, suspended, error] idle ecs_request: Optional[ECSRequest] None ecs_full_request: Optional[Dict[str, Any]] None last_human_input: Optional[Dict[str, Any]] None其中ECSRequest定义了一个决策请求的最小数据契约class ECSRequest(BaseModel): type: str # form, confirmation, visual_display message: str options: List[Dict[str, Any]] context_data: Dict[str, Any]几个要点status的四种状态idle→processing→suspended→idle构成了一个显式的生命周期。suspended不是错误不是等待——它是一种被设计出来的执行状态。ecs_request是推理节点写入的不是外部注入的。换言之是推理过程自身判定我需要外部信息而不是某个外部控制器强制中断了它。last_human_input只在恢复阶段才被填充用于在下一轮推理中作为高置信度上下文注入。三、为何要将它设计为步骤而不是对话一个常见替代方案是 让智能体通过多轮对话逐步澄清信息。这种方式在简单场景下有效但在工程系统中存在明显问题信息分散在多轮上下文中难以结构化处理模型需要自行判断哪些信息是最终版本无法明确区分输入阶段和推理阶段将外部决策设计为一个独立步骤可以带来清晰的边界在进入该步骤前系统停止推进推理在该步骤完成前不发生任何后续决策外部输入以完整、一次性的形式返回系统这使得推理流程在时间和语义上都更加可控。对话澄清 vs. 结构化决策步骤为什么不用对话根本原因在于信息的结构保真度。在 Wenko 的实现中外部决策请求携带的不是一个自然语言问题而是一个完整的结构化 schema。后端的ECSField定义了每个待采集字段的精确约束# workflow/ecs_schema.py class ECSField(BaseModel): name: str type: ECSFieldType # TEXT, SELECT, NUMBER, SLIDER, DATE, BOOLEAN... label: str required: bool False placeholder: Optional[str] None default: Optional[Any] None options: Optional[List[ECSOption]] None min: Optional[float] None max: Optional[float] None当系统需要用户的音乐偏好时它不会问你喜欢什么音乐——它会生成一个包含SELECT类型选择、SLIDER频率、TEXT补充说明的字段集合。返回的数据是Dict[str, Any]不是一句自然语言不需要模型再做一次解析。这是一个关键的设计判断在决策边界上用结构替代语言。四、工程实现一个可暂停的推理模型在实现层面引入外部决策步骤意味着对执行模型做出明确约束。1. 推理结果不直接驱动执行当智能体判断需要外部决策时它不会继续生成最终答案而是生成一个决策请求对象其中包含当前推理意图所需信息的结构化定义可选项或默认值对输入结果的预期用途该对象本身是推理的一部分而不是 UI 产物。触发机制在 Wenko 中ReasoningNode是执行图中唯一的 LLM 调用节点。它在完成 LLM 调用并解析响应后检查输出中是否包含外部决策请求# workflow/core/nodes/reasoning.py — ReasoningNode.compute() if is_ecs_enabled(): ecs_request extract_ecs_from_llm_response(full_response) if ecs_request: updates[ecs_request] ECSRequest( typeecs_request.type, messageecs_request.title, options[], context_data{ecs_id: ecs_request.id}, ) updates[status] suspended updates[ecs_full_request] ecs_request.model_dump(modejson) return updates注意这里的控制流return updates意味着ReasoningNode**不再产生response**不再更新对话历史不再执行后续逻辑。它的唯一输出是一个决策请求和一个状态标记。为什么不让模型同时输出回复和决策请求因为这会模糊决策边界——如果模型已经给出了回复那外部决策的结果还能改变什么外部决策步骤的前提是当前推理必须等待外部信息才能产出有效结果。2. 推理流程进入显式暂停状态一旦外部决策步骤被触发当前执行图终止系统状态被标记为等待外部输入不再发生任何隐式推理或自动推进这种暂停是结构性的而不是通过 sleep、await 或轮询实现。执行图中的路由与终止暂停的实现依赖 LangGraph 的条件边conditional edge机制。ReasoningNode的输出经过路由函数分发# workflow/core/graph.py — GraphOrchestrator._build_text_graph() def route_reasoning(state: GraphState): if state.pending_tool_calls: return tools if state.ecs_request: return ecs return END当ecs_request不为空时执行流进入ECSNode。而ECSNode本身几乎不做任何事——它只是确认暂停状态# workflow/core/nodes/ecs.py class ECSNode: async def execute(self, state: GraphState) - Dict[str, Any]: if not state.ecs_request: return {status: processing} return {status: suspended}紧接着一条无条件边将ECSNode连接到ENDworkflow.add_edge(ecs, END) # 挂起等待恢复整个执行图在此终止。不是暂停在某个节点等待回调而是图的执行彻底结束。状态被持久化外部决策请求通过 SSE 事件推送到前端。完整的执行图拓扑如下IntentNode → EmotionNode → MemoryNode → ReasoningNode → ? │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ToolNode ECSNode END │ │ (正常完成) │ ▼ │ END │ (挂起等待) ▼ ReasoningNode (循环)为什么ECSNode要连接到END而不是挂起等待因为 LangGraph 的执行模型是流式的——每次astream()调用对应一次完整的图遍历。没有在图中间暂停的语义。暂停必须表达为图的终止恢复必须表达为新图的启动。这不是实现上的妥协而是对推理暂停的一种更干净的建模暂停就是当前推理链的结束恢复就是一次全新推理的开始。3. 外部输入作为新上下文重新注入当外部输入完成后系统并不接着往下跑而是构建一个新的推理起点将外部决策结果作为高置信度上下文注入重新执行完整的推理流程恢复路径GraphRunner.resume()方法处理恢复。它不会加载之前的执行状态而是构建一个全新的GraphState# workflow/graph_runner.py — GraphRunner.resume() ecs_context build_continuation_context(continuation_data) initial_state GraphState( conversation_idsession_id, semantic_inputSemanticInput( textf请根据我刚才提交的表单信息给出回复。\n\n{ecs_context}, ), last_human_input{ action: continuation_data.action, form_data: continuation_data.form_data, field_labels: continuation_data.field_labels, }, ) orchestrator GraphOrchestrator(...) workflow orchestrator.build() app workflow.compile() asyncfor output in app.astream(initial_state, config{recursion_limit: 50}): ...几个关键设计选择为什么不断点续跑系统中存在 checkpoint 机制_save_checkpoint/_load_checkpoint但恢复流程故意没有使用它。原因是外部决策的返回结果可能改变推理的所有前提——意图判断、情绪推断、记忆检索都可能因为新信息而产生不同结论。如果从断点继续这些节点的输出是基于旧信息的系统会在新信息和旧推理之间产生不一致。上下文注入如何工作build_continuation_context()将结构化的表单数据转换为 LLM 可读的上下文字符串同时根据表单复杂度HIGH/MEDIUM/LOW生成不同粒度的响应指导。外部输入不是直接丢给模型的原始数据而是经过格式化的、带有元信息的上下文块。last_human_input的作用是什么它以原始结构化格式保留外部输入与semantic_input.text中的自然语言表示形成互补。下游节点可以选择直接读取结构化数据而不必从自然语言中重新提取。这种方式的好处在于推理路径始终是完整的系统可以自然地重新评估意图、情绪、记忆等因素外部输入不会被当作临时补丁而是正式上下文的一部分链式外部决策恢复后的推理可能再次触发外部决策。GraphRunner.resume()在流式输出中检测ecs_request# 恢复执行中检测链式 ECS if ecs_request in update and update[ecs_request]: ecs_req update.get(ecs_full_request) if ecs_req: store_ecs_request(ecs_req, session_id) ecs_payload self._format_ecs_payload(ecs_req, session_id) yield self._format_sse(ecs, {type: ecs, payload: ecs_payload})这意味着外部决策不是一次性机制而是可组合的。一次推理恢复后如果新信息引发了新的不确定性系统会再次挂起。这种递归能力是将外部决策建模为执行图中的一等节点而非特殊分支带来的自然结果。五、为什么这种设计更可靠1. 不确定性被显式建模系统不再假装我已经知道答案而是承认当前状态下内部信息不足以继续。这种承认本身是一种工程成熟度。在 Wenko 中这表现为status: suspended是一个与processing和error平级的状态——不是异常不是降级而是执行模型的正常分支。2. 外部输入的价值被最大化结构化的外部决策输入减少歧义降低模型解释成本提高后续推理的稳定性在实现层面这依赖两个机制结构化采集ECSField的类型系统TEXT,SELECT,NUMBER,SLIDER,DATE,BOOLEAN等 11 种字段类型确保返回数据的类型安全。模型不需要从我大概每周听三次中提取频率值——它直接收到{frequency: 3}。持久化与复用ecs_handler将外部决策结果写入工作记忆working memory的context_variables以ecs_{request_title}为键。这意味着同一决策的结果可以在后续推理中被复用而不需要重复询问。3. 推理与交互职责清晰分离推理阶段系统负责判断缺什么外部决策阶段外部世界负责给什么恢复阶段系统负责如何使用这些信息每个阶段只承担一种责任。在执行图中这三个阶段对应三段独立的执行路径判断阶段IntentNode → EmotionNode → MemoryNode → ReasoningNode在ReasoningNode中决定是否需要外部信息暂停阶段ECSNode → END图终止状态持久化恢复阶段GraphRunner.resume()构建新图外部输入作为初始上下文重新经过完整的IntentNode → EmotionNode → MemoryNode → ReasoningNode链路三段路径之间没有共享的中间状态只有通过GraphState传递的显式数据契约。六、适合这种设计的典型场景这种外部决策步骤尤其适合以下场景需要结构化参数的任务计划、配置、筛选与真实世界状态强相关的操作用户偏好尚未明确、但对结果影响显著的决策任何继续猜测会显著降低质量的情况它并不适用于所有对话而是用于高价值、低容错的推理节点。结语为智能体推理引入外部决策步骤并不是削弱智能体能力而是承认一个事实并非所有认知都应当被压缩进一次语言生成。通过将关键决策显式外包、暂停执行并重新注入上下文系统获得了更稳定的推理基础也获得了与外部世界协作的能力。在 Wenko 的实现中这套机制最终体现为几个简洁的工程约束一个四状态的生命周期idle→processing→suspended→idle一条从ECSNode到END的终止边一个不从断点恢复、而是从头构建新推理的resume()方法一份结构化的数据契约ECSRequest→ECSResponseData→ECSContinuationData-END -如果您关注前端AI 相关领域可以扫码进群交流添加小编微信进群关于奇舞团奇舞团是 360 集团最大的大前端团队非常重视人才培养有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。