明确工具反馈循环
研究任务如何依据命令和文件结果继续，明确自己的流程各步骤需要什么证据。
Kimi Code CLI
参考 Kimi Code CLI 的工具循环、子 Agent、生命周期 hooks 与编辑器协议，为自己的工作流划分任务职责、设置执行检查，并改善 Floatboat 中各环节的上下文交接。
规划编辑器到 Agent 的审查交接
提供角色分工或编辑器交接不清楚的开发任务，让请求比较 Kimi Code 的工具反馈与生命周期边界。先说明各阶段需要的上下文和结果，再提出适配器或执行流程调整方案。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: Kimi Code CLI https://github.com/MoonshotAI/kimi-code 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 阅读 Kimi Code 的 ACP 文档，评估从我的编辑器发起审查的交接方式。将选中文件与验收标准作为同一任务，按代码位置返回问题；先核对兼容性，再提出最小测试。 期望交付: 接口兼容性检查，以及上下文、问题与验证结果的交接格式。
关于 Kimi Code CLI
Kimi Code CLI 是月之暗面当前的开源终端编程 Agent。官方说明涵盖读取和编辑代码、执行命令、搜索文件与获取网页，再根据工具反馈选择后续步骤。它是模型周围的应用系统，不是一个 Skill 包。
对希望优化工作流的 Floatboat 用户，有价值的是职责划分、明确的工具反馈和适当的检查节点。Kimi Code CLI 为这些机制提供了具体参考；ACP 也展示了界面与 Agent 执行进程分离的组织方式。
当前维护的仓库是 MoonshotAI/kimi-code，采用 MIT 许可。旧 Python 项目 MoonshotAI/kimi-cli 已归档并引导迁移到新版。阅读教程时要区分版本，旧架构、包名和命令不能直接当作当前发行版说明。
值得借鉴的工作流机制
Kimi Code 通过工具反馈、角色职责和生命周期检查协调执行。每个角色交回的上下文及审阅证据需要足以支撑下一阶段，接口存在并不能代替这些交接约定。
专注的任务职责
参考子 Agent 上下文划分探索、规划与实施职责，同时保留主任务目标。
生命周期边界上的检查
需要确定操作检查节点和工具间上下文传递方式时，研究 hooks 与接口协议。
Kimi Code CLI的使用场景
多角色编码要约定成果交接，重要动作要设置检查点，编辑器还需传递正确背景。Kimi Code 的接口与运行时机制可作为参考，具体上下文约定及适配仍应在自己的环境验证。
多角色开发流程
编码工作流可以将研究、规划和实施交给不同角色，但需要定义各自输入、可检查的输出和交接条件。所有角色围绕同一个开发任务协作，并约定何时将发现返回主任务，避免并行贡献逐渐变成彼此脱节的独立工作。
重要步骤之前的检查
在有实际影响的命令、文件变更或外部行动之前，明确评估影响需要哪些证据，并设置验证或人工审阅节点。将检查结果带回工作流，再依据实际发现和适用授权决定继续或停止，而不是仅根据原有计划自动执行。
一致的上下文交接
跨编辑器、工作区和 Agent 进程的任务，需要清楚的上下文传递约定。参考界面与运行时分离的方式，将工作区路径和任务资料对应到执行进程。对 ACP 或其他接口进行实际核验，不假定客户端天然支持所需的全部行为。
采用生命周期检查前先试验
用于检查重要步骤的钩子或插件，本身也需要范围明确的试验。对照当前 Kimi Code 文档及外围运行环境，说明检查接收什么、返回什么，以及无法判断时如何处理。验证反馈能够回到主流程，不假定安装扩展就已经建立项目需要的批准策略。
使用当前 Kimi Code 资料
持续维护的 kimi-code 与旧 Python CLI 示例可能描述不同架构。以下条件先确定调查针对哪个版本，再借鉴委派或上下文机制，避免把不兼容示例混合成一套配置。
选择当前维护的参考
研究机制时使用 kimi-code 文档，旧 Python CLI 示例可能属于不同架构。
验证 Kimi Code 中的委派任务
下一角色既需要足够背景，也不应被无关历史淹没。为委派贡献约定输出和审阅节点，再检查接收阶段能否使用实际材料，确认交接有效后才扩展更多协作环节。
定义职责与检查点
明确每个委派任务接收什么、返回什么，以及哪些操作必须等待审阅。
验证上下文传递
检查各阶段是否获得足够相关信息，同时避免每一步都携带无关对话历史。
相关软件项目
比较这些项目的用途、运行条件和源码许可。
Kimi Code CLI 常见问题
现在应选择哪个 Kimi 仓库？
当前应使用 MoonshotAI/kimi-code。MoonshotAI/kimi-cli 是已归档的 Python 实现，其官方说明明确引导用户迁移到新项目。
Kimi Code CLI 属于独立 Agent 项目吗？
是。它包含交互应用、工具、会话和 Agent 执行能力，不能只理解为提示、模型或 Skill 集合；Skills 可以参与其中，但不是整个项目。
是否只能使用 Kimi 模型？
README 说明可配置其他兼容提供方。实际使用前仍要核对协议与功能支持，不能假设所有模型接口行为一致。
ACP 集成提供什么？
它让兼容编辑器通过 Agent Client Protocol 驱动 Kimi Code CLI 会话。编辑器提供界面，CLI 承担 Agent 会话，前提是编辑器支持相关集成。
借鉴这些机制是否需要更换工作工具？
不需要。可以先将 Kimi Code CLI 作为任务结构、工具边界和结果审阅的设计参考，在已有工作流中验证思路。软件复用是另一项选择，需要核对兼容性、权限与许可；借鉴设计思路不会自动完成软件与 Floatboat 的连接。
MIT 许可是否覆盖 Kimi 订阅？
不覆盖。MIT 适用于项目源码；Kimi Code 账号访问、Moonshot API 调用和其他模型服务分别适用各自权益、额度与条款。