
人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载本文围绕 Kun 项目中 Work 办公模式文本写作场景的双模式补全方案展开它将原本单一路径的 ghost text幽灵文本拆分为心流状态下的「短补全」short与停顿思考时的「灵感长补全」long两者共享编辑器上下文与服务端请求链路但各自拥有独立的触发条件、prompt、token 预算与质量过滤规则。读完本文你将掌握两种模式的判定逻辑、双计时器调度机制、本地候选评分过滤原理、与 RAG 检索的关系以及设置页中每一项参数的默认值与源码出处能够在实际部署与调参时做到有的放矢。为什么要拆成两套补全策略写作补全天然存在两个互相冲突的目标心流输入时用户正在快速敲字需要的是低延迟、短、准、不打扰的补全最好就像「下一串键入」。停顿思考时用户停住笔头等待灵感需要的是更完整的下一句或下一段帮助接住即将溜走的思路。如果只用一套策略会出现两类典型问题触发太积极长补全打断正在输入的节奏用户被迫频繁按 Esc。触发太保守用户真正停住时只给一两个词缺少启发价值。因此当前自动触发的 ghost text 路径被拆成short与long两个 mode它们共享编辑器上下文和同一套 IPC/service 请求链路但使用不同的触发条件、prompt、token 预算和质量过滤。同一套 IPC/service 还包含面向选区编辑的手动editmode其行为由独立的 inline edit 链路承载详见 docs/WRITE_INLINE_EDIT_RAG.zh-CN.md英文版见 docs/WRITE_INLINE_EDIT_RAG.en.md。总体架构双模式补全的整体数据流如下核心实现分布在前端渲染进程与主进程两层层次文件职责渲染进程codemirror.tsCodeMirror 插件双计时器、请求调度、ghost text 渲染、Tab/Esc 键绑定渲染进程policy.ts短/长补全的触发判定函数渲染进程prompt.ts构造发往主进程的补全请求 payload含 policy、signals渲染进程feedback.ts候选质量评分、边界归一化与拒绝决策渲染进程context.ts从 CodeMirror state 抽取窗口化上下文与 Markdown 结构信号主进程write-inline-completion-service.tsservice 入口聚合主进程write-inline-completion-request.tsFIM/chat completions 路由、token 预算、RAG 检索、超时与 debug 记录主进程write-inline-completion-prompt.tsprompt/chat messages 构建与响应清洗共享write-inline-completion.ts模式、请求与结果类型定义模式定义与请求协议模式类型定义在 write-inline-completion.ts 中export type WriteInlineCompletionMode short | long | edit补全请求会携带{ mode?: short | long | edit }未传 mode 时默认视为short这一兼容逻辑在渲染进程的buildInlineCompletionPayloadoptions.mode ?? short与主进程的resolveMode见 write-inline-completion-prompt.ts中双重实现保证旧调用路径不受影响。edit复用同一请求类型仅用于显式 inline replacement本文重点说明两个自动 ghost text 模式。请求体WriteInlineCompletionRequest除mode外还包含丰富的结构化字段值得逐项了解prefix/suffix光标前后窗口化文本服务端 FIM 引擎直接使用cursor光标所在行号与列号context.signals一组布尔信号包括list、quote、heading、table、atLineEnd、endsWithSentencePunctuation、previousLineEndsWithSentencePunctuation、prefersNewLineCompletion、paragraphBreakOpportunity它们是触发判定与 prompt 注入的核心依据policy由name、instruction、acceptanceCriteria、rejectionCriteria组成的策略对象随请求注入模型editCandidate/recentEditsinline edit 模式使用的可编辑范围与最近编辑历史model可选的模型覆盖。这些信号在渲染进程由 context.ts 从 CodeMirror state 计算得出。值得注意的实现细节是上下文只取窗口而非整篇文档——prefix窗口默认 1600 字符、suffix窗口默认 900 字符常量定义见 constants.ts注释明确指出在大文档上直接切片窗口避免了每次触发补全时复制全文档的开销。短补全心流状态下的「下一串键入」短补全面向心流输入目标是让补全看起来像用户接下来要打的几个键。触发条件短补全使用基础策略shouldRequestInlineCompletion实现见 policy.ts补全总开关开启isEnabled回调为真当前光标不是选区selection 为空光标后一个字符不是单词字符nextCharIsWord为 false避免打断正在拼写的词当前文档有足够上下文文档非空、prefix 窗口去空白后非空不是 URL 尾部looksLikeUrlTail为 false空白行必须有结构化上下文如列表、引用、标题或段落机会才允许触发局部信号与文档信号至少要满足其一当前行前缀去空白后不少于 3 个字符或文档预览上下文不少于 16 个字符INLINE_COMPLETION_MIN_CONTEXT_CHARS或有结构化上下文/段落机会。默认参数参数默认值含义源码常量debounce650 ms停止输入多久后请求INLINE_COMPLETION_DEBOUNCE_MS最小请求间隔1400 ms同模式两次请求最小间隔INLINE_COMPLETION_MIN_REQUEST_INTERVAL_MSmax tokens96FIM 最大生成长度DEFAULT_WRITE_INLINE_COMPLETION_MAX_TOKENSmin accept score0.52本地候选显示阈值INLINE_COMPLETION_MIN_ACCEPT_SCOREmax visible chars220ghost text 最大字符数INLINE_COMPLETION_MAX_VISIBLE_CHARSmax visible lines6ghost text 最大行数INLINE_COMPLETION_MAX_VISIBLE_LINESRAG snippets3最多注入 3 个检索片段request 服务中maxSnippetsPrompt 策略短补全的 prompt 强调渲染进程的buildInlineCompletionPayload与主进程的buildWriteInlineCompletionPrompt共同体现只返回插入文本不返回解释、围栏、XML 或 action 标记局部上下文模糊时宁可返回空响应不重复光标后的 suffix 文本不发散新主题保持 Markdown 结构、缩进与当前语气。短补全对应策略名precision-inline-v2其 rejection criteria 明确要求跳过「仅复述前文」「开启当前块未支撑的新主题」「过长、泛化或推测性」的候选。质量过滤短补全会更严格地惩罚见 feedback.ts 的evaluateInlineCompletionCandidate过长候选超过 140 字符或 3 行即施加 0.14 长度惩罚与 suffix 重复的候选直接以already-in-suffix拒绝重复检测redundancyPenalty命中即返回 1 分惩罚在完整句子后硬接词的候选当prefersNewLineCompletion为真且候选以词字符开头时sentenceBoundaryPenalty达 0.42超过 0.4 拒绝线直接拒绝过于泛化的开头genericPenalty对以 the/this/that/it/然后/这里/这个 等泛化引导词开头的候选施加 0.18 惩罚空响应冷却同一位置的空响应会被记录并进入冷却防止反复空请求详见下文调度章节。这些惩罚让短补全更像「下一串键入」而非 AI 主动写作。灵感长补全停顿后的「给我一点可继续写的东西」灵感长补全面向用户停顿之后的启发时刻。触发条件长补全基于短补全基础条件再叠加额外限制shouldRequestLongInlineCompletion长补全开关开启isLongEnabled通过短补全基础判定光标必须在行尾isAtLineEnd当前行后面没有剩余文本currentLineSuffixTrimmed为空不在表格上下文中hasTableContext为 false不在标题上下文中hasHeadingContext为 false当前文档或局部上下文达到更高信号量文档上下文不少于 80 字符INLINE_LONG_COMPLETION_MIN_CONTEXT_CHARS或当前行前缀不少于 12 字符或有结构化上下文/段落机会当前行以单词字符结束时需要更长的局部信号局部信号 ≥ 12 字符避免在半个词处触发。这些限制确保长补全只在「用户真的停住了」的地方出现即行尾/段落边界。默认参数参数默认值含义源码常量debounce2800 ms更长停顿后触发INLINE_LONG_COMPLETION_DEBOUNCE_MS最小请求间隔4500 ms长补全请求最小间隔INLINE_LONG_COMPLETION_MIN_REQUEST_INTERVAL_MSmax tokens256允许约一段的续写灵感DEFAULT_WRITE_INLINE_LONG_COMPLETION_MAX_TOKENSmin accept score0.36比短补全更宽松INLINE_LONG_COMPLETION_MIN_ACCEPT_SCOREmax visible chars900ghost text 最大字符数INLINE_LONG_COMPLETION_MAX_VISIBLE_CHARSmax visible lines14ghost text 最大行数INLINE_LONG_COMPLETION_MAX_VISIBLE_LINESRAG snippets5最多注入 5 个检索片段request 服务中maxSnippetsPrompt 策略长补全会在 prompt 前加入隐藏注释主进程buildWriteInlineCompletionPrompt中 mode 为 long 时注入!-- DeepSeek GUI inline completion mode: long inspiration. The user paused at the cursor. Continue the draft with a grounded next thought... Return only insertable text... --它明确告诉模型用户是停顿寻求灵感可以给更完整的下一句或下一段仍然必须贴合当前草稿不得总结文档、不得生成整篇文章优先一段紧凑的续写或短列表延续而非全文大纲或泛化头脑风暴检索到的参考片段仅用于术语、事实连续性与风格提示不得在返回文本中提及。长补全对应策略名inspiration-inline-v1其 acceptance criteria 额外允许「提供有用的下一个想法但不得接管整个草稿」。质量过滤长补全复用短补全的重复检测、句边界检测和泛化惩罚但放宽长度限制并降低初始阈值长度惩罚放宽为超过 760 字符或 10 行才施加 0.08 惩罚评分基础分从短补全的 0.34 降至 0.40结构化 action 返回时 0.48显示阈值从 0.52 降至 0.36。这样长补全可以显示更完整的段落同时仍然避免重复现有 suffix、突然开新主题、输出过长整篇内容、在不适合的位置插入大段文本。双计时器调度与过期保护编辑器插件内部维护两个 timercodemirror.ts 的inlineCompletionControllershortTimerlongTimer每次文档、选区或焦点变化时执行调度流程sequence 1使所有在途请求的 id 失效清掉旧 timer重新计算上下文如果可短补全设置短 timer如果可长补全设置长 timer长补全 debounce 更长因此两个 timer 可并存。请求返回时会执行三重过期检查当前 request id 是否仍是最新sequence编辑器 state 是否仍是发起请求时的 state引用相等比较当前光标位置是否仍匹配发起时的 anchor。如果用户继续输入旧请求自然失效不会把过期补全插入界面。除 debounce 外调度层还有一套「防打扰」节流机制这是原文档之外源码中非常关键的设计最小请求间隔short 1400 ms、long 4500 ms超频时用setTimeout延迟到间隔满足后再发同模式在途互斥inFlightModes集合防止同一模式并发请求若在途则记入pendingAfterInFlight返回后再重新调度空响应冷却同一上下文签名mode、文件、光标、行内容等拼接而成返回空候选后进入 10 秒冷却INLINE_COMPLETION_EMPTY_COOLDOWN_MS30 秒窗口内INLINE_COMPLETION_EMPTY_BURST_WINDOW_MS连续 3 次INLINE_COMPLETION_EMPTY_BURST_LIMIT空响应触发 8 秒全局冷却INLINE_COMPLETION_EMPTY_GLOBAL_COOLDOWN_MS避免弱模型反复产生空结果造成无意义请求。本地候选质量评分机制反馈与评分逻辑集中在 feedback.ts是「本地过滤不过时不展示」原则的落地。其核心是一个加权评分函数evaluateInlineCompletionCandidate加分项Boost连续性加分continuityBoost光标前以词字符结尾且候选以词/字母/数字开头 0.2以标点结尾且候选以标点开头 0.08句末标点后换行 0.12结构加分structuralBoost结构化上下文 0.12、列表上下文 0.1、引用上下文保持标记 0.08、匹配当前缩进 0.08段落开头加分paragraphStartBoost段落机会处 0.22。减分/拒绝项Penalty冗余惩罚redundancyPenalty候选与 suffix 开头重复 → 直接拒绝already-in-suffix与 prefix 尾部重复 → 扣 0.45句边界惩罚sentenceBoundaryPenalty完整句后硬接词 → 扣 0.42≥0.4 拒绝泛化惩罚genericPenalty泛化引导词开头扣 0.18无意义的 1~2 字符候选非有用单 token扣 0.22长度惩罚lengthPenalty见上文短/长两套阈值。防御性校验空文本、纯空白 →empty-candidate/blank-candidate拒绝协议标记残留正则/[ \t]*(?:SHORT|LONG|EDIT|PREFIX|SUFFIX|EDIT_SCOPE)\b/i命中即按marker-artifact拒绝——即使后端已清洗防御纵深确保畸形标记骨架绝不进入 ghost text 渲染normalizeCompletionBoundary当光标前后均为词字符时自动在候选前补一个空格避免「词黏词」长度/行数超限拒绝short 220 字符/6 行、long 900 字符/14 行。最终得分低于minAcceptScoreshort 0.52 / long 0.36时以low-confidence拒绝每次决策都会通过onFeedback上报phase: candidate的反馈记录含决策、原因、分数与预览供 UI 与后续调参使用。与 RAG 的关系双模式补全和跨文本检索是两层正交能力双模式决定「什么时候补、补多长、用什么策略补」RAG 决定「补全前参考哪些跨文本片段」。在主进程 write-inline-completion-request.ts 中检索由retrieveWriteInlineCompletionContext完成短补全maxSnippets 3注重局部流畅候选更短长补全 / editmaxSnippets 5注重灵感连续prompt 明确提示停顿续写。检索到的片段在 write-inline-completion-prompt.ts 的buildRetrievalPromptBlock中注入 prompt包含索引文件/块统计、查询关键词以及每个片段的精确位置PDF 按页码、文本按行号区间同时明确约束模型「仅将片段用于术语、事实连续性与风格不得在返回中提及片段」。若用户在设置中关闭检索则请求退化为纯 FIM 补全。设置项与默认值设置页提供以下开关与参数启用幽灵文本补全write.inlineCompletion.enabled跨文本检索增强write.inlineCompletion.retrievalEnabledFIM API 地址write.inlineCompletion.baseUrl默认为 DeepSeek 兼容地址补全模型write.inlineCompletion.model默认deepseek-v4-flash可inheritModel继承全局模型短补全触发延迟debounceMs短补全显示严格度minAcceptScore短补全最大长度maxTokens灵感长补全开关longCompletionEnabled灵感长补全触发延迟longDebounceMs灵感长补全最大长度longMaxTokens另含longMinAcceptScore。默认值定义在 app-settings-types-provider.ts与原文档中引用的src/shared/app-settings.ts同属设置类型体系DEFAULT_WRITE_INLINE_COMPLETION_DEBOUNCE_MS 650DEFAULT_WRITE_INLINE_COMPLETION_MAX_TOKENS 96DEFAULT_WRITE_INLINE_COMPLETION_MIN_ACCEPT_SCORE 0.52DEFAULT_WRITE_INLINE_LONG_COMPLETION_DEBOUNCE_MS 2_800DEFAULT_WRITE_INLINE_LONG_COMPLETION_MAX_TOKENS 256DEFAULT_WRITE_INLINE_LONG_COMPLETION_MIN_ACCEPT_SCORE 0.36设置的规范化与解析逻辑见 app-settings-write.tsnormalizeWriteInlineCompletionModel、resolveWriteInlineCompletionBaseUrl等旧版本设置的默认值迁移由 settings-store.test.ts 验证加载后longCompletionEnabled true、longMaxTokens 256等。服务端请求链路FIM 与 Chat Completions 的选择主进程 write-inline-completion-request.ts 的requestWriteInlineCompletion是请求出口其路由逻辑决定了两条不同的补全通道const useChatCompletions mode edit || actionMayEdit const useFimCompletions !useChatCompletions configuredEndpointFormat chat_completions isDeepSeekInlineCompletionBaseUrl(baseUrl)自动 short/long ghost text当端点为 DeepSeek 兼容地址且格式为 chat_completions 时直接请求 FIM/beta/completionsupstreamDeepSeekFimCompletionsUrlprompt 以「指令注释块 raw prefix」拼接显式mode: edit或可能返回 action 的请求走 chat completionsmessages 形式使用 TextIDE 风格的动作块协议SHORT ... /LONG ... /EDIT ... 让模型自行决定返回类型自定义端点支持/chat/completions、/completions、/responses、/messages四种结尾格式自定义完整端点 URL 若不匹配其中一种会直接返回错误Responses Lite对 Codex/ChatGPT 等responsesMode: lite的 provider 走 Responses API 轻量通道。token 预算同样按模式区分mode long || mode edit || actionMayEdit时使用longMaxTokens256否则使用maxTokens96。整个请求有 12 秒超时INLINE_COMPLETION_TIMEOUT_MS每次请求都会写入 debug 条目最多保留 120 条prompt/响应文本裁剪至 8 万字符供listWriteInlineCompletionDebugEntries排查。响应清洗同样按模式处理cleanCompletionText会剥掉模型误包的三重反引号围栏与成对引号extractWriteInlineAction负责解析 action 块并剔除纯协议骨架回显弱模型逐字复述占位符的情况永远不会成为真实建议。用户体验原则这套设计的核心是「不抢笔」用户正在快速输入时只出现短补全用户停顿较久2800 ms时才出现长补全长补全只在行尾/段落边界出现Tab 接受Esc 隐藏本地过滤不过时不展示API 或检索失败时静默消失不打断输入。渲染层将补全实现为 CodeMirror 的WidgetTypeInlineCompletionWidget以cm-inline-completion样式渲染 ghost textedit模式的替换预览则用箭头指示替换位置。键位绑定Prec.highest保证 Tab/Esc 优先于其他默认键位。失败降级任意环节失败都不会影响编辑器输入设置关闭不请求enabled false直接返回失败并记录 preflightAPI Key 缺失返回失败不显示检索失败retrieveWriteInlineCompletionContext(...).catch(() null)退化为普通 FIMFIM 失败不显示候选低分本地过滤拒绝不显示用户继续输入sequence推进导致旧请求失效。测试覆盖相关测试集中在三个文件write-inline-completion-service.test.tsapp-ipc-schemas.test.tssettings-store.test.ts重点覆盖的行为包括自动 short/long ghost text 请求走 FIM/completions测试断言 URL 为https://api.deepseek.com/beta/completions且不含/chat/completions显式mode: edit或可能返回 action 的请求走 chat completions断言 body 含messages而无prompt短补全默认 mode请求未传 mode 时按 short 处理长补全使用独立 prompt 与 token budget设置默认值迁移旧配置加载后长补全开关与longMaxTokens 256生效自定义端点的格式校验必须以/chat/completions、/completions、/responses或/messages结尾IPC schema 接受mode: long与mode: edit后者由 inline edit 测试与文档docs/WRITE_INLINE_EDIT_RAG.zh-CN.md覆盖。后续优化方向原文档列出的演进方向在实现中已有部分雏形其余仍待落地给长补全增加单独的显示样式区别「下一串键入」与「灵感续写」增加「只在空行触发长补全」的更安静模式当前已具备空响应冷却与全局冷却的节流基础用接受率反馈自动调整长补全 debounceonFeedback已上报phase: interaction的 accept/dismiss 数据可作为调参输入为不同工作空间保存独立补全偏好在 RAG 命中较弱时提高长补全阈值减少发散长补全已有独立的longMinAcceptScore配置位可在此基础上按检索强度动态调整。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐arduino-cli 命令行补全Tab 补全配置与实现原理指南arduino cli 命令行补全Tab 补全配置与实现原理指南 arduino cli 内置了面向 bash 、 zsh 、 fish 、 powersh开发工具嵌入式Kun Work 跨文本 BM25 关键词检索 RAG本地写作补全的轻量检索增强实现解析Kun Work 跨文本 BM25 关键词检索 RAG本地写作补全的轻量检索增强实现解析 导读 本文讲解 Kun 桌面应用中 Work 办公模式的 跨文本人工智能AI Agent自主智能体桌面应用MCP ClientsBazel 命令行补全Tab 补全配置指南Bash、Zsh 完整安装与源码级原理Bazel 命令行补全Tab 补全配置指南Bash、Zsh 完整安装与源码级原理 本篇技术指南围绕 Bazel 的命令行补全Command Line C构建工具上一篇CKEditor 5 Undo 撤销/重做功能完全指南选择性撤销、命令 API 与底层实现原理下一篇upb util 库解析基于公开 API 构建的 def_to_proto 与 required_fields 工具集创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考