registerHost 方法先调用 mapper.addHost，然后调用 registerContext 方法注册 Host 的子容器 Context。mapper.addHost 方法是将 Host 加入的 Mapper 类的的成员变量MappedHost[] hosts 中。其主要逻辑是将 Context 对象，以及 Context 的子容器 Wrapper 对象，每一个都分别构建一个对应

一个系统 各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。可以指多个不同组件分布在网络上互相协作，比如说电商网站也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余，当数据修改时也需要通信来复制数据分布式最早出现的目地首先是解决单点问题，避免单点故障，然后解决了性能问题。分布式事务是相对本地事务而言的，对于本地事务，利用数据库本

方法的第一行代码先触发 CONFIGURE_START_EVENT 事件，以便执行 StandardServer 的 LifecycleListener 监听器，然后调用 setState 方法设置成 LifecycleBase 的 state 属性为 LifecycleState.STARTING。可以看出，StandardServe 的 startInternal 跟 initInternal

大模型 Agent 是基于大型语言模型并结合模块化规划、记忆和工具调用的自主决策系统，它能够根据最终目标把复杂任务拆分成子任务，调用 API、检索数据库或使用插件，再通过内部循环不断优化执行流程，基本不需要人在每一步都监督。传统 AI 是你问一个问题它回答一个问题，每次都是独立的，被动响应；而 Agent 有自己的规划能力，你给它一个复杂目标，它会自己把任务拆成多步，通过调工具、访问记忆、感知环境

多个任务之间有依赖关系怎么搞？

之前的 Agent 只是单纯的“听指令 -> 干活”，容易干着干着就忘了初衷，或者在复杂的任务中迷失方向。就像是给 Agent 装了一个“记事本”和“监工”。

在 代码的TOOLS变量里，我们会定义了工具长什么样（名字、参数）。// 遍历响应中的工具调用块// 提取命令// 执行 Bash// 构建工具结果LLM 不会真的“运行”代码，它只是输出一个符合这个格式的 JSON（比如而代码才是负责解析这个 JSON 并真的去执行。

这两个是Springboot中新增的扩展点，之所以将这两个扩展点放在一起，是因为它两个功能特性高度相似，不同的只是名字、扩展方法形参数类型、执行先后的一些小的不同。这两个接口触发时机为整个项目启动完毕后，自动执行。如果有多个，可以利用@Order来进行排序。CommandLineRunner和ApplicationRunner都有一个扩展方法run()，但是run()形参数类型不同；

每次都要主 Agent 分配任务太累。所以引入了：扫描看板，认领任务。队友自己扫描任务板并认领任务，无需主 Agent 逐个分配。

这里解决了 Agent 开发中的一个核心痛点：上下文窗口限制与知识广度的矛盾。这段代码引入了知识分层和懒加载的概念，这是解决 LLM 上下文限制（Context Window）的关键策略。核心思想：引入外部知识库系统，将专业知识和经验以结构化的"技能"文件形式存储，让Agent能够动态学习和复用专业知识，实现"知识外挂"。知识外化：将AI的专业知识存储在外部文件，而不是硬编码在代码中动态加载：程序