Agentplane - 给 coding agent 工作流加上计划、验证和证据
AI coding agent 越来越擅长改代码，但团队真正担心的常常不是“能不能生成 diff”，而是：这次改动的任务边界在哪里？agent 是否先写了计划？它跑过哪些检查？reviewer 该看什么证据？一个月后再回头，谁能解释这组文件为什么被改？
今天推荐的 basilisk-labs/agentplane 正是在处理这层操作问题。它不是新的模型 provider，也不是新的聊天界面，而是一个 CLI-first 的本地工作流层，把 coding agent 的任务、计划、验证、上下文和 Agent Change Record 写成 Git 可见的工件。GitHub 页面当前显示项目约有 54 stars、6 forks、主要语言是 TypeScript、许可为 MIT。仓库创建于 2026 年 1 月 27 日，最近在 2026 年 5 月 26 日仍有推送，最新 GitHub release 为 v0.6.9，发布时间是 2026 年 5 月 24 日。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | basilisk-labs/agentplane |
| Stars | 约 54 |
| Forks | 6 |
| 主要语言 | TypeScript |
| 许可 | MIT |
| 创建时间 | 2026 年 1 月 27 日 |
| 最近推送 | 2026 年 5 月 26 日 |
| 最新 release | v0.6.9 |
它关心的是 agent 工作的可复盘性
Agentplane 的 README 把它定义成 AI agents 周围的 operational layer。换句话说，它不负责替你选择 Claude、Codex、Cursor 还是 Aider，而是要求这些 agent 在一个可检查的本地流程里工作。
初始化之后，Agentplane 会在仓库里写入 AGENTS.md 或 CLAUDE.md、.agentplane/WORKFLOW.md、.agentplane/tasks/<task-id>/README.md、.agentplane/tasks/<task-id>/acr.json 等文件。任务说明、计划、验证命令、回滚提示、发现的问题和最终证据都留在仓库附近，而不是散落在某个聊天窗口里。
这对团队很实际。很多 AI coding 失败并不是因为模型完全不会写代码，而是因为任务意图没有被固定下来，验证没有被记录下来，review 时只能面对一大块 diff。Agentplane 试图把“让 agent 干活”变成“让 agent 在一个有生命周期的任务里干活”。
Agent Change Record 是核心设计
Agentplane 里的 ACR 是 Agent Change Record。它是机器可读的工作记录，用来描述任务意图、工作流状态、改动文件、验证证据和 review 状态。README 里展示了 agentplane acr generate、validate、check、explain 等命令，也提供了对应 schema。
这个思路很重要。团队接受 agent 产出的代码，往往需要一个比 commit message 更结构化的证据包。commit message 适合人读，但很难稳定表达“这次任务要求是什么、验证是否跑过、review 状态如何、哪些文件属于 agent 改动”。ACR 把这些信息放进一个可校验的 JSON 文件，后续可以被 CI、review bot 或内部审计工具消费。
它不是替代 code review，而是让 review 有更好的入口。Reviewer 可以先看 task README 和 ACR，再决定要深挖哪些文件。
本地上下文也有生命周期
Agentplane 还提供 local context 机制，用 context/raw/**、context/wiki/**、context/facts/**/*.jsonl、context/graph/**/*.jsonl 和 .agentplane/context/derived 组织仓库知识。README 提到的模式是：原始材料保持不可变，wiki 做综合，facts 和 graph 保存结构化事实，生成投影可以随时重建。
这比“把所有资料一次性塞进 prompt”更像工程流程。上下文会过期，会有来源，会需要审查。Agentplane 的 context learn、context search、context check 等命令把上下文维护也纳入可验证的本地流程里。
对长期项目来说，这层价值可能比一次生成代码更大。Agent 需要知道项目约定、历史决策、发布流程、测试门禁和常见陷阱。如果这些知识只存在于聊天记录里，它们很难被下一个任务复用。
direct 和 branch_pr 两种模式
Agentplane 提供 direct 和 branch_pr 两类工作流模式。
direct 适合个人开发、本地快速循环和短任务。它在当前 checkout 里工作，少一些流程开销。branch_pr 则更适合团队：每个任务可以有独立分支、worktree、PR 工件和交接材料，让 agent 的改动边界更清楚。
这个分层很合理。很多工具只有一种默认姿势，要么过于轻量，不适合团队 review；要么一上来就要求完整平台化，个人试用成本很高。Agentplane 把工作流强度做成模式选择，让你先从本地任务记录开始，再逐步加上更严格的分支和 PR 工件。
适合什么场景
Agentplane 适合已经在认真使用 coding agent 的开发者和团队，尤其是那些想把 agent 输出纳入正常工程纪律的人。
如果你只是临时让 Codex 或 Claude Code 改一个小脚本，直接用原本的 CLI 更快。Agentplane 更适合这些场景：
- 希望每次 agent 任务都有明确计划和验证记录；
- 需要把 agent 改动和 review 证据一起提交；
- 团队要求 AI 生成 PR 说明任务意图、检查结果和回滚方式；
- 想把 Claude Code、Codex、Cursor、Aider 等工具放进同一个操作流程；
- 希望本地上下文有来源、索引和检查机制；
- 平台或安全团队需要 CI 可检查的 agent 工作记录。
需要注意的边界
Agentplane 目前还是早期项目，stars 数不高，release 也在快速迭代。它的价值建立在团队愿意接受额外工件的前提上。如果团队根本不看 task README、ACR 或 verification 记录，那么这些文件只会变成负担。
另外，它不解决模型质量问题，也不保证 agent 改动一定正确。它更像是一套操作轨道：让计划、验证和证据留下来。真正的代码正确性仍然依赖测试、review、权限边界和开发者判断。
使用时也要注意不要把敏感信息写进上下文或任务记录。Agentplane 把本地知识和运行证据放进仓库附近，这提高了可复盘性，也意味着团队要明确哪些内容可以提交、哪些只能留在本地。
总结
basilisk-labs/agentplane 把 AI coding agent 的问题从“模型怎么调用”推进到“工程组织如何接住 agent 的工作”。它用 TypeScript CLI 在本地仓库里生成任务、计划、验证记录、上下文和 Agent Change Record，让 agent 产出的代码更容易 review、追踪和复盘。
如果你已经开始让 Claude Code、Codex、Cursor 或 Aider 参与真实项目，并且发现聊天记录和普通 commit message 不足以解释 agent 做过什么，Agentplane 是一个值得观察的小众项目。