为了尽量发挥 AI 在项目开发里的作用，我用开源的 dsh-agent-teams 插件搭了一个自动化开发工作流。核心思路是：让多个 agent 按角色协作，走 GitHub 的 PR 流程开发，而不是让一个模型在一个会话里从头写到尾。

具体设计

我把开发拆成几个角色：

• 需求师：把想法写成可执行的规格；
• 工程师：在独立 worktree 里实现，提 PR；
• 审查师：独立验证和审查，不直接相信实现者；
• 队长：负责任务调度、PR 跟进和异常处理。

一个任务大致这样流转：

需求规格
  → 独立 worktree 实现
  → 提 PR
  → 独立验证
  → 独立审查
  → 待合并池
  → 人工 / Codex 合并

几个关键约束：

• 每个任务从最新 main 拉独立 worktree，不在主目录混改；
• 任务写成契约：目标、验收、改动范围、验证命令；
• 实现、验证、审查必须是不同的人；
• 验证绑定具体 commit，并看真实 CI，不只看本地测试；
• 审查不通过就返工，修完重新验证/审查；
• 合并权保留给人或 Codex，队长和成员不自动合并。

队长负责看当前有哪些任务在跑、哪些卡在验证或审查、哪些在等合并，并处理冲突、CI 红灯、额度不足之类的问题。

效果

用这种方式，我累计完成了 34 个 PR、112 个 commit。

但真正跑起来之后，也暴露了几个问题：

1. 不能完全自动化。 需求取舍、合并顺序、冲突处理、验证结论的可信度，仍然需要人来判断。
2. workflow 不稳定，很难稳定、持续地开发。 Agent 会失败、上下文会超限、provider 会限流；队长上下文累计后会漂移，状态和真实仓库对不上；成员也经常要因额度或工具问题移除重加，旧任务重排。最后仍然需要人不断中断、纠正、重新给边界。
3. 任务通常需要队长手动派发和催办。 自动调度并不总是可靠，失败、暂停、换人之后都要重新派任务，队长实际上变成了调度员。

所以我又做了一个新的插件：dsh-auto-workflow。

它要解决的核心问题，是把 workflow 从队长的会话上下文里拿出来：流程状态、任务和调度规则由插件持久化管理，而不是靠 captain 记住一切。这样才有机会减少漂移，让自动化开发变得可持续。

dsh-auto-workflow 还在开发中。这篇算是对上一版实践的一个阶段记录：它确实能跑，也确实完成了很多工作，但离“稳定持续的自动化开发”还有距离。

Motivation

WorkBench executes tool calls in a sandbox and evaluates the resulting environment state. Two observations from reproducing CoA motivated this experiment.

Failures with side effects

I distinguish two kinds of failure:

• E1: failures without side effects.
• E2: failures that create side effects inconsistent with the target state.

CoA-v1 raises accuracy from 38.35% to 73.63% relative to SingleAgent, while E2 also rises from 5.19% to 24.15%. E2 accounts for about 92% of CoA-v1 failures. Stronger tool use therefore brings a second concern alongside task completion: changing the environment in the wrong way.

Plan-induced trajectory inertia

Once a plan is fixed, later tool choices are conditioned on it. If reflection only appends a judgment to the trajectory without invalidating the old plan, subsequent actions can still follow that plan. When the error is in the plan itself, reflection alone cannot change the direction of the trajectory.

This suggests two requirements: intercept inappropriate calls before execution, and discard the old plan when a call is rejected.

Reflection and replanning

DR-CoA (Dual-Reflection CoA) adds reflection before and after each tool call. A rejection before execution requires replanning.

1. Propose a call. Store the candidate tool call as pending_tool.
2. Check before execution. pre-reflect checks task and plan alignment, necessity and redundancy, parameter validity, and prerequisites for actions with side effects.
3. Allow or replan. An allow decision executes the call. A replan decision discards pending_tool, invalidates the old plan, and returns to planning.
4. Check the outcome. After execution, post-reflect checks whether the observation supports the current plan. If it does not, the system returns to plan.

A rejected call commonly exposes an issue in task interpretation, ordering, or dependencies rather than a single bad parameter. Making replanning an explicit state transition is intended to break this trajectory inertia.

Results on WorkBench

All systems use deepseek-v4-flash as the underlying model. DR-CoA-v2 adds phase-specific prompts to the v1 state machine. Acc denotes accuracy; E1 and E2 are the failure categories defined above.

Compared with CoA-v1, DR-CoA-v2 raises accuracy from 73.63% to 85.03% and lowers E2 from 24.15% to 11.96%.

Interpretation and limitations

The change cannot be attributed entirely to replanning: DR-CoA also introduces pre- and post-reflection and state constraints, and v2 changes the prompts. This comparison measures the combined system rather than the isolated effect of replanning.

The results support trying a return to plan when a proposed action with side effects is judged inappropriate, before patching the existing trajectory.