AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载导读TowerInit是 Kimi Codeagent-core-v2中 Tower 多 Agent 编排功能的起点工具它负责在当前仓库创建.tower/工作区骨架comms 通信区、inbox 收件箱、findings、reviews、missions、活动日志、worktree 槽位供 TowerPlan/TowerSpawn/TowerMerge/TowerTeardown 及共享的 TowerSend/TowerInbox/TowerFinding/TowerReview/TowerMission/TowerStatus 整套工具共同运作。读完本文你将掌握Tower 模式的开启前提/tower on与实验开关、TowerInit的完整行为契约幂等、会话接管、base 分支解析与校验、.tower/的目录结构与底层存储实现以及初始化失败的各种边界场景与正确处置方式。一、TowerInit 是什么整套 Tower 协议的入场券在 Kimi Code 的 agent-core-v2 中Tower 是一套“多 Agent 单仓库并行协作”的编排协议多个 worker/reviewer 子代理在互相隔离的 git worktree 中工作经由 review 门禁review-gated merge protocol合入分支。整套协议的工具族被定义为 10 个编排工具加 1 个初始化工具见 tower.ts 与 towerService.ts编排工具TowerPlan、TowerSpawn、TowerMerge、TowerTeardown共享通信工具TowerSend、TowerInbox、TowerFinding、TowerReview、TowerMission、TowerStatus初始化工具TowerInitTOWER_MODE_TOOLS [TowerInit, ...TOWER_TOOL_NAMES]TowerInit是这一整套工具集得以运行的前提——它创建协议赖以落盘的.tower/工作区。其工具定义位于 init.ts执行逻辑位于 initTool.ts描述文本来自 init.md通过import DESCRIPTION from ./init.md?raw直接注入。适用场景判断Tower 模式并非所有任务都需要。官方描述明确仅在任务足够大、足以拆分成多个并行 Agent、且需要隔离 git worktree 与 review 门禁合并协议时才使用 Tower。小任务直接由主 Agent 完成即可开启 Tower 反而引入不必要的编排开销。二、前置条件Tower 模式必须已开启且只有用户能开启TowerInit的第一条硬性约束是调用前 Tower 模式必须已激活而只有用户才能激活它Agent 永远不能自行进入。用户通过/tower on开启从代码实现看这一约束被双重强制工具执行前拦截initTool.ts 检查this.tower.isActive未激活时直接返回错误TOWER_MODE_USER_ENABLED_ONLY见 support.ts“tower mode is not active — only the user can enable it (with /tower on), never the agent. Ask the user to turn tower mode on, then drive the tower protocol.”只有主 Agent 可用initTool.ts 检查this.scopeContext.agentId ! MAIN_AGENT_ID返回TOWER_MAIN_AGENT_ONLY“Tower orchestration tools are only supported by the main agent”。此外Tower 目前是实验性功能需要显式开启实验开关才能使用见 flag.ts环境变量KIMI_CODE_EXPERIMENTAL_TOWER1或配置文件config.toml中设置[experimental] tower true若实验未开启工具执行会收到拒绝信息见 towerService.ts 与 tower.tstower 工具是惰性的需要重新启用实验刚开启时可能需要重启进程后才能驱动 tower 协议。/tower base与 requestedBase用户开启 Tower 模式时可以同时指定 base 分支/tower base。该值被记录为towerBaseKey见 towerService.ts 的requestedBasegetterTowerInit在不显式传base参数时会优先使用这个值作为 base见 initTool.tsargs.base ?? this.tower.requestedBase。开启 Tower 模式本身就会执行一次工作区接管adoption详见 towerService.ts 的adoptTowerRoster()而TowerInit则是显式的、幂等的方式再次声明接管。三、核心行为契约幂等创建、绝不重置TowerInit的核心语义在 init.md 中描述得很清楚并由 store.ts 的TowerStore.init()落实3.1 幂等性已存在则报告绝不重置若.tower/工作区已初始化再次调用TowerInit会返回created: false并保留全部既有状态missions、roster、worktrees、日志绝不会清空重建。若再次传入的base与工作区已记录的 base 不同该参数会被忽略并提示ignoredBase见 initTool.tsrequested base ... ignored — the existing workspace already records base ...。想更换 base必须先TowerTeardown再重新初始化。测试用例完整验证了这一契约store.test.ts 验证二次 init 返回created: false且 missions 保留store.test.ts 验证冲突 base 被忽略、已记录 base 保持。3.2 跨会话接管新会话采纳工作区从新的 CLI 会话重新进入 Tower 时TowerInit会“采纳”既有工作区但语义上有明确的边界前一会话 spawn 的 roster 条目会被退役retire这些 Agent 的 id 无法跨会话恢复resume必须用TowerSpawn重新 spawn 新 worker 来继续它们对应的工作。missions、worktrees、activity log 原样保留任务、工作树和日志跨会话延续。其底层实现是adoptForeignRosterstore.ts当state.sessionId ! 当前 sessionId时把旧会话的 roster 条目过滤出来退役将state.sessionId更新为当前会话并在活动日志记录adopt事件含previous与retired。对应测试见 store.test.ts。需要注意的所有权冲突如果工作区被一个仍然存活live的会话拥有priorOwner存在、不等于当前会话 id、且该会话仍在 sessionManager 中TowerInit会直接拒绝并抛出TowerProtocolError见 initTool.ts——因为采纳会退役那个会话的 roster。正确做法是回到那个会话使用 tower或先关闭它。3.3 初始化返回信息TowerInit成功后返回多行结构化输出见 initTool.ts核心字段对应TowerInitResultstore.ts字段含义created是否新创建工作区true为首次初始化false为已存在base生效的 base 分支名ignoredBase被忽略的冲突 base 请求仅 re-init 且 base 不一致时出现checkout主 worktree 当前检出分支detached HEAD 时为HEADretiredAgents本次接管退役的旧会话 roster 条目openMissions接管时仍处于打开状态未 merged/abandoned的 mission 列表同时输出以下提示checkout 与 base 不一致时note: the main checkout is on X, not base Y — merges stay blocked until it is switched over (git checkout Y)若为 detached HEAD 则提示note: the main checkout is in a detached HEAD state — merges stay blocked until the base is checked out (git checkout Y)。存在 carry-over 的 open missions 时这些 mission 的 scope 仍被保留reserved继续它们需TowerSpawn新 worker若属于无关的旧任务应先用TowerMission statusabandoned放弃否则新计划无法使用那些文件。退役 roster 条目时提示它们的 Agent 属于已死的会话、无法恢复missions 与 worktrees 保留用TowerSpawn新 worker 继续。结尾固定提示Tower mode is active and the tower tool set is enabled.以及下一步指引——用TowerPlan拆分每个 mission 对应互不相交的文件 scope再为每个 missionTowerSpawn一个 worker指派 reviewer只有 clean review 之后才用TowerMerge合并。四、base 分支mission 分叉与合并的锚点base是TowerInit唯一的可选参数见 init.ts 的 zod schemaz.string().min(1).optional()也是整套协议最重要的配置。4.1 base 的角色base是每个 mission 分叉fork和合并回去merge back的本地分支。它会被记录在工作区整个生命周期内missions、reviews、merge 门禁全部以它为基准评估。因此官方建议在 init 时慎重选择re-init 报告既有工作区时会保留已记录的 base。4.2 解析优先级base 的解析优先级为见 initTool.ts 与 store.ts显式传入的base参数用户开启 Tower 模式时通过/tower base指定的 basetower.requestedBase主 worktree 当前检出的分支。4.3 只接受本地分支base 必须是本地分支remote-tracking 引用如origin/main和 tag 都不被接受因为合并最终要落在本地分支上。校验逻辑见 store.ts 的assertLocalBaseBranchbase branch X does not exist as a local branch — merges land on a local branch, so remote-tracking refs and tags are not accepted; create a local branch first。对应测试store.test.ts验证origin/main和不存在分支no-such-branch都会被拒绝且工作区保持未初始化状态。4.4 边界情况detached HEAD 与 checkout 不一致detached HEAD 且未显式传 base拒绝初始化报cannot determine the base branch from a detached HEAD — pass the base branch explicitlystore.ts。测试见 store.test.ts。detached HEAD 但显式传了 base允许初始化checkout记为HEAD但合并保持阻塞直到切回 base。测试见 store.test.ts。base 与主 checkout 不同工作可正常进行但合并保持阻塞直到主 checkout 切换到 basegit checkout base。五、TowerInit 做了什么.tower/ 工作区全景TowerInit创建的是整套 Tower 协议操作的对象。目录布局在 paths.ts 中统一定义.tower/ ├── comms/ # 通信与协议状态区COMMS_DIR │ ├── state.json # 工作区状态base、sessionId、roster、missions │ ├── MISSIONS.md # mission 索引MISSIONS_INDEX │ ├── inbox/ # 收件箱TowerSend 投递的 .md 消息 │ ├── findings/ # finding 记录TowerFinding 归档 │ ├── reviews/ # review 记录TowerReview 提交 │ ├── missions/ # 每个 mission 一个 .md 文件 │ └── log/ │ └── activity.log # 活动日志所有参与者的每个动作 └── worktrees/ # git worktree 槽位wt-N5.1 初始化流程TowerStore.initstore.ts确保仓库存在ensureRepositorystore.ts若当前目录还不是 git 仓库会自动git init必要时切换到 base 分支若 base checkout 有未提交的改动会先为它们创建快照提交tower: snapshot of uncommitted base checkout changes。要求已有提交仓库没有任何 commit 时报the repository has no commits yet — create an initial commit firststore.ts。幂等分支已初始化则执行adoptForeignRoster并返回现有状态。校验并解析 base见第四节。创建目录骨架mkdirinbox、findings、reviews、missions、log、worktrees 六个目录。写 git exclude把.tower/追加进.git/info/excludestore.ts确保工作区状态文件不被 git 跟踪。测试验证见 store.test.ts。写入state.jsonTowerStateversion: 1、mode: branch、createdAt、sessionId、空 roster、空 missions采用“临时文件 rename”的原子写入方式store.ts。初始化活动日志、渲染 MISSIONS.md 索引并追加一条tower init日志含modebranch basebase。5.2 状态文件与活动日志的意义state.json是 Tower 协议的全部权威状态base、session 所有权、roster、missions。load()在文件缺失时报tower is not initialized in this repository — run TowerInit firststore.ts。activity.log是审计中枢每个参与者的每个动作都以时间 actor action keyvalue ref...的格式追加appendLogstore.ts。Tower 模式的全量提示tower-mode-full-reminder.md明确要求当协议行为异常时先读.tower/comms/log/activity.log。六、初始化之后的正确姿势Tower 工作流第 1 步TowerInit只是起点。Tower 模式的全量工作流提示tower-mode-full-reminder.md给出了 init 之后的标准动作Init本文主角TowerInit创建.tower/并记录 base 分支用户/tower base时已预设。注意若工作目录还不是 git 仓库引擎会自动初始化并提交当前所有文件——务必提醒用户先把 secrets 或大文件移走再 init。先安顿 carry-over 的 open missions 再规划属于当前目标的用新 worker 继续无关的用TowerMission statusabandoned放弃——open missions 保留其 scopeTowerPlan会拒绝任何与之重叠的新 mission。Plan按功能边界与工作量拆分每个 mission 一个 coherent 切片scope globs 必须互不相交picomatch 语法**跨目录标题必须是可打印 ASCII 英文含非 ASCII 字符会被拒绝并强制重规划只读调研任务标kind: survey。Spawn每个 mission 一次TowerSpawn后台运行把所有依赖已解锁的 mission 背靠背立刻全部 spawn不要一个个等。Supervise每次被唤醒worker 完成、用户消息用TowerInboxTowerStatus检查并行动。Merge按依赖顺序用TowerMerge(branch)绝不手写git merge绝不绕过拒绝。Teardown promptly全部 mission ✅ merged 且无未处理 inbox 项后先总结每个 worker 的产出再调用TowerTeardown。Teardown 不会退出 Tower 模式——直到用户用/tower off关闭。TowerInit 的返回输出见 3.3会直接给出“Next:”指引与上述流程完全一致。七、错误与边界场景速查场景行为依据Tower 模式未开启用户未/tower on工具拒绝tower mode is not active — only the user can enable itsupport.ts实验开关未开启无 env/config工具惰性/拒绝The tower experiment is disabledtowerService.ts非主 Agent 调用拒绝Tower orchestration tools are only supported by the main agentsupport.ts工作区被存活会话拥有拒绝tower workspace is owned by a live session需回该会话或先关闭initTool.ts仓库无任何 commit拒绝create an initial commit firststore.tsbase 不是本地分支如origin/main拒绝create a local branch firststore.tsdetached HEAD 且未显式传 base拒绝pass the base branch explicitlystore.ts已初始化 传入冲突 basebase 被忽略ignoredBase保留已记录 baseinitTool.tsbase 与 checkout 不一致 / detached初始化成功但合并阻塞直到切回 baseinitTool.ts再次初始化同会话幂等created: false保留 roster 与全部状态store.test.ts跨会话接管旧会话 roster 退役不可恢复missions/worktrees/log 保留store.test.ts八、关键源码路径索引工具描述文档init.md工具契约zod schemainit.ts工具执行逻辑initTool.ts协议存储层TowerStore.initstore.ts目录与文件命名paths.ts实验开关flag.tsTower 模式服务enter/adopt/exittowerService.ts初始化测试store.test.tsTower 全量工作流提示tower-mode-full-reminder.md赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐多智能体如何并行协作Claude Code Ultimate Guide Agent Teams工作流与决策框架全解多智能体如何并行协作Claude Code Ultimate Guide Agent Teams工作流与决策框架全解 Claude Code Ultimatewagmi 的 useFeeHistory Hook 使用指南在 React 中获取历史 Gas 费用信息wagmi 的 useFeeHistory Hook 使用指南在 React 中获取历史 Gas 费用信息 useFeeHistory 是 wagmi 提供的AI Agent代码智能体人工智能大模型CLIAgent Zero 初始消息协议解析从 fw.initial_message.md 看 JSON 工具调用规范Agent Zero 初始消息协议解析从 fw.initial_message.md 看 JSON 工具调用规范 在 Agent Zero AI framew人工智能大模型AI AgentAgent 框架自主智能体多智能体工具调用MCP 服务浏览器控制上一篇微信好友检测工具不打扰任何人一次筛出谁删了你下一篇Hermes Rust 工作区公共工具 cratehermes_utils 设计规范与 PointerAddress 实现解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考