我们为什么把「智能体内核」放进一个成熟的 Java 中台里，而不是再起一套 Python 服务。
一、企业要的不是「能聊天的机器人」
过去两年，几乎每个团队都搭过一个 Agent Demo：接一个大模型 API，挂几个函数，就能对话、能查数据、能写记录。Demo 到生产之间，隔着几道很硬的墙：
- 权限：谁可以用？能查哪个部门的数据？能不能删记录？——企业里没有「匿名全能 Bot」这种东西。
- 可控的写操作：让模型直接写库？没人敢。删除、发布、改配置这类副作用，必须有人点头。
- 审计：这次回答引用了哪些工具？谁确认的？花了多少 Token？出了问题能不能复盘？
- 可持续的底座：账号、组织、调度、文件、消息推送这些「无聊但必要」的能力，不该在 AI 项目里重造一遍。
- 技术栈融合：企业存量是 Java 中台。再引入一套 Python 运行时的运维成本，往往比想象中高。
BizBuddy 就是冲着这几点做的：一个企业级智能业务运行平台——它在成熟中后台底座之上，叠加一整套可运营的 AI 能力，而不是一个孤立的对话机器人。
二、技术选型：为什么坚持「纯 Java」
2.1 智能体内核：AgentScope Java 2.0.3
内核选的是 AgentScope 的 Java 版 Harness（2.0.3）。它是国内开源、专为「工程化 Agent」设计的框架，提供我们需要的全部工程能力：
- Harness Agent：内置工具循环（reasoning → tool call → observation）、最大迭代次数、流式事件；
- Middleware：可插拔的中间件（我们用它注入「当前时间」「候选专家清单」「槽位继承」）；
- 权限三态：
ALLOW / ASK / DENY，原生支持 HITL（Human-in-the-Loop）暂停与恢复； - 状态存储抽象：
AgentStateStore可对接 Redis，承载多轮记忆； - 上下文压缩、分层记忆、技能仓库、子 Agent、Plan Mode 等工程化能力。
最关键的是：它是 Java。同一进程、同一 JVM、同一套权限与事务，和 RuoYi-Vue-Plus 天然融合，不需要跨语言的 sidecar 和 RPC 边界。
2.2 业务底座：RuoYi-Vue-Plus 6.0.0
底座是 Dromara RuoYi-Vue-Plus 6.0.0，一个非常成熟的 Java 中后台脚手架，自带：
- RBAC 权限体系：用户 / 角色 / 菜单 / 部门 / 岗位 / 数据权限 / 字典；
- 工作流（Warm-Flow + LiteFlow）、定时调度（SnailJob）、代码生成器、OSS 文件存储、统一消息推送；
- 认证鉴权（Sa-Token）、ORM（MyBatis-Plus）、分布式缓存与锁（Redisson / Lock4j）、接口文档（SpringDoc）。
BizBuddy 的 AI 能力集中在一个模块：ruoyi-modules/ruoyi-ai（包 org.dromara.ai）。对底座是「叠加」而非「替换」——存量中后台能力全部可复用。
2.3 为什么不是 Python 方案
不是说 LangGraph / Dify 不好，而是当企业存量是 Java 中台时，纯 Java 路线有三个现实优势：
| 维度 | 纯 Java（本项目） | 引入 Python 运行时 |
|---|---|---|
| 权限打通 | 直接复用 Sa-Token、PermissionService、@DataPermission | 需要跨进程同步用户态与权限 |
| 事务与数据 | 与业务库同源，工具即 Service 调用 | 需要自建一致性边界 |
| 运维 | 一套 Maven 构建、一个 jar、一份监控 | 双语言构建 / 部署 / 排障 |
| 调试 | 一个 JVM 内断点、链路日志连续 | 跨语言链路断点 |
三、整体架构
flowchart LR
U["用户 / 飞书 / 企微 / 钉钉 / GitHub"] --> FE["Vue3 前端 plus-ui-Vue"]
FE -->|SSE 流式| API["ruoyi-admin / ruoyi-ai"]
API --> ROUTER["入口智能体 小Z<br/>意图判断 + 专家路由"]
ROUTER -->|route_decision| EXP["领域专家（独立装配）"]
EXP --> TOOLS["业务工具（代码侧 25 个实现）"]
EXP --> MCPC["MCP 客户端（接入外部工具）"]
EXP --> KB[("Milvus 知识库")]
API --> MODEL["大模型（OpenAI 兼容协议）"]
API <--> STATE[("Redis：会话状态 / 记忆")]
API --> PG[("PostgreSQL：业务表 + 审计表")]
运行形态可以概括成一句话：入口智能体统一接待，按需把任务委派给领域专家，专家的回答直接交付用户。
- 入口智能体「小Z」：所有对话先到它这里，它判断意图并给出「候选专家清单」，再通过协议工具
route_decision决定「自答」还是「委派」。 - 专家直答：被选中的专家回复直接交付用户，小Z 只负责「选谁」。这样上下文、记忆、场景包、权限槽位天然连续。
- 写操作人工确认（HITL）：涉及写库 / 写外部系统的工具调用会暂停并请求人工确认，确认后才继续执行。
- 多渠道接入：飞书 / 企业微信 / 钉钉 / GitHub Webhook 入站回调，渠道消息同样进入统一链路。
- 全链路审计：会话、路由、工具调用、确认、用量均有留痕（
ai_trace/ai_tool_call_log/ai_route_run等）。
四、「Harness 平台」到底 Harness 了什么
「Harness」一词在这个项目里不是噱头，它指的是把 Agent 从「一次性脚本」变成「可运营组件」的那层工程化外壳。BizBuddy 借助 AgentScope Harness 落地了这些东西：
- 工作区（Workspace）：每个智能体一个工作目录，承载人格与行为约定文件（
AGENTS.md）与附加上下文文件，每轮注入 system prompt。 - 分层记忆：
MEMORY.md（长期）+memory/YYYY-MM-DD.md（每日流水），按用户隔离，自动抽取与合并。 - 技能（Skill）：把「产出规格」做成可加载的 Markdown 技能，命中才加载，避免提示词爆炸。
- 上下文压缩：超长对话自动摘要 + 大工具结果卸载落盘，避免撑爆上下文窗口。
- 权限三态 + HITL：把「能不能调、要不要人确认」做进框架层，而不是靠提示词祈祷。
- 子 Agent / Plan Mode：可组合的能力，按智能体定义开启。
- MCP 双向：既能作为 MCP 服务端对外暴露只读工具，也能接入外部 MCP Server 的工具。
五、完全开源
BizBuddy 采用 MIT License，代码完全开源，托管在 Gitee：
- 代码仓库（后端
RuoYi-Vue-Plus+ 前端plus-ui-Vue）：gitee.com/zl3624/biz-…
后端底座源自 RuoYi-Vue-Plus（MIT），本项目在其上做平台化改造。你可以在自己的环境里跑起来：
# 后端：JDK 21 + Maven，PostgreSQL 14 / Redis / Milvus
cd RuoYi-Vue-Plus
./mvnw clean install -DskipTests
./mvnw -pl ruoyi-admin spring-boot:run # 默认 8080，初始账号 admin/admin123
# 前端：Node ≥ 20.19、pnpm ≥ 10
cd plus-ui-Vue
pnpm install && pnpm dev # 默认 80
数据库脚本在 RuoYi-Vue-Plus/script/sql/postgres/，按 框架基础表 → 工作流 → AI 平台 → 调度 顺序导入即可。
六、这篇文章没讲完的部分
三篇文章是一个系列，各有侧重：
- 本篇：项目是什么、为什么纯 Java、跑起来长什么样。
- 第二篇：企业级智能体的权限怎么落地——组织机构 + RBAC + 三档工具授权 + HITL。
- 第三篇：AgentScope Harness 与 RuoYi-Vue-Plus 的集成工程实践与踩坑。
如果你正准备把 Agent 从 Demo 推向企业生产，希望这个项目的取舍能给你一点参考。
技术栈速览
| 层 | 组件 |
|---|---|
| 语言 / 运行时 | Java 21 |
| 业务框架 | Spring Boot 4.1.1（Jetty） |
| 智能体内核 | AgentScope Harness 2.0.3 |
| MCP | 官方 MCP Java SDK 0.17.2（自建出口 + 客户端接入） |
| 数据 | PostgreSQL 14、Redis、Milvus 2.6.13 |
| 权限 | Sa-Token 1.46.0 + RBAC + 数据权限 |
| 调度 / 工作流 | SnailJob 2.0.2 / Warm-Flow 1.8.9 + LiteFlow |
| 前端 | Vue 3.5 + TypeScript 6 + Element Plus 2.14 + Vite 8 + Pinia |
作者：AI架构师张磊
