SoloMap
管理本地 Agent 执行边界、证据与交接
紧贴代码仓库的团队计划,不等于本地 Agent 的工作协议
GitHub Projects 适合围绕 issue、pull request 和贡献者规划工作;SoloMap 适合在本地项目内约束并续接 Agent 执行。公开协作选 GitHub Projects,本地执行连续性选 SoloMap,也可以按承诺层与执行层组合。
管理本地 Agent 执行边界、证据与交接
让计划贴近 issue、PR 与贡献者
让 GitHub Projects 执行,让 SoloMap 保存约定
| 比较维度 | SoloMap | GitHub Projects |
|---|---|---|
| 核心职责 | 管理本地 Agent 执行边界、证据与交接 | 让计划贴近 issue、PR 与贡献者 |
| 重要边界 | 不替代 issue 和 PR 协作 | 本地会话上下文可能分散在多个仓库对象中 |
| 项目连续性 | 把已验证状态和下一步留在项目中 | 主要围绕自身工作流和对象组织上下文 |
| 完成判断 | 由用户依据可复核证据确认 | 提供执行结果,但不应独占长期项目状态 |
| 适合组合吗 | 可以作为项目约定层 | 可以在清晰边界内承担对应动作 |
管理本地 Agent 执行边界、证据与交接
让计划贴近 issue、PR 与贡献者
让 GitHub Projects 执行,让 SoloMap 保存约定
不要只凭功能表作决定。不替代 issue 和 PR 协作;本地会话上下文可能分散在多个仓库对象中。最终应以你的真实项目、协作人数和事实边界验证。
通常不是直接替代。二者承担不同职责,是否组合取决于你的项目工作流。
用一个真实项目检验:谁负责执行、谁保存项目事实、谁确认完成,以及换会话后能否从已验证状态继续。
可以,但每项决策只能有一个明确的事实所有者,避免路线图、代码和完成状态互相冲突。
最近复核: 2026-08-27
在本地项目中定义目标、边界、授权与完成证据。