01 开篇：为什么做企业 Agent 平台
本篇是连载第一章。这个连载记录我把一个 Agent demo 变成「可交付的企业平台」的全过程：每个决策为什么这么选，放弃了什么，坑在哪，以及每一项能力的实测数字。
2026 年了，为什么还要自己搭
市面上的选择很多：LangChain 系的 SaaS 平台、低代码 Agent 搭建台、云厂商的百炼类产品。但当我站在「企业私有化交付」这个位置上看，它们几乎都有同一个问题：数据出不了内网。
企业客户要的东西其实很朴素：
- 员工能问制度、合同、技术文档，答案要有出处（RAG）；
- Agent 能自己查业务库、导报表，但不能乱写（只读 SQL 沙箱）；
- 谁在什么时候问了什么、调了什么工具，要有审计（合规硬需求）;
- 租户之间数据不能串（多租户隔离）；
- 每一轮对话花了多少钱，要能对账（真实 token 计量）。
这五条没有一条是「模型能力」问题，全是工程问题。而工程问题恰恰是 demo 与产品之间的那条沟。
底座选型：为什么是 AgentScope-Java
定了自建，接下来是选底座。我对比了三条路：
| 路线 | 问题 |
|---|---|
| Python 系（LangChain/LangGraph） | 我的交付场景是 Java 技术栈的企业服务，跨语言维护两套栈成本高 |
| Spring AI | 抽象偏「模型调用」，Agent 编排、事件流、工具循环这些内核能力要自己补 |
| 自研全套 | Agent 执行内核（ReAct 循环、事件流、状态管理）自研代价极高，没必要 |
最终选了 AgentScope-Java：阿里开源、JVM 原生、Apache 2.0，ReAct 编排、工具调用、事件流、MCP 这些内核它都有。我的判断标准很简单——内核不用自研，增值层自己写：RAG、评估、权限、审计、可观测，这些才是企业交付里真正的增值部分。
少侵入：最重要的一个决定
选了底座，最容易犯的错是「顺手改上游源码」。我给自己立了一条铁律：
尽量不侵入 agentscope-java，优先用 SPI、事件监听、自定义 Tool 扩展；确需修改的文件必须在文件头标注，保留原版权声明。
这么做的回报在后面显形：底座升级时直接拉上游新版本合并，维护成本极低。反例我也踩过——AgentScope 自带的 event-log 持久化 SPI 太复杂、侵入太深，我评估后果断放弃，改在应用层自己管会话记忆。这个取舍后面第 07 章专门讲。
平台全貌与连载路线
整个平台的能力面：多租户 RAG 知识库、ReAct 智能体编排、MCP 工具接入、量化评估平台、RBAC + 审计、可观测监控、私有化部署。我把连载拆成 12 章（见 docs/连载大纲.md），从 RAG 链路一路讲到「离商用还差什么」。
先给一个诚实的锚点：目前 16 项核心能力全部实机验证通过——对话、多轮记忆、Milvus 真实向量检索、评估 5/5 通过、judge 抓幻觉、403/401 权限矩阵、租户隔离不泄露、token 真实计费、SSE 流式、坏例回归闭环。每一项的复现动作和指标都落在 docs/11_量化能力清单.md 里，连载里反复引用的都是这些实跑出来的数，不是理论值。
下一篇讲总体架构：我怎么用 Profile 让一套代码在「笔记本 demo」和「Milvus + Redis + PostgreSQL」两副面孔之间自由切换。
- 代码仓库：
src/biz-platform（自研业务层） - 配套设计文档：
docs/01_项目概述.md、docs/02_系统架构.md