AgentScope Java 实战 01：dream-scope 开篇，从最小内核认识 AgentScope

本篇是《AgentScope Java 实战》系列的第一篇同时推进两条线。框架学习线从 AgentScope 的全景地图切入落到最小内核的四个概念与几行可运行代码。项目线介绍同期开源的模块化 Agent 运行时 dream-scope展示同一个框架在工程化主路径上的形态。两条线在第四节汇合最小 Agent 能跑之后距离一个可部署的产品级运行时还差什么。建议的阅读路径分三步先跑通第三节的最小样例建立最小内核的体感再带着第四节列出的三个缺口理解工程化实现最后按第五节在本地拉起完整服务。前置知识Java 21 与 Spring Boot 基础、Maven 基本用法、HTTP 接口概念不要求接触过 Agent 框架。阅读目标建立 AgentScope 的四概念全景看懂 dream-scope 的工程化边界并按第五节在本地 10 分钟跑通。关于代码文中 Java 片段均为从仓库摘出的关键片段省略 import 与类声明完整可运行代码见各处标注的仓库路径本篇不面向零基础读者。文中版本号、端口与配置均以仓库 0.1.0-SNAPSHOT 源码为准。一、dream-scope 是什么基于 AgentScope Java 的模块化 Agent 运行时dream-scope 是一个基于 AgentScope Java 2.0 的模块化单体 Agent 运行时仓库地址 GitHub - logosssss/dream-scope: 基于 AgentScope Java 2.0 的模块化单体 Agent 运行时 · GitHub 。基础信息一行说清当前版本0.1.0-SNAPSHOT框架基线锁定 AgentScope 2.0.3运行环境Java 21 Spring Boot 3.5.5。“模块化单体”的含义体现在一条明确的边界上业务契约放在 dream-scope-domain 模块该模块禁止依赖 io.agentscope.* 下的任何类型AgentScope 的具体装配全部关在 dream-scope-adapter 模块。框架类型在工程里有且仅有一个集中入口升级框架或替换实现时影响面被限制在 adapter 之内。选择单体而非微服务形态是因为 Agent 的调用链天然处于单进程内——模型调用、工具执行、状态读写共享同一份上下文拆成分布式进程只会引入额外的网络与会话一致性成本模块边界则保证进程内部不会退化成无结构的大泥球。当前主路径有两个出口同步POST /api/agents/invoke即 HarnessAgent.call 语义内部走 streamEvents 累积到 Done 事件后一次返回流式POST /api/agents/stream以 SSEServer-Sent Events服务器向浏览器单向推送的流式协议边推理边推送。chat Agent 带 workspace 与 Middleware中间件框架在推理链路上预留的横切挂点挂点。内置两个 agentIdchat 是默认入口knowledge 只做检索、不调模型a2aAgent-to-AgentAgent 之间互相发现与协作的开放协议在配置远端能力后注册task 为预留标识调用返回 404。chat 注册了四个无 Spring 依赖的演示工具getCurrentTime取当前时间calculate四则运算httpGet抓取 http/https 页面并截断响应体retrieve进程内关键词检索返回带 [1] 编号的资料。模型在需要时通过 ReAct 循环自行调用是否调工具由模型根据问题判断普通问候不会触发工具链。安全侧默认从紧Harness 的工作区工具 read_file / write_file 与 shell 已关闭HTTP 进程不在本机执行文件操作和命令。Plan Mode计划模式模型先产出执行计划再按计划行动默认开启模型可自行 plan_enter / plan_write / plan_exit计划文件写在工作区 plans/ 目录下不提供 HTTP 手动进入也不做人审确认。普通问答不进入计划时行为与普通对话一致。观测能力随工程默认交付ActuatorSpring Boot 的生产观测组件暴露运行时健康与指标端点开放 health / info / metrics / prometheus 端点chat 挂有官方手册中的 OtelTracingMiddlewareinvoke_agent、chat、execute_tool 三个 span 已埋点未配置 OTEL_EXPORTER_OTLP_ENDPOINT 时为空操作配置后才向 OTLPOpenTelemetry 官方链路数据导出协议导出。仓库还自带无 Spring 注解的 LoggingMiddleware在控制台打印 onAgent / onModelCall / onActing 的开始与完成日志包含 agentId、sessionId 与耗时。dream-scope 与姊妹仓 dream-aihttps://github.com/logosssss/dream-ai定位互补。dream-ai 是手写的 Agent 运行时从状态图、消息抽象到工具调度全部自行实现基于 Spring AI 与状态图编排适合读源码理解运行时原理dream-scope 站在 AgentScope 框架之上关注模块边界、状态会话与流式协议等工程化命题。一个回答“运行时内部为什么这样转”一个回答“框架落地时怎样不被框架绑架”两仓可对照阅读读完手写实现再看框架代码能分清哪些能力是框架白送的、哪些是任何运行时都绕不开的基本件。运行依赖与版本策略三条讲清Redis 必选进程启动时执行 ping 校验连不上直接启动失败不带着失效连接进入服务默认连接 redis://127.0.0.1:6379key 前缀 dream-scope:。Nacos 可选且默认全关三套开关互不绑死——AgentScope AIprompt、A2A、skill走 gRPC 9848要求 Nacos 3.x、Spring Cloud 配置中心、服务发现各自独立启用。本地不用 Nacos 时无需任何额外配置。版本统一收口仓库根 POM 与 dream-scope-bom 统一管理 Spring Boot BOM、Spring Cloud Alibaba 2025.0.0.0 与 agentscope-dependencies-bomAgentScope 坐标不逐个手写版本号避免多模块间出现框架小版本漂移。项目仍在快速迭代HITLHuman-in-the-Loop人工审批介入决策循环、knowledge 调模型、入库向量检索在 Roadmap 上计费与管理后台明确不做。代码以 Apache License 2.0 发布欢迎 star也欢迎在 issue 里反馈接入问题。二、AgentScope 全景core / harness / extensions / startersAgentScope官网 https://java.agentscope.io/是面向 Java 的 Agent 应用框架2.0 代际把“最小内核”与“工程层”做了清晰拆分。dream-scope 统一通过官方 BOMBill of Materials一份材料清单统一收口全部依赖版本agentscope-dependencies-bom 管理版本本文与仓库代码均以 2.0.3 为准。框架可以按四层建立认知。core最小内核agentscope-core 提供构成 Agent 的全部基础抽象Agent 与 ReActAgent、消息类型 Msg / UserMessage 与 ContentBlock 体系、模型抽象 Model 与 ModelRegistry、工具容器 Toolkit、运行时上下文 RuntimeContext、类型化事件流、AgentStateStore 状态接口、MiddlewareBase 横切抽象。第三节的四个概念全部落在这一层。core 不绑定 Spring也不绑定任何模型供应商。harness工程层agentscope-harness 在 core 之上提供 HarnessAgent以及产品化所需的一组约定workspace 工作区目录、DistributedStore分布式状态存储接口dream-scope 用 Redis 实现、MemoryConfig记忆配置约定会话记忆的挂载方式与 CompactionConfig记忆压缩配置、SubagentDeclaration 子 Agent 声明、Plan Mode。harness 的思路是把产品里反复出现的配置项变成目录约定与 builder 挂点而不是让每个接入工程各自发明一套状态与会话结构。dream-scope 的 chat 主路径主角就是 HarnessAgent第四节给出它的 builder 形态。extensions供应商与基础设施扩展扩展层按能力独立发包。模型侧有 agentscope-extensions-model-dashscope 以及 openai / anthropic / gemini / ollama 等厂商包厂商包各自携带协议适配不进 core引入新供应商因此不需要改动内核基础设施侧有 agentscope-extensions-redis提供 RedisDistributedStoreRedis 客户端 Jedis 的版本随 AgentScope BOM 管理。dream-scope 当前使用 core、harness、extensions-redis 与 dashscope 厂商包默认模型为 dashscope:qwen-plus密钥读环境变量 DASHSCOPE_API_KEY。spring-boot-starters自动装配入口官方为 Spring Boot 提供一组 starter核心 agentscope-spring-boot-starter 负责装配 ReActAgent各厂商 starter 按 agentscope.model.provider 只启用一个 Model另有 chat-completions-web-starter 暴露 POST /v1/chat/completions、agui-spring-boot-starter 提供 /agui 页面、admin-spring-boot-starter 提供 /v1/admin写操作默认关闭、a2a-spring-boot-starter 与 nacos-spring-boot-starter 负责协议互通其中 nacos starter 必须显式置为 true环境里没有 Nacos 时进程无法启动见仓库 README 的 starter 对照表。四层的关系可以用一句话概括core 定义最小内核并保持零绑定harness 在内核上补齐工程约定extensions 以独立坐标注入供应商与基础设施starters 把前三层的装配写进 Spring Boot 自动配置。依赖方向严格单向starters 不向下渗透因此完全可以只用 core 手写全部装配dream-scope-web 的 PortsConfigweb 模块里手写的 Bean 装配配置类走的就是这条路径。dream-scope 对两种 Spring 集成方式都保留了入口对照着看主路径 web 模块手写 PortsConfig 装配 HarnessAgent默认产品入口端口 8091配置前缀 dream-scope.*对照路径 boot 模块使用官方 starterstarter 默认给出 ReActAgent内存 Memory、空 Toolkit端口 8092配置前缀 agentscope.*。web 不依赖 boot两套 Bean 不会叠在同一进程。这条“主路径 vs 对照路径”的区分是全篇的事实基线第三节的入门教学使用 boot 对照路径上的 ReActAgent第四节起的工程化主路径使用 HarnessAgent两者不可混为一谈。阅读顺序建议跟随这个递进先在对照入口看清最小内核再看工程层如何把内核包进边界。四层自上而下的依赖关系如下图箭头由上层指向被依赖的下层第三节沿这条单向链走到最底层的 core从四个概念开始建立认知。三、递进第一层Agent / Msg / Model / ReAct 最小内核第一次接触 AgentScope只需建立四个概念。3.1 Agent循环的驱动者Agent 是推理循环的驱动者接收一组消息驱动模型生成与工具执行交替进行最终返回承载结果的消息。框架在 core 中给出的直接实现是 ReActAgent它把系统提示、模型、工具包、最大迭代次数收进构造期配置对外暴露 call 与 streamEvents 两类入口——前者返回 Mono在服务端攒齐结果后者推送类型化事件用于流式消费。Agent 本身不承担 HTTP、序列化与容器职责这些都由外层宿主决定这也是同一个 Agent 可以被 web 与 boot 两个模块共用的原因。3.2 Msg统一消息抽象Msg 是框架内部流转的统一消息类型用户输入对应 UserMessage。一条消息可以是纯文本也可以由一组 ContentBlock 拼成TextBlock 承载文本ImageBlock 配合 URLSource 承载图片 URL。多模态请求因此与纯文本请求共用同一种入口形状。反向读取时Msg.getTextContent() 返回拼好的文本Msg 还可以携带结构化数据与单次模型调用的 ChatUsage。这意味着“消息”在框架里不只是字符串而是文本、图片、结构化数据与用量信息的共同载体。3.3 Modelprovider:model 与 ModelRegistryModel 抽象模型调用模型标识采用 provider:model 形式例如 dashscope:qwen-plus。字符串到 Model 对象的解析由 ModelRegistry 完成密钥通过 ModelCreationContext 传入Model model ModelRegistry.resolve(dashscope:qwen-plus, ModelCreationContext.builder() .apiKey(System.getenv(DASHSCOPE_API_KEY)) .build());provider 前缀决定走哪个厂商扩展冒号后是该厂商的模型名API Key 只出现在创建上下文中工程里不存在硬编码密钥。切换厂商只改字符串与对应的 Key 环境变量调用方代码不变。同一个厂商前缀对应历史沿用的环境变量名例如 deepseek: 前缀读 DEEPSEEK_API_KEY无法从前缀确定时回落 DASHSCOPE_API_KEY这类映射规则在装配处一处收口不分散到业务代码。Model 抽象与 Toolkit、RuntimeContext 完全解耦它只负责一次模型生成不知道调用方是否处于 ReAct 循环、也不管理历史消息消息累积由 Agent 负责。采样参数 temperature、topP、maxTokens 在需要时通过 GenerateOptions 传入三项均不配置则沿用模型默认值避免在工程里悄悄覆盖供应商侧的默认行为。3.4 ReAct 循环推理与行动交替ReAct 即 Reasoning Acting。一轮循环的形态是模型先产出文本若判断需要外部能力则发起工具调用框架执行工具并把结果回填模型基于结果进入下一轮直到给出最终答复或达到最大迭代次数。max-iters 是循环的硬上限达到上限时框架抛出专门的 ExceedMaxIters 事件而不是静默截断形如 exceeded max iterations: 10/10 的信息会被上层转成可渲染的失败事件。一次提问可能触发多轮模型调用例如先取时间再做运算因此 token 用量在整条链路上是累加概念而非单次生成的用量。流式视角下文本增量、工具调用开始/增量/结束、工具结果、模型用量都作为类型化事件在同一条流上到达消费方需要理解“一次工具调用等于一个事件序列”这也是第四节 EventCodec 要解决的问题。这个循环的推进与终止路径如下图这个循环接下来就会在几行代码里跑起来。3.5 几行代码跑通最小 Agent在 dream-scope 的 boot 对照路径上ReActAgent 由官方 starter 自动装配。application.yml 中的关键配置如下agentscope: agent: enabled: true name: chat sys-prompt: 你是一个有帮助的助手。 max-iters: 10 model: provider: dashscope dashscope: api-key: ${DASHSCOPE_API_KEY:} model-name: qwen-plus stream: true片段出处dream-scope-boot/src/main/resources/application.ymlstarter 据此完成的动作等价于用 3.3 节的方式解析出 dashscope:qwen-plus 的 Model再构造一个 ReActAgent。拿到 Agent 之后最小调用只有几行Msg reply agent .call(List.of(new UserMessage(用一句话解释 ReAct 循环)), RuntimeContext.builder().build()) .block(Duration.ofSeconds(120)); System.out.println(reply.getTextContent());List.of(new UserMessage(...)) 是入参消息列表RuntimeContext 承载 userId、sessionId 等运行时维度block 给出等待上限返回值是同一种 Msg——入参与出参对称是这个内核最容易建立的心智模型。系统提示没有写在调用处而是在 Agent 构造期固化因此每一轮对话不必重复传入角色设定多轮续聊时历史消息按同一形状追加进列表即可。需要边推理边消费时把 call 换成 streamEvents 即可agent.streamEvents(List.of(inbound), context) .timeout(Duration.ofSeconds(120)) .subscribe(event - { /* 文本增量、工具事件按类型消费 */ });这条对照路径没有 Harness也就没有 Redis、子 Agent、技能与 Plan Mode它的价值是把内核形状暴露到最小一个 Agent、一种消息、一个模型、一条循环。dream-scope 的 boot 模块8092保留了完整的可运行版本第五节给出启动方式。需要特别说明最小样例中没有手写 builder 链是因为 boot 路径刻意交给官方自动配置——starter 的意义正是让“模型供应商、模型名、系统提示”这些装配项留在配置文件里工程代码只负责使用 Agent。要理解 builder 每一项背后的工程决策则要看第四节 HarnessAgent 的形态这也是系列递进的次序先看清内核是什么再看工程层加了什么。四、从玩具到工程裸 ReActAgent 缺什么dream-scope 怎么补控制台能打印回复只验证了 SDK 可用。把同一个 Agent 放进需要长期运行的 Web 服务三个缺口立刻出现。4.1 三个缺口第一流式细事件无法直接面向前端。一次工具调用在 2.0.3 的类型化事件流里不是一条事件而是 ToolCallStartEvent、若干条 ToolCallDeltaEvent、ToolCallEndEvent 的序列工具结果侧同样是 ToolResultTextDeltaEvent 后接 ToolResultEndEvent。end 事件没有完整的 input/output getter完整入参出参必须从 delta 拼接end 事件还可能不带工具名名称只出现在 start 或 delta 上。直接透传前端收到的就是一串半截 JSON。第二没有跨进程的状态与记忆。starter 给出的 ReActAgent 使用内存 Memory 与空 Toolkit进程重启会话即丢多轮对话变长后缺少压缩机制上下文会持续膨胀直到触及模型窗口。对于一个按 HTTP 请求提供服务的进程会话还需要按用户与会话标识隔离而不是所有请求共用同一段内存。第三框架类型污染边界。Web 层需要的是 HTTP 入参与 JSON/SSE 出参如果 Msg、框架事件、RuntimeContext 直接出现在 Controller 和业务代码里框架升级就会变成全工程改动。这类污染初期没有痛感真正暴露通常在框架升版本、改供应商或需要给同一套业务逻辑增加第二个出口的时候。三个缺口指向同一个判断最小内核解决“Agent 能不能跑”工程化解决“Agent 能不能长期稳定地跑在 Web 进程里”。两者不是优劣关系而是分层关系——dream-scope 没有修改内核而是在内核之外补齐契约、边界与协议。4.2 六模块六边形边界dream-scope 的回答首先是模块边界。工程共六个 Maven 模块模块职责dream-scope-bom对外版本锁Spring Boot / Spring Cloud Alibaba / AgentScope / 本仓库模块dream-scope-domainSPIService Provider Interface留给上层实现替换的接口约定、请求响应、Agent 注册表零框架依赖dream-scope-adapterAgentScope 装配模型、消息与事件编解码、Harness 主路径dream-scope-knowledgeRAG检索增强生成先检索资料再让模型作答实现只依赖 domaindream-scope-web默认产品入口手写 PortsConfig 与 HTTP/SSE端口 8091dream-scope-boot官方 starter 对照入口端口 8092bom 只承担版本锁不参与运行时依赖其余五个模块的依赖方向如下图箭头由依赖方指向被依赖方boot 与 domain 在图上没有出边——前者独立走官方 starter后者不依赖任何模块这份独立由下一组构建规则强制保证。domain 不出现框架类型不是口头约定。domain 与 knowledge 的 pom 中启用 maven-enforcer-plugin配合根 POM 的 bannedDependencies 规则excludeio.agentscope:*/exclude一旦 domain 误引任何 AgentScope 包构建直接失败。防腐层是否成立因此从 code review 纪律变成编译纪律在 domain 代码中搜索 io.agentscope 的 import 语句应当零命中。4.3 两道编解码MessageCodec 与 EventCodecdomain 只认识 String 与图片 URL框架只认识 Msg 与 ContentBlock翻译集中在 adapter 的 MessageCodec。纯文本与多模态入口在同一方法收口public static Msg toUserMessage(String input, ListString imageUrls) { String text input null ? : input; if (imageUrls null || imageUrls.isEmpty()) { return new UserMessage(text); } ListContentBlock blocks new ArrayList(); if (!text.isBlank()) { blocks.add(TextBlock.builder().text(text).build()); } for (String url : imageUrls) { blocks.add(new ImageBlock(new URLSource(url))); } return new UserMessage(blocks); }片段出处dream-scope-adapter/src/main/java/com/zhu/scope/adapter/MessageCodec.java反方向由 textOf 调 Msg.getTextContent() 收口空消息安全回落为空串结构化数据由 structuredOf 提取为 Map提取做两段兜底先按宽松模式读取失败再走 Class 重载两种方式都取不到才返回 null以此消化不同供应商消息结构的细微差异。所有翻译静态、无状态、只有一处不散落在各 Agent 实现里。判断防腐是否成立有一个简单标准Msg、UserMessage 这些类型的 import 只允许出现在 adapterweb 与 domain 里永远只能拿到 String、record 与领域事件。流式碎片的拼装由 EventCodec 负责。它内部维护三张 MaptoolCallId 到最近一次非空工具名、到入参碎片缓冲、到出参碎片缓冲。穷尽 switch 中工具相关分支的形态如下case ToolCallStartEvent e - rememberTool(e.getToolCallId(), e.getToolCallName()); case ToolCallDeltaEvent e - bufferTool(toolInputs, e.getToolCallId(), e.getToolCallName(), e.getDelta()); case ToolCallEndEvent e - Optional.of(new AgentEvent.ToolCall( finishTool(e.getToolCallId(), e.getToolCallName()), take(toolInputs, e.getToolCallId())));片段出处dream-scope-adapter/src/main/java/com/zhu/scope/adapter/event/EventCodec.javastart 与 delta 返回 Optional.empty()表示框架内部态不对外发到 end 才 take 出完整缓冲弹出一条完整的 ToolCall工具名缺失时由缓存回填。EventCodec 有状态且非线程安全正确用法是每次请求 new 一个跨请求复用会把上一轮的半截入参拼进下一轮。其余边界处理无 id 碎片归桶、用量累加、过程提示与订阅级异常见仓库 EventCodec 源码与配套测试。4.4 SSE 主路径与 HarnessAgent对外事件协议由 domain 的 sealed interface 固定为六种TextDelta、ToolCall、ToolResult、Hint、Done、Error与 SSE 的 event 名 textDelta / toolCall / toolResult / hint / done / error 一一对应。sealed 让事件协议成为封闭集合新增类型会在编译期打断所有消费方。同步入口不是另一条裸 call而是在内部订阅同一条流式实现、拼齐 Done 后返回两个出口共用一条推理主路径。整条流式链路的协作时序如下图至此从 HTTP 请求到六种 SSE 事件的完整链路已经收齐缺的只是主角的装配细节。主路径的主角是 HarnessAgentScopeChatAgent 对外实现 domain 的 StreamingAgentHandler对内持有它builder 的关键片段如下HarnessAgent.builder() .name(AgentIds.CHAT) .sysPrompt(prompt) .model(model) .toolkit(toolkit) .compaction(compactionConfig(30, 10)) .memory(MemoryConfig.defaults()) .subagents(chatSubagents()) .middlewares(chatMiddlewares()) .disableFilesystemTools() .disableShellTool();片段出处dream-scope-adapter/src/main/java/com/zhu/scope/adapter/ScopeChatAgent.javaworkspace、Redis DistributedStore 与 Plan Mode 按运行环境条件挂入ScopeChatAgent 本身没有 Spring 注解资源打开顺序Redis ping、MCPModel Context Protocol模型连接外部工具与数据的开放协议连接、构造 Agent与关闭顺序Harness、MCP、Redis在静态工厂中严格定义任何一步失败都会关闭已申请的资源不带着半开连接退出。每一项配置对应一个工程决策但完整实现不在本篇逐一展开仓库 adapter 模块可直接对照源码。RAG、HITL、Compaction上下文压缩对话过长时把早期消息压缩成摘要触发细节、MCP 与子 Agent 均留给后续篇目。这里值得收束第四节的设计逻辑。六模块边界、enforcer、MessageCodec、EventCodec、HarnessAgent 与两个出口六个构件各自只回答一个问题合起来才构成一条从 HTTP 到 SSE 的完整主路径单独抽出任何一件都不复杂难点在于让它们各自独立又彼此咬合这也是 dream-scope 作为工程样本的主要价值。五、10 分钟跑起来以下命令以仓库 README 为准环境需要 JDK 21、Maven 3.9 与 Docker。克隆仓库git clone https://github.com/logosssss/dream-scope.git cd dream-scope复制环境变量模板并填入 Keycp .env.example .env需要注意进程不会自动加载 .env 文件配置走 Spring Environment。可以把 Key 导出到当前 shellexport DASHSCOPE_API_KEYyour-key或写入已 gitignore 的 application-local.yml启动时加 --spring.profiles.activelocal。真实 Key 不要入库。启动必选的 Redisdocker compose up -d redis启动默认产品入口 web端口 8091mvn -pl dream-scope-web -am spring-boot:run同步调用curl -s http://localhost:8091/api/agents/invoke \ -H Content-Type: application/json \ -d {\input\:\你好\}返回 JSON 中 output 为模型回复inputTokens / outputTokens 为累计用量planActive 标识计划模式状态。一次典型返回的形态如下{agentId:chat,output:你好有什么可以帮你的,inputTokens:0,outputTokens:0,data:null,planActive:false}需要续聊时在请求体中带上成对的 sessionId 与 userId会话即写入 Redis 同一槽位只传其中一个等同于无会话。请求体还支持 imageUrls最多 8 个 http/https 图片地址、structured 与 jsonSchema结构化输出input 与 imageUrls 至少一个非空否则返回 400模型超时返回 504供应商或运行失败返回 502。流式调用curl -N http://localhost:8091/api/agents/stream \ -H Content-Type: application/json \ -d {\input\:\你好\}响应为 text/event-stream事件按 textDelta、toolCall、toolResult、hint、done、error 依次出现done 之后连接结束。done 的 JSON 含 finalOutput、inputTokens、outputTokens 与 planActive多轮 ReAct 触发多次模型调用时 token 为累加值结构化请求成功时还会带 data 对象。-N 参数让 curl 不缓冲输出便于直接观察增量到达的顺序。SSE 连接超时为 chat-timeout 再加 30 秒默认配置下为 150 秒。对照入口 boot 不需要 Redis启动后监听 8092可用于体验官方 starter 与 ReActAgent 最简路径mvn -pl dream-scope-boot -am spring-boot:run curl -s http://localhost:8092/api/agents/invoke \ -H Content-Type: application/json \ -d {\input\:\你好\}六、本篇学到了什么与 02 预告框架侧本篇建立了四个概念Agent 是推理循环的驱动者Msg 是文本、图片与结构化数据的统一载体Model 通过 provider:model 字符串与 ModelRegistry 解析ReAct 循环按“模型推理—工具行动—结果回填”推进直到最终答复或迭代上限。四者的依赖方向清晰Agent 持有 Model 与 Toolkit消息在循环中以 Msg 形状流转循环本身不感知 Web 与 Spring。在 boot 对照路径上几行代码即可跑通最小 Agent。工程侧最小内核与产品主路径之间存在明确缺口被拆散的流式细事件需要按 toolCallId 攒齐进程内状态需要升级为分布式会话与记忆压缩框架类型必须靠模块边界与编解码挡在业务代码之外。dream-scope 用六模块六边形边界、构建期 enforcer、MessageCodec、EventCodec 与 SSE 主路径给出了一份可直接运行的回答。两个出口共用同一套调用契约与同一条推理链是这套设计的收口点。下一篇进入 Harness 工程层HarnessAgent 与 ReActAgent 的分工、Workspace 目录约定、基于 RuntimeContext 的多租户状态会话、Redis 分布式存储与 Compaction 记忆压缩以及 Middleware 与权限取舍的真实决策。主路径为什么是 HarnessAgent届时结合代码逐层展开。项目信息dream-scope 开源地址GitHub - logosssss/dream-scope: 基于 AgentScope Java 2.0 的模块化单体 Agent 运行时 · GitHub 觉得有帮助欢迎 starDream-SaaS 项目地址https://dream-saas.com有问题评论区见欢迎交流~