我司开发实践：从流程编排到智能决策的演进

背景与目标

我的文章可能对你没有吸引力，但是我推荐一个一定能吸引你的项目claule-code源码分析，从中可以学到agent常见的难题的解决方式

在公司近期的智能项目汇报中，我们面临一个核心挑战：如何让AI系统高效、准确地理解用户意图，并从多个微服务中获取数据，最终生成有价值的回答。我们基于现有业务系统，先后探索了两套技术方案------一套基于开源流程编排工具FastGPT，另一套基于Java构建的自研Agent（采用ReAct模式）。本文旨在复盘两版方案的实现细节、优劣对比，并分享我们在记忆管理、工具蒸馏、工程化等方面的思考，为后续迭代提供参考。

方案一：基于FastGPT的流程编排

实现逻辑

我们利用FastGPT（支持私有化部署）搭建了固定的处理流水线：

意图识别：通过精心设计的提示词（System Prompt）限制AI的输出范围，将用户问题分类到预定义的意图类别。
RAG匹配：根据意图，从向量数据库中检索相关数据表的结构信息（表名、字段、关系）。
SQL生成：将检索到的表结构和用户问题一并交给LLM，生成可执行的SQL语句。
SQL执行：在沙箱或只读数据库中执行SQL，获取结果集。
结果生成：将结果集再次送入LLM，生成自然语言回答。

优点

开发速度快，借助FastGPT的可视化编排，无需编写大量代码。
私有化部署，数据安全可控。
流程清晰，适合处理结构化查询类的固定场景。

缺点（需重点补充）

意图识别脆弱

依赖提示词工程来界定边界，当用户问题模糊或超出预设意图时，模型容易"乱猜"，导致后续步骤全部偏离。维护大量的边界案例提示词成本高昂。
RAG召回质量不稳定

表结构向量化后，检索结果受embedding模型和chunk策略影响，可能漏掉关键字段或引入无关表，直接影响SQL生成准确性。
SQL生成风险
- LLM生成的SQL可能存在语法错误、逻辑错误，甚至包含潜在的安全风险（如SQL注入），需要额外的校验和过滤层。
- 复杂查询（多表JOIN、子查询、聚合）往往难以一次生成正确，需要多轮修正，但固定流程不支持迭代。
链路冗长，延迟高

每个请求需经过四次LLM调用（意图→SQL→结果解释）加一次向量检索和一次DB执行，总耗时通常在5~10秒以上，无法满足实时交互需求。
难以处理多轮对话和上下文

每次请求独立处理，无法记忆之前的问题和回答，导致用户需要重复描述上下文，体验差。
扩展性受限

每新增一个业务场景，都需要修改流程、补充提示词、更新向量库，缺乏灵活的工具调用机制，难以应对动态变化的微服务生态。
调试与可观测性差

链路较长，错误分散在各环节，难以快速定位是意图误判、RAG失准还是SQL生成失败。

方案二：Java构建的ReAct Agent

核心设计

我们放弃固定流程，转而采用**ReAct（Reasoning + Acting）**模式，赋予AI自主决策能力。整体架构如下：

多微服务蒸馏为Skill

我们将各个微服务的能力（包括API接口、数据表、业务逻辑）进行"蒸馏"，转化为标准化的Skill。每个Skill是一个自包含的功能模块，包含：
- 场景路由表：意图→可执行脚本的映射。
- 标准调用链：针对复杂问题，定义了多步骤数据获取的顺序和依赖。
- 渐进式加载：Skill的描述和元数据常驻内存，具体SQL脚本和代码仅在需要时动态加载执行，减少资源占用。
ReAct循环

Agent接收用户问题后，进行"思考-行动-观察"循环：
1. 思考：LLM根据当前上下文和可用的Skill列表，决定调用哪个Skill。
2. 行动：执行Skill中的脚本（如SQL查询、API调用）。
3. 观察：获取执行结果，并将其反馈给LLM，用于下一步决策或最终回答。
蒸馏与验证流程

我们使用不同的提示词、工具和模型对同一微服务进行多次蒸馏，产生多个候选Skill。随后让AI（另一LLM）模拟用户场景，自动验证各Skill生成的SQL脚本的正确性，并输出验证报告。最终由人工审核并完善，确保每个Skill的边界清晰明确，避免模型在边界模糊时"乱猜"。

优点

灵活决策：ReAct模式让AI能够根据问题动态选择工具，甚至组合多个Skill解决复杂问题。
解耦与复用：每个Skill独立封装，新增业务只需蒸馏新Skill，无需改动核心Agent逻辑。
可控性增强：经过严格验证的Skill大幅降低了SQL生成错误率和安全风险。
性能优化：渐进式加载减少内存占用，且可通过缓存频繁使用的Skill脚本提升响应速度。

记忆管理（补充）

在多轮对话场景下，记忆管理是Agent的关键能力。我们设计了双层记忆机制：

短期记忆（会话级）

使用内存缓存存储当前会话的完整对话历史，包括用户提问、Agent思考链、中间观察结果。每次ReAct循环，都将相关历史片段拼接到LLM上下文窗口中，确保模型能理解最新状态。为防止上下文溢出，我们实现了滑动窗口 和关键信息摘要：当对话轮次超过阈值时，自动生成历史摘要，压缩非关键信息。
长期记忆（用户级）

将用户的历史查询偏好、常用Skill、已验证的SQL模板等持久化到向量数据库（如Milvus）或图数据库（如Neo4j）。当用户再次发起类似问题时，Agent先检索该用户的长期记忆，快速匹配可能相关的Skill或历史答案，提高响应速度。
遗忘机制

为长期记忆设置TTL（时间生存期），定期清理过时信息，避免知识陈旧。
记忆可解释性

所有记忆操作均记录日志，便于审计和调试。

其他补充（工程化与治理）

工具调用标准化

除了SQL执行，我们还封装了REST API调用、文件读取、外部知识库查询等工具，统一以Skill形式注册，使Agent具备更广泛的能力。
错误处理与重试
- 每个Skill执行失败时，Agent会尝试调用备选Skill或切换查询方式。
- 对SQL执行结果进行空值、异常检测，自动触发重写或回退。
安全防护
- 使用SQL解析器对生成的SQL进行语法校验和关键词黑名单过滤（如DROP、DELETE）。
- 数据库连接仅赋予只读权限，且执行超时限制。
可观测性与监控
- 接入Prometheus监控，记录每次ReAct循环的耗时、Skill调用次数、Token消耗。
- 使用分布式追踪（如Jaeger）串联整个请求链路，快速定位瓶颈。
评估与持续优化
- 构建离线评估数据集，定期运行回归测试，评估Agent在不同场景下的准确率和召回率。
- 根据线上日志，定期重新蒸馏性能不佳的Skill，形成闭环迭代。

两版方案对比

维度	FastGPT流程编排	Java ReAct Agent
开发效率	高（可视化）	中（需编码）
灵活性	低（固定流程）	高（动态决策）
多轮对话	不支持	支持（记忆管理）
扩展性	差（需改流程）	好（新增Skill）
准确性	依赖提示词，不稳定	Skill验证后，较稳定
性能	延迟高	中等（可优化）
维护成本	高（提示词工程）	中（Skill治理）

结论与下一步计划

基于当前项目需求，我们最终选择**方案二（Java ReAct Agent）**作为主力架构。尽管开发投入略高，但其灵活性、可扩展性和长期维护价值远超FastGPT方案。记忆管理的引入显著改善了多轮对话体验，而Skill蒸馏与验证流程则保障了回答质量。

后续我们计划：

进一步完善Skill自动蒸馏流水线，减少人工介入。
探索引入强化学习，让Agent根据用户反馈自我进化。
将Agent能力封装为标准化API，赋能更多业务线。

Agent开发不是一蹴而就的，它需要工程、算法、业务三方的紧密配合。希望我们的实践能为大家提供有价值的参考，也欢迎交流探讨。