一位开发者分享了他构建 AI 代理工作流的完整经历。他尝试过两种方式：自己写代码只把琐碎部分交给代理，或把整个任务交给代理最后审计结果。前者太慢，后者在出错时已经太晚。他原本预期要花九篇文章强制代理遵循工作流，结果发现根本不需要强制执行。
这套系统的核心是一个位于仓库根目录的短指令文件，在接触任何任务前先对请求分类。琐碎工作直接内联处理，标准或复杂工作则按完整链路运行，每个阶段读取前一个阶段的产物而非对话记录。底层还有保持产物命名的 slug、区分实际表述与推断内容的清单、以及每个产物必须通过的出口门禁。
让他意外的是，分类结果与他自己的判断一致，无需他干预。小 bug 不会触发完整流程，标准需求、spike 或跨领域任务则按顺序跑完整周期。这套机制让他站在了流程中间——在 brief 阶段批准或退回，在构建前审阅计划，看到需求部分返回时决定是否阻塞工作。
作者坦言，目前无法验证分类是否真正正确，还是仅仅与他的判断一致。如果代理在相同方向上持续犯错，产物看起来会完全一样。此外，整个流程只经过一个人、一个任务，其他人写的产物是否具有同等效力仍是未知数。
他最终将精简版发布为 guide.md，包含分类规则、需求清单和出口门禁，完整版则放在 agentsmyth。这套流程的价值不在于让代理更听话，而是给了开发者一个在代理工作时可以站立的位置——在还有时间调整时，逐阶段观察结果落地。
@DevToolboxHub