我为什么放弃 Python 搭建 Agent,转向 Go

导读：原型阶段，Python 是最快的脚手架。到了生产环境，真正决定成败的，不是起步速度，而是地基够不够稳。

你用 Python 写过 Agent 上线吗？

有没有因为一个依赖冲突，整个 LangChain 升级后 Agent 全部罢工？有没有在凌晨两点排查一个 TypeError，原因是某个工具返回了 None 而你的代码假设它一定是 str？有没有为了让 Agent 和 tRPC 微服务通信，单独搭了一套 HTTP 桥接层、一套部署流程、一套监控链路？

如果以上都中招，这篇文章就是写给你的。

一、Python 搭 Agent：快是快，但上线是另一件事

我用 Python 写了将近两年的 Agent。LangChain、AutoGen、CrewAI——主流框架我全都用过。

原型阶段确实爽。一个 chain = LLMChain(llm=..., prompt=...) 就能跑起来，几十行代码就能做出一个能对话的 Agent。

但上线之后，问题一个接一个。

第一个问题：类型黑洞。 Python 当然不是完全没有类型检查。你可以写类型注解，可以跑 mypy，也可以用 Pydantic 在边界上做数据校验。

问题在于，Agent 的数据流太长了——LLM 返回、工具调用、状态拼接、上下文回写，往往跨越多个框架层。只要其中一段没有把类型约束接住，错误还是会在运行时漏出来。你调一个工具，返回了 None，下游代码当 str 处理——线上炸了才看到。LangChain 的 chain.invoke() 返回什么类型？很多时候还是得看文档、看源码、跑起来才知道。

第二个问题：依赖地狱。LangChain 半年迭代了三个大版本，每次升级都是一次赌命。你的 Agent 代码在 v0.1 能跑，v0.2 就废了。更别提 numpy、torch 这些底层包的版本冲突。

第三个问题：和微服务体系的割裂。 我的后端全是 Go，跑在 tRPC 上，监控用 OpenTelemetry，服务发现走 Polaris。Agent 用 Python 写，意味着要单独维护一套运行时、一套部署流程、一套监控链路。Agent 调后端服务，走 HTTP 桥接；后端服务调 Agent，再走一层 gRPC。链路追踪断成两截。

Python 是 Agent 的脚手架，不是 Agent 的地基。

下面是完整拆解。

二、一个需要澄清的事实：并发不是 Python 的死穴

先说清楚一件事——Python 的 GIL 对 Agent 场景并没有想象中那么致命。

Agent 是 IO 密集型应用：调 LLM API、查向量库、执行工具调用，本质上全是网络等待。Python 的 asyncio + aiohttp 完全能处理这种并发。一个 async def 协程的开销也不大，LangChain 也已经全面支持异步调用。

所以如果你只看"能不能并发"，Python 没问题。

但并发只是生产级 Agent 的及格线，不是终点线。

我转向 Go 的真正原因，不是 Python 跑不动，而是 Python 更依赖人为把约束补齐——类型要靠注解、mypy、Pydantic 和团队纪律一起兜住，依赖要自己盯，和微服务体系的集成成本也要自己扛。

决定换语言之前，我列了一张表：

这不是语言宗教战争——这是生产环境的验收单。

下面这张图，把 Python 和 Go 在生产级 Agent 场景里的结构差异摊开了：

说完并发，再说性能。Agent 确实是 IO 密集型，但不是纯 IO 密集型。每一次 LLM 调用之间，还有大量 CPU 工作：JSON 序列化/反序列化、Prompt 模板拼接、工具参数解析、向量后处理。这些计算在 Python 里是解释执行的，在 Go 里是编译执行的。

一组数据，来自我用 Eino 和 LangChain 分别实现的同一个 Agent（QPS 100 压测）：

CPU 差 6 倍、内存差 10 倍，这个差距主要不是来自并发模型，而是来自语言运行时的效率。Go 编译成原生机器码，Python 解释执行字节码；Go 的 GC 暂停亚毫秒级，Python 的 GC 在高并发下会引发不可预测的延迟抖动。压测时 P99 延迟的波动，很大程度就是这么来的。

Go 的 goroutine 模型还有一个 asyncio 做不到的事：你不需要区分同步和异步。 在 Python 里，requests 是同步的，aiohttp 是异步的，混用就阻塞事件循环。而在 Agent 场景中，JSON 解析、数据变换这些 CPU 操作天然是同步的——它们和异步 IO 混在一起时，要么用 run_in_executor 桥接，要么接受事件循环被阻塞。在 Go 里，http.Get() 和 json.Marshal() 写法一样，运行时自动调度，同步代码自动获得并发效果。

但更致命的差距仍然在类型系统。Agent 的数据流从用户输入 → Prompt 拼接 → LLM 返回 → 工具调用 → 状态更新，每一步都有类型变换。Python 当然可以靠类型注解、mypy 和 Pydantic 提前拦下一部分问题，但这些约束能不能贯通整条链路，往往取决于框架支持和团队执行力。Go 的很多约束则默认落在编译期。Agent 的链路越长，这个差距越致命。

但 Go 一直缺一个东西——成熟的 Agent 框架。

直到 tRPC-Agent-Go 和 Eino 出现。

三、腾讯和字节同时出手，Go 的 Agent 框架终于能打了

tRPC-Agent-Go：腾讯的 Agent 重火力

基于 tRPC 微服务生态的自主多 Agent 协作框架，同时兼容图编排工作流。

tRPC-Agent-Go 是腾讯开源的 Go 语言 Agent 框架，背靠 tRPC 在腾讯内部 200 万+ 节点、5 万+ 服务的微服务基座。

它的核心架构设计有两个关键决策：

自主协作为主，图编排兜底。

和 LangChain 那种纯编排式框架不同，tRPC-Agent-Go 让每个 Agent 都具备环境感知、自主决策和动作执行能力。多个 Agent 通过消息传递协作，不是死板的工作流，而是能根据上下文动态调整策略的智能体。

自主多 Agent 协作，就是让多个 Agent 像施工班组一样分工、协同、回传结果，而不是按一条死流程机械执行。

但腾讯也承认，对于明确流程的场景，图编排更稳定。所以 GraphAgent 同样是一等公民。

插件化设计，所有组件可插拔。

Model、Tool、Session、Memory、Knowledge——每个模块都是插件。你想换模型？换一行配置。想加 MCP 工具？注册一个 Tool 就行。想接 OpenTelemetry 监控？内置支持。

它读资料、调模型、挂工具、管会话、记记忆。

支持五种 Agent 类型：

• LLMAgent：基础智能 Agent，对话+工具调用
• ChainAgent：链式流水线，适合文档处理、内容审核
• ParallelAgent：并行多专家，适合多维度评估
• CycleAgent：循环迭代，适合内容优化、自动调试
• GraphAgent：图工作流，适合复杂决策和存量迁移

agent := llmagent.New("assistant",    llmagent.WithModel(openai.New("gpt-4o-mini")),    llmagent.WithInstruction("你是一个专业的AI助手"),    llmagent.WithTools([]tool.Tool{calculatorTool, searchTool}),)

这几行代码，就是一个完整的自主智能体。

Eino：字节的 Agent 编排引擎

基于图编排的 Go 语言大模型应用开发框架，组件化设计，强类型校验。

Eino 是字节跳动 CloudWeGo 团队开源的框架，已经在抖音、豆包等核心业务中规模化应用。

图编排，就是先把 Agent 的每一步搭成结构图，让输入、决策、工具调用和输出按既定连接流转。

它的核心设计理念是 Graph（图编排）——把 AI 应用抽象成有向图，节点是组件，边是流转逻辑。

Eino 给我最深的感受有三个：

强类型。 组件输入输出类型严格对齐，编译时就拦住错误，不是跑到线上才炸。这是 Go 的基因优势，Eino 把它发挥到了极致。ChatModel 的输出类型和 ToolsNode 的输入类型对不上？编译报错，不是运行时崩。

流式处理。 独创 StreamReader/StreamWriter 机制，自动处理流的拼接和复制。对 Agent 的实时对话场景，这是刚需。

生态完备。 预置 50+ 组件，覆盖主流大模型接入、知识库管理、RAG 检索。配套 EinoDev 可视化平台，调试链路也更顺手。

agent, err := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{    Name:        "TechInterviewer",    Instruction: "你是一个资深面试官...",    Model:       model,    ToolsConfig: adk.ToolsConfig{        ToolsNodeConfig: compose.ToolsNodeConfig{            Tools: []componenttool.BaseTool{GetResumeInfoTool()},        },    },    MaxIterations: 15,})

四、选错框架比选错语言更致命

两个框架的差别，摊开看会更清楚：

简单说：你的团队用 tRPC，选 tRPC-Agent-Go；你的团队用通用 Go 技术栈，选 Eino。两者都不选 Go 生态之外的方案。

五、让我换语言的不是压测数据，是凌晨两点的报警

压测数据容易找，但真正让我下定决心换语言的，不是数字，是三个深夜排障的瞬间。

理由一：类型安全不是锦上添花，而是生产底线。Agent 的数据流天然复杂——用户输入到 Prompt，LLM 返回 JSON 解析成工具参数，工具返回结果拼回上下文。每一步都有类型变换。Python 当然可以用 Pydantic 做输入输出校验，也可以用类型注解和静态检查补强，但这些约束通常要一层层手工接起来。只要有一个工具节点漏了校验，一个 null 而不是 ""，下游 .lower() 还是会炸。Go 的编译器替你挡住了更多这类问题，而 Eino 的组件类型约束让整条数据流在编译时就被校验通过。

理由二：部署复杂度是隐性成本。 Python Agent 的 Docker 镜像 800MB，冷启动 30 秒。Go 编译出来一个 20MB 的二进制，毫秒级启动。当你的 Agent 需要弹性扩缩容——流量高峰加实例、低谷缩回去——这个差距直接变成钱。更关键的是，Python 的虚拟环境、依赖锁定、多阶段构建，每一环都可能出问题。Go 的 go build 一步到位，运维团队不需要理解 Python 生态。

理由三：和微服务体系的融合成本。 这是我最痛的一点。Agent 不是孤立运行的——它需要调后端的用户服务、内容服务、推荐服务。Python Agent 调 tRPC 服务，要走 HTTP 网关；tRPC 服务调 Agent，要走 gRPC。链路追踪断成两截，监控面板拼不上。换成 Go 后，Agent 和后端服务在同一个 tRPC 体系内，进程内直接调用，链路追踪一拉到底。

换语言不是为了更快，是为了更稳。

编译器的报错，总比凌晨两点的报警好。

六、Python 的库再强，也不该来扛地基

读到这里，你可能有一个疑问：Python 的库那么丰富，Go 根本替代不了啊。

没错。NumPy、Pandas、spaCy、sentence-transformers——这些库在 Go 里没有等价物。如果 Agent 需要做 PDF 解析、本地 Embedding 计算、机器学习推理，Go 确实做不了。

但"Go 做 Agent 框架"和"全部用 Go"是两件事。

我实际在用的架构是这样的：

[Go Agent 框架] ├── 编排：Eino Graph / tRPC-Agent-Go ├── 会话/内存/状态：全在 Go 侧 ├── 通用工具：MCP、HTTP、DB → Go 原生 └── 重型工具：PDF解析/Embedding → gRPC → [Python 微服务]

Go 是主线，Python 是支线。

Agent 的编排、会话管理、路由、微服务集成，全在 Go 侧。Python 只在某个具体工具需要特定库时，作为一个独立的微服务出现。

这和我之前批评的"Python Agent 和 Go 后端之间 HTTP 桥接"完全不同。那时候的问题是：Agent 编排层本身在 Python，需要和整个 Go 微服务体系桥接，链路追踪断成两截。 现在反过来——编排层在 Go，Python 只是一个工具节点。通过 gRPC 调用，有 proto 文件定义强类型接口，链路追踪穿透到底。

Python 服务是无状态的——给输入，返输出。不持有会话，不管理 Agent 生命周期。挂了不影响 Agent 主流程，独立扩缩容。

Python 不是被抛弃了，是被安置在了正确的位置。

它是工具箱里的一把专用扳手，不是整栋建筑的地基。

七、两周迁移，12 台缩到 2 台

从 Python Agent 迁移到 Go，我走了三步：

第一步：保留 LLM 调用逻辑，用 Go 重写编排层。 Agent 的核心是 LLM 调用 + 工具调用 + 状态管理，这些逻辑和语言无关。我用 Eino 的 Graph 重新编排了原来的 LangChain Chain。先只替换主流程，不碰提示词和工具协议，确保第一版能对齐旧结果。

第二步：工具迁移。 Python 里用 @tool 装饰器定义的工具，在 Go 里实现为 componenttool.BaseTool 接口。结构更清晰，类型更安全。我优先迁走高频、低依赖的工具，把 PDF 解析和 Embedding 这种重依赖能力继续留在 Python 服务里。

第三步：和现有微服务打通。 原来需要用 HTTP 桥接的 tRPC 服务，现在直接在进程内调用。链路追踪、服务发现、负载均衡，一套体系全打通。迁移完成前，我保留了一段双跑期：同一批请求同时打旧链路和新链路，对比结果、时延和错误率，确认一致后再切流。

整个过程花了两周。迁移后，我的 Agent 集群从 12 台机器缩减到 2 台。

Python 写 Agent 的速度，Go 部署 Agent 的速度，不是同一个速度。

也许你会问：是不是过度工程？我的 Agent 就跑个 Demo，有必要换 Go 吗？

如果只是验证想法，Python 完全够用。LangChain 二十分钟跑通一个原型，Go 做不到这个速度——也没有必要做到。

但原型和生产的距离，比很多人以为的远。

一旦 Agent 需要扛住真实流量、融入微服务体系、让运维团队睡个安稳觉——你面对的问题就不再是"能不能跑起来"，而是"跑起来之后怎么不挂"。

腾讯和字节同时选择用 Go 做 Agent 框架，不是巧合。生产级的 Agent，需要生产级的基座——类型安全、单二进制部署、原生微服务集成。

换语言不会让你少写代码。但换到 Go，你写的每一行代码，都跑在编译器的承重墙后，跑在单二进制的预制结构里，跑在你已有的微服务生态里。

Python 的生态没有被浪费——它只是从地基搬到了工具箱。

Agent 的战场不在原型，在生产。

Go 打地基，Python 当扳手。

如果你也在用 Python 跑 Agent 并遇到了类型黑洞和微服务割裂，这个周末可以试试 Eino——初始化一个 Go 项目，用 20 行代码跑通一个最简单的 LLMAgent。Python 那些不可替代的库，封装成 gRPC 微服务挂上去就行。你会发现，Go 做 Agent，比你想象的容易得多。

如果你身边也有人正被 Python Agent 的类型黑洞和微服务割裂折磨，把这篇文章转给他。

你在 Agent 上线这件事上，踩过最大的坑是什么？

🔧 相关资源：

• tRPC-Agent-Go：https://github.com/trpc-group/trpc-agent-go
• Eino：https://github.com/cloudwego/eino
• tRPC-Agent-Go 官方文档：https://trpc-group.github.io/trpc-agent-go/zh/
• Eino 官方文档：https://www.cloudwego.io/zh/docs/eino/