5 个 Agent 如何交付一套啤酒节营销系统：平凯 Loop 开发轻量业务应用的实践

啤酒节开幕前，活动玩法还在不断调整：主会场要做满减，精酿专场要上买一送一，音乐嘉年华的套餐价格也可能临时变化。对业务来说，这些只是几条促销规则；对研发来说，背后却涉及需求确认、代码修改、测试、部署和验收。如果每次变化都重新走一轮跨团队排期，系统上线时，营销窗口可能已经过去。

这类需求不是传统大型软件工程的缩小版，而是一类很典型的轻量业务系统：业务边界相对明确，以数据管理、状态流转和规则配置为主，需要快速上线，也需要持续修改。

为了验证一种更敏捷的交付方式，我们在平凯 Loop 中组建了一支由 5 个角色 Agent 构成的协作团队，开发了一套啤酒节智能营销促销系统。它覆盖活动管理、促销配置、优惠券发放与核销、客户分群、A/B 实验和运营看板，并提供了可以直接体验的顾客端 Demo。

这次实践想回答的不是“Agent 能不能写代码”，而是另一个更实际的问题：当需求、开发、测试、部署都需要协同时，如何让多个 Agent 在同一套上下文和验收机制下，把一个轻量业务系统真正交付出来？

• 客户端通过 HTML5 登录 Web 页面访问参与活动

• 营销端通过后台页面分析数据情况以及智能问数

• 后端可见促销系统的客户旅程

平凯 Loop 多 Agent 团队交付的啤酒节智能营销促销系统 Demo

一、什么样的轻量业务系统适合用 Loop 开发

“轻量”不等于只有几个静态页面，也不等于可以降低质量要求。它更多是指系统的业务边界、协作规模和集成复杂度相对可控。

适合快速交付的轻量业务系统，通常有几个共同特征：

1. 核心流程可以被清楚描述，例如创建活动、配置规则、审批、发券、核销；

2. 主要能力由表单、数据管理、状态流转、权限和统计分析构成；

3. 需求变化频繁，但单次变化的影响范围可以界定；

4. 验收结果可以观察和测试，而不是完全依赖主观判断；

5. 外部系统依赖有限，或者能够通过清晰的接口边界隔离。

活动运营平台、内部管理工具、数据看板、审核系统、客户运营工具和场景模拟器，都属于这类需求。啤酒节营销系统也是一个典型样本：业务玩法变化快，但“活动—促销—优惠券—订单—分析”的主链路是明确的，很适合拆成可独立开发和验收的任务。

最终交付的 Demo 包含 17 个 REST API，以及一条覆盖“活动创建 → 促销配置 → 审批 → 发券 → 核销 → 客户分群 → A/B 实验 → 业务模拟 → 运营看板”的演示链路。顾客端可以切换不同活动，查看满减、折扣和套餐促销，领取优惠券、模拟下单并查询记录。Demo 预置了 3 个活动和 16 条促销数据，打开即可体验。

技术栈采用 Go 1.22、Gin、TiDB Cloud Serverless 和 Redis 7，通过容器化方式运行，并使用 GitHub Actions 执行自动化检查。仓库同时提供 TiDB Cloud 和本地 MySQL 两种启动路径，方便开发者从零部署和二次开发。

系统能力图

二、不是让一个 Agent 包办，而是建立一条协作链

个人使用 AI Coding 工具时，任务通常是“帮我写一个接口”或“修复这个错误”。一旦进入完整项目，问题就不再只是生成代码：需求由谁拆解，改动是否越界，谁负责测试，部署后如何验证，出现分歧时谁做决定，都需要明确机制。

啤酒节项目在 Loop 中配置了 5 个角色 Agent：

Leader 也是 Agent，并不代替人类项目负责人。人的职责是确认目标、处理超出既定范围的决策，并在涉及发布、数据变更和安全风险时做最终判断。Agent 负责持续推进那些可拆解、可验证、可留痕的工作。

同一项目上下文中的角色分工与任务流转

三、五条可以复用的协作实践

实践一：一个需求对应一个线程，先写验收标准再开工

项目中的每个需求都在独立线程中讨论，相关任务再进入任务板。线程保存“为什么做、决定了什么”，任务记录“由谁做、做到哪一步、如何验收”。这样可以避免需求散落在私聊、文档和口头沟通中。

一个可以直接复用的任务描述至少包含五项内容：

• 背景：为什么要改；

• 范围：本次改什么、不改什么；

• 输入：相关页面、接口、数据和约束；

• 验收：什么结果可以判定完成；

• 风险：哪些操作必须等待人工确认。

对 Agent 来说，清晰的验收标准比一段很长的背景介绍更重要。例如，“增加满减规则”仍然过于模糊；“运营可以创建满 300 减 100 的规则，未达到门槛时订单不抵扣，重复请求不重复发券”才是可实现、可测试的任务。

实践二：按照交付物划分角色，而不是让多个 Agent 重复工作

多 Agent 不等于把同一条指令同时发给几个模型。角色设计的关键是：每个 Agent 对一种结果负责，并且能够检查上一个角色的产出。

RD 负责实现，但不能给自己的代码做最终放行；QA 负责验证，但不直接修改业务实现；DevOps 负责环境和部署一致性，但不代替 QA 判断业务是否正确。角色边界越清楚，重复劳动和“大家都以为别人检查过”的风险越小。

实践三：按照依赖关系安排顺序，而不是机械套用固定流程

任务并不总是按照“开发 → 测试 → 运维”串行推进。对于需要在线环境才能验证的功能，更合理的顺序是：

需求确认 → RD 开发和本地自检 → DevOps 部署到演示环境 → QA 在线验证 → 人工确认闭环

测试用例设计可以和开发并行，但浏览器验收必须等到可测试版本部署完成。通过在任务板中明确依赖关系，Agent 可以提前完成不受阻塞的工作，也能在依赖未满足时停止无效尝试。

如果任务涉及数据库迁移、清理数据、对外发布或权限调整，则在执行前增加人工确认节点。速度来自减少等待和重复沟通，而不是跳过必要的控制。

实践四：把“完成”定义为一组证据，而不是一句回复

代码写完不等于需求完成，服务能够启动也不等于业务正确。这个项目将完成标准拆成三层：

1. 静态检查：代码、配置、敏感信息和变更范围符合要求；

2. 自动化检查：单元测试、接口测试和业务流程测试通过；

3. 真实交互检查：在浏览器中按照用户路径完成操作，并核对页面、接口和数据结果。

每次交付都要能够关联到代码版本、测试结果、部署版本和最终验收结论。对于关键结论，至少使用两条相互独立的验证路径，例如接口测试与浏览器操作互证。这样，“已完成”才是其他成员可以复核的工程事实。

实践五：把踩坑记录成下一轮可以执行的规则

项目中遇到过环境变量位置不一致、部署版本与预期不一致、提交历史包含敏感信息等问题。如果这些经验只停留在一次聊天中，下一个任务仍然会重演。

因此，团队把稳定的做法写入项目文档、角色职责和 Agent 记忆，例如：部署前检查环境变量来源；发布时记录提交版本与构建产物；提交前自动扫描密钥、邮箱和服务器地址；开源前检查当前代码树与 Git 历史。

需要注意的是，重写 Git 历史只能作为敏感信息已经进入仓库后的补救措施。更好的实践，是通过示例配置、密钥管理和提交前扫描，从源头阻止敏感信息进入版本库。

四、一次 25 分钟变更，真正节省的是什么

项目中有一次“统一品牌词，并把测试数据扩展为多活动”的需求调整。它涉及代码修改、演示环境部署、重新生成种子数据和完整业务链路验收。

18:14，Leader Agent 完成拆解并派发任务；随后 RD、DevOps 和 QA 按依赖关系接力执行；18:40，QA 给出最终放行结论。整个变更从派单到验收约 25 分钟。

这里需要强调：25 分钟指的是一次范围明确的增量变更闭环，不是从零开发整套系统的时间。 它说明的也不是 Agent 能瞬间写完所有代码，而是当角色、上下文、环境和验收规则已经建立后，需求不必在不同人员和工具之间反复搬运，开发完成后可以立即进入部署和验证。

这次实践中，Loop 带来的效率主要来自三件事：

• 上下文共享：需求、决定、代码版本和测试结论在同一条任务链上；
• 依赖显性化：下一位执行者不必等待人工通知，也不会在条件不具备时重复试错；
• 验收标准前置：Agent 知道什么时候可以交付，QA 也知道应该检查什么。

换句话说，Loop 优化的不只是写代码的速度，更是从需求到验收之间的协作损耗。

五、轻量系统可以快速交付，但不能省略生产化工作

这个项目验证的是：Loop 可以组织多个 Agent，快速完成一套有真实业务流程、前后端交互和数据状态的轻量业务系统参考实现。它并不意味着 Demo 无需改造就可以承载正式业务。

如果要进入生产环境，还需要根据场景补齐 HTTPS、身份认证、权限隔离、审计日志、数据保护、容量测试、监控告警、备份恢复和发布回滚等能力。涉及真实支付、核心交易、个人敏感信息或强监管数据时，还应引入更严格的安全与合规评审，并保留明确的人工审批节点。

因此，更适合使用这套模式起步的场景包括：

• 活动运营和营销配置系统；

• 内部数据录入与管理后台；

• 审批、工单和进度跟踪工具；

• 数据看板和业务模拟器；

• 边界清晰的客户运营工具。

而对于需求边界尚不明确、与大量遗留系统深度耦合，或者直接承担资金与高敏感数据处理的核心系统，更合适的方式是先用 Loop 完成需求梳理、原型和独立模块，再经过架构、安全和合规评审逐步扩展。

写在最后

轻量业务系统的难点，往往不是某一个接口有多复杂，而是需求持续变化时，产品、研发、测试和部署如何保持在同一个节奏中。

啤酒节项目的实践表明，当需求能够被清晰拆解、角色拥有明确边界、任务按照依赖关系推进、完成结果由证据判断时，多 Agent 才不只是同时生成更多内容，而是能够组成一条真正可运转的交付链。

Loop 的价值也正在这里：它不只帮助一个人更快地写代码，而是把人和多个 Agent 放在同一个项目上下文中，让轻量业务系统从需求、开发、测试到交付的全过程，都变得更快、更清晰，也更容易复用。