---
title: "阿里云端到端业务需求专家 Agent：Multica 平台 + superai-* 技能集群 + TDD/pre-push 质量门禁"
type: raw
source_url: https://mp.weixin.qq.com/s/9o_z-POj9r4dbwe3NlC1pw
source_mp: 阿里云开发者
source_author: 阿里云开发者（阿里妹 导读）
published: 2026-06-15
ingested: 2026-06-15
sha256: e9a1f23d196a02f618a82b910f9715ec36ebf7784925d588f213f94995f16bfb
tags: [agent, aliyun, multica, skill, harness, tdd, quality-gate, requirement-engineering, aone, delivery-pipeline, memory, dual-wiki, pre-push-hook]
sources: []
review_value: 8
review_confidence: 7
review_recommendation: strong
review_stars: 4
---

# 阿里云端到端业务需求专家 Agent：Multica 平台 + superai-* 技能集群 + TDD/pre-push 质量门禁

> 阿里妹 导读：如何把业务需求从进入、澄清、方案、实现、CR 协同、验收、发布到结项沉淀，组织成一套能减少人工干预、能自我验收、能吸收反馈并持续成长的 Agent 研发闭环。文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
>
> 这篇文章不讲 prompt 技巧，也不做单次 AI 写代码的 demo。它记录的是一套已经在真实业务需求上跑通的端到端链路。

## 1. 问题：代码之外的串联成本才是真正的瓶颈

AI 写代码本身已经不再是主要瓶颈。但一个业务需求从 PRD 到上线，中间要经过需求澄清、方案确认、实现、CR、验收、发布观察和结项沉淀—— 代码生成只是其中最标准化的一段，真正贵的是代码之外的串联成本。

每个环节 AI 都已经能参与一点，但如果这些能力只是散落在不同对话、不同工具和不同命令里，最后真正负责串起来的还是人。

**三个工程化问题**:

- **上下文能不能被组织起来** — 需求文档、用户澄清、历史业务知识、代码事实、配置平台、日志和人的经验，原本分散在不同地方。
- **工具能不能被串起来** — Aone、CR、代码仓、配置平台、SLS、HSF、监控、钉钉文档等都参与研发链路，但过去需要人手动编排。
- **反馈能不能产生复利** — CR 评论、issue 对话、验收记录、自恢复日志和人工修正，如果只停留在聊天记录里，下一个需求大概率还会再犯一次。

> [!quote] 业务需求专家 Agent
> 它不是一个更聪明的代码生成器，而是把需求研发过程中的上下文、工具调用、人工确认、验收证据和反馈沉淀组织成一个闭环，尽可能把人从重复性的串联、取证和回忆里解放出来。

## 2. 总体架构：四层闭环

从静态视角看，这套系统可以拆成四层，**不是并列模块，而是一条从事实输入、阶段判断、工具落地到反馈回收的闭环**:

| 层 | 名称 | 解决的问题 |
|----|------|----------|
| 第一层 | 上下文输入层 | Agent 靠什么理解业务（按阶段拉取长期业务知识、当前需求材料、代码事实、运行证据） |
| 第二层 | 业务专家编排层 | 下一步该做什么（澄清/方案/实现/验收阶段的判断；哪些地方必须停下来等人确认） |
| 第三层 | 工具执行层 | 具体动作怎么落地（Aone/Code/CR/配置平台/SLS/HSF/监控/钉钉文档按阶段调用） |
| 第四层 | 反馈学习层 | 下次能不能更好（CR 评论、issue 对话、验收记录、自恢复日志、人工修正 → 长期 wiki / codemap / skill 改进） |

**为什么选 Multica 作为落地平台**（文章原话）:

> 这套方案本身不绑定特定平台，核心仍然是 skill 的组合编排和提示词设计。落地时选择 Multica，是因为它在几个关键基础设施问题上降低了成本：独立 issue 工作区带来上下文隔离，Agent 与 skill 绑定减少每次手动拼装，多运行时和沙箱让需求可以持续推进，不依赖本地开发机在线。

## 3. 纵向闭环：一个需求如何被业务专家承接

### 3.1 需求进入：先组织上下文

**两类信息必须先到位**:
- **当前需求材料**: Aone 工作项、钉钉 PRD、issue 评论、用户补充说明
- **长期业务知识**: LLM Wiki、codemap、历史口径、系统边界

**三仓库上下文管理设计**:

```
代码仓库 (master)
  │
  ├─ 长期 wiki 仓库 (master, 永远在 master)
  │    └─ 业务知识、codemap、历史口径
  │
  └─ 项目记忆仓库 (feature/<需求-id> 分支)
       ├─ requirements.md     (澄清阶段产出)
       ├─ plan.md             (技术方案)
       ├─ progress.md         (实现进度)
       ├─ verification.md     (验收证据)
       └─ closeout-raw.log    (结项审计)
```

**核心设计原则 — "不直接升级"**:

> 项目过程中产生的事实先留在项目记忆层，只有经过结项审视和人工确认，才会选择性地进入长期知识。这样既避免了噪声污染长期 wiki，也保证了每次结项都能沉淀出真正有复用价值的业务知识。

**底层能力**:
- `superai-memories` — 上下文拉取和组织
- `superai-aone` — Aone 工作项操作
- `dingtalk-doc-rw` — 钉钉文档读写

### 3.2 需求澄清：第一质量门

**底层 skill**: `superai-clarify`（结构化澄清方式）

**澄清产出** = requirements.md（项目记忆第一份文件）:
- 目标行为
- 非目标边界
- 验收标准
- 风险
- 待确认问题

> [!key] 协作留痕
> 对 Agent 的反馈不应该只停留在对话框里，而应该尽量落到 Aone / Code 平台本身的评论体系里，例如 requirements 的确认评论、代码评审 MR 的反馈和 resolve 记录。

**门禁规则**:
- 确认前 `superai-workflow` 不应该继续进入技术方案或实现
- 确认后的 requirements 会成为后续 plan、实现和验收的共同基准
- 澄清是**第一质量门**（最高密度的人工反馈发生地）

### 3.3 技术方案：第二质量门

**澄清后不是直接写代码**，先写技术方案 — **人工确认最密集的第二处**:

- 现状是什么
- 目标行为是什么
- 不做什么
- 影响范围在哪
- 核心改动点是什么
- 风险在哪
- 怎么验证
- 出问题怎么回滚

**"怎么验收"必须在方案阶段就定清楚**（关键设计点）:

> 很多需求到了实现完才开始想怎么验证，结果发现验收条件不明确、配置状态没确认、边界场景没覆盖，又要回头补。所以在方案阶段，验收方式、测试策略和验证入口就应该写进 plan。

**验收覆盖三类**（在 plan 里定好）:
- **正例**: 核心业务场景
- **反例**: 边界条件和异常路径
- **回归**: 改动是否影响了不应该变化的行为

**配置类需求特别处理**（天机星策略 / 工作台配置 / 开关 / 白名单 / 人群分流）:

> 方案阶段不只是读取当前配置状态，还包括提前创建好配置的 schema、完成配置校验，并把这些信息写进技术方案文档里。

**底层 skill**:
- `superai-plan` — 方案编写
- `superai-tjx` + `superai-mt` — 基于天机星 CLI (`tjx-cli`) 和工作台 CLI 的配置取证和 schema 校验

### 3.4 实现与内部质量门：TDD、PMD、review

**实现阶段** = `superai-execute` 负责编码和 TDD 推进。

**关键设计决策 — TDD 驱动实现**（反 AI 写测试的最常见失败模式）:

> AI 写测试最常见的失败模式不是"写不出来"，而是"为了通过覆盖率而写"——先写完代码，再补一堆只验证代码能跑通的测试，本质上只是在用测试确认自己的实现，而不是用测试约束正确行为。
>
> 真正有价值的 TDD 是反过来的：先根据 plan 里已经定好的验收标准和业务行为写测试，让测试定义"什么是对的"，再让实现去满足测试。

**三道内部硬门禁**（pre-push quality gate — Agent 自己必须过）:

| 门禁 | 触发机制 | 检查内容 |
|------|---------|---------|
| **diff-to-test 映射** | pre-push hook | 每一处生产代码的行为变化都要有具体测试锚点 |
| **PMD / lint** | pre-push hook | 规则类问题由自动化工具捕获 |
| **Agent 内部代码 review** | `superai-code-review` | PMD 通过后，对完整待 push diff 做结构化 review |

> [!warning] 关键设计取舍
> 这些门禁不能只靠提示词约束，必须变成 Agent 绕不过去的硬规则。提示词再怎么写"push 前必须跑 PMD"，Agent 在复杂任务中还是可能跳过。所以落地时，我们通过 git pre-push hook 把 PMD 校验和单元测试覆盖率检查注入到 push 流程里——Agent 执行 `git push` 时，hook 会自动触发检查，不通过就直接拒绝 push。
>
> 这样质量门禁就从"Agent 应该做"变成了"不做就推不上去"，是真正的工程化卡口，而不是靠提示词的自觉。

### 3.5 CR / Issue 协同：把人机反馈留下来

> 评论协作最密集的阶段恰恰是澄清和方案，而不是代码实现。需求理解对了、方案确认了，到了真正写代码的时候，以现在 Agent 的能力反而不需要那么多微操。

**关键设计 — 评论必须留在可追溯的地方**:

- Agent 主动读取 CR 上的 unresolved 评论
- 按评论内容修改对应文档或代码、提交新 commit、回复并 resolve
- 评论涉及需求语义或范围变更 → 回到 requirements 或 plan 阶段重新确认（不在当前层面硬改）
- 重大节点通过 Aone milestone 评论回刷（澄清完成、方案确认、进入 TDD、代码完成、CR 反馈处理、验收通过）

**为什么强调"留痕"**:

> CR 评论和 issue 对话不只是当次需求的协作工具，更是后续结项沉淀的素材。哪些澄清反复出现、哪些代码模式被反复指出、哪些人工介入本可以自动化——这些信息只有留在平台上，结项时才能被系统性地回看和分析。如果反馈只停在聊天框里，需求结束就蒸发了。

**底层能力**: `superai-aone`（基于 a1 CLI）+ Aone 钉钉群绑定（Agent 做评论和回刷，团队在钉钉群里就能直接收到通知）

### 3.6 验收验证：让 Agent 用真实证据确认结果

> 单元测试通过不等于业务做对了。

**独立项目环境验证**（不在共享预发上跑）:
- Agent 创建或复用独立的项目环境
- 把当前 feature 分支部署上去
- 通过 HSF 泛化调用验证业务行为
- 通过 SLS 查询验证日志输出
- 通过监控或 Sunfire 验证运行时指标

**底层 skill**:
- `superai-aone` — 独立项目环境的创建和部署
- `superai-sls` — SLS 日志查询
- `superai-ops` — HSF 泛化调用和监控指标核对

**人工确认门保留**: 独立环境验收通过后，进入主预发或线上发布之前，仍然需要人工确认。Agent 不会自动执行主预发部署或线上发布。

### 3.7 发布与变更观察：上线不是流程终点

> 上线是需求交付的一个节点，不是终点。

- 变更材料、风险评估和回滚预案 → Agent 协助准备
- 发布动作 → 仍由人工确认和执行
- 发布后观察期 → 复用 `superai-sls` 和 `superai-ops` 回读日志、监控指标
- 只有观察期无异常，才算真正可以进入结项

### 3.8 结项沉淀：让下一次需求更少依赖人工

**结项回答三个问题**:

| 类别 | 处理方式 |
|------|---------|
| **稳定的知识**（业务规则、系统边界、验收规范、排障经验） | 通过 CR 确认后进入长期 wiki 和 codemap |
| **可改进的流程**（Agent 在哪个环节犯了错、被人工反复纠正） | skill / 提示词的迭代候选 |
| **只需归档的材料**（一次性实现细节、临时调试记录） | 留在 closeout raw log |

**结项审计表格**形式产出（示例: bug 排查、配置变更、流程反思分别归类）。

**底层 skill**:
- `superai-finish` — 结项入口编排
- `superai-memories` — 项目记忆收口和长期 wiki 候选生成

> 这样就真正合上了 3.1 里描述的闭环：结项蒸馏出的稳定知识回到长期 wiki，成为下一个需求进入时的「长期业务知识」背景拉取来源。每做一个需求，Agent 理解业务的基线就高一点，人需要解释的上下文就少一点。

## 4. 现有问题与后续规划

### 4.1 接入成本还需要降低

当前 Agent 的首次接入成本偏高，主要在鉴权和运行时初始化环节。集团内不少平台工具还只支持网页授权登录，没有对 Agent 的命令行沙箱环境做好适配。这是过渡态问题。

### 4.2 缺少 Agent 效果的度量体系

**至少需要观测的 4 个维度**:

| 维度 | 观察指标 |
|------|---------|
| 人力投入 | 人工介入次数、评论轮次、人工修正比例是不是在下降 |
| 需求质量 | 方案返工率、验收一次通过率是不是在提升 |
| 线上稳定性 | 上线后的问题数、回滚次数是不是在减少 |
| 协作效率 | Aone 和 Multica 双事实源之间的同步成本、跨平台信息丢失率是不是在可控范围 |

> 有了这样的度量基线，才能判断每一轮 skill / 提示词迭代到底是改进还是退化，Agent 的自我成长才有据可循，而不是靠感觉。

### 4.3 从单 Agent 走向 Agent Team

**关键设计约束 — 共享长期 wiki，各自维护视角**:

```
PD Agent ──┐
           ├─ 共享同一份长期业务知识
前端 Agent ─┤  各自维护自己的 requirements、plan 和过程产物
           │
后端 Agent ─┤  队长负责把各方产物对齐
           │
测试 Agent ─┘
```

**关键设计原则**:

> 这个 team 模式的关键设计约束是共享长期 wiki，各自维护视角。所有 Agent 共享同一份长期业务知识，保证对业务理解的一致性；但每个 Agent 从整体需求中只拆解出跟自己职责相关的部分，各自维护自己的 requirements、plan 和过程产物。队长负责把各方产物对齐，确保前后端接口契约一致、测试覆盖完整。

**铺垫 PD Agent 角色**:

> 往上游看，需求产出本身也可以纳入：一个 PD Agent 负责生成 PRD、梳理业务规则、输出验收标准，它同样共享长期 wiki，了解过去的技术方案和业务需求历史。这样一来，前面 3.2 里人工介入最密集的需求澄清环节，就可以变成 PD Agent 与业务专家 Agent 之间的直接对齐，人只需要在关键歧义处做最终裁决，而不是全程逐条解释业务背景。

**已经试点的数据方向扩展**:

> 一个数据专家 Agent 采用和后端 Agent 相同的方法论——上下文组织、方案确认、TDD 实现、验收取证、结项沉淀——但专注于离线数据开发、报表生成和数据分析。它验证了一件事：这套框架不是只能用在后端编码上，而是可以被不同领域的 Agent 复用的通用研发流程。

> 这个 team 模式的关键设计约束是共享长期 wiki，各自维护视角。所有 Agent 共享同一份长期业务知识，保证对业务理解的一致性；但每个 Agent 从整体需求中只拆解出跟自己职责相关的部分，各自维护自己的 requirements、plan 和过程产物。队长负责把各方产物对齐，确保前后端接口契约一致、测试覆盖完整。

**不急于提前铺设**:

> Agent 拆分不应该按流程步骤机械切分，而应该看是否真的存在独立判断、独立产物、并行执行和责任隔离的需要。在还没有足够多的真实复杂需求验证之前，不急于提前铺设。

## 5. 结语

> 这套系统做的事情可以用一句话概括：把一个业务需求从进入到结项的完整过程，组织成 Agent 能自主推进、人只在关键节点确认的闭环。
>
> 它现在还远谈不上完善——接入成本、度量体系、多 Agent 协作都是摆在前面的问题。但已经跑通的这条链路证明了一件事：需求研发过程中大量重复的上下文组织、工具调用、取证验证和经验回收，确实可以被系统化地交给 Agent，而不是每次都靠人脑记忆和手动串联。

**隐含的协作模式转变**:

> 人不应该继续在每个需求里反复补位，而是把这些补位动作沉到系统里。Agent 缺上下文，就补知识和项目记忆；缺能力，就补工具接口；流程容易跑偏，就补确认门和质量门；反馈容易丢失，就补评论、验收和结项沉淀。只有这些工作条件被系统化，需求交付才不会继续卡在人身上。

> 也许真的会有一天，PD 提完需求之后，就能直接交给对应的业务 Agent 去研发、验收和上线。

## 全文 superai-* 技能清单

| 技能 | 用途 | 涉及阶段 |
|------|------|---------|
| `superai-workflow` | 流程编排（门禁控制） | 3.2 澄清门禁 |
| `superai-memories` | 上下文拉取、组织、长期 wiki 蒸馏 | 3.1 进入 / 3.8 结项 |
| `superai-aone` | Aone 工作项 + CR 评论 + milestone 回刷 + 独立项目环境 | 3.1 / 3.5 / 3.6 |
| `superai-clarify` | 结构化澄清 → requirements | 3.2 澄清 |
| `superai-plan` | 技术方案编写 | 3.3 方案 |
| `superai-tjx` | 天机星 CLI 配置取证 | 3.3 配置 |
| `superai-mt` | 工作台 CLI 配置校验 | 3.3 配置 |
| `superai-execute` | 编码和 TDD 推进 | 3.4 实现 |
| `superai-code-review` | 结构化代码 review | 3.4 PMD 后 review |
| `superai-sls` | SLS 日志查询（验收 + 发布观察） | 3.6 / 3.7 |
| `superai-ops` | HSF 泛化调用 + 监控指标核对 | 3.6 / 3.7 |
| `superai-finish` | 结项入口编排 | 3.8 结项 |

## 相关实体

- [[entities/multica-managed-agents-platform]] — 新文章选用的运行时平台（独立 issue 工作区 + Agent-skill 绑定 + 多运行时沙箱）
- [[entities/alibaba-aone-agentic-rd-mode-xiangbangyu]] — 阿里 Aone Agentic RD 模式（组织层重构视角）
- [[entities/harness-engineered-business-agent-evaluation-aliyun-boyu]] — 阿里泊予 评测 Harness 视角（兄弟文章）
- [[entities/从提需求到部署发布全ai全自动化后研发效能全面跃升]] — 腾讯 CodeBuddy L1→L2→L3 演进
- [[entities/ai-native-rd-org-design]] — AI 原生研发组织设计
- [[entities/agent-harness-context-management-working-set]] — Agent Harness 上下文管理
- [[entities/agent-skill-writing-guide]] — Skill 编写基础
- [[entities/agent-skill-writing-practices]] — Skill 编写实战

→ [[raw/articles/aliyun-end-to-end-business-requirements-agent-multica-2026|原文存档]]