问题
Kimi Code 现在有多种运行面:终端 TUI、桌面客户端、kimi -p 无头、kimi web、ACP(编辑器插件)。但模型在会话中无法可靠感知自己运行在哪个面,系统提示层面没有任何结构化的宿主标识:
- 系统提示模板变量里没有 surface / client 字段(见
packages/agent-core-v2/src/app/agentProfileCatalog/profile-shared.ts 的 systemPromptVars)。
- 唯一与面相关的内容是
${reply_style_guide} 散文:CLI 默认值为 "Your text replies render as Markdown in the user's terminal."(profile-shared.ts:110 的 DEFAULT_REPLY_STYLE_GUIDE);桌面端通过 replyStyleGuide 覆盖成桌面文案(packages/kap-server/src/start.ts:221)。
- 结果是 TUI、
kimi -p、ACP 拿到完全相同的 "terminal" 文案,模型据此自述"运行在终端"。
复现(kimi-code 0.43.1, macOS)
无头会话 kimi -p,提问:"你的系统提示中有没有明确告诉你当前运行在哪种宿主环境?"
模型回答(基线):
有。原话:"You are Kimi Code CLI, an interactive general AI agent running on a user's computer." / "Your text replies render as Markdown in the user's terminal." …… 即系统提示表明宿主环境是 macOS 上的终端 CLI
即无头会话被提示词描述为"终端",模型也如此自述。
harness 其实知道,但没有告诉模型
同一无头会话的 SessionStart hook payload:
{"hook_event_name":"SessionStart","session_id":"...","cwd":"...","client_type":"kimi_code_cli","source":"startup","model":"kimi-code/kimi-for-coding","profile":"agent"}
client_type 来自 KimiHostIdentity.platform(packages/oauth/src/identity.ts:18-29,注释明确列出取值如 kimi_code_cli、kimi_code_desktop;注入点 packages/agent-core-v2/src/features/externalHooks/app/externalHooksRunnerService.ts:93)。但该字段:
- 只进 hook payload,不进模型上下文;
- hooks 文档 的示例只写了
kimi_code_cli,其余取值没有文档化,插件作者无从知晓。
影响
- 无头/CI 场景下模型给出依赖交互的指引(快捷键、
/ 命令面板、"点按钮");
- 桌面端与 TUI 的交互差异(如
/plugins 面板、Tab/Space 键)无法被模型区别对待;
- 插件/Skill 想做面适配只能靠进程树考古;嵌套场景(在某 surface 内再 spawn
kimi -p)启发式必然不可靠——实测 workaround 插件在此场景判对纯属祖先链顺序巧合。只有 harness 的 platform 字段是 ground truth。
建议
- 系统提示模板增加
${surface}(或等价变量),取值与 KimiHostIdentity.platform 对齐,并覆盖全部运行面(TUI / desktop / web / ACP / headless);
- 文档化 hook payload
client_type 的全部取值;
- (可选)
kimi -p 场景下 DEFAULT_REPLY_STYLE_GUIDE 不应再写 "user's terminal"。
临时方案(社区 workaround)
我写了一个 sessionStart 探测插件(进程树 + TTY 启发式),同一个无头会话里把模型的自述从"终端"修正为"headless"并给出进程链证据。这验证了"模型并非不想知道,而是 harness 没告诉它"。但启发式无法覆盖嵌套/未来 surface,建议在 harness 层暴露。
问题
Kimi Code 现在有多种运行面:终端 TUI、桌面客户端、
kimi -p无头、kimi web、ACP(编辑器插件)。但模型在会话中无法可靠感知自己运行在哪个面,系统提示层面没有任何结构化的宿主标识:packages/agent-core-v2/src/app/agentProfileCatalog/profile-shared.ts的systemPromptVars)。${reply_style_guide}散文:CLI 默认值为"Your text replies render as Markdown in the user's terminal."(profile-shared.ts:110的DEFAULT_REPLY_STYLE_GUIDE);桌面端通过replyStyleGuide覆盖成桌面文案(packages/kap-server/src/start.ts:221)。kimi -p、ACP 拿到完全相同的 "terminal" 文案,模型据此自述"运行在终端"。复现(kimi-code 0.43.1, macOS)
无头会话
kimi -p,提问:"你的系统提示中有没有明确告诉你当前运行在哪种宿主环境?"模型回答(基线):
即无头会话被提示词描述为"终端",模型也如此自述。
harness 其实知道,但没有告诉模型
同一无头会话的 SessionStart hook payload:
{"hook_event_name":"SessionStart","session_id":"...","cwd":"...","client_type":"kimi_code_cli","source":"startup","model":"kimi-code/kimi-for-coding","profile":"agent"}client_type来自KimiHostIdentity.platform(packages/oauth/src/identity.ts:18-29,注释明确列出取值如kimi_code_cli、kimi_code_desktop;注入点packages/agent-core-v2/src/features/externalHooks/app/externalHooksRunnerService.ts:93)。但该字段:kimi_code_cli,其余取值没有文档化,插件作者无从知晓。影响
/命令面板、"点按钮");/plugins面板、Tab/Space 键)无法被模型区别对待;kimi -p)启发式必然不可靠——实测 workaround 插件在此场景判对纯属祖先链顺序巧合。只有 harness 的 platform 字段是 ground truth。建议
${surface}(或等价变量),取值与KimiHostIdentity.platform对齐,并覆盖全部运行面(TUI / desktop / web / ACP / headless);client_type的全部取值;kimi -p场景下DEFAULT_REPLY_STYLE_GUIDE不应再写 "user's terminal"。临时方案(社区 workaround)
我写了一个 sessionStart 探测插件(进程树 + TTY 启发式),同一个无头会话里把模型的自述从"终端"修正为"headless"并给出进程链证据。这验证了"模型并非不想知道,而是 harness 没告诉它"。但启发式无法覆盖嵌套/未来 surface,建议在 harness 层暴露。