BizBuddy 是一个全量开源的企业级智能体平台，基于 Spring Boot 4.1 + AgentScope Java Harness。1.0.0 不是一个"再加几个功能"的版本，它回答的是一个问题：企业真的敢把一个 Agent 平台放进生产吗？
一、1.0.0 是一条基线，不是一次升级
从 0.3 到 0.9.9，我们一直在补能力：检索、记忆、路由、渠道、MCP、安全合规。到 1.0 该收口了——把前后端、数据库脚本、部署编排、端到端测试、开发者文档全部收敛到一条可复现的线上。
所以 1.0.0 的定位很明确：
- 基线版本：建库脚本即当前结构全集，40 张 ai_* 表、34 个功能页、98 个按钮权限一次建好；
- 只支持全新初始化：不提供从 0.9.9 升级的迁移路径。与其让每个团队在旧库上手工补 DDL，不如明确划一条干净的起点；
- 两套数据库栈等价交付：PostgreSQL 14 与 MySQL 8.0，建库脚本双方言等价，端口错开可同时运行。
企业敢用，通常不是因为模型更聪明，而是因为四件事：出问题能定位、写操作能管住、外部系统能接、最坏情况能兜底。1.0.0 把这四件都落成了代码与测试。
二、企业级能力：一张可验证的清单
| 入口智能体 + 专家路由 | 所有对话先进「小Z」，由它判断自答或委派；专家回复直接交付用户，不被二次改写 | 路由与融合是 Agent 平台最容易失真的一环，专家直答消除信息损耗 |
| 写操作人工确认（HITL） | 写工具默认「需确认」，命中即暂停本轮、弹卡片，确认后在同一轮续跑 | 写库 / 写外部系统不再依赖"提示词里写一句请确认" |
| 无人值守写工具白名单 | 定时任务 / 渠道链路按 ai_tool.tool_type 代码级拒绝写工具，仅白名单显式放行 | 无人确认场景的安全不再靠配置纪律，漏配就是拒绝而不是静默执行 |
| 多渠道接入 | 飞书 / 企业微信 / 钉钉 / GitHub；Webhook 与长连接双形态，长连接免公网 IP | 企业内网环境也能接消息平台，不必为回调地址开洞 |
| 多模态对话 | 图片转 Base64 下发视觉模型、文档解析为纯文本内联，随任务片段一并交给专家 | 同一份材料入口与专家都看到，不需要"你再说一遍" |
| 知识库混合检索 | vector / hybrid 按库可配，向量 + BM25 双路召回、RRF 融合、可选重排、上下文装配 | 型号、错误码、条款这类精确词，向量未必排得进第一 |
| 长期记忆平台托管 | 平台接管抽取、注入、合并、归档与清理；水位抽取、净化前置、版本快照可回滚 | 记忆是"看起来能用、实际不敢用"的重灾区，可回滚才敢开 |
| MCP 双向集成 | 自建 /mcp 只读出口 + MCP 客户端接入外部；工具名归一化、回参逐块脱敏 | 既能被第三方 AI 调用，也能把外部能力接进平台 |
| 六类审计留痕 | 会话消息 / 工具调用 / 权限决策 / 链路追踪 / 编排运行 / 平台运行日报 | "AI 昨天干了什么"必须能答，排障与合规都需要 |
| 全链路安全合规 | 输入 / 输出 / 渠道出站 / 工具结果 / 知识库入库 / MCP 出口全过审 + PII 脱敏 + 注入防护 | 审核引擎可选本地词库或外部 API，缺配置自动降级 |
三、三个最"企业级"的设计取舍
1. 无人值守写工具：不靠配置纪律，靠代码强制
定时任务和渠道接入的共同点是没有人类可确认。早期做法是"在智能体上把写工具配成允许"，它有两个隐患：漏配是任务静默失败，误配是无人确认的写操作直接落库。
1.0.0 改成代码级兜底：写工具一律追加 DENY，只有列入「安全合规配置 → 无人值守白名单」（bizbuddy.ai.security.unattended-write-allowlist）的工具才执行。白名单变更走独立权限 ai:runtime:unattended:edit，且必须填写变更理由，下一次任务或渠道调用即时生效。
这个改动我们自己先踩了一遍：10 月底上线强制拒绝后，平台运行日报连续几天没有落库——只读汇总工具正常，写工具每次都是 Permission denied by rules。定位后把内置的 write_daily_digest 放进默认白名单（它按日期 upsert、本身幂等），1.0.0 才真正做到"开箱即用就写得出日报"。安全默认值不是越严越好，而是严到能解释、能验证。
2. 每一轮都能回溯：六类留痕之外，还有一个日报样板
审计不是"存了日志"，而是能按问题维度查到答案：这次为什么被拦下（权限决策日志）、这个工具为什么慢（工具调用明细）、这一轮为什么降级（编排运行与链路追踪）。
「平台运行日报」是 1.0.0 的样板场景：内置专家 platform_ops 每天 08:00 运行，五块数字由服务端只读工具现取，模型只给日期与正文，再由写工具按 digest_date upsert 落库；页面只读，并提示「近 7 天缺失日期」。
它把「定时任务 × 技能 × 工具边界」做成了一条可直接复制的骨架：产出契约（数值来自工具）、权限边界（写工具走白名单）、可见性兜底（缺失日期提示）。后续巡检类场景只需新增「1 个技能 + N 个只读工具 + 1 行任务配置」。
3. 双数据库栈与一键启动，把部署门槛压到最低
企业现场的数据库不是统一的。BizBuddy 两套 Compose 编排组件一致、仅方言不同：
| 前端 / 后端 | 80 / 8080 | 81 / 8081 |
| 数据库 / Redis / Milvus | 5432 / 6379 / 19530 | 3306 / 6380 / 19531 |
| 平台 MinIO | 9000（控制台 9001） | 9002（控制台 9003） |
两栈可同时运行、并排对照。方言差异只在两处，且代码内自动处理：JDBC 驱动与技能持久化仓库。部署只需三步：构建 jar 与前端、docker compose up -d –build、在「模型配置」补密钥。
四、"全量开源"具体开了什么
这不是一个"开源了壳、企业版留功能"的项目。MIT 协议下，以下全部在同一个仓库里：
- 前后端完整代码：Spring Boot 4.1 + JDK 21 后端，Vue 3 + TypeScript 前端；
- 双方言建库脚本：PostgreSQL 14 与 MySQL 8.0 等价，含 40 张 ai_* 表与种子数据；
- 两套容器编排：deploy/deploy-pg 与 deploy/deploy-mysql；
- 20 层 HTTP 端到端用例 + 18 条 Playwright UI 用例：不只是"提供测试框架"，而是可对着你本地已运行的栈直接复跑；
- 发版门禁清单：五道门禁的命令、判定口径、实测基线与已知抖动；
- 开发者文档与平台功能说明：架构、二次开发、配置参考、页面与接口说明。
没有隐藏的"企业版"分支，也没有需要付费解锁的写权限。你可以把代码拉下来，在自己的语料、自己的合规要求下验证它。
五、怎么证明它能跑，而不是"写完就算"
1.0.0 发版前，我们在两套栈都做了全新初始化（down -v）后的完整回归：
| 单元 / 集成测试（BIZBUDDY_IT=true，双栈真库） | biz-buddy 1557 通过 / 0 失败 / 0 错误（1 例预期跳过）；ruoyi-admin 10 / 0 / 0 |
| HTTP e2e（两栈各 20 层，含结构化决策桩） | PG 20 / 0 / 0、MySQL 20 / 0 / 0 |
| UI e2e（Playwright 18 条，两栈） | 18 / 18 × 2 |
| 全新环境种子 | 40 张 AI 表 / 34 功能页 / 98 按钮 / 4 模型 / 4 专家 / 1 入口 / 1 知识库 / 1 定时任务 |
| 健康自检 | 两栈 0 FAIL，版本号显示 1.0.0 |
| 重建冒烟与日志 | nginx 冒烟 200 / 200；后端 ERROR 0 / 0 |
过程中修掉的问题也如实记录在门禁清单里：建库脚本的幂等语句位置错误导致全新库建表中断、PostgreSQL 健康检查在初始化期间过早判定就绪、重新生成与会话互斥的时序竞争、长期记忆合并水位在 Windows 时钟精度下可能早于文件 mtime。每一个都是"单测全绿但真栈会挂"的典型——这也是为什么 e2e 与门禁清单和代码一起开源。
六、边界说在前面
- 1.0.0 只支持全新初始化：请用空数据卷启动；已有数据卷需先 docker compose down -v（会删除全部数据，请先备份）；
- 长期记忆以单副本为前提：文件工作区 + 进程内节流，多副本一致性是后续独立课题；
- 出厂示例值必须替换：JWT 密钥、接口加密密钥对、模型密钥加密根 crypto-key、MCP 出口口令、数据库 / Redis / Milvus 口令——启动自检会对所有 profile 生效，漏改会直接拒绝启动；
- 内容审核默认关闭：避免误杀，可先"只留痕"灰度；
- 混合检索尚未纳入检索质量 A/B 报告：功能与回归已完成，但没有同口径的提升数字，所以不写"提升了多少个百分点"。
七、从仓库到可登录，三步
# 1. 构建产物
cd code/back-end && ./mvnw clean package -DskipTests
cd ../front-end && pnpm install && pnpm build:prod
# 2. 启动任一栈（两栈端口错开，可并存）
cd ../../deploy/deploy-pg && docker compose up -d –build # 或 deploy-mysql
# 3. 登录 http://localhost ，在「模型配置」补齐对话与向量模型的 API Key
起来之后，想验证"真的跑通了"，直接用仓库自带的脚本：
node e2e/http/run.mjs # PostgreSQL 栈
node e2e/http/run.mjs –base-url http://localhost:8081 # MySQL 栈
仓库地址：https://gitee.com/zl3624/biz-buddy
八、开源之后，我们希望被挑战什么
1.0.0 不是终点。我们更希望它被真实场景挑战：
- 用你所在行业的语料，去试混合检索到底该不该开；
- 用你团队的合规要求，去试安全合规的六道审核是否够用；
- 用你自己的外部系统，去接 MCP 与渠道，看工具边界是否经得起误配；
- 用你们的运维习惯，去跑那 20 层 e2e，看它在你的环境里是否同样稳定。
企业级不是一句形容词，是一组可复现的验证。代码、脚本、测试与文档都已开源，欢迎直接来验。
