一、热点引入：为什么企业开始「收回」AI的自由？
最近36氪的报道提到了一个值得深思的信号：企业级AI落地正在从「自主代理」向「工作流驱动」转向。Gartner、Forrester 等主流分析机构也在2024-2025年的报告中反复强调这一趋势——企业在生产环境中更愿意部署确定性强的Agent工作流，而非让AI完全自主决策。
这背后有个很朴素的理由：失控的AI代价太贵。
一个自主Agent可能在测试环境跑出漂亮的结果，但放到企业生产环境里，它可能在一个关键审批节点上「灵机一动」跳过了合规检查，把企业送到监管风险里。这是企业无法接受的。
作为Java工程师，我们对「确定性」有本能般的追求——事务、幂等、可审计这些都是刻在骨子里。所以工作流驱动的方式来构建AI Agent，对我们来说其实是更熟悉的思路，只是换了一个皮：把业务工作流引擎和LLM能力融合在一起。
二、两个核心范式：自主Agent vs 工作流Agent
在深入代码之前，我们需要先弄清楚这两个范式的本质差异。这直接影响系统设计的选择。
2.1 自主Agent的工作方式
自主Agent通常遵循一个经典的 Loop 循环：
// 经典自主Agent Loop（伪代码） while (true) { Action action = agent.decide(); // LLM决定下一步做什么 Result result = executor.run(action); if (result.isTerminal()) { break; // 任务完成或达到上限 } context.update(result); // 更新上下文，继续循环 }这个模型的优势很明显：极度灵活，适合开放性任务。但问题同样明显：
第一，不可预测。LLM的decide()方法输出不稳定，同样的输入可能产生完全不同的action序列，企业无法对AI行为做精确审计。
第二，Token消耗不可控。在复杂任务中，自主Agent可能循环几十上百次，每次都带完整的上下文，Token费用像漏油一样往外冒。
第三，错误累积。每一步的微小偏差在循环中不断放大，到后期可能完全偏离原始目标。LangChain的AgentExecutor就经常被人吐槽"走偏了"——你让它写一个接口，它一步步自己建了一个微服务集群。
2.2 工作流Agent的工作方式
工作流驱动的Agent，本质上是把LLM当作一个节点嵌入到预先设计好的业务流程中，而不是让它控制整个流程的走向。
// 工作流驱动的Agent（Java伪代码） // 流程定义：ReviewAgentWorkflow public class ReviewAgentWorkflow { public void execute(Task task) { // Step 1: 信息提取 - LLM只负责从文本中提取关键字段 ExtractedData data = extractionNode.extract(task.getContent()); // Step 2: 规则校验 - 完全确定性，由业务规则引擎控制 ValidationResult vr = ruleEngine.validate(data); if (!vr.isPassed()) { notifyHuman(vr.getViolations()); return; } // Step 3: 生成建议 - LLM在这里发挥作用，但输出范围被约束 Suggestion suggestion = generationNode.generate(data, task.getContext()); // Step 4: 人工审批 - 确定性介入点 Approval approval = humanReviewer.review(suggestion); if (!approval.isApproved()) { handleRejection(approval.getReason()); return; } // Step 5: 执行落地 - 确定性业务操作 executeAction(suggestion.getAction()); } }注意看上面这个设计：LLM被约束在特定节点中发挥作用，但整个流程的走向由业务逻辑控制。每个节点的输入输出都是结构化的，LLM不是在"决定做什么"，而是在"高效完成一个被明确定义的任务"。
这和我们Java里熟悉的策略模式有点像：把不确定的部分（LLM）封装在确定的框架内，而不是让AI控制全局。
三、工作流引擎的选择：自研还是开源？
Java生态里工作流引擎的选择其实不少。主流的有 Camunda、Flowable、Activiti（以及其fork Bonita），国内还有普元、炎黄等。这里重点说三个在AI Agent场景下最值得关注的。
| 引擎 | 优势 | 劣势 | AI场景适配度 |
|---|
| Camunda | BPMN规范完整，社区活跃，Cloud版本支持Kubernetes | 商业版贵，免费版功能有限 | ⭐⭐⭐⭐ |
| Flowable | 轻量，国产化适配好，文档清晰 | BPMN覆盖不完整，对复杂历史版本管理较弱 | ⭐⭐⭐⭐ |
| 自研状态机 | 完全可控，无外部依赖，性能好 | 工作量大，需要处理持久化、分布式状态 | ⭐⭐⭐（适合简单场景） |
在实际项目中，我发现 Flowable + LangGraph 的组合 是一个非常务实的选择。Flowable负责业务流程的编排和持久化，LangGraph负责Agent节点的推理逻辑，两者通过事件驱动解耦。
3.1 Flowable 与 LLM 节点的集成模式
Flowable 的 Service Task 可以用来嵌入LLM调用，但关键是怎么设计这个集成，让LLM调用不阻塞工作流的执行。
// Flowable Java Delegate 实现LLM节点集成 public class LLMReviewDelegate implements JavaDelegate { private static final Logger LOG = LoggerFactory.getLogger(LLMReviewDelegate.class); @Override public void execute(DelegateExecution execution) { String content = execution.getVariable("documentContent"); String prompt = buildPrompt(execution); // 异步调用LLM，避免阻塞Flowable线程池 CompletableFuture<String> future = llmClient.asyncComplete(prompt); future.thenAccept(result -> { execution.setVariable("reviewResult", result); LOG.info("LLM review completed for task: {}", execution.getProcessInstanceId()); // 触发下一步 - 通过消息事件让流程继续 sendEvent(execution, "ReviewCompletedEvent", result); }); // 注意：这里不等待结果，流程异步继续 } private String buildPrompt(DelegateExecution execution) { String template = execution.getVariable("promptTemplate"); Map<String, Object> vars = Map.of( "content", execution.getVariable("documentContent"), "taskType", execution.getVariable("taskType"), "rules", execution.getVariable("reviewRules") ); return promptTemplate.format(vars); } }这种异步设计非常关键。在企业级工作流中，一个LLM调用可能需要几秒甚至几十秒，如果流程引擎的线程在这里同步等待，整个流程吞吐量会非常低。通过异步事件驱动，Flowable可以同时处理数千个流程实例。
四、从36Kr热点看工作流Agent的落地场景
36氪这篇报道中提到的"企业人工智能最好基于工作流构建"，核心论点是Agent与工作流的混淆是AI风险潜入的主要方式。这个观点很值得咀嚼。
在实际落地中，有几个场景是最典型的：
4.1 客服工单处理
这是最常见的企业级AI Agent场景。传统的做法是LLM直接理解用户意图然后决定操作，缺点是不可控。用户说"帮我查一下上个月的订单"，它可能去查了财务系统——这在企业里是不可接受的。
用工作流来设计是这样的：
// 工单处理工作流（简化版） public class TicketWorkflow { public void handle(CustomerMessage message) { // Step 1: 意图识别（LLM）- 但输出是枚举，不是动作 Intent intent = intentClassifier.classify(message.getText()); // Step 2: 动作路由（确定性）- 根据intent类型分发 switch (intent.getType()) { case ORDER_INQUIRY: handleOrderInquiry(intent.getParams()); break; case REFUND_REQUEST: handleRefundFlow(intent.getParams()); break; case COMPLAINT: escalateToHuman(message, intent); break; } } }这里LLM的作用被严格限制在「意图分类」这一步，输出是预定义的枚举值，而不是一个可执行的action。这种设计让整个系统的行为变得可预测、可审计。
4.2 文档审核与合规检查
这个场景在金融、法律、医疗行业特别常见。工作流Agent的价值在于：把LLM的「理解能力」和规则引擎的「执行能力」结合在一起。
// 合规审核工作流核心逻辑 public class ComplianceReviewWorkflow { private final RuleEngine ruleEngine; // 确定性规则引擎 private final LLMClient llmClient; // LLM用于语义理解 public ReviewResult review(Document doc) { // Step 1: 规则匹配（确定性，毫秒级） List<Violation> ruleViolations = ruleEngine.check(doc); // Step 2: 语义检查（LLM辅助）- 检查规则无法覆盖的语义风险 List<SemanticRisk> semanticRisks = llmClient.analyzeSemanticRisk(doc); // Step 3: 人工复核介入点 if (ruleViolations.isEmpty() && semanticRisks.isEmpty()) { return ReviewResult.pass(); // 无风险，自动通过 } else if (semanticRisks.stream().anyMatch(Risk::isHigh)) { return ReviewResult.requireHumanReview(ruleViolations, semanticRisks); } else { // 中低风险，生成建议供人工确认 return ReviewResult.suggestFixes(ruleViolations, semanticRisks); } } }这个设计有一个重要的工程原则：确定性规则先行，LLM在后。规则引擎能搞定的事情不用LLM，LLM只在规则覆盖不到的语义层发挥作用。这样做有两个好处：一是性能好（规则引擎是毫秒级），二是可解释性强（规则匹配的结果是确定的，可以精确审计）。
五、生产环境的关键工程挑战
纸上谈兵容易，真正在生产环境跑起来会发现一堆问题。下面几个是我踩过坑之后总结的。
5.1 状态管理与断点恢复
工作流长时间运行（数小时甚至数天），中间一旦出现故障，必须能从断点恢复，而不是重新开始。Flowable本身支持状态持久化，但和LLM节点结合时有个坑：LLM调用是外部的，可能返回了但工作流状态还没更新。
// 带幂等性的LLM节点调用（Java实现） public class IdempotentLLMNode { // 每个LLM调用必须关联唯一的幂等Key public String executeWithIdempotency( String workflowId, String nodeId, String prompt) { String idempotencyKey = workflowId + "_" + nodeId + "_" + prompt.hashCode(); // 检查是否已经执行过（从状态存储中） Optional<String> cached = stateStore.get(idempotencyKey); if (cached.isPresent()) { LOG.info("LLM call skipped (already executed): {}", idempotencyKey); return cached.get(); } // 执行LLM调用 String result = llmClient.complete(prompt); // 状态持久化（事务保证） stateStore.put(idempotencyKey, result); return result; } }这个模式在分布式环境下尤为重要。如果工作流实例在执行到一半时重启，重启后应该能检测到哪些LLM节点已经执行过并拿到了结果，哪些还没有，然后继续未完成的部分。
5.2 超时与重试策略
LLM调用本质上是网络请求，可能超时、可能返回错误。工作流节点的超时策略需要仔细设计。
// LLM节点超时与重试配置（Java伪代码） LLMNodeConfig config = LLMNodeConfig.builder() .timeoutSeconds(30) // 单次调用超时30秒 .maxRetries(3) // 最多重试3次 .retryDelaySeconds(5) // 重试间隔5秒 .fallbackPolicy(FallbackPolicy.ESCALATE_TO_HUMAN) // 兜底：人工介入 .build();一个重要的原则是：重试策略需要结合业务场景。对于「生成文章标题」这种场景，重试几次可能就够了；但对于「医疗影像诊断辅助」这种场景，3次重试失败后必须立即触发人工介入，而不是无限重试。
5.3 可观测性：怎么知道AI在做什么？
这是企业级AI Agent最容易忽视但又最关键的部分。传统工作流有日志、监控、审计，但LLM节点的输入输出是半结构化的，传统的监控手段不够用。
// 工作流节点执行追踪（Java实现） public class WorkflowTracer { public void traceNode(TraceContext ctx, String nodeType, Object input, Object output, Duration duration) { Span span = Tracer.startSpan("workflow.node") .tag("workflow_id", ctx.getWorkflowId()) .tag("node_type", nodeType) .tag("node_id", ctx.getNodeId()) .tag("duration_ms", duration.toMillis()) .tag("llm_model", ctx.getLlmModel()); // 记录输入输出摘要（脱敏后） span.log("input_tokens", ctx.getInputTokens()); span.log("output_tokens", ctx.getOutputTokens()); span.log("latency_ms", ctx.getLatencyMs()); // 异常情况单独标注 if (ctx.hasError()) { span.tag("error", ctx.getErrorMessage()); } span.finish(); } }在生产环境中，建议把LLM调用的tracing数据和业务workflow的tracing数据放到同一个trace里，这样排查问题时可以从业务视角看到AI在每个环节的表现，而不需要去LLM日志里大海捞针。
六、面试题实战
题目一：工作流驱动的Agent与自主Agent在企业生产环境中的核心差异是什么？如果让你设计一个客服工单处理系统，你会选择哪种架构？为什么？核心差异：
自主Agent的决策权在LLM，流程走向不确定；工作流Agent的决策权在业务流程，LLM作为节点被调用。
架构选择：
客服工单处理系统应该选工作流架构。原因有三：
第一，合规要求：企业客服需要可审计，AI的每个动作必须有记录，自主Agent无法做到精确审计。
第二，风险控制：客服涉及退款、投诉等高风险操作，AI不能自由决定处理方式，必须在预设规则内运行。
第三，成本可控：自主Agent的Token消耗不可预测，工作流架构可以精确计算每个工单的成本。
具体设计：意图分类（LLM）→ 规则匹配（确定性）→ 动作执行（业务系统）→ 人工复核（高风险场景）。LLM只负责语义理解，不直接操作业务动作。题目二：在工作流驱动的AI Agent系统中，如果LLM节点执行超时或者返回了不符合预期的输出，系统的容错机制应该如何设计？请从重试策略、降级方案、人工介入三个维度说明。重试策略：
指数退避重试（Exponential Backoff），首次重试间隔1秒，第二次2秒，第三次4秒，避免对LLM API的瞬时压力冲击。同时设置最大重试次数（如3次），超过后进入降级。
降级方案（Fallback）：
降级分为多个级别：
· LLM超时 → 尝试调用备用模型（如从GPT-4降级到GPT-3.5）；
· 模型不可用 → 返回预设的默认回复并标记「AI暂时不可用」；
· 输出不符合Schema → 触发输出校验，校验失败进入人工处理。
人工介入：
人工介入需要设计明确的触发条件和交接流程。触发条件：连续重试失败超过阈值、LLM输出置信度低于设定值、检测到内容安全风险。交接时需要把上下文完整传递给人工客服，避免用户需要重复描述问题。
关键原则：人工介入后，系统应该记录本次失败的完整上下文，用于后续的根因分析和模型优化。愿你在复杂与确定之间，找到属于自己的架构之道。
技术的本质，不是消除不确定性，而是让不确定性变得可以管理。 🌄
夜雨聆风
