上一篇在讨论生产质检的案例时结论是混合架构——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 工程里很少被明说但大多数有经验的团队都在实践的原则。