trpc-agent-python
腾讯开源的 Python Agent 开发框架,支持多模型、多编排、多协议的全链路生产级 Agent 解决方案
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
腾讯开源的 Python Agent 开发框架,支持多模型、多编排、多协议的全链路生产级 Agent 解决方案
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:你接到一个需求——用大模型做一个能查天气、写代码、记住用户偏好的智能助手。不是写完一个脚本就跑,而是要做成生产级的、可部署的、能多轮对话的服务。传统方案里,光是让模型调用工具、管理会话、处理记忆,就要写一大堆胶水代码,还要自己处理服务化部署、协议对接。
tRPC-Agent-Python 就是来解决这个问题的——来自腾讯开源团队,提供从 Agent 构建、编排、工具接入、会话记忆,到服务化部署与可观测性的全链路能力,让你专注业务逻辑,不用从零搭基建。
腾讯的 AI Agent 团队在实际业务中积累了大量的工程实践。他们发现市面上的框架各有擅长,但往往只覆盖某一层:LangChain 擅长知识库但编排弱,LangGraph 编排灵活但服务化差,FastAPI 可以快速部署但 Agent 能力薄。缺少一个能在生产环境直接使用、覆盖全链路的方案。
tRPC-group 是腾讯内部的 Agent 框架团队,他们将内部成熟的 Agent 开发能力开源,希望帮助社区开发者快速构建可靠的 AI 应用。框架的核心设计理念是生态集成:不重复造轮子,而是广泛对接 LangChain、LangGraph、LiteLLM、Mem0 等主流生态,让开发者可以自由组合。
框架内置四种编排模式:ChainAgent(链式)、ParallelAgent(并行)、CycleAgent(循环)、TransferAgent(转接),同时支持 GraphAgent 图编排,通过 DSL 统一管理 Agent、Tool、MCP、Knowledge、CodeExecutor 等组件,形成可视化的工作流编排。
这种设计非常适合复杂场景:比如一个客服 Agent,需要先理解意图(Chain),然后并行查询多个知识库(Parallel),最后根据结果决定是否需要人工介入(Cycle)。用 GraphAgent 就能清晰表达这个流程。
框架对工具系统的支持非常全面。FunctionTool 支持将任意 Python 函数注册为 Agent 工具,自动生成调用接口;MCPToolset 对接 Model Context Protocol 协议,生态内已有大量 MCP Server 可直接接入;此外还支持 LangChain Tool、Agent-as-Tool 等模式。
对于 MCP 协议,这是当前 Agent 工具生态的重要标准,tRPC-Agent-Python 对其的支持意味着项目能方便地接入 Claude Desktop、Cursor 等平台的 MCP 工具生态。
Session 负责单次会话内的消息与状态管理,支持 InMemory / Redis / SQL 三种后端;Memory 负责跨会话的长期记忆与个性化信息沉淀,可接入 Mem0、Mempalace 等专业记忆服务。
这套设计的巧妙之处在于分层:Session 解决"当前对话"的问题,Memory 解决"记住用户"的问题。两个系统独立扩展,按需启用,既适合简单场景(纯内存),也能支撑高并发生产环境(Redis + Mem0)。
知识库能力基于 LangChain 组件构建,提供完整的 RAG 场景支持。对于需要结合私有知识库回答的企业场景(如内部文档问答、产品 FAQ),这套能力可以快速接入,不需要另起一套系统。
这是非常关键的一个扩展能力。传统 Agent 只能"给出代码建议",但 CodeExecutor 支持本地或 Docker 容器化的代码执行,Agent 可以实际运行自己生成的代码、验证结果、修正错误。对于需要代码生成和自动化的场景,这是从"建议"到"行动"的关键一步。
框架内置 FastAPI 服务,支持三种协议:HTTP(OpenAI-compatible)、A2A(Agent-to-Agent 通信协议)、AG-UI(Agent UI 协议)。这意味着部署后可以与现有的 Agent 网络、其他 Agent 服务、前端界面无缝对接,不需要自己写协议适配层。
同时内置 OpenTelemetry 追踪,线上运行时的调用链路、性能瓶颈一目了然。
框架的技术选型非常务实:核心依赖包括 FastAPI(Web 服务)、Pydantic v2(数据验证)、OpenAI SDK(模型通信)、MCP SDK(工具协议)、LangGraph(工作流编排)、LangChain(知识库组件)、Redis(会话持久化)、SQLAlchemy(数据库抽象)。
项目采用 hatchling 构建系统,支持 pip install -e . 源码安装和 pip install trpc-agent-py 直接安装两种方式,可选依赖按需组合([a2a,knowledge,agent-claude] 等),避免安装不必要的包。
开发规范方面,有完整的 .flake8、.coveragerc、coverage 报告、Codecov 集成,代码质量基础设施完备。License 为 Apache-2.0,可商用。
安装只需一行:pip install trpc-agent-py。按需扩展:pip install "trpc-agent-py[a2a,knowledge,agent-claude]"。
创建一个天气查询 Agent 的完整代码不到 40 行,核心是定义工具函数 → 创建 LlmAgent → 配置 Session → Runner 驱动运行。全程类型安全,Pydantic 模型贯穿数据流。
部署方面,框架本身不需要 GPU,因为调用的是外部模型 API。生产环境建议配合 Redis(会话持久化)和 MySQL(长期数据),通过 FastAPI 直接启动 HTTP 服务。
需要坦诚指出几个问题:
1. 文档深度不足:尽管 README 和 INSTALL 文档齐全,但复杂场景(如 GraphAgent DSL 详细语法、CodeExecutor 容器配置)的文档仍较简略,需要参考源码理解。
2. 生态锁定风险:深度依赖 LangChain/LangGraph/Mem0 等第三方生态,这些生态的版本迭代可能导致兼容性问题。
3. 生产成熟度待验证:项目当前版本为 1.1.0,PyPI 分类仍为"Alpha",在腾讯外部的生产环境案例尚不多,大规模并发场景下的性能数据缺失。
4. 无容器化支持:项目不提供 Dockerfile 或 docker-compose,对于习惯容器化部署的团队不够友好,需要自己编写。
tRPC-Agent-Python 代表了一个趋势:从"实验框架"到"生产框架"的收敛。随着 Agent 技术从 Demo 走向生产,开发者需要的不是更多"玩具级"的教程框架,而是能真正承接流量的工程化方案。腾讯将内部验证过的 Agent 工程实践开源,对中文开发者社区有直接的参考价值。
同时,框架对 A2A、AG-UI 等新兴协议的支持,也显示出腾讯在 Agent 互联互通标准上的布局——未来 Agent 不只是"单个智能助手",而是一个能互相通信、协作的 Agent 网络,tRPC-Agent-Python 在架构上已经为此做好准备。