题外话这个系列终于完结了下个系列目前准备围绕“AgentScope-Java”这个开源项目来展开毕竟不能光说不练整体会以项目的形式带大家由浅入深边学边做。感兴趣的同学可以关注下~为什么要写这个系列做Java后端十年我接触过不少企业的核心系统。金融、电商、政务——行业不同但底层的现状惊人地相似生产系统还在Java 8框架停在Spring Boot 2.x甚至更早代码跑了很多年没人敢轻易动。去年开始几乎每个项目都在谈接AI。但真正动手的时候团队就卡住了。不是因为不懂大模型而是老系统本身接不住。JDK版本不够Spring AI引不进来依赖树牵一发动全身升级一个包怕带崩一片生产流量压着不敢拿主流程赌一个AI试点。更危险的是硬塞。我见过团队在老系统的Service层直接new一个HttpClient调模型APIPrompt拼在业务代码里超时没配、降级没有。模型响应慢的时候老系统的订单查询线程池被占满主流程跟着卡住。还有团队把用户手机号、身份证原样送进Prompt过了两个月才被安全审计发现。这种事见多了我就开始想一个问题老系统不具备直接接入AI的条件这是不是大多数企业的常态答案是肯定的。而且这不应该成为接不了AI的理由。核心思路其实就三条老系统少改 —— 不升级 JDK不引入 Spring AI 依赖 AI 能力旁路 —— 独立部署老系统通过 HTTP 或 MQ 调用 企业边界先行 —— 脱敏、审计、降级、幂等比模型调用更重要这个系列就是把这三条线展开成10讲。从AI Gateway到MCP工具中心从SQL Agent到RAG知识库从工单Agent到多Agent研发团队——每一讲都围绕同一个前提你的老系统还在跑Java 8你不能为了AI去赌它的稳定性。每讲配套一个可运行的Maven Lab不讲空架构不写Hello World。你跑得通Demo看得到边界拿得到代码。这就是我做这个系列的原因。这个系列帮你建立企业 AI 接入的架构意识。每个 Demo 都可独立运行每讲都配有边界设计和企业避坑。但意识不等于系统。当你真正要在自己的项目里落地时会发现10 个独立 Lab 的组件需要整合成一个完整的 AI 能力中心Stub 模型需要替换成真实模型调用权限、审计、脱敏需要从 Demo 级别升级到生产级别先把架构意识打好落地时才能走得更稳。Java 8老系统多Agent研发团队实战不是炫技是落到研发流程摘要本文是《Java 8老系统AI接入实战》系列的第10讲聚焦多Agent研发团队在企业老系统中的落地实践。针对Java 8老系统无法直接升级接入AI的普遍困境本系列提出老系统少改、AI能力旁路、企业边界先行三条核心原则。本讲通过一个订单延迟预警的完整Demo展示了五个研发角色AgentPlanner、Architect、Coder、Tester、Reviewer如何围绕结构化输入协同工作输出可落地的技术建议。重点强调多Agent不是全自动开发而是研发辅助编排——通过冲突检测、不确定项显式列出、人工确认等机制让AI能力稳妥地服务企业研发流程。文章最后指出从Demo到生产落地还需Agent输出标准化、Memory持久化、审批流程集成等关键步骤。多Agent很容易被讲成炫技一个 Agent 当产品经理 一个 Agent 当架构师 一个 Agent 写代码 一个 Agent 写测试 一个 Agent 做 Review听起来很热闹但企业真正关心的是它能不能服务研发流程 冲突会不会显式列出 不确定项会不会显式列出 会不会自动提交代码 最终谁确认所以本系列最后一讲不把多Agent写成自动开发团队而是写成研发辅助编排。最终效果代码目录code/spring-ai-enterprise-lab/labs/chapter10-multi-agent-dev-team运行.\compile-and-run.ps1Demo输入一个老订单系统改造需求新增订单延迟预警功能超过 48 小时未发货时提醒客服介入。然后由五个Agent输出结构化建议Planner → Architect → Coder → Tester → Reviewer最后由Orchestrator汇总冲突、不确定项和建议。代码结构核心代码如下src/main/java/com/ynzz/lab/chapter10 ├── agents │ ├── PlannerAgent ← 需求理解和任务拆解 │ ├── ArchitectAgent ← 架构和接入方式设计 │ ├── CoderAgent ← 代码改造建议 │ ├── TesterAgent ← 测试用例建议 │ ├── ReviewerAgent ← 代码 Review │ └── DevAgent ← 各 Agent 基类 ├── common │ ├── DevTaskRequest │ ├── AgentContribution │ └── DevTeamReport └── orchestrator ├── DevTeamOrchestrator ← 多 Agent 编排和汇总 └── ConflictDetector ← 冲突检测每个Agent只负责一个研发视角。DevTeamOrchestrator不让它们直接执行生产动作而是汇总报告。五个Agent的职责边界多Agent最怕变成五个人一起泛泛而谈。所以每个Agent都要有清楚的输入来源、结构化输出字段和禁止动作。下面这张表系统定义了五个Agent的职责边界Agent接收输入从谁那里来产出明确的结构化字段禁止做什么边界PlannerAgentDevTaskRequest.requirement需求文本DevTaskRequest.constraints约束列表DevTaskRequest.projectName项目名taskBreakdown: ListString子任务列表preConditions: ListString待确认前置条件affectedModules: ListString疑似涉及模块clarifyItems: ListString需人工澄清项不直接输出技术实现细节不指定具体类/方法名不做架构决策ArchitectAgentPlannerAgent.taskBreakdown任务拆解DevTaskRequest.constraints旁路约束、Java 版本约束项目上下文 Memory模块列表、调用链accessMode: String接入方式旁路/嵌入/混合moduleBoundaries: MapString, String模块边界及职责responsibilitySplit: String老系统 vs AI 能力中心职责划分riskNotes: ListString架构风险点不输出具体代码 Patch不替开发决定实现细节不绕过企业约束做方案CoderAgentArchitectAgent.accessMode接入方式ArchitectAgent.moduleBoundaries模块边界DevTaskRequest.constraints老系统 Java 8 约束DevTaskRequest.requirement需求patchSuggestions: ListPatchItemPatch 建议列表含文件路径、改动说明、示例代码classMethodHints: ListString类/方法改造点dtoSuggestions: ListStringDTO 建议configurationHints: ListString配置项建议不直接修改仓库不提交代码/Pull Request不自动执行 Patch不绕过 Architect 的模块边界约束TesterAgentDevTaskRequest.requirement需求CoderAgent.patchSuggestionsPatch 建议CoderAgent.classMethodHints改造点testCases: ListTestCase测试用例列表含用例名称、类型正常/边界/异常/幂等、前置条件、预期结果testDataHints: ListString测试数据建议edgeCaseChecklist: ListString边界情况检查清单不跳过业务确认生成生产测试数据不直接访问生产数据库不假设需求中未明确的业务规则ReviewerAgent所有 Agent 的AgentContribution含output和note企业约束规则历史评审结论 MemoryriskList: ListRiskItem风险清单含风险描述、严重度、关联 Agent、建议措施reviewFocus: ListStringReview 关注点preDeploymentItems: ListString上线前必须补充的项approved: Boolean是否建议批准默认 false不直接批准上线不修改代码不忽略冲突检测报告在本讲 Demo订单延迟预警中的具体输出示例对应到当前 Demo的需求——「新增订单延迟预警功能超过 48 小时未发货时提醒客服介入」——五个Agent的输出如下PlannerAgent 输出{agentName:Planner,output:{taskBreakdown:[订单查询找出超过 48 小时未发货的订单,延迟判断计算订单创建时间到当前的小时差,客服提醒调用通知接口推送预警,重复提醒幂等同一订单不重复提醒,审计记录预警触发记录可追溯],preConditions:[确认订单状态字段定义待发货/已发货,确认客服通知渠道站内信/邮件/短信],affectedModules:[legacy-order 模块的 OrderService,通知模块的 NotificationService],clarifyItems:[延迟阈值是否所有租户固定为 48 小时,客服通知渠道是否已有统一服务]},note:requiresClarificationtrue}ArchitectAgent 输出{agentName:Architect,output:{accessMode:旁路AI 能力中心生成预警解释文案规则判断仍在老系统,moduleBoundaries:{legacy-order:负责订单查询、48 小时判断、预警记录写入Java 8,ai-capability-center:接收订单摘要生成预警解释文案和客服建议话术Spring AI,notification-service:接收预警事件调用客服通知渠道不改动},responsibilitySplit:老系统保持 Java 8 规则引擎AI 能力中心只做文本生成两系统通过 MQ/HTTP 解耦,riskNotes:[定时任务扫描频率需可配置,AI 能力中心不可用时的降级策略需明确]},note:bypassArchitecturetrue}CoderAgent 输出{agentName:Coder,output:{patchSuggestions:[{file:DelayAlertService.java,action:新增,description:定时任务扫描延迟订单调用 AI Gateway 获取解释文案},{file:OrderMapper.xml,action:新增 SQL,description:查询超过 N 小时未发货的订单列表}],classMethodHints:[DelayAlertService#findDelayedOrders(thresholdHours),DelayAlertService#pushAlert(order, aiSuggestion)],dtoSuggestions:[AiGatewayClient.DelayAlertRequest,AiGatewayClient.DelayAlertResponse],configurationHints:[delay.alert.threshold-hours48application.properties,delay.alert.cron0 0 * * * ?每小时执行一次]},note:patchSuggestionOnlytrue, doesNotModifyRepotrue}TesterAgent 输出{agentName:Tester,output:{testCases:[{name:正常场景订单超过 48 小时未发货触发预警,type:正常},{name:边界场景订单刚好 48 小时未发货触发预警,type:边界},{name:边界场景订单 47.9 小时未发货不触发预警,type:边界},{name:异常场景订单已发货不触发预警,type:异常},{name:幂等场景同一订单在扫描窗口内不被重复提醒,type:幂等},{name:失败场景通知渠道不可用预警记录标记待重试,type:异常}],testDataHints:[使用 H2 内存数据库预置订单数据不同创建时间、不同状态],edgeCaseChecklist:[多租户不同租户的阈值可能不同,时钟回拨服务器时间异常时的处理,AI Gateway 超时降级为默认文案]},note:requiresTestDataSetuptrue}ReviewerAgent 输出{agentName:Reviewer,output:{riskList:[{description:Coder 建议新增 DelayAlertService 在 legacy-order 模块但 Architect 建议旁路需确认职责边界,severity:高,sourceAgent:Coder,suggestedAction:人工确认是否允许在老系统新增 Service},{description:定时任务缺少幂等键可能重复推送预警,severity:中,sourceAgent:Coder,suggestedAction:参考历史评审结论定时任务必须有幂等键},{description:AI Gateway 调用未配置超时和重试,severity:中,sourceAgent:Coder,suggestedAction:补充 Resilience4j 配置}],reviewFocus:[幂等设计,多租户差异处理,通知失败重试机制,生产数据库变更新增表/字段需 DBA 审批],preDeploymentItems:[补充预警去重表delay_alert_log,配置 AI Gateway 超时时间,通知模板需运营确认],approved:false},note:requiresHumanConfirmationtrue}这五个角色之间的传递不是谁更聪明谁说了算而是让后一个角色基于前一个角色的结构化贡献继续补充。每一个Agent的AgentContribution.output都是强类型的结构化字段而不是一段自由文本这样ConflictDetector才能做关键词和字段级冲突检测Orchestrator 才能可靠地汇总报告。Orchestrator 怎么把输入交给 Agent当前 Demo的输入不是一句裸需求而是一个DevTaskRequesttenantIddemo operatorIdu1001 projectNamelegacy-order requirement新增订单延迟预警功能超过 48 小时未发货时提醒客服介入。 constraints[ 老系统保持 Java 8, 不能直接修改生产数据库, 需要输出测试用例 ]这几个字段决定了五个Agent的边界。projectNamelegacy-order告诉 Agent 当前目标是老订单系统不是新建一个独立服务。老系统保持 Java 8约束了架构和代码建议不能直接建议升级到新版本框架。不能直接修改生产数据库会进入冲突检测提醒所有 Patch 建议只能停留在代码审查阶段。需要输出测试用例则让TesterAgent的输出成为报告必要部分。DevTeamOrchestrator.run的流程是创建 agents 列表 Planner / Architect / Coder / Tester / Reviewer ↓ for agent in agents: contribution agent.contribute(request) contributions.add(contribution) ↓ ConflictDetector.detect(request, contributions) ↓ 组装 DevTeamReport当前 Stub 里每个Agent都拿同一个DevTaskRequest。真实项目里可以让后一个 Agent 额外读取前面 Agent 的输出但第一版先保证所有角色都围绕同一份需求和约束发言。最终AgentContribution只有三个字段{agentName:Coder,output:Patch 建议新增 DelayAlertService#findDelayedOrders(thresholdHours)新增 AI Gateway 调用 DTO不自动提交代码。,note:patchSuggestionOnlytrue}这说明当前 Demo 还不是完整的多Agent平台而是先把角色贡献可结构化、可汇总、可检测冲突跑通。每个 Agent 只做建议运行后能看到{patchSuggestionOnly:true,requiresHumanConfirmation:true}这两个字段是本讲最重要的边界。CoderAgent会输出 Patch 建议新增 DelayAlertService#findDelayedOrders(thresholdHours) 新增 AI Gateway 调用 DTO 不自动提交代码但它不会真的修改仓库也不会提交 PR。在企业流程里多Agent的第一阶段应该是生成建议 ↓ 人类确认 ↓ 再进入开发或变更流程Orchestrator 要列出冲突多Agent不是每个角色说完就结束。真正有价值的是 Orchestrator 能发现冲突。本讲 Demo 会列出Architect 建议旁路 AI 能力中心Coder 建议新增老系统 DelayAlertService 需要确认规则判断和 AI 文案生成的职责边界。这很接近真实研发讨论。架构师强调旁路开发建议改老系统服务。两者都可能合理但边界必须确认。如果系统不列出冲突只把所有建议拼成一篇报告那多Agent只是换了一种方式制造噪声。ConflictDetector 的实现逻辑当前 Stub 的检测方式是关键词冲突检测Architect 输出含 旁路 / 不侵入 Coder 输出含 老系统 / 新增 Service → 标记为架构方案冲突需人工确认后续可以升级为基于结构化输出的字段比对或者基于项目上下文知识库的语义冲突检测。但无论哪种实现方式关键是冲突必须显式列出而不是让人类 Reviewer 在一堆输出里自己找矛盾。不确定项要进入报告报告里还会列出客服通知渠道是否已有统一服务。 延迟阈值是否所有租户都固定为 48 小时。这类问题不能假装已经解决。企业研发里AI 很适合提前暴露这些不确定项。因为它们往往决定接口怎么设计 配置放哪里 测试用例怎么写 发布风险有多大企业避坑第一个坑不要让多Agent自动提交代码。至少第一阶段只输出建议和 Patch。第二个坑不要把多Agent输出简单拼接。必须有冲突检测和最终汇总。第三个坑不要隐藏不确定项。不确定项应该变成人工确认清单。第四个坑不要把 Agent 角色设计得太玄。最好贴近真实研发流程需求、架构、编码、测试、评审。从 Demo 到落地还差什么本讲 Demo 验证了多角色分析 冲突检测 不确定项显式列出的研发辅助编排。但企业真实落地还差几步Agent 输出格式标准化当前各 Agent 输出字段不一致落地时需要定义统一的AgentContribution结构——建议类型、影响范围、置信度、相关文件缺一不可。Agent Memory 持久化当前 Stub 没有记忆每次运行是独立的。真实项目里Agent 必须能查询项目的历史上下文、历史决策和历史评审结论否则每次都像在重新认识项目重复踩坑。我们把 Agent 的 Memory 划分为三类每一类服务于不同的研发决策场景。第一类是项目上下文 Memory。它存的是项目当前的静态结构模块列表、入口方法、调用链、表结构、已有接口、配置项。这类 Memory 最接近传统 RAG 知识库但区别在于它不是非结构化文档而是结构化元数据——ArchitectAgent查它来决定模块边界CoderAgent查它来避免改到禁止修改的老模块。项目上下文 Memory 的更新频率较低通常在项目结构发生实质性变化新增模块、表结构变更时触发更新。第二类是历史决策 Memory。它存的是为什么这么做为什么选择旁路而不是嵌入、哪些老系统模块被明确标记为不可改动、哪些技术方案曾经被提出但又被否决、当时的否决理由是什么。这类 Memory 的价值在于防止 Agent 反复建议已经被否决的方案。比如在这个系列的历史里团队已经决定老系统保持 Java 8AI 能力走旁路如果ArchitectAgent不读取历史决策 Memory就可能再次建议把 AI 逻辑直接写进 legacy-order 模块而这通常意味着冲突和返工。历史决策 Memory 的写入发生在每次架构评审或技术决策会议之后由人工或 Agent 辅助录入。第三类是历史评审结论 Memory。它存的是过去出过什么问题常见风险清单、幂等要求、回滚开关规范、测试缺口模板、上线事故复盘。这类 Memory 最接近传统经验教训库但它是面向 Agent 消费而设计的。TesterAgent查它来生成更完整的测试用例——比如历史上有过定时任务重复执行导致重复通知的事故那么这次订单延迟预警的测试用例就必须包含幂等场景。ReviewerAgent查它来沿用团队过去形成的风险规则——比如历史上要求所有对生产数据库的变更必须走 DBA 审批那么这次新增delay_alert_log表的建议就必须标记数据库变更风险。历史评审结论 Memory 的写入发生在每次 Code Review、测试复盘或上线事故分析之后。这三类 Memory 的查询流程复用了第 6 讲的 RAG 检索能力但不是简单的把需求扔给向量库而是有结构的多步检索。当一个DevTaskRequest进入 Orchestrator 时查询流程是首先用projectName加上requirement的关键词检索项目上下文 Memory返回相关模块列表和调用链然后用projectName加上module名称检索历史决策 Memory返回该模块的相关技术决策比如legacy-order 的 Service 层不允许新增 AI 调用必须走 MQ最后用风险关键词从requirement中提取比如定时任务、“通知”、“数据库变更”检索历史评审结论 Memory返回相关风险规则和测试经验。三步检索的证据作为结构化字段比如projectContext: MapString, String、historicalDecisions: ListString、historicalReviewConclusions: ListString注入到对应 Agent 的输入中。具体到这次订单延迟预警的需求Memory 应该返回什么项目上下文 Memory 会返回legacy-order里订单创建和发货状态相关的 Service 是OrderService对应的 Mapper 是OrderMapper通知相关的现有接口是NotificationService.send()但这个方法只支持站内信不支持短信和邮件。历史决策 Memory 会返回团队历史约定老系统保持 Java 8AI 能力走旁路并且历史上曾经有人建议在 OrderService 里直接调用 AI Gateway被架构师否决理由是老系统模块不允许直接依赖外部 HTTP 服务。历史评审结论 Memory 会返回历史上的定时任务必须有幂等键避免重复执行通知失败必须可重试并且重试次数可配置新增数据库表必须走 DBA 审批。这些证据会直接影响五个 Agent 的输出ArchitectAgent不会再次建议在 legacy-order 里直接调用 AI而是坚持旁路方案CoderAgent不会改到OrderService而是在旁路模块新增DelayAlertServiceTesterAgent会自动补上幂等和重试的测试用例ReviewerAgent会自动标记新增delay_alert_log表需要 DBA 审批。人工审批节点集成当前 Demo 的人工确认只是一个字段。落地时需要把 Orchestrator 的输出接入审批工作流参考第 9 讲让架构师、技术负责人能看到冲突列表并做决策。CI / PR 流水线触发当前是手动输入需求。真实场景应该是有人提 PR 或创建 Issue 时自动触发多Agent分析输出评论回写到 PR让 Reviewer 在合并前看到所有 Agent 视角。Patch 自动生成到 PRCoderAgent的输出从文本描述升级为可执行的 Patch 文件git diff 格式Orchestrator 将其附到 PR 评论区。人类确认后由人类决定是否应用。如果你在推进企业研发智能化这套多Agent编排是企业 AI 工程化的最后一块拼图。小结多Agent的企业落地不是模拟一个全自动研发团队。更稳的方式是多角色分析 ↓ 结构化贡献 ↓ 冲突检测 ↓ 不确定项清单 ↓ Patch 建议 ↓ 人工确认这也是整个系列的收束Java 8 老系统不升级 ↓ 旁路接入 AI 能力 ↓ AI Gateway统一入口 MCP Tool Center工具标准化 SQL Agent数据访问 代码阅读理解系统 Code Review保护质量 RAG 知识库业务问答 工单助手流程自动化 Browser Test测试自动化 AI Workflow任务编排 多 Agent 协作研发辅助整个系列在讲一件事企业 AI 落地不需要推翻老系统而是在老系统旁边架一条旁路把 AI 能力稳妥地接进来。
