工程团队已经会把云端 Agent 接到触发器上：新 Issue 进来就复现打标，PR 打开就留评，Sentry 报警就排查，CI 挂了就找回滚，文档和 changelog 跟着改，浏览器代理做一轮视觉验收。Trigger → Agent Activity，单点风险低、成本低，也确实能培养手感。

我起初觉得把这些点连起来，软件工厂就出现了。后来看完一轮“评审变好了、分诊还是老样子、QA 读不到评审学到的约束”，才发现缺的不是更多触发器，是一条能被度量、能被回滚的闭环。

点状自动化能跑完一段工序，带不走下一段工序的上下文

常见起步有两条路。一条是自研：Claude Code SDK 塞进容器，再用服务把 GitHub、Sentry、CI 事件接进去。另一条是买阶段产品：专门的 Agent 评审器、AI SRE、文档生成器。两条路在爬行期都成立，因为它们自动化的是软件生命周期里的一段，不是整条产线。

三件事会在叠加之后同时出现。改进停在烟囱里——评审提示词调好了，分诊和验收用的仍是另一套记忆。全局指标看不见——单 PR 成本、周期时间、自动化比例没有跨阶段的账本，只能靠感觉说“好像快了”。治理表面膨胀——每套点方案自带配置、密钥、审计缺口和观察死角，平台组最后会要统一策略，而不是再接一个 Webhook。

这就像车间里每道工序都买了一台会干活的机械臂，却没有一条传送带和一块总电表。手臂越来越勤快，厂长仍然说不清这周合格件变贵了还是变便宜了。

走起来之前要先回答工厂建在哪，而不是先回答再用哪个模型

能把爬行期问清楚的团队，问题会从“这个机器人灵不灵”变成“我们到底要一套什么系统”。开发默认发生在本地还是云端沙箱；成功自动化长什么样、用哪些指标；编码 Agent 的数据归谁、对模型供应商依赖到什么程度；成本和吞吐怎么一起管；模型与监管变化时有没有退路；工程师、设计、产品各在哪一个闸门上手；产线被渗透时怎么停机和追责。

想明白的人，多半会落到云端软件工厂这一侧：默认在云上开发，把沙箱交给 Agent，而不是把仓库密钥散落在笔记本里；集中治理 Agent 能碰的工具；留下完整轨迹，用来审计也用来解释产能；模型和 Harness 可替换，避免锁死一家；接上已经在用的 Slack/Teams、Jira、GitHub；人可以中途接管，或把工作拖回内圈；有一层跨阶段共享的上下文；有评测和基准，让“变好了”能被证伪。

这不是经典的自建或采购二选一。工厂必须嵌进自家仓库、权限和工序，内部团队一定要写东西。该写的是组织特异的 Skills、内部 MCP、私有上下文源。不该从零再写一遍的，往往是所有公司都要的那一层：云上跑 Agent、转向、交接、计量、计算机使用、审计。经验法则很硬：只造对本组织特殊的零件。

走的阶段真正算迈出去的，是在一个低风险产品表面上打通端到端。营销站或内部工具够用。仓库一多、依赖一深、干系人一增，团队很容易得出“我们还没准备好自动化”。先把一条短环跑热，再加复杂度。

目标环是分诊 → 规格 → 实现 → 评审 → 验收 → 监控。新 Issue 进来，分诊 Agent 复现并判断：能自动就交给实现；范围不清就和人一起写规格；含糊就停住或挂起。实现写代码，评审看 diff，验收用计算机使用或其他检查，人看代码和验收记录，必要时退回前面任意一站，再进 CI/CD、发布、监控。监控再开新 Issue，环才闭合。

Warp 自己把这条走阶段工厂用在 warp.dev 营销站上，大约 75% 的变更能从一句需求走到发布，人主要出现在 Slack 或任务系统里把改动说清楚。那和 Warp Terminal 不是同一量级：后者是近百万活跃开发者、约一百万行原生 Rust 的产品。75% 说的是简单表面上的闭环覆盖，不是核心客户端已经交给工厂值夜班。

# factory.yaml —— 工厂状态应当能进 Git，而不是散落在各家控制台
schemaVersion: v1alpha1
name: marketing-site
repositories:
  - owner: acme
    name: www
intake:
  - slack
  - linear
agents:
  triage:
    harness: claude-code
    skills: [repro-issue, label-risk]
  implement:
    harness: codex
    skills: [repo-conventions]
  review:
    harness: claude-code
    policy: "不合并未经验收的视觉回归"
  verify:
    computer_use: true
gates:
  human:
    - spec-approval
    - final-merge
metrics:
  - cost_per_merged_pr
  - cycle_time_hours
  - automation_rate

def stage_handoff(issue, shared_ctx):
    """阶段之间只传递被记录的上下文，不靠各工具自己的聊天窗口。"""
    decision = triage(issue, shared_ctx)
    if decision == "ambiguous":
        return park(issue)  # 含糊就停，不让实现 Agent 猜产品意图
    if decision == "needs_spec":
        spec = wait_human(spec_agent(issue, shared_ctx))
        shared_ctx = shared_ctx.with_spec(spec)
    pr = implement(issue, shared_ctx)
    review = review_agent(pr, shared_ctx)
    qa = verify_agent(pr, shared_ctx)
    return merge_if(human_ok(pr, review, qa))

跑起来之后先爆的是远程环境和评测，不是又一个触发器

基本环在简单项目上站住，再扩到复杂仓库。远程开发环境会先成为瓶颈：多仓、大代码量、服务依赖会让“在云里复现”本身失败。Skills 和配置一多，改工厂到底提高了交付还是制造了抖动，没有评测就分不清。任务变长、模型更贵，路由和 Harness 选择开始直接决定单 PR 成本。核心用户面应用一进工厂，安全和审计从可选项变成地板。干系人变多，需要可追溯的多人输入，而不是某个 Agent 在私聊里点头。PR 堆积后，必须写清哪些走人工评审、哪些相信 Agent 验收。发布后的质量闭环也要单独设计，否则工厂会把缺陷加速送进生产。

把软件工程做成工厂工程，接下来几年会比再写一个编码助手更难。能把工厂做稳、做可观测、做自改进的组织，比拼的是单位成本吞吐，不是谁先接到了更新的模型。

真正转起来的工厂有几个不显眼却关键的层。工厂即代码，配置可测、可对比、可回滚，换一条分诊规则像换一条流水线参数。多模型、多 Harness，前沿权重和开源权重都能进同一条产线，Claude Code 和 Codex 不该绑死布局。数据所有权必须留下，轨迹是改进工厂的原料，不是供应商日志里的边角。API 优先，这样 Agent 才能在人的监督下调试工厂自身。

闭环、可测、可改进，是这一阶段唯一站得住的目标。所有人在同一份被审计的上下文里干活；观察 Agent 盯着 Skills 和配置，提出改工厂的 PR；平台组把内部系统接进去；工程负责人看见的是产能指标和改动归因，而不是“大家觉得 Agent 更会了”。经验还在，账本必须先在。

Zach Lloyd 把这条路径写成 Warp 的采用模型，产品侧对应的是仍在 Early Access 的 Warp Factories；合格团队有工厂用量额度，但这套分层并不依赖某一家控制台。自建传送带或借用现成栈，检验标准相同：阶段之间能否共享上下文，指标能否跨过触发器，人能否在闸门上把手停住。

你们现在堆在 GitHub Action 和专用评审机器人上的那些自动化，有哪一项改进曾经反向写进过分诊或验收？若从来没有，下一笔预算是再买一个点方案，还是先给现有触发器加一条共同的轨迹和一组跨阶段指标？

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。