Agent 别硬接:编排边界才是生产问题1×0:006:430:08开场1:03技术拆解2:51编排边界4:28工程意义5:55收尾0:08主持过去二十四小时里,没有看到足够扎实的一手 Agent Loop Engineering 新动态。本期把窗口扩大到近一周,讲一篇 Camunda 在七月八日前后发布的长文。它的题目很直白:把 LangChain 硬接到现有工作流引擎上,规模一大就会反噬。0:25主持这件事听起来像厂商立场,但问题很实在。很多团队已经有流程引擎,也已经用 LangChain 或 LangGraph 做过 Agent 原型。下一步很自然:流程走到某个节点,就调用一次 Agent。Demo 会动,流程图也好看,可一到等待、审批、重试、审计,边界就开始漏水。0:47主持Camunda 在文章里把这种做法叫 bolt-on architecture,可以理解成外挂式架构:工作流引擎调用 Agent 框架,Agent 框架再调用大模型。它能把 AI 放进旧流程,但也把状态、工具权限和审计记录切成了几块。1:03主持第一处裂缝是上下文。Camunda 文章说,当 Agent 需要等一个人回复、等一个审批、等外部事件时,很多系统会先退回流程引擎。等事件回来,再重新唤起 Agent。问题在于,Agent 并不是从原地醒来,它常常是靠历史消息、旧工具调用和一些状态字段重新拼出现场。1:25主持这和真正的恢复不是一回事。重新拼上下文会多烧 token,也会增加延迟。更麻烦的是,重建出来的现场可能和当时的推理状态有偏差。工程上你当然可以给 Agent 框架接 checkpointer,接数据库,接自己的恢复逻辑,但这时你已经开始重造一套小型工作流系统了。1:46主持第二处裂缝是工具治理。Camunda 原文举的点很关键:在流程层,工具调用通常是显式任务,谁能调用、参数怎么校验、失败怎么补偿,都能放进流程模型里。可在 Agent 层,大模型会动态决定调用哪个工具、按什么参数调用。你可以在提示词里写规则,但提示词不是执行层的门禁。2:09主持如果一个退款工具超过五百美元必须审批,这条规则最好不要只藏在某个 Agent 的系统提示词里。它应该落在工具真正执行之前,能被流程引擎、审批队列、决策表或权限系统强制拦住。否则同一个规则会散落在提示词、中间件和工具 wrapper 里,后面每多一个 Agent,就多一份漏掉的风险。2:31主持第三处裂缝是审计。外挂式架构里,业务流程有一套日志,Agent 框架有一套 trace,大模型供应商还有一套调用记录。事故发生以后,团队要跨三套系统拼时间线。小规模还能忍,企业流程一旦跑到成千上万实例,排查成本会变成常态成本。2:51主持Camunda 给出的解法是把 Agent 放进 BPMN 的 ad-hoc subprocess,也就是一段可以按任意顺序执行、重复或跳过的子流程。按照 Camunda 文档,AI Agent connector 会让大模型在这个子流程里选择工具,但真正执行工具、保存变量、做重试、处理事件和人工任务的,仍然是 Camunda。3:13主持这里可以把系统分成两层。外层编排管业务旅程,比如一个贷款申请从提交到审核再到放款。内层编排管 Agent 的行动,比如它想查知识库、问客户、找专员、算还款能力,每一步都先经过流程引擎。大模型负责提出下一步,编排层负责决定这一步能不能做、怎么做、出事后怎么恢复。3:38主持这和 Dapr 文档里的 DurableAgent 方向也能对上。Dapr Agents 在核心概念页里已经把普通 Agent 标成废弃,推荐 DurableAgent。原因也很直白:DurableAgent 是基于 Dapr Workflows 的工作流 Agent,有持久状态、自动重试、checkpoint、消息路由和跨故障恢复。它承认 Agentic system 本质上就是分布式系统。4:02主持Dapr 还给了一个小细节:因为 DurableAgent 依赖工作流事件溯源,运行时代码可能在等待外部活动后 replay,文档专门提供了 replay-aware logging,避免恢复过程重复打日志。这个细节很工程,也说明一件事:长循环 Agent 的难点不是让模型多想几步,而是暂停、恢复、重放、去重这些老问题又回来了。4:28主持所以今天这期要带走的判断是:Agent 框架和工作流引擎不该抢同一层职责。LangChain 这类框架擅长模型抽象、提示模板、工具调用封装和 RAG 脚手架。流程引擎擅长持久状态、人工任务、权限、重试、补偿、版本迁移和业务审计。把两者串起来没错,错的是让边界含糊。4:51主持最危险的形态,是流程层以为 Agent 框架会管好状态,Agent 层又以为流程系统会兜住业务规则。最后两边都只管了一半。这个时候出问题,表面上是某次工具调用失控,底下其实是系统没有一个明确的执行裁判。5:10主持对工程团队来说,设计 Agent loop 时可以先问四个问题。第一,Agent 暂停以后,完整状态存在哪里。第二,副作用工具执行前,谁有权强制拦截。第三,人工审批、超时、重试和补偿,是业务流程的一部分,还是每个 Agent 自己写一遍。第四,半年后要复盘某个案例时,审计链能不能在一个业务视图里看明白。5:36主持如果这些问题答不上来,就不要急着把 Agent 接进核心流程。先把工具分级,低风险查询可以让 Agent 自主调用;会改数据、花钱、发通知、触达客户的工具,要进入编排层。然后再决定哪些步骤适合让模型判断,哪些路径应该逐步沉淀成确定性规则。5:55主持Camunda 的文章当然带有自己的产品视角,不能把它当成唯一答案。但它抓住了一个正在变清楚的方向:生产级 Agent 不只是一个 reason-act-observe 循环,它还要活在一个能等待、能审批、能恢复、能查账的系统里。6:14主持今天回到自己的架构图时,可以找一条已经上线或准备上线的 Agent 流程,沿着每一次工具调用往下追:这一步是谁决定的,谁执行的,谁能拦住,失败后谁负责恢复。如果答案一路都落在同一个提示词里,那这条 Agent loop 还没有真正进生产。