上一篇在讨论生产质检的案例时，结论是混合架构——Workflow 负责实时判定，Agent 负责异常归因。这个结论是对的，但停在这里还不够，因为"混合"本身也需要设计，不是把两套技术摆在一起就叫混合架构。
这篇把这个案例拆细，说清楚两条链路怎么划分职责、怎么衔接，以及一个经常被放错位置的组件：知识库。
为什么同一个场景会需要两套技术
生产质检异常处理这个场景，表面上是一个完整的业务流程，但它在内部包含两种性质完全不同的子任务。
- 第一种是合格/不合格的判定。输入是检测数据，比对的是预定义的标准阈值，输出是一个二元结论。这件事的执行路径在设计阶段就可以完全确定：采集数据、与标准比对、输出判定结果、记录日志、触发后续动作。容错要求极高，一次漏判可能导致不合格品流入市场，召回成本可能远超整条产线的产值。这是典型的 Workflow 场景。
- 第二种是异常根因分析。输入是一个"判定为异常"的信号，但为什么异常，没有固定答案。可能是设备磨损导致加工精度下降，可能是这批原料的参数偏离了供应商规格，可能是昨晚调整工艺参数之后引入了新的误差，也可能是三个因素叠加。排查根因需要结合历史工单、设备维护记录、原料批次数据、工艺变更日志，逐一排查，动态推理。这件事的执行路径在设计阶段无法确定，每次异常的根因可能完全不同。这是 Agent 场景。
两种子任务在同一个场景里，但它们的执行逻辑、容错要求、工具调用方式都不同。强行把两者统一到一套技术里，要么 Workflow 要覆盖所有根因分析路径（写不完，而且写了也不准），要么 Agent 来负责质检判定（准确率和可审计性都难以保证）。对这个场景的核心目标来说，这两种单一方案都不合适。
两条链路的职责划分
混合架构的设计原则是：按子任务的性质划分链路，不按界面或系统划分。
链路一：Workflow 负责判定。
这条链路是实时的、自动化的、确定性的。生产线上的传感器采集数据，Workflow 拿到数据，和预定义的标准阈值比对，输出"合格"或"异常"，同时把判定结果和原始数据写入记录系统。核心判定环节不需要 LLM 参与，因为判定逻辑是规则驱动的，不需要自然语言推理。LLM 如果出现在这条链路里，通常也只会增加延迟和不确定性，收益很有限。
这条链路接入 MES 或 SCADA 系统，与产线直连，实时运行，零容错。
链路二：Agent 负责归因。
这条链路在链路一触发"异常"信号之后启动，不是实时的，是按需的。工程师看到异常报警，进入工作台，用自然语言描述问题：这台设备今天下午连续出现三次表面划痕异常，帮我分析一下原因。
Agent 接到任务，开始执行 Agent Loop。它需要查历史工单（这台设备上次维护是什么时候，维护内容是什么），查原料批次记录（这批零件用的是哪家供应商的材料，这个批次有没有其他问题），查工艺变更日志（最近有没有调整过这个工序的工艺参数），查设备传感器数据（磨损指标有没有异常趋势）。每一步的结果影响下一步的查询方向，执行路径是动态的。
最终，Agent 给出根因假设和建议处置方案，工程师确认后决定是立即停机维修、更换原料批次，还是调整工艺参数观察效果。
这条链路接入数字员工的工作台，异步运行，允许试错，有人工兜底。
两条链路怎么衔接
链路一是触发器，链路二是响应者。衔接点是"异常信号"。
技术上，Workflow 在判定为异常时，除了写入记录系统，还可以通过消息队列发出一条异常通知，通知里包含设备 ID、异常类型、时间戳、相关检测数据。工作台订阅这个消息队列，异常通知到来时，自动在工程师的工作台界面生成一个待处理任务。工程师选择处理，工作台用异常通知里的数据作为初始上下文，启动 Agent。
这条衔接路径有几个设计要点。首先，链路二的触发是异步的，不阻塞链路一的实时判定。其次，链路二使用链路一的输出数据作为初始上下文，不需要工程师手动转述问题，减少信息遗漏的风险。第三，链路二的结论不自动写回链路一，工程师的确认是必须的，这保证了最终执行决策始终有人负责。
知识库应该放在哪一层
这是整个架构里最容易放错的一个组件。
一个常见的错误做法是：把知识库完全塞进 Agent 的私有执行层，让 Agent 在推理时直接检索、直接维护。逻辑上看起来很顺：Agent 需要参考某些知识，就去检索，检索结果进入上下文，推理继续。
但这有一个深层问题。知识库里存的是业务规则、操作规范、历史案例，这些是业务系统的一部分，有明确的归属和更新责任人。一旦让 Agent 私有化维护知识库，它就容易脱离既有的治理体系：谁来维护它、怎么保证内容准确、访问权限怎么控制，这些问题都会变得模糊。
更合理的做法通常是把知识库放在受治理的业务系统层或共享知识服务层，而不是让 Agent 自己单独维护一份。这样知识库有自己的访问控制、专人维护和版本管理；Agent 需要检索知识时，通过统一接口调用，这次调用会经过权限校验，也会被记录在审计日志里，和调用其他业务系统接口的方式一致。
这个设计的好处在于知识库的治理责任明确，它由懂业务的人维护，不是由 AI 基础设施团队单独维护；权限控制统一，知识库的内容访问和其他业务数据遵循同一套权限体系；Agent 的行为可审计，包括它检索了什么知识、检索结果是什么，都在调用日志里有完整记录。
把知识库放在业务系统层，看起来多了一层调用，实际上是把一个容易失控的组件纳入了既有的治理体系。
没有技术洁癖才是正确姿势
生产质检这个案例，最终的架构是 Workflow 处理判定、Agent 处理归因、知识库作为业务系统存在、两条链路通过消息队列衔接、执行结果经人工确认后写回。
这个架构里用到了规则引擎、消息队列、LLM、向量检索、人工审核，技术栈是混杂的，没有哪一种技术统一了所有环节。这在追求技术简洁的工程师眼里有时候是不舒服的。
但在企业场景里，这种"混杂"通常是对的。每种技术被用在它擅长的位置，而不是用一种技术强行覆盖所有场景。判定用规则，归因用 Agent，知识用业务系统管理，衔接用消息队列，最终决策留给人。每个环节的技术选择都对应一个清晰的理由，没有"我们统一用 Agent"这种追求一致性的冲动驱动的决策。
这不是说混合架构不需要设计，恰恰相反，混合架构比单一架构更需要清晰的边界定义。每条链路做什么、不做什么，链路之间怎么传递信息、传递哪些信息、谁有权修改传递的内容，这些问题都需要在设计阶段想清楚，不然"混合"会变成"混乱"。
边界清晰的混合架构，比强行统一的单一架构更稳健，也更容易随业务需求演进。这是企业 AI 工程里很少被明说但大多数有经验的团队都在实践的原则。
)
