最近遇到一个实际问题：做 agent 开发时，消息长度一旦超过模型上下文限制，大多数方案都是简单粗暴地截断——后面的内容直接丢掉，对话变得没头没尾。

这显然不行。

参考了虚拟机动态迁移的思路，在 JiXing 里实现了一套完整的上下文管理方案。核心想法是：对话可以保存、压缩、迁移到更长的上下文中继续，就像虚拟机在不同物理机之间热迁移一样。

安装

项目已经发布到 PyPI，安装很简单：

pip install jixing

或者从源码安装：

git clone https://github.com/cycleuser/JiXing.git
cd JiXing
pip install -e .

安装完成后可以验证：

jixing --version

核心问题

实际使用中会遇到几种情况：

对话越来越长，超过模型支持的上下文窗口。 很多 agent 的做法是直接截断，但这样会丢失重要信息。

即使模型支持最大上下文，压缩后只保留一条摘要消息，历史会话保存在 JSONL 文件中，新开更长的会话是否可行？ 答案是可以的，关键是怎么把上下文"搬"过去。

解决思路分三层：

第一层是智能压缩。 不是简单截断，而是根据消息重要性评分，保留关键信息，压缩中间内容。压缩率可以精确控制，从 0.1 到 0.9 可调。同时加入了语义压缩模块，用更短的同种文字表达同样的意思。

第二层是会话迁移。 当压缩后仍然超限时，创建快照，把原始目标、中间要求、最后一轮对话打包，迁移到支持更长上下文的新会话中。

第三层是运行时持久化。 如果已经是模型支持的最大上下文，就把运行状态写入 Markdown 文件——原始目标、中间要求、决策过程、最后一轮输入输出都保留下来。

语义压缩：同样的意思，更短的表达

这是这次改进的核心亮点之一。传统的上下文压缩是直接截断或者让 AI 总结，但我们发现很多文本本身就存在大量冗余表达，可以通过规则直接压缩。

中文压缩规则

中文里有很多冗余的表达模式，比如：

"首先...其次...最后" → 直接删除"首先"，用"另外"替代"其次"
"具有...的特点" → 直接删除，保留核心内容
"进行...的处理" → 简化为"处理..."
"从...角度来看" → 简化为"看..."
"在...方面" → 简化为"...上"
"对于...来说" → 简化为"对..."
"综上所述" → "总之"
"总而言之" → "总之"

这些规则可以在不改变语义的前提下，显著缩短文本长度。

英文压缩规则

英文同样存在大量冗余：

"In order to" → "To"
"Due to the fact that" → "Because"
"On the other hand" → "But"
"In conclusion" → "So"
"For example" → "Like"
"It is important to note that" → "Note:"

压缩效果

实际测试中，一段典型的 AI 生成中文文本：

首先，人工智能具有强大的数据处理能力。其次，AI已经渗透到各行各业。综上所述，我们需要重视AI发展。

压缩后变为：

人工智能具有强大的数据处理能力。另外，AI已经渗透到各行各业。总之，我们需要重视AI发展。

字符数减少了，但语义完全保留。

流式输出：实时看到模型回复

之前的版本没有流式输出，每次都要等模型全部生成完才能看到结果。现在支持实时流式显示了。

jixing ollama run huihui_ai/lfm2.5-abliterated:latest -i

进入交互模式后，模型的回复会逐字显示，就像在使用官方 Ollama 客户端一样。

完整的 Ollama 模型管理

现在 JiXing 可以完全夺舍 ollama 命令行进行模型管理：

列出所有模型

jixing ollama list

输出格式和 ollama list 一致，显示模型名称、ID、大小和修改时间。

查看模型详情

jixing ollama show gemma3:1b

显示模型的格式、家族、参数量、量化级别等信息。

拉取新模型

jixing ollama pull llama3.2

支持显示下载进度。

删除模型

jixing ollama delete old-model

对话记录与保存

交互模式下，所有对话都会自动保存到 Session 中。每次交互结束后，可以通过以下命令查看历史：

jixing sessions list
jixing sessions get <session-id>

会话信息包括模型名称、消息数量、token 使用量等。

命令简介

模型运行

# 单次运行
jixing ollama run gemma3:1b "Say hello"

# 交互模式（流式输出）
jixing ollama run gemma3:1b -i

# 启用上下文压缩
jixing ollama run gemma3:1b -i --compress

# 指定 Ollama 地址
jixing ollama run gemma3:1b --base-url http://server:11434

模型管理

# 列出模型
jixing ollama list

# 查看模型信息
jixing ollama show gemma3:1b

# 拉取模型
jixing ollama pull llama3.2

# 删除模型
jixing ollama delete old-model

会话管理

# 列出会话
jixing sessions list
jixing sessions list --provider ollama

# 查看会话详情
jixing sessions get <session-id>

# 删除会话
jixing sessions delete <session-id>

# 合并会话
jixing sessions merge <id1> <id2> --mode timeline

搜索与统计

# 搜索消息
jixing search "关键词"

# 查看统计
jixing stats

# 查看系统信息
jixing info

Web 界面

jixing web --port 5000

效果

这套方案解决了几个实际问题：

对话不会因为超限而中断。 系统会自动压缩或迁移，保持对话连续性。

重要信息不会丢失。 基于重要性评分的压缩策略，确保关键内容被保留。

完整历史可追溯。 所有被压缩的对话都归档到 JSONL，随时可以加载。

运行状态可恢复。 即使会话结束，Markdown 文件保留了完整的运行上下文。

压缩率可控。 可以根据需要调整压缩程度，平衡信息保留和上下文空间。

流式输出体验好。 实时看到模型回复，不用等待全部生成完成。

模型管理一体化。 不需要切换到 ollama 命令行，所有操作在 jixing 中完成。

实际测试全部通过，覆盖了压缩、迁移、归档、持久化、CLI 命令所有场景。

写在最后

这个方案的核心思路其实很简单：对话不应该因为上下文限制而丢失，而是应该像数据一样可以被保存、压缩、迁移、恢复。

虚拟机热迁移给了启发——状态可以完整保留，只是换了一个更大的运行环境。对话管理也是同样的道理。

语义压缩则是另一个维度的优化——不是让 AI 总结，而是直接消除文本中的冗余表达，用更短的文字表达同样的意思。

代码已经开源，欢迎试用和反馈。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

大语言模型 · 目录

大语言模型

上一篇FanFu（凡赴）：把 Ollama 的 GGUF 模型转成 HuggingFace 格式，纯好玩下一篇自用的 OpenCode Skills 合集更新：从 6 个技能到 22 个，以及必须承认的问题

搜索「」网络结果

调整当前正文文字大小

100%