文章摘要：Kungfu 是一个面向 AI 编程 Agent 的开源“持久化工作层”。它不负责把多个 Agent 组织成自动聊天群，也不是替代 Codex、Claude Code 或 OpenCode 的新模型；它解决的是另一类问题：当开发者切换 Agent、会话中断、进程崩溃或任务需要独立复核时，如何保留同一项工作的目标、进度、证据、下一步动作与完成状态。本文将拆解 Kungfu 的 Project、Work、Attempt、独立审查和结算机制，给出安装配置方法、一套可落地的多 Agent 功能开发流程，并说明 Alpha 阶段的限制、安全边界与选型建议。适合经常混用多个编程 Agent、需要处理长周期任务或希望建立可审计 AI 开发流程的个人开发者和技术团队。
核心结论
Kungfu 值得关注，但它更准确的定位不是“让多个 Agent 自动并行写代码”，而是为多个 Agent 提供一个可持续、可检查、可恢复的共同工作状态。开发者可以让 Codex 负责仓库分析，让 Claude Code 实现复杂修改，再让另一个 Agent 独立审查；即使中途更换工具，也不必完全依赖复制聊天记录来恢复上下文。
- 核心价值是任务连续性：Kungfu 保存的是 Work，而不是某个 Agent 的完整聊天。目标、进度、证据、下一步操作和完成状态可以跨会话延续。
- 适合串行接力与独立复核：不同 Agent 可以围绕同一个 Work 工作，但 Kungfu 会阻止两个执行者同时静默修改同一项 Work，避免状态悄悄分叉。
- 完成权与执行权分离：执行 Agent 可以提交候选结果和证据，却不能自行宣布任务最终完成；独立审查与 Kungfu 的 settlement 流程决定 Work 是否结束。
- 不等于代码隔离和自动合并：Kungfu 不会替用户执行 Git 暂存、提交、推送或合并，也不能替代分支、Git worktree、测试、CI 和人工代码审查。
- 当前适合评估，不宜直接视为生产级底座：官方明确将 Kungfu v4 标记为 Alpha，Stable 发布线、完整终端体验、部分持久性与跨版本保障仍未完成。
因此，建议个人开发者先在测试仓库中验证“分析 Agent—实现 Agent—审查 Agent”的接力流程；团队则应把它作为现有 Git、CI 和代码审查体系之外的任务连续层，而不是直接替换项目管理平台或生产审计系统。
Kungfu 是什么：它管理 Work，而不是替你选择模型
使用多个 AI 编程工具时，最明显的问题通常不是模型不会写代码，而是工作状态散落在不同会话中。开发者在 Codex 中完成代码库分析，切换到 Claude Code 后要重新解释业务目标；Agent 进程异常退出后，又要重新梳理已经改了什么；换一个模型做代码审查时，还要复制需求、计划、错误日志和测试结果。
Kungfu 的设计出发点是把“工作”从特定 Agent 会话中抽离出来。根据其官方 GitHub 项目说明，Kungfu 会在 Agent 会话之外保存任务目标、当前进度、证据、下一步动作和完成状态。同一个 Work 可以在 Codex、Claude、OpenCode、Amp 或自定义执行界面之间继续推进。
这里需要区分三个容易混淆的概念：
- Agent：真正读取代码、调用终端、修改文件和运行测试的执行者，例如 Codex 或 Claude Code。
- Kungfu：保存任务事实、执行记录、所有权和完成状态的持久化工作层。
- Git 与 CI：负责代码版本、变更隔离、自动测试、审查和发布门禁的工程基础设施。
Kungfu 没有把这三者混成一个黑箱，而是尝试明确各自的责任边界。对已经理解 Agent 编程基本模式的读者，可以先阅读 AI Stack Nav 的AI 编程工具 Agent 化趋势与选型指南，再把 Kungfu 理解为位于“执行 Agent”和“工程交付流程”之间的一层连续性基础设施。
核心机制拆解：Project、Work 与 Attempt 如何协作
理解 Kungfu 不需要先学习整个项目的内部术语。对普通使用者而言，最重要的是 Project、Work 和 Attempt 三个概念。它们分别回答“任务属于哪里”“当前真实状态是什么”和“某个 Agent 具体尝试了什么”。
Project：相关工作的归属范围
Project 用来标记一组相关 Work 所属的项目。它可以对应一个代码仓库、一款产品或一个长期维护的工程。Project 本身不是一次 Agent 对话，也不应被理解成 Git 分支；它更接近承载任务连续性的上层范围。
Work：唯一目标及其当前事实
Work 是 Kungfu 最关键的对象。一项 Work 应围绕一个可以验证的目标创建，例如“为登录接口增加速率限制并补齐测试”，而不是“把后端全面优化一下”。Kungfu 会围绕它保存目标、进度、证据、下一步动作和完成状态。
Work 的价值在于，不同 Agent 接手时读取的是当前任务事实，而不是只能依靠上一段聊天记录。聊天中可能包含大量探索、误判和重复讨论，而 Work 应保留经过确认、仍然影响后续执行的信息。
Attempt：记录一次执行，包括失败
Attempt 表示某个 Agent 对一项 Work 的一次尝试。如果网络中断、进程崩溃或实现方案被否决，这次 Attempt 不会覆盖 Work，也不会抹掉之前发生的事情。后续 Agent 可以在同一个 Work 下创建新的 Attempt，利用已有证据继续推进。
这种设计对调试和复杂重构尤其重要。失败不是一条需要删除的聊天消息，而是一段可以帮助下一个 Agent 避免重复踩坑的执行历史。例如，第一次 Attempt 已经证明某个依赖版本与当前运行环境不兼容，第二个 Agent 就不必再次走同一条路径。
执行权、审查权和完成权相互分离
Kungfu 官方特别强调：完成任务的 Agent 不能只凭自己的判断批准自己的工作。执行者可以提交候选结果与相关证据，但仍需经过独立审查和 settlement 路径才能将 Work 判定为完成。
这与软件团队中的 Pull Request 审查非常相似。写代码的人可以说明“测试已经通过”，但生产流程仍应验证测试日志、变更范围和验收标准。对高风险任务，这种权责分离比单纯增加 Agent 数量更有价值。
| Kungfu 概念 | 负责解决的问题 | 不负责的事情 | 开发流程中的对应物 |
|---|---|---|---|
| Project | 确定相关 Work 的归属范围 | 不等于 Git 仓库或分支 | 产品或工程项目 |
| Work | 保存一个目标及其当前事实 | 不直接编写或合并代码 | 带验收标准的开发任务 |
| Attempt | 记录某个 Agent 的一次执行及结果 | 不覆盖整个 Work 的历史 | 一次实现、修复或验证尝试 |
| Review | 独立检查候选成果和证据 | 不能只采用执行者的自我评价 | PR 审查与质量门禁 |
| Settlement | 决定 Work 是否满足完成条件 | 不等于自动部署到生产环境 | 任务验收和状态关闭 |
Kungfu 多 Agent 工作流的真正运行方式
Kungfu 所谓的多 Agent 工作流，重点不是让五个 Agent 同时修改同一份代码，而是让不同 Agent 围绕同一项可持续 Work 承担适合自己的阶段。一个相对稳妥的流程是：先分析，再计划，然后隔离实现，最后由独立 Agent 审查。
阶段一：分析 Agent 建立事实基线
第一个 Agent 只读检查仓库，确定入口文件、调用关系、现有测试、潜在风险和需要补充的信息。它不应立即进行大范围编辑，而应把已确认事实、仍存在的不确定性和建议的验收标准记录进 Work。
如果使用 Codex，可以结合 AI Stack Nav 的Codex 使用技巧与 AGENTS.md 配置教程建立仓库规则。对于 Claude Code，则可参考Claude Code 项目初始化与代码库理解教程，先让 Agent 构建代码地图。
阶段二：规划 Agent 把目标变成可验证任务
第二个 Agent 可以审查第一阶段的事实，补充实现计划。计划至少应包含修改范围、不可改变的接口、测试命令、失败回退方式和交付证据。如果任务过大，应拆成多个 Work，而不是让一个 Work 同时承担数据库迁移、界面改版、权限重构和生产部署。
阶段三：执行 Agent 在隔离环境中实现
执行 Agent 接手同一项 Work 后，在独立 Git 分支或 worktree 中修改代码。Kungfu 可以保留 Work 的连续状态，但文件级冲突、依赖安装和代码版本仍由 Git 与实际开发环境管理。
这里尤其需要注意官方边界：Kungfu 不会自动替用户执行 git add、git commit 或 git push。因此，开发者必须自己规定分支命名、提交粒度和允许执行的命令，不能因为接入了持久化工作层就放松代码安全控制。
阶段四：验证 Agent 复现证据
实现完成后，可以让另一个 Agent 独立读取 Work、代码差异和测试要求。它不应只接受“执行者说测试通过”的文字总结，而应重新运行必要测试，检查异常路径、安全边界、兼容性和无关文件变动。
阶段五：人工验收和结算
对于生产项目，最终验收仍应由负责人完成。人工检查应覆盖需求是否满足、测试是否可复现、密钥是否泄露、数据库迁移是否可回滚、变更是否超出范围以及 PR 是否获得必要审批。满足标准后，再通过受治理的 review 与 settlement 路径关闭 Work。
安装和完成第一个 Kungfu Work
Kungfu 官方为 macOS、Linux 和 Windows 提供独立 CLI 安装方式。不过，由于当前公开版本属于 Alpha，建议先在非生产设备或隔离测试环境中体验，并在执行远程安装脚本前检查脚本内容、版本、文件摘要和发布证据。
- 确认测试环境。 准备一个可以随时丢弃的示例仓库，确认已安装 Git，并至少配置一种 Kungfu 支持的编程 Agent。真实项目应先创建备份或独立 worktree。
- 安装 Kungfu CLI。 macOS 或 Linux 的官方快捷命令为
curl -fsSL https://kungfu.tech/install.sh | sh；Windows PowerShell 的官方快捷命令为irm https://kungfu.tech/install.ps1 | iex。高安全环境不应直接管道执行，而应下载脚本、核对 SHA-256、检查内容后再运行。具体参数以Kungfu 官方安装指南为准。 - 验证命令路径与版本。 在 macOS 或 Linux 中执行
command -v kungfu和kungfu --version。如果系统找不到命令，应把安装程序提示的用户级 bin 目录加入当前 Shell 的 PATH，而不是猜测应用目录并手工创建软链接。 - 先用 Mock Agent 验证恢复流程。 可运行
KUNGFU_MOCK_AGENT_SCENARIO=recovery-story kungfu，观察同一个 Work 经历断连、崩溃和恢复交付的过程。若只想快速体验提问、批准和等待审查流程，可使用KUNGFU_MOCK_AGENT_SCENARIO=multi-step kungfu。 - 让当前 Agent 读取 Kungfu 简报。 在支持本地命令的 Agent 中要求其运行
kungfu agent brief，然后指导创建第一个 Project 和 Work。这样可以继续使用原有 Agent 界面，把 Kungfu 作为背后的持久化工作层。 - 通过 Kungfu 启动实际 Agent。 进入项目目录后，可执行
kungfu run codex。如果使用其他已支持的 Agent，可将codex替换为claude、opencode或amp。也可以用kungfu run codex "为登录接口补充速率限制测试"直接创建第一项 Work。 - 检查项目本地状态目录。 首次运行后，项目中可能出现
.kungfu/。这是 Kungfu 保存本地工作和运行状态的目录，不应直接删除，也不要未经检查就把整个目录提交到 Git。可让 Agent 执行kungfu agent map --json，根据输出中的workspaceGit策略决定哪些内容可以进入版本控制。 - 创建验收标准并进行接力测试。 让第一个 Agent 完成只读分析并退出，再用另一个 Agent 接手同一个 Work。检查它是否能说清任务目标、已完成工作、现有证据和下一步动作，而不是依赖复制上一段聊天记录。
实战示例：三个 Agent 完成登录限流功能
下面以“为现有登录接口增加按 IP 限流，并补齐自动化测试”为例，展示一套更接近真实工程的 Kungfu 工作流。这个示例强调职责分离，不要求所有 Agent 同时运行。
Agent A：代码库侦察与需求澄清
Agent A 只读检查认证入口、中间件结构、缓存方案、现有错误码和测试目录。它将以下事实写入 Work：登录接口路径、当前鉴权流程、可复用的 Redis 客户端、现有测试命令，以及“禁止改变正常登录响应结构”的约束。
如果无法确认限流窗口、代理服务器下真实 IP 的获取方式或 Redis 故障时的策略，Agent A 应把它们标为待确认事项，而不是自行假设。
Agent B：实现与自测
人工确认策略后，Agent B 在独立 worktree 中接手 Work，编写限流中间件、配置项和单元测试。它运行格式化、静态检查和测试，并把命令、退出状态、失败记录、修改文件与仍未覆盖的风险作为证据保存。
如果首次实现导致并发测试失败，这次 Attempt 应被保留。Agent B 可以开启新的 Attempt 修正原子计数逻辑，失败记录则帮助后续审查者理解为什么最终方案使用了特定 Redis 操作。
Agent C：独立验证
Agent C 不沿用 Agent B 的自我评价，而是重新读取验收标准和代码差异。它重点检查代理头伪造、IPv6、Redis 不可用、计数器过期、并发竞争、错误信息泄露和测试隔离问题，并重新执行测试。
如果 Agent C 发现重大缺陷，Work 不应被直接标记完成，而应返回实现阶段。若问题只是非阻塞的可维护性建议，可以明确记录为后续 Work，避免当前任务无限扩大。
人工负责人：审查与结算
负责人检查最终 diff、验证报告和失败历史，确认没有真实密钥进入仓库，测试在干净环境中可以复现，限流配置具有回退方案。之后再批准 PR，并完成 Work 的受治理结算。
这套流程的关键不是“用了三个模型”，而是每个阶段都有明确输入、输出和权限。若任务非常简单，例如修改一个文案或调整单个 CSS 值，使用多个 Agent 反而会增加成本；Kungfu 更适合跨会话、长周期、需要恢复或需要独立复核的任务。
Kungfu 与常见多 Agent 方案有什么不同
市场上的“多 Agent”可能指三种完全不同的东西：多个 Agent 并行竞争同一个答案、多个角色自动讨论并分工，或多个 Agent 依次接手同一项持久任务。Kungfu 更接近第三种，同时通过所有权与完成权规则降低静默分叉和自我批准风险。
| 方案 | 核心能力 | 主要优势 | 主要风险 | 适合场景 |
|---|---|---|---|---|
| 多个独立聊天窗口 | 人工复制上下文并分配任务 | 零额外配置 | 上下文丢失、结论冲突、重复劳动 | 一次性小任务 |
| 自动群聊或主管—执行者框架 | Agent 自动对话、路由和分工 | 适合流程化协作与并行探索 | 消息膨胀、调度瓶颈、成本难控制 | 研究、内容生成和可拆分子任务 |
| Git worktree 多 Agent 并行 | 通过独立工作树隔离代码修改 | 文件冲突边界清晰、便于比较方案 | 缺少统一任务事实时仍需人工协调 | 独立 backlog 和多个功能分支 |
| Kungfu 持久化 Work | 跨 Agent 保存目标、事实、证据和状态 | 支持接力、恢复、独立复核和可检查历史 | Alpha 阶段，不能替代 Git、CI 与生产治理 | 长周期任务、多工具切换和故障恢复 |
如果团队主要需求是同时处理十个完全独立的 Issue，优先建立 GitHub Issue、worktree、CI 和 PR 队列可能更直接。如果问题是同一项复杂任务会跨多天、跨多个 Agent，且经常因为会话结束丢失决策和证据，Kungfu 的价值才会更加明显。
成本、权限与团队落地建议
Kungfu 项目采用 Apache License 2.0，但“开源”不等于整套工作流没有成本。实际成本主要来自所连接 Agent 的订阅或 API 使用量、长上下文读取、重复验证、并行执行环境以及团队维护规则的时间。
先控制任务粒度，再增加 Agent 数量
如果 Work 没有清晰验收标准，增加 Agent 只会产生更多解释、日志和冲突。建议每项 Work 对应一个可以独立验证的结果，并明确允许修改的目录、测试命令、不能改变的接口和停止条件。
为每种角色设置最小权限
分析 Agent 通常只需要读权限；实现 Agent 可以写入隔离分支，但不应默认拥有生产部署权限；审查 Agent 应能运行测试，却未必需要推送代码。密钥、生产数据库和云平台管理员凭据不应因为“Agent 需要自主执行”就直接暴露。
把模型选择与任务风险匹配
Kungfu 支持在不同 Agent 之间保持同一 Work，这为模型路由提供了现实空间：低风险的信息整理可以交给成本较低的模型，复杂架构修改使用能力更强的 Agent，最终安全审查再交给独立执行者。但官方并未给出“切换后一定降低多少成本”的统一数据，团队需要根据自身任务记录实测。
把证据定义成可复现材料
“我检查过了”不是高质量证据。更有价值的材料包括测试命令及退出状态、失败日志摘要、变更文件清单、关键 diff、构建产物摘要、性能测试环境和人工验收结果。证据越结构化，后续 Agent 恢复工作的成本越低。
风险、限制与注意事项
截至 2026 年 8 月 15 日，Kungfu 官方将 v4 公开版本标记为 Alpha。根据官方 Known Limits 文档，当前不能把一次 Alpha 发布推断为已经建立 Stable 发布线、原生包管理器分发、生产支持承诺或后续版本自动通过资格验证。
- 持久性不等于完整生产级灾难恢复：官方明确说明，当前测试证据不能自动扩展为所有设备、文件系统和突然断电场景下的生产保证。
- v4 跨版本兼容保障仍在完善：部分 schema 兼容检查、运行时加载门禁和跨版本导入导出测试基线尚未完成。
- 终端和图形界面功能仍不完整：GUI 与 CLI 启动的托管会话尚未实现全部能力对等，部分多窗口和会话行为也不是默认开启。
- Agent 连续性不能替代代码隔离：两个 Agent 是否共享 Work，与两个进程是否会同时编辑同一工作目录是不同问题。涉及并行开发时仍应使用分支或 worktree。
- 不要提交整个本地状态目录：
.kungfu/中包含项目本地工作与运行状态，应先读取工具给出的 Git 策略，再决定哪些文件可以纳入版本控制。 - 远程安装脚本需要供应链检查：高安全环境应下载并审查脚本、核对版本与 SHA-256，而不是直接把网络内容管道交给 Shell。
- Agent 输出仍可能出错：Kungfu 能保留证据和不确定性，但不会让模型自动变得完全可靠，也不能保证 Agent 提交的证据本身一定真实完整。
对企业团队，建议先采用“影子运行”方式：保持现有 Issue、PR、CI 和审批流程不变，同时用 Kungfu 记录少量非核心任务，观察恢复成功率、重复工作比例、平均审查时间和 Agent 成本。只有取得内部数据后，才适合扩大使用范围。
事实依据与来源
内容核验日期：2026 年 8 月 15 日。
本文关于 Kungfu 支持 Codex、Claude、OpenCode 和 Amp，保存 Project、Work、Attempt、证据与完成状态，以及执行 Agent 不能自行批准 Work 的描述，来自 Kungfu 官方仓库 README 和项目文档。关于安装命令、PATH、版本校验、Mock Agent、签名渠道及更新所有权的说明，来自官方 CLI 安装指南。
“Kungfu 更适合串行接力和独立审查，而不是让多个 Agent 同时修改同一项 Work”是根据官方单一写入者限制、独立 review 和 settlement 设计作出的编辑归纳。具体团队效率、成本节省比例和生产稳定性未经本文作者进行长期基准测试，不应视为官方性能承诺。
本文中的登录限流案例、Agent A/B/C 分工、分支策略、权限模型和落地指标属于实施建议，并非 Kungfu 官方固定模板。用户应根据代码库、Agent 类型、操作系统和安全制度进行实测。
Kungfu v4 当前处于 Alpha 阶段；Stable 渠道、完整包管理器支持、生产持久性保证和部分跨版本能力仍有限。任何用于生产系统的决定，都应再次查看官方当前版本、Alpha 状态和 Known Limits，不应只依据本文的静态描述。
FAQ
Kungfu 是新的 AI 编程模型吗？
不是。Kungfu 不提供一个取代 Codex、Claude Code 或 OpenCode 的基础模型。它是位于编程 Agent 之外的持久化工作层，用于保存任务目标、进度、证据、下一步动作和完成状态，让不同 Agent 可以接手同一项 Work。
Kungfu 能让多个 Agent 同时修改同一个功能吗？
Kungfu 的重点不是允许多个执行者静默修改同一项 Work。官方说明，当某个活跃 Agent 已经拥有 Work 时，系统会阻止第二个写入者，避免两套状态悄悄分叉。如果要并行开发独立子任务，应先拆分 Work，并配合 Git 分支或 worktree 隔离代码。
使用 Kungfu 后还需要 Git 和 GitHub 吗？
需要。Kungfu 不负责 Git 暂存、提交、推送、PR 合并和版本回退。它保存的是 Agent 工作状态和证据，而代码版本、文件冲突、审查与发布仍应由 Git、GitHub、CI 和团队工程流程管理。
Kungfu 支持哪些编程 Agent？
官方 README 当前明确展示了 Codex、Claude、OpenCode 和 Amp 的使用入口，并允许接入自定义执行界面。实际兼容能力可能随 Alpha 版本变化，安装前应查看当前官方文档和版本说明。
Kungfu 是否适合零基础用户？
零基础用户可以用 Mock Agent 体验 Work 创建、失败恢复和审查流程，但真实项目仍涉及终端、PATH、Git、权限和测试等工程知识。完全没有命令行经验的用户更适合先在示例仓库中练习，不要直接连接生产代码或敏感凭据。
Kungfu 可以降低 Agent 使用成本吗？
理论上，跨 Agent 保留任务状态可以减少重复解释和无效代码库扫描，也便于把不同阶段交给不同成本的模型。不过官方没有提供适用于所有项目的统一节省比例，实际成本还会受到上下文长度、验证次数、Agent 价格和任务复杂度影响，应通过团队数据实测。
如果 Agent 中途崩溃，Kungfu 能恢复代码吗？
Kungfu 可以保留同一 Work 下的 Attempt、进度和证据，帮助新进程理解此前发生的事情，但它不等同于代码备份系统。未提交的文件是否能够恢复仍取决于工作目录、Git、文件系统和备份策略。因此执行重大修改前仍应使用分支、worktree 或快照。
Kungfu 现在适合直接用于生产项目吗？
不建议把当前 Alpha 版本未经验证地作为生产系统的唯一事实来源或关键任务控制层。更稳妥的方法是在非核心仓库或影子流程中试用，同时保留原有项目管理、Git、CI、审计和人工审批机制。
为什么执行 Agent 不能自己宣布 Work 完成？
因为生成结果和验证结果存在利益与视角重叠。执行 Agent 可能遗漏自己引入的问题，也可能错误理解测试输出。Kungfu 将执行、独立审查与结算分开，是为了让完成状态建立在可检查证据和独立判断上。
总结：Kungfu 的价值不是更多 Agent，而是更少的任务失忆
Kungfu 代表了一种值得关注的 Agent 工程方向：多 Agent 开发的重点不应只是同时启动更多模型，而应建立稳定的任务状态、所有权、证据、失败恢复和完成权限。只有这些基础机制存在，Agent 接力才不会退化成复制聊天、重复扫描代码和人工追问进度。
对于经常在 Codex、Claude Code、OpenCode 等工具之间切换的开发者，Kungfu 可以作为实验性的持久化 Work 层；对于团队，它更适合与 Git worktree、测试、CI、PR 审查和人工审批组合使用。当前版本仍处于 Alpha，因此最合理的行动不是立刻替换生产流程，而是在测试仓库完成一次可复现的跨 Agent 接力：让一个 Agent 分析、一个 Agent 实现、另一个 Agent验证，再判断这种机制能否真正降低上下文丢失和重复工作。
参考来源
- Kungfu 官方 GitHub 仓库与项目说明，核验日期：2026 年 8 月 15 日。
- Kungfu CLI 官方安装指南，核验日期：2026 年 8 月 15 日。
- Kungfu v4 Alpha Status，核验日期：2026 年 8 月 15 日。
- Kungfu Known Limits，核验日期：2026 年 8 月 15 日。
- Kungfu System Overview，核验日期：2026 年 8 月 15 日。
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
