2. V2EX
  3. 想问大佬们一些 go+ Python (langgraph agent)的一些开发问题

想问大佬们一些 go+ Python (langgraph agent)的一些开发问题

JimLee0921 2026-07-16 09:44 1
RT ，新进的这家公司想把之前用 fastapi 写的一套后端用微服务把网关什么的迁移到 go 上，通过 rpc 调用 py 的 agent 微服务，然后通信上司让我看那个 NATS ，但是我还是有一些问题，希望大佬们解答一下给一些建议


1. 因为 python 里面的 agent 调用涉及那种 SSE 流传输什么的，go 和 python 怎么通信比较好呢？
2. 数据的保存，如果是那种不涉及 agent 调用的接口好弄一些，直接在 go 里面做 CURD 就行了，但是有些接口是 agent 生成完数据再保存到数据库并且还要返回给用户某些东西的，这种是在哪些层面保存，agent 又应该如何返回呢？
3. 因为感觉难的大头是在 agent 和 go 之间的通信，不敢让 ai 一把梭，但是上司用 AI 生成的方案看着又很不靠谱。。。


大家有啥相关经验或者意见可以分享一下嘛？
最新回复 (6)
  • BingoXuan 07-16 12:01
    1楼
    1. llm 返回的流数据可以传给任何流，你可以选用 NATS 或者其他消息队列，返回给用户时候变成 SSE
    2. agent 生成的东西不应该保存到数据库，而是考虑保存到 S3 这类存储服务
    3. 我看完了也没搞清楚 go 部分到底要干嘛？如果本身功能角色不清晰，和任何系统对接都会变成一坨不可名状的东西
  • JimLee0921 楼主 07-16 12:14
    2楼
    @BingoXuan 按照上司意思是害怕上线后用户多了会那啥，想用 go 做网管来写接口，不需要 agent 的接口就直接在 go 里面处理，向外只暴露 go 的接口，然后通过 go 再去调用 python agent
  • BingoXuan 07-16 14:35
    3楼
    @JimLee0921
    完全是过度优化了。fastapi 性能没那么不堪，而且 agent 都是重 io 的。套一层 go 并不会提高性能。反而降低了可观察性。有这个时间应该把 fastapi 的可观察性提高，确认性能瓶颈和找 bug 而不是盲目换语言。如果架构足够清晰，第一点既不是问题。llm 返回的流如何缓存，用户网络抖动断开重连如何恢复等细节都会处理好。换语言不影响架构，尤其现在 LLM 重写有太多成功例子。
  • Hstar 07-16 14:52
    4楼
    我讲下我们的方案, 供参考
    1. 外部请求经由 API 服务, 先把 session / message 之类数据前置准备好, 包括使用的模型/配置等等, 保存到 DB, 返回前端消息创建成功.
    2. python 端相当于是个纯运行 agent 的异步任务后台, 用一个消息队列触发. 用 rpc 触发也可以, 个人感觉 python 用 rpc 比较丑陋, 很少这么用.
    3. python agent 接到的任务就是运行一个指定的 message, 负责直接维护和 LLM 供应商的数据流, 然后根据数据做各种操作, tool call / 本地数据操作之类的.
    4. 需要暴露给用户的内容, python agent 把约定好的 sse chunk 数据塞进当前 message 专属的 redis stream 或者类似的轻量队列就好, 再做些生命周期管理避免资源占用.
    5. 前端经过 API 服务用新接口打开 sse 连接, 从当前 message 专属的队列里读 sse chunk 然后吐给前端.
  • JimLee0921 楼主 07-16 17:34
    5楼
    @BingoXuan #3 好的，谢谢
  • JimLee0921 楼主 07-16 17:34
    6楼
    @Hstar 好的，谢谢
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐