一个围绕 AI 团队组织的产品，会自然产生许多专业入口：员工、项目、任务、资料和业务。专业分工越完整，用户第一次开口时反而越容易遇到选择负担：现在该找谁，是否已经需要建一个任务？
小松鼠承担的是这个阶段的关系。用户可以先把问题讲出来，短问题就地处理，需要持续推进的事再进入独立工作。它让团队产品保留一个稳定、容易辨认的交谈对象。
因此，小松鼠既有形象设计，也有工作关系设计。小窗、完整主聊和后台任务不能只是三个相似界面，它们需要准确解释同一段讨论怎样延续，以及什么时候真正交出了执行责任。
窗口可以变，讨论不另起一份
假设你刚和主助手讨论过一场分享的提纲，打开项目检查资料时，又想补充一句“先讲遇到的问题，再讲方法”。如果页面助手另用一段历史，你就得猜它是否知道刚才的决定。
Teloa 让小窗和完整主聊沿用同一会话。短回复在页面旁阅读，长内容和完整过程在更大的视图中处理。切换改变的是空间，先前的讨论继续保留。
离开页面再回来，重新打开的仍是原来的主聊。用户下一次找小松鼠，可以接着刚才的话说，不必先辨认哪一个同名窗口记得上次的讨论。
共用主聊解决的是“刚才的讨论属于哪里”，并没有让助手自动知道屏幕上的一切。我们有意保留这一区别：显示位置可以贴近项目，输入依据仍须明确。否则，用户只是移动了小窗，就可能无法解释回答突然多出了哪份背景。
形象让入口容易辨认，共同的会话则让讨论真正延续。一个悬浮角色只有接到已有讨论和后续工作，才有理由长期留在工作环境里。
这也影响小窗里的信息取舍。短问题适合就地回答，长任务要能进入完整过程；如果把全部任务管理挤进小窗，原本为了就近提问而设计的入口反而会遮住正在看的工作。
一句追问，与一项独立工作
两种说法对应不同的工作需要：
- 一句追问：“这段话是什么意思”，适合直接回答。
- 一项独立工作：“根据这些资料整理一份说明，我稍后来看”，需要保留目标、过程与成果。
若两者都只成为一条聊天消息，长工作就会挤占对话，也难以单独跟进。
当前社区版可以从主聊或小松鼠发起通用独立工作。用户明确交办后，需要到完整主聊中处理这次执行的确认；批准以后，系统才建立独立任务并启动，由通用助手执行，无需先创建员工。
继续前面的分享准备。你可以先在主聊比较两种开场，确定采用“问题—方法”的顺序；需要成稿时，再明确交办“根据我提供的材料整理一份十分钟讲稿”。当前小窗不处理工具确认，需要到完整主聊核对并批准这次执行。
这以后，主聊保留讨论的来路，独立任务承接成稿责任，执行会话处理具体工作，成果入口供你稍后取得和核对内容。你可以继续讨论别的问题，无需让一项长工作占住全部交谈；也不必为了得到一份讲稿，先建立一个长期演讲岗位。
这种分工让开始合作的成本随工作需要增加。最初只需说清问题，交出一项责任时再确认目标与执行，反复出现的工作才值得维护专门岗位。小窗与完整主聊的切换是当前确认路径的安排，真正需要保留的是已经形成的要求能够进入后续工作。
主助手与专业员工，各自保留什么
主助手提供持续沟通的位置，专业员工围绕一类职责工作。研究员工保留来源标准，内容员工保留表达方法，主聊则承接用户临时提出和逐步形成的目标。
两种方式可以并存。用户知道该找谁，就直接找相应岗位；只是想先把问题讲清楚，也可以留在主聊。产品无需让所有工作绕经同一中转者，也不需要把每项独立工作伪装成一个新员工。
收起形象，让出的是屏幕空间
一个长期可达的助手，也需要让人能够暂时不看它。读长文、核对表格时，小松鼠可以移动、收起或隐藏；显示偏好与实际执行分别维护。
这项取舍关系到信任。隐藏形象只应腾出空间，停止任务才改变执行；重新显示入口，也不应重新交办。用户理解动作的后果以后，才能放心把助手留在工作环境里。
用户可以先找一个熟悉的助手说清问题，也可以直接找知道该做什么的专业员工。小松鼠值得始终可达，是因为开始合作时不必先理解整支团队；需要认真交办时，刚才形成的要求又有地方继续。