Agent 不只是会想：Conductor 把思考接进耐久工作流 (2026)

节目导览

如果一个 Agent 的每次思考都变成一个工作流步骤，它就不再只是一次接口请求。它可以停在人工审批前，等上几天，再从原来的位置继续。Orkes 在 9 月 1 日发布的 Conductor 更新，正是在做这件事：让 Agent 和传统工作流跑在同一个持久化引擎上。1

本期追踪一个工程问题：Agent 的“思考”怎样变成可恢复、可审计、又不越权的循环？

你会听到：

Conductor 这次更新到底改变了 Agent 的运行边界。
为什么把模型思考、工具调用和人工审批都记录进同一个运行，能解决长任务最容易丢失的那部分状态。
为什么工具和 guardrail 应该属于工作流定义，而不只是写在 prompt 里的约定。
如果把这个模式落到自己的系统里，哪些状态、权限和恢复测试必须先做。

一个变化：Agent 也成为工作流

这次更新最值得注意的地方，不是又多了一个 Agent SDK，而是运行单位变了。

在 Conductor 的描述里，Agent 本身就是一个工作流。模型的一次思考可以成为一个 task。一次工具调用也可以成为一个 task。原来藏在应用内存、回调函数和临时队列里的过程，被放到了引擎持有的运行记录里。1

这会改变什么？先想一个很普通的长任务。Agent 查库存，发现需要调用另一个系统；接着它要申请人工审批；审批可能两天以后才回来。传统的接口式 Agent 往往要自己保存会话、步骤、工具结果和等待状态。服务一重启，开发团队就要回答：它现在走到哪一步，哪些动作已经发生，哪些动作可以重试？

Conductor 的做法，是让引擎保存这段过程。崩溃、部署、超时，甚至跨天等待审批，都不会天然抹掉运行位置。引擎从停止的步骤继续，已经完成的步骤不再被当成新的动作重复安排。模型的思考、工作流步骤和审批记录，也都落在同一个运行里。1

这里要把一句话说准：这不是在说模型变得更可靠，而是在说模型外面多了一层能保存事实的控制面。模型仍然可能判断错。引擎只是让系统知道，模型在什么时候做了什么，下一步为什么还没有发生。

真正的循环，不在 prompt 里

很多 Agent 系统把工具说明、权限提醒和安全要求写进 prompt。这样做可以帮助模型理解任务，但它不能单独构成执行边界。

Conductor 把工具和 guardrail 放进工作流定义。模型可以提出下一步，但引擎决定这一步是不是已经被声明、是否允许调度，以及输入和输出要不要先检查。一个没有写进工作流的工具，即使模型在文字里请求了，也不会被调度。引擎会把实际可用的工具告诉模型。1

这个设计把循环拆成了两件事。

第一件事是推理。模型根据上下文提出计划，选择它认为合适的工具，或者决定还需要什么信息。

第二件事是执行。工作流引擎验证这个计划能不能进入下一步，调用哪个已经注册的工具，如何记录结果，失败之后在哪里重试。

两件事分开以后，模型的自由度仍然存在，但自由度不再等于写权限。模型可以在结构里寻找路径，却不能凭一句自然语言凭空创造一个新出口。

这也解释了为什么 Agent 可以和传统工作流互相嵌套。一个 Agent 可以被放进订单处理、客服升级或数据审核流程里，成为其中一个步骤。反过来，Agent 也可以把一整段已经定义好的工作流当成工具调用。对模型来说，它看到的是一个可用能力；对系统来说，能力背后仍然有固定的步骤、分支和审计记录。1

持久化不等于没有重复风险

听到“从精确步骤继续”，很多工程师会立刻想到一个问题：如果外部工具已经成功写入，系统却在确认结果前崩溃，恢复时会不会再次写入？

这正是不能只听产品口号的地方。引擎可以保存自己的步骤状态，但外部系统的写入仍然需要幂等设计。创建工单、扣库存、发通知这类动作，都应该携带业务幂等键。重试策略也要区分读取、可重复写入和不可逆动作。审批通过是一条记录，真正改变外部状态的动作是另一条记录。

所以，“已经完成的步骤不会重复执行”应当理解为引擎对自身执行记录的承诺。它不自动替你证明所有外部副作用都只发生了一次。工程团队还需要在故障注入里验证三个时刻：工具已经成功但确认丢失，工具执行超时但结果未知，以及审批已经通过但后续作业还没启动。

这几个时刻很枯燥，却是 Agent 循环能不能进入生产的分水岭。没有测试，持久化状态只是更完整的日志。只有当恢复逻辑和外部系统的幂等协议一起工作，日志才会变成可继续执行的状态机。

把安全边界放在模型外面

Conductor 这次更新还给出一个很清楚的权限思路：工具、分支和审批人都先写进工作流，模型只能在这个范围里提出动作。

这种做法至少能挡住两类常见问题。第一类是模型请求了根本不存在的工具。系统可以在调度前拒绝它。第二类是工具参数本身有风险。引擎可以在工具执行前检查输入，在结果返回后检查输出，再决定是否进入下一步。1

但这仍然不是完整的安全方案。工作流定义可能写错，工具服务可能权限过大，外部数据可能带着提示注入，审批人也可能看不清楚自己批准的到底是什么。把 guardrail 从 prompt 移到控制层，是必要条件，不是充分条件。

落地时可以把一条高风险循环拆成四道门：先读取和整理证据，再提出结构化计划；计划通过权限和参数检查后，才调用低风险工具；涉及外部写入时，再进入人工审批；动作完成以后，把结果和原始输入一起写回运行记录，供下一轮验证。

这里的关键不是让 Agent 每一步都等人点按钮。低风险读取可以自动走。关键是让系统明确区分：模型提出了什么，系统允许了什么，工具实际做了什么，谁批准了什么。

今天能做的工程验证

如果你正在做长任务 Agent，不必先迁移整套架构。可以先选一条会等待、会重试、还会产生外部副作用的真实流程，做一张最小运行记录。

记录至少包括：任务目标、当前步骤、模型看到的上下文、工具请求、工具输入、工具返回、审批决定、幂等键、重试次数和 trace。每一项都绑定同一个运行标识。下一次恢复时，系统必须能回答：最后一个确定完成的动作是什么，哪个动作的结果未知，恢复以后允许哪些动作继续发生。

然后做三组测试。让运行在工具成功后、确认返回前中断；让人工审批跨过一个部署周期；让模型请求一个没有注册的工具。每组测试都检查两件事：系统是否从可解释的位置恢复，外部状态是否出现重复或越权变化。

这套测试也会帮你区分两种产品价值。工作流引擎解决的是状态、调度、重试和审计。模型解决的是在允许的空间里提出下一步。把两者混成“Agent 自己会恢复”，最后往往只得到一个会自动重试的黑箱。

回到开头的问题

Agent 的思考要变成可恢复、可审计、又不越权的循环，答案不在于给 prompt 再加一段提醒，而在于把思考接到一个能保存事实的执行系统上。

Conductor 这次公开的方向，是让 Agent 和工作流共享同一个持久化引擎。它把模型思考、工具调用和人工审批放进一条可以追踪的运行里，也把工具边界和 guardrail 放回工作流定义。1

对工程团队来说，真正要验收的不是“Agent 能不能继续想”，而是中断之后，系统能不能说清楚哪里已经发生，哪里还没有发生，下一步为什么被允许。只要这三个答案还不稳定，Agent 就还没有获得生产级的循环能力。

这里是 AI Loop Engineering，我们明天见。

References

1
Conductor Now Runs Agents Alongside Your Workflows, on the Same Durable Engine
orkes.io