AI Native Develop Workflow 研发流程到 Delivery

从研发流程到 AI Native Delivery

一份关于 Task Engineering、Loop Engineering、Harness Engineering、Multica 与 Chat Gateway 的内部实践复盘

文档定位

这不是某个 AI 工具的功能介绍，而是一份研发体系演进案例。它记录了我们如何从传统的 Jira、Confluence、Git、CI/CD 流程出发，先在单人 GitHub 环境验证最小闭环，再把经验收敛为公司级的 Multica Agent 编排方案。

本文适合产品、研发、测试、架构、工程效率和管理同学共同阅读。读完后应能回答五个问题：

AI 应该进入研发流程的哪些环节？
Task Engineering、Loop Engineering、Harness Engineering 分别解决什么问题？
Multica、Codex/Claude、Jira、Confluence、Git 和 CI/CD 的边界是什么？
人为什么仍然是责任主体，Gateway 为什么不可缺少？
如何从一个 Jira 链接启动并闭环一次真实交付？

一句话结论

AI Native 研发不是让一个 Agent 接管所有工具，而是把研发工作建模为一组有明确合同、证据和责任边界的任务，再通过可恢复的反馈循环推进这些任务，并用 Harness 把模型安全地接入真实环境。

我们最终采用的结构是：

Jira、Confluence、Git、CI/CD 继续作为各自领域的事实源。
Multica 负责任务编排、Agent 身份、执行记录和协作。
Codex、Claude 等 Runtime 负责理解、设计、编码、测试和分析。
Harness 负责接入 Repo、IDE/SDK、SQL、环境、DSL、MCP、凭据与验证命令。
Chat Gateway 负责身份、权限、审批、通知、审计和紧急停止。
人类负责目标、责任、Review 和高风险决策。

flowchart LR Intent["业务意图与 Jira 需求"] --> Task["Task Engineering 任务合同与职责边界"] Task --> Loop["Loop Engineering 执行观察修正验证"] Loop --> Harness["Harness Engineering Repo IDE SDK SQL Env DSL MCP"] Harness --> Runtime["Codex / Claude Runtime"] Runtime --> Evidence["PR CI Test Release Evidence"] Evidence --> Loop Loop --> Gateway["Chat Gateway 审批通知审计"] Gateway --> Human["人类责任人与 Reviewer"] Human --> Task

1. 起点：先把传统研发流程说清楚

最初的问题不是“选哪个 Agent 平台”，而是“我们的研发流程究竟是什么”。如果角色、状态和事实源都没有定义清楚，AI 只会放大原有的混乱。

1.1 角色视角

传统流程包含四类主要角色：

角色	核心责任
运营	收集市场、客户和业务反馈，提出问题或机会
产品	理解需求、定义范围、验收标准和优先级
开发	技术设计、任务拆分、实现、自测和修复
测试	测试设计、缺陷管理、回归和质量结论

以角色为列，需求状态的主要流转如下：

sequenceDiagram autonumber participant Ops as 运营 participant Product as 产品 participant Dev as 开发 participant QA as 测试 Ops->>Product: 提交市场/客户反馈 Product->>Product: 分析价值、范围与优先级 Product->>Dev: 提交需求与验收标准 Dev->>Product: 澄清边界与技术约束 Product-->>Dev: 需求 Ready Dev->>Dev: 认领、拆分、技术设计 Dev->>Dev: 开发、Unit Test、自测 Dev->>QA: 提测并提供构建与变更说明 QA->>QA: Integration / E2E / Regression alt 测试发现缺陷 QA->>Dev: 提交 Bug 与复现证据 Dev->>Dev: 修复并补充测试 Dev->>QA: 重新提测 else 验收通过 QA-->>Product: 提供质量结论 Product-->>Ops: 确认可发布结果 end

这张图回答“谁和谁协作”，但没有回答“信息存在哪里、状态如何被工具驱动”。因此还需要工具视角。

1.2 工具视角

工具	事实与职责
Jira	需求、Bug、子任务、负责人、状态和验收标准
Confluence	PRD、技术方案、架构设计、ADR 和长期知识
Git / PR / MR	分支、代码变更、Review 和合并边界
CI/CD	构建、静态检查、测试和发布证据
Jenkins	公司现有发布编排或环境部署入口

sequenceDiagram autonumber participant Jira as Jira participant Conf as Confluence participant Git as Git / PR / MR participant CI as CI/CD participant Jenkins as Jenkins Jira->>Jira: 产品创建需求并进入 Ready Jira->>Jira: 开发认领并拆分子任务 Jira->>Conf: 关联 PRD / 技术方案 / ADR Conf-->>Jira: 方案 Review 通过 Jira->>Git: 创建分支并关联 Issue Key Git->>CI: Push / PR 触发构建与测试 CI-->>Git: 回写 Check 与质量证据 Git->>Git: Code Review 与人工 Merge alt 测试发现问题 CI->>Jira: 创建或关联 Bug Jira->>Git: 修复分支与新提交 Git->>CI: 重新验证 else 质量门禁通过 Git->>Jenkins: 触发受控发布 Jenkins-->>Jira: 回写版本与发布结果 Jira->>Jira: 关闭子任务和父需求 end

这里形成了第一个重要判断：工具不是流程本身，事实源、状态和交接合同才是流程。

2. AI 进入流程，但不替代事实源

当 AI 参与后，最容易犯的错误是再建一套 AI 状态、AI 文档和 AI 任务系统。这样会制造双重事实源。

更稳妥的原则是：

AI 从 Jira 读取任务合同，并把状态与证据写回 Jira。
AI 从 Confluence 读取背景和架构，并把长期设计写回 Confluence。
AI 通过分支和 PR/MR 修改代码，不直接改默认分支。
AI 以 CI/CD 的实际结果作为验证证据，不凭自然语言宣布成功。
Multica 记录一次 Agent 执行，不把 task completed 等同于 Jira Done。

sequenceDiagram autonumber actor Human as 人类责任人 participant Jira as Jira participant Multica as Multica participant Agent as AI Agent participant Conf as Confluence participant Git as Git / PR / MR participant CI as CI/CD participant KN as Chat Gateway Human->>Jira: 提交或确认任务合同 Jira->>Multica: 触发/关联交付任务 Multica->>Agent: 委派当前阶段 Agent->>Jira: 读取需求、状态和负责人 Agent->>Conf: 读取或更新设计事实 Agent->>Git: 创建分支、提交和 PR/MR Git->>CI: 运行检查 CI-->>Agent: 返回可验证结果 Agent-->>Multica: 返回产物、证据和下一步 Multica->>KN: 通知状态或请求审批 KN-->>Human: 展示上下文与待决策动作 Human->>KN: Review / Approve / Reject / Stop KN->>Jira: 回写决定和证据

3. 三种 Engineering 不是同义词

3.1 Task Engineering：把意图变成可执行合同

Task Engineering 解决的是“一次工作到底是什么”。一个可执行任务至少包含：

背景和业务目标。
非目标和范围边界。
可测试的验收标准。
目标仓库与影响平台。
上下文和设计引用。
依赖、风险和负责人。
预期产物与验证证据。
允许的动作和必须停下来的门禁。

Task Engineering 的产物不是 Prompt，而是可以由人或 AI 接手、可以被 Review、可以判断 Done 的任务合同。

3.2 Loop Engineering：让任务持续推进并可恢复

Loop Engineering 解决的是“一次执行之后怎么办”。典型循环是：

读取事实 -> 规划 -> 执行 -> 观察 -> 验证 -> Review -> 修正 -> 再验证 -> 交接

一个可靠的 Loop 必须具备：

明确的进入条件和退出条件。
每一步都有外部证据。
失败能定位到原阶段，而不是从头重跑。
重试有限，连续失败会升级人工。
可以从已有 PR、CI 或测试状态恢复。
不因 Agent Run 结束而误判业务任务完成。

3.3 Harness Engineering：让 Agent 真正具备工作能力

Harness Engineering 解决的是“Agent 如何接触真实世界”。它通常包含：

Repo Registry 与本地工作区映射。
Git Provider、分支、PR/MR 和 CODEOWNERS。
IDE、SDK、构建工具和包管理器。
Jira、Confluence、Git、CI/CD 的 MCP、Skill 或 CLI。
SQL、测试数据、环境、DSL 和内部平台。
Secret 注入、最小权限、脱敏和审计。
超时、并发、幂等、重试、回滚和可观测性。

因此三者关系是：

Task 定义工作，Loop 推进工作，Harness 让工作能够在真实环境中发生。

缺少任何一层都会出现典型失败：

缺失层	结果
缺 Task Engineering	Agent 很忙，但范围漂移、产物不可验收
缺 Loop Engineering	能做一次操作，但失败后无法恢复，交接靠人盯
缺 Harness Engineering	Agent 知道应该做什么，却读不到 Jira、Repo、CI 或环境

4. 先做单人、免费、GitHub-native 的最小实验

在接入公司 Jira、Confluence、Jenkins 和 IAM 前，我们先用一个独立开发者环境验证流程，而不是先建设完整平台。

映射关系如下：

公司级能力	GitHub Demo 替代
Team	GitHub Organization 或 Repository Collaborators
Jira	GitHub Issues + Projects
Confluence	仓库内 `docs/`，Wiki 仅作为可选入口
Git / CR	Branch + Pull Request Review
Jenkins / CI/CD	GitHub Actions
Gateway	Issue/PR 评论、Label、Environment Approval

sequenceDiagram autonumber actor Owner as 独立开发者 participant Issue as GitHub Issue participant Project as GitHub Project participant Action as GitHub Actions participant Docs as Repo docs participant PR as Pull Request Owner->>Issue: 创建任务合同 Issue->>Project: 加入看板并设置状态 Owner->>Issue: /ai approve Issue->>Action: issue_comment 触发设计工作流 Action->>Docs: 生成 PRD / Design / ADR Action->>PR: 创建设计 PR Owner->>PR: Review 并 Merge Owner->>Issue: /ai implement Issue->>Action: 触发实现工作流 Action->>PR: 创建代码、测试与实现 PR PR->>Action: CI 与 AI Review Owner->>PR: 人工 Review 并 Merge Action->>Issue: 回写证据并关闭任务

4.1 这个实验暴露的真实工程问题

实验价值不在于“成功创建了 PR”，而在于暴露了自动化系统的边界：

创建 Project 不会自动触发 Workflow。 GitHub Actions 只响应声明的事件；Issue、Project、评论和 PR 是不同事件模型。
Action 版本会影响 Runner Runtime。 actions/checkout@v4 曾产生 Node.js 20 弃用警告，说明依赖版本本身也是 Harness 的一部分。
默认 GITHUB_TOKEN 不一定允许创建 PR。 Repository 的 Workflow permissions 必须允许写入和创建 PR，或使用权限更小、用途明确的 GitHub App/PAT。
由 GITHUB_TOKEN 产生的事件通常不会递归触发新 Workflow。 这是 GitHub 防止自动化死循环的安全设计。跨 Workflow 编排需要显式事件、workflow_run、GitHub App 或受控 Token。
/ai implement 不是自然语言魔法。 必须有监听 issue_comment 的 Workflow、命令解析、身份检查、幂等和错误回写。
通知就是 Gateway 的最小形态。 当任务需要人确认时，系统必须把“上下文、风险、可选动作、超时和后果”送到人，而不是只把任务设为 waiting。

4.2 曾经尝试的 AI 可执行等级

GitHub Demo 一度使用 human-only / assist / auto-branch / auto-pr 控制自动化能力。它适合解释单个 Workflow 最多能做什么，但在公司级多 Agent 流程中会产生问题：

同一任务在不同阶段需要不同动作，单一等级无法准确表达。
等级会和 Agent 角色权限、Repo 权限、人工门禁重复。
容易把 auto-pr 误解为 auto-merge 或 auto-release。
业务风险不等于代码写权限。

因此最终方案从 Multica Agent 和 Squad 中移除了该字段，改用三种机制：

角色职责边界：谁能设计、编码、Review、测试和发布。
风险分轨：Fast、Standard、Critical 决定必须经过哪些门禁。
动作级人工门禁：Merge、生产发布、回滚、Schema、权限、安全、支付、生产数据和 Secret。

GitHub Demo 中仍可保留等级作为历史实验，但不能把它当作公司级最终规范。

5. 回到公司级：为什么选择 Multica

Multica 的合理定位不是“替代研发工具”，而是公司级 Agent 编排层：

管理 Agent Profile、Instructions、Runtime、Model、访问范围和并发。
把 Jira、Chat、PR/MR、CI/CD 事件转换为可执行任务。
记录任务委派、运行日志、失败原因和重试。
让本地或受控 Daemon 调用 Codex、Claude 等 Coding Runtime。
支持 Squad 中的角色协作和阶段交接。

它不应该承担：

Jira 的需求和责任事实源。
Confluence 的长期知识事实源。
Git 的代码边界。
CI/CD 的质量与发布证据。
IAM 和 Chat Gateway 的审批责任。

flowchart LR Jira["Jira 需求状态责任人"] --> Gateway["Chat Gateway 身份权限审批通知"] Conf["Confluence PRD ADR 架构"] --> Harness["Harness Layer"] Gateway --> Multica["Multica Squad Agent Task Run"] Multica --> Daemon["Multica Daemon"] Daemon --> Runtime["Codex / Claude / Cursor"] Runtime <--> Harness Harness <--> Repo["Repo Registry Git Worktree SDK Env"] Harness <--> Data["MCP SQL DSL Internal API"] Runtime --> Git["Git PR / MR"] Git --> CI["CI/CD / Jenkins"] CI --> Gateway Gateway --> Jira Runtime --> Conf

6. 为什么 Multica 中的 Codex 不能自动访问 Jira

“Codex 本身能访问 Jira”不代表“Multica 启动的 Codex Runtime 能访问 Jira”。能力属于一次具体运行环境，而不是模型名称。

Multica 需要显式提供：

Jira MCP、Skill、CLI 或内部 API。
对应的 URL、认证和最小权限凭据。
Runtime 能发现这些能力的配置。
Jira Issue URL、Key 和项目上下文。
网络可达性与审计策略。

推荐的分工是：

Gateway 负责用户身份、项目权限、审批与命令合法性。
Agent Runtime 通过受控 Harness 读取和回写 Jira。
对高风险写操作，Gateway 生成短时授权或在批准后代为执行。
如果 Runtime 无写权限，Agent 必须输出完整草案并设为 Blocked，不能伪造已创建结果。

sequenceDiagram autonumber actor User as Chat 用户 participant KN as Chat Gateway participant IAM as Company IAM participant Jira as Jira participant Multica as Multica participant Runtime as Codex Runtime participant MCP as Jira MCP / Internal API User->>KN: 提交 Jira URL 或 /ai run KN->>IAM: 校验身份、项目角色和审批资格 IAM-->>KN: allow / deny KN->>Jira: 读取任务合同与当前状态 Jira-->>KN: issue context KN->>Multica: 创建幂等任务并附最小上下文 Multica->>Runtime: 启动 Agent Runtime->>MCP: 使用受控凭据读取 Jira MCP->>Jira: API 请求 Jira-->>Runtime: 任务、评论、链接、子任务 Runtime-->>Multica: 产物、证据、写入草案 alt 写操作需要审批 Multica->>KN: 请求动作级批准 KN-->>User: 展示影响与确认按钮 User->>KN: approve / reject KN->>Jira: 执行批准后的写操作 else 普通可审计写入 Runtime->>MCP: 回写评论、链接或状态 end

7. Repo Registry：让一个 Jira 找到正确代码和环境

仅把 Jira 链接交给 Agent 并不足够。Agent 还需要知道项目对应哪些仓库、默认分支、语言、构建命令和环境。

早期可以用一份受版本控制的 Registry，不需要先建设数据库或 Multica Property：

projects:
  PROJ:
    owner_team: rd-platform
    repos:
      - name: backend
        url: git@github.company.com:proj/backend.git
        default_branch: main
        scope: backend
        commands:
          test: make test
          lint: make lint
      - name: web
        url: git@github.company.com:proj/web.git
        default_branch: main
        scope: frontend
        commands:
          test: pnpm test
          build: pnpm build
    docs:
      architecture: https://confluence.company.com/x/PROJ-ARCH
    release:
      system: jenkins
      pipeline: proj-release

当项目数量、权限或动态环境显著增加时，再把 Registry 服务化。原则是先解决确定性映射，不为“以后可能需要”提前制造平台。

8. 最终 Squad：一个 Leader，七类专业能力

我们没有一开始就创建 Backend、Frontend、Android、iOS 四个固定 Agent。平台拆分是任务结构，不一定是 Agent 结构。只有某个平台长期有稳定工作量、独立 Harness 或专门 SDK 时，才值得建立专用 Agent。

Agent	最终职责	明确不做什么
R&D Leader Agent	需求合理性、风险分轨、门禁、子任务、分配、闭环	不代替专业成员设计、编码、测试、Review、发布
Requirement Design Agent	补全任务合同、验收标准和拆分草案	不创建正式实现任务，不决定最终负责人
Architecture Agent	Design Note/架构方案、依赖、迁移、测试与发布设计	不批准自己的方案，不直接实现
Code Review Agent	`architecture-review` 与 `implementation-review`	不修改被审查产物，不自审
Implementation Agent	单个职责子任务、代码、Unit Test、PR/MR、Review 修复	不关闭自己的任务，不 Merge/Release
QA Agent	Unit 证据核验、Integration、E2E、Regression 和验收	不用无证据的“看起来没问题”判定通过
CI Fix Agent	跨阶段根因定位、最小修复并返回原阶段	不禁用测试或降低门禁
Release Ops Agent	发布计划、受控执行、验证和回滚准备	不绕过生产审批和质量证据

9. 三轨交付模型

并非所有任务都值得走同样重的流程。最终方案使用风险分轨，而不是统一套完整架构流程。

轨道	典型任务	必需门禁
Fast Track	小 Bug、文档、配置、单仓低风险变更	实现 Review、CI、必要 QA、人工 Merge
Standard Track	功能、跨平台、跨仓、API/事件/数据模型	架构设计、架构 Review、实现 Review、QA、发布门禁
Critical Track	Schema/迁移、安全、权限、支付、客户数据、生产流量	Standard 全流程 + 实现前人工批准 + 更严格发布/回滚门禁

flowchart TD Start["Jira Requirement"] --> Understand["Leader 理解合理性与完整性"] Understand --> Complete{"任务合同完整?"} Complete -- 否 --> Req["Requirement Design 补全"] Req --> Understand Complete -- 是 --> Risk{"风险分轨"} Risk -- Fast --> Implement["创建并行实现子任务"] Risk -- Standard --> Arch["Architecture Design"] Risk -- Critical --> Arch Arch --> ArchReview["Code Review architecture-review"] ArchReview --> ArchVerdict{"Review 结论"} ArchVerdict -- changes_required --> Arch ArchVerdict -- blocked --> Blocked["Blocked 通知 Chat"] ArchVerdict -- approved --> CriticalGate{"Critical?"} CriticalGate -- 是 --> HumanGate["Chat 人工批准"] HumanGate --> HumanVerdict{"approved?"} HumanVerdict -- rejected / expired / artifact drift --> Blocked HumanVerdict -- approved --> Implement CriticalGate -- 否 --> Implement Implement --> ImplReview["PR/MR implementation-review"] ImplReview --> ImplVerdict{"Review 结论"} ImplVerdict -- changes_required --> Implement ImplVerdict -- blocked --> Blocked ImplVerdict -- approved --> Merge["人工 Review / Merge"] Merge --> QA["聚合 QA"] QA --> QAVerdict{"QA 结论"} QAVerdict -- blocked --> Blocked QAVerdict -- failed --> Defect["Leader 去重并创建缺陷子任务"] Defect --> Implement QAVerdict -- passed --> NeedRelease{"需要发布?"} NeedRelease -- 否 --> NoRelease["记录 no-release 原因"] NoRelease --> Done["关闭父 Jira"] NeedRelease -- 是 --> ReleasePrep["Release Ops 准备"] ReleasePrep --> Production{"生产动作?"} Production -- 是 --> ReleaseApproval["Chat 发布审批"] ReleaseApproval --> ReleaseApprovalVerdict{"approved?"} ReleaseApprovalVerdict -- rejected / expired / version drift --> Blocked ReleaseApprovalVerdict -- approved --> Release["执行发布"] Production -- 否 --> Release Release --> ReleaseResult{"发布验证"} ReleaseResult -- passed --> Done ReleaseResult -- CI/CD failed --> CIFix["CI Fix origin_stage=release"] CIFix --> Release ReleaseResult -- smoke / metric / data failed --> Incident["停止扩散 回滚或人工接管"] Incident --> Blocked

9.1 最终时序

sequenceDiagram autonumber actor Owner as 需求责任人 participant Jira as Jira participant Leader as R&D Leader participant Req as Requirement Design participant Arch as Architecture participant Review as Code Review participant Impl as Implementation Members participant Git as Git / PR / MR participant QA as QA participant Fix as CI Fix participant Release as Release Ops participant KN as Chat Gateway Owner->>Jira: 提交 Jira URL 与任务合同 Jira->>Leader: 触发或委派父任务 Leader->>Leader: 合理性、完整性、风险分轨 opt 需求不完整 Leader->>Req: 补全任务合同与拆分草案 Req-->>Leader: 可测试合同 / blocker end alt Standard 或 Critical Leader->>Arch: 生成技术方案与任务拆分建议 Arch-->>Leader: Design / ADR / 风险 loop 直到 architecture-review approved 或 blocked Leader->>Review: architecture-review alt changes_required Review-->>Arch: Findings 与修订要求 Arch-->>Leader: 修订后的方案与证据 else blocked Review-->>Leader: blocker 与证据 Leader->>Jira: 状态改为 Blocked Leader->>KN: 通知 blocker 与所需决策 break 架构 Review 未通过，停止后续流程 Leader-->>Owner: 等待 blocker 解除后重新 Review end else approved Review-->>Leader: approved + 审查证据 end end opt Critical Track Leader->>KN: 请求实现前人工批准 KN-->>Owner: 展示方案、风险和动作 Owner-->>KN: approve / reject alt approved KN-->>Leader: approval granted else rejected / expired / artifact drift KN-->>Leader: approval denied Leader->>Jira: 状态改为 Blocked break 未获得有效批准，停止进入实现 Leader-->>Owner: 等待新方案或新审批 end end end end Note over Leader,Jira: 只有架构 Review 和所需人工门禁全部通过，才创建实现子任务 Leader->>Jira: 创建受影响平台/仓库子任务 par Backend / Service Leader->>Impl: 分配后端子任务 and Frontend Leader->>Impl: 分配前端子任务 and Android / iOS（仅真实受影响时） Leader->>Impl: 分配客户端子任务 end loop 每个实现子任务直到人工 Merge 或 blocked Impl->>Git: 创建或更新 PR/MR，附 Unit 与 CI 证据 Git->>Review: PR Ready，implementation-review alt changes_required Review-->>Impl: Findings 与修订要求 Impl->>Impl: 修复并重新运行 Unit / CI else blocked Review-->>Leader: blocker 与证据 Leader->>Jira: 子任务改为 Blocked break 实现 Review 未通过，停止该子任务后续流程 Leader-->>Owner: 等待 blocker 解除后重新 Review end else approved Review-->>Leader: approved + 审查证据 Leader-->>Owner: 请求人工 Review / Merge alt 人工要求修改 Owner-->>Impl: Review Findings Impl->>Impl: 修复并重新运行 Unit / CI else Merge blocked Owner-->>Leader: 拒绝或暂停 Merge Leader->>Jira: 子任务改为 Blocked break 未完成 Merge，停止该子任务后续流程 Leader-->>Owner: 等待新的 Review 决定 end else 人工 Review 通过并 Merge Owner->>Git: Approve / Merge Git-->>Leader: merged SHA Impl-->>Leader: Unit、CI、PR、Review 与 Merge 证据 Leader->>Jira: 核验证据并关闭实现子任务 end end end Note over Leader,QA: 仅当全部必需实现子任务 Done 后进入最终 QA Leader->>QA: 创建一个聚合 QA 任务 QA-->>Leader: passed / failed / blocked alt QA failed QA-->>Leader: 缺陷报告与复现证据 Leader->>Jira: 去重并创建缺陷子任务 Leader->>Impl: 分配修复 Impl->>Review: 修复 Review Leader->>QA: 回归测试 else QA blocked Leader->>Jira: 状态改为 Blocked Leader->>KN: 通知环境、数据或依赖缺口 else QA passed alt 明确不需要发布 Leader->>Jira: 记录 no-release 原因并关闭父任务 else 需要发布 Leader->>Release: 准备固定版本、Release Note 与回滚方案 opt 生产动作 Release->>KN: 请求生产发布批准 KN-->>Owner: 展示版本、风险和回滚方式 Owner-->>KN: approve / reject alt approved KN-->>Release: approval granted else rejected / expired / version drift KN-->>Release: approval denied Release-->>Leader: release blocked Leader->>Jira: 状态改为 Blocked break 未获得有效批准，停止发布 Leader-->>Owner: 等待新审批或调整计划 end end end Release->>Release: 执行获准版本并验证 alt 发布与验证通过 Release-->>Leader: passed + 发布证据 Leader->>Jira: 关闭父任务 else CI/CD Pipeline failed Release->>Fix: origin_stage=release + Run URL + SHA Fix-->>Release: 最小修复与验证 Release->>Release: 返回发布阶段重试 else Smoke / Metric / Data failed Release->>KN: 请求停止流量、回滚或人工接管 Release-->>Leader: failed + 运行时证据 Leader->>Jira: 状态改为 Blocked，不关闭父任务 end end end opt implementation 或 qa 阶段 CI/CD 失败 Leader->>Fix: 附 origin_stage、Run URL、SHA Fix-->>Leader: 根因、最小修复、验证 Leader->>Leader: 返回原阶段继续 end

10. 子任务分配：平台是职责边界，不是固定组织结构

Leader 只为真实影响面创建子任务。一个纯后端 Bug 不应机械创建 Frontend、Android、iOS 空任务。

每个子任务至少包含：

父 Jira 和 Jira URL。
scope/platform 与目标仓库。
目标、非目标和验收标准。
Design/ADR 引用。
依赖关系和预期证据。
唯一主要负责人。

分配优先级：

Jira 或人工明确指定的负责人。
Squad 中职责匹配的人类或 AI Member。
无专用成员时使用通用 Implementation Agent。
无法可靠判断时保持未分配，通过 Chat 请求负责人。

这允许公司后期按需要引入专用 Backend/Frontend/Android/iOS Agent，但不在初期制造空角色和额外维护成本。

11. 状态、DoR 与 DoD

11.1 状态保持简单

父任务和子任务只使用：

Todo -> In Progress -> Blocked / Done

阶段写入 Jira 评论、Multica Activity 和 Leader 输出，不依赖额外 Property、Label 或大量自定义状态。这样可以先跑通流程，再根据真实查询和报表需求增加结构化字段。

11.2 Definition of Ready

进入实现前必须满足：

任务合同完整，验收可测试。
目标仓库与职责边界明确。
Standard/Critical 所需设计和架构 Review 完成。
依赖、风险、测试策略和预期证据明确。
Critical Track 已通过人工批准。

11.3 Definition of Done

实现子任务 Done：

范围与验收完成。
Unit Test、静态检查和 CI 通过。
implementation-review=approved。
PR/MR 经过人工 Review 并 Merge。
证据回写 Jira。

QA Done：

Unit Test 证据已核验。
必需的 Integration、E2E、Regression、兼容和平台测试完成。
结论对应当前发布版本，而不是过期 SHA。

父任务 Done：

所有实现和缺陷子任务完成。
QA passed。
发布验证成功，或明确记录 no-release 原因。
文档、风险和证据完成回写。

12. CI Fix 不是一个固定阶段

CI/CD 失败可能发生在实现、QA 或发布阶段，因此 CI Fix 应被设计为中断处理器：

sequenceDiagram autonumber participant Stage as Origin Stage participant CI as CI/CD participant Fix as CI Fix Agent participant Git as Git / PR participant Human as 人类负责人 Stage->>CI: 执行当前阶段检查 CI-->>Stage: failed + Run URL + SHA Stage->>Fix: origin_stage + owner + failure context Fix->>CI: 定位第一个真实失败点 Fix->>Fix: 分类代码/测试/依赖/配置/基础设施 alt 可以最小修复 Fix->>Git: 创建修复提交或 PR Git->>CI: 重新验证当前 SHA CI-->>Fix: passed Fix-->>Stage: 返回原阶段继续 else 连续两次失败或根因不明 Fix-->>Human: Blocked，提供证据与建议 end

关键限制：不能删除测试、降低门禁、吞掉错误或用无限重跑掩盖确定性失败。

13. Chat Gateway：让人只在需要负责时出现

Gateway 不是普通聊天机器人，而是人机责任边界：

命令入口：接收 Jira URL、/ai run、审批、拒绝、停止。
身份映射：Chat、IAM、Jira、Multica、Git 身份关联。
权限判断：判断谁能操作哪个项目和动作。
审批：展示上下文、影响、风险、版本和可选动作。
通知：把 Blocked、Review、CI、发布状态送回原 Thread。
审计：记录发起者、执行者、批准者、时间和证据。
幂等：避免消息重放创建重复任务。
Emergency Stop：在错误扩散前停止 queued/running task。

需要人工的不是“所有步骤”，而是责任不可委托或风险不可逆的动作：

需求/验收冲突与范围变更。
Critical Track 进入实现。
架构或 Code Review 的重大争议。
Merge。
生产发布、回滚和流量切换。
Schema/迁移、支付、权限、安全、客户数据和高权限 Secret。

14. 简化原则

这次迭代过程中，最终保留了以下简化：

一个 Leader 负责全生命周期协调。 避免多个 Agent 同时决定下一步。
Requirement Design 只在需求不完整时介入。 不为每个清晰任务生成重复 PRD。
Fast Track 跳过架构阶段。 小改动不需要沉重流程。
Code Review 复用一个 Agent 的两种模式。 不额外创建 Architecture Review Agent。
平台通过子任务动态拆分。 初期不创建四个长期空闲 Agent。
默认一个聚合 QA 任务。 只有环境和验收真正独立时才拆平台 QA。
CI Fix 作为中断处理器。 不把失败修复排成固定串行阶段。
暂不引入 Property 和 Label。 状态和阶段先通过现有事实源表达。
从第一个未满足门禁恢复。 不因重跑而重复建任务、重复设计或重复创建 PR。
PAK 等领域流程保持独立。 Repo Registry 识别领域项目后，通用 Leader 只生成最小交接包并路由到独立领域 Squad，然后结束通用流程；不得直接调用领域专用 Agent/Skill。

15. 推荐落地顺序

Phase 0：Shadow Mode

Agent 只读 Jira、Confluence、Repo 和 CI。
输出分诊、设计、Review 和测试建议。
不创建分支、不写状态。
目标是验证任务合同、Repo Registry 和证据质量。

Phase 1：PR Delivery

开放分支、代码修改、测试和 PR/MR。
Merge 仍由人完成。
Chat 处理通知、审批和 Stop。
重点衡量 PR 可用率、Review finding 命中率和返工次数。

Phase 2：Closed Loop

启用 Leader 自动拆分和动态分配。
接入 QA、缺陷回流和 CI Fix。
从已有状态恢复，处理失败重试和幂等。
重点衡量 Lead Time、Blocked Time 和人工接管原因。

Phase 3：Controlled Release

接入 Jenkins/CI/CD 发布计划与非生产执行。
生产动作保留人工批准和回滚责任。
接入监控、告警和发布验证。
只有审计、权限、幂等和回滚稳定后才扩大自动化。

16. 衡量是否真的有效

不要用“Agent 执行次数”衡量 AI Native 成熟度。推荐指标是：

维度	指标示例
交付效率	Jira Ready 到 PR、PR 到 Merge、Merge 到 Release 的时间
任务质量	首次验收通过率、返工次数、范围变更次数
工程质量	CI 首次通过率、逃逸缺陷、回滚率
Agent 质量	有证据完成率、错误工具调用率、重复任务率
人机协作	人工审批等待时间、接管原因、无效通知比例
Harness 稳定性	Jira/Repo/CI 可访问率、环境准备时间、Secret/权限失败率

一个健康的系统应该减少等待和重复劳动，同时让责任和证据更清楚；如果只是增加了大量 AI 评论和状态，说明流程没有真正改善。

17. 常见误区

“有了 Multica 就有了 Jira 能力”

错误。Multica 负责编排，Jira 能力必须通过 Runtime Harness 显式提供。

“用了 Codex 就是 Loop Engineering”

错误。一次 Coding Run 不等于可恢复、可验证、有失败回流的 Loop。

“全自动化意味着没有人”

错误。全自动化的合理目标是机器处理可验证的重复工作，人只在目标、责任、Review 和高风险决策上出现。

“角色越多越专业”

错误。Agent 数量会增加交接、上下文复制和维护成本。先按稳定职责创建角色，再按真实吞吐量拆分。

“流程字段越多越可管理”

错误。没有真实查询和决策需求的 Property、Label 和状态只是维护负担。

“Agent 完成就是需求完成”

错误。Agent Run 完成只表示一次计算结束。需求完成必须由 PR、CI、QA、发布和 Jira 验收共同证明。

18. 内部分享建议

可以按以下 30 分钟结构分享：

5 分钟：传统角色与工具时序图。
5 分钟：GitHub-native Demo 以及暴露的真实问题。
5 分钟：Task、Loop、Harness 三层哲学。
8 分钟：Multica、Agent Roles、三轨状态机和 Chat Gateway。
5 分钟：现场输入一个 Jira URL，展示 Leader 的分轨与下一步。
2 分钟：试点范围、指标和责任边界。

推荐演示任务选择：

一个 Fast Track 小 Bug，用来展示快速路径。
一个 Standard Track 跨端功能，用来展示架构 Review 和动态拆分。
一个模拟 CI 失败，用来展示 CI Fix 返回原阶段。

19. 最终原则

先定义事实源和责任，再引入 Agent。
任务必须是可执行、可验收的合同。
循环必须可观察、可恢复、可停止。
Harness 能力必须显式配置和审计。
AI 不创建第二套 Jira、Confluence 或 CI 真相。
Agent 不批准自己的产物。
自动化程度由风险和证据决定，不由一个笼统等级决定。
人承担目标、责任、Review 和不可逆决策。
从最小闭环开始，用真实失败推动平台演进。
只有发布验证或明确的 no-release 结论，才代表父需求可以关闭。

这套体系的目标不是追求“无人研发”，而是让每一次研发活动都有清晰的上下文、边界、证据和责任，让人把时间花在真正需要判断的地方。

posted @ 2026-08-26 17:43 月光宝盒造梦师阅读(34) 评论(0) 收藏举报

刷新页面返回顶部

月光宝盒造梦师

志在创造