04-Python和Go做Agent:同一个订单分析任务,代码到底差在哪?

这次不讨论“谁的 benchmark 更快”，也不拿两个完全不同的 Demo 硬比。我们把第二篇的订单分析任务搬过来，用同一份数据、同一个问题、同一组工具，分别看 Python 和 Go 的代码到底差在哪里。代码将在最后附上

先说结论：

Python 把复杂度放在生态和试错速度上，Go 把复杂度放在类型和工程边界上。

这不是“Python 适合 AI、Go 不适合 AI”这么简单。真正的选型问题是：你的 Agent 现在更需要快速验证，还是更需要嵌进一个已经稳定运行的服务系统？

本文技术资料核验于 2026 年 8 月 12 日。示例中的 Eino API 以官方仓库和官方示例为准；OpenAI Agents Python 当前 PyPI 版本为 0.20.0。本文没有做性能测试，不用代码行数推导性能结论。

先把题目固定下来

我们继续使用游戏充值订单表。为了让两种语言真的可比，先把输入和输出约束固定：

• 输入问题：哪个游戏的实收金额最高？
• 默认口径：只统计 paid 订单，排除退款和待支付
• 工具：query_orders(group_by, status)
• 工具输出：按金额从高到低返回汇总结果
• 最终回答：说出排名，并明确统计口径

数据仍然是第二篇里的演示数据，不包含真实用户信息。按 paid 口径，工具会得到：

传奇霸业：1204 元三国志异：846 元仙侠奇缘：358 元

这组结果是本地函数直接计算出来的，不是模型生成的运行记录。模型模式需要你自己提供新的 MODEL_API_KEY，本文不复用任何历史会话里的凭据。

Python：先把循环和工具写明白

Python 的优势，第一眼就能看见：写一个工具函数，再把它塞进模型调用，胶水代码很少。下面是核心工具，参数和返回值都用 Python 类型标出来：

def query_orders(group_by: str, status: str = ”paid”) -> list[dict[str, Any]]:    if group_by not in {”game”, ”channel”}:        raise ValueError(”group_by 只能是 game 或 channel”)    if status not in {”paid”, ”all”}:        raise ValueError(”status 只能是 paid 或 all”)    totals: defaultdict[str, float] = defaultdict(float)    for order in ORDERS:        if status == ”paid” and order[”status”] != ”paid”:            continue        totals[order[group_by]] += order[”amount”]    return [        {group_by: key, ”total_amount”: round(amount, 2)}        for key, amount in sorted(            totals.items(), key=lambda item: item[1], reverse=True        )    ]

这里有两个容易被忽略的点。

第一，str 和 list[dict] 是开发期提示，不是默认的运行时校验。模型传进来的参数仍然是不可信输入，所以函数内部依然要检查 group_by 和 status。这和后端接口不能只相信 TypeScript 类型、还要在边界校验请求体，是同一个道理。

第二，dict[str, Any] 很灵活，也意味着返回结构没有被完全固定。今天返回 total_amount，明天某个分支多返回一个字段，静态检查未必会替你发现调用方已经不兼容。

Python 的循环，你仍然看得见

示例代码 code/04-python-go-agent/python_agent.py 保留了上一篇的手写路线。模型模式的关键部分只有几步：

for round_no in range(1, 9):    response = client.chat.completions.create(        model=os.getenv(”MODEL_NAME”, ”deepseek-chat”),        messages=messages,        tools=TOOLS,    )    message = response.choices[0].message    messages.append(message.model_dump(exclude_none=True))    if not message.tool_calls:        print(message.content or ”(模型没有返回文本)”)        return    for call in message.tool_calls:        arguments = json.loads(call.function.arguments or ”{}”)        messages.append({            ”role”: ”tool”,            ”tool_call_id”: call.id,            ”content”: execute_tool(call.function.name, arguments),        })

这段代码的价值不在于它短，而在于它把协议边界暴露出来了：assistant 消息要带着 tool_calls 回填历史，工具结果要带对应的 tool_call_id，然后再进入下一轮。

如果不想自己维护这个循环，Python 生态也有更高层的选择。以 OpenAI Agents Python 为例，工具可以用 function_tool 装饰器定义，Runner 管理 Agent loop，Runner.run_streamed 返回事件流。它支持自定义 OpenAI-compatible provider，但“兼容接口”仍不等于每个模型的工具调用行为完全一致，接入时要按目标模型实际验证。

因此 Python 有两条路：

• 手写循环：最适合学习协议、快速改实验和定位问题
• SDK 托管循环：最适合接入 sessions、guardrails、tracing 等现成能力

生态丰富是 Python 的真实优势，但它也带来选择成本：SDK、模型适配器、异步库、类型检查器各有自己的版本节奏，依赖升级需要有人负责。

Go：工具参数先变成一个类型

Go 版本使用 Eino 的 InferTool。它的思路很符合 Go：先定义参数结构体，再让工具 schema 从结构体推导出来。

type QueryOrdersInput struct {    GroupBy string `json:”group_by”`    Status  string `json:”status,omitempty”`}type OrderSummary struct {    Group string  `json:”group”`    Total float64 `json:”total_amount”`}queryTool, err := toolutils.InferTool(    ”query_orders”,    ”按游戏或渠道汇总订单金额。默认只统计 paid 订单；status=all 才包含退款和待支付订单。”,    queryOrders,)

InferTool 会根据 QueryOrdersInput 生成工具参数 schema，并负责把模型传来的 JSON 参数解码成这个结构体。真正执行业务逻辑的函数是：

func queryOrders(_ context.Context, input QueryOrdersInput) ([]OrderSummary, error) {    if input.GroupBy != ”game” && input.GroupBy != ”channel” {        return nil, fmt.Errorf(”group_by 只能是 game 或 channel”)    }    if input.Status == ”” {        input.Status = ”paid”    }    if input.Status != ”paid” && input.Status != ”all” {        return nil, fmt.Errorf(”status 只能是 paid 或 all”)    }    // 汇总逻辑与 Python 版本相同    return result, nil}

这里的收益很具体：queryOrders 的输入和输出在编译期就是确定的。调用方拿错字段、返回值类型不匹配，通常会更早暴露；context.Context 也让超时、取消和请求链路可以自然地传到工具内部。

但别把“有类型”理解成“自动安全”。模型传来的 group_by 仍然可能是任意字符串，运行时校验仍然要写。Go 帮你挡住的是程序员和重构带来的类型错误，不是模型和用户输入带来的业务错误。

Eino 把循环放到 Runner 里面

Go 版本的 Agent 组装大致是这样：

agent, err := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{    Name:          ”OrderAnalyst”,    Instruction:   ”先调用 query_orders，再根据工具结果回答。不要编造数据。”,    Model:         model,    MaxIterations: 8,    ToolsConfig: adk.ToolsConfig{        ToolsNodeConfig: compose.ToolsNodeConfig{            Tools: []tool.BaseTool{queryTool},        },    },})runner := adk.NewRunner(ctx, adk.RunnerConfig{    Agent:           agent,    EnableStreaming: true,})iter := runner.Query(ctx, ”哪个游戏的实收金额最高？”)

上一篇手写的“模型决定 → 执行工具 → 回填结果”仍然存在，只是由 ChatModelAgent 和 Runner 托管了。MaxIterations 对应我们手写版本的轮数上限；context.Context 则贯穿模型、工具和流式读取。

这里有一个很有 Go 味道的取舍：框架负责通用循环，业务函数仍是普通函数。以后不用 Eino 了，订单汇总逻辑不需要跟着重写。

流式输出：两边都有，形状不同

流式不是“把最终答案拆成几段打印”这么简单。一个 Agent 的流里至少可能混着四类事件：

1. 模型正在生成文本
2. 模型正在拼装工具名和工具参数
3. 工具返回结果
4. Agent 进入下一轮后继续输出最终答案

Python Agents SDK 的典型写法是遍历 stream_events()，从 raw response event 中取文本增量：

result = Runner.run_streamed(agent, input=question)async for event in result.stream_events():    if event.type == ”raw_response_event”:        print(event.data.delta, end=””, flush=True)

Go/Eino 的 Runner.Query 返回事件迭代器。打开 EnableStreaming 后，事件里的 MessageOutput 可能携带 MessageStream，读取它就能逐块处理内容：

for {    event, ok := iter.Next()    if !ok {        break    }    if event.Err != nil {        return event.Err    }    if event.Output == nil || event.Output.MessageOutput == nil {        continue    }    stream := event.Output.MessageOutput.MessageStream    if stream == nil {        continue    }    for {        chunk, err := stream.Recv()        if err == io.EOF {            break        }        if err != nil {            return err        }        fmt.Print(chunk.Content)    }}

两种写法的共同点是：上层业务应该消费事件，而不是假设每次只有一个最终字符串。差异在于，Python 的异步迭代器和 Go 的显式 Recv 各自贴合语言习惯。Go 的 io.EOF、取消和 channel/stream 生命周期需要更明确地处理；Python 的异步代码更短，但取消传播和任务生命周期也不能靠“代码少”自动解决。

并发与取消：Go 的优势要到服务化才明显

这次订单汇总本身只有一个工具调用，没法凭它证明 Go 一定更快。真正能看出差异的是把 Agent 放进服务以后：

• Python 通常依靠 asyncio、异步 HTTP 客户端和任务管理来组织并发
• Go 可以用 goroutine、channel 和 context 组合请求生命周期
• 两边都必须设置模型请求超时、Agent 最大轮数、工具查询超时和输出上限
• 两边都要避免把模型生成的 SQL 或其他外部输入直接当成可信命令

Go 的 context 贯穿函数签名，意味着“用户断开连接后停止模型和工具”更容易形成统一约定；代价是每个函数都要认真传递和检查 context。Python 的异步模型也能做到同样的事，但项目需要统一 asyncio.CancelledError、任务取消和客户端超时的处理方式。

我的判断是：语言优势要放到真实服务边界里评估。在 Notebook 或一次性脚本里，Go 的类型和工程约束可能显得笨重；在高并发、长连接、已有 Go 中间件体系的服务里，重新引入一套 Python 运行时也会产生边车、部署和排障成本。

调试体验：谁让你更快找到错的那一行？

Agent 出问题时，最重要的不是“模型说错了”，而是你能不能回答下面几个问题：

• 哪一轮调用了哪个工具？
• 模型看到的工具参数是什么？
• 工具返回了什么，耗时多久？
• 是模型请求失败，还是工具业务失败？
• 用户取消后，底层请求真的停了吗？

Python 手写版可以直接打印 round_no、工具名和参数，改起来很快。SDK 路线则能进一步接 tracing、sessions 和 guardrails，但排查时要理解 SDK 的事件模型。

Eino 官方提供 Callback 切面，可以在 OnStart、OnEnd、OnError 以及流式输入输出等节点接日志、Tracing 和指标。它还把模型、工具、Graph 和 Agent 统一到一套组件/编排模型里。对 Go 后端来说，接入现有日志和指标系统的边界比较自然。

两边的底线都一样：不要只打印最终答案。至少记录 run_id、模型调用、工具名、经过脱敏的参数、错误、耗时和 token 用量。订单数据、用户输入和工具返回值可能含敏感信息，日志要按生产数据规范脱敏。

代码量不是选型结论

把这次对照压成一张表：

不要拿这张表去评“谁赢”。它更像一张复杂度放置位置图：

• Python 把时间省在胶水代码上，把注意力放到模型、Prompt 和实验上
• Go 把时间花在类型、接口和生命周期上，换来更明确的服务边界

我的选择建议

如果你是第一次做 Agent，建议按这个顺序试：

1. 先用现有语言写一个本地确定性工具，验证数据口径和业务流程
2. 再接模型，手写一次循环，搞懂 tool call 的协议细节
3. 复杂度长出来后，再选择 SDK、状态图或 Go 原生 Agent 框架

具体到团队：

• 快速验证 Prompt、工具描述和模型能力：Python 更省力
• 已有 Python 服务或数据科学团队：优先沿用 Python，减少跨语言成本
• Agent 要嵌入现有 Go API、消息队列和监控体系：优先评估 Eino
• 需要复杂状态、审批和恢复：语言不是第一决策，先选能解决运行时问题的框架
• 只是因为“AI 圈都用 Python”：先问自己是否真的需要跨语言部署

还有一个比语言更重要的边界：把工具和领域逻辑写成普通函数，把模型调用放到适配层，把会话状态和业务状态分开。这样以后从 Python 换 Go，或从手写循环换框架，迁移的是编排层，不是整套业务。

写在最后

这次对照没有证明 Python 或 Go 谁更适合 Agent。它只把选择拆成了几个可以讨论的工程问题：

• 你要多快验证一个想法？
• 你能接受多少运行时灵活性？
• 你的服务已经沉淀在哪套语言和基础设施里？
• 你准备怎样处理流式、取消、日志和失败恢复？

Agent 不是脱离后端工程的特殊程序。模型负责提出下一步，工具负责接入现实世界，框架负责管理循环和状态；剩下的超时、权限、并发、日志、重试和数据边界，仍然是我们熟悉的后端问题。