决定什么时候走哪个流程，什么时候派哪个 Agent，上不上 AI，失败后怎么处理。智能编排不是在替代 Workflow、Agent、AI，而是在把它们组织起来，让系统既可控，又灵活。| 工作流|| Agent 集合||| AI 能力|| Workflow|| 一个或多个执行者 ||| LLM/分类/推理/生成 || 工具 / API / 数据库 / 检索 / 系统 || 定义步骤顺序 || 会思考

更适合能流式返回模型过程：例如 reasoning、delta、状态变更能传结构化协议消息：例如 tool call、call_id、arguments、resume signal能与普通 HTTP 动作自然协同：例如提交 tool result、取消、查询最终态能作为跨浏览器、CLI、IDE、服务端的统一协议基座SSE：更适合前端消费的事件流：更适合 Agent 会话级协议编排。

不是越“智能”越好，而是要把智能放在真正需要判断的地方，把流程控制权留在编排层。- 智能编排：后厨经理，负责排菜顺序、分配厨师、协调上菜、处理催单和缺料。如果你以后自己做系统，别一开始就说“我要做 Agent 平台”。但如果你开饭店，同时来 100 桌客人，就必须有编排。- 多流程、多角色、多策略统一协调：智能编排。所以如果只是炒一个青菜，可能不需要后厨经理。- 需要查资料、调接口、读日志、写报告

工具调用|| 上下文拼装|| ERP/CRM/DB/Git|| 多步决策|| 引用来源|| 工单/测试平台|| 任务拆解|| 检索/召回/重排|| API/脚本/系统能力 || 观测 / Tracing / Eval / 安全 / 脱敏 / 权限|| 重试 / 超时 / 审批 / 回滚 / 任务编排 / 成本控制|

T5 | Encoder-Decoder | Text-to-Text | 翻译、摘要、问答、生成式任务 || LLaMA | Decoder-only | 自回归生成 | 和 GPT 类似，偏生成和通用推理 || GPT | Decoder-only | 自回归预测下一个词 | 对话、写作、代码、生成 |- 它不是和 GPT 平级的“另一种结构”，而是 GPT 这一路架构里的一个重要模型家族。|

因此：日常从页面点「检查」时，主要是流式路径；兜底是非流式的「直接 LLM」路径。“真实生效”的主链路是 前端。→ SSE 回前端。

而是因为行业主战场从“理解几个固定任务”变成了“一个模型处理尽可能多的生成与交互任务”，而这个舞台更适合 GPT 类模型。行业关注点从“单点理解任务”转到了“通用生成与智能体能力”，而这正好不是 BERT 最擅长的方向。很多企业内部系统里，BERT 类模型其实还在稳定干活，只是不像大模型那样“显眼”。BERT 很强，但它的强项不容易被普通人直接感知。3. BERT 不擅长“看得见的惊艳能力”BER

SSE 时代：重点是“把模型输出实时显示出来”Streamable HTTP 时代：重点是“把 Agent 协议稳定、统一、可扩展地传输出来”前者偏 UI streaming，后者偏 protocol streaming。一种更中立的 HTTP 流式承载层一套可演进的结构化消息协议更好的跨语言、跨宿主兼容性更自然的服务间调用和 SDK 抽象更方便承载 tool call、delta、state、e

SSE和都与基于 HTTP 的流式传输有关，但它们不是同一层面的概念。SSE：是一种具体的浏览器/HTTP 推送技术标准，全称。：通常指可流式返回数据的 HTTP 交互方式，更偏向一种能力描述或设计模式，而不是像 SSE 那样严格、单一的浏览器标准。SSE是一种“如何流”的标准方案。是“HTTP 请求/响应可以边生成边返回”的更宽泛能力，其中可以用 SSE，也可以不用 SSE。SSE 的全称是，即

Encoder-Decoder | Encoder 全看，Decoder 生成 | 很适合 | T5 |- Decoder 一边看自己已经生成的内容，一边看 Encoder 给的编码结果。| Decoder-only | 只看左边 | 最擅长 | GPT、LLaMA || Encoder-only | 左右都看 | 不擅长长生成 | BERT || 结构 | 看输入方式 | 会不会自然生成 | 代