[Bug]: 流水线中无法切换本地ollama模型

[hicocsco]

Runtime environment

V4.8.7,Ubuntu 24.04.4,docker

Exception

Reproduction steps

No response

Enabled plugins

No response

[dosubot]

Hi @hicocsco! I'm Dosu and I’m helping the LangBot team.

这个错误的根本原因是 Ollama 在 LangBot v4.8.7 中尚未实现流式输出。OllamaChatCompletions 类只实现了非流式的 invoke_llm() 方法，而没有实现 invoke_llm_stream() 方法。当平台尝试使用流式输出时，基类的默认实现返回 None，导致 async 迭代失败。

解决方法: 在平台配置中禁用流式输出。如果你使用的是钉钉、飞书或 Telegram，在平台配置中设置：

enable-stream-reply: false

如果使用 Discord、Slack、QQ 等平台，流式输出默认是禁用的，不应该出现此错误。可以检查一下你使用的平台适配器是否启用了流式输出。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hicocsco]

感谢大佬的回复。
我的使用场景主要是针对企业微信，对于enable-stream-reply: false这条命令要在哪里修改？谢谢
PS:后续版本会支持流式输出吗？
再次感谢回复

[dosubot]

企业微信平台适配器目前没有 enable-stream-reply 配置选项。

LangBot 有三种企业微信适配器：

• wecom (标准适配器) - 不支持流式输出
• wecombot (企业微信智能机器人) - 内置流式输出，始终开启
• wecomcs (企业微信客服) - 不支持流式输出

如果你使用的是 wecom 标准适配器或 wecomcs，它们本身不支持流式输出，不应该出现这个错误。请检查一下你配置的是哪个适配器类型。

如果使用的是 wecombot (企业微信智能机器人)，它默认启用流式输出且目前无法关闭，这就是导致 Ollama 报错的原因。这种情况下，在 Ollama 实现流式输出支持之前，可能需要临时切换到其他 LLM 提供商，或者等待后续版本的修复。

关于后续版本是否支持 Ollama 流式输出，建议关注本 issue 的后续更新或项目的 release notes。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hicocsco]

在Test流水线中关闭流式按钮后可以正常调试本地ollama

在langbot新建企微机器人和企微客服

然后在企微的窗口中分别输入“1+1=2”但得不到结果
下面的日志只有一条消息，没有任何报错，企微客服

下面的日志报错，企微机器人

[dosubot]

很高兴关闭流式按钮后 Test 流水线可以正常工作了！

关于企业微信适配器的问题：

企微机器人 HTTP 400 错误：这是一个已知问题，企微智能机器人发送请求时 Content-Type 是 text/xml 但实际请求体是 JSON 格式，导致 LangBot 无法解析。解决方案是使用 nginx/Caddy 等反向代理将 Content-Type 从 text/xml 改写为 application/json。

企微客服无响应：企微客服需要在 https://kf.weixin.qq.com/ 单独设置，配置和普通企业微信不同，请参考 Issue #2019 确认配置是否正确。

调试建议：

• 查看 data/logs/langbot-YYYY-MM-DD.log 日志文件获取更多错误信息
• 使用 DEBUG=true 环境变量启用调试模式

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hicocsco]

可否提供一下 nginx 配置，谢谢。

[dosubot]

参考 Issue #1825 的讨论，nginx 配置示例如下：

# 对于统一 webhook 端点 (推荐)
location ~ ^/bots/ {
    proxy_pass http://your_langbot_internal_address:port;
    proxy_set_header Content-Type application/json;
}

# 或者对于旧版 webhook 端点
location /callback/command {
    proxy_pass http://your_langbot_internal_address:port;
    proxy_set_header Content-Type application/json;
}

关键是添加 proxy_set_header Content-Type application/json;，将企微发送的 text/xml 头改写为 application/json，这样 LangBot 就能正确解析请求体中的 JSON 数据了。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hicocsco]

按照上面的方法修改了nginx配置文件仍然报相同的错误，下面是nginx的部分配置文件，帮忙看看是否写得有问题

介绍下我的环境：
langbot和nginx反向代理在同一台公司内网机器上，通过防火墙映射443端口到公网，使用企业备案的域名与企微互联

下面是nginx反向代理access.log中的报错

[dosubot]

从你的 access.log 看到有 301 重定向和 404 错误，这说明请求可能没有到达正确的 webhook 处理程序。

几个排查建议：

1. 检查 location 路径是否匹配：确保 nginx 的 location 块与企微配置的回调 URL 路径完全一致。如果你使用的是统一 webhook 端点，路径应该是 /bots/<uuid> 格式

2. 验证 Content-Type 是否真的被改写：可以在 LangBot 侧开启 debug 模式（DEBUG=true）查看收到的请求头，或者临时在 nginx 配置里加一个自定义 header 测试：

   add_header X-Debug-Content-Type $content_type;

3. 301 重定向问题：检查是否有其他 location 块或 server 块在做 HTTP->HTTPS 或路径重定向。301 会导致 POST 请求变成 GET，丢失请求体

4. 确认 proxy_pass 地址：你配置的是 127.0.0.1:5300，确保 LangBot 确实在监听这个地址和端口。可以用 curl -v http://127.0.0.1:5300/bots/<你的uuid> 直接测试内网连通性

能否提供一下完整的 location 块配置以及企微后台配置的回调 URL？这样可以帮你更准确地定位问题。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hicocsco]

完整的nginx配置：

回调地址：