混合架构

一句话理解：生产系统很少是纯 Workflow 或纯 Agent。要么在确定性流程里嵌入一个“需要判断”的 Agent 节点，要么让 Agent 把确定性的部分交给 Workflow 或脚本执行。设计的关键在于划清边界、定好接口。

前面几课分别讲了 Workflow 模式和 Agent Loop，好像两者是两条独立的路线。但如果去看真正稳定运行的 Agent 产品，会发现它们几乎都是混合体：触发、分流、校验、审批、执行由确定性的代码负责，只有真正需要判断的环节才交给模型自由决策。

混合架构回答的是一个很实际的问题：确定性和灵活性，能不能兼得？ 答案是可以，前提是清楚地知道每一段该交给谁。

两种嵌套方向

方向 A：Workflow 为主，嵌入 Agent 节点

外层流程是固定的，Agent 只是其中一个节点：它有明确的输入（一条工单和相关上下文）、受限的能力（只读工具、步数上限）和约定格式的输出（原因、证据、建议）。整个系统的可预测性由外层保证，处理“规则写不完”的长尾情况则交给 Agent。

方向 B：Agent 为主，调用确定性的 Workflow

Agent 决定做什么，但遇到“每次都必须以相同方式完成”的部分，就调用一个封装好的 Workflow 工具。标准周报的口径和计算过程永远一致，Agent 负责判断还需要补充哪些分析、怎么组织结论。

这种模式在前面的课程中已经多次出现：

• Skill 中的 scripts/，本质上是让 Agent 调用确定性程序，见「Skill、Tool、Workflow 与 Subagent」。
• Claude Code 的“动态工作流”：让 Claude 编写一个脚本，由脚本在后台调度许多子 Agent 并汇总结果。它的文档这样对比：使用子 Agent 时，由 Claude 逐轮决定下一步做什么；在工作流中，由脚本决定。这相当于 Agent 生成了一个 Workflow 来执行。

边界怎么划

逐个步骤判断，把每一步放到最合适的位置：

步骤特征	放在哪里	售后工单场景的例子
触发时机固定	Workflow（定时任务、事件）	每晚 2 点拉取待办工单；支付回调失败时触发
规则可以穷举	Workflow / 规则引擎	超过承诺时限未出库且订单已支付，直接归为发货延迟
需要根据中间结果决定查什么	Agent 节点	多种因素叠加的疑难工单
必须每次完全一致、可审计	Workflow 或脚本	退款金额计算、报表口径
生成自然语言说明或建议	LLM 调用（可在 Workflow 中）	给客服的处理说明
写操作、不可逆操作	程序校验 + 权限 + 人工审批	修改订单状态、发起退款

可以参考一个更细致的步骤归类方法：「步骤归类」。

接口决定混合架构的质量

Workflow 和 Agent 交接的地方，是混合架构最容易出问题的地方。三个接口要设计清楚：

1. 交给 Agent 的输入 Agent 节点不应该收到“处理这条工单”这样一句话，而应该收到完整的任务说明：目标、已知信息（规则分流阶段已经查到的数据）、可用工具、约束（只读、最多 15 轮）、完成标准。前面步骤查过的数据要传进去，避免 Agent 重复查询。

2. Agent 返回的输出 下游是程序，所以输出必须是结构化的，并且有明确的异常状态。例如：

{
  "ticket_no": "T-1024",
  "status": "diagnosed",
  "cause_category": "payment_callback",
  "cause_summary": "支付渠道配置变更后回调未同步，订单一直没有进入出库流程",
  "evidence": [
    {"tool": "get_payment", "finding": "9 月 3 日回调失败"},
    {"tool": "search_orders", "finding": "9 月 1 日以后同渠道 37 单回调失败"}
  ],
  "suggested_action": "escalate_to_payment_team",
  "confidence": "high"
}

status 除了 diagnosed，还应该有 insufficient_evidence、needs_human、tool_failure 等取值，让外层流程知道接下来走哪条分支。字段设计的原则见「输出契约」。

3. 校验与回退 外层流程在接收 Agent 输出时，要用程序校验：字段是否齐全、分类是否在允许的取值内、suggested_action 是否在该节点被授权的动作范围内。校验不通过时，可以让 Agent 重试一次（有次数上限），或者直接转人工。永远不要让 Agent 的自由文本直接驱动写操作。

一个完整例子：订单售后处理 Agent

把实战项目放进混合架构里看（对应实战项目中的「订单售后诊断 Agent」与「可执行的售后处理 Agent」）：

在这张图里，模型只在一个方框内自由决策，其余部分都是可测试、可审计的程序。审批与风险分级的设计见「操作分级」。

演进路径

混合架构通常不是一次设计出来的，而是逐步演进的。两条常见路径：

从 Workflow 出发，逐步引入 Agent 先用规则覆盖高频情况上线；持续观察“未知原因”分支里积累的案例；当规则越写越多、维护成本越来越高时，把这个分支替换成 Agent 节点。好处是风险可控，每一步都有对照数据。

从 Agent 出发，逐步固化 Workflow 先用一个通用 Agent 快速验证价值；上线后分析大量轨迹，找出反复出现的固定路径（比如 70% 的排查都是“查工单 → 查订单 → 判定发货延迟”）；把这些路径固化为 Workflow 或工具，Agent 只处理剩下的情况。好处是起步快，同时能降低成本、提高一致性。这条路径依赖完善的轨迹记录，见「持续改进闭环」。

两条路径的终点往往很接近：高频、确定的部分由程序完成，低频、需要判断的部分交给 Agent，两者之间由清晰的接口和校验连接。

常见误区

• “混合架构就是在流程里随便插一个 Agent。” 没有清晰输入、受限能力和结构化输出的 Agent 节点，会把整个流程的不确定性放大。
• “Agent 节点的输出可以直接驱动下一步操作。” 外层流程必须校验 Agent 的输出，写操作前还要经过权限检查和必要的审批。
• “架构定下来就不用改了。” 业务分布会变化，模型能力也在提升。今天需要 Agent 处理的长尾情况，明天可能已经可以固化为规则；今天必须写死的步骤，将来也可能交给模型。

产品经理检查清单

• 能否在架构图上圈出所有由模型自由决策的部分？这些部分是否足够小、边界是否清楚？
• 每个 Agent 节点是否都有明确的输入、受限的工具、停止条件和结构化输出？
• Agent 的输出在进入下游之前，是否都经过了程序校验？
• 写操作和不可逆操作是否都在 Agent 节点之外，经过了权限检查和审批？
• 是否有机制收集 Agent 节点的轨迹，用来发现可以固化成 Workflow 的高频路径？
• 如果 Agent 节点完全失效，系统能否降级为“规则处理 + 人工兜底”继续运行？

练习

完成本模块的综合练习（约 60 分钟）：

1. 选一个业务流程：销售下降分析、SEO 诊断或订单售后处理。
2. 分别画出纯 Workflow 版、纯 Agent 版和混合版三张架构图。
3. 对混合版，写出 Agent 节点的输入说明、可用工具、停止条件和输出契约（字段与异常状态）。
4. 填写对比表：

版本	可靠性	单次成本（估算）	处理长尾情况的能力	调试难度	适合的阶段
纯 Workflow
纯 Agent
混合

延伸阅读

• Building effective agents：各种模式的组合原则，以及只在确有必要时增加复杂度的建议。
• Extend Claude Code：子 Agent 与动态工作流的对比，一个产品内确定性编排与模型决策并存的例子。

下一步

Workflow 与 Agent 模式模块到此结束。无论选哪种模式，都需要一套运行系统来承载循环、工具、权限和状态。下一个模块从「什么是 Harness」开始讲这套系统。