1. 从“指令驱动”到“智能体驱动”的范式转变如果你最近在折腾大模型应用开发尤其是想用 Java 来搞点事情那你肯定对“Prompt Engineering”提示词工程这个词不陌生。我们花了大量时间像雕琢咒语一样精心设计一段段文本试图让大模型理解我们的意图并给出精准的回应。从简单的角色扮演到复杂的思维链CoT再到各种高级技巧我们乐此不疲。但不知道你有没有和我一样的感受当业务逻辑稍微复杂一点需要多个步骤、调用外部工具、或者处理长上下文时光靠一个或几个精心设计的 Prompt就开始力不从心了。代码里充斥着大量的字符串拼接、条件判断和结果解析整个项目很快就变成了一团难以维护的“胶水代码”。这感觉就像你试图用一堆精心准备的演讲稿Prompt去指挥一个交响乐团但乐团成员大模型、工具、数据之间缺乏一个统一的指挥和协作机制最终可能是一片混乱。这就是为什么我们需要Agent智能体。智能体不是一个简单的“问答机”而是一个具备自主感知、规划、决策和执行能力的实体。它可以根据目标动态地决定下一步做什么是调用一个工具查询天气还是根据历史对话总结要点或者是向用户提出一个澄清性问题。而AgentScope这个框架正是为了帮助我们高效地构建和管理这样的智能体而生的。我之前也关注过它的 Python 版本功能很强大社区也很活跃。但作为一个长期深耕 Java 技术栈的开发者我一直在期待一个能无缝融入 Spring Boot、MyBatis 这套生态的 Java 版 Agent 框架。直到AgentScope Java 1.1.0带着全新的Harness 架构出现我才感觉属于 Java 开发者的智能体时代可能真的要来了。这次 1.1.0 版本最大的亮点就是彻底重构了核心架构引入了Harness这个概念。你可以把它理解为一套“缰绳”或“驾驶舱”系统。如果说之前的版本是给每个智能体配了简单的操作手册Prompt那么 Harness 就是为整个智能体团队打造了一个集成的任务控制中心。它不再仅仅关注单次的“提问-回答”而是着眼于智能体完整生命周期的编排与管理。这背后反映的正是开发范式从“指令驱动”向“智能体驱动”的深刻转变。我们不再只是写死流程而是定义规则和目标让智能体在 Harness 的约束和辅助下自主、可靠地完成任务。接下来我就结合官方文档、源码阅读以及自己的实践尝试为你深入拆解这套全新的 Harness 架构设计看看它到底解决了哪些痛点又能给我们 Java 开发者带来怎样的新可能。2. Harness 架构核心设计思想解读2.1 为什么是“Harness”在深入细节之前我们先聊聊这个名字的寓意。“Harness”英文原意是“马具”、“缰绳”引申为“利用”、“控制”、“驾驭”。用在 AgentScope 的语境下我觉得它精准地传达了三个层面的含义控制与安全如同缰绳控制马匹的方向和速度Harness 架构旨在为强大的智能体能力提供可控的执行边界。大模型本身具有不可预测性直接让其“自由发挥”在生产环境中是危险的。Harness 通过定义清晰的状态机、约束条件和监控钩子确保智能体的行为始终在业务逻辑允许的轨道内运行防止“幻觉”输出或越权操作带来的风险。协同与编排一套马具能协调多匹马共同拉车。Harness 架构的核心目标之一就是编排多个智能体、工具、记忆模块之间的复杂协作。它定义了智能体之间如何传递消息、如何共享上下文、如何解决冲突使得多个智能体能够像一支训练有素的团队一样工作完成单个智能体无法处理的复杂任务。效率与复用好的马具是标准化、可复用的。Harness 架构将智能体的通用运行逻辑如循环等待输入、处理中断、维护对话状态抽象出来形成一套标准化的“驾驶舱”接口。开发者无需重复编写这些样板代码只需关注业务特定的逻辑智能体的“大脑”和“技能”从而大幅提升开发效率并且使得智能体组件更容易被测试和复用。2.2 核心架构组件拆解AgentScope Java 1.1.0 的 Harness 架构主要由以下几个核心组件构成它们共同协作形成了一个完整的智能体运行时环境。2.2.1 Harness缰绳/驾驶舱这是整个架构的总控中心。它是一个抽象类定义了智能体执行任务的标准流程。你可以把它想象成一个剧本的导演或一个工作流的引擎。其主要职责包括生命周期管理负责智能体的初始化、启动、运行、暂停、恢复和销毁。消息循环驱动驱动智能体主循环从外部用户、其他智能体接收消息传递给智能体处理再将处理结果发送出去。状态维护维护智能体的当前状态如空闲、运行中、等待输入、错误等并对外提供状态查询接口。异常处理与容错捕获智能体执行过程中抛出的异常根据预设策略如重试、降级、终止进行处理保证系统的鲁棒性。提供扩展点通过一系列“钩子”Hooks方法允许开发者在生命周期的关键节点注入自定义逻辑例如在每次收到消息前进行鉴权或在发送消息后进行日志记录。2.2.2 Agent智能体这是执行具体任务的核心单元。在 Harness 架构下Agent 的职责变得更加纯粹和聚焦根据当前的状态和输入的消息决定要执行的动作Action。它不再需要关心消息如何路由、状态如何持久化、循环如何控制这些“杂事”。一个典型的 Agent 实现通常包含模型客户端用于连接大模型如 OpenAI GPT、阿里云通义千问、智谱 GLM 等。提示词模板定义与模型交互的“话术”可能包含角色设定、任务描述、上下文填充位等。工具集Tools智能体可以调用的外部函数如查询数据库、调用 API、执行计算等。记忆Memory用于存储和检索对话历史、知识片段为决策提供上下文。动作Action智能体决策的输出可能是一个简单的文本回复也可能是一个工具调用请求。2.2.3 消息Message与 对话Dialog这是智能体之间以及智能体与外界通信的血液。Harness 架构强化了消息系统的地位。Message结构化的通信单元。通常包含发送者、接收者、内容、类型如文本、工具调用结果、错误信息等元数据。统一的消息格式使得不同智能体之间的协作成为可能。Dialog可以看作是一个消息的会话容器。它管理着一个智能体参与的所有消息序列提供了按时间、按发送者查询消息的能力是智能体“记忆”的重要载体。Harness 通常会为每个智能体绑定一个 Dialog 实例。2.2.4 仓库Repository与 钩子Hooks这两个是提升架构可扩展性和可观测性的关键。Repository一个可插拔的存储抽象层。用于持久化智能体的状态、对话历史、工具调用记录等。默认可能提供内存实现但可以轻松替换为 Redis、MySQL 或任何其他数据库这对于实现智能体的状态恢复、跨会话记忆至关重要。Hooks一系列定义在 Harness 生命周期关键节点的回调接口。例如onMessageReceived: 收到消息时触发可用于消息过滤、格式化。onBeforeAgentAct: 智能体决策前触发可用于注入上下文、进行权限检查。onAfterAgentAct: 智能体决策后触发可用于记录动作、发送通知。onError: 发生错误时触发用于统一错误处理和告警。 通过实现这些钩子开发者可以非侵入式地为智能体添加审计、监控、调试、定制化业务逻辑等功能。2.3 新旧架构对比与优势为了更直观地理解 Harness 带来的改变我们可以做一个简单的对比对比维度旧有模式 / 单纯 Prompt 驱动AgentScope Java 1.1.0 Harness 架构控制流由业务代码硬编码控制流程僵化难以应对分支和循环。由 Harness 引擎驱动基于状态和消息的事件驱动模式灵活支持复杂工作流。智能体职责混杂既要处理业务逻辑又要管理状态、通信等基础设施。职责单一专注“感知-决策”基础设施由 Harness 托管。可观测性差日志分散难以追踪一次完整对话的智能体内部状态变化。强通过 Hooks 和结构化日志可以清晰看到消息流、状态迁移和决策过程。容错性弱异常处理需要开发者手动在业务代码中到处添加 try-catch。强Harness 提供统一的异常处理管道和重试、降级策略。可测试性困难智能体与运行环境高度耦合。容易Harness 提供了清晰的接口可以方便地对 Agent 进行单元测试和集成测试。复用与组合低智能体像“黑盒”难以被其他流程复用。高智能体成为标准的、可插拔的组件易于组合成更复杂的多智能体系统。注意从“Prompt驱动”升级到“Harness架构”本质上是一种设计范式的升级。它要求开发者从思考“如何写一个完美的Prompt”转变为思考“如何设计一个能自主完成任务的智能体以及如何为它配置合适的运行环境Harness”。这个思维转变是用好这个框架的关键。3. 深入 Harness 运行机制与核心实现理解了组件我们再来看看它们是如何协同工作的。一个智能体在 Harness 架构下的典型生命周期可以概括为以下几个核心阶段。3.1 初始化与启动阶段这一阶段主要是“搭台”为智能体的运行准备舞台和道具。// 示例创建一个简单的对话型智能体及其 Harness // 1. 配置模型服务例如使用阿里云灵积 ModelServiceConfig modelConfig new ModelServiceConfig(); modelConfig.setType(dashscope); modelConfig.setConfig(new HashMap() {{ put(api_key, your-api-key-here); put(model, qwen-max); }}); // 2. 创建智能体并绑定模型和提示词 PromptTemplate promptTemplate new PromptTemplate(你是一个友好的助手。历史对话{{history}}\n用户{{current_input}}\n助手); Agent myAgent new SimpleDialogueAgent(assistant, modelConfig, promptTemplate); // 3. 创建 Harness并装配智能体、仓库、钩子等 MemoryRepository repository new InMemoryRepository(); // 使用内存仓库 Harness harness new DefaultHarness.Builder() .agent(myAgent) .repository(repository) .addHook(new LoggingHook()) // 添加日志钩子 .addHook(new MetricsHook()) // 添加监控指标钩子 .build(); // 4. 启动 Harness此时智能体进入就绪状态 harness.start();在这个阶段DefaultHarness.Builder扮演了工厂的角色它确保所有必需的组件如 Agent、Repository都被正确装配。start()方法会初始化内部状态机并可能启动一些后台线程如用于监听消息队列。3.2 消息处理与智能体决策循环这是 Harness 的核心驱动循环。一旦启动Harness 就进入一个事件循环等待并处理消息。消息接收外部系统如 HTTP 控制器、消息队列消费者调用harness.sendMessage(message)。这个消息必须指定目标智能体的 ID。触发钩子onMessageReceived钩子被触发你可以在这里进行消息预处理。状态检查与转换Harness 检查当前智能体状态是否允许处理新消息例如如果智能体正忙可能将消息放入队列。然后将智能体状态可能转换为“处理中”。上下文准备Harness 从绑定的Dialog中加载最近的对话历史并从Repository中加载其他相关状态将它们与当前消息一起组装成智能体决策所需的“上下文”Context。调用智能体Harness 调用agent.act(context)方法。这是智能体“大脑”工作的时刻智能体结合上下文和自身的提示词模板生成最终发送给大模型的 Prompt。大模型返回响应。智能体解析响应可能将其识别为一个简单的文本回复也可能识别为一个工具调用请求例如{“action”: “call_tool”, “tool_name”: “get_weather”, “parameters”: {“city”: “北京”}}。智能体最终返回一个Action对象。后处理与执行Harness 接收到Action。如果 Action 是工具调用Harness 会负责在安全的沙箱或指定环境中执行该工具并将执行结果封装成新的消息再次发送回给这个智能体形成递归由智能体根据工具结果决定下一步。如果 Action 是最终回复Harness 会触发onAfterAgentAct钩子然后通过harness.reply(message)或其他回调机制将回复发送给最初的请求者。状态持久化与清理将本次交互产生的新消息存入Dialog更新智能体状态并可能通过Repository进行持久化。最后将智能体状态恢复为“空闲”等待下一条消息。这个循环的精妙之处在于将工具调用也纳入了消息循环。工具执行结果被当作一个新的“内部消息”来处理这使得智能体可以链式、递归地调用多个工具直到完成任务整个过程完全由 Harness 统一调度对开发者透明。3.3 状态管理与持久化策略智能体的“状态”是理解其行为的关键。Harness 管理着两种主要状态运行时状态由 Harness 内部状态机维护如IDLE,PROCESSING,WAITING_FOR_TOOL,ERROR等。这决定了 Harness 当前能接受什么操作。业务状态存储在Repository中的持久化状态。这包括对话历史完整的 Message 序列是智能体记忆的核心。智能体属性一些需要跨会话保留的键值对例如用户的偏好设置、任务进度等。工具调用缓存昂贵的工具调用结果可以缓存起来提高后续响应速度。持久化策略的选择至关重要InMemoryRepository适用于开发、测试或短期会话场景。重启即丢失。RedisRepository生产环境推荐。利用 Redis 的高性能和丰富数据结构List 存对话Hash 存属性能很好地支持高并发和分布式部署。需要注意设置合理的 TTL生存时间。JdbcRepository如果状态需要强一致性或需要做复杂的查询分析可以选用关系型数据库。但性能可能成为瓶颈需要精心设计表结构如消息表可能非常庞大。实操心得在生产环境中我建议采用Redis 作为主存储因为它读写速度快数据结构匹配度高。同时可以配合一个LoggingHook将重要的状态变更和消息流同步写入到 Elasticsearch 或数据库做长期存储和分析实现可观测性。这样既保证了运行时性能又满足了审计和数据分析的需求。3.4 钩子Hooks的实战应用场景钩子是 Harness 架构的“瑞士军刀”下面列举几个实战场景场景一注入系统级上下文假设你的智能体需要知道当前日期、服务器负载等信息。你可以实现一个onBeforeAgentAct钩子在每次智能体决策前自动将这些信息添加到上下文中而无需修改每个智能体的提示词。public class SystemContextHook implements AgentHook { Override public void onBeforeAgentAct(AgentContext context) { MapString, Object sysInfo new HashMap(); sysInfo.put(current_date, LocalDate.now().toString()); sysInfo.put(server_load, getSystemLoad()); // 假设的方法 context.setSystemVariables(sysInfo); } }场景二敏感信息过滤与审计所有进出智能体的消息都需要经过内容安全审核和审计。public class SecurityAuditHook implements AgentHook { Override public void onMessageReceived(Message message) { // 1. 内容安全过滤 if (containsSensitiveInfo(message.getContent())) { throw new SecurityException(消息包含敏感信息); } // 2. 审计日志 auditLog.info(Received message: {} from {}, message.getId(), message.getSender()); } Override public void onAfterAgentAct(AgentContext context, Action action) { // 审计智能体的决策和输出 auditLog.info(Agent {} took action: {}, context.getAgentId(), action.getType()); } }场景三性能监控与限流监控智能体的响应延迟和调用频率。public class MetricsHook implements AgentHook { private final MeterRegistry meterRegistry; // 假设使用 Micrometer Override public void onBeforeAgentAct(AgentContext context) { context.putAttachment(startTime, System.nanoTime()); } Override public void onAfterAgentAct(AgentContext context, Action action) { Long startTime (Long) context.getAttachment(startTime); if (startTime ! null) { long duration System.nanoTime() - startTime; meterRegistry.timer(agent.act.duration).record(duration, TimeUnit.NANOSECONDS); } // 可以在这里检查调用频率实现限流 } }通过组合不同的钩子你可以为智能体系统轻松添加各种横切关注点Cross-Cutting Concerns的功能保持业务代码的纯净。4. 基于 Harness 架构构建复杂多智能体系统Harness 架构的真正威力在构建多智能体系统Multi-Agent System, MAS时体现得淋漓尽致。单个智能体能力有限但多个各司其职的智能体协作可以解决极其复杂的问题。4.1 多智能体协作模式设计在 Harness 架构下多智能体协作主要有两种典型模式模式一主从式Master-Worker一个“主管”智能体负责接收用户任务将其分解为子任务然后调度不同的“工作者”智能体去执行。主管收集结果并汇总反馈给用户。实现为每个智能体主管和工作者创建独立的 Harness 实例。主管智能体的act方法中逻辑是解析任务然后通过workerHarness.sendMessage()向对应的工作者发送任务消息。工作者处理完后将结果消息发送回主管的 Harness需要配置消息路由例如通过一个共享的消息总线或直接回调。适用场景任务分解清晰子任务间耦合度低如一个客服系统主管负责理解用户意图然后调度“查询订单”工作者、“处理退货”工作者等。模式二平等协作式Peer-to-Peer多个智能体地位平等通过互相通信、协商来共同完成任务。就像一个专家小组开会讨论。实现每个智能体都有自己的 Harness。它们通过一个集中的消息路由器Message Router或共享的对话空间Shared Dialog进行通信。智能体 A 将消息发给路由器并指定接收者为智能体 B路由器负责找到 B 的 Harness 并投递消息。AgentScope 通常提供一个Room或Group的概念来简化这种模式。适用场景需要多角度决策、创意生成、复杂谈判等例如一个产品设计评审会由“设计师”、“工程师”、“市场经理”三个智能体角色共同讨论。4.2 实战构建一个技术问答系统假设我们要构建一个系统用户输入一个技术问题如“如何在 Spring Boot 中整合 Redis”系统需要给出高质量、可落地的答案。系统设计我们采用主从式协作设计三个智能体RouterAgent路由智能体分析用户问题判断其属于哪个技术领域前端、后端、数据库等。SearchAgent搜索智能体负责调用外部知识库或搜索引擎 API获取相关的技术文档、博客、Stack Overflow 片段。AnswerAgent回答智能体接收问题和搜索到的资料生成结构清晰、包含代码示例的最终答案。Harness 编排与消息流用户请求到达系统入口创建一个包含用户问题的Message发送给RouterAgent的 Harness。RouterAgent分析后判断为“后端/Java”问题。它生成一条新的Message内容为“搜索关键词Spring Boot Redis 整合”发送给SearchAgent的 Harness。SearchAgent调用搜索工具获取到3篇相关文章和代码片段。它将搜索结果封装成Message发送给AnswerAgent的 Harness。AnswerAgent综合原始问题和搜索资料生成最终答案。它通过 Harness 的回复机制将答案返回给系统入口再呈现给用户。关键实现点消息路由我们需要一个简单的AgentRegistry来维护所有智能体 Harness 的引用以便智能体 A 能通过registry.getHarness(“SearchAgent”).sendMessage(...)向 B 发送消息。上下文传递RouterAgent在发给SearchAgent的消息中需要携带原始问题的 ID 或内容以便最终AnswerAgent能关联起来。这可以通过在Message中设置parentId或conversationId字段来实现。超时与错误处理在主管智能体或一个专门的协调器的 Harness 中设置超时钩子。如果某个工作者智能体长时间未响应协调器可以触发重试或降级策略例如让另一个备用的搜索智能体工作。4.3 性能考量与优化建议当智能体数量增多、交互变复杂时性能成为关键。Harness 实例管理每个智能体一个 Harness 实例是清晰的但也会消耗更多资源内存、线程。对于无状态或轻量级的智能体可以考虑使用“池化”策略即创建一个智能体实例池多个并发的请求共享这些实例由 Harness 来管理并发访问通常需要保证 Agent 是无状态的或状态完全由外部 Repository 管理。异步非阻塞Harness 的核心消息循环应设计为异步非阻塞模式。当智能体在等待大模型响应或工具调用可能是网络 I/O时不应该阻塞处理线程。可以利用CompletableFuture或响应式编程模型如 Project Reactor来实现让一个线程可以服务多个智能体的并发请求。仓库性能如前所述选择高性能的 Repository 实现如 Redis。对于对话历史可以考虑只保留最近 N 轮对话在内存或快速存储中更早的历史归档到冷存储。模型调用优化这是最大的性能瓶颈。可以采用以下策略缓存对常见、结果稳定的模型请求进行缓存可在 Hook 中实现。批处理将多个独立的、不紧急的推理请求合并成一个批量请求发送给模型 API如果 API 支持。降级模型在非关键路径或简单任务上使用更小、更快的模型。监控与告警通过 Hooks 全面接入 APM应用性能监控系统。监控关键指标消息队列长度、智能体平均响应时间、模型调用耗时与费用、工具调用错误率等。设置告警以便在系统出现瓶颈或异常时及时干预。5. 常见问题、排查技巧与进阶思考即使有了优秀的架构在实际开发和运维中依然会遇到各种问题。下面分享一些我实践中遇到的典型问题和解决思路。5.1 典型问题排查速查表问题现象可能原因排查步骤与解决方案智能体无响应或超时1. 大模型 API 调用失败或超时。2. 工具调用陷入死循环或长时间阻塞。3. Harness 消息队列堵塞。1. 检查模型 API 密钥、网络连通性、服务状态。在 Hook 中增加模型调用的超时设置和重试逻辑。2. 检查工具实现是否有无限循环或依赖的外部服务不可用。为工具调用设置独立超时。3. 检查是否有某个消息处理异常导致状态机卡死。增加 Harness 级别的看门狗Watchdog监控单个消息处理时长。智能体输出不符合预期胡言乱语1. Prompt 设计有歧义或指令冲突。2. 上下文Dialog中积累了过多无关或错误的历史消息。3. 模型温度temperature参数过高。1. 使用系统 Prompt 明确角色和规则。采用思维链CoT或提供更具体的输出格式示例。2. 在 Hook 中实现对话历史摘要或过滤功能只保留相关历史。或定期清理 Dialog。3. 对于需要稳定输出的任务将 temperature 调低如 0.2。多智能体间消息丢失1. 消息路由配置错误发送给了错误的 Harness ID。2. 接收方智能体状态异常如处于 ERROR 状态拒绝了消息。3. 异步处理中消息回调丢失。1. 强化日志记录每条消息的发送者、接收者和路由路径。实现一个消息轨迹 IDTraceId贯穿整个处理链。2. 在发送消息前检查目标 Harness 的状态。实现死信队列处理无法投递的消息。3. 使用可靠的异步框架并确保回调函数的异常被捕获和处理。状态不一致或丢失1. Repository 持久化失败如 Redis 连接断开。2. 并发访问导致状态覆盖多个请求同时修改同一智能体状态。1. 为 Repository 操作增加重试和降级策略如先写本地缓存异步同步到远程。监控存储层健康状态。2. 对于关键状态更新使用乐观锁或分布式锁。或者将智能体设计为无状态的所有状态都通过消息传递。工具调用权限问题或副作用1. 工具执行了危险操作如删除文件。2. 工具消耗资源过多。1.这是安全重中之重必须在 Harness 或 Hook 层实现严格的工具权限沙箱。对工具输入进行校验和清洗。限制智能体可调用的工具范围。2. 为工具执行设置资源限制CPU、内存、执行时间。对高风险工具进行二次确认例如通过另一个“审核智能体”或人工审核流程。5.2 调试与日志技巧结构化日志不要在代码里乱打System.out.println。使用 SLF4J Logback/Log4j2并定义清晰的结构化日志格式包含agentId,messageId,traceId,timestamp,level,event如MESSAGE_RECEIVED,AGENT_ACT_START,TOOL_CALLED等字段。这便于后续用 ELKElasticsearch, Logstash, Kibana或 Loki 进行聚合查询和链路追踪。可视化消息流可以开发一个简单的管理界面或者利用 Hook 将所有的消息流包括智能体内部产生的工具调用和结果消息推送到一个图形化工具甚至可以是简单的 Mermaid 图生成器实时查看智能体之间的对话图谱这对调试复杂协作流程非常有用。Prompt 与上下文快照在onBeforeAgentAct钩子中将最终发送给大模型的完整 Prompt 和上下文信息记录下来。当模型输出出现问题时这是最重要的调试依据。5.3 安全与合规考量智能体系统直接处理用户输入并可能执行外部操作安全风险极高。输入输出过滤对所有用户输入和模型输出进行严格的过滤防止 Prompt 注入、越权指令、敏感信息泄露。工具沙箱绝对不要允许智能体直接执行操作系统命令或访问敏感数据库。所有工具都应在受控的、权限最小化的环境中运行。考虑使用 Docker 容器或轻量级沙箱技术来隔离工具执行。审计溯源利用 Repository 和 Hooks记录下每一次智能体决策、每一次工具调用的完整上下文和结果。确保所有操作可追溯满足合规要求。人工审核回路对于高风险操作如发送邮件、修改数据、生成重要内容设计流程让智能体的决策先进入一个待审核队列由人工确认后再执行。5.4 未来展望与进阶方向Harness 架构为 AgentScope Java 打下了坚实的基础但社区和生态的繁荣才是关键。我认为接下来有几个值得关注的方向更丰富的内置智能体类型除了基础的对话智能体需要更多开箱即用的智能体如规划智能体擅长分解任务、审核智能体检查内容安全与合规、代码智能体专精代码生成与审查。可视化编排工具提供一个低代码/无代码的界面让开发者可以通过拖拽的方式将不同的智能体、工具、条件判断节点连接起来形成可视化的工作流进一步降低多智能体系统的开发门槛。与现有 Java 生态深度集成提供 Spring Boot Starter让 Harness 和智能体能像普通 Bean 一样被注入和管理。与 Micrometer 深度集成用于监控与 Spring Cloud Stream 集成用于事件驱动等。分布式 Harness当前的 Harness 设计主要针对单机或单个服务进程。未来可能需要支持分布式的 Harness 集群智能体可以跨进程、跨机器部署和通信通过消息中间件如 Kafka, RabbitMQ来连接从而实现真正的弹性伸缩和高可用。从单纯的 Prompt 工程到 Harness 架构下的智能体系统开发这不仅仅是技术的升级更是思维模式的进化。我们不再是与一个静态的模型对话而是在设计和培育一个能够自主运作、与环境交互、并持续学习的数字生命体。AgentScope Java 1.1.0 的 Harness 架构为我们 Java 开发者提供了驾驭这个新范式的强大工具和清晰路径。剩下的就是发挥我们的创造力去构建那些曾经只存在于想象中的智能应用了。