上下文要独立，感知能扩，能力还得找得到

初衷是分人办事：专职 Agent，上下文分开，别往同一个全能助手里堆。

小队一旦要变大，目录、发现、装配会一起冒出来。这轮主要啃这几块。

工作目录也算上下文

我对 Agent 的定义是互相独立的上下文。聊天记录分开还不够，工作目录也是它能感知到的范围。

每个 Agent 可以有自己的工作目录，默认别互相踩。开发改代码、测试盯复现、资料助手整理文献，磁盘上也少搅在一起。

可感知范围不该锁死在某一个路径。真干活时常要碰到用户本机上的项目盘。所以工作区加了项目根：在「项目」Tab 挂本机目录，写进该次访问的 project_roots；文件工具只允许在 visitCwd + project_roots 里动。

越界不默默放行。审批会提议挂载（project_mount）；你点头后写入再继续。once 只管这一次；session / agent 可以记路径允许，后面同类越界少点几次。敏感路径照样拒。

独立是为了别干扰。能挂载，是需要时把感知撑开。不是一上来把整块硬盘交给同一个 Agent。

人一多，就得会找

Agent 多了，工具多了，最省事是每轮把花名册和工具表全喂进去。人少还凑合；人一多，上下文先炸。

所以发现改成检索。不再每轮塞「小花名册全量」。按用户话术打分，有命中才注入 Top-K；模型也可以主动 agent_search。协作偏好里写着：委托前先搜再派。

MCP 也一样：默认延迟暴露，先 tool_search 再调用，别假设工具已经全声明在上下文里。

实体可以很多。当前这一轮看见的，得少而准。发现不是多一个搜索框，是挡上下文爆炸的闸。

配起来太麻烦，app 就活不了

只有隔离和发现还不够。每个 Agent 都要从零手搓技能的话，通讯录里永远就那几个示范角色。

这轮接上社区 Skill 的搜索和安装，包校验也放宽一点，兼容更多 frontmatter。系统提示里收紧工具选用：能用 grep / find / read / edit 就别滥用 shell，少一次审批，也少一次跑偏。

我想降低装配成本，让里面的 Agent 真的多起来。多起来之后，独立目录和发现才用得上；否则架子搭了，屋里没人。

和时间那条怎么拼

异步编排管等待和接续。这篇管看见什么、找得到谁、装得上什么。

别互相干扰，靠独立 cwd 和会话。偶尔要更大感知，就挂项目根，越界先问你。实体和工具变多，靠检索，不靠全量塞提示。app 要活，还得 Skill 好配。

小队要长大，时间和空间这两边都得有。