Java后端转AI Agent：技术栈全景图与从ReAct到多Agent协作实战

Java后端转AI Agent：技术栈全景图与从ReAct到多Agent协作实战

Agent入门系列① | 面向Java后端开发者的AI转型实战指南

本系列是6年Java老兵转型AI Agent的完整踩坑记录。上篇聚焦技术栈全景与架构演进，下篇深入代码审查Agent实战与工具链优化。所有方案均已在dream-saas.com项目落地验证。

---

一、79%的企业在试，但只有11%上了生产

Gartner最近发了组数据：79%的企业已经在尝试AI Agent，但真正跑在生产环境的，只有11%。

1/9的转化率，gap在哪？

以dream-saas.com的代码审查Agent为例：Spring AI Alibaba Graph编排审查流程，DeepSeek做推理，Vue3前端，CI/CD自动部署，代码审查、质量评分、SSE流式输出、Docker一键部署------功能齐备，但距离生产级仍有三个底层问题没解决：

问题	具体表现	实测数据
质量不稳	换个模型效果天差地别	qwen-plus审查通过率60%，deepseek-v3.1直接93%
成本没算清	一次审查任务调3-5次模型	单次审查成本是对话的8-10倍
没有运维体系	npm残缺、SSH被爆、Nginx漏配	能跑≠能用

79%到11%的gap不是技术问题，是把这三个底层问题解决掉的能力。

Deloitte数据显示74%的企业计划2年内部署Agent，Gartner预测今年底40%的企业应用会嵌入Agent。需求真实存在，但解决方案供给不足。

---

二、AI Agent技术栈全景：5层架构拆解

AI Agent应用不只是调API接LLM。从Prompt到记忆、从工具调用到模型编排、从监控到安全，是一个完整的闭环体系。按5层拆解：

graph TB subgraph "AI Agent 5层技术栈" A[核心能力层] --> B[智能层] B --> C[基础设施层] C --> D[业务层] A -.-> E[跨层能力] B -.-> E C -.-> E D -.-> E end A --> A1[Function Calling] A --> A2[MCP协议] A --> A3[HITL] A --> A4[Advisor体系] B --> B1[Prompt Engineering] B --> B2[RAG知识库] B --> B3[多模型编排] C --> C1[可观测性OTel] C --> C2[测试评估] D --> D1[多平台适配] D --> D2[数据驱动增长] E --> E1[Agent记忆系统] E --> E2[成本优化] E --> E3[AI安全对齐]

第一层：核心能力层------Agent的"五官四肢"

这是AI Agent应用的地基，决定了Agent能做什么。

1. 工具调用与Function Calling

让AI能够调用外部系统。比如用户问"今天天气怎么样"，Agent需要识别意图→调用API→返回结果。

Spring AI的Tool Calling实现：

@Tool(description = "获取指定城市的天气信息")
public WeatherResult getWeather(
        @ToolParam(description = "城市名称") String city,
        @ToolParam(description = "国家代码", required = false) String countryCode) {
    String finalCountry = Optional.ofNullable(countryCode).orElse("CN");
    WeatherResponse response = callWeatherApi(city.trim(), finalCountry);
    return WeatherResult.builder()
            .city(response.getCity())
            .temperature(response.getTemp())
            .humidity(response.getHumidity())
            .condition(response.getCondition())
            .timestamp(LocalDateTime.now())
            .build();
}

MCP协议（Model Context Protocol）

Anthropic提出的标准协议，让不同AI应用用同一套方式调用工具。写一个查询库存的工具，MCP让任何支持MCP的AI应用都能直接调用，不用每个应用都写一遍对接代码。

2. HITL与条件分支

HITL = Human-in-the-Loop，关键决策必须人确认。典型场景：转账金额超10万需主管审批、删除重要数据需二次确认、AI置信度低于阈值时交给人工处理。

public class HITLDecisionEngine {
    
    public ExecutionResult decide(AgentContext context, AIGateway gateway) {
        double aiConfidence = context.getAiConfidence();
        BigDecimal amount = context.getTransactionAmount();
        RiskLevel riskLevel = evaluateRisk(context);
        
        // 置信度低于阈值 → 人工审核
        if (aiConfidence < 0.7 || riskLevel == RiskLevel.HIGH) {
            log.info("触发人工审核: confidence={}, risk={}", aiConfidence, riskLevel);
            return ExecutionResult.requiresHumanApproval(context.getTaskId());
        }
        
        // 金额超标 → 主管审批
        if (amount.compareTo(new BigDecimal("100000")) > 0) {
            return ExecutionResult.requiresManagerApproval(context.getTaskId());
        }
        
        return ExecutionResult.autoExecute(context);
    }
}

3. Advisor体系

Spring AI的拦截器链设计，实现请求增强、响应处理、统一日志监控。

@Component
public class TracingAdvisor implements OrderedAdvisor {
    
    private static final int ORDER = 100;
    
    @Override
    public AdvisedRequest before(AdvisedRequest request) {
        Map<String, Object> augmentedParams = new HashMap<>(request.getParameters());
        String traceId = UUID.randomUUID().toString();
        augmentedParams.put("traceId", traceId);
        long startTime = System.currentTimeMillis();
        TracerContext.set(traceId, startTime);
        return RequestBuilder.copy(request).parameters(augmentedParams).build();
    }
    
    @Override
    public AIResponse after(AdvisedRequest request, AIResponse response) {
        TracerContext context = TracerContext.get();
        long duration = System.currentTimeMillis() - context.getStartTime();
        metricsService.record("ai.call.duration", duration, 
                Tags.of("model", request.getModel()));
        TracerContext.clear();
        return response;
    }
}

---

第二层：智能层------让Agent更"聪明"

这层解决的核心问题：怎么让AI的回答质量更高、更有用。

1. Prompt Engineering体系

好的Prompt需要考虑：角色定义、任务描述、约束条件、输出格式、示例参考。

public class PromptTemplateEngine {
    
    public String build(UserQuery query, PromptStrategy strategy) {
        return switch (strategy) {
            case TECHNICAL -> buildTechnicalPrompt(query);
            case CASUAL -> buildCasualPrompt(query);
            case CODE_REVIEW -> buildCodeReviewPrompt(query);
        };
    }
    
    private String buildCodeReviewPrompt(UserQuery query) {
        return """
            # Role: Senior Java Architect
            
            ## Task
            审查以下Java代码，提供详细的代码审查意见。
            
            ## Code
            {code}
            
            ## Review Criteria
            - 代码安全性
            - 性能优化建议
            - 设计模式应用
            - 可维护性评估
            
            ## Output Format
            严格按以下JSON格式输出：
            {{
                "issues": [
                    {{
                        "severity": "BLOCKER|CRITICAL|MAJOR|MINOR",
                        "line": <行号>,
                        "description": "<问题描述>",
                        "suggestion": "<修改建议>"
                    }}
                ],
                "summary": {{
                    "totalIssues": <总问题数>,
                    "score": <1-10评分>
                }}
            }}
            """.replace("{code}", query.getCode());
    }
}

2. 知识资产体系（RAG）

RAG = Retrieval Augmented Generation，检索增强生成。核心思想：不让模型凭空编造，把知识库接进来。

graph LR A[用户Query] --> B[向量检索] B --> C[知识库匹配] C --> D[Top-K文档] D --> E[Context组装] E --> F[LLM生成] F --> G[最终回答] H[知识库] -.-> C I[Embedding模型] -.-> B

在dream-saas.com项目中，质检标准文档全部向量化到Milvus向量数据库，Agent实时检索，审查结论有据可查。

3. 多模型编排与路由

不同模型能力不同、成本不同、速度不同。根据任务类型自动选择最合适的模型。

@Component
public class ModelRouter {
    
    private final Map<TaskType, ModelStrategy> strategies = new HashMap<>();
    
    public ModelResponse route(TaskContext context) {
        TaskType taskType = classifyTask(context);
        ModelStrategy strategy = strategies.get(taskType);
        if (strategy == null) {
            throw new IllegalStateException("No strategy for task: " + taskType);
        }
        return strategy.execute(context);
    }
    
    private TaskType classifyTask(TaskContext context) {
        String content = context.getContent();
        if (containsCodePatterns(content)) {
            return TaskType.CODE_GENERATION;
        }
        if (isChineseContent(content)) {
            return TaskType.CHINESE_NLP;
        }
        return TaskType.GENERAL;
    }
}

/**
 * 代码任务专用策略 - 路由到Claude
 */
@Component
public class CodeGenerationStrategy implements ModelStrategy {
    
    private static final String PREFERRED_MODEL = "claude-3-sonnet";
    
    @Override
    public TaskType supports() {
        return TaskType.CODE_GENERATION;
    }
    
    @Override
    public ModelResponse execute(TaskContext context) {
        return ModelRequest.builder()
                .model(PREFERRED_MODEL)
                .prompt(enhanceCodePrompt(context.getContent()))
                .temperature(0.2)  // 代码生成需要低温度
                .maxTokens(4096)
                .build()
                .execute();
    }
}

/**
 * 中文NLP任务策略 - 路由到国内高性价比模型
 */
@Component
public class ChineseNLPStrategy implements ModelStrategy {
    
    @Override
    public TaskType supports() {
        return TaskType.CHINESE_NLP;
    }
    
    @Override
    public ModelResponse execute(TaskContext context) {
        return ModelRequest.builder()
                .model("qwen-turbo")
                .prompt(context.getContent())
                .temperature(0.7)
                .build()
                .executeViaFallback(List.of("ernie-4.0", "wenxin-pro"));
    }
}

graph TD A[任务输入] --> B{任务分类} B -->|代码任务| C[Claude 3.5 Sonnet] B -->|中文理解| D[通义千问 / 文心] B -->|长文本| E[GPT-4-Turbo] B -->|简单问答| F[GPT-3.5-Turbo] C --> G[执行调用] D --> G E --> G F --> G G --> H[结果返回]

---

第三层：基础设施层------让Agent能"跑起来"

这层和传统后端开发最像，Java工程师的强项。

1. 可观测性建设（OTel）

Agent运行状态需要Tracing（链路追踪）、Metrics（指标）、Logging（日志）三件套。推荐OpenTelemetry（OTel），Spring Boot可无缝集成。

2. 测试与评估

AI应用的测试比传统单元测试复杂：功能测试、回归测试（Prompt改了性能不下降）、对抗测试（故意问刁钻问题）、评估框架（用AI来评估AI的回答质量）。

---

第四层：业务层------让Agent"赚钱"

1. 多平台适配

一套Agent核心逻辑，多个前端适配。对Java来说就是后端服务+多端API的架构。

2. 数据驱动增长

ToC的AI应用需要关注：用户留存、转化漏斗（注册→激活→付费每步流失多少）、A/B测试（Prompt改版效果对比）。

---

第五层：跨层能力------贯穿所有环节

1. Agent记忆系统

记忆≠知识。知识是静态的，记忆是Agent运行时的上下文。两种记忆：短期记忆（当前会话靠Chat History）、长期记忆（跨会话靠向量存储）。

sequenceDiagram participant User as 用户 participant Agent as Agent Core participant ShortMem as 短期记忆<br/>(Chat History) participant LongMem as 长期记忆<br/>(Vector DB) participant LLM as LLM User->>Agent: &#34;继续&#34; Agent->>ShortMem: 获取最近对话 ShortMem-->>Agent: 历史上下文 Agent->>LongMem: 检索用户偏好 LongMem-->>Agent: 偏好数据 Agent->>LLM: 组装完整上下文 LLM-->>Agent: 生成回复 Agent->>User: 继续之前的话题

2. 成本优化

核心思路：模型选型（能用小模型就不用大模型）、Prompt压缩（减少无效Token）、缓存（相同问题直接返回）、按需调用（非必要不调API）。

3. AI安全与对齐

主要风险：Prompt注入（用户输入恶意指令）、敏感信息泄露（AI把不该说的说出去了）、内容安全（生成违规内容）。

---

三、Agent进化路线：V1.0到V2.5的实战演进

从ReAct说起

直接调LLM API做代码审查，效果很差------模型倾向输出笼统的"代码结构清晰"这类废话，给不出具体问题。核心原因是缺少"工具调用"环节：模型只能凭空推理，无法主动获取代码的静态分析数据、复杂度指标等客观信息。

ReAct模式解决了这个问题。核心就三个动作循环：Thought→Action→Observation。

用户输入 → Thought: 分析现状 → Action: 调用工具 → Observation: 获取结果 → 循环...

在Spring AI Alibaba里的实现：

// 初始化ReAct Agent
this.reactAgent = ReactAgent.builder()
    .name("CodeReviewAssistant")
    .model(chatModel)
    .methodTools(toolExecutor)  // 自动识别@Tool注解
    .build();

工具定义加个注解即可：

@Tool(name = "analyzeComplexity", description = "分析代码复杂度")
public ComplexityInfo analyzeComplexity(@ToolParam String code) {
    return toolService.analyzeComplexity(code);
}

Agent根据场景自动选择工具调用，配合ChatMemory做会话记忆，工具调用+记忆构成ReAct基本盘。

---

ReAct的三个局限

ReAct基本盘能跑，但三个结构性问题限制了它的上限。

问题一：没有反思，审查结果容易飘。

ReAct是单轮决策：Thought→Action→Observation→输出结果。模型在第一轮就"自信"给出结论，但实际审查中经常出现NPE隐患漏检、事务边界识别错误、关键维度缺失等问题。模型输出的"完整性"是表象，缺少自我校验机制才是根因。

问题二：没有计划，复杂任务执行效率低。

ReAct边想边做，每一步决策都依赖上一步的Observation。对于代码审查这种多维度任务，如果能先规划检查清单再逐项执行，效率和完整度都比逐步摸索好。ReAct没有"先想清楚再做"的能力。

问题三：单Agent承载过多职责，专业度不够。

代码审查、安全检测、日志规范，这些需要不同的专业Prompt和工具集。一个Agent什么都干，每个维度都做不深。

---

进化路线：V1.0到V2.5

版本	模式	核心改进	适用场景
V1.0	ReAct	工具调用+记忆	简单问答、单一任务
V1.2	Reflexion	自我反思循环	需要质量把控的审查类任务
V1.5	Plan-and-Execute	先计划再执行	复杂多步骤任务
V2.5	多Agent协作	专业Agent分工+RocketMQ通信	复杂系统、多维度审查

V1.2 Reflexion：在ReAct循环里加自我评估

执行→反思→调整→再执行。Reflexion的本质是让模型批判自己的上一轮输出：

public CodeReviewResult reviewWithReflection(String code, String fileName,
                                              ReviewContext context) {
    CodeReviewResult previousResult = null;
    
    for (int iteration = 1; iteration <= maxIterations; iteration++) {
        // 反思Prompt：让模型批判上一轮输出
        if (previousResult != null) {
            context.setUserPromptSupplement(buildReflectionPrompt(previousResult));
        }
        
        currentResult = reviewAgent.review(code, fileName, context);
        
        // 自我评估：检查完整性、正确性、可操作性
        ReflectionResult reflection = reflectOnResult(currentResult);
        
        // 收敛则退出
        if (shouldTerminate(currentResult, previousResult, reflection)) {
            break;
        }
        previousResult = currentResult;
    }
    return currentResult;
}

加了反思之后，模型会主动补充上一轮遗漏的问题，定位更精确。dream-saas.com实测，审查通过率从60%提升到93%。

V1.5 Plan-and-Execute：先规划再执行

把任务分成Plan和Execute两个阶段：

// Plan阶段：生成任务列表
List<Task> plan = generatePlan(code, fileName, context);

// Execute阶段：按计划执行
for (Task task : plan) {
    TaskResult result = executeTask(task, code, context);
    results.add(result);
    context.setExecutionContext(accumulateContext(results));
}

Plan阶段的执行计划对人类可见，如果规划方向有偏差，可以在执行前介入纠正。

V2.5 多Agent协作：专业分工+事件驱动

用Router Agent做任务分发和调度，专业Agent各司其职：

• CodeReview Agent：代码质量审查
• Security Agent：安全漏洞检测
• Log Agent：日志规范检查

Agent之间通过RocketMQ事件总线通信：

// 协作请求通过RocketMQ发送
AgentEvent event = AgentEvent.builder()
    .eventType(AgentEventType.COLLABORATION_REQUEST)
    .sourceAgent("CodeReviewAgent")
    .targetAgent("SecurityAgent")
    .payload(Map.of("code", codeContent, "requestType", "SECURITY_CHECK"))
    .build();

rocketMQTemplate.asyncSend("agent.collab.request", event);

Router Agent根据任务类型路由到对应的Agent，复杂任务触发多Agent协作，审查报告由Router统一聚合输出。

---

四、Javaer做Agent的独特优势

微服务架构经验直接复用。

多Agent协作本质是分布式系统的思路------任务分发给不同Agent，Agent之间通过事件总线通信，最终聚合结果。Spring Cloud微服务里做服务拆分、消息通信、服务治理的经验，在这里直接适用。

Spring生态的工程化能力。

Spring AI Alibaba Graph已经封装了ReAct循环，开发者只需要关注：

• 怎么设计工具
• 怎么构建Prompt
• 怎么组装业务流程

依赖注入、AOP、配置管理这些工程化能力照常用，代码结构清晰、可维护、可测试。

从Spring MVC转Spring AI，比从零学Python调LangChain门槛低很多。

---

五、一个人做AI Agent项目，优先搞什么？

第一优先级（必须搞定）

1. Prompt Engineering------花20%时间优化Prompt，效果可能提升50%
2. 工具调用------不会调工具，Agent就是个问答机器人
3. 可观测性------不知道效果怎么样，就没法迭代

第二优先级（核心能力）

1. 记忆系统------让Agent能"记住"上下文
2. 知识库（RAG）------让Agent有"专业知识"
3. 基础监控------先能跑起来，再说优化

第三优先级（锦上添花）

1. 多模型路由------省钱提效
2. 多平台适配------扩大分发
3. 自动化测试------保证质量

---

写在最后

AI Agent的核心技术栈，Java后端都有对应的概念迁移：

• Advisor ≈ Filter/Interceptor
• MCP ≈ RPC框架
• RAG ≈ 搜索引擎 + LLM
• 可观测性 ≈ 监控 + 链路追踪

真正难的，是把这些能力组合起来，解决真实的业务问题。

---

在线体验：dream-saas.com

预告：下篇《Agent入门系列② | AI代码审查Agent实战：从工具调用优化到Cursor Skills》将深入讲解CodeGraph代码大脑、mattpocock/skills实测，以及如何将审查通过率从60%提升到93%的完整踩坑记录。

---

作者 ：宋哥转AI

定位 ：6年Java后端，独立负责SaaS平台，正在转AI Agent方向

技术栈：Spring AI Alibaba + pgvector + DeepSeek

---