Kimi K2.6：长程编码与多 Agent 工作流

一句话结论

Kimi K2.6 适合把复杂工程拆成可验证的长程阶段，并在需要时扩展为并行 Agent Swarm；关键是持续记录 todo、工具结果和验收，而不是只给一句“把项目做完”。

适用场景

• 适合的任务：跨语言代码库、前端/DevOps/性能优化、长时间工具调用、并行研究/文档/网站/表格生成。

• 不适合的任务：没有版本控制、无法回滚或没有验收资源的全自动生产变更；复杂任务不应只依赖模型最后一句自报。

• 适用的模型版本：Kimi K2.6；官方示例还对比 K2.5，但本工作流以 K2.6 为准。

• 适用的客户端、Agent 或 API：Kimi Code、Kimi Agent/Agent Swarm、OpenAI-compatible API；具体工具 schema 需由客户端提供。

• 推荐的推理档位和参数：官方基准默认 thinking enabled、temperature 1.0、top-p 1.0、上下文 262,144；生产任务应以自己的成本/延迟评估为准。

可直接使用的内容

以下是根据官方长程编码案例整理的可复用工作流模板（不是官方逐字 system prompt）：

你是本项目的长程工程 Agent。请把目标拆成可回滚、可验证的阶段，并持续维护 TODO。

目标：<最终可验收结果>
仓库与运行方式：<目录、语言、启动/测试命令>
硬约束：<不能改的 API、依赖、文件、性能目标>

执行规则：
1. 先扫描仓库、运行现有测试并写出短计划；不要假设未检查的模块行为。
2. 每完成一个阶段就更新 TODO，保存可运行的中间结果和验证日志。
3. 性能任务先建立基线，再逐项改动；记录指标、工具调用和回归结果。
4. 遇到阻塞时寻找替代路径，说明假设和风险，不要用占位数据冒充成功。
5. 最终必须运行测试/基准并报告：改动文件、指标前后值、失败项、剩余风险。

阶段结束条件：<测试、性能、界面或交付物的明确验收标准>

如要扩展为并行 Agent Swarm，把任务按“搜索/分析/实现/验证/写作”等互不覆盖的子任务拆开；每个子 Agent 只提交结构化产物，主 Agent 负责冲突合并和最终验收。

测试/工作流步骤

1. 先用单 Agent 扫描代码库，建立基线测试和 TODO。

2. 将大任务分为规划、实现、测试、性能/安全审查四类阶段，阶段之间保存 commit 或 patch。

3. 对可并行的资料检索、文件分析和候选实现启用子 Agent；规定输出格式、文件范围和停止条件。

4. 主 Agent 汇总子结果，按同一测试命令和指标复核，不直接接受未经验证的建议。

5. 在长程会话中记录工具调用数、上下文裁剪、token、失败恢复和最终人工改动量。

原始证据与数据

• 官方示例一：下载并部署 Qwen3.5-0.8B 到 Mac，用 Zig 优化推理；超过 12 小时、4,000+ 工具调用、14 次迭代，吞吐约从 15 提升到 193 tokens/sec。

• 官方示例二：重构 exchange-core；13 小时、1,000+ 工具调用、修改 4,000+ 行代码；中等吞吐从 0.43 提升到 1.24 MT/s（约 185%），性能吞吐从 1.23 到 2.86 MT/s（约 133%）。

• 官方 Agent Swarm 描述支持最多 300 个子 Agent 和 4,000 个协调步骤，高于 K2.5 的 100 个子 Agent/1,500 步骤。

• 官方说明其基准通常使用 thinking enabled、temperature 1.0、top-p 1.0、上下文 262,144；代码基准平均 10 次独立运行。

适用边界

• 上述模板是基于公开案例重组的 workflow，不是 Kimi 官方隐藏 prompt；工具描述、权限和停止条件必须由使用者补充。

• 官方长程案例是厂商展示，不包含完整输入、失败样本或独立复核；不能把 12/13 小时案例直接当作所有仓库的成功率。

• Agent Swarm 的子 Agent 数量/步骤上限是官方架构描述，不代表任务一定更快或更便宜；并发错误、合并冲突和上下文管理需要单独测量。

• 任何性能提升都必须在相同硬件、编译参数和负载下验证；不可只比较叙述中的前后数字。

来源摘录或观察（仅做合规短引）

官方把 K2.6 的重点概括为 “long-horizon coding” 与 “agent swarm capabilities”；案例同时给出持续时间、工具调用和性能前后值，因而可以转化为上述可复用验收流程。