你有没有遇到过这种情况：正在用AI写代码，发出去的消息突然变成了"新建任务"，原来的会话就这么断了。不是模型不够聪明，是它太想帮你做决定了。
这个问题困扰我很久。直到我们重新设计了交互逻辑，才意识到核心矛盾不在技术，而在控制权。
两种完全不同的意图
写代码时，用户其实只有两种需求：
一是继续当前会话——我刚让Claude Code改完一个函数，现在要继续调试；
二是需要更高层级的协助——看看整体进度，协调多个任务，决定接下来做什么。
如果这两个入口混在一起，系统就不得不猜。猜对了还好，猜错了直接打断心流。更麻烦的是，这种打断是隐形的：用户以为自己还在跟原来的runtime对话，实际上已经被切走了。
我们做的产品叫CliGate，一个本地AI网关，支持Claude Code、Codex CLI、Gemini CLI等工具。之前的版本和其他产品一样，默认走"助手"路径——每条消息先过一遍意图理解，再由系统决定怎么处理。
这个设计的问题在于：越智能的预判，越不可预测。
拆成两个明确模式
现在的CliGate把交互拆成了两种显式模式：
Direct Runtime（直连运行时）
规则极其简单：消息直接进当前会话，不做任何意图拦截。没有"我觉得你可能想……"，没有惊喜监督层。
这个路径在代码里被优先处理——如果助手模式未激活，消息直接落到runtime路由。一个判断，消掉了大量歧义。
稳定的工具就该"无聊"。用户已经在Codex或Claude Code会话里，下一条消息默认继续这个会话，除非他明确说要不。
Assistant Collaboration（助手协作）
另一条路径需要用户显式调用CliGate Assistant。这时候系统扮演的是监督者角色：检查当前状态、决定复用会话还是新建、选择用哪个工具、跟踪审批和失败、最后汇总回复。
不是终端，是协调员。两个模式不互相冒充，用户清楚自己在跟谁对话。
为什么这改变了架构
表面看是UI调整，实际上重构了整个消息流转。以前所有消息先进一个"智能"黑盒，现在分叉点前置，由用户主动选择而非系统推测。
代价是少了一些"无缝"的魔法感。收益是每次交互都可预期——你知道这条消息会去哪，不会突然从调试模式被拽到任务规划模式。
对于每天写代码的人来说，可预期比智能更重要。AI助手最大的敌人不是不够聪明，是聪明得让人猜不透。
热门跟贴