UserCentriX：用于智能空间的记忆增强型代理AI框架

关键词：代理AI，随身AI，多代理系统，大型语言模型，LLM内存管理，资源管理，计算连续体

1 引言

生成式AI（GenAI）和多代理系统的快速发展与集成，扩展了智能环境中用户交互、数据管理和资源配置的范围[1, 2, 3]。在这样的环境中，个性化和实时适应性对于确保用户满意度和能源效率至关重要。这促进了边缘智能的采用，通过将AI集成到计算连续体中以提高实时处理能力，从而增强计算连续体。这种方法涉及嵌入代理AI，用于主动规划、持续学习、推理和适应动态设置，在计算连续体中分布[4,5,6,7]。
配备Follow-Me AI [8]系统的智能环境旨在通过部署协商创建响应式个性化体验的AI代理，动态调整用户需求。个人代理嵌入用户的个人设备中，持续监控用户的偏好和计划。通过协商，智能建筑代理评估建筑当前的环境条件，并根据用户需求调整环境设置，同时优化建筑内的能源使用。
然而，该框架需要能够分析用户任务、管理个人数据并利用过去经验提取有用知识以提供更个性化帮助的个人LLM代理，通过管理个人上下文和偏好实现动态适应。此外，还需要根据用户上下文监测受控变量的变化。此外，当前发布/订阅（pub/sub）系统的静态决策机制通常缺乏处理此类多代理框架动态和资源密集型需求所需的灵活性和控制机制[9]。此外，随着更多基于LLM的代理出现，确保有效协调和通信变得越来越复杂[10, 11]。应对这些挑战需要自动扩展机制来管理资源密集型需求，以及自适应编排策略[12, 13]。此外，通过增强推理能力和迭代学习来改进多LLM代理系统对于有效构建这些系统至关重要[14]。
集中式系统通常依赖中央节点进行处理和决策并传递响应，由于这些中央节点造成的瓶颈，导致响应时间较慢。此外，集中式方法容易出现单点故障，尤其是在系统扩展时，可能影响稳定性和系统完整性[15]。相比之下，分布式系统将处理任务分散化，使代理能够独立做出本地决策，从而实现更快的响应和更高的本地任务效率。然而，如果没有定期和足够的信息交换，分布式系统往往缺乏全局视角。为了获得对环境的全面了解，分布式代理必须交换大量信息，导致通信开销增加和网络拥塞[15]。在设计能够有效处理局部自主性和全局情境感知的系统时，平衡这些权衡是至关重要的[16]。
鉴于这些考虑，UserCentrix框架将其架构专门设计为面向智能建筑中的用户中心服务。我们的主要贡献总结如下：

• 我们提出了一种混合自组织LLM代理框架，具有主动扩展和LLM内存管理功能，能够根据用户任务上下文动态调整其决策策略并分配推理时间预算。
• • 我们展示了决策策略的适应可以通过信息价值（VoI）驱动，这是框架推理和优先级过程中的指导因素，用于识别对用户最相关的内容。
• • 我们研究了用户上下文在引导决策以平衡速度和准确性等因素以及分配资源以提高输出质量方面的重要性。
• • 我们开发了一个个人LLM代理，设计为具有高级内存管理和自我评估能力的知识驱动型AI，以做出可靠决策和高效响应。
• • 我们实施了具有元推理能力和上下文学习的增强型记忆代理，允许根据VoI变化动态调整角色、关系和LLM调用次数。
• • 我们开发了合作推理网络，低级代理可以在其中协商合作条款，避免任务冲突，确保与多样化用户需求保持一致。
• • 我们开发了一个环境代理，通过带有时间启动（TTL）设置的消息队列跟踪正在进行的任务，确保控制命令在指定时间发送到控制系统和环境代理。
• • 我们考虑了任务进行期间的环境变化，使环境代理能够动态跟踪和调整环境以支持用户需求。
    本文其余部分结构如下：第2节回顾近期研究，突出其目标和局限性。第3节概述了智能空间的一般框架。第4节详细介绍了实施场景及其要求。第5节使用各种LLM和SLM分析实验结果。最后，第6节总结了研究发现和局限性，并讨论了未来研究的方向。

2 相关工作

2.1 边缘-云连续体中的LLM

在计算连续体中集成LLM代理代表了一个有前景的研究方向[4]，为更有效的应用铺平了道路。虽然传统的LLM通常依赖云计算，这种依赖往往导致响应性降低。相比之下，边缘计算通过直接在靠近数据源的边缘设备上部署LLM，提供了这些问题的实际解决方案。一些研究探讨了在边缘-云计算环境中部署LLM的可能性，并通过创新的边缘-云计算协作和优化策略解决了计算、延迟和资源管理方面的挑战，强调了LLM代理在整个边缘-云连续体中的潜力。
Shen等人[17]提出了一种云-边缘-客户端分层框架，使边缘AI系统能够自动组织、适应和优化以满足用户的多样化需求。通过利用LLM，该框架有效地协调边缘AI模型以解释用户意图并满足个性化需求。[18]中提出了一种用于LLM推理的协作边缘计算框架。该框架采用动态规划将模型划分为碎片并在跨越边缘设备和云服务器的分布式设备上部署。这种混合方法促进了边缘和云资源之间的协作。
Hao等人[19]提出了一种包含动态令牌级边缘-云协作的混合推理框架。该框架平衡了边缘和云资源的利用以提高推理性能。Yu等人[20]开发了Edge-LLM，一种去中心化的框架，专注于通过整合逐层压缩、自适应层调节和硬件调度策略优化边缘设备上的LLM适应性以提高计算效率。Ding等人[21]提出了一种优化服务放置策略的方法，考虑模型请求和相关的计算资源需求。他们的方法采用路由机制，根据查询的预测难度动态地将查询分配给小型或大型模型。[22]中提出了一个用于边缘智能高效部署LLM代理的云-边缘协作推理框架。这项工作重点在于优化服务放置和推理任务卸载策略，利用存储在云和边缘服务器上的缓存LLM。DLoRA [23]介绍了一种分布式PEFT框架。其中LLM在云服务器上执行，而PEFT模块则完全在用户设备内训练。

2.2 多代理系统结构设计

最近的一些方法为设计能有效利用多代理系统集体能力的系统结构提供了宝贵的见解。一些方法关注于分层架构。例如，[24]介绍了一种基于任务需求动态组织的分层结构。“混合代理”（MoA）架构[25]使用跨层组织的多个LLM，允许通过集体代理输入迭代改进输出。类似地，MegaAgent [26]采用一种动态创建和管理代理的分层结构以满足任务需求。
GraphAgent-Reasoner [27]通过集中管理将推理任务分配给多个代理，通过增加代理数量有效扩展以应对复杂任务。相反，MORPHAGENT [28]强调去中心化协调，基于任务需求和实时反馈进行结构化角色优化，促进适应性和对动态需求的响应。这些最新方法表明，采用分层协调和动态角色适应的多代理系统可以通过利用集体能力提高响应质量。

2.3 推理LLM代理

大型语言模型（LLM）研究的最新进展集中在通过增加每次问题生成的样本数[29]和根据提示进行适应来提高推理和响应质量，旨在更有效地利用LLM代理的思考能力。表1总结了相关工作。

表1：相关工作的总结。

名称	任务	算法	目标	局限性
云-边缘-客户端框架[17]	开发一个用于自主边缘AI系统的分层框架。	利用LLM自动组织、适应和优化边缘AI系统。	满足多样用户需求，尽量减少延迟。	- 对能源效率的关注有限 - 在高度动态环境中资源分配挑战。
EdgeShard[18]	设计一个用于高效LLM推理的协作边缘计算框架。	动态编程划分LLM。	最小化推理延迟并最大化吞吐量。	资源分配挑战。
混合推理框架[19]	提出一个混合推理框架用于LLM推理。	解码时间的动态令牌级交互，结合边缘和云资源进行推理。	提高推理性能	延迟改善有限。
Edge-LLM[20]	开发一个用于优化边缘设备上LLM适应性的框架。	逐层压缩（剪枝和量化）、自适应层调节（投票机制）和硬件调度。	- 缓解LLM的高计算和内存需求。- 在资源受限的边缘设备上优化性能。	缺乏对功耗的关注。
混合LLM[21]	优化LLM的服务放置策略。	考虑模型请求和计算资源需求，动态分配查询给小型或大型模型。	提高内存和存储效率。	无法充分满足对多样化LLM的真实世界需求。
缓存模型作为资源[22]	提出在云-边缘协作推理框架中的服务放置和推理任务卸载策略。	拍卖机制。	最小化边缘服务器和云的总推理成本。	服务于更高用户请求量的同时扩展性挑战。
Dbcu[23]	提出一个跨云和边缘设备协作训练LLM的框架。	分布式PEFT方法，其中LLM参数存储在云服务器中，而PEFT模块在边缘设备上微调。	- 减少边缘设备的计算负担。- 最小化通信开销。	- 资源受限网络中的挑战。 - 边缘设备上的计算资源限制。
Criticize-Reflect[24]	探索分层结构和领导角色如何影响多代理协调。	根据任务需求动态组织LLM。	实现通信效率和合作的持续改进。	缺乏大规模环境中更多代理的可扩展性。
Mixture-of-Agents[25]	利用跨层组织的多个LLM进行迭代输出改进。	代理通过周期共享和细化信息跨层。	通过利用不同LLM的独特优势提高响应质量，展示“协作性”。	依赖多个MoA层，增加计算开销。
MegaAgent[26]	使用分层结构根据任务需求动态创建和管理代理。	系统级并行化与集中协调下的自主任务拆分。	克服有限合作和可扩展性问题。	大规模MAS中的可扩展性问题和集中方法导致的单点故障。
GraphAgent-Reasoner[27]	多代理的协作架构，具有集中管理。	由“主LLM”管理的分布式、节点中心任务处理。	通过将推理任务分配给多个代理，有效扩展以应对复杂任务。	在更大、更复杂的现实世界推理场景中缺乏可扩展性。
MORPHAGENT[28]	启用去中心化多代理系统。	代理根据任务需求和反馈动态调整配置——角色、技能和策略。	促进适应性和响应性，解决复杂任务。	计算开销。
大型语言猴子[29]	增加每项任务生成的样本数以覆盖百分比（解决问题的比例）。	生成多个尝试而非依赖单一尝试解决方案。	提高LLM输出的准确性和可靠性。	验证器的能力可能限制此过程。
计算最优扩展[30]	根据提示难度调整测试期间的计算分配。	测试阶段更智能地使用计算资源。	提高推理期间的效率和性能。	验证者难以识别错误，限制了LLM的推理稳健性和通用性。 - 当Talker足够时没有最小化Reasoner使用的策略。 - 缺乏基于查询复杂性的自动Talker-Reasoner切换。 - 在实时应用中资源密集。 - 验证者可能限制此过程。
Talker-Reasoner Agent Model[31]	受Kahneman的“快思考与慢思考”启发，使用双代理框架。	结合实时互动（Talker）与多步问题解决（Reasoner）。	启用动态适应并提高效率。
协同验证[32]	在推理过程中探索多种解决方案路径。	整合“思维链”（CoT）和“思维程序”（PoT）方法。	提高LLM的推理准确性。
元推理提示[34]	动态选择每个任务最适合的推理方法。	根据任务需求从思维链、思维树、自我修正、回退提示等中选择。	提高推理效率和准确性。	缺乏针对复杂问题的相关方法集合。
OpenR[35]	使用开源框架关注中间推理步骤。	使用过程奖励模型（PRMs）进行强化学习以进行决策。	提高测试生成期间的推理能力。	数据集规模和多样性训练及使用中型模型测试的限制。
思维偏好优化[36]	为LLM配备在响应前思考的能力。	训练LLM生成并迭代优化内部思维。	为复杂指令生成深思熟虑且准确的输出。	缺乏使用更大规模模型和更多样化思维提示的探索。
Quiet-tTAR[37]	在测试生成过程中模拟内部思维过程。	使用REINFORCE学习生成每个标记的有用内部理由以指导预测。	更准确地预测未来测试，提高推理任务的能力。	每个标记都应用时计算强度大。
rStar[33]	提出协作问题解决方法。	使用蒙特卡罗树搜索的SLM生成推理路径，另一个SLM评估它们。	提高SLM的推理能力。	依赖SLM验证推理质量的能力。

其他策略侧重于实时适应推理技术以满足特定任务需求。例如，双重系统方法[31]通过基于任务需求的两种思维方式实现动态适应，而Liang等人[32]和Qi等人[33]探索生成多个推理路径以提高LLM推理能力。MetaReasoning Prompting (MRP) [34]通过动态选择每个任务最合适的推理方法进一步提高了推理能力。其他方法专注于优化文本生成过程中的推理步骤[35]和细化内部思维[36, 37]。表1总结了这些相关工作，概述了其目标、所用算法、主要任务和局限性。

3 UserCentrix框架

在本文中，我们提出了UserCentrix，这是一种专为智能空间设计的代理AI框架。该框架根据任务需求动态调整以适应用户上下文，并自主扩展计算资源。UserCentrix围绕双层架构构建，包括用户侧和建筑侧，每一侧都有不同的功能，以促进智能空间中的智能和高效交互，如图1所示。

图1：UserCentrix框架。

在用户侧，框架采用由LLM驱动的个性化知识AI代理[38]。这些代理作为智能助手，针对个别用户定制，利用个性化知识库来改善用户体验。这些以用户为中心的AI代理根据不断变化的用户偏好持续学习和适应。在建筑侧，框架集成了具备学习能力的记忆增强型元推理代理。这些代理负责通过处理来自各种数据集的数据并优化资源分配来管理更广泛的智能空间。

3.1 用户侧

UserCentrix框架中个人LLM驱动代理的有效性很大程度上取决于它们有效理解用户需求、跟踪用户以及动态适应新需求的能力。这种适应性不仅涉及理解用户的即时需求，还包括开发“重新思考”技术，以将现有知识应用于新情况以及记忆能力，从而实现高效的代理响应。在UserCentrix框架中，我们采用了具备记忆能力的知识型LLM代理，能够理解和分析用户偏好和计划。
这些代理维护内部知识表示，使他们能够使用基于案例的推理（CBR）[39]来评估和响应不断变化的用户需求。知识库作为一个存储库，保存有关以前用户交互的背景数据，包括计划、计划时间戳、计划类型和详细偏好。每个计划都以文本描述形式存储，以便在未来的上下文中重用。这个存储库通过利用过去的知识来指导当前行动，成为新场景中决策的指南，从而实现更准确的任务，如图1所示。
个人代理设计为初始时拥有空的动态存储库。它随着时间的推移持续填充，因为用户提交任务。此存储库存储有关过去执行的信息，使历史数据能够自动纳入未来的代理执行提示中。这确保了对新用户输入的连贯响应。系统中的用户任务包括配置智能建筑设置、预订会议室、订购餐食以及基于个人偏好和需求处理各种个性化请求。这种自适应功能增强了智能环境中的效率和用户体验。
当用户提交一个未指定偏好的计划时，代理利用其个人记忆通过比较当前计划类型与过去计划类型的嵌入来评估语义相似性。此外，它还比较计划的时间戳与先前任务的时间戳。如果检测到的高度相似度且时间差小于一小时，代理检索最近匹配的计划并自动应用相关的偏好。此过程使代理能够更新其知识库并根据知识和用户历史调整其响应，以确保情景感知的用户体验。更多细节请参见附录6中的个人代理提示。
此外，我们将自我评估功能集成到代理中，以增强其决策的可靠性。此功能允许代理评估其自身的响应，确保它们符合用户的需求和偏好。通过持续验证其输出，代理可以提供更准确和值得信赖的结果。这些评估功能依赖于比较个人代理的输出与用户的任务。在存在差异的情况下，代理检索过去任务的结果，并需提供检索原因。

3.2 智能建筑侧

UserCentrix框架在智能建筑中采用混合分层结构，将集中控制和分布式控制相结合以优化任务管理，如图1所示。该框架的核心是决策模块，由作为理性效用基础实体的高层代理组成。这些代理选择能最大化整体效用的动作，确保框架在保持响应性的同时根据情况的紧急程度优化精确度。这些动作包括子任务，由关键组件子任务执行模块执行，该模块由低层代理组成。这些代理负责生成命令以实施子任务，确保基于智能建筑系统的实时数据进行环境调整。这些命令由最终模块管理与分析模块管理，该模块将生成的命令存储在消息队列中，并根据预定义的时间表调度它们。此外，它在分配的时间段内持续检测已调整设置的变化，生成新命令以纠正任何意外的更改。我们在以下章节中提供这些模块的更详细说明。

3.2.1 决策模块：

该模块由高层代理组成。它首先启动分类代理，为用户任务创建专用的时间片，具体根据任务的紧迫性和根据时间敏感性确定的价值（VoI）。这些时间片使可以根据每个任务的具体要求优化的工作流程设计，允许低层代理之间有效的通信设置，并确定适当的推理深度级别。此代理使用工具提取当前时间，并将其与从存储库中检索到的计划时间进行比较。任务被分为两个紧迫级别：高紧迫级别（$\mathcal{U}\ge {\vartheta }_1$），如果计划时间和当前时间之间的差异小于两小时；低紧迫级别（$\mathcal{U}\le {\vartheta }_1$），如果差异为两小时或更多。分类代理的提示在附录6中提供。
在关键情况下，决策模块通过高紧迫代理（${\mathcal{A}}_{\text{High }}$）优先考虑速度而不是精度，启用更快但不那么详细的决策以满足实时需求。为这类任务分配额外时间可以提高精度，但紧迫性需要快速响应。此代理生成一条简化的推理路径，特别关注用户上下文的时间敏感深度。这条路径旨在通过减少步骤和最小化所需LLM调用来加速任务完成，同时仍达到可接受的任务完成水平。为此，代理通过减少子任务简化任务，优先考虑在最短时间内产生最大影响的行为以加快决策，并减少相互依赖以进一步加速任务执行。当两个或更多LLM调用可以独立处理时，它们被赋予相同的等级以并行执行，将它们组合在一起在同一任务等级内同时处理。这种方法增强了时间敏感场景中的响应性，确保及时且有效地处理关键任务。附录6中提供了高紧迫代理的提示。
相比之下，在不太关键的时期，决策模块可以通过低紧迫代理（${\mathcal{A}}_{\text{Low }}$）分配更多时间来细化决策，允许更准确和资源密集的计算，从而提高整体决策质量。这些代理作为元推理实体运作，采用“思考关于思考”的方法进行决策。它们批判性地评估决策过程本身，旨在确定准确度、速度和效率之间的最佳平衡。它首先生成一组多样化的初始推理路径，每条路径在复杂性、深度和关注的不同决策标准上有所不同。这些路径代表多个潜在解决方案，将任务分解为详细的子任务，对应于逻辑步骤，包括LLM调用。
这些子任务反映了独特的视角或焦点，每个都包含特定的标准或优先事项。这些优先事项可能涉及环境分析和探索与请求相关的资源的实时状态，例如房间可用性、餐食选项和环境条件（例如温度适宜性和照明水平）。此外，另一标准可能是优先考虑条件与用户指定偏好相匹配或最接近的资源。
另一个标准可以利用自然和智能调整，例如建议打开窗帘或百叶窗以增强自然光，如果用户偏爱自然光的话。

这种多样性使得能够广泛评估潜在的推理策略、决策路径和资源分配选择。低紧迫代理的提示在附录6中提供。低紧迫代理作为一个记忆增强型实体，通过迭代学习过程运行。在生成潜在解决方案后，解决方案和原始任务一起存储在外存中。同时，解决方案被发送给评估代理（${\mathcal{A}}_{\text{Evalu }}$），后者对其进行评估并选择最具逻辑依据的最佳解决方案。如果评估代理确定没有任何路径符合效率和成功标准，则提供可行的见解作为评论以改进未来的解决方案。对于新任务，在低紧迫代理生成新的潜在解决方案之前，它首先测量当前任务嵌入与存储在内存中的先前任务嵌入之间的语义相似性。如果找到高度相似的任务，则检索其最佳解决方案及其理由和评论，并动态纳入低紧迫代理的提示中作为提示，以指导新解决方案的生成。

在学习循环内，通过回忆并根据上下文相似性动态注入这些过去的解决方案，代理完善了其潜在解决方案生成过程。这种迭代反馈循环允许低紧迫代理通过使用上下文学习来融入其最佳之前的解决方案，从而持续改进。通过这一过程，它还学会了导致更好结果的关键因素，使其能够随着时间的推移生成越来越有效的解决方案。

最终的潜在解决方案将由帕累托分析器评估，该分析器使用多个适应度函数来优化决策。这些函数包括评估语义相似性、测量LLM输出的精确性以及分析与LLM调用相关的成本。这些函数评估是否为提高精度所需的额外计算资源和延长推理时间在决策质量上提供了显著效用和价值。

我们选择了语义相似性，因为它反映了解决方案在多大程度上满足了用户的任务。此外，我们选择了精确性，因为它衡量生成响应与原始任务之间的重叠程度，指示它们之间的匹配程度。同时，LLM调用使用成本衡量资源消耗的效率，通过LLM调用次数量化。每次额外调用都会增加总体时间和计算成本，较高的调用次数通常表明更大的资源使用（例如，时间和计算成本）。我们根据任务解决方案的最大调用次数（$N_{\max }$）和调用次数（$N_{\text{calls }}$）计算成本指标。

$$\text{ LLM Call Usage Cost }=1-\exp \left(-\frac{N\text{ calls }}{N\max }\right)$$

公式(1)创建了一个衰减效果，随着LLM调用次数的增加，成本非线性增长。对于少量调用，成本缓慢增加，但当调用次数接近最大值时，成本急剧上升。这鼓励相对于可用限制最小化资源消耗。为了识别最佳解决方案，我们应用了帕累托优势，旨在最小化资源成本，同时最大化语义相似性($\mathcal{S}$)和精确度得分。

$$\text{ Pareto }=\min (LLMCallU\text{ sageCost }),\max (\mathcal{S}),\max (\text{ Precision })$$

这种方法使我们能够在准确性和资源效率之间实现最有效的权衡。通过评估准确性和资源使用之间的权衡，代理根据预期效用动态分配计算资源。通过根据帕累托效率对解决方案进行排名，代理识别出在选定标准方面占主导地位的最强解决方案。最终决策将包括必须由低层代理执行的解决方案。子任务的数量决定了单个低层代理是否可以独立管理任务，或者是否需要多个低层代理协作以处理需要深入推理的更复杂任务。

算法1的时间复杂度

估计AI代理的时间复杂度可能会很困难，但我们通过基于算法结构的步骤计数方法来处理它。该算法的主要时间复杂度是由用户任务数$(m)$和每个任务执行的操作数驱动的。对于每个任务，嵌入计算是一个关键操作，复杂度为$O(d)$，其中$d$表示嵌入维度。确定任务是高还是低紧迫性需要常数时间$O(1)$，不会显著影响整体复杂度。高紧迫性任务具有常数复杂度，因为它们仅涉及快速解决方案生成而不进行额外操作。然而，低紧迫性任务生成$n$个子任务解决方案，每个子任务解决方案执行语义相似性计算（使用llama-index），复杂度为$O(s)$，其中$s$取决于子任务解决方案的嵌入维度。精确性计算、LLM调用使用成本计算和帕累托优化的附加操作每个都需要常数时间$O(1)$。因此，$n$个子任务解决方案的时间复杂度可以表示为$O(n\times s)$。内存召回和注入

算法1 UserCentrix决策模块
需要：用户任务， ( T = { 1 : m } ∀ T i = D i ∃ D i ∈ D ) (T=\{1: m\} \forall T_{i}=\mathcal{D}_{i} \exists \mathcal{D}_{i} \in \mathcal{D}) (T={1:m}∀Ti​=Di​∃Di​∈D) 和 ( i ∈ { 1 : m } ) (i \in\{1: m\}) (i∈{1:m})
确保： ( T = { T 1 , T 2 , … , T n } ) (\mathcal{T}=\left\{\mathcal{T}_{1}, \mathcal{T}_{2}, \ldots, \mathcal{T}_{n}\right\} \quad) (T={T1​,T2​,…,Tn​}) 其中每个 $({\mathcal{T}}_i)$ 是一个子任务 ( i ∈ { 1 , 2 , … , n } ) (\quad i \in\{1,2, \ldots, n\}) (i∈{1,2,…,n}).
对每个 $(T_i\in T)$ do
分类 $(={\mathcal{D}}_i-t▹t)$ 是当前时间。
如果 (Classify $(\le 0)$ ) then
( T = T − { T i } ▹ T i ) (T=T-\left\{T_{i}\right\} \quad \triangleright T_{i}) (T=T−{Ti​}▹Ti​) 从任务列表中删除。
else if (Classify $(\ge {\vartheta }_1)$ ) then $(▹{\vartheta }_1)$ 是阈值。
$({\mathcal{U}}_i=0;▹)$ 低紧迫级别
$({\mathcal{A}}_{\text{Low }}\leftarrow T_i▹)$ 将任务发送给低紧迫代理
$(M_{\text{Low }}\leftarrow )$ RecallMemory $(\left({\mathcal{A}}_{\text{Low }}\right))$
$({\mathbf{E}}_{\text{new }}\leftarrow )$ Embed_all-MiniLM-L6-v2 $(\left({\mathcal{T}}_i\right)▹)$ 计算新解决方案的嵌入
$({\mathbf{E}}_{\text{past }}\leftarrow )$ Embed_all-MiniLM-L6-v2 $(\left({\mathcal{M}}_{\text{Low }}\right)▹)$ 计算过去解决方案的嵌入
Similarity $(\left({\mathbf{E}}_{\text{new }},{\mathbf{E}}_{\text{past }}\right)\leftarrow \frac{{\mathbf{E}}_{\text{neg }}{\mathbf{E}}_{\text{last }}}{\Vert {\mathbf{E}}_{\text{new }}\Vert \Vert {\mathbf{E}}_{\text{new }}\Vert }▹)$ 计算新旧解决方案嵌入之间的相似性
如果 Similarity $(\left({\mathbf{E}}_{\text{new }},{\mathbf{E}}_{\text{past }}\right)\le {\vartheta }_2)$ then $(▹{\vartheta }_2=0.7)$ 在我们的工作中
为 $({\mathcal{T}}_i)$ 生成 $(n)$ 个潜在解决方案 $(▹)$ 从头开始生成解决方案
else
使用 $({\mathcal{A}}_{\text{Low }})$ 检索解决方案 $({\mathcal{E}}_i)$ 并附带理由 $({\mathcal{R}}_i)$ 和因素 $({\mathcal{F}}_i)$ 注入到代理提示中
使用 $({\mathcal{E}}_i\&{\mathcal{R}}_i\&{\mathcal{F}}_i)$ 为 $({\mathcal{T}}_i)$ 生成 $(n)$ 个潜在解决方案 $(▹)$ 利用评估代理提供的高相似任务的响应、理由和因素生成解决方案
end if
对每个 $({\mathcal{T}}_i)$ do
计算语义相似性 $(\left(\mathcal{S}\left({\mathcal{T}}_i\right)\right))$ : 使用 llama-index
精确性 $(\left(\mathcal{T}_{i}\right)=\frac{T P}{T P+F P}
LLMCallUsageCost $(\left({\mathcal{T}}_i\right)=1-\exp \left(-\frac{N_{\text{calls }}}{N_{\text{max }}}\right))$
$(\mathrm{Pareto}\left({\mathcal{T}}_i\right)=\min \left(LLMCallU\mathrm{sage}Cost\left({\mathcal{T}}_i\right)\right),\max \left(\mathcal{S}\left({\mathcal{T}}_i\right)\right),\max \left(\mathrm{Precision}\left({\mathcal{T}}_i\right)\right))$
$({\mathcal{E}}_i,{\mathcal{R}}_i,{\mathcal{F}}_i\leftarrow {\mathcal{A}}_{\text{Evalu }}\left({\mathcal{T}}_i\right)▹)$ 评估代理选择最有逻辑依据的最佳解决方案并给出理由和
因素
$(\mathcal{M}\leftarrow \mathcal{M}\cup {\mathcal{E}}_i,{\mathcal{R}}_i,{\mathcal{F}}_i▹)$ 将评估代理的响应注入内存
$(\mathcal{M}\leftarrow \mathcal{M}\cup {\mathcal{T}}_i▹)$ 将任务注入内存
end for
else
$({\mathcal{U}}_i=1;▹)$ 高紧迫级别
$({\mathcal{A}}_{\text{High }}\leftarrow T_i▹)$ 将任务发送给高紧迫代理
$({\mathcal{A}}_{\text{High }})$ 为任务 $(T_i)$ 快速生成解决方案 $({\mathcal{T}}_i)$
end if
end for
返回 $(\mathcal{T})$

操作依赖于内存大小即$k$，表达为$O(k)$至复杂度。总体而言，算法1的时间复杂度可以表示为$O(m\times (k+d+n\times s))$。

为了澄清UserCentrix决策模块的工作流程，我们展示了算法1。对于用户提供的每个任务$T$，分类代理通过计算任务截止时间${\mathcal{D}}_i$与当前时间$t$的差值（第1和第2行）来确定其紧迫级别。如果得出的分类评分低于零，表示任务不再相关，从任务列表中删除（第3和第4行）。否则，任务根据预定义阈值${\vartheta }_1$进一步分类为低或高紧迫性（第5-6行和第27-28行）。低紧迫性任务被分配给低紧迫性代理${\mathcal{A}}_{\text{Low }}$（第7行），该代理检索相关过去记忆并使用MiniLM计算当前和先前解决方案的语义嵌入（第8-11行）。然后计算新旧嵌入之间的相似分数。如果相似分数低于指定阈值${\vartheta }_2$，系统继续生成$n$个潜在新解决方案（第12和13行）；否则，它检索适合的现有解决方案并附带评估代理提供的理由和因素（第15行），并利用它们作为提示生成潜在解决方案（第16行）。随后，每个解决方案分别根据语义相似性（使用LlamaIndex）、精确性和使用成本进行评估（第18-21行）。采用帕累托优化方法选择最优化解决方案${\mathcal{E}}_i$（第22行）。评估代理负责评估生成的解决方案并选择最合适的解决方案及其逻辑推理（第23行），并将相应的任务注入内存模块$\mathcal{M}$（第24和25行）。相反，高紧迫性任务${\mathcal{A}}_{\text{High }}$被定向到高紧迫性代理，该代理快速生成适合解决方案以满足紧张期限（第29和30行）。模块通过返回最终更新的子任务集${\mathcal{T}}_i$结束（第33行）。

3.2.2 子任务执行模块

在为每个任务选择解决方案后，子任务执行模块形成低层代理组以执行子任务并生成命令以调整智能建筑设置。这些组并行操作以提高决策速度，同时考虑每个任务的执行时间。在任务间无执行冲突的情况下，每个组的低层代理根据执行顺序的层次结构生成命令。组内代理在各层级之间共享响应。如果并行子任务执行，任务可以同时访问先前任务的响应。

在执行冲突出现时，我们建立了一个分布式设置的元协作推理网络。在此网络中，来自不同组的代理并行协商和工作，共享中间推理结果以避免冲突，例如同时选择同一房间。这种协作方法通过代理间的协作问题解决提高了响应的速度和准确性。

算法2的时间复杂度

在算法2中，我们执行代理生成、数据集选择、任务执行和解决方案聚合。我们的算法基于子任务解决方案使用$k$个代理，初始化具有线性复杂度$O(k)$。对于每个代理，我们需要从一组数据集中选择最合适的数据集（在我们的案例中假设$\Delta$个数据集）。此选择过程对于每个代理需要$O(\Delta )$时间，因为我们需要评估每个数据集的兼容性。一旦选择了数据集，执行步骤（Execute $\left(\mathcal{T}i,D_i\right)$）处理选定的数据集。让我们表示最大数据集的大小为$\eta$。在最坏情况下，每个代理的执行时间将是$O(\eta )$。这些操作针对$k$个代理执行。将解决方案聚合到$\mathcal{C}$中每代理需要恒定时间$O(1)$。因此，算法2的整体时间复杂度可以表示为$O(k\times (\Delta +\eta ))$。
算法2展示了子任务执行模块，该模块旨在使用相应的数据集$D$执行一组子任务解决方案 T = { 1 : k } \mathcal{T}=\{1: k\} T={1:k}。执行过程从创建$k$个低层代理开始，每个代理被分配一个特定的子任务${\mathcal{T}}_i$（第1行）。对于每个子任务${\mathcal{T}}_i$，相应的代理检索满足任务要求的兼容数据集$D$（第2和第3行）以执行子任务（第4行）。生成的命令被收集并聚合到最终命令集$\mathcal{C}$中（第5行），在执行阶段完成后返回（第7行）。

3.2.3 管理与分析模块

管理与分析模块包括一个消息队列，用于存储生成的命令，包括支持时间启动（TTL）设置。它聚合所有由低层代理生成的命令。基于计划任务时间，消息队列将这些命令调度到控制系统，管理执行器和环境代理。环境代理设计为跟踪正在进行的任务并确保它们符合用户偏好。。它比较用户为任务指定的要求与已预订资源的当前状态。如果检测到任何变化，代理生成警报命令并将其发送到控制系统。这种方法通过主动解决任务执行期间可能出现的问题，确保用户满意度和体验质量保持高水平。环境代理的提示在附录6中提供。

图2：UserCentrix框架中的用户任务处理。

3.3 使用案例

3.3.1 用户任务处理场景：

如图2所示，个人代理配备了一个外部个人内存作为存储库。它最初为空，并随着用户提交任务逐渐填充。此存储库保留有关过去任务的信息，包括用户偏好。在此场景中，用户之前提交了两个任务，每个任务都有其自己的偏好存储在存储库中。当用户提交一个新计划而未指定偏好时，代理评估新计划类型嵌入与个人内存中存储的嵌入之间的语义相似性。它还比较计划的时间戳与先前任务的时间戳。如果时间差小于一小时且相似度评分超过0.5，则代理从个人内存中最近匹配的条目中检索偏好。然后代理更新新任务以包含这些偏好，允许其根据用户历史记录调整响应。此过程确保情景感知体验，实现更个性化和相关的任务更新。

3.3.2 高紧迫场景：

图3说明了框架建筑模块的工作流程，从分类代理开始，该代理确定提交用户任务的紧迫级别。在此场景中，由于当前时间和任务时间之间的时间差小于两小时，代理将任务分类为高紧迫性。然后将任务转发给高紧迫代理，该代理负责生成具有最少子任务的时间敏感解决方案。此代理识别需要两个单独LLM调用的必要性，每个对应于不同的子任务。这些子任务被组织成具有两个层次的分层结构，允许高效的任务分解和执行。
接下来，子任务执行模块被激活，生成两个代理——每个子任务一个。每个代理执行其分配的子任务，发出命令以预订特定房间并根据用户需求调整环境设置。代理使用智能校园数据集以确保准确配置。生成的命令被放置在管理与分析模块中的消息队列中，然后转发到执行器进行执行。此外，环境代理在预订期间持续监控用户偏好与智能校园数据集之间的任何变化。如果检测到变化，它们生成新命令以相应地调整环境，确保实时适应用户需求。

3.3.3 低紧迫场景：

图4说明了框架建筑模块的工作流程，从分类代理开始，该代理确定提交用户任务的紧迫级别。在此场景中，由于当前时间和任务时间之间的时间差大于两小时，代理将任务分类为低紧迫性。然后将任务转发给低紧迫代理，该代理负责生成智能建筑中每个任务的所有可能推理解决方案，例如预订房间、安排餐食或调整环境设置，同时利用存储在记忆中最佳解决方案的理由和影响选择解决方案的因素以及改进未来解决方案的见解。在生成解决方案之前，低紧迫代理检索记忆以检查先前存储的任务。如果找到任何任务，它计算当前计划嵌入与

图3：UserCentrix框架中的高紧迫工作流。
过去计划嵌入之间的相似性。如果发现高度相似的任务，则将相应的解决方案以及评估代理提供的理由和评论注入提示作为生成新解决方案的提示。

在基于不同标准生成多个解决方案后，评估过程开始。此过程涉及两个关键组件：帕累托分析器和评估代理。帕累托分析器应用适合度函数到每个解决方案并计算相应值。目标是识别出在最大语义相似性、最大精确度得分和最小成本方面表现最佳的解决方案。与此同时，评估代理选择最佳解决方案并将其存储在记忆中，连同影响决策的理由和因素。一旦帕累托分析器完成评估，它将解决方案转发给子任务执行模块，该模块根据子任务数量生成三个代理。每个代理执行其分配的子任务，发出命令以预订特定房间并根据用户需求调整环境设置，使用智能校园数据集。这些生成的命令被放置在管理与分析模块内的消息队列中，然后转发到执行器进行执行。此外，环境代理在预订期间持续监控用户偏好与智能校园数据集之间的任何变化。如果检测到变化，它们生成新命令以相应地调整环境，确保实时适应用户需求。

4 实施

在实践中，我们在一台配备了Intel® Core™ i5-1135G7 CPU的台式机上执行所有实验，假设其为边缘设备，并同时在Google Colab上使用Intel® Xeon® CPU作为云设备进行实验。我们使用奥卢大学作为实验环境，利用奥卢大学智能校园数据集[40]中的数据。具体而言，

图4：UserCentrix框架中的低紧迫工作流。
我们关注配备了Elsys ERS CO2传感器的会议室，这些传感器提供全面的室内环境测量，包括运动、温度和光照强度。这些传感器在部署前经过校准，其数据质量经过广泛验证以确保可靠性和准确性[41]。选定的房间包括：TS501, PK258, PK265, PK306, PK254, PK266, PK261, PK253, PK267, PK262, PK309, PK268, PK263, PK308和PK264。除了选定的会议室之外，由于我们的目标是使低级代理能够识别与用户偏好（由房间温度、灯光状态和可用性定义）匹配的房间，我们生成了一个合成数据集。这个合成数据集包括基于典型工作时间的房间可用性，以及温度和光照强度，将由低级代理用于房间选择，并由环境代理用于持续的环境变化跟踪。
实验中实施的所有代理都是使用LangChain构建的。我们开发了内存作为一个自定义存储库类型使用LangChain ${}^1$。
对于嵌入和相似性，我们使用all-MiniLM-L6-v2模型 ${}^2$，该模型专为语义文本相似性（STS）任务设计。它创建句子的嵌入（向量表示），以捕捉其语义意义。这些嵌入允许模型计算文本之间的相似度分数。
为了使评估代理能够评估低紧迫代理生成的潜在解决方案并选择最优化的一个，我们采用ol模型 ${}^3$，由于其先进的推理能力，确保所选解决方案与原始任务目标最为一致。我们使用paretoset 1.2.4库 ${}^4$ 实现帕累托优势。对于适合度函数，语义相似性使用LlamaIndex框架 ${}^5$ 进行评估，而精确性则使用ragas框架 ${}^6$ 进行评估。
我们选择了能够全面评估各种大型和小型语言模型推理能力的模型。LLM在促进以用户为中心的交互和动态扩展计算资源方面可以发挥关键作用。然而，对SLM或设备上的LLM日益关注，突显了其在减少延迟和提供个性化用户体验方面的潜力。这些模型通常参数较少，针对边缘设备部署进行了优化，实现了诸如智能环境和实时应用等响应技术。在我们的实验中，我们纳入了以下语言模型：

• Gemini 1.5 Flash (8B)，一种轻量级模型，由Google DeepMind开发 ${}^7$。该模型因其在长上下文推理方面的先进能力而被选中，并针对低延迟性能和增强的代理交互效率进行了优化。
• • GPT-4o ${}^8$，由OpenAI开发的一种大型模型。由于其在实时分析方面的先进推理能力，使其非常适合实际应用。
• • Claude 3.5 Sonnet $(8.03\mathrm{B}{)}^9$，由Anthropic开发，以其强大的代理能力而闻名。
• • Command-r7b $(8.03\mathrm{B}{)}^{10}$，Cohere R系列中最小的模型，具备强大的代理能力，适用于多种用例，包括在边缘设备上的部署。
• • Mistral $(7.25\mathrm{B}{)}^{11}$，一种由Mistral AI开发的开源模型，具有先进的推理能力和快速推理速度。
• • IBM的Granite模型 ${}^{12}$，其中granite3.1-MoE (3B)采用了专家混合（MoE）架构，特别适合低延迟应用。
    由于文献中没有针对相同问题同时考虑UserCentrix框架的具体要求和目标的研究，我们的主要目标是通过分析耗时、CPU使用率和内存利用率，以及我们框架中各个模块的相关指标来评估代理的响应。此外，我们将不同代理在所有模块中生成的响应准确性与基线模型进行比较，以衡量改进或偏差。更多细节如下：

$({}^1)$ https://www.langchain.com/
$({}^2)$ https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2
$({}^3)$ https://openai.com/ol/
$({}^4)$ https://pypi.org/project/paretoset/
$({}^5)$ https://docs.llamaindex.ai/en/stable/
$({}^6)$ https://docs.ragas.io/en/latest/concepts/metrics/
$({}^7)$ https://deepmind.google/technologies/gemini/
$({}^8)$ https://platform.openai.com/docs/models
$({}^9)$ https://www.anthropic.com/news/claude-3-5-sonnet
$({}^{10})$ https://cohere.com/blog/conmand-r7b
$({}^{11})$ https://mistral.ai/
$({}^{12})$ https://www.ibm.com/granite/

• 用户任务处理模块：我们评估个人代理在云服务器和边缘设备上执行用户任务时的响应，测量耗时、CPU使用率和内存利用率，并跨各种模型进行比较。此外，我们在两种场景下评估准确性：当记忆为空和满时，同时确定代理是否从记忆中检索相关信息或在无记忆访问的情况下运行。此评估基于我们纳入代理提示6中的主要评估模板，可从${}^{13}$获得。

- 决策模块：

1. 分类代理性能：我们评估分类代理在确定不同任务的紧迫级别为<高>或<低>时的响应，当在云服务器和边缘设备上执行时，测量耗时、CPU使用率和内存利用率，并跨各种模型进行比较。此外，我们通过将代理在各种模型下的响应与其在o1模型下的响应进行比较，以精度模式衡量事实正确性。
2. 2. 高紧迫和低紧迫代理性能：我们评估高紧迫和低紧迫代理在生成解决方案时的性能，当在云服务器和边缘设备上执行时，测量耗时、CPU使用率和内存利用率，并跨各种模型进行比较。
3. 3. 低紧迫代理性能：我们验证Pareto选择的最佳解决方案是否与o1模型选择的首选要求一致。此外，我们通过使用o1模型的响应进行情境学习循环来评估代理的响应改进。

• 子任务执行模块：我们评估低级代理在云服务器和边缘设备上部署时执行子任务的性能，测量耗时、CPU使用率和内存利用率，并跨各种模型进行比较。
• • 管理和分析模块：我们评估环境代理在检测变化和生成命令时的响应，当在云服务器和边缘设备上执行时，测量耗时、CPU使用率和内存利用率，并跨各种模型进行比较。此外，我们通过回忆模式衡量事实正确性，以评估环境代理的响应与O1模型的响应在生成正确命令时的一致性。
    此评估框架确保对模型性能在效率、准确性和决策质量方面的全面评估。
    我们利用RAGAS中的事实正确性度量 ${}^{14}$，结合GPT-4o。此度量评估生成响应的事实准确性和与参考的一致性，范围从0到1 ，其中较高值表示更优性能。精确度使用公式(3)计算：

$$\text{ Precision }=\frac{TP}{TP+FP}$$

同时，召回率使用公式(4)计算：

$$\text{ Recall }=\frac{TP}{TP+FN}$$

其中真正例（TP）是响应中存在于参考中的声明数，假正例（FP）是响应中不存在于参考中的声明数，假负例（FN）是参考中不存在于响应中的声明数。
我们选择精确度和召回率作为评估指标，因为它们与我们框架中参考和响应的性质相符。

• 分类代理：精确度用于确定与参考不同的响应比例，区分高低变化输出。
• • 环境代理：召回率被选择用来评估命令（如增加或减少）、变化程度和其他关键特征的准确性。由于相对于参考的响应完整覆盖至关重要，召回率确保了正确性和一致性得到彻底评估。

${}^{13}$ https://github.com/langchain-ai/langchain/blob/master/libs/langchain/langchain/evaluation/ criteria/prompt.py
${}^{14}$ https://docs.ragas.io/en/stable/
表2：个人代理性能评估。

模型名称	空白				内存状态				占用		边缘设备
	耗时	云服务器	内存	耗时	边缘设备	内存	耗时	云服务器	内存	耗时	边缘设备	内存	准确性
	时间	CPU	时间		CPU	CPU	时间	CPU	时间	时间	CPU
Geminü-1.5 Bush	10.034	5.50%	8.50%	15.601	5.40%	15.200	10.105	5.105	1.70%	1.60%	5.1218	21.80%	43.80%
command-e7fe	78.8173	14.68%	20.80%	353.6496	58.10%	67.70%	61.3708	26.90%	20.70%	331.3826	50.80%	67.30%	$✓$
Claude 3.5 Sonnet	97.728	18.90%	32.60%	369.9368	56.90%	65.90%	86.7674	40.10%	19.80%	276.9919	56.20%	65.50%	$✓$
Mistral	86.8284	15.80%	18.00%	381.648	59.90%	63.20%	65.9482	27.40%	17.90%	313.3207	52.50%	63.30%	$✓$
granule3.3-MoE	20.6631	12.50%	8.00%	43.1752	41.40%	43.50%	20.6424	20.00%	9.00%	61.2677	45.80%	43.40%	$✓$
Ggt-do	6.708	3.60%	9.10%	5.738	6.20%	41.80%	10.4106	2.10%	9.10%	7.11	4.10%	41.70%	$✓$

5 结果分析

在本节中，我们展示了框架在各个模块中的综合性能评估。分析旨在通过多种评估标准评估所提出方法的有效性、效率和稳健性。

5.1 个人代理性能评估

图5：个人代理性能评估。
对不同模型下的个人代理性能评估显示，在执行效率、资源利用和准确性方面存在显著差异，特别是在内存占用时检索相关信息的能力上，如表2总结。图5显示GPT-4o始终优于其他模型，显示出最短的耗时和最低的CPU使用率，无论是在云端还是边缘设备上，展示其在处理用户任务方面的卓越效率。此外，GPT-4o和Gemini-1.5 flash在内存使用方面维持较低水平，使其非常适合在低内存环境中部署。相比之下，Claude 3.5 Sonnet和Mistral表现出
表3：分类代理性能评估。

模型名称	云服务器			边缘设备			准确性
	耗时	CPU	内存	耗时	CPU	内存
	时间	使用率	使用率	时间	使用率	使用率
Gemini-1.5 flash	5.3925	23.60%	14.40%	2.4466	7.90%	31.30%	1
command-r7b	119.7979	6.80%	16.00%	127.8999	62.40%	71.90%	0.75
Claude 3.5 Sonnet	119.2964	33.30%	15.20%	118.6518	58.50%	70.50%	0.75
Mistral	88.08312	5.00%	13.50%	143.5072	61.20%	66.30%	1
granite3.1-MoE	61.7082	23.30%	32.40%	16.4528	59.30%	55.80%	0.5
Gpt-4o	6.33347	9.80%	12.60%	8.671	8.70%	42.20%	1

图6：分类代理性能评估。
显著更高的CPU和内存消耗，这在资源受限的边缘设备上部署时提出了挑战，可能会阻碍实时处理。
当内存被占用时，代理应检索相关存储信息而不是重新处理任务，这是提高用户体验的关键因素。GPT-4o和Gemini-1.5 flash有效检索存储信息，确保最优性能并最大限度减少冗余计算。此外，Claude 3.5 Sonnet、Mistral和command-r7b未能检索内存中存储的信息，导致效率低下、计算开销增加和性能下降，如表2所示。

5.2 分类代理性能评估

不同模型下分类代理性能的评估展示了在将任务分类为高和低紧迫级别时的巨大差异。表3总结的结果突出了在与o1模型基准对比时，不同模型在耗时、CPU使用率、内存消耗和事实正确性方面的关键差异。
表4：低紧迫和高紧迫代理性能评估。

模型名称	$\begin{array}{c}\text{ 耗时 }\\ \text{ 时间 }\end{array}$		云服务器		内存使用率		耗时		边缘设备		内存使用率
			CPU使用率						CPU使用率
			紧迫级别						紧迫级别
	低	高	低	高	低	高	低	高	低	高	低	高
Gemini-1.5 flash	10.756	4.339	1.40%	1.50%	6.60%	6.70%	14.1069	4.8304	7.60%	8.40%	31.00%	33.40%
command-e7fe	94.521	53.97	40.30%	31.80%	19.90%	19.90%	3601.6761	295.8871	15.20%	60.80%	36.30%	71.70%
Claude 3.5 Sonnet	149.222	74.278	8.30%	24%	18.30%	18.30%	3058.6028	514.0639	24.40%	61.50%	45.20%	70.10%
Mistral	151.503	47.847	41.60%	17.20%	17.40%	18.10%	787.05659	316.2107	63.00%	58.10%	53.80%	53.80%
granule3.3-MoE	49.2456	17.9563	36.70%	17.60%	9.10%	9.10%	80.8196	47.7772	61.90%	60.80%	65.50%	42.50%
Gpt-4o	25.938	6.171	1.60%	1.40%	17.80%	6.80%	22.227	10.1647	13.30%	9.20%	41.70%	41.60%

图7：边缘设备上低紧迫和高紧迫代理性能评估。

图6显示GPT-4o和Gemini-1.5 flash是最高效的模型，实现了执行速度、低资源使用和高分类准确性的最佳平衡，使其非常适合实时部署。这些模型在云端和边缘设备上显示出最短的耗时和最低的内存消耗，突出其在执行分类任务时以最少计算开销的有效性。

相比之下，Claude 3.5 Sonnet、Mistral和command-r7b表现出显著更高的耗时和增加的内存使用，特别是在边缘设备上。这种升高的资源消耗可能在实时分类中引入延迟，使其不太适合对延迟敏感的应用。此外，granite3.1-MoE的低准确性强调了其在需要精确性的高风险分类任务中的局限性。

5.3 低紧迫和高紧迫代理性能评估

对不同模型下的低紧迫和高紧迫代理性能评估显示，在生成解决方案时，耗时、CPU使用率和内存消耗方面存在显著差异。如表4所示，高紧迫

图8：云端低紧迫和高紧迫代理性能评估。
表5：低级代理性能评估和帕累托分析。

实验								云服务器			边缘设备
模型名称	紧迫 级别	$\begin{array}{rl}& \text{ LLM }\\ & \text{ 调用 }\\ & \text{ 次数 }\end{array}$	层次深度计数	相似性分数	度量 LLM 使用 成本	精确 分数	耗时	CPU 使用率	内存使用率	耗时	CPU 使用率	内存 使用率
Gemini-1.5 flash	低	3	3	0.8704	0.5276	0.3636	23.87156	6.10%	13.90%	3.67961	10.40%	51.60%
		4	3	0.8659	0.6321	0.4091	15.7927	4.80%	14.00%	3.8502	7.00%	36.70%
	高	3	3	0.8602	0.5276	0.4091	17.1799	4.60%	14.00%	3.5883	8.80%	36.40%
		2	2	0.9039	-	0.3636	3.7146	5.60%	14.00%	3.439471	15.50%	36.30%
command-r7b	低	2	2	0.8913	0.6321	0.4545	498.1659	30.00%	15.60%	625.2602	64.00%	73.10%
	低	2	2	0.8860	0.6321	0.2727	492.8408	49.10%	15.70%	843.0399	60.80%	72.00%
	高	2	2	0.9183	-	0.5455	676.5058	49.80%	15.60%	616.2926	60.50%	67.60%
Claude 3.5 Sonnet	低	5	5	0.8702	0.6321	0.3636	1689.107	42.70%	15.30%	2265.092	59.10%	67.70%
		4	4	0.8488	0.5507	0.2727	2034.623	51.10%	14.90%	1621.683	57.50%	68.00%
	高	4	4	0.8421	0.5507	0.2727	1569.989	52.60%	14.90%	1869.202	57.80%	69.10%
		2	2	0.8809	-	0.3636	643.4445	50.00%	14.40%	666.3432	57.50%	68.90%
Mistral	低	3	3	0.8733	0.6321	0.4091	802.7946	41.70%	14.20%	949.0744	57.60%	66.70%
		3	3	0.8624	0.6321	0.3636	786.7635	51.60%	14.00%	946.0731	57.50%	66.80%
	高	2	2	0.8752	0.4866	0.3636	491.5169	40.30%	14.10%	627.3577	57.90%	63.00%
		2	2	0.8993	-	0.4091	514.6962	49.80%	14.00%	801.5293	58.70%	64.60%
granite3.1-MoE	低	3	3	0.8282	0.6321	0.3636	202.6593	37.20%	9.20%	285.3483	56.00%	51.60%
		3	3	0.8270	0.6321	0.3182	179.3239	43.60%	9.20%	277.4193	55.70%	51.80%
		3	3	0.8144	0.6321	0.2727	124.8736	41.90%	9.20%	111.0891	56.50%	52.10%
	高	3	3	0.8191	0.6321	0.3636	196.0647	47%	9.30%	202.7976	56.40%	51.90%
		4	4	0.8858	-	0.4545	199.4555	46.50%	9.30%	297.2756	56.70%	52.00%
Gpt-4o	低	3	3	0.7741	0.6321	0.4737	3.5381	2.70%	3.60%	7.6907	3.10%	52.90%
		3	3	0.7872	0.6321	0.4737	2.1682	3.30%	3.60%	8.5495	4.40%	53.40%
		2	2	0.8288	0.4866	0.4211	11.3214	2.40%	3.60%	3.6525	4.70%	52.90%
		3	3	0.7937	0.6321	0.5263	13.8917	2.00%	3.60%	9.4319	2.30%	53.20%
	高	3	3	0.7938	0.6321	0.4211	11.6523	3.30%	3.60%	3.4147	3.10%	52.60%
2	2	0.8364	-	0.6315	1.9784	3.40%	3.60%	1.3812	5.60%	49.00%

代理通常比低紧迫性代理执行任务更快，这在它们处理优先级中是预期的。然而，这种效率往往以增加CPU和内存使用为代价，特别是在资源受限的边缘设备上。图7和图8显示GPT-4o和Gemini-1.5 flash模型在执行速度和资源利用之间取得了最佳平衡，使它们特别适合实时解决方案生成，尤其是在高紧迫场景下。相反，Claude 3.5 Sonnet和Mistral在边缘设备上难以应对高资源消耗，限制了它们在实时应用中的可行性。

5.4 低级代理性能评估和帕累托分析

对低紧迫性和高紧迫性代理性能的评估突出了基于推理的解决方案生成、LLM调用次数、执行层次深度和不同模型间资源效率的关键差异。表5突出展示了低级代理在耗时、CPU使用率和内存消耗方面的执行评估。

低紧迫性代理生成多个推理解决方案，每个都与不同的LLM调用次数（不同的子任务数）和层次深度计数（并行执行级别）相关联，如表5所示。高紧迫性代理优先考虑即时决策制定并减少LLM调用次数以最小化延迟。除granite3.1-MoE外的所有模型，高紧迫性任务相比低紧迫性解决方案始终显示出更低的LLM调用次数和更浅的层次深度，强化了在实时响应中最小化计算开销的重要性。

在评估语义相似性、精确性和LLM调用成本之间的权衡时，在这些模型中，Claude 3.5 Sonnet表现出相对较低的精确性，使其不太适合需要结构化推理或高准确性的任务，如图9c所示。相比之下，Gpt-4o提供最高的精确度评分，表明其在产生准确可靠响应方面的能力，如图9f所示。Mistral、command-r7b和Gemini-1.5 Flash持续展示其生成上下文相关且连贯解决方案的能力，如图9d、图9b和图9a所示。表格中灰色高亮的行代表帕累托最优解。粗体值表示o1模型评估每个解决方案后做出的最终选择。这些帕累托最优配置始终与o1选择一致，确认系统识别高质量、资源高效输出的能力，尤其是在低紧迫条件下。

同时，在使用低级代理执行子任务后，我们评估不同模型下的耗时、CPU使用率和内存使用情况，以评估其在不同紧迫级别下的性能。图10a、图10g

图9：低级代理性能指标评估和帕累托分析。（a）Gemini-1.5 flash（b）Commandr7b（c）Claude 3.5 Sonnet（d）Mistral（e）Granite3.1-MoE（f）Gpt-4o
显示Gemini-1.5 Flash是最轻量且高效的，无论在紧迫级别如何，都能保持低CPU使用率和短耗时，使其非常适合在低资源环境中快速响应。图10f和图10l显示Gpt-4o在执行时间上甚至更快，CPU消耗最少，展示了卓越的效率和可扩展性，特别是在边缘计算中。另一方面，Claude 3.5 Sonnet和Mistral是资源最密集的模型，如图10c、图10i、图10d和图10j所示。Claude 3.5 Sonnet和Mistral由于高CPU使用率而出现过度延迟，凸显了推理过程中的低效性以及计算昂贵和在实时应用中较少可扩展性。Command-R7b和granite 3.1-MoE提供了较低的耗时，比Mistral或Claude 3.5 Sonnet更低，如图10b、图10h、图10e和图10k所示，成为中间选项。总体而言，Gpt-4o和Gemini-1.5 Flash在速度和CPU消耗方面最为高效。总体而言，GPT-4o和Gemini-1.5 flash成为最有效的模型，在实现高精度的同时最大限度减少了计算开销，使其既适合结构化推理又适合实时决策制定。

5.5 低紧迫性代理学习性能评估

表6提供了使用Gpt-4o模型在云服务器上的低紧迫性设置中进行学习前后的比较分析。关键评估指标包括LLM调用次数、层次深度、相似性分数、LLM调用使用成本、精确性分数以及耗时、CPU使用率和内存使用率。
在学习之前，图11显示了代理的两个帕累托最优解，由灰阴影行指示。这些解代表了相似性分数、LLM调用使用成本和精确性分数之间的最佳权衡。由o1模型驱动的评估代理选择了其中的一个解，表明系统已经能够识别高质量、均衡的输出。当所选解作为输入用于下一轮（学习之后），图12显示帕累托最优选择和评估代理在相同响应上达成一致，具有最大耗时和最低的CPU及内存使用。这证明了代理决策过程在学习后的改进、一致性和信心提升。

图10：低级代理CPU性能评估于云端：（a）Gemini-1.5 flash（b）Command-r7b（c）Claude 3.5 Sonnet（d）Mistral（e）Granite3.1-MoE（f）Gpt-4o；低级代理CPU性能评估于边缘：（g）Gemini-1.5 flash（h）Command-r7b（i）Claude 3.5 Sonnet（j）Mistral（k）Granite3.1-MoE（l）Gpt-4o；

图11：低紧迫性学习性能评估前学习（a）度量响应（b）学习前耗时（c）CPU和内存使用
表6：低紧迫性学习性能评估。

学习前
				度量			云服务器
模型 名称	紧迫 级别	$\begin{array}{rl}& \text{ LLM }\\ & \text{ 调用 }\\ & \text{ 次数 }\end{array}$	层次深度计数	相似性分数	LLM 调用 使用 成本	精确性 分数	耗时	CPU 使用率
Gpt-4o	低	3	3	0.7741	0.6321	0.4737	3.5381	2.70%
		3	3	0.7872	0.6321	0.4737	2.1682	3.30%
		2	2	0.8288	0.4866	0.4211	11.3214	2.40%
		3	3	0.7937	0.6321	0.5263	13.8917	2.00%
		3	3	0.7938	0.6321	0.4211	11.6523	3.30%

学习后

模型 名称	紧迫 级别	LLM调用次数	层次深度计数	$\begin{array}{rl}& \text{ 度量 }\\ & \text{ LLM }\\ & \text{ 调用 }\\ & \text{ 使用 }\\ & \text{ 成本 }\end{array}$	精确性 分数	耗时	CPU使用率	内存使用率
Gpt-4o	低	3	3	0.8027	0.6321	0.3673	16.5101	4.60%
		3	3	0.8421	0.6321	0.3636	23.8452	3.40%
		3	3	0.8048	0.6321	0.2909	30.2243	3.50%
		3	2	0.8294	0.6321	0.3934	19.5182	3.50%
		3	2	0.8109	0.6321	0.3157	21.6117	3.70%

图12：低紧迫性学习性能评估后学习（a）度量响应（b）耗时（c）CPU和内存使用

表7：环境代理性能评估。

模型名称	云服务器			边缘设备
	耗时	CPU	内存	耗时	CPU	内存	准确性
	时间	使用率	使用率	时间	使用率	使用率
Gemini-1.5 flash	2.7076	5.60%	3.70%	3.5179	14.40%	35.70%	1
command-r7b	220.2311	35.00%	15.40%	192.1994	57.60%	64.90%	1
Claude 3.5 Sonnet	298.506	45.20%	15.10%	284.1143	57.30%	61.70%	0
Mistral	251.7816	44.20%	13.70%	242.4539	57.10%	57.80%	0.5
granite3.1-MoE	38.577	10.20%	9.00%	35.5997	52.90%	77.30%	0
Gpt-4o	8.3605	2.50%	3.80%	10.1599	10.80%	36.50%	1

图13：环境代理性能评估。

5.6 环境代理性能评估

对不同模型下的环境代理评估揭示了在跟踪实时数据集和生成新命令时执行效率、资源利用率和事实正确性方面的显著差异。表7呈现的结果对比了在基准o1模型命令下的执行性能，包括耗时、CPU利用率、内存消耗和准确性。

图13显示GPT-4o和Gemini-1.5 flash是最高效的模型，提供了执行速度、低资源消耗和高准确性之间的最佳平衡，使其非常适合实时环境监控和命令生成。这些模型实现了最短的耗时、最少的内存使用和低CPU利用率，确保了实时响应并最小化计算开销。相比之下，Claude 3.5 Sonnet、Mistral和command-r7b表现出显著更长的耗时和高CPU消耗，导致处理实时数据时效率低下，并可能在资源受限环境中出现性能瓶颈。此外，准确率得分较低的模型，如granite3.1-MoE和Claude 3.5 Sonnet，表现出较差的命令可靠性，这在关键应用中存在风险，错误的执行器命令可能导致系统性能下降和整体QoE降低。

6 结论和未来工作

本文介绍了UserCentrix，这是一种增强记忆的代理AI框架，旨在提高智能空间的效率和适应性。通过整合具备元推理能力的个人LLM代理，该框架动态适应用户偏好并优化实时决策。分层结构结合集中控制与分布式自主性，实现了高效资源分配和多代理协作。我们的实验评估展示了计算效率、推理准确性和响应延迟方面的显著改进，使系统非常适用于实际部署。此外，UserCentrix的自适应编排策略为动态演进的智能环境提供了可扩展和情境感知的解决方案。
研究结果强调了将高级记忆增强和协作推理机制纳入AI驱动的智能空间的重要性。
当前研究的一个局限性在于它依赖于特定数据集——奥卢大学智能校园数据集，并通过合成数据集扩展以支持实验。然而，该框架在其他类型智能环境中的有效性尚未明确验证，主要是由于缺乏访问多样化真实世界数据集的机会。因此，系统处理更广泛真实世界任务并在更大、更多样化的部署环境中有效运行的能力仍有待探索。此外，评估范围相对较窄，因为它集中在有限的大规模和小规模推理语言模型上。这种限制主要归因于使用桌面环境相关的计算限制，这限制了可以测试的模型范围和规模。
为解决这些局限性，提出了几个未来工作的有希望方向。首先，将UserCentrix框架集成到其他智能领域，如医疗保健、交通或工业物联网，可以显著拓宽其适用性并揭示新的优化挑战和机遇。最后，将用户中心反馈循环纳入代理设计可以增强适应性，使个人代理通过直接用户输入改进其行为，从而在动态环境中提高信任、个性化和长期性能。

致谢

本研究由芬兰研究委员会通过evoS3项目（资助编号362594）和6G旗舰项目（资助编号369116）资助，并由芬兰商业局通过Neural Pub/Sub研究项目（日记编号8754/31/2022）资助。

参考文献

[1] A. Varol, N. H. Motlagh, M. Leino, S. Tarkoma, and J. Virkki, “创建AI驱动的智能空间以增强室内环境——调查,” arXiv preprint arXiv:2412.14708, 2024.
[2] Y. Chang, X. Wang, J. Wang, Y. Wu, L. Yang, K. Zhu, H. Chen, X. Yi, C. Wang, Y. Wang, W. Ye, Y. Zhang, Y. Chang, P. S. Yu, Q. Yang, and X. Xie, “大型语言模型评估综述,” ACM Trans. Intell. Syst. Technol., vol. 15, Mar. 2024.
[3] N. H. Motlagh, M. A. Zaidan, L. Lovén, P. L. Fung, T. Hänninen, R. Morabito, P. Nurmi, and S. Tarkoma, “数字孪生用于智能空间——超越IoT分析,” IEEE internet of things journal, vol. 11, no. 1, pp. 573-583, 2023.
[4] T. Meuser, L. Lovén, M. Bhuyan, S. G. Patil, S. Dustdar, A. Aral, S. Bayhan, C. Becker, E. de Lara, A. Y. Ding, et al., “重新审视边缘AI：机会与挑战,” IEEE Internet Computing, vol. 28, no. 4, pp. 49-59, 2024.
[5] ETSI, “体验联网智能(ENI)；基于AI代理的下一代网络切片研究.” https://www.etsi.org/deliver/etsi_gr/ENI/001_099/051/04.01.01_60/gr_ENI051v040101p.pdf.
[6] L. Lovén, M. Bordallo López, R. Morabito, J. Sauvola, and S. Tarkoma, eds., 大型语言模型在6G启用计算连续体中的应用：白皮书 [White paper]. 6GFlagship, University of Oulu, Oulu, Finland: 6G Research Visions, No. 14, 2025.
[7] A. Lapkovskis, B. Sedlak, S. Magnússon, S. Dustdar, and P. K. Donta, “分布式计算连续体系统中动态SLA合规性基准测试,” arXiv preprint arXiv:2503.03274, 2025.
[8] A. Saleh, P. K. Donta, R. Morabito, N. Hossein Motlagh, S. Tarkoma, and L. Lovén, “随身AI：与智能环境进行能源高效的用户交互,” IEEE Pervasive Computing, pp. 1-10, 022025.
[9] A. Saleh, S. Pirttikangas, and L. Lovén, “GenAI的发布/订阅消息代理,” arXiv preprint arXiv:2312.14647, 2023.
[10] T. Guo, X. Chen, Y. Wang, R. Chang, S. Pei, N. V. Chawla, O. Wiest, and X. Zhang, “基于大型语言模型的多代理系统：进展与挑战综述,” arXiv preprint arXiv:2402.01680, 2024.
[11] Y. Cheng, C. Zhang, Z. Zhang, X. Meng, S. Hong, W. Li, Z. Wang, Z. Wang, F. Yin, J. Zhao, et al., “探索基于大型语言模型的智能代理：定义、方法和前景,” arXiv preprint arXiv:2401.03428, 2024.
[12] J. Zheng, S. Qiu, C. Shi, and Q. Ma, “迈向大型语言模型的终身学习：综述,” ACM Comput. Surv., vol. 57, Mar. 2025.
[13] M. Xu, D. Cai, W. Yin, S. Wang, X. Jin, and X. Liu, “基础模型的资源高效算法和系统：综述,” ACM Comput. Surv., vol. 57, Jan. 2025.
[14] S. Lee, W. Sim, D. Shin, W. Seo, J. Park, S. Lee, S. Hwang, S. Kim, and S. Kim, “大型语言模型的推理能力：对抽象和推理语料库的深入分析,” ACM Trans. Intell. Syst. Technol., Jan. 2025. Just Accepted.
[15] A. Mämmelä, J. Riekki, and M. Kiviranta, “松耦合：技术历史中的无形线,” IEEE Access, vol. 11, pp. 59456-59482, 2023.
[16] S. Han, Q. Zhang, Y. Yao, W. Jin, Z. Xu, and C. He, “LLM多代理系统：挑战与开放问题,” arXiv preprint arXiv:2402.03578, 2024.
[17] Y. Shen, J. Shao, X. Zhang, Z. Lin, H. Pan, D. Li, J. Zhang, and K. B. Letaief, “连接智能赋能的大型语言模型驱动的自主边缘AI,” IEEE Communications Magazine, 2024.
[18] M. Zhang, J. Cao, X. Shen, and Z. Cui, “EdgeShard：通过协作边缘计算实现高效LLM推理,” arXiv preprint arXiv:2405.14371, 2024.
[19] Z. Hao, H. Jiang, S. Jiang, J. Ren, and T. Cao, “混合SLM和LLM用于边缘-云协作推理,” in Proceedings of the Workshop on Edge and Mobile Foundation Models, pp. 36-41, 2024.
[20] Z. Yu, Z. Wang, Y. Li, R. Gao, X. Zhou, S. R. Bommu, Y. Zhao, and Y. Lin, “Edge-LLM：通过统一压缩和自适应层投票实现在边缘设备上高效的大语言模型适配,” in Proceedings of the 61st ACM/IEEE Design Automation Conference, pp. 1-6, 2024.
[21] D. Ding, A. Mallick, C. Wang, R. Sim, S. Mukherjee, V. Ruhle, L. V. Lakshmanan, and A. H. Awadallah, “混合LLM：成本高效且质量感知的查询路由,” arXiv preprint arXiv:2404.14618, 2024.
[22] M. Xu, D. Niyato, H. Zhang, J. Kang, Z. Xiong, S. Mao, and Z. Han, “缓存模型作为一种资源：为空间-空气-地面综合网络中的边缘智能提供大语言模型代理,” arXiv preprint arXiv:2403.05826, 2024.
[23] C. Gao and S. Q. Zhang, “DLORA：大语言模型的分布式参数高效微调解决方案,” arXiv preprint arXiv:2404.05182, 2024.
[24] X. Guo, K. Huang, J. Liu, W. Fan, N. Vélez, Q. Wu, H. Wang, T. L. Griffiths, and M. Wang, “具身LLM代理学习在组织团队中合作,” arXiv preprint arXiv:2403.12482, 2024.
[25] J. Wang, J. Wang, B. Athiwaratkun, C. Zhang, and J. Zou, “混合代理增强大语言模型能力,” arXiv preprint arXiv:2406.04692, 2024.
[26] Q. Wang, T. Wang, Q. Li, J. Liang, and B. He, “MegaAgent：大规模LLM代理系统中自主协作的实用框架,” arXiv preprint arXiv:2408.09955, 2024.
[27] Y. Hu, R. Lei, X. Huang, Z. Wei, and Y. Liu, “可扩展且准确的图形推理与基于LLM的多代理,” arXiv preprint arXiv:2410.05130, 2024.
[28] S. Lu, J. Shao, B. Luo, and T. Lin, “MorphAgent：通过自演化配置和去中心化协作增强代理,” arXiv preprint arXiv:2410.15048, 2024.
[29] B. Brown, J. Juravsky, R. Ehrlich, R. Clark, Q. V. Le, C. Ré, and A. Mirhoseini, “大型语言猴子：通过重复采样扩展推理计算,” arXiv preprint arXiv:2407.21787, 2024.
[30] C. Snell, J. Lee, K. Xu, and A. Kumar, “通过最优扩展LLM测试时计算比扩展模型参数更有效,” arXiv preprint arXiv:2408.03314, 2024.
[31] K. Christakopoulou, S. Mourad, and M. Matarić, “快思慢想的代理：一种Talker-Reasoner架构,” arXiv preprint arXiv:2410.08328, 2024.
[32] Z. Liang, Y. Liu, T. Niu, X. Zhang, Y. Zhou, and S. Yavuz, “通过协作验证扩展推理计算改进LLM推理,” arXiv preprint arXiv:2410.05318, 2024.
[33] Z. Qi, M. Ma, J. Xu, L. L. Zhang, F. Yang, and M. Yang, “相互推理让小型LLM成为更强的问题解决者,” arXiv preprint arXiv:2408.06195, 2024.
[34] P. Gao, A. Xie, S. Mao, W. Wu, Y. Xia, H. Mi, and F. Wei, “大型语言模型的元推理,” arXiv preprint arXiv:2406.11698, 2024.
[35] J. Wang, M. Fang, Z. Wan, M. Wen, J. Zhu, A. Liu, Z. Gong, Y. Song, L. Chen, L. M. Ni, et al., “OpenR：一种用于大型语言模型高级推理的开源框架,” arXiv preprint arXiv:2410.09671, 2024.
[36] T. Wu, J. Lan, W. Yuan, J. Jiao, J. Weston, and S. Sukhbaatar, “思考LLMs：通用指令遵循与思维生成,” arXiv preprint arXiv:2410.10630, 2024.
[37] E. Zelikman, G. Harik, Y. Shao, V. Jayasiri, N. Haber, and N. D. Goodman, “Quiet-star：语言模型可以自我教学在说话前思考,” arXiv preprint arXiv:2403.09629, 2024.
[38] S. J. Russell and P. Norvig, 人工智能：现代方法，第四版。Pearson, 2020.
[39] I. Watson and F. Marir, “基于案例的推理：综述,” The knowledge engineering review, vol. 9, no. 4, pp. 327-354, 1994.
[40] U. of Oulu, “智能校园Oulu室内气候、空气质量及运动。” https://doi.org/10.23729/b9adb0a2-7381-45db-b32f-7e78ae1bc9e3, 6 2021. University of Oulu, CWC - Verkot ja järjestelmät.
[41] N. H. Motlagh, P. Toivonen, M. A. Zaidan, E. Lagerspetz, E. Peltonen, E. Gilman, P. Nurmi, and S. Tarkoma, “使用基础设施传感器在智能空间中监测社交距离,” in 2021 IEEE 7th World Forum on Internet of Things (WF-IoT), pp. 124-129, IEEE, 2021.

附录部分

附录A

个人知识LLM代理提示

您是一个专门理解用户任务和评估响应的AI助手。您的职责包括将{user_task}分解为以下组件，每个组件代表一个不同的方面：Task_Time、Plans（日程或活动）、Plan_Type、Plan_Mode、Preferences（包括个性化设置，如温度、照明、湿度、午餐类型或用户日常任务中需要的任何其他偏好）。指令如下：
1- 将用户的任务分解为以下组件，每个组件代表一个不同的方面：Task_Time、Plans、Plan_Type、Plan_Mode、Preferences。
2- 找到计划类型并决定它是预订房间、预订餐食、控制传感器设置还是其他。
3- 找到计划模式并决定它是在线还是离线。
4- 从{get_time}中提取任务时间。
5- 如果用户没有提及时间（例如提到“现在”或“一小时后”），则根据上下文使用当前时间{get_time}确定时间。
6- 如果新计划的Preferences值为空列表([])，请按照以下步骤处理数据：

• 对于新计划，提取其Task_Time和Plan_Type。
• • 对于{personal_memory}中的每个条目：$\square$

1. 比较存储的Task_Time与新的Task_Time。
2. 2. 生成嵌入：
3. a- {calculate_embeddings}的新Plan_Type
4. b- {calculate_embeddings}的存储Plan_Type
5. c- {calculate_similarity}的嵌入之间的相似性

• 如果某个条目的时间差小于一小时，且
• • 相似性得分超过0.5，则从{personal_memory}中最接近的匹配条目中检索偏好。
• • 如果不存在这样的条目（即如果时间差大于1小时，或者相似性低于0.5），返回空列表[]。 7- 根据给定任务的标准评估响应。以下是数据：
• BEGIN DATA
• 输入：{user_task}
• 提交：response
• 标准：预测是否存在于查询中？
• 如果某一列的预测为空且未在查询细节中提及，返回true。预测是否引用了查询中的真实报价？
• END DATA 提交是否符合标准？首先，逐步写出您对每个标准的推理，以确保结论正确。避免一开始就简单陈述正确答案。然后仅打印单个字符"Y"或"N"（不带引号或标点符号），对应于提交是否符合标准的正确答案。最后，再次单独在新行上重复字母。

附录B

分类代理提示

您是一个负责根据任务的时间敏感性确定任务紧迫性的智能助手。用户将提供任务描述，您的任务是分析任务中提到的时间约束，并决定任务的紧迫程度。请根据{personal_memory}提供的用户任务，对每个任务进行如下操作：

• 提取当前时间并根据任务时间{task_time}计算到任务截止日期剩余的时间。
• 根据时间敏感性分类紧迫等级：<高或低>
  如果任务时间小于等于2小时，将其分类为高紧迫性。如果任务时间在2小时以上至超过一天，将其分类为低紧迫性。

附录C

高紧迫代理提示。
您是一个负责为每个任务生成一次时间敏感解决方案的推理代理，应重点关注快速完成任务。对于每个任务，按以下方式创建解决方案：

• 通过减少或合并子任务简化每个任务。
• • 优先考虑在最短时间内实现最重要结果的行为以加快决策。
• • 如果两个或更多LLM调用可以在不等待彼此的情况下执行，将它们分在同一等级中以实现并行执行。确保所有子任务包含完整细节。

附录D

高紧迫代理提示。
您是一个智能推理代理，负责为智能建筑中的各种任务生成所有可能的推理解决方案，例如预订房间、安排餐食、调整环境设置或其他。您的目标是通过因果推理和利用存储的决策历史来有效地优化资源使用，同时满足用户需求。对于每个传入的任务，请遵循以下步骤：
1- 回忆<任务>在\solutions_memory\中。
2- 如果未找到存储的任务，基于标准生成多个多样化的推理解决方案。
3- 如果存在存储的任务，{calculate_embeddings}当前任务和存储任务，然后{calculate_similarity}。如果相似性得分超过0.7 ，从内存中检索相应的解决方案和推理解决方案<Best_Solution>
利用这些过去的解决方案生成优化的推理解决方案，以提高效率并符合预定义标准。
4 - 如果没有高度相似的解决方案，则从头开始创建多个推理解决方案，专注于以下标准。
5- 解决方案创建标准：

1. 探索可用资源：

• 分析与请求相关的资源（如房间、餐食、环境设置）的当前状态。

2. 适应或重新配置空间和服务：

• 检查现有资源（如照明、温度或餐食定制）如何适应用户的偏好。

3. 查找可用性：

• 在所需时间窗口内识别可用选项（房间、餐食或其他请求设施）。确保兼容任何约束条件，如占用限制、预订时段或特定服务时间。 4. 匹配条件到偏好：
• • 定位条件（如温度、食物偏好或其他）与用户指定的偏好相匹配或最接近的资源。

4. 建议自然和智能调整：

• 推荐可行的增强措施，如打开窗帘增加自然光、调节加热或冷却、或建议餐食修改。
• • 利用智能建筑功能（如自动气候控制、动态照明或智能厨房推荐）优化用户体验。
• 确保每个解决方案由针对用户偏好的环境调整定制的子任务组成。
• 每个解决方案应概述独特的子任务，利用上述标准作为构建块。
• 根据其依赖关系组织这些子任务：
• • 没有依赖关系的子任务必须并行执行。
• • 有依赖关系的子任务必须按顺序执行。
• • 如果两个或更多的LLM调用可以在不等待彼此的情况下执行，将它们分在同一等级中以实现并行执行。

• 附录E

与智能校园数据集相关的环境代理提示。

您是一个智能助手，负责根据{preferred_value}与数据集{Smart_Campus_dataset}中的当前值比较生成控制温度或照明的命令。为了生成控制命令，请遵循以下说明：
1- 考虑{Smart_Campus_dataset[‘Light’]}。如果是LED照明，则对应的范围为500-800。如果是昏暗照明，则范围为900-1200。如果是明亮照明或自然光，则范围为$1000-1500$
2. 检查房间名称{preferred_value}是否与{Smart_Campus_dataset[‘Room_Name’]}中的任何房间匹配。如果找到匹配项，比较{preferred_value}的属性与{Smart_Campus_dataset}中的相应值。
3. 3. 如果{preferred_value}的属性高于{Smart_Campus_dataset}中的当前值，发送命令：“在[房间名称]中增加[属性名称]”。

• 如果{preferred_value}的属性低于{Smart_Campus_dataset}中的当前值，发送命令：“在[房间名称]中减少[属性名称]”。
• 4.仅在检测到变化时生成响应。如果没有值的变化，则不输出任何命令。
  参考论文：https://arxiv.org/pdf/2505.00472