尧图网站建设 
LiveKit Agents 集成 LangChain/LangGraph用 LLMAdapter 把任意工作流变成实时语音 Agent 的大脑【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents导读livekit-plugins-langchain是 LiveKit Agents 生态中连接 LangChain/LangGraph 的官方插件它提供LLMAdapter让你可以把任何已经编译好的 LangGraph 工作流StateGraph直接作为实时语音 Agent 的 LLM 使用——也就是用 LangGraph 的节点、状态、工具编排逻辑来驱动语音对话的思考部分。读完本文你将掌握该插件的安装方式、LLMAdapter的完整参数语义、LangGraph 流式输出messages/custom两种模式如何被转换为 LiveKit 语音管线可消费的增量文本以及底层消息与状态的映射原理能够将现有 LangGraph 项目平滑嵌入实时语音 Agent。插件定位把 LangGraph 工作流伪装成一个 LLMLiveKit Agents 的语音管线中LLM 负责接收用户语音转写出的文本并生成回复内容。常规做法是直接接入 GPT、Claude 等云模型而本插件提供了一条不同的路径用 LangGraph 图来充当 LLM。从源码看LLMAdapter继承自livekit.agents.llm.LLM见 llm.py并实现了该抽象基类的chat()接口返回一个LangGraphStream继承llm.LLMStream。也就是说对于 Agent 运行时而言它面对的是一个符合标准 LLM 接口的对象并不关心背后是云厂商的模型还是你自己编排的图。这正是该插件bring over any existing workflow in LangGraph as an Agents LLM的设计初衷见 README.md。安装插件通过 PyPI 分发使用 pip 直接安装pip install livekit-plugins-langchain根据 pyproject.toml 的依赖声明安装时还会自动拉取以下核心依赖并对版本有最低要求依赖最低版本作用livekit-agents 1.8.0提供 Agent、AgentSession、LLM 抽象等运行时langchain-core 0.3.0消息类型AIMessage、BaseMessageChunk、RunnableConfiglanggraph 0.6.0StateGraph、PregelProtocol、astream 流式执行同时要求 Python 版本不低于 3.10requires-python 3.10.0。插件当前版本为 1.8.0见 version.py并遵循 Apache-2.0 开源许可。插件在导入时还会通过Plugin.register_plugin(LangChainPlugin())自动注册到 LiveKit 插件体系见init.py。快速开始把 LangGraph 工作流挂进 Agent 会话README 给出的用法非常精炼编译好一个StateGraph然后把它作为Agent(llmlangchain.LLMAdapter(graph))传给会话即可。下面是 README 示例的完整展开增加 VAD/STT/TTS 与入口函数等实际可运行上下文参考 README.md 与 basic_agent.py 的会话组织方式from langgraph.graph import StateGraph from livekit.agents import Agent, AgentSession, JobContext from livekit.plugins import langchain def entrypoint(ctx: JobContext): # 任何已经 compile 的 LangGraph 图都可以 graph StateGraph(...).compile() session AgentSession( vad..., stt..., tts..., ) await session.start( agentAgent(llmlangchain.LLMAdapter(graph)), ) ...关键点在于graph必须是已编译compile()之后的 LangGraph 图其类型对应源码中的PregelProtocol[Any, ContextT, Any, Any]见 langgraph.py。从源码结构可以推断只要你的图接受一个包含messages键的状态输入、并在执行过程中产出消息或自定义流式负载就能无缝接入。LLMAdapter 参数全解LLMAdapter的构造签名见 langgraph.py如下LLMAdapter( graph: PregelProtocol, # 已编译的 LangGraph 图必填 *, config: RunnableConfig | None None, context: ContextT | None None, subgraphs: bool False, stream_mode: StreamMode | list[StreamMode] messages, )各参数语义参数类型默认值说明graphPregelProtocol无必填已编译的 LangGraph 图作为 Agent 的推理后端configRunnableConfig \| NoneNone透传给 LangGraph 的运行时配置如recursion_limit、configurable参数等contextContextT \| NoneNone透传给astream的上下文对象需与图的泛型参数匹配subgraphsboolFalse是否让astream同时产出子图的事件流stream_modeStreamMode \| list[StreamMode]messages流式输出模式仅支持messages与custom可传列表组合LLMAdapter还实现了 LLM 基类的两个标识属性见 langgraph.pymodel返回固定字符串unknown这是 LLM 基类的默认值见 llm.py因为后端是用户自己的图而非具体模型provider返回LangChain用于遥测与日志标记。stream_mode 校验规则构造时会对stream_mode做严格校验见 langgraph.py只有messages与custom被允许_SUPPORTED_MODES {messages, custom}其余 LangGraph 模式如values、updates会抛出ValueError: Unsupported stream mode(s): ...。测试 test_langgraph.py 中test_validation_rejects_unsupported_mode、test_validation_accepts_supported_modes对这一行为做了明确验证。运行时原理会话消息如何进入 LangGraph 状态每次用户发言触发 LLM 调用时LangGraphStream._run()会执行以下流程见 langgraph.py将 LiveKit 的ChatContext转换为 LangGraph 的输入状态调用self._graph.astream(state, config, ...)启动图的异步流式执行兼容性回退部分 LangGraph 版本尚未支持context/subgraphs关键字因此先带全参数调用捕获TypeError后降级为只传state、config、stream_mode的调用逐条消费流式事件并转换为llm.ChatChunk通过_event_ch发送给 LiveKit 语音管线。角色映射表_chat_ctx_to_state()见 langgraph.py把 LiveKit 的消息角色翻译成 LangChain 消息类型并保留原始消息idLiveKit ChatContext 角色LangChain 消息类型assistantAIMessageuserHumanMessagesystem/developerSystemMessage转换后的状态固定为{messages: [...]}结构这正是 LangGraph 中MessagesStateAnnotated[list, add_messages]的典型输入格式测试 test_langgraph.py 也使用了这一约定。注意转换仅保留有文本内容raw_text_content的消息空内容消息会被跳过。流式输出messages 与 custom 两种模式语音场景要求边说边出的流式效果因此插件完整支持 LangGraph 的流式事件并转译为 LiveKit 的ChatChunkroleassistant见 langgraph.py。事件消费逻辑同时兼容单模式item直接是数据与多模式item是(mode, data)元组两种形态。模式一messages默认图内部由真实 LLM 节点产出 token 时astream(..., stream_modemessages)的每个事件是(token, metadata)二元组其中 token 通常是BaseMessageChunk也可能是字符串。插件通过_extract_message_chunk()见 langgraph.py将各种可能的事件形状统一归一化(token, meta)(namespace, (token, meta))—— 启用subgraphsTrue时(namespace, mode, (token, meta))/(mode, (token, meta))—— 面向未来的兼容形态直接是BaseMessageChunk或str的兜底形态模式二custom图内节点通过 LangGraph 的StreamWriterwriter(...)主动发射自定义负载时负载可以是字符串、字典取content键或任意带content属性的对象插件统一提取文本后继续交给语音管线合成语音。测试 test_langgraph.py 中的build_custom_graph展示了典型用法stream_node依次写入chunk1、chunk2、{content: chunk3}最终三个负载都会被正确转成语音回复的增量文本见test_custom_mode_string、test_custom_mode_dict。多模式组合stream_mode支持列表组合例如[messages, custom]此时 LLM 节点的 token 流与节点自定义发射的负载会按图执行顺序混合输出。测试test_multi_modetest_langgraph.py用一个chat 节点 stream 节点串联的图验证了两种来源的文本都能被合并消费。模式隔离的边界行为测试还验证了模式之间的隔离语义test_langgraph.pystream_mode[]不产生任何输出显式关闭流式仅含 LLM 节点的图配custom模式无输出仅用StreamWriter的图配messages模式无输出。这说明你选择的stream_mode必须与实际产生事件的图结构匹配否则语音管线将收不到回复内容。工具调用交给 LangGraph 内部编排需要特别说明的是LLMAdapter.chat()中的几个参数见 langgraph.pyparallel_tool_calls、tool_choice、extra_kwargs三个参数虽然出现在签名中但不会被使用——源码注释明确写道 these are unused, since tool execution takes place in langgraph。也就是说当你的 LLM 是 LangGraph 图时工具function_tool、ToolNode等的注册与执行应当全部在图内部完成LiveKit 侧的tools列表仅透传给LangGraphStream保存工具编排逻辑完全由 LangGraph 自身接管。这是与传统云模型接入方式最大的架构差异设计时需注意把业务工具定义在 LangGraph 一侧。验证与测试仓库在 tests/test_langgraph.py 提供了覆盖本插件的完整单元测试可作为接入时的行为参考与回归依据test_messages_mode/test_messages_mode_is_default验证默认messages模式能流式产出GenericFakeChatModel生成的AIMessageChunk文本test_custom_mode_string/test_custom_mode_dict验证StreamWriter发射的字符串与字典负载的转换test_multi_mode验证多模式组合消费test_validation_*验证不支持模式的报错与合法模式的接受test_empty_stream_mode_disables_streaming等验证模式隔离边界。这些测试直接使用LLMAdapter(graph, ...)adapter.chat(chat_ctx...)的方式驱动并断言chunk.delta.content的拼接结果与实际语音管线中消费ChatChunk的方式一致。小结与适用前提livekit-plugins-langchain的价值在于复用任何已经用 LangGraph 编排好的状态机、多智能体图、带条件分支与工具调用的工作流都可以通过LLMAdapter零成本接入 LiveKit 实时语音 Agent。使用时需要注意三点前提一是stream_mode只支持messages与custom二是工具执行必须内聚在 LangGraph 图内三是图的输入状态需兼容{messages: [...]}结构。基于这些约束你就能把成熟的 LangGraph 逻辑平滑迁移到语音交互场景中。【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiveKit Agents 集成 LangChain/LangGraph：用 LLMAdapter 把任意工作流变成实时语音 Agent 的“大脑“
LiveKit Agents 集成 LangChain/LangGraph用 LLMAdapter 把任意工作流变成实时语音 Agent 的大脑【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents导读livekit-plugins-langchain是 LiveKit Agents 生态中连接 LangChain/LangGraph 的官方插件它提供LLMAdapter让你可以把任何已经编译好的 LangGraph 工作流StateGraph直接作为实时语音 Agent 的 LLM 使用——也就是用 LangGraph 的节点、状态、工具编排逻辑来驱动语音对话的思考部分。读完本文你将掌握该插件的安装方式、LLMAdapter的完整参数语义、LangGraph 流式输出messages/custom两种模式如何被转换为 LiveKit 语音管线可消费的增量文本以及底层消息与状态的映射原理能够将现有 LangGraph 项目平滑嵌入实时语音 Agent。插件定位把 LangGraph 工作流伪装成一个 LLMLiveKit Agents 的语音管线中LLM 负责接收用户语音转写出的文本并生成回复内容。常规做法是直接接入 GPT、Claude 等云模型而本插件提供了一条不同的路径用 LangGraph 图来充当 LLM。从源码看LLMAdapter继承自livekit.agents.llm.LLM见 llm.py并实现了该抽象基类的chat()接口返回一个LangGraphStream继承llm.LLMStream。也就是说对于 Agent 运行时而言它面对的是一个符合标准 LLM 接口的对象并不关心背后是云厂商的模型还是你自己编排的图。这正是该插件bring over any existing workflow in LangGraph as an Agents LLM的设计初衷见 README.md。安装插件通过 PyPI 分发使用 pip 直接安装pip install livekit-plugins-langchain根据 pyproject.toml 的依赖声明安装时还会自动拉取以下核心依赖并对版本有最低要求依赖最低版本作用livekit-agents 1.8.0提供 Agent、AgentSession、LLM 抽象等运行时langchain-core 0.3.0消息类型AIMessage、BaseMessageChunk、RunnableConfiglanggraph 0.6.0StateGraph、PregelProtocol、astream 流式执行同时要求 Python 版本不低于 3.10requires-python 3.10.0。插件当前版本为 1.8.0见 version.py并遵循 Apache-2.0 开源许可。插件在导入时还会通过Plugin.register_plugin(LangChainPlugin())自动注册到 LiveKit 插件体系见init.py。快速开始把 LangGraph 工作流挂进 Agent 会话README 给出的用法非常精炼编译好一个StateGraph然后把它作为Agent(llmlangchain.LLMAdapter(graph))传给会话即可。下面是 README 示例的完整展开增加 VAD/STT/TTS 与入口函数等实际可运行上下文参考 README.md 与 basic_agent.py 的会话组织方式from langgraph.graph import StateGraph from livekit.agents import Agent, AgentSession, JobContext from livekit.plugins import langchain def entrypoint(ctx: JobContext): # 任何已经 compile 的 LangGraph 图都可以 graph StateGraph(...).compile() session AgentSession( vad..., stt..., tts..., ) await session.start( agentAgent(llmlangchain.LLMAdapter(graph)), ) ...关键点在于graph必须是已编译compile()之后的 LangGraph 图其类型对应源码中的PregelProtocol[Any, ContextT, Any, Any]见 langgraph.py。从源码结构可以推断只要你的图接受一个包含messages键的状态输入、并在执行过程中产出消息或自定义流式负载就能无缝接入。LLMAdapter 参数全解LLMAdapter的构造签名见 langgraph.py如下LLMAdapter( graph: PregelProtocol, # 已编译的 LangGraph 图必填 *, config: RunnableConfig | None None, context: ContextT | None None, subgraphs: bool False, stream_mode: StreamMode | list[StreamMode] messages, )各参数语义参数类型默认值说明graphPregelProtocol无必填已编译的 LangGraph 图作为 Agent 的推理后端configRunnableConfig \| NoneNone透传给 LangGraph 的运行时配置如recursion_limit、configurable参数等contextContextT \| NoneNone透传给astream的上下文对象需与图的泛型参数匹配subgraphsboolFalse是否让astream同时产出子图的事件流stream_modeStreamMode \| list[StreamMode]messages流式输出模式仅支持messages与custom可传列表组合LLMAdapter还实现了 LLM 基类的两个标识属性见 langgraph.pymodel返回固定字符串unknown这是 LLM 基类的默认值见 llm.py因为后端是用户自己的图而非具体模型provider返回LangChain用于遥测与日志标记。stream_mode 校验规则构造时会对stream_mode做严格校验见 langgraph.py只有messages与custom被允许_SUPPORTED_MODES {messages, custom}其余 LangGraph 模式如values、updates会抛出ValueError: Unsupported stream mode(s): ...。测试 test_langgraph.py 中test_validation_rejects_unsupported_mode、test_validation_accepts_supported_modes对这一行为做了明确验证。运行时原理会话消息如何进入 LangGraph 状态每次用户发言触发 LLM 调用时LangGraphStream._run()会执行以下流程见 langgraph.py将 LiveKit 的ChatContext转换为 LangGraph 的输入状态调用self._graph.astream(state, config, ...)启动图的异步流式执行兼容性回退部分 LangGraph 版本尚未支持context/subgraphs关键字因此先带全参数调用捕获TypeError后降级为只传state、config、stream_mode的调用逐条消费流式事件并转换为llm.ChatChunk通过_event_ch发送给 LiveKit 语音管线。角色映射表_chat_ctx_to_state()见 langgraph.py把 LiveKit 的消息角色翻译成 LangChain 消息类型并保留原始消息idLiveKit ChatContext 角色LangChain 消息类型assistantAIMessageuserHumanMessagesystem/developerSystemMessage转换后的状态固定为{messages: [...]}结构这正是 LangGraph 中MessagesStateAnnotated[list, add_messages]的典型输入格式测试 test_langgraph.py 也使用了这一约定。注意转换仅保留有文本内容raw_text_content的消息空内容消息会被跳过。流式输出messages 与 custom 两种模式语音场景要求边说边出的流式效果因此插件完整支持 LangGraph 的流式事件并转译为 LiveKit 的ChatChunkroleassistant见 langgraph.py。事件消费逻辑同时兼容单模式item直接是数据与多模式item是(mode, data)元组两种形态。模式一messages默认图内部由真实 LLM 节点产出 token 时astream(..., stream_modemessages)的每个事件是(token, metadata)二元组其中 token 通常是BaseMessageChunk也可能是字符串。插件通过_extract_message_chunk()见 langgraph.py将各种可能的事件形状统一归一化(token, meta)(namespace, (token, meta))—— 启用subgraphsTrue时(namespace, mode, (token, meta))/(mode, (token, meta))—— 面向未来的兼容形态直接是BaseMessageChunk或str的兜底形态模式二custom图内节点通过 LangGraph 的StreamWriterwriter(...)主动发射自定义负载时负载可以是字符串、字典取content键或任意带content属性的对象插件统一提取文本后继续交给语音管线合成语音。测试 test_langgraph.py 中的build_custom_graph展示了典型用法stream_node依次写入chunk1、chunk2、{content: chunk3}最终三个负载都会被正确转成语音回复的增量文本见test_custom_mode_string、test_custom_mode_dict。多模式组合stream_mode支持列表组合例如[messages, custom]此时 LLM 节点的 token 流与节点自定义发射的负载会按图执行顺序混合输出。测试test_multi_modetest_langgraph.py用一个chat 节点 stream 节点串联的图验证了两种来源的文本都能被合并消费。模式隔离的边界行为测试还验证了模式之间的隔离语义test_langgraph.pystream_mode[]不产生任何输出显式关闭流式仅含 LLM 节点的图配custom模式无输出仅用StreamWriter的图配messages模式无输出。这说明你选择的stream_mode必须与实际产生事件的图结构匹配否则语音管线将收不到回复内容。工具调用交给 LangGraph 内部编排需要特别说明的是LLMAdapter.chat()中的几个参数见 langgraph.pyparallel_tool_calls、tool_choice、extra_kwargs三个参数虽然出现在签名中但不会被使用——源码注释明确写道 these are unused, since tool execution takes place in langgraph。也就是说当你的 LLM 是 LangGraph 图时工具function_tool、ToolNode等的注册与执行应当全部在图内部完成LiveKit 侧的tools列表仅透传给LangGraphStream保存工具编排逻辑完全由 LangGraph 自身接管。这是与传统云模型接入方式最大的架构差异设计时需注意把业务工具定义在 LangGraph 一侧。验证与测试仓库在 tests/test_langgraph.py 提供了覆盖本插件的完整单元测试可作为接入时的行为参考与回归依据test_messages_mode/test_messages_mode_is_default验证默认messages模式能流式产出GenericFakeChatModel生成的AIMessageChunk文本test_custom_mode_string/test_custom_mode_dict验证StreamWriter发射的字符串与字典负载的转换test_multi_mode验证多模式组合消费test_validation_*验证不支持模式的报错与合法模式的接受test_empty_stream_mode_disables_streaming等验证模式隔离边界。这些测试直接使用LLMAdapter(graph, ...)adapter.chat(chat_ctx...)的方式驱动并断言chunk.delta.content的拼接结果与实际语音管线中消费ChatChunk的方式一致。小结与适用前提livekit-plugins-langchain的价值在于复用任何已经用 LangGraph 编排好的状态机、多智能体图、带条件分支与工具调用的工作流都可以通过LLMAdapter零成本接入 LiveKit 实时语音 Agent。使用时需要注意三点前提一是stream_mode只支持messages与custom二是工具执行必须内聚在 LangGraph 图内三是图的输入状态需兼容{messages: [...]}结构。基于这些约束你就能把成熟的 LangGraph 逻辑平滑迁移到语音交互场景中。【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考