阿里妹:端到端业务需求专家 Agent——4 层架构 × 8 步流程
核心命题:业务需求专家 Agent,不是更聪明的代码生成器,而是把需求研发里的上下文、工具调用、人工确认、验收证据、反馈沉淀组织成闭环——Agent 自主推进,人只在关键节点确认。
核心结论(5 句话)
- AI 写代码已不是主要瓶颈,真正贵的是代码之外的串联成本——Aone/CR/代码仓/配置平台/SLS/HSF/监控/钉钉文档,每次切换都丢上下文,人都要重新做判断。
- 系统本质 = 业务需求承接系统:4 层横向架构(上下文输入/业务专家编排/工具执行/反馈学习)走完 8 步纵向流程(需求进入→澄清→方案→实现→CR 协同→验收→发布→结项沉淀)。
- 关键设计取舍 3 条:①「不直接升级」原则(过程材料留项目记忆,结项审视后才进长期 wiki)②质量门禁硬规则化(pre-push hook 注入 PMD + 覆盖率,推不上去才是真卡口)③反馈留痕到平台(评论/工单/里程碑,而不是聊天框)。
- 3 大现有问题:接入成本高(平台多只支持网页授权,未对命令行沙箱适配)、缺 Agent 效果度量体系(人工介入次数/返工率/回滚次数未量化)、单 Agent → Agent Team(共享长期 wiki,各自维护视角,不按流程机械切分)。
- 这套方法论已经可复用:数据方向已复用同一框架,说明它不是后端特例,而是通用研发流程。
知识节点(8 个独立概念)
节点 1:业务需求专家 Agent
把业务需求从进入到结项的完整过程,组织成 Agent 能自主推进、人只在关键节点确认的闭环。核心不是模型能力,而是流程组织能力。
节点 2:串联成本瓶颈
真正贵的不是代码生成,而是需求澄清→方案确认→实现→代码评审→验收→发布观察→结项沉淀整条链路里的上下文切换和人工补位。问题拆开看有 3 个:上下文能不能组织起来、工具能不能串起来、反馈能不能产生复利。
节点 3:4 层横向架构
| 层 |
回答什么 |
关键产出 |
| 上下文输入层 |
Agent 靠什么理解业务 |
长期业务知识 + 当前需求材料 + 代码事实 + 运行证据 |
| 业务专家编排层 |
下一步该做什么 |
阶段判断 + 是否需要人工介入 |
| 工具执行层 |
具体动作怎么落地 |
Aone/代码评审/配置平台/SLS/HSF/监控 变成可调能力 |
| 反馈学习层 |
下次能不能更好 |
稳定知识→长期 wiki / 流程问题→技能改进候选 / 一次性材料→归档 |
没有第四层,系统就是无状态的,每个需求都得从零开始。
节点 4:8 步纵向流程
- 需求进入:先组织上下文,区分代码仓 / 项目记忆仓 / 长期 wiki 仓。
- 需求澄清:生成 requirements,把目标/边界/验收/风险结构化。
- 技术方案:方案阶段就把”怎么验收”定清楚。
- 实现与内部质量门:测试驱动开发 + 内部结构化审查。
- CR/Issue 协同:评论最密的阶段其实是澄清和方案。
- 验收验证:独立项目环境部署 + HSF/SLS/监控取证。
- 发布与观察:上线是节点不是终点,观察期无异常才算稳定。
- 结项沉淀:稳定知识进长期 wiki,流程问题进技能改进候选,一次性材料归档。
节点 5:「不直接升级」原则
过程材料不直接进入长期 wiki,而是先留在项目记忆层。只有经过结项审视和人工确认,才蒸馏进长期知识库。这样既避免噪声污染,也保证每次结项都能沉淀出真正可复用的业务知识。
节点 6:质量门禁硬规则化
最关键的一点不是”提醒 Agent 要验证”,而是让 Agent 绕不过去。落地方式是 git pre-push hook 注入 PMD 校验 + 覆盖率检查 + diff-to-test 映射:不通过就直接拒绝 push。质量门禁从”应该做”变成”不做就推不上去”。
节点 7:反馈留痕到平台
反馈不能只留在聊天框,要留在 Aone / CR / issue / milestone 里。这样结项时才能系统回看:哪些澄清反复出现、哪些代码模式总被指出、哪些人工介入本可以自动化。
节点 8:Agent Team 拆分准则
前后端协同的复杂需求,适合拆成前端 Agent / 后端 Agent / 测试 Agent / 产品 Agent / 数据专家 Agent,再加一个队长角色做拆解与协调。关键约束是共享长期 wiki,各自维护视角。但拆分不能按流程步骤机械切,而要看是否真有独立判断、独立产物、并行执行和责任隔离的需要。
关联图谱(3 段)
- 上游(产业入门)→ 本文(阿里内部落地)→ 下游(技能形态):[[APPSO-Codex-Claude-Code-Loop-Engineering]] → 本文 4 层 × 8 步 → [[Addy-Osmani-agent-skills-设计哲学]]
- 同级(Loop 主题):[[Addy-Osmani-Loop-Engineering]] + [[Loop-Engineering-详解-把反馈循环放进工程现场]] + [[Agentic-Engineering-AI-Workbench]]
- 同级(组织/Harness 视角):[[Multica-AI-Native-组织-人是最慢的节点]] + [[清华沈阳-自进化AI新物种]] + [[从零设计生产级-Multi-Agent-Harness]]
对 Seetong / OpenClaw / MyAIWiki 的 5 个可借鉴动作
- 复用 MyAIWiki 的 raw/wiki 分层——
raw/ 就是项目记忆层,wiki/ 就是长期知识层,继续坚持”过程材料先留 raw,结项后才进 wiki”。
- 把硬规则放到提示词前面——这跟 [[Skill-Self-Evolution]] 的”验证 Gate 必填 + 失败自动回滚”是同一思路。
- 给 [[seetong-tapd-version-review]] 补”结项审计表”——稳定知识进 wiki,流程改进进 SKILL 候选,一次性材料进 raw,待补证单列回填。
- 把 Seetong 技能从”按主题”升级到”按阶段+按主题”——补
seetong-clarify / seetong-plan / seetong-execute / seetong-finish 4 阶段编排。
- 用这篇文章的 3 大问题做自查——接入成本是否足够低?循环命中/误报/回滚/成本/证据 5 项指标是否有基线?KMP 跨端是否适合拆成多 Agent?
备注与链接
- 原文链接:https://mp.weixin.qq.com/s/9o_z-Poj9r4dbwe3NlC1pw
- 作者:森叶(阿里妹)
- 抓取时间:2026-06-15 13:49
- 分类理由:本文核心是”业务需求 Agent 端到端落地”,主题更偏 AI Agent 落地方法论 + AI 原生组织实践,放在
01-ai-agents 比 02-ai-coding 更贴切。
- 待补证:8 个 superai-* Skill 的源码/实现细节未公开;”独立项目环境部署”的稳定性/成本数据未给;产品 Agent / 数据专家 Agent 目前是规划还是已落地,文中未明说。