概念/概念定义
Orchestrator 与 MessageHandler 门面：控制流的树干与表演的门面
出自东方屹腾执行型 Agent 落地（案例提供 梁博）
概念定义
一个执行型 Agent 跑起来之后，所有能力都得有个家。这个家就是 Orchestrator——整个运行态执行流的编排器，Agent 运行的核心骨架。从拿到用户对话输入开始，它解析链路上的控制信号，按信号编排各环节动作：调用某项能力、在某环节蒸馏记忆、检索外部知识、判断本次对话完成并合成回复。Agent 表现出的理解意图、有记忆、能总结经验、能调技能工具，本质上都是在这棵控制流树干上长出的枝叶。
使用说明
它的运行节奏可以概括为发散与收敛交替：发散、收敛、再发散、再收敛。LLM 带来的增量，是能在各种边界上把自然语言信息收敛锚定到控制信号上，从而驱动看似自由的智能活动。每一步看似在自由选择，下一步的走向却已被前面的控制信号约束住。自然语言负责发散，控制信号负责收敛，Orchestrator 负责在每个环节把发散的结果重新收敛回确定的控制流。
Orchestrator 不必暴露在最外层。最外层封装一个 MessageHandler 薄门面，承接用户输入再转给 Orchestrator，专职负责给用户展示层的能力。Orchestrator 执行时自由发出符合统一结构规范的活动事件，MessageHandler 在一个通道里监听这些事件、用 SSE 渲染输出，让用户看到打字机效果的执行流和对话流。这些表演逻辑不耦合进 Orchestrator，让它专注控制。东方屹腾后端选了 Go，正好用原生协程和通道把这种事件发布订阅写得很轻——其它主流语言也能做，只是要写更多代码。
这套结构能避免一类常见的耦合：把展示逻辑和控制逻辑混在一起。一旦渲染、推送、打字机效果写进了控制流主干，控制流就难以读清，加一个新的输出形态要改动核心，改一处推送也可能碰坏编排。把展示逻辑剥到门面里，控制流主干只负责按信号编排动作，前端如何展示与它无关。
意图识别产出控制信号之后，下一步是定义信号的消费者，这映射成一种拦截和路由模式，消费者就是意图网关组件。有了它，闲聊可以直接用编排好的机械式对话结束，连回复都不必调 LLM 合成，而查询、任务、兜底各自编排不同的下游执行链。意图网关的输入是控制信号，输出是明确的下游活动编排链。整条链路的大边界是确定的：总入口接原始对话、先定意图，是 pre 阶段，结尾合成返回用户的对话是 post 阶段，中间的 middle 阶段才是可灵活编排的部分。在东方屹腾的薪资组搭建场景里，正是这条 pre-middle-post 骨架，让一句口语化的诉求被收敛成意图、路由到对应执行链，再一步步编排出向量匹配、建快照、导入模板这串有严格依赖的动作。Orchestrator 落地之后，各项能力单元就都有了承载它们的位置，可以专注往上叠加。
何时需要
当你的 Agent 要承载多种能力、按不同意图走不同执行流，而你又希望控制逻辑保持干净、展示形态可以独立演化时。把控制信号怎么被识别出来这件事往前看，就是控制平面与叙事平面的二元论；把意图怎么收敛成可执行信号这件事讲透，就是意图即编译。