Kungfu：让 Agent 换班时工作不丢，但别把它当万能胶
代理工作的连续性。继续使用您已有的代理 kungfu run 代理是黄金路径，而不是 Codex、Claude Code、VS Code、终端或其他代理表面的必需替代品。
秒懂
- 它是什么？
- Kungfu 是一个面向 Agent 工作流的持久层，它把目标、证据和完成状态从聊天记录里剥离出来。它适合频繁切换 Codex、Claude 等工具的人，但 alpha 阶段和 Mock Agent 的依赖值得先看清楚。
- 适合谁用？
- 适合每天在多个 Agent 之间切换、且受够了复制粘贴上下文的人采用。它把工作状态从聊天记录里抽出来，让你换工具时不丢进度。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是切换成本，不是模型能力
Kungfu 的切入点很具体：每次换 Agent 都要重新解释背景、复制上下文、检查哪一步丢了。它不试图取代 Codex 或 Claude，而是把工作本身，目标、进度、证据、下一步动作和完成状态，放到聊天记录之外。README 的原话是，kungfu run agent 是黄金路径，不是替代品。这个定位避免了和现有 Agent 生态正面竞争，也让它的适用范围变得清晰：只处理连续性，不处理智力。对工程师来说，这意味着你不需要改变现有工作流，只需要在切换时多一个持久层。
Project、Work、Attempt 三层结构如何防止状态丢失
它的核心机制是三个概念。Project 记住相关工作归在哪里，Work 保存一个持久目标和当前事实，Attempt 记录某个 Agent 尝试了什么，包括失败，但不覆盖 Work。这个设计的关键在于，Attempt 是追加式的，失败不会抹掉已有状态。文档里还提到一个写入锁机制：如果另一个活跃 Agent 已经拥有某个 Work，Kungfu 会阻止第二个写入者，而不是让两个 Agent 静默分叉。这是对付多 Agent 并发最实际的手段，比事后合并冲突要省心得多。三个概念的分工在 README 里讲得很直白，没有多余抽象。
安装和首次验证：两条命令就能看到恢复过程
安装走的是 macOS 或 Linux 的 per-user 安装器，不需要 sudo，也不改 shell profile。命令是 curl -fsSL https://kungfu.tech/install.sh | sh。装完要按它打印的 PATH 步骤操作。验证恢复能力用的是内置 Mock Agent，不需要任何 provider 凭证。跑 KUNGFU_MOCK_AGENT_SCENARIO=recovery-story kungfu，它会用三个连续的 Attempt 模拟断线、崩溃、恢复交付。另一个场景是 KUNGFU_MOCK_AGENT_SCENARIO=multi-step，一次 Attempt 里跨过提问、审批、就绪审查。这两个场景都是确定性的，测试的是本地连续性和恢复路径，不是某个模型的好坏。注意 README 明确说，正式上手仍然需要一个真实 Agent 做独立审查，Mock Agent 不能替代。
两种接入方式：留在原 Agent 或通过 Kungfu 启动
接入方式有两种。第一种是留在你当前的 Agent 里，把一段话粘贴给 Codex、Claude、OpenCode 或 Amp，让它们运行 kungfu agent brief，然后引导你完成第一个 Project 和 Work。第二种是用 kungfu run codex 启动 Agent，后面可以跟任务参数，比如 kungfu run codex "Prepare the release notes"。这两种方式的差别在于谁持有会话的入口。前者保持你熟悉的界面，Kungfu 只做后台持久层；后者把启动入口交给 Kungfu，但控制台还是 Agent 自己的。README 强调 TUI 和 GUI 只是侧车视图，不是每个对话都必需。这个设计降低了迁移成本，但也意味着你多了一层要维护的命令。
本地工作区 .kungfu/ 的边界和 Git 策略
项目会在项目目录下生成 .kungfu/ 文件夹，这是本地工作区和运行时状态。README 明确警告：不要删除它，也不要把整个目录加进 Git。它要求你运行 kungfu agent map --json，然后按照输出的 workspaceGit 策略来决定暂存什么。大部分内容留在本地，Kungfu 永远不会替你暂存、提交或推送文件。这一点对团队很重要，因为如果策略没搞对，可能会把不该提交的运行时状态混进仓库。文档没有详细列出 workspaceGit 策略的具体规则，实际行为需要跑一次命令看输出。这种谨慎是对的，但也是 alpha 阶段的典型表现，你需要自己验证。
三个可审计的演示：证据链而不是宣传语
README 提供了三个可审计的演示，分别对应三个问题：换 Agent 后工作能否继续，失败后工作能否恢复，谁有权完成工作。每个演示都链接到 public-evidence.json 文件，是确定性的人工产物，不是生产环境认证。第三个演示把 Agent 退出、独立审查、Kungfu 结算分开，强调 Agent 可以产出候选结果和证据，但不能自我批准完成。这个设计把完成权从执行者手里拿走，是防止自说自话的关键。不过 README 也承认，这些是 bounded exact-artifact demonstrations，不是 provider 排名，也不是生产认证。想亲自试的话，可以跑 kungfu agent-work-lab，走一遍 open、watch、tour、try、test、report 的流程。
alpha 阶段的真实限制和替代方案
最明显的限制是它还在 alpha，版本号 v4.0.0-alpha.3 摆在那里。Mock Agent 只能覆盖 Work 创建和执行，常规上手仍需要真实 Agent 做独立审查，所以还没有端到端的零外部 Agent 路径。另一个限制是平台，安装指南提到 Windows 需要单独看 docs/guides/installing-cli.md，说明 Windows 不是一等公民。替代方案方面，你可以什么都不用，靠手动复制聊天记录维持连续性，成本低但容易漏；也可以用 git 分支和 commit message 记录工作状态，但那是为代码设计的，不是为 Agent 任务设计的。Kungfu 的差异在于它把 Attempt 的失败也保留下来，而 git 历史通常不会记录一次失败的尝试。如果你只需要版本控制，git 够用；如果你需要跨 Agent 的工作连续性，Kungfu 是专门做这个的。
维护成本和许可证：Apache-2.0 下的自由与代价
Kungfu 使用 Apache-2.0 许可证，商用和修改都没有障碍，这一点对团队采用是加分项。维护成本主要来自三点：一是 .kungfu/ 工作区的 Git 策略需要每个成员都理解，否则容易误提交；二是 alpha 阶段 API 和命令可能有变动，v4.0.0-alpha.2 到 alpha.3 间隔只有九天，说明迭代很快，跟进升级需要花时间；三是它依赖你已有的 Agent 工具，那些工具本身的更新也可能影响 kungfu run 的兼容性。项目默认分支是 dev/v4/v4.0，不是稳定分支，这本身就说明了维护节奏。代码主体是 C++，如果你打算自己改源码，编译环境需要额外配置。整体看，采用成本不高，但持续跟进的成本是实打实的。
编辑结论
适合每天在多个 Agent 之间切换、且受够了复制粘贴上下文的人采用。它把工作状态从聊天记录里抽出来，让你换工具时不丢进度。不适合只用单一 Agent、且对 alpha 阶段容忍度低的人。采用前先验证三件事：在 macOS 或 Linux 上跑一遍 KUNGFU_MOCK_AGENT_SCENARIO=recovery-story，确认 .kungfu/ 目录的 workspaceGit 策略符合你的仓库规范，再确认你常用的 Agent（Codex、Claude、OpenCode 或 Amp）能通过 kungfu run 正常启动。Kungfu 的承诺是工作不丢，不是替代你的 Agent，这个边界在 README 里写得很清楚，别越界使用。
社区笔记