xianliticn
fd0f8b9a24
All checks were successful
Build and Deploy Qingshuige / build-deploy (push) Successful in 1m28s
15 lines
2.1 KiB
Markdown
15 lines
2.1 KiB
Markdown
---
|
||
title: AI客户端的上下文问题
|
||
date: 2026-06-18T03:12:00.000+08:00
|
||
author: 线粒体
|
||
---
|
||
我感觉虽然现在LLM大发展，但是应用端的软件还不是很完善，特别是一些平时不会注意到但很核心的功能。
|
||
|
||
比如AI聊天客户端——就拿Cherry Studio来说吧——在第一轮对话中，模型调用MCP工具获得一些内容，然后输出回答。紧接着第二轮对话中，Cherry Studio就会丢弃第一轮中MCP工具获取的内容，只发送用户的问题和模型的回答作为上下文。这就会导致从第二轮对话开始，每一轮对话都可能缺失完整的上下文，从而有效信息越来越少，最后自说自话。
|
||
|
||
我们对于客户端的期望是，能够尽可能长时间多轮次工作而不丢失回答质量。显然这样的策略并没有落实到Cherry Studio中。
|
||
|
||
我想出来的一个很不雅的解决方法是：在所有MCP服务器前面挂一个透明代理，每次调用工具的时候，都把工具的返回缓存到本地文件。再在客户端上挂一个脚本，每轮对话都自动读取缓存的文件，作为上下文一并上传。这样能勉强解决问题，但是治标不治本。其本在于，目前的客户端没有一个比较统一的上下文处理策略。各家客户端处理上下文的方式都不怎么公开透明，什么时候压缩，什么时候裁切，都无法精细控制。这方面做得比较好的是Codex CLI和Claude Code——它也不敢做得不好，因为服务的是开发者，代码上下文要是随意裁掉，是要出大问题的。但是普通用户用这些工具问问题，就给人一种很奇怪的感觉。我们用Cherry Studio的原因，就是因为它支持的提供商多，GUI比较方便，上传文件、配置MCP什么的也比较直观。结果它在上下文这个要命的问题上出了岔子，那地位就很尴尬了。
|
||
|
||
总之，现有的AI客户端都处于一种各自为政的状态。毕竟LLM的接口才刚基本统一没多长时间，各种协议也还在野蛮生长期，只能等待社区和开发者的贡献了。或许有机会的话，我也可以贡献一点点。
|