工单一来就开 Agent？用 MindFlock 把 Git worktree、人工审查和合并权限拆成三道关
团队开始同时使用 Claude Code、Codex 一类编码 Agent 后，最容易失控的并不是「有没有生成代码」，而是任务入口和 Git 状态：同一个工作目录被两个会话改动、工单上下文靠人工复制、Agent 完成后直接把提交推远端。把这些动作塞进一条自动流水线看似省事，却会让分支、依赖安装、审查责任和合并权限纠缠在一起。
MindFlock 提供了另一种分层方式。它是 Apache-2.0 许可的 Python 项目：把 Jira、Linear、GitHub Issues、Shortcut 或 Asana 中分配给你的工作转成独立的 Agent 会话；每个会话使用自己的 Git worktree 与功能分支，准备依赖并带着工单标题、描述、验收标准和评论启动。关键点不在于「让更多 Agent 自动写代码」，而在于把并行执行与最终 Git 决策分开。
截至本文核查时，项目 README 明确说明：由工单摄入创建的会话使用 Claude Code；手工创建的会话可以选择 Agent CLI。无论哪种入口，MindFlock 都不会替用户自动 commit、push、创建或合并 PR。对希望保留审查闸门的团队，这条边界比「自动化程度」更重要。
先把三个责任面拆开
可以把 MindFlock 的工作流理解为三个相互独立的层次：
- 任务摄入层：轮询工单系统或带审查评论的 PR，挑选分配给当前用户的任务。它解决的是上下文从哪里来，而不是替你判断需求是否正确。
- 执行隔离层：一个任务对应一个 worktree、一个
feature/...分支和一个 Agent 会话。依赖安装、终端输出和工作目录不与另一个任务共享，减少多个 Agent 在同一索引或未提交改动上互相踩踏的概率。 - 人工落地层：你在 Diff 视图检查改动，再按需提交、推送、开 PR 和合并。这里的「一键」是受控操作入口，不是绕过审查的授权。
这三个层次不能互相替代。工单内容不完整时，隔离得再好也只会更快地产生错误实现；worktree 隔离也不能证明依赖升级安全；Diff 审查通过更不等于可以跳过 CI、代码所有者或发布审批。MindFlock 适合把并行编程的物理环境整理好，而不是充当需求或安全决策器。
从手工会话开始验证，而不是先连生产工单
首次试用时，先在一个可丢弃的测试仓库创建手工会话。README 给出的 CLI 路径如下：
mindflock doctor cd ~/code/your-repo mindflock serve mindflock new . -p "修复测试中第一个失败用例" mindflock ls
mindflock doctor 用来检查安装与认证条件；mindflock serve 默认只绑定本机回环地址；mindflock new 创建会话；mindflock ls 列出会话的标题、仓库、状态、阶段、Diff 与成本信息。创建后应先在本机确认三件事：原工作目录没有出现未预期的改动；新会话位于独立 worktree；Agent 的第一条上下文确实对应你输入的任务。
不要把「Agent 能运行」误判为「它已经具备合并资格」。更稳妥的冒烟任务是改一条测试或文档，再在 Diff 中核对文件范围、生成的命令与测试输出。这样即使 Agent 选错文件，也只污染隔离分支，不会直接影响主分支工作区。
工单摄入要当成权限系统配置
当手工路径稳定后，才考虑在桌面应用的 Settings → Ticketing 中连接工单来源并打开 Ticket Ingestion。MindFlock 的说明指出，该路径通过轮询发现分配任务；因此新工单出现前可能有等待时间。轮询的好处是无需额外公网 webhook，代价则是要明确令牌权限、轮询范围和停用开关。
实践中建议采用最小授权：工单系统的令牌只读；仓库令牌按实际流程选择最小范围；测试阶段只接入一个测试项目或标签过滤后的队列。不要因为 Agent 最终需要在本地读写仓库，就顺手把组织级管理令牌、生产部署凭据或全局 Git 凭据暴露给它。
还要检查每个仓库的初始化方式。README 说明 Python/uv 仓库可自动检测并执行 uv sync --all-groups 与 pre-commit install，其他技术栈需要自行声明 setup_commands。这意味着 setup 命令本身是受信任代码：应像审查 CI 配置一样审查它，避免工单触发时安装不受控依赖、下载未知脚本，或误执行带破坏性的数据库迁移。
把审查点放在 Agent 最难替代的位置
并行 worktree 的真实价值是把等待时间转化为可审查的候选改动，而不是把人从循环中移除。一个实际可执行的流程可以是：
- 工单进入队列后，人工先判断验收标准、影响范围与是否需要设计讨论；
- MindFlock 创建隔离会话，Agent 只处理指定仓库和分支；
- Agent 完成后，先查看 Diff、文件清单和测试命令，再运行团队既有的测试、静态检查与安全扫描；
- 只有审查者确认变更满足工单，并且 CI 通过后，才由拥有相应权限的人 commit、push、创建 PR 和合并；
- 若 PR 收到新评论，将评论作为新的会话输入处理，而不是让旧会话继续猜测审查意图。
README 描述了一个有用的保护：带审查评论的 PR 可以重新形成会话，但它会跳过已过时的讨论和 PR 顶层对话。即便如此，审查者仍应确认 Agent 得到的是完整的当前要求；「跳过过时评论」是减少噪声的规则，不是对业务语义的证明。
注意网络入口与资源上限
MindFlock 的服务默认在 127.0.0.1 上监听。项目也提供 mindflock serve tailscale，用于显式启用 tailnet/手机访问，并输出认证 token 与二维码。只有确实需要移动端查看状态时才启用该模式；不要为了方便把服务直接暴露到公共网络。对任何远程入口，都应单独评估设备准入、token 生命周期、日志中是否泄露工单内容和终端输出。
并行会话还会放大资源消耗。每个 worktree 可能要安装依赖、运行测试并启动 Agent；同时开太多任务，瓶颈通常落在磁盘、包缓存、Docker、数据库测试端口或模型 API 限额上。建议为每个仓库设并发上限，并为重型测试配置独占资源或串行队列。看到多个 Agent 同时失败时，优先排查共享基础设施，而不是把失败任务全部重试。
还应给会话设置可观测的终止条件：记录工单号、分支名、worktree 路径、Agent 启动时间、测试结果与人工审查结论。任务被暂停或失败时，先保留现场并明确标注原因，再决定继续、丢弃 worktree，还是把发现回写到工单。否则并行队列很容易积累「看似仍在运行、实际上已不具备上下文」的会话。对包含凭据、生产数据或客户日志的任务，更应在启动前准备脱敏副本与允许访问的目录清单；隔离 worktree 并不能自动隔离环境变量、挂载卷和网络权限。
适用场景与不适用场景
MindFlock 适合「工单驱动、可拆分、需要人工收口」的开发节奏：维护者同时处理多个 bug、需求和 PR 评论，希望每个任务都有独立目录与清晰 Diff。它尤其适合作为团队现有 Git/CI 流程的前置工作台，而不是替换这些流程。
如果任务高度耦合、需要频繁共同编辑同一组未提交文件，或者仓库初始化本身带有高风险副作用，先不要盲目并行。此时应先拆分任务、固定依赖与迁移策略，必要时仍采用单一受监督会话。并行 Agent 解决的是工作区和上下文的隔离，不会自动消除架构耦合。
最终，可靠的多 Agent 流程不应以「任务一来就自动合并」为目标，而应以可追踪、可暂停、可审查为目标。MindFlock 用 worktree 隔离执行，用工单提供上下文，并把 Git 的最后几步保留给人。把这三道关配置清楚，自动化才会增加吞吐量，而不是增加难以追责的变更。