Warp CEO Zach Lloyd 昨天发布了"云端软件工厂"系列的第二篇文章，核心主题是：如何让 Agent 处理那些太复杂或太模糊、无法一次性搞定的问题。
这是该系列的第二篇。第一篇搭建了一个简单的 Triage → Implementation 流水线：Agent 审查 issue 质量，问澄清问题，如果 scope 足够清晰就直接实现为 draft PR。这对简单 bug 和小功能很有效，但遇到复杂需求就抓瞎了。
新增 Spec Agent：给复杂需求加一层"设计文档"
第二篇的解决方案是引入 Spec Agent，在 Triage 和 Implementation 之间增加一个规格设计层。整个流程变成：
Triage → Spec → Implementation
Triage Agent 的判断逻辑也相应升级：
- 简单需求 → 标 "ready-to-implement" → 直接进 Implementation Agent
- 复杂但符合路线图的 → 标 "ready-to-spec" → 进 Spec Agent
- 信息不足的 → 标 "needs-info" → 等补充
- 其他 → 标 "wait-to-implement" → 暂搁置
什么算"复杂"？
Zach 给了两个简单标准：
模糊（Ambiguity）：存在多种潜在的产品或技术实现路径，差异显著，需要人类拍板选哪个。
复杂（Complexity）：实现需要超过几百行代码。
为了让 Triage Agent 能判断"是否符合路线图"，Zach 在示例项目中加入了两个全局上下文文件：
roadmap.md：描述产品演进方向vision.md：描述最终想成为什么
这两个文件被注入到 Triage Agent 的上下文中，让它在分类时能对照长期目标做判断，而不是只看眼前这个 issue。
双规格文档：PRODUCT.md + TECH.md
Spec Agent 被触发后，会产出两份规格文档，都存放在与 issue 编号绑定的 specs/ 目录下：
PRODUCT.md：定义产品行为——这个功能应该做什么、用户交互流程是什么、边界情况怎么处理。相当于传统开发中的 PRD（产品需求文档）。
TECH.md：定义技术架构和代码结构——模块划分、接口设计、数据流、依赖关系。相当于传统开发中的技术方案文档。
两份文档分离的设计很聪明：产品规格给 Implementation Agent 约束"做什么"，技术规格约束"怎么做"。Agent 在实现时既有明确目标，又有清晰的架构指导，不会因为"理解偏差"而走偏。
Zach 建议把这些规格文档随实现 PR 一起提交，作为"Agent 当时想做什么、怎么做的"记录，方便后续验证和审计。
人机协作的 refinement 环节
Spec Agent 产出的初版规格通常需要打磨。Zach 推荐了一个互动式精修流程：把规格拉到本地工作区，和 Agent 一起迭代对齐预期。他特别推荐了 Matt Pocock 的 /grill-me Skill 来完成这个环节——本质是让 Agent 扮演"挑剔的审校者"，不断追问、挑战规格中的模糊点，直到双方都满意。
这个环节体现了 Warp 对"完全自动化"的务实态度：不是追求零人类介入，而是在关键环节（规格设计）让人类做不可逆决策，把重复性工作（实现、测试）交给 Agent。
与第一篇的衔接
Spec 完成后，issue 被标记为 "ready-to-implement"，触发 Implementation Agent。Zach 更新了 Implementation Skill，让它在执行前先查找并遵循对应的规格文档。这意味着 Implementation Agent 的上下文里不仅有 issue 描述，还有详细的产品和技术规格——实现质量理论上会显著提升。
技术栈与基础设施
整个流水线复用了第一篇的基础设施：
- Docker 镜像（包含代码和工具链）
- 运行环境（示例使用 Warp 的 Oz 云平台）
- GitHub Actions 触发机制
Spec Agent 通过 GitHub Action 触发，与 Triage、Implementation Agent 共用同一套事件驱动架构。
下一步：Review + Verification Agent
Zach 预告了第三篇的主题：引入 Review Agent 和 Verification Agent 来确保实现质量。Verification Agent 会使用 /validate-changes-match-specs Skill 来检查实现是否符合规格文档——这相当于给整个流水线加了一层"验收测试"。
完整流水线展望
三篇文章拼起来，Warp 的云端软件工厂将覆盖完整 SDLC：
Issue 提交
↓
Triage Agent（分类 + 初步评估）
↓
├─ 简单 → Implementation Agent → Draft PR
└─ 复杂 → Spec Agent → PRODUCT.md + TECH.md
↓
人类 review + refinement
↓
Implementation Agent（遵循规格）→ Draft PR
↓
Review Agent + Verification Agent
↓
人类最终 review → Merge
这套架构的核心洞察是：不同复杂度的需求需要不同的处理深度。简单需求直接干，复杂需求先设计再干，模糊需求先澄清再设计。Agent 不是万能的，但放在正确的环节里，它能大幅提升效率。