今天是2025年5月22日，星期四，北京，阴。
我们来看看Agent的事情，看到一个思路，通过人工介入Agent运行控制思路Magentic-UI，这个有点像高级的RPA。
但是，实际上在真实落地的时候，目前除了coze，dify这种写死的workflow之外，做这种人工控制的，其实也蛮不错，只是还是需要人来盯着，比较消耗精力，所以更适合做debug。毕竟，你要么就全自动，要么就不自动老老实实按流程走。中间这种形态，真实使用起来，其实并不友好，但是很适合做实验对比，所以看看起实现过程。
另一个，就是关于GraphRAG以及无人机控制的项目，重点看实现思路。
抓住根本问题，做根因，专题化，体系化，会有更多深度思考。大家一起加油。
一、人机交互型Agent运行控制思路Magentic-UI
来看看Agent的进展，微软发布的Magentic-UI Web Agent(https://github.com/microsoft/magentic-ui)，自动化浏览器操作，生成 planning，然后让人确认，整个过程人工介入，完成可控结果的生成，这个才靠谱些，人机互动UIAgent。这个的根本逻辑在于，现在agent运行并不稳定，尤其是在安全性上，所以引入人工介入，其实会好些。
1、功能设定
从功能侧看，Magentic-UI Web Agent是由多智能体系统驱动，可以浏览和执行网页操作、生成和执行代码以及生成和分析文件，适用于需要网页操作的Web任务（例如，填写表单、定制餐单）、深度导航至未被搜索引擎收录的网站（例如，筛选航班、查找个人网站的链接）或需要网页导航和代码执行的任务（例如，根据在线数据生成图表）。
具体体现在界面上，由两个面板组成，如下：
左侧面板是会话导航器，用户可以在其中创建新会话来解决新任务，在会话之间切换，并使用会话状态指示器检查会话进度（🔴需要输入，✅任务完成，↺任务进行中）；
右侧面板显示所选会话。可以向 Magentic-UI 输入查询，并添加文本和图像附件，查看详细的任务进度，并与代理进行交互。
会话显示本身分为两个面板：左侧面板用于Magentic-UI 显示计划、任务进度并请求操作批准；右侧面板是浏览器视图，可以在其中实时查看Web代理操作并与浏览器进行交互。最后，会话显示顶部是一个进度条，会随着Magentic-UI 的进度而更新。
2、重要区别
从区别上看，与其他浏览器使用产品的区别在于其透明且可控的界面，允许高效的人机交互，使用AutoGen构建，提供一个研究人机交互和 Web代理实验的平台，这个协同工作的表现如下：
一个是共同规划，使用聊天和计划编辑器协作创建和批准分步计划；
一个是协同任务，直接使用网页浏览器或通过聊天工具中断并指导任务执行；
一个是敏感动作只有在获得用户明确批准的情况下才会执行；
3、系统构成
Magentic-UI底层系统由改编自AutoGen的Magentic-One系统，
其中：
Orchestrator，由大模型提供支持，与用户一起执行共同规划，决定何时向用户征求反馈，并将子任务委托给其余代理完成。
WebSurfer，可控制Web浏览器的Agent，收到Orchestrator的请求后，执行点击、输入、滚动和多轮访问页面的操作，最终完成Orchestrator的请求；
Coder，Docker代码执行容器的Agent，可以编写和执行Python和Shell命令，并向Orchestrator提供响应；
FileSurfer，Docker代码执行容器和来自MarkItDown包的文件转换工具。可以定位 Magentic-UI 控制目录中的文件，将文件转换为Markdown格式，并回答相关问题。
UserProxy，代表用户与Magentic-UI交互的代理。
4、人机交互具体如何实现具体执行逻辑
整个的交互逻辑可以整理成如下流程：
1）用户输入文本消息并附加图片。
2）作为响应，Magentic-UI创建一个分步计划，用户可以通过计划编辑界面进行交互。
3）用户添加、删除、编辑、重新生成步骤，并编写后续消息以迭代计划，计划存储在Orchestrator内部，用于执行任务。
4）对于计划的每个步骤，Orchestrator确定由哪个代理（WebSurfer、Coder、FileSurfer）或用户来完成该步骤。
5）做出决定后，Orchestrator向其中一个代理或用户发送请求，并等待响应。
6）收到响应后，Orchestrator判断该步骤是否完成。
7）如果完成，Orchestrator将继续执行下一步。
8）所有步骤完成后，Orchestrator生成最终答案并呈现给用户。
9）如果在执行任何步骤时，Orchestrator认为该计划不充分（例如，由于某个网站无法访问），Orchestrator 可以在用户许可的情况下重新规划并开始执行新的计划。
9）所有中间进度步骤显示给用户。
10）用户可以暂停计划执行并发送其他请求或反馈，也可以通过界面配置代理操作（例如，点击按钮）是否需要审批。
但是呢，这个有点像高级的RPA，实际上在真实落地的时候，目前除了coze，dify这种写死的workflow之外，做这种人工控制的，其实也蛮不错，只是还是需要人来盯着，比较消耗精力，所以更适合做debug。
毕竟，你要么就全自动，要么就不自动老老实实按流程走。
中间这种形态，真实使用起来，其实并不友好，但是很适合做实验对比。
二、关于GraphRAG以及无人机控制的一些实现思路
1、GraphRAG-SubGCache做推理加速
《SubGCache: Accelerating Graph-based RAG with Subgraph-level KV Cache》，https://arxiv.org/pdf/2505.10951。这个工作，主要针对的问题是，多个查询在结构上存在相似性，导致重复计算的问题，通过子图级别的缓存机制来加速推理过程。
核心就是怎么做子图之间的相似性，如何有效比较和识别不同查询检索到的子图之间的结构和语义相似性。
做法也很粗暴：
对于语义相似性，使用一个基于SentencesBERT的节点特征初始化的预训练GNN，将每个检索到的子图编码成一个图嵌入，然后进行层次聚类，将具有相似子图的查询分组在一起。
对于结构相似性，那就是subgraph层次，那就上聚类方法，对于每个聚类，将所有查询的子图合并为一个代表性子图，以保留高质量响应生成所需的关系上下文。
基于这两个步骤，在提速实现上，在每个聚类中，仅计算一次代表性子图的KV缓存，并在所有查询中重用该缓存，从而避免重复计算。
但是，从落地的可用性上看，可以预见的是，这种方案对于问题的覆盖程度和泛化性不回很好，尤其是问题多变的情况。
此外，如果Graph本身又是动态变化，这种机制回瞬间失效。
所以，这种方式，是针对静态的以及少量Graph场景下的一种方案。
2、基于Qwen的AI控制无人机的项目DeepDrone
DeepDroneD使用自然语言处理进行无人机控制、分析和操作，包括实时飞行控制和遥测监控 、数据分析和可视化功能、任务规划和执行功能 以及预测性维护建议。
相应的地址在：https:https://huggingface.co/spaces/evangelosmeklis/deepdronerepo，https://github.com/evangelosmeklis/deepdrone。
对于技术方案，在deepwiki：https://deepwiki.com/evangelosmeklis/deepdrone可以进行细致了解。
技术流程如下：
实现技术栈也是集成，例如：
smolagents用于代理+Qwen2.5-Coder用于大模型理解+DroneKit-Python用于无人机控制+Streamlit用于用户界面+Pandas、Matplotlib和Seaborn用于数据分析和可视化。
参考文献
1、https://github.com/microsoft/magentic-ui
（文：老刘说NLP）