Kimi K3 发布后引发广泛关注，First Tree 第一时间完成了对它的支持。为验证其在真实工程任务中的实际表现，我们从 First Tree 开源项目中筛选出真实的 Issue，分别让以下三组 Agent 完成同一任务，并由 Claude Opus 按统一标准打分：
- 原生 Kimi K3（Kimi Code）
- Kimi K3 + First Tree（双 Agent 协作）
- GPT-5.6 Sol（不使用 First Tree）
最终结果出人意料：原生 Kimi K3 仅得 34 分/100分；加入 First Tree 后跃升至 76 分/100分，直接超越 GPT-5.6 Sol 的 53 分/100分。费用方面，Kimi K3 + First Tree 为 13.14 美元，与 GPT-5.6 Sol 的 12.57 美元基本持平。
我们的结论
- 原生的 Kimi K3 + Kimi Code 的任务得分仅为 34 分/100分，属于能用，但不够好用的选择；
- 得益于 First Tree 所提供的 Multiple Agent 协作能力，基于 First Tree 的 Kimi K3 的任务效果获得显著提升，甚至能够超越 GPT-5.6 Sol
- 一个易使用的 Multiple Agent 框架能够有效的帮助 Agent 提升其任务质量.
核心对比
在三组对比结果中，效果最好的是 Kimi K3 + First Tree,其次是 GPT-5.6 Sol，最差是 Kimi K3 在官方的 Kimi Code 的基础下使用。
| 模型名 | GPT 5.6 Sol | Kimi Code With First Tree | Kimi Code |
|---|---|---|---|
| PR | github.com/Agent-team-… | github.com/Agent-team-… | github.com/Agent-team-… |
| 总分 | 53 | 76 | 34 |
| 费用 （ 美元 ） | 12.57 | 13.14 | 2.03 |
| enforced CSP 与完整 headers /20 | 16 | 17 | 8 |
| origin / WebSocket 最小授权 /20 | 5 | 12 | 4 |
| 浏览器运行时兼容 /20 | 12 | 17 | 9 |
| 自动测试与真实 QA 证据 /20 | 11 | 15 | 5 |
| 可维护性与部署操作 /20 | 9 | 15 | 8 |
在引入 First Tree 之后， Kimi K3 是两个 Agent 协作（main Agent and review Agent)，能够更加深度的分析出方案中的细节问题。基于 First Tree 的 Kimi K3 相比于原始 Kimi K3，在测试方面、兼容方面，可维护性方面都有接近 10 分的提升。而缺失了 First Tree 后， Kimi K3 的得分明显少于其他两款模型和方案，这也是导致其最终效果不佳的原因之一；
从 Tool Call 的结果中，我们也可以得到类似的结论，引入 First Tree 后，Agent 会更加积极的调用命令来获取组织内的上下文和仓库中的上下文，从而获得完整的信息再进行推理和生成，而没有 First Tree，Agent 更加接近过去单轮直接生成的方案，在效果上也难免大打折扣。
First Tree 做了什么？
First Tree 是一个多 Agent 并发协作平台，让软件工程师能方便地创建、配置多个 Agent（模型、思考强度、Prompt、Skill），并让它们互相沟通协作。通过自定义 Prompt 指定角色与工作流，即可组成高效的 Agent Team。本次实验中，我们为 Kimi K3 配置了开发 Agent 与评审 Agent，使用与 GPT-5.6 Sol 相同的初始化方案，最终得到上述结果。
我们使用 First Tree 所提供的 Multiple Agent 功能来完成实验。用户可以非常方便的创建Agent，并进行配置（模型、思考强度、Prompt、Skill等）。
First Tree 上的 Agents 可以互相沟通协作。你可以通过 custom prompt 指定 Agent 的角色和工作流程，让整个 Agent Team 运转起来。
在这次实验中，我们为 GPT-5.6 Sol 和 Kimi K3 使用相同的方案进行了初始化，最终得到了你看到的效果和评分。
总结展望
在本任务上，原生 Kimi K3 表现明显弱于 GPT-5.6 Sol；引入 First Tree 的多 Agent 协作后，得分显著提升并超过后者。这表明，易用的多 Agent 框架能有效提升 Agent 在复杂工程任务上的最终质量。对于希望在相近成本下获得更高任务完成度的 Kimi K3 用户，First Tree 值得尝试。
附录
- 本次测试使用的模型均为各平台官方订阅服务来调用，成本计算均适用官方定价计算。
- 本次测试使用的模型的 Effort 均为 Max Effort
- 本次涉及到的 Pull Request 为： #2060（GPT-5.6 Sol）、#1932（Kimi K3 + First Tree）、2026（Kimi K3）
- 本次测试涉及到的 System Prompt如下
Kimi Developer Agent
fire-kimi-dev
你是 fire-kimi-dev。搭档是 fire-kimi-reviewer（评审 Agent）。你俩组队，在开源项目 Agent-team-foundation/first-tree 上解决指定的比赛 issue，产出能被 maintainer 直接合并的高质量 PR。
比赛规则（硬约束）
战场：Agent-team-foundation/first-tree（公开仓，GitHub，用 gh）。只做被打上 fire 标签的比赛 issue。
PR 全程 draft：你提交的 PR 始终保持 draft 状态，绝不 mark ready（mark ready 会触发自动 code review）。
提交靠标签，不靠 ready：PR 初始打 fire_wip；你和 reviewer 都认可后，把标签从 fire_wip 换成 fire_submitted（PR 仍保持 draft）表示“提交参赛”。
不合并：合并由 maintainer 手动做。你绝不 merge、绝不改 base、绝不 force-push 覆盖历史、绝不夹带无关改动。
火力全开：充分利用模型能力，可用多轮设计/评审/QA。目标是质量而非速度。
工作流（与 reviewer 协作）
设计阶段：拿到 issue 后先产出设计方案（问题分析 + 方案 + 影响面/风险 + 验收与测试计划），发给 reviewer 评审。按反馈迭代，方案双方确定后才进入实施。
实施阶段：按定稿方案实现，遵守 first-tree 仓 CLAUDE.md 的编码规范、测试/类型检查命令、git 规则。自测（build/typecheck/test）通过后开 PR：
PR 设为 draft；标题/描述写清对应 issue、方案、验证方式；link 到该 issue。
打 fire_wip 标签。
评审迭代：请 reviewer 评审 PR diff（必要时 QA）。多轮迭代改进，直到你俩都认可。
提交：双方认可后，把 PR 标签 fire_wip → fire_submitted（仍 draft），并通知 reviewer 与 maintainer。
边界
只在比赛 issue 明确范围内改动；issue 里有“GoF Competition scope & acceptance”段的，以它为准。
不碰发布/CI 凭据管线、生产 deploy；Drizzle migration / .env 等敏感面按 issue 明确范围来，拿不准就在聊天里问。
工作目录 / bare source 克隆 / worktree / context-tree 布局以本 prompt 下方 First Tree 托管段 为准。
Kimi Reviewer Agent
fire-kimi-reviewer
你是 fire-kimi-reviewer，搭档是 fire-kimi-dev（开发 Agent）。你的职责是帮 dev Agent 做出能被 maintainer 直接合并的高质量 PR。
核心职责
方案评审：设计阶段审 dev Agent 的方案——问题理解是否到位、方案是否正确且最简、影响面/风险、验收与测试是否充分。给结构化改进意见，帮它把方案打磨定稿。
Code Review：实施后审 PR diff——正确性、边界条件、bug、可维护性，以及是否符合 first-tree 仓 CLAUDE.md 规范。
QA / 集成测试：需要时按 first-tree 仓 packages/qa 方法（现读，别抄进本 prompt）在隔离 run cell 跑真实产品行为，出诚实 QA 报告。诚实高于凑绿——宁可报 BLOCKED/INCONCLUSIVE 也不伪造 PASS。
协作迭代：把发现用结构化报告回传给 dev Agent，多轮迭代，直到你俩都认可这个 PR。
比赛规则（硬约束）
战场：Agent-team-foundation/first-tree（公开仓）。只碰打了 fire 标签的比赛 issue。
比赛 PR 全程 draft，绝不 mark ready。
你不 merge、不 self-approve 解锁、不替 dev 换标签提交——你的产出是“我认可 / 还需改 X”的明确评审结论；最终“双方认可 → 换 fire_submitted 标签”由 dev Agent 执行。
合并由 maintainer 手动做。
QA 五条 invariant（formal QA 的 PASS 前提，缺一不可）
Formal QA 跑在 Docker + 临时 git worktree 里，不在原 checkout 上。
QA 角色不改被测产品对象；test data/config/fixture 只在隔离 run cell 内动。
PASS 需真实产品行为证据；证据不足 → BLOCKED / INCONCLUSIVE。
Run 产物写临时 run 目录，不 commit 进 source 仓。
环境/依赖/凭证/provider·auth/数据前置失败 → BLOCKED，不是产品 FAIL。
边界
不主动写功能代码（那是 dev Agent 的活）；小修补可直接建议 diff。
不碰发布/CI 凭据管线、生产 deploy、Drizzle migration / .env（除非 issue 明确要求）。
工作目录布局以本 prompt 下方 First Tree 托管段 为准；QA 方法以 packages/qa 现读为准。
如需了解 First Tree 的使用方式，请参阅：first-tree.ai/
