Factory over Assistant

这种“助手”模式——在侧边栏中与Agent一对一协作、全程监控其运行、来回交互——会限制生产力与可扩展性。随着模型的自主性与能力不断增强，人类作为反馈回路将成为瓶颈。当你通过侧边栏监控Agent时，同一时间只能运行一个Agent。

从助手模型转向工厂模型：生成多个并行工作的自主Agent，定期检查它们的进度，将时间聚焦于更高层级的编排工作，而非充当反馈回路。

工厂思维模式：

• 分派多个Agent处理不同任务
• 定期检查进度（30-60分钟后）
• 专注于搭建自动化反馈回路（测试、构建、技能模块）
• 以并行性和自主性为优化目标

助手模型正在被淘汰的原因：

1. 并行化受限：紧盯单个Agent时，你只能高效运行这一个实例
2. 人力沦为依赖项：你本应搭建自动化回路，却成了手动反馈环节
3. 优化方向偏差：侧边栏的用户体验优化以“实时监控”为导向，而非“自主工作”
4. 阻碍技术发展：性能较弱的模型在侧边栏场景适配性更好，但更优秀的模型在自主工作模式下才能充分发挥实力

graph TD
    subgraph Assistant_Old["助手模型（旧）"]
        A1[人类] <-->|侧边栏来回交互| B1[Agent]
        B1 -->|一次处理一项任务| C1[结果]
    end

    subgraph Factory_New["工厂模型（新）"]
        A2[人类] -->|分派任务| B2[Agent 1]
        A2 -->|分派任务| B3[Agent 2]
        A2 -->|分派任务| B4[Agent 3]
        B2 -->|自动化反馈回路| C2[结果]
        B3 -->|自动化反馈回路| C3[结果]
        B4 -->|自动化反馈回路| C4[结果]
        A2 -->|定期检查| C2
        A2 -->|定期检查| C3
        A2 -->|定期检查| C4
    end

    style B1 fill:#ffcdd2,stroke:#c62828
    style B2 fill:#c8e6c9,stroke:#2e7d32
    style B3 fill:#c8e6c9,stroke:#2e7d32
    style B4 fill:#c8e6c9,stroke:#2e7d32

演进历程：

| 阶段 | 模型 | 人类角色 | Agent行为 | |-------|-------|------------|----------------| | 过去 | 助手模型 | 全程监控、提供反馈 | 频繁汇报、交互式 | | 当下 | 混合模型 | 搭建自动化回路 | 兼具交互式与自主性 | | 未来 | 工厂模型 | 编排与审核 | 完全自主、极少需要人类介入 |

核心洞见：对于GPT-5.2这类可自主工作45分钟以上的模型，在侧边栏实时监控它们纯属资源浪费。你应该能够一次性生成10个这类Agent，之后再统一检查它们的工作成果。

从助手模式向工厂模式转型

1. 调整时间投入：

# 助手模式（旧）
时间分配:
  监督Agent工作: 80%
  实际开发工作: 20%

# 工厂模式（新）
时间分配:
  搭建自动化循环: 30%
  生成与编排Agent: 20%
  审核与集成: 50%

2. 构建自动化反馈循环：

不再亲自充当反馈环节，而是搭建以下机制：

• Agent可自动运行的测试指令
• 验证正确性的构建指令
• 封装常见操作的技能组件
• Agent可调用的代码检查器（Linter）与代码格式化工具（Formatter）

3. 为不同模式选用适配模型：

• 交互模式：选用Opus这类“响应灵敏的即时型”模型处理快速任务
• 工厂模式：选用GPT-5.2这类“偏研究导向的低交互型”模型开展自主工作

4. 采用异步工作流：

# 旧工作流（助手模式）
用户 → Agent → 用户 → Agent → 用户 → Agent → 结果

# 新工作流（工厂模式）
用户 → 生成(Agent1) + 生成(Agent2) + 生成(Agent3)
→ 处理其他任务
→ 稍后查看进度
→ 集成结果

来自AMP的实践案例：

AMP正逐步停用其VS Code扩展，他们的核心依据是：

• 仅占1%的前沿开发者，仅需在编辑器中完成20%的工作
• 他们的目标是将这一比例降至10%甚至1%
• 侧边栏功能已不再适配前沿开发场景
• 工厂模式能让自主型模型的价值得到更高效的发挥

优势：

• 大规模并行处理：同时运行多个Agent
• 更高效利用人力时间：专注于编排调度，而非全程监控
• 随模型能力扩展：模型自主性越强，工厂模型的效用越高
• 延迟降低：无需等待Agent完成每一步流程
• 吞吐量提升：可并行完成多项任务

劣势：

• 控制权减弱：无法实时引导Agent
• 反馈延迟：可能需要30-60分钟才能发现问题
• 搭建成本高：需要可靠的自动化反馈循环机制
• 调试难度大：出现问题时，对流程的可见性较低
• 工具要求高：需要完善的监控和检查机制

工厂模型不适用的场景：

• 需求尚不明确的探索性工作
• 需要频繁人工指导的任务
• 技能/文档未覆盖的复杂领域知识场景
• 需要快速迭代、交互式反馈更高效的场景

“最后20%”原则：

“对于那1%想要保持领先的开发者而言……他们只需要在编辑器中完成工作的最后20%。而且我们认为这个比例还能降到10%、1%甚至更低。”

工厂模型并非要淘汰编辑器——而是将编辑器的使用范围缩减至最终的集成工作。

与“侧边栏已死”相关： 工厂模型正是AMP弃用其VS Code扩展的原因。该扩展针对助手模型（侧边栏）做了优化，但未来属于工厂模型（通过CLI、进程孵化、自主式工作）。