研发数字员工如何工作：Workflow、Agent 与 Coding Agent 的职责边界

从控制流归属出发，分析企业工作流与 Agent 的关系，明确开发数字员工中确定性流程、模型判断和代码执行的职责边界。

系列：从零构建企业级 AI Agent · 第 03 篇

前两篇文章分别讨论了企业级 Agent 的总体挑战，以及智能开发人员工作台的产品定位和任务模型。

在第二篇中，我们提出了一个基本架构原则：

模型提出判断，确定性程序负责验证和执行约束，企业系统保存最终事实，人负责高风险和高歧义节点。

但这个原则真正落到实现时，还会遇到一个更具体的问题：

研发数字员工的工作过程，究竟应该预先编排成 Workflow，还是交给 Agent 自主决定？

一方面，企业流程需要稳定、可追踪和可审计；另一方面，需求分析、问题诊断和代码修改又很难预先穷举路径。如果所有步骤都被固定，系统很容易退化成僵硬的自动化脚本；如果所有控制权都交给 Agent，系统又难以保证权限、状态和结果的可靠性。

通用 Agent 兴起之后，传统工作流编排产品在市场叙事中的存在感似乎也在下降。用户更愿意说“交给 Agent 完成”，而不是先打开流程画布，逐个配置触发器、条件和节点。

这是否意味着 Agent 将替代 Workflow？二者是互斥的 A 与 B，还是可以相互组合？开发数字员工又应该如何选择？

本文尝试从“谁拥有控制流”这个问题出发，回答这些疑问。

一、先澄清四个容易混淆的概念

1.1 业务流程描述组织如何完成一项工作

业务流程表达的是企业协作方式。例如一个研发任务可能经历：

需求分析
→ 技术方案设计
→ 开发与自测
→ Code Review
→ 提测
→ 测试
→ 上线准备
→ 发布

业务流程包含的不只是技术步骤，还包括角色分工、质量要求、审批责任和组织规则。它首先是一种业务约定，并不天然等于某个软件产品中的流程图。

1.2 Workflow 把流程转化为可执行状态

Workflow 负责将业务过程变成系统可以执行、等待和恢复的状态模型。

很多人把 Workflow 理解成固定的线性步骤。实际上，它可以包含：

• 条件分支和循环。
• 并行任务。
• 外部事件。
• 人工任务和审批。
• 超时与重试。
• 错误处理和补偿。
• 动态子流程。

Workflow 的“确定性”并不意味着每次都走完全相同的路线，而是：

哪些状态是合法的、什么事件可以触发变化、进入下一阶段需要什么条件，原则上由程序或流程定义预先约束。

例如：

代码修复完成
→ 必要检查是否通过？
├── 否：返回修复
└── 是：是否已经部署测试环境？
         ├── 否：等待部署
         └── 是：标记已修复，等待测试回归

不同任务可以走过不同路径，但不能跳过组织要求的状态和证据。

1.3 Agent 在运行时决定下一步

Agent 的核心不只是调用大模型，而是让模型拥有一部分控制流决定权。

Anthropic 将 Workflow 与 Agent 区分为：前者通过预定义代码路径编排模型和工具，后者由模型动态决定过程和工具使用。对于路径明确、重复性高的任务，Workflow 更可预测；对于无法提前知道具体步骤的任务，Agent 更有价值。

例如，面对一个接口偶发 500 的问题，Agent 可以在运行时决定：

• 先查询日志还是先阅读代码。
• 需要检查哪些模块。
• 是否需要查找历史 Bug。
• 当前信息是否足够。
• 应该调用哪些工具。
• 需要补充哪些测试。
• 是否应该向开发人员提问。

这些路径很难在系统设计阶段全部列出。

1.4 Coding Agent 是专业执行器

Coding Agent 是面向代码仓库的专业 Agent，通常具备：

• 阅读和检索代码。
• 编辑文件。
• 执行命令。
• 编译和运行测试。
• 分析失败结果并继续修改。
• 生成 Diff 和提交说明。

开发数字员工不等于 Coding Agent。

开发数字员工拥有企业身份、项目职责、WorkItem、协作上下文和长期任务状态；Coding Agent 则是它在需要操作代码时调用的专业执行器。

开发数字员工
├── 企业身份与职责
├── WorkItem 和 Workflow
├── 业务上下文
├── 通用模型推理
├── 外部系统工具
└── Coding Agent

二、让 Workflow 与公司流程匹配有什么价值

2.1 把隐性规则变成可执行约束

企业中存在大量没有被正式写下来的规则：

• 哪个团队负责哪个项目。
• 哪类修改需要哪些人员 Review。
• 哪些检查通过后才能部署。
• 谁可以更新 Bug 状态。
• 哪些模块属于高风险范围。
• 哪些操作必须经过审批。

如果这些规则只存在于人的经验中，Agent 很难稳定遵守。

Workflow 可以将它们表达为：

状态
+ 进入条件
+ 权限
+ 审批点
+ 超时规则
+ 验收证据

这相当于把组织运行方式中最重要的不变量，编译成系统可以执行和验证的规则。

2.2 协调人、Agent 与多个系统

企业研发任务通常同时涉及：

• 开发人员和测试人员。
• 开发数字员工。
• 云效等工作项系统。
• 飞书等协作系统。
• Git、PR/MR 和 Code Review。
• CI/CD 和测试环境。

Agent 可以完成其中某个复杂步骤，但整个任务还需要回答：

• 当前由谁处理？
• 现在正在等待什么？
• 外部事件到达后恢复哪个任务？
• 超时后如何处理？
• 谁对最终结果负责？
• 哪个系统保存最终业务状态？

这些问题属于 Workflow 和 WorkItem，而不是一次模型调用。

2.3 支撑跨越数天的长期任务

一个研发任务可能这样运行：

今天完成问题分析
→ 等待开发人员确认
→ 明天修改代码
→ 等待 CI
→ 等待测试环境部署
→ 两天后测试人员回归

模型不需要在这几天中一直运行，也不应该依靠一段聊天历史记住全部状态。

Workflow 负责保存任务进行到哪里、等待什么事件、已经执行过什么，以及恢复时应该从哪里继续。

这也是当前 Agent 编排框架重新引入持久状态、人工介入和恢复能力的原因。LangGraph 将自己定位为长时间、有状态 Agent 的编排运行时，允许在同一个图中混合确定性节点与模型节点；Temporal 则强调，即使模型的决定不可预测，已经发生的决定和工具结果仍应持久记录，进程恢复时不需要让模型重新决定一次。

2.4 建立权限、审计和责任边界

Workflow 可以明确：

• 数字员工以什么身份执行。
• 它可以访问哪些项目和仓库。
• 哪些动作允许自动完成。
• 哪些动作需要在线确认。
• 哪些动作需要独立审批。
• 谁承担最终业务责任。

Agent 是否能够想到某个操作，与企业是否允许执行该操作，是两个不同问题。

2.5 形成可分析的过程数据

当任务通过正式 Workflow 推进后，系统才能准确回答：

• 哪个阶段耗时最长？
• 有多少任务在等待人工？
• 哪类 Bug 经常被重新打开？
• Agent 在什么步骤经常失败？
• 哪些情况需要人工接管？
• 哪些检查没有产生实际价值？

聊天记录可以帮助理解个案，但很难直接替代结构化的流程数据。

三、流程匹配不等于复制现有流程

与公司流程匹配，并不意味着逐项复制现有的人工操作。在设计企业 Workflow 时，可以将流程内容拆成四类：

流程设计的目标不是百分之百还原现状，而是：

保留组织必须遵守的不变量，消除无价值摩擦，把无法预先枚举的判断交给 Agent。

四、为什么 Agent 兴起后，工作流产品看起来不再流行

目前很难证明工作流自动化本身正在衰退。更准确的判断是：它在产品前台的可见度下降了，但在 Agent 系统后台的重要性反而增加了。

4.1 Agent 销售结果，工作流销售搭建过程

传统工作流产品的典型交互是：

选择触发器
→ 拖入节点
→ 配置字段映射
→ 设置条件
→ 处理异常
→ 发布

用户必须提前知道任务应该如何完成。

Agent 的入口则更接近：

帮我处理这个 Bug，并在需要我决定时通知我。

Agent 承诺的是结果，工作流编排器展示的是实现结果的过程。前者更符合普通用户的心理模型，也更容易成为产品和市场叙事的中心。

4.2 自然语言降低了自动化门槛

传统流程编排通常要求用户理解：

• API 和连接器。
• 参数映射。
• 数据结构。
• 条件表达式。
• 错误路径。
• 状态管理。

Agent 允许用户先表达目标，再由模型选择工具、补充参数或询问信息。

因此，聊天或任务入口逐渐取代流程画布成为前台界面，但后台的连接器、权限、执行记录、重试和状态仍然存在。

4.3 大模型压缩了语义处理节点

传统流程可能需要：

关键词匹配
→ 正则提取字段
→ 规则分类
→ 选择负责人
→ 填充回复模板

大模型可能通过一次或少量调用完成：

理解消息
→ 提取信息
→ 分类
→ 推荐负责人
→ 生成回复

流程图上的节点减少了，难以用规则表达的部分被模型吸收。但模型节点之外的任务创建、权限检查、状态更新、通知和失败恢复依然需要 Workflow。

4.4 Agent 更擅长处理异常和长尾输入

传统工作流最擅长稳定、重复、字段清晰的任务。一旦遇到信息缺失、表达方式变化、多个问题混合、临时选择工具或无法预先枚举的异常，流程分支就会不断膨胀。

Agent 的核心价值正是处理这种不确定性。

但“不确定性处理得更好”不等于“确定性执行不再需要”。Agent 能够判断下一步应该创建 PR，不代表它应该直接获得不受限制的代码仓库写权限。

4.5 工作流产品正在重新包装为 Agent 基础设施

当前主流产品正在出现明显融合：

• Microsoft Copilot Studio 同时提供确定性的 Agent Flow 和由模型动态规划的生成式编排。
• n8n 既支持 Workflow 调用 Agent，也支持 Agent 将 Workflow 当作工具调用。
• LangGraph 在同一图中混合确定性节点和模型驱动节点。
• Temporal 用持久执行为动态 Agent 提供状态、等待和失败恢复。
• Camunda 将确定性流程、人工任务与 AI Agent 的组合称为 Agentic Orchestration。

因此，工作流不是消失了，而是从产品名称和交互界面中退到 Agent 的运行底座。

五、二者不是 A 与 B，而是两种控制权分配方式

Workflow 和 Agent 的根本差异，可以用两个简化模型表示。

5.1 Workflow 是显式状态转换

下一状态 = δ（当前状态，事件，规则）

例如：

CI 已通过
+ 已部署测试环境
→ 等待测试回归

转换规则来自业务设计和确定性程序。

5.2 Agent 是运行时行动策略

候选行动 = π（任务目标，当前状态，上下文，可用工具）

例如：

读取日志
→ 定位相关模块
→ 搜索调用链
→ 修改代码
→ 选择测试

这些步骤由模型根据任务上下文动态决定。

5.3 企业系统需要在两者之间增加验证层

Agent 提出候选行动
          │
          ▼
Workflow / Policy 验证
├── 允许：执行并记录结果
├── 需要审批：暂停等待人工
└── 拒绝：返回 Agent 重新规划

也就是说：

Agent 决定“建议做什么”，Workflow 决定“是否允许这样做，以及做完以后任务进入什么状态”。

二者不是同一层面的竞争关系。Agent 提供运行时判断能力，Workflow 提供组织约束和可靠执行能力。

六、Workflow 与 Agent 的四种组合方式

6.1 Workflow 调用 Agent

接收反馈
→ 调用 Agent 识别是否为 Bug
→ 获得结构化判断
→ 程序创建或关联 WorkItem

外层路径固定，某个需要语义理解的节点由 Agent 完成。这是大多数企业场景最容易控制的方式。

6.2 Agent 调用 Workflow

Agent 判断需要创建 Draft PR
→ 调用“创建 Draft PR”工作流
→ 工作流完成权限、参数、幂等和结果确认

这是一种非常重要的安全模式。

Agent 不直接持有宽泛的 Git 写权限，而是获得一个语义明确、能力受限的工具。n8n 给出的类似例子是：Agent 不直接获得 CRM 写权限，而是调用一个只能添加备注的工作流。

6.3 Workflow 中包含 Agent 子流程

进入“问题诊断”状态
→ Agent 自主循环：
   查日志 → 读代码 → 提出假设 → 验证
→ 输出诊断结果
→ 返回主流程

外层业务生命周期确定，局部探索过程动态。

6.4 Agent 在运行时组合多个 Workflow

Agent 根据目标选择：
├── 查询相关 Bug
├── 获取日志
├── 启动代码修改
├── 创建 Draft PR
└── 通知负责人

Agent 是规划者，Workflow 则成为安全、稳定、可复用的企业技能。

这四种方式可以同时存在。真正需要选择的，不是整个系统使用 Workflow 还是 Agent，而是每一个控制点的决定权应该放在哪里。

七、如何判断一个步骤应该交给谁

可以从五个维度判断：

一个实用原则是：

高确定性 + 高风险 + 强审计
→ Workflow 占比更高

开放输入 + 难预测路径 + 依赖语义判断
→ Agent 占比更高

如果某一步虽然需要模型判断，但会产生高风险副作用，可以采用：

Agent 生成建议
→ Workflow 校验
→ 人工审批
→ 确定性执行

八、开发数字员工中的具体分工

8.1 外层生命周期由 Workflow 管理

第一个主动式 Bug 闭环可以表示为：

收到飞书反馈或云效事件
→ 验签、去重
→ 创建或关联 WorkItem
→ 确认项目与权限
→ 分配开发数字员工
→ 等待分析结果
→ 等待代码与测试
→ 等待人工 Review
→ 等待 CI
→ 等待测试环境部署
→ 标记 Bug 已修复
→ 等待测试回归
→ 关闭或重新打开

这些步骤涉及企业状态、权限、等待和责任，应当由确定性程序管理。

8.2 内部探索由 Agent 完成

开发数字员工中的通用模型可以负责：

• 理解飞书消息和任务意图。
• 提取项目、模块、接口和环境信息。
• 判断信息是否足够。
• 查找候选重复问题。
• 分析需求和技术文档。
• 设计技术方案。
• 规划排查路径。
• 诊断问题和生成修复计划。
• 选择需要调用的工具。
• 总结结果、风险和下一步。

8.3 代码操作交给 Coding Agent

当任务进入代码执行阶段时，开发数字员工通过 CodingAgentProvider 提交受约束的代码任务：

WorkItem
→ Context Builder 生成任务上下文
→ 创建隔离工作区
→ 调用 Coding Agent
→ 阅读与修改代码
→ 编译和运行测试
→ 返回 Diff、日志和测试结果

Coding Agent 可以自主决定修改哪些文件、运行哪些命令，但它不能自行决定是否拥有目标仓库权限，也不能自行宣布业务任务已经完成。

8.4 外部副作用通过受限工具暴露

不应直接给 Agent 一个宽泛的“调用云效 API”或“执行 Git 命令”工具，而应提供语义明确的能力：

findRelatedBugs()
createOrLinkWorkItem()
addBugComment()
createDraftPullRequest()
requestCodeReview()
markBugFixed()
notifyOwner()

每个工具内部负责：

• 身份与权限。
• 参数校验。
• 幂等。
• 重试。
• 外部结果确认。
• 审计记录。

这样 Agent 可以灵活规划，却无法绕过企业约束。

九、一个更具体的运行模型

开发数字员工处理任务时，可以形成如下循环：

1. Workflow 激活 WorkItem
2. Context Builder 构建本轮上下文
3. Agent 输出结构化候选行动
4. Policy 检查权限、风险和前置条件
5. Executor 或 Coding Agent 执行
6. 外部系统返回真实结果
7. 结果写入 Run、Artifact、Evidence 和 DomainEvent
8. Workflow 根据结果推进、等待或重新调度

Agent 的输出不应只是自然语言，而应尽可能结构化：

AgentDecision
├── intent
├── proposedAction
├── target
├── parameters
├── rationale
├── contextReferences
├── riskLevel
└── requiredApproval

Policy 层再返回：

PolicyDecision
├── allow
├── denyReason
├── approvalRequired
├── preconditions
└── idempotencyKey

这使模型判断、企业规则和实际执行可以分别测试和审计。

十、总结：用 Workflow 表达不变量，用 Agent 处理不确定性

Workflow 与 Agent 不是两种互斥的产品，也不是简单的新旧技术替代关系。

它们代表的是两种不同的控制方式：

• Workflow 将组织已经明确的规则转化为可执行状态。
• Agent 根据运行时上下文处理无法预先枚举的问题。
• Coding Agent 在受控工作区内执行专业代码任务。
• Policy 和 Approval 决定候选行动能否产生真实副作用。
• 外部企业系统保存最终业务事实。

通用 Agent 的兴起，没有消灭工作流。它只是让工作流从用户直接操作的前台产品，逐渐转化为 Agent 背后的任务、权限和可靠执行底座。

对于开发数字员工而言，合理的系统不是让 Agent 自由操作所有系统，也不是把它限制在一条完全固定的脚本中，而是：

用 Workflow 表达组织的不变量，用 Agent 处理运行时的不确定性；让 Agent 可以选择经过治理的 Workflow，让 Workflow 可以在需要判断的节点调用 Agent。

Agent 越接近真正的企业员工，越需要 Workflow 为它提供任务状态、权限、审批、等待恢复、审计和责任边界。

下一篇将进一步进入开发人员工作台的实现：如何用 WorkItem 状态机、Timeline、Evidence 和 Approval 建立一个无需 Agent 也能运行的领域骨架。

参考资料

1. Anthropic：Building effective agents — 区分预定义路径的 Workflow 与模型动态控制的 Agent，并讨论各自适用场景。
2. Microsoft Copilot Studio：Agent flows overview — 确定性 Agent Flow、人工介入、连接器和流程可见性。
3. Microsoft Copilot Studio：Apply generative orchestration capabilities — 生成式规划、工具调用、控制边界和审批方式。
4. n8n：Introducing n8n Agents — Agent 调用 Workflow、Workflow 调用 Agent，以及凭证和审批边界。
5. LangGraph overview — 混合确定性步骤和模型步骤的长时间、有状态 Agent 编排运行时。
6. LangChain：What is an AI agent? — 从模型拥有多少控制流解释 Agent 的自主程度。
7. Temporal：Of course you can build dynamic AI agents with Temporal — 非确定性 Agent 决策与确定性、可恢复执行之间的关系。
8. Camunda：The Case for a Central Business Orchestration Layer — 在同一业务编排中组合确定性流程、人工判断和不同自主程度的 Agent。