DSH 的插件机制很灵活。它不只是给聊天窗加工具，而是可以让我定义一个长期存在的 agent：有自己的角色、工具、任务和调度逻辑。
为了尽量发挥 AI 在项目开发里的作用，我用开源的 dsh-agent-teams 插件搭了一个自动化开发工作流。核心思路是：让多个 agent 按角色协作，走 GitHub 的 PR 流程开发，而不是让一个模型在一个会话里从头写到尾。
具体设计
我把开发拆成几个角色：
- 需求师：把想法写成可执行的规格；
- 工程师：在独立 worktree 里实现，提 PR；
- 审查师：独立验证和审查，不直接相信实现者；
- 队长：负责任务调度、PR 跟进和异常处理。
一个任务大致这样流转：
需求规格
→ 独立 worktree 实现
→ 提 PR
→ 独立验证
→ 独立审查
→ 待合并池
→ 人工 / Codex 合并
几个关键约束：
- 每个任务从最新
main拉独立 worktree，不在主目录混改； - 任务写成契约：目标、验收、改动范围、验证命令；
- 实现、验证、审查必须是不同的人；
- 验证绑定具体 commit，并看真实 CI，不只看本地测试；
- 审查不通过就返工，修完重新验证/审查；
- 合并权保留给人或 Codex，队长和成员不自动合并。
队长负责看当前有哪些任务在跑、哪些卡在验证或审查、哪些在等合并，并处理冲突、CI 红灯、额度不足之类的问题。
效果
用这种方式，我累计完成了 34 个 PR、112 个 commit。
但真正跑起来之后，也暴露了几个问题：
- 不能完全自动化。 需求取舍、合并顺序、冲突处理、验证结论的可信度，仍然需要人来判断。
- workflow 不稳定，很难稳定、持续地开发。 Agent 会失败、上下文会超限、provider 会限流；队长上下文累计后会漂移，状态和真实仓库对不上；成员也经常要因额度或工具问题移除重加，旧任务重排。最后仍然需要人不断中断、纠正、重新给边界。
- 任务通常需要队长手动派发和催办。 自动调度并不总是可靠，失败、暂停、换人之后都要重新派任务，队长实际上变成了调度员。
所以我又做了一个新的插件：dsh-auto-workflow。
它要解决的核心问题，是把 workflow 从队长的会话上下文里拿出来：流程状态、任务和调度规则由插件持久化管理，而不是靠 captain 记住一切。这样才有机会减少漂移，让自动化开发变得可持续。
dsh-auto-workflow 还在开发中。这篇算是对上一版实践的一个阶段记录：它确实能跑，也确实完成了很多工作，但离“稳定持续的自动化开发”还有距离。