MoonshotAI / MoonshotAI/kimi-code

上下文很长的对话经常出现打不开(超时)

Open
#3,592 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

你运行的 Kimi Code 版本是?

0.41

你使用的是哪个开放平台/订阅?

基元律动

你使用的是哪个模型?

glm5.3 flash

你的电脑平台是?

Linux 6.1.0-30-amd64 x86_64 unknown debian

你遇到了什么问题?

所有上下文很长的对话都有很大概率打不开,会出现超时
我有2个上下文很长的对话,ai自己工作了几天了,但是很大概率打不开对话。
第一次打开电脑以后成功打开对话的概率高一些。但是之后就大概率打不开对话了。
我是在vps部署kimi code,用的官方安装命令。然后在我的电脑远程使用网页端操作。使用cloudflare反代。
其他短对话没问题,可以打开。
以下是出错信息:
无法连接到 Kimi 服务器
Web 没有拿到 Kimi 服务器的响应。请确认它仍在运行,或刷新页面重试。

诊断信息:
操作: loadSessionTranscript
Session ID: session_e3c84894-f2db-498f-b05d-fcf0812e64c6
连接状态: connected
时间: 2026-09-07T02:02:36.406Z
耗时: 30000ms
请求: GET /sessions/session_e3c84894-f2db-498f-b05d-fcf0812e64c6/transcript
请求地址: https://(隐藏我的域名)/api/v1/sessions/session_e3c84894-f2db-498f-b05d-fcf0812e64c6/transcript?agent_id=main&page_size=20
Request ID: 01M1WSKVP6SK609F6MQ4MM7HJR
失败阶段: parse
超时设置: 30000ms
HTTP 状态: 200
响应类型: application/json; charset=utf-8
底层原因: AbortError: The user aborted a request.

复现步骤?

1.在vps上(2g内存)使用官方脚本安装kimi code,并启动webui,只对本地开放
2.使用caddy 反代端口,再用cloudflare接管域名,
3.开启一个对话,提出任务,让ai自己工作几天,然后上下文很长
4.然后这个很长的对话就大概率经常打不开,出现上面的出错提示了。其他短的对话没问题

期望的行为是什么?

打开长对话(尤其是ai工作了几天的长对话)不会出现上面的错误。

补充信息

对话满了会自动压缩上下文,我已经压缩上下文几次了
我使用了caddy转发和cloudflare转发
就算能够打开页面,浏览器会非常卡
我觉得对话界面不应该一次性加载太多内容,可以模仿deepseek harness一样只加载最后一部分内容,用户需要查看的时候再提供翻页功能(并给出标签方便用户跳转到指定对话时刻)。这样避免一次性加载太多内容加载失败或者浏览器卡死。

Contribution
  • 我愿意自己提交修复此 bug 的 PR(请先等待维护者在本 issue 中批准)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the loadSessionTranscript request to GET /sessions/{session_id}/transcript and reproduce the timeout using a long conversation through the Web UI. Inspect how the response is parsed and rendered, then verify that long transcripts open reliably without excessive browser lag or a 30-second timeout.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, frontend, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.