多个编码 Agent 不该只共享终端：Kota 用项目房间、原生日志与 worktree 把协作留下来
同时开着 Claude Code、Codex 或 OpenCode 时，真正麻烦的往往不是“再启动一个 Agent”，而是协作痕迹立刻碎成几份：每个 CLI 各有会话记录；一个 Agent 改了工作区，另一个只看到过期状态；人负责在不同终端之间转述任务、复制上下文和处理冲突。等任务跨过一次会话，原本的决定、失败尝试与交接理由又很难被找回。
Kota 是一个面向 macOS 的桌面工作区，试图把协作单位从单次会话改为“项目房间（project-scoped room）”。它不提供模型账号或 API Key，而是运行用户已配置好的 Agent CLI，并把各提供商的原生日志投影到一个共享视图。公开仓库的源代码采用 Apache-2.0；不过 Kota 名称、标志和官方视觉资产另有使用规则，不能把它们和源代码许可混为一谈。
这篇文章不把 Kota 描述成自动分配任务的“多 Agent 指挥官”。官方白皮书明确把自动路由和角色发现列为仍由用户主导的方向。它当前更有价值的地方，是把多个 CLI 在同一项目里的状态、记录、隔离工作区和交接面收拢为可检查的本地协作结构。
先换一个边界：项目房间，而不是聊天窗口
Kota 的房间是连续性的边界：人类指令、Agent 活动、时间线、记忆、代码库与工作文档围绕项目组织，而不是附着在某一条聊天线程上。这样的建模解决了一个很实际的问题——模型或 CLI 可以替换，但项目不该因此失忆。
官方资料列出的当前 CLI 支持包括 Claude Code、Codex、Gemini、OpenCode 与 Pi。Kota 用 PTY（伪终端）托管这些用户自带的 CLI，而不是把所有提供商压成同一种 SDK 调用。这个选择有两个直接收益：其一，CLI 新能力暴露后，桌面端不必等待 SDK 对齐；其二，原生 TUI 和交互表面不会被降级成最低公分母的 API。
代价也必须正视。PTY 集成不是无成本抽象：工作状态识别更脆弱，hook 能力受限，不同 CLI 的 TUI 行为与日志格式也会带来持续兼容工作。因此，Kota 更适合作为“保留原生 CLI 使用方式的协作容器”，而不是承诺屏蔽所有提供商差异的统一 Agent API。
共享不等于把所有历史塞进上下文
长任务最容易走向另一个极端：为了让 Agent “知道一切”，每次都把完整历史重新注入上下文。Kota 的白皮书把记忆层称为 Violet，思路是先扫描原生 CLI 的本地会话日志，再生成按时间段划分的 events/ JSONL 文件。该事件层首先标出哪些信息适合人类显示、哪些信息对 Agent 可见。
在这之后，Kota 将记忆分成三类表面：
raw_logs/：面向精确追溯的会话级、参与者级日志；Agent 需要细节时再打开。latest.jsonl与manifest.json：房间级的可读对话投影，并用最近窗口限制避免无限增长。summaries/：当历史达到阈值时生成的摘要层。
这个分层的重点不是“记住更多”，而是让历史可搜索、可按需加载、可回溯。比如审查 Agent 发现一个实现和既定约束不一致时，理想路径不是猜测，而是先从房间记录定位，再回到对应的原始会话日志核对决定来源。对人而言，这也让 Agent 的上下文不再是不可见的黑箱；项目记忆变成可查看的工件。
并行的关键，是把隔离与交接一起设计
多个 Agent 同时编辑同一工作目录，通常会制造比串行更高的返工成本。Kota 的资料把并行 worktree、同步与冲突交接作为协作结构的一部分：并行执行应先拥有隔离工作区，再把需要合并的变化带回项目层处理。
可把它理解为三条简单规则：
- 探索与主线分开。 让一个 Agent 在独立 worktree 里做重构、排错或原型验证，避免它的中间改动直接污染主分支工作区。
- 交接要带证据。 交给下一个 Agent 的不应只是“我做完了”，至少要指向改动、关键命令结果、尚未解决的风险与相关日志位置。
- 冲突不伪装成自动成功。 当两条 worktree 改到同一处，应该把冲突暴露给人或专门的整合步骤，而不是让另一个 Agent 在不了解来由时静默覆盖。
这套方法不替 Git 解决冲突，却能减少“为什么这么改”已经随某个终端关闭而消失的情况。对于需要多轮研究、实现、审查和修复的任务，这种可追溯性交付的价值通常高于多开几个并行窗口本身。
从单人试用到团队流程：先约定最小交接契约
房间、日志和 worktree 不能自动制造协作纪律。首次引入时，建议只为每一项并行任务约定一个最小交接契约：任务目标、隔离 worktree、验证方式、待整合的提交或文件清单，以及尚存的不确定性。这样，审查者面对的不是一段失去上下文的自然语言总结，而是可回到代码和记录核实的线索。
例如，让 Agent A 在隔离工作区验证一个依赖升级，让 Agent B 审查兼容性。A 的交接应说明：测试覆盖了哪条命令、失败是否可复现、改动位于哪些文件；B 则应在自己的审查意见里引用房间中对应的活动或日志，而不是重新猜测 A 的假设。最终由人决定是否合并，或要求 A 补充验证。这里的关键不是把人排除在外，而是把人的判断放在信息仍完整的节点上。
也不要把共享记忆当作永久真相库。项目规则、摘要和工作记录会过时，尤其在依赖版本、架构边界或安全约束改变之后。实践中应把关键结论连接到测试、提交或原始日志，并在重大重构后更新项目级规则。这样，后来的 Agent 看到的是有来源、可推翻的工作记忆，而不是一段无法判断年代的提示词。
还有一个常见失败模式是把“房间里看得到活动”误作“变更已经可安全合并”。日志能解释谁在何时做过什么，却不能替代可重复的测试、差异审查和明确的合并责任。对每次交接，至少应保留工作分支或 worktree 的定位、验证命令及其结果、需要人工裁决的冲突点；若验证尚未运行，也应直接标成未验证。这样，后续参与者不会把可见性当作正确性，更不会把摘要中的旧结论当成当前代码的事实。
一个可复现的本地开发检查
如果目标是从源码验证桌面端，而非直接使用发布版，官方 app-v2/ README 给出了 macOS 前提：Node.js 与 npm、Rust/Cargo、Tauri 2 的 macOS 开发依赖；实际 Agent 会话仍要求自行安装 CLI 并拥有相应提供商账户。仓库中的前端与 Rust 后端分别通过以下命令检查：
cd app-v2 npm install npm run typecheck npm test cd src-tauri cargo test
要启动本地 Tauri 开发窗口，则回到 app-v2 目录执行：
npm run tauri dev
这里有一个容易遗漏的边界：这些命令是在验证或开发 Kota 本身，不等于完成生产环境安装；官方 README 说明签名、公证的 DMG 由发布流水线处理。更重要的是，Kota 不捆绑模型访问凭据。把 API Key 写入项目文件或期待应用替你开通 Provider，都是与其设计不符的使用方式。
适合什么场景，不适合什么场景
Kota 适合已经以 CLI 为主、又开始遇到跨会话协作成本的团队或个人：同一代码库要由不同 Agent 分别做探索、实现和复核；你希望保留各 CLI 的原生体验；同时需要一个按项目集中查看活动与历史的界面。其共享记忆和房间边界尤其适合长周期任务，而不是一次性问答。
反过来，如果需求是无人值守地自动决定每个 Agent 的角色、完全消除合并冲突，或在 Linux/Windows 上直接部署当前桌面预览，就不该把 Kota 当作现成答案。公开资料将当前桌面端定位在 macOS，且明确承认 PTY 兼容性与自动角色发现仍有边界。先把它作为“让协作过程可见、可检索、可交接”的工具试用，再评估是否要把它放进日常开发链路，会更稳妥。