AgentKit
AgentKit
文档指南
请输入
- 文档首页
AgentKitDeliveryAI产品简介应用场景
复制全文
下载 pdf应用场景
文档反馈
问问助手DeliveryAI 是嵌入在 AgentKit 控制台的一项交付服务，用于把“需求 → 交付 → 代码 → 环境”接成一条可治理、可验证的自动化链路。它面向希望将智能体真正落到软件交付过程中的企业与研发团队。本文按“做什么、由谁做、产出什么证据”的思路，介绍 DeliveryAI 的典型适用场景，帮助新手用户判断自己团队是否适合引入。
端到端需求交付自动化
适用团队：使用飞书项目作为需求管理系统、通过 CodeBase 管理代码，希望降低“需求 → 代码 → 上线”链路人工衔接成本的研发团队。
典型链路：
- 在飞书项目使用指定流程模板创建需求；
- 需求自动同步到 DeliveryAI 产品空间，进入需求澄清节点；
- Agent 读取项目地图、系统架构、技术栈与相关代码后，生成人工确认卡片；
- 用户完成人工确认，流程依次经过 Spec 设计、编码实现、联调测试、MR、正式环境发布；
- 每个节点自动沉淀 Spec、代码提交、测试报告、截图、MR、CI、发布报告等证据；
- 完成后由业务负责人在正式环境完成最终验收。
能解决什么问题：
- 将需求与代码基线自动关联，避免 Agent 在错误分支上工作。
- 把"需求澄清"从口头讨论前置为结构化确认卡片，确保范围、来源、边界有据可查。
- 通过节点化流程明确"谁做什么、产出什么"，减少交付信息在多个系统之间的丢失。
智能体驱动的研发角色沉淀
适用团队：希望把“需求分析师、Spec 设计师、Coding Agent、测试与发布 Agent”等角色标准化，供多个项目复用的团队。
典型做法：
- 在产品设置 → Agent 配置中，创建自定义 Agent 模板，或基于系统内置模板（例如"需求分析师"）复制并微调。
- 每个模板明确 Coding Agent、模型、Skills、MCP 与系统提示词，把角色的职责、边界与输出规范固化下来。
- 将模板绑定到流程节点，形成“节点 = 角色”的稳定映射，避免每个新项目重复搭建。
能解决什么问题：
- 通过模板复用，减少 Agent 的重复配置成本，降低使用门槛。
- 通过统一 Skills 与 MCP 的绑定关系，保证同一角色在不同项目上的行为一致。
- 对模板设置负责人、版本与变更记录，方便审计与后续演进。
可追溯的 AI 研发过程
适用团队：在需求交付中引入 AI 后，需要用统一方式沉淀与审计交付证据的团队，尤其适合对合规、审阅要求较高的业务线。
核心能力：
- 每个节点都会产生可查阅的证据：Spec 文档、代码提交哈希、测试报告、桌面端与移动端截图、MR 链接、CI 与 Review 状态、发布报告、健康检查结果。
- 需求详情面板支持在“需求详情、Spec 文档、文件”标签之间切换，跨节点集中查阅产物。
- 需求中心支持按"未开始、已完成、待人工处理、Agent 执行中"状态筛选，便于回溯任意一条需求的历史。
能解决什么问题：
- 让“Agent 说完成了”变成“证据说完成了”，避免仅凭状态位判断交付质量。
- 一旦出现线上问题，可以顺着节点证据回溯到 Spec、代码、测试与发布记录，快速定位。
- 满足团队内部审阅、Code Review 与运维审计对可追溯性的要求。
交付链路的分层治理
适用团队：既需要统一的团队默认流程，又允许成员按个人工作方式适配的团队；空间管理员与普通用户并存。
典型分工：
个人级配置：普通用户可在“个人设置”中维护个人消息通知 Bot、个人服务授权、个人 Agent 模板、个人 Skill、个人 MCP，以及“按产品空间覆盖”的个人流程配置，仅对当前用户生效。
能解决什么问题：
- 空间管理员统一控制关键治理策略，避免个人配置扩散到全空间。
- 普通用户在明确的责任边界内推进需求，减少误操作与越权风险。
- 通过“空间级 + 个人级”双层配置，兼顾团队一致性与个人灵活性。
存量流程接入与渐进式落地
适用团队：已有一套需求管理与研发流程，希望以“先接入示例流程、再逐步扩展节点”的方式，稳妥引入 AI 交付能力。
典型接入路径：
- 在 AgentKit 控制台开通 DeliveryAI 服务；
- 建立第一个产品空间，绑定飞书项目需求空间与 CodeBase 代码仓库、基准分支和标签；
- 导入示例流程，先启用少量 AI 节点，其余保留人工节点；
- 在小范围 Demo 需求上完成端到端验收，观察证据是否完整、人工确认是否合理；
- 逐步把更多节点从人工调整为 AI，或引入自定义 Agent 模板、Skills 与 MCP；
- 在正式生产化前，完成上线前验收清单。
能解决什么问题：
- 通过小步接入避免“大爆炸式”改造，降低对现有交付流程的冲击。
- 用示例流程先跑通链路，再按团队实际需要定制 Agent、Skills 与 MCP。
- 用上线前验收清单强制形成一次真实的端到端验证，避免只看“已绑定 / 已启用”的假成功。
什么场景暂不建议使用
DeliveryAI 依赖“可结构化、可追溯”的交付流程。以下场景当前不建议直接使用：
- 需求描述极度模糊、缺少验收标准（例如仅一句"帮我优化一下页面"），Agent 无法判断范围与完成标准。
- 完全脱离代码仓库、飞书项目或类似需求管理系统的一次性事务型任务。
- 高频、极短生命周期的临时性变更，且不需要沉淀 Spec、测试、MR 与发布证据。
对于上述场景，建议先在团队内明确需求描述规范和证据要求，再决定是否引入 DeliveryAI。
最近更新时间：2026.08.18 01:21:18
这个页面对您有帮助吗？
有用
有用
无用
无用