LangGraph 开发Agen的两大核心范式——Graph API（基于显式节点、边和状态构建有向图）与 Functional API（通过轻量级任务装饰器与原生 Python 控制流编写函数式工作流）。1.智能体设计的前置核心要素在进入具体的架构设计之前，教科书式的智能体开发必须明确并定义以下三个核心物理实体，无论是采用何种 API 范式，这些要素都构成了智能体与外界交互的基石。大语言模型（L

1. 入口在哪？- 前端入口 ： main.py 的用户输入框- 逻辑入口 ： rag_agent.py 的 get_results() 函数（被 main.py 第 90 行调用）2. Neo4j 连接在哪初始化？每个 Chain 自己初始化 ，不是全局共享的：- vector_chain.py 第 76-84 行： Neo4jVector.from_existing_index()

简单比喻：同构图 (Homogeneous) = 纯牛奶（里面只有一种东西：牛奶分子）。异构图/多部图 (Heterogeneous) = 珍珠奶茶（里面有：牛奶、珍珠、椰果）场景类比：场景 A：同构图 （前面1-5做的）例子：Cora 引用网络。节点：全是论文。边：只有一种关系：引用。特点：因为大家都是论文，所以大家的特征维度都一样（比如都是 1433 维），地位也平等。GNN 处理方式：大家一

本文介绍了使用图卷积网络(GCN)处理Cora学术论文引用网络的分类任务。Cora数据集包含2708篇论文节点、5429条引用边，每篇论文用1433维词袋向量表示，需分类到7个学术领域。相比传统MLP仅利用节点特征，GCN通过两层消息传递层（GCNConv）聚合邻居信息，采用ReLU激活和dropout防止过拟合。实验在PyTorch Geometric框架下实现，使用Adam优化器，经过200轮

买菜的不思考，做饭的不伸手：前3个Agent是买菜的，它们只要把菜（数据）买回来。最后一个行程规划是做饭的，它没有外部工具（手），就是要炒菜。一个Agent只配发一把专属的武器：搜天气的和搜酒店的分开给，保证了工具调用 100% 不会出错。不同数据的获取逻辑不同，分开设置获取：天气是确定性的（只要给个城市名就行）；景点和酒店是偏好性的（需要根据用户的“历史文化”、“经济型”等偏好去搜索）。在前面3

大模型怎么当项目经理？TODO Planner Agent 扮演了项目经理的角色。当用户抛出一个宽泛的宏大主题时，Planner 不需要立刻去查阅外部资料。它凭借的是大模型在预训练阶段所积累的庞大世界知识库与常识。它将复杂的任务“降维拆解”为3到5个具体的、可执行的子任务。对于每一个拆解出来的子任务，它不仅给出了清晰的任务标题，还明确了研究意图，并针对性地写好了最容易搜出干货的英文查询词。为什么不

在让大模型生成旅行计划时，系统直接报错，大模型回复：“抱歉，工具不可用”。底层的存在 Bug，在向大模型注册工具时，传递的参数说明书是个空字典{}。大模型虽然聪明，但它没有参数说明，它根本不知道怎么构造高德地图的 API 请求，导致 Function Calling 整个流程直接断裂。放弃了让 LLM 自主调度工具。用 Python 代码做拦截，直接硬编码去调用高德 API 获取真实的 JSON

买菜的不思考，做饭的不伸手：前3个Agent是买菜的，它们只要把菜（数据）买回来。最后一个行程规划是做饭的，它没有外部工具（手），就是要炒菜。一个Agent只配发一把专属的武器：搜天气的和搜酒店的分开给，保证了工具调用 100% 不会出错。不同数据的获取逻辑不同，分开设置获取：天气是确定性的（只要给个城市名就行）；景点和酒店是偏好性的（需要根据用户的“历史文化”、“经济型”等偏好去搜索）。在前面3