智能开发人员工作台：产品定位、研发任务模型与系统边界

以 WorkItem 为中心定义研发任务模型，厘清开发数字员工、确定性程序、企业系统与人的职责边界。

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

上一篇文章《企业级 AI Agent 系统：需求分析、核心挑战与架构设计目标》讨论了企业 Agent 面临的共性问题：业务上下文、组织权限、可靠执行、长期任务、评估和审计。

但如果直接从这些技术问题出发，项目很容易变成一个范围不断扩大的“Agent 平台”：先搭模型网关，再做工具调用，然后加入记忆、Multi-Agent 和工作流引擎，最后却很难说清它究竟在为谁解决什么问题。

因此，这个项目需要一个更具体的近期载体。

我们选择的产品形态是智能开发人员工作台；领域边界是研发全流程；第一个主动式闭环是自动处理测试阶段 Bug；长期方向则是企业级数字员工。

在这个长期方向下，工作台首先要支持的不是一个抽象的“万能 Agent”，而是一个职责明确的角色：开发数字员工。它可以像团队中的开发人员一样被加入飞书群，在授权范围内接收群消息和 Bug 反馈，分析问题、设计技术方案、编写和测试代码、提交 Draft PR/MR，并持续汇报任务进展。

长期愿景：企业级数字员工体系
               ↑
首个角色：开发数字员工
               ↑
产品与治理底座：智能开发人员工作台
               ↑
首个闭环：测试阶段 Bug 的发现、修复与回归跟踪

这一定位仍然留下了三个必须回答的问题：

1. 为什么还需要一个开发人员工作台，而不是继续给 IDE 和聊天机器人增加功能？
2. 研发任务跨越需求、代码、测试和协作系统时，系统应该用什么对象持续组织它？
3. 开发数字员工如何像团队成员一样参与协作，同时保持权限、执行和责任边界？

本文尝试回答这三个问题，并进一步定义第一阶段真正要建设的产品。

一、开发人员缺少的不是又一个 AI 输入框

1.1 研发工作天然分散在多个系统中

一次真实的软件交付通常会经过如下过程：

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

这条流程不会完整地存在于任何单一工具中。

• 需求和 Bug 可能在云效等项目协作平台中。
• 讨论和临时反馈可能发生在飞书群。
• 代码、Commit 和 PR/MR 在代码托管平台中。
• 构建、测试和部署结果在 CI/CD 系统中。
• 技术方案、接口说明和操作手册分散在文档平台与代码仓库中。
• 开发人员还可能在 IDE、命令行和 Coding Agent 之间切换。

这些系统分别保存了一部分事实，却没有共同维护“这项研发工作现在进行到哪里、已经产生了什么、还缺少什么证据”。

结果是，开发人员承担了大量隐性的上下文搬运工作：从群消息中找到问题描述，到项目系统确认需求和负责人，再定位相关代码和 PR，检查 CI 与测试环境，最后回到原系统更新状态。

AI 可以帮助分析其中某一步，但如果它只能在一次对话中工作，仍然无法持续承担跨系统协作。

1.2 IDE、聊天机器人与工作台解决的是不同问题

IDE 和 Coding Agent 擅长操作代码：理解仓库、编辑文件、执行命令、补充测试和生成 Diff。聊天机器人擅长交互式理解、解释和生成内容。这两类产品都很重要，但它们通常以“当前会话”或“当前代码仓库”为中心。

研发交付却以业务任务为中心，并且持续时间可能跨越数小时甚至数天。任务会等待 Code Review、CI、测试环境、其他团队反馈或人工审批；任务状态不会因为对话结束而消失，也不能仅靠模型上下文恢复。

智能开发人员工作台要解决的不是“如何再提供一个调用模型的入口”，而是：

如何让分散在需求、协作、代码、CI 和测试环境中的信息，围绕同一项研发工作持续汇聚；并让人、Agent 与企业系统在清晰边界内共同推进它。

因此，工作台位于各类研发工具之上，但不替代它们。

开发人员 / 测试人员 / 负责人
                 │
                 ▼
        智能开发人员工作台
   任务 / 上下文 / 产物 / 执行 / 证据
        │       │       │       │
        ▼       ▼       ▼       ▼
      云效     飞书   Git/PR    CI/环境
                         │
                         ▼
                    Coding Agent

它的价值不是把所有系统重新做一遍，而是提供统一的任务视角、可靠的协作状态和受控的智能执行能力。

1.3 工作台与开发数字员工是什么关系

工作台不是开发数字员工的一个聊天页面，开发数字员工也不是工作台里的一项普通工具。

两者的关系更接近“员工”与“工作环境”：

• 开发数字员工是研发流程中的参与者，拥有持续身份、明确角色、职责范围和可审计的工作记录。
• 智能开发人员工作台是它与人协作的任务、上下文、执行和治理底座。
• 飞书群是接收信息、澄清问题和反馈进展的协作入口之一。
• 云效、代码仓库和 CI/CD是它读取或更新业务事实的工作系统。
• Coding Agent是它完成代码分析与修改时可以调用的专业执行器，而不是数字员工的全部。

飞书群中的开发数字员工
  ├── 接收 @消息、Bug 反馈和任务指派
  ├── 识别意图、补充信息、反馈进展
  └── 创建或关联 WorkItem
                    │
                    ▼
          智能开发人员工作台
  任务 / 上下文 / 方案 / 执行 / 证据 / 审批
        │            │             │
        ▼            ▼             ▼
      云效       Coding Agent    Git / CI

因此，“像员工一样”并不只是拥有一个拟人化头像或能够在群里回复消息。它至少意味着：身份长期存在，能够被分配任务，知道自己负责哪些项目，可以在任务中持续工作，遇到权限或信息不足时主动请求帮助，并对每次行动留下可追踪记录。

群聊只是协作入口，不是任务状态的保存位置。开发数字员工从群消息中识别出工作后，仍然要将其关联到 WorkItem，后续的技术方案、代码修改、PR/MR、测试结果和人工决定才能持续归属于同一项研发任务。

二、产品中心不是聊天会话，而是 WorkItem

2.1 为什么需要统一的研发任务对象

需求、开发任务和 Bug 在外部平台中可能是不同类型的记录，但从工作台视角看，它们都代表一项需要被持续推进、产生交付物并最终验证的工作。

本文将这个统一的协作对象称为 WorkItem。

WorkItem 不是某条云效 Bug 的简单复制，也不是一段 Agent 对话。它是工作台内部可持久化的研发协作单元，负责把跨系统对象关联到同一条交付主线上。

WorkItem
├── 原始需求与验收标准
├── 项目、模块、环境与负责人
├── 技术方案与开发计划
├── 分支、Commit 与 PR/MR
├── 自测、CI 与测试环境结果
├── Code Review 意见
├── 云效 Bug 与飞书反馈
├── Agent 执行和修复记录
└── 发布及最终验证证据

例如，测试人员在飞书群反馈一个问题，云效中随后创建了一条 Bug，开发人员完成修复并提交 Draft PR，CI 通过后部署到测试环境。表面上这是五个系统中的多个对象，实际上它们属于同一个修复任务。

如果没有 WorkItem，Agent 每次都要重新猜测这些对象是否相关；如果有 WorkItem，系统就可以保存它们的确定性关联、当前状态和验证证据。

2.2 WorkItem 不是新的外部事实来源

建立统一任务模型时，一个常见误区是试图用工作台取代现有研发系统。

工作台不应该宣布自己拥有所有事实：

• 云效仍然是需求和 Bug 原始记录及业务状态的重要来源。
• Git 平台仍然保存分支、Commit、PR/MR 和 Review 事实。
• CI/CD 系统仍然保存构建、测试和部署结果。
• 飞书仍然保存原始讨论与反馈消息。

工作台保存的是跨系统的协调事实：这些外部对象属于哪个任务、当前流程等待什么、某次判断依据了哪些上下文、某项操作是否获得批准，以及什么证据支持任务进入下一状态。

这意味着 WorkItem 既不是简单的数据镜像，也不是凌驾于所有系统之上的“超级主数据”。它更像一条可追踪的研发协作主线：引用外部事实，保存必要快照，并对跨系统流程负责。

2.3 核心领域对象

围绕 WorkItem，工作台至少需要以下对象：

这些对象并不是为了制造复杂的数据模型，而是为了避免把所有内容都塞进一段对话历史或一个巨大的任务 JSON 中。

WorkItem 仍然是业务中心，DigitalEmployee 则是任务参与者。一个开发数字员工可以同时参与多个 WorkItem，一个 WorkItem 也可能由开发人员、开发数字员工、测试人员和负责人共同推进。系统需要分别记录任务归属、当前执行者和最终责任人，不能因为数字员工执行了某一步，就模糊人的责任边界。

2.4 Context、Artifact、Evidence 和 Memory 不能混为一谈

这四类对象看起来相近，但承担不同职责。

Context 回答“这次判断使用了什么”。例如需求描述、相关代码片段、项目规范、日志和历史 Bug。它应当记录来源、获取时间和适用范围，以便之后解释 Agent 为什么得出某个结论。

Artifact 回答“这次工作产生了什么”。例如技术方案、修改后的代码、Commit、Draft PR、测试用例和报告。

Evidence 回答“凭什么认为某个条件已经满足”。编译成功、单元测试通过、CI 检查结果、部署记录、Code Review 结论和测试回归结果，都属于证据。

Memory 回答“哪些经验可以在未来复用”。它不应该自动等于历史对话或历史修复方案。只有来源明确、经过验证且仍在有效期内的经验，才适合晋升为团队记忆。

这种区分还有一个实际意义：证据必须绑定明确的对象版本。某个 Commit 上通过的测试，不能自动证明后续修改后的 Commit 仍然正确；针对旧 Diff 的审批，也不能无条件覆盖新的代码变更。

三、研发任务的状态不是一个“完成”按钮

3.1 通用生命周期与业务子流程

不同团队会使用不同的研发状态。工作台不应一开始就强迫所有团队接受一套僵硬流程，但仍然需要一个最小的内部生命周期，用于判断任务是正在推进、等待外部结果、被阻塞还是已经结束。

待处理 → 处理中 → 等待外部结果 → 已完成
              ├── 被阻塞
              └── 已取消

在这层通用状态下，可以针对不同任务类型建立更具体的业务子流程，例如需求交付、技术方案评审或 Bug 修复。

3.2 测试阶段 Bug 闭环

第一个重点场景发生在 Code Review 和上线之间。开发人员完成 CR 并提测后，测试人员可能在飞书群反馈问题，也可能直接在云效创建或更新 Bug。

完整的处理过程是：

测试反馈或云效 Bug
→ 识别、去重与关联
→ 问题分析和代码修复
→ 自测
→ 必要的增量 Code Review
→ 部署测试环境
→ 将 Bug 标记为“已修复”
→ 测试人员回归验证
├── 通过：关闭 Bug
└── 失败：重新打开 Bug，恢复原修复任务

“已修复”也不等于“已关闭”。前者表达开发侧已经提供候选修复，后者表达测试回归已经确认问题解决。类似的区别在成熟工作项系统中也普遍存在：例如 Azure DevOps 将 Resolved 类状态用于“工作完成但等待验证”的阶段，而不是直接视为最终关闭。

3.3 状态变化必须由证据支持

如果工作台只是让 Agent 修改状态，它并不会比普通自动化更可信。

每个关键状态变化都应有明确的进入条件：

因此，“Agent 已执行”“代码已生成”或“PR 已创建”都不能单独代表任务完成。任务完成必须由业务可接受的结果和可追踪证据共同定义。

四、谁负责判断，谁负责执行，谁保存最终事实

企业 Agent 系统最重要的边界之一，是不要把所有职责都交给模型。

一个较稳定的原则是：

模型提出判断和行动建议，确定性程序负责验证与执行约束，企业业务系统保存各自领域的最终事实，人在高风险或高歧义节点负责决定。

4.1 模型和 Agent 适合处理什么

模型擅长处理语义理解和开放性问题，例如：

• 从飞书消息中判断是否包含 Bug 反馈。
• 从需求、代码、日志和文档中提取相关上下文。
• 识别可能重复或相关的问题。
• 分析候选原因并形成修复计划。
• 调用 Coding Agent 修改代码、补充测试。
• 总结 Diff、测试结果、风险和待确认事项。
• 为开发人员提供下一步行动建议。

这些输出通常具有概率性。即使结果看起来合理，也需要通过权限、规则、测试或人工评审验证。

4.2 确定性程序必须承担什么

以下能力不应依赖模型“记住”或“自觉遵守”：

• 外部事件验签、接收、去重和顺序控制。
• WorkItem 状态机与合法状态转换。
• 用户身份、服务身份和权限检查。
• 项目、仓库、分支、Commit、PR/MR 和 CI 的确定性关联。
• 外部 API 调用、幂等键、重试和结果确认。
• 审批检查点、超时、取消和恢复。
• 证据完整性以及验收条件判断。

例如，当创建 Draft PR 的请求超时，系统不能简单重试，否则可能创建两个 PR。正确做法是先查询外部系统，确认操作是否已经成功，再决定是否补偿或重试。

4.3 企业系统负责什么

工作台不应绕开现有企业系统的规则。

• 云效决定 Bug 是否真的更新成功，以及当前业务状态是什么。
• Git 平台决定 Commit、PR/MR、Review 和合并状态。
• CI/CD 系统决定某次构建、测试和部署是否成功。
• 身份系统决定用户和服务账号的有效身份与授权范围。

工作台可以编排这些系统，但不能用自己的推断伪造外部成功。

4.4 人必须保留哪些决定

第一阶段至少应保留以下人工检查点：

• 需求存在重大歧义或验收标准不足。
• Agent 请求访问新的仓库、环境或敏感数据。
• 代码修改影响高风险模块。
• 测试证据不足，或者自动化检查结果互相冲突。
• PR/MR 合并和生产环境发布。
• 是否将一次修复经验晋升为团队长期记忆。

初期系统只创建 Draft PR/MR，不自动合并，也不自动发布生产环境。自主程度应当由任务风险、证据质量和组织策略共同决定，而不是由 Agent 能否调用某个工具决定。

4.5 数字员工需要身份、职责与授权

开发数字员工要进入飞书群并参与真实项目，首先需要成为企业系统中可识别、可约束的主体。

它的身份至少包含三个层次：

• 协作身份：在飞书中以明确的数字员工身份加入授权群聊，接收 @消息、任务指派或经过配置的事件，并向群内反馈进展。
• 业务角色：作为“开发”参与指定项目，能够设计技术方案、分析和修复问题、编写代码并提交 Draft PR/MR。
• 系统凭证：通过受限的服务身份访问云效、代码仓库、CI/CD 和文档系统，不直接继承某个开发人员的全部权限。

身份存在不代表拥有无限访问权。系统仍然需要明确它可以加入哪些群、处理哪些项目、读取哪些仓库、调用哪些工具、执行到什么阶段，以及哪些动作必须由人确认。

同样，开发数字员工也不应默认处理群内所有内容。消息是否触发任务，可以由 @提及、指定群规则、明确任务指令或已配置事件共同决定；原始消息、触发原因和后续回复都应关联到对应 WorkItem。这样它既能像员工一样参与日常协作，又不会退化成监听所有聊天内容、凭自己判断任意执行的机器人。

五、外部系统的复杂性应该停留在适配层

5.1 用 Provider 隔离平台差异

工作台可以定义一组面向领域的接口：

WorkItemProvider       → 云效等需求与缺陷系统
CollaborationProvider  → 飞书等协作系统
RepositoryProvider     → GitLab、Codeup、GitHub 等代码平台
PipelineProvider       → CI/CD 与测试环境
CodingAgentProvider    → Codex 或其他成熟 Coding Agent

这些接口不应追求抹平所有平台能力，而应围绕当前用例提供最小、稳定的语义。例如核心层关心的是“获取某项目更新的 Bug”“关联外部工作项”“将 Bug 标记为已修复”，而不是某家平台具体使用了哪条 URL。

适配层还要负责：

• 外部标识映射。
• 原始状态与内部状态的转换。
• Webhook、轮询和 API 响应的统一事件化。
• 限流、重试与错误分类。
• 保留原始事件和来源，支持审计与问题追踪。

这种边界不仅方便未来接入其他平台，更重要的是保护 WorkItem 生命周期不被某个供应商的接口模型绑架。

六、工作台的信息架构应该映射领域模型

如果产品中心是 WorkItem，那么页面结构也应该围绕研发任务，而不是围绕技术组件或 Agent 名称设计。

第一阶段可以包含以下区域：

6.1 工作台概览

展示人和开发数字员工当前需要关注的研发任务：处理中、等待 Review、等待 CI、等待测试回归、被阻塞和最近完成。概览页首先回答“现在有哪些事情需要处理、正在由谁处理”，而不是展示模型调用次数。

6.2 数字员工

首版只提供一个“开发”数字员工角色，展示其工作身份、职责说明、授权项目和群聊、可用工具、当前任务、等待事项、近期执行和人工接管入口。

这里不是创建任意 Agent 的市场，也不需要一开始就支持复杂的角色编排。它首先要让团队看清楚：这个数字员工是谁，能做什么，正在做什么，为什么暂停，以及人如何接管。

6.3 研发任务

提供 WorkItem 列表和详情页。详情页集中展示：

• 当前状态、负责人和下一步动作。
• 需求、Bug 和原始反馈。
• 关联分支、Commit、PR/MR 和环境。
• 时间线。
• 产物和证据。
• Agent 与工具执行记录。
• 人工审批及其适用版本。

6.4 Bug 闭环

这是围绕测试阶段建立的业务视图，重点呈现从发现、修复、标记已修复到回归关闭或重新打开的全过程。它不是另一套任务数据，而是 WorkItem 在特定业务流程下的视图。

6.5 执行记录

展示 Workflow、Agent、Coding Agent 和工具调用产生的 Run，包括输入上下文、使用的权限、过程日志、产物、耗时、成本与结果。

6.6 项目上下文

管理项目、模块、代码仓库、环境、团队、规范与上下文来源。它决定一个 WorkItem 在执行时可以访问什么，以及不同信息如何组合。

6.7 连接与集成

集中管理云效、飞书、Git、CI 和 Coding Agent。当前已实现的云效连接配置应归入这里，而不应成为整个工作台的首页或产品中心。

6.8 治理

逐步加入身份、权限策略、审批规则、审计、记忆和评估。第一阶段可以只提供必要入口，不必提前建设一个完整治理平台。

这套信息架构背后的原则是：导航映射业务概念，技术能力服务于任务。Timeline、Evidence 和 Approval 是同一个 WorkItem 的不同观察角度，不应被拆成互不相关的功能孤岛。

七、第一阶段应该做到什么程度

7.1 Iteration 0：先建立没有 Agent 也能运行的领域骨架

第一阶段首先实现 Project、DigitalEmployee、WorkItem、Artifact、Evidence、Approval、Run、DomainEvent、状态流和时间线，外部平台可以使用模拟适配器。此时的开发数字员工可以先由模拟执行器驱动，不必等待完整 Agent 能力才能验证任务归属、协作和状态模型。

退出条件不是“页面已经搭好”，而是无需模型参与，也能够完整模拟以下过程：

开发 → Code Review → 提测 → 测试发现 Bug
→ 修复 → 标记已修复 → 回归关闭或重新打开

这一步能验证领域模型是否稳定，也能避免核心业务状态被某个 Agent 框架或外部平台结构主导。

7.2 Iteration 1：从任务到可验证的 Draft PR/MR

随后接入成熟 Coding Agent，实现任务上下文组装、隔离工作区、代码修改、测试执行、Diff 和证据收集，并在人工确认后创建 Draft PR/MR。

退出条件是：一个预置任务能够产生可审查的 Draft PR/MR，并附带测试证据、变更说明和剩余风险，而不是只生成一段代码。

7.3 Iteration 2：接通真实的主动式 Bug 闭环

最后让开发数字员工以明确身份接入飞书、云效、代码平台与 CI/CD：

• 在授权群聊中接收 @消息、Bug 反馈或任务指派。
• 从飞书反馈或云效事件中发现问题，并创建或关联 WorkItem。
• 对重复事件和重复问题进行去重、关联。
• 触发受控的分析与修复。
• 设计技术方案或修复方案，必要时向人补充提问。
• 跟踪必要的增量 CR、CI 和测试环境部署。
• 满足条件后将 Bug 标记为已修复。
• 等待测试人员回归，通过则关闭，失败则重新打开并恢复原任务。

退出条件包括：重复事件不会创建重复任务；进程重启不会丢失状态；外部结果不确定时能够先查询确认；回归失败后可以从已有上下文和证据继续处理。

八、第一阶段明确不做什么

为了让产品边界保持清晰，第一阶段不追求以下目标：

• 不重新开发一个完整的项目管理、代码托管或 CI/CD 平台。
• 不在首版同时设计多个数字员工角色，先验证“开发”这一类角色。
• 不从零开发完整 Coding Agent，而是通过适配器接入成熟执行器。
• 不让聊天历史承担任务状态和长期流程恢复。
• 不因为技术上能调用工具，就默认允许自主执行。
• 不为了展示 Multi-Agent 而人为拆分多个角色。
• 不自动合并 PR/MR，不自动发布生产环境。
• 不把 Agent 推测直接写成企业事实或团队长期记忆。
• 不在缺少证据时把“已执行”解释成“已完成”。
• 不提前把暂定框架和技术选型写成不可替换的系统边界。

首版真正需要证明的是：以 WorkItem 为中心的任务模型，能否让跨系统研发协作持续、可控、可恢复和可验证。

九、总结：工作台是研发数字员工的任务底座

智能开发人员工作台并不是给现有后台加一个 AI 对话框，也不是把云效、飞书、代码仓库和 CI 页面集中放进同一个导航栏。它要支撑的第一个真实角色，是能够进入团队协作环境并持续承担研发任务的开发数字员工。

它的核心是建立一条跨系统、跨阶段的研发任务主线：

• 用 WorkItem 表示需要持续推进的工作。
• 用 Context 记录判断所依据的信息。
• 用 Artifact 保存过程中产生的交付物。
• 用 Run 记录人、Agent 和工具执行了什么。
• 用 Evidence 证明状态为什么可以向前推进。
• 用 Approval 保留必要的人工决定。
• 用 DomainEvent 连接外部变化和内部生命周期。
• 用经过验证的 Memory 支持未来任务，而不是积累不可控的历史猜测。

在这个模型中，模型和 Agent 提供理解、推理与候选行动；确定性程序维护状态、权限、幂等和验收条件；企业系统保存各自领域的最终事实；人负责高风险、高歧义和最终责任节点。

开发数字员工可以在飞书中接收任务和反馈，设计技术方案，调用 Coding Agent 编写与测试代码，提交 Draft PR/MR，并在等待 Review、CI 或测试回归期间持续跟踪任务。工作台则让它的身份、权限、上下文、行动和结果始终处于可见、可控和可审计的状态。

只有先建立这样的任务底座，自动修复测试阶段 Bug 才不会退化成一段脆弱的自动化脚本，研发 Agent 也才可能从一次性助手逐步演进为能够长期参与企业协作的数字员工。完成“开发”这一角色的验证后，同一套底座才有可能扩展到测试、运维或其他企业数字员工。

下一篇将继续讨论一个更具体的问题：研发流程中哪些环节应该使用 Workflow，哪些应该交给 Agent？

参考资料

1. 企业级 AI Agent 系统：需求分析、核心挑战与架构设计目标 — 本系列首篇，介绍企业 Agent 的需求、挑战、架构目标和项目总体定位。
2. AI 辅助研发工作流 — 从研发实践角度讨论需求、设计、开发、Review 与交付过程。
3. Microsoft Learn：About work items and work item types — 工作项类型、状态、历史以及与开发对象关联的官方说明。
4. Microsoft Learn：Customize the workflow — 工作项状态流及 Resolved、Completed 等状态类别。
5. GitHub Docs：About pull requests — Pull Request 在代码讨论、Review 与合并流程中的作用。
6. GitHub Docs：Status checks — 构建、测试、代码扫描和部署检查如何为变更提供验证信号。
7. CloudEvents Specification — 跨系统事件的通用描述规范。
8. OpenTelemetry Documentation — Trace、Metric 和 Log 等可观测性基础。
9. Model Context Protocol — Agent 访问工具和上下文资源的标准化协议；它不替代业务状态、权限和验收流程。