企业级 Agent

模型、Agent Runtime 与 Coding Agent 如何分工-开发工作台的运行时架构

从模型调用、Agent Runtime、Coding Agent、Workflow 和智能开发工作台的分层关系出发，说明开发数字员工如何被运行、约束和持续管理。

更新：2026-11-12

从模型调用、Agent Runtime、Coding Agent、Workflow 和智能开发工作台的分层关系出发，说明开发数字员工如何被运行、约束和持续管理。

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

前面的文章已经讨论了智能开发工作台的产品定位、研发任务模型、Workflow 与 Agent 的边界，以及角色融合对数字员工设计的影响。

接下来需要回答一个更接近实现的问题：

当工作台把一项需求交给开发数字员工后，真正执行任务的究竟是谁？大模型、Agent Runtime、Coding Agent 和 Workflow 分别位于哪里？

这个问题看起来只是技术选型，实际上会决定系统的状态归属、权限边界、失败恢复方式，以及未来能否替换模型或执行器。

一、开发数字员工不是一个大模型会话

把数字员工理解成“拥有固定提示词的大模型会话”，很容易得到一个可以对话的 Demo，却很难得到能够持续参与研发协作的系统。

一次真实的需求交付可能持续数天：

理解需求
→ 设计技术方案
→ 等待人工确认
→ 开发与自测
→ 联调
→ Code Review
→ 等待 CI 和测试环境
→ 处理测试 Bug
→ 等待回归
→ 发布

在这条链路中，模型调用只是若干执行步骤。需求状态、DRI、审批结果、外部系统事实和长期等待不能只存在于模型上下文中。

因此，需要先区分几个容易混淆的概念：

大模型 ≠ Agent
Agent ≠ 数字员工
Coding Agent ≠ 开发数字员工
工作台 ≠ Agent Runtime

大模型提供语言理解、推理和生成能力。
Agent围绕目标持续选择行动、调用工具并处理结果。
Agent Runtime负责让 Agent 可以被启动、跟踪、取消和恢复。
Coding Agent是面向代码仓库的专业 Agent。
开发数字员工是研发协作中的持续身份和责任主体。
智能开发工作台保存需求、权限、流程、证据和企业事实。

二、开发数字员工的五层架构

一个更清晰的运行结构可以分成五层：

智能开发工作台
需求 / DRI / Workflow / 权限 / 审批 / 证据
                    │
                    ▼
开发数字员工
身份 / 职责 / 能力 / 授权范围 / 当前任务
                    │
                    ▼
Agent Runtime
Session / Run / 上下文 / 工具调用 / 取消 / 恢复
                    │
                    ▼
专业执行器与企业工具
Coding Agent / 云效 / 飞书 / Git / CI/CD
                    │
                    ▼
大模型与外部系统
推理服务 / 代码仓库 / 项目系统 / 构建环境

这五层不是为了增加抽象，而是为了让不同变化停留在不同位置。

替换模型，不应改变需求模型。
替换 Coding Agent，不应改变数字员工身份。
从本地执行迁移到远程 Runner，不应重写业务流程。
Agent 运行失败，不应让需求或 Bug 进入错误状态。
Workflow 的门禁，不应依赖模型是否“记得”遵守。

三、大模型位于哪里，承担哪些功能

大模型位于运行时内部或下方，是智能能力来源，但不是工作台的业务状态机。

在开发数字员工中，大模型主要承担四类工作。

3.1 理解

理解需求目标、范围和验收标准。
从飞书消息中识别任务、问题和补充信息。
从代码、日志和文档中提取相关上下文。
理解 Code Review 意见和测试反馈。

3.2 推理与规划

分析需求影响范围。
形成技术方案和开发步骤。
诊断 Bug 候选原因。
根据工具返回结果调整下一步行动。

3.3 生成

生成技术方案草稿。
生成或修改代码与测试。
总结 Diff、验证结果和剩余风险。
形成面向人或协作群的进展说明。

3.4 工具选择

判断需要读取哪些文件。
决定是否运行构建或测试。
选择需要查询的企业系统。
在权限不足或信息不完整时请求人工输入。

模型不负责决定需求是否可以越过质量门禁，也不能把自己的推测直接写成企业事实。

四、ModelProvider 与 AgentRuntimeProvider 不是一回事

并不是所有需要大模型的场景都需要启动完整 Agent。

例如以下任务通常只需要一次模型调用：

消息分类。
内容摘要。
字段提取。
相似问题判断。
负责人候选推荐。

它们更适合通过 ModelProvider 完成：

输入
→ 单次模型推理
→ 结构化输出

而以下任务更适合交给 AgentRuntimeProvider：

需要多步规划。
需要持续读取环境并调整行动。
需要调用多个工具。
可能暂停等待人工输入。
需要取消、超时或恢复。
需要保存完整执行轨迹。

目标
→ 规划
→ 调用工具
→ 观察结果
→ 调整计划
→ 继续执行或等待
→ 形成结果

将二者分开，可以避免把每一次分类和摘要都变成昂贵、难以预测的长期 Agent 任务。

五、Agent Runtime 负责什么

Agent Runtime 解决的不是“模型够不够聪明”，而是“一个 Agent 任务如何可靠运行”。

它通常需要处理：

创建和恢复 Session。
接收目标与上下文快照。
选择模型、工具和运行策略。
记录文本、工具调用、用量和错误事件。
管理运行中、等待输入、等待审批、成功、失败、取消和超时等状态。
在进程退出、网络错误或外部系统暂时不可用时提供明确结果。
让工作台能够查询、取消和审计一次执行。

一次运行可以抽象为 Run：

Run
├── target：需求、开发任务或 Bug
├── digitalEmployeeId
├── taskType
├── providerId
├── goal
├── contextSnapshot
├── requiredCapabilities
├── status
├── events
├── result
└── error

这里的 SUCCEEDED 只表示 Agent 任务完成，不代表需求已经完成，也不代表技术方案已经批准、代码可以合并或 Bug 已经关闭。

六、Coding Agent 是专业执行器

Codex、Claude Code、Gemini CLI 等 Coding Agent 已经具备代码仓库理解、文件修改、命令执行和测试等能力。开发数字员工没有必要从基础模型 API 开始重新实现完整 Coding Agent。

Coding Agent 更适合负责：

阅读和搜索代码。
分析变更影响。
修改代码和测试。
执行构建、静态检查和测试。
生成 Diff、代码说明和剩余风险。
协助处理 Code Review 意见。

工作台仍然负责：

为什么启动这次代码任务。
任务属于哪个需求或 Bug。
可以访问哪个仓库和工作区。
是否允许写代码、执行命令或联网。
哪些结果需要人工确认。
是否可以创建 Draft PR。
什么证据支持业务状态变化。

因此，开发数字员工可以调用 Coding Agent，但不能被简化为 Coding Agent 的一个别名。

七、Agent Runtime 的五种接入方式

不同产品看起来都能“运行 Agent”，但它们可能位于完全不同的层次。

7.1 一次性 CLI

工作台为每个任务启动一个命令行进程，通过标准输出接收结果或事件。

工作台
→ 启动 codex exec
→ 读取 JSONL 事件
→ 保存 Run 和结果

这种方式接入快、边界直观，适合先验证技术方案生成、代码分析和 Bug 修复等闭环。缺点是会话恢复、版本兼容和进程治理需要由工作台补充。

7.2 托管的常驻进程

有些 Runtime 会以长期子进程运行，并通过协议接受多个 Session 和任务。

DeepSeek Harness 的 SDK 模式就是一个例子：调用方启动 dsh --profile sdk，通过标准输入输出上的 JSON-RPC 创建 Session、发送 Prompt 并接收状态事件。

相比一次性 CLI，这种方式更适合持续会话和丰富的生命周期事件，但需要处理子进程存活、协议版本、断线和状态映射。

7.3 进程内框架

AgentScope Java 这类框架可以直接集成到 Java 应用中，在同一进程内构建 ReAct、工具、状态和长期 Agent。

它的优势是类型和生命周期更容易与应用集成；代价是应用需要承担更多 Agent 设计、模型适配、工具治理和升级工作。使用开源框架不等于没有运行时成本，只是运行时进入了应用内部。

7.4 标准协议接入

ACP，即 Agent Client Protocol，用于标准化客户端应用与 Coding Agent 之间的通信。工作台可以作为 ACP Client，Coding Agent 或适配器作为 ACP Agent，双方交换 Session、Prompt、流式消息、权限请求和执行状态。

ACP 不是模型，也不是 Agent 框架。它解决的是“客户端如何控制不同 Agent”的问题。

7.5 远程 Runner

当本地进程无法满足并发、资源隔离、操作系统差异和团队共享需求时，可以把 Agent Runtime 部署成独立服务或容器执行环境。

远程 Runner 不改变 Agent 的业务职责，只改变执行位置和资源治理方式。它通常需要额外处理队列、租户隔离、工作区准备、凭据注入、日志上传和执行回收。

八、ACP 与 MCP 解决不同问题

ACP 和 MCP 都使用结构化协议连接不同组件，但连接关系不同。

工作台
  │
  │ ACP：控制 Coding Agent
  ▼
Coding Agent
  │
  │ MCP：访问工具、资源和外部数据
  ▼
Git / 云效 / 飞书 / 文档 / 数据库

ACP 关注客户端与 Agent 之间的 Session、Prompt、运行事件和交互能力；MCP 关注 Agent 如何发现并调用外部工具、资源和提示模板。

两者可以同时使用，也可以都不使用。一个工作台可以直接调用 Codex CLI，而 Coding Agent 通过 MCP 访问企业工具；也可以通过 ACP 控制 Agent，同时让企业系统继续通过普通 API 适配器接入。

协议的价值是降低集成耦合，但协议本身不会替应用解决业务状态、权限策略、幂等、审批和验收问题。

九、Provider 应该面向运行方式抽象

如果接口被命名为 CodingAgentProvider，它会天然携带仓库、分支、Diff 和测试等字段，很难承载需求分析、方案设计或协调任务。

更合理的抽象是：

AgentRuntimeProvider
├── CodexExecProvider
├── DshSdkProvider
├── AcpProvider
├── AgentScopeEmbeddedProvider
└── RemoteRunnerProvider

Provider 回答：

这种 Runtime 是否可用？
支持哪些能力？
能否只读运行？
能否取消或恢复？
如何启动并接收事件？

数字员工角色回答：

它是谁？
负责什么？
被授权处理哪些需求和项目？
可以请求哪些能力？

任务回答：

这次要完成什么目标？
目标对象是哪项需求、任务或 Bug？
需要哪些能力和上下文？
允许产生哪些副作用？

Provider Registry 再根据任务所需能力、运行模式和可用性选择具体执行方式。开发数字员工不应在代码中被永久绑定到某个模型或 CLI。

十、Workflow 必须掌握业务控制权

Agent Runtime 可以管理一次执行，但不能代替企业 Workflow。

Workflow
├── 合法状态转换
├── 权限与审批
├── 质量门禁
├── 等待、重试和恢复
└── 证据与审计

Agent Runtime
├── 理解目标
├── 规划行动
├── 调用工具
├── 处理运行时异常
└── 返回结果和执行轨迹

以“生成技术方案草稿”为例：

用户从需求驾驶舱发起
→ Workflow 校验需求、数字员工和授权
→ 创建只读 AgentTask
→ AgentRuntimeProvider 执行
→ 生成 TECH_DESIGN 草稿 Artifact
→ 人工审阅

Agent 成功生成文档后，需求不会自动进入开发阶段。是否批准方案、是否补充任务、是否允许写代码，仍然由确定性流程和人决定。

未来扩展到 Bug 修复时也是如此：Coding Agent 可以完成代码修改和测试，但只有在检查、部署和外部状态确认满足条件后，Workflow 才能推进相应业务状态。

模型负责理解、推理和生成
Agent Runtime 负责执行和生命周期
Coding Agent 负责专业代码能力
Workflow 负责状态、门禁和恢复
工作台负责需求、责任、权限、证据和企业事实

有了这层区分，系统才可能在不改变业务模型的前提下替换模型、CLI、Agent 框架或运行位置，也能避免一次 Agent 执行结果直接越过企业流程。

对开发数字员工而言，真正重要的不是它背后固定使用哪一个模型，而是它能否在明确身份和权限下持续参与需求交付，调用合适的专业能力，并让每一次行动都可见、可控、可恢复和可验证。

下一篇将结合实际接入进一步讨论：Codex CLI、DeepSeek Harness、AgentScope 与 ACP 分别处于哪一层，如何选择和验证。

参考资料

Codex — OpenAI 关于 Codex 及其开发流程集成方式的官方资料。
DeepSeek Harness SDK — 通过标准输入输出上的 JSON-RPC 驱动 Harness Runtime。
AgentScope Java — 阿里开源的 Java Agent 框架与生产运行时。
Agent Client Protocol — 客户端应用与 Coding Agent 之间的开放通信协议。
Model Context Protocol — Agent 连接外部工具、资源与数据源的开放协议。
开发数字员工中的 Workflow、Agent 与 Coding Agent：从流程编排到自主执行 — 本系列第三篇，讨论确定性流程与运行时决策的边界。
全栈化浪潮带来的启示：数字员工与开发工作台的设计抉择 — 本系列第四篇，讨论角色融合、端到端责任与需求驾驶舱。

DISCUSSION