编者摘要：搭建 AI 软件工厂有四种模式：自研、采购平台、Fork 开源项目、全权委托给常驻智能体。自研自主拼装任务接入、调度、沙箱、校验、评测闭环，自由度最高，但工程成本重；采购依托 Warp 等平台，开箱即用，配置驱动；Fork 以 Open SWE 这类开源底座起步，复用成熟架构，兼顾可控与效率；委托模式依靠 Always-on Agent 自主串联工具，上手最简单，但编排逻辑隐式、链路分散。
四个维度对比：任务接入、工作调度、结果校验、工厂自迭代。自研、采购、Fork 属于 “智能体在工厂内”，具备可观测、可实验、可量化迭代的能力；委托是 “工厂装在智能体内”，最大短板是缺少标准化观测与评测闭环，难以系统性优化。Checkpoint 机制被视为弥补方案，只定义验收标准，不限制执行路径。 现实方案大多混合搭配。长期看行业会走向原语标准化，部分范式成为主流。
10个关键问题 Q&A
-
Q：搭建 AI 软件工厂的四种模式是什么？ A：自研、采购平台、Fork 开源、全权委托给常驻智能体。 -
Q：自研和委托模式最本质区别？ A：自研是智能体放入显式工厂系统；委托是把整套工厂逻辑放在 Agent 内部动态执行。 -
Q：委托模式为什么简单？ A：不需要提前硬编码全链路流转规则，Agent 自主判断下一步、调用工具。 -
Q：委托模式最大缺陷？ A：链路分散、编排不透明，缺少统一观测层，很难系统性迭代优化工厂本身。 -
Q：Fork 模式的典型开源代表？ A：Open SWE，自带接入、调度、CI 评审链路，配套 LangSmith 追踪。 -
Q：采购模式代表平台有哪些？ A：Warp、Factory.ai、Port.io，内置任务接入、Runner、Benchmark 评测。 -
Q：软件工厂 “自迭代” 闭环怎么做？ A：采集运行轨迹→构建评测集→变更配置→重跑对比，用测试 + LLM-as-a-judge 打分。 -
Q：Checkpoint 思路用来解决什么问题？ A：给委托式 Agent 增加稳定、可度量的验收节点，保留 Agent 自主执行的灵活性。 -
Q：四种模式是互斥二选一吗？ A：不是，企业落地大多混合，比如 Fork 底座 + 采购沙箱 + 自研校验 + 局部委托。 -
Q：行业长期趋势是什么？ A：底层能力原语走向标准化，大量异构方案收敛，少数范式成为主流。
附录 软件工厂之争：自研、采购、Fork 开源，还是全权委托
当下搭建软件工厂，基本有四条路径：自行组装基础设施搭建工厂、采购现成工厂平台、Fork 一份开源软件工厂并改造为自用版本；还有一个越来越流行的思路 —— 舍弃大部分工厂基础设施，直接把任务交给常驻智能体（always-on agent）。
自研（Build）：围绕编码智能体，搭配配套基础设施自行搭建整套工厂，把智能体单次执行的能力整合成一套持续运转的系统。组件自主选型，并且全权掌控组件之间的集成逻辑。
采购（Buy）：直接使用成熟工厂平台，例如 Warp、Factory.ai、Port.io。平台已经封装好大部分底层基建，你只需要在更高层界面上配置、持续优化工厂的运转规则。
Fork 改造（Fork）：基于已有开源软件工厂（比如 langchain-ai/open-swe）起步，适配自身业务环境。复用现成的工厂架构，而不是从零搭建整套系统。
全权委托（Delegate）：使用常驻智能体（例如 Grok Bot、OpenAI Dots），授予它足够权限自主协调工作。不用手动定义各个系统之间每一步流转逻辑，由智能体自主判断下一步动作、直接调用各类工具系统。
这四种方式都可以接收工单，最终产出 Pull Request。下面对比四者，看清各自架构取舍与局限。
工单流入工厂：任务接入层
软件工厂需要持续发现待办任务。任务来源可以是 Linear / Jira 工单、GitHub Issue、Slack 消息、CI 构建失败、线上故障、依赖包升级、定时运维任务，未来甚至是工厂自己主动识别出来的问题。
- 自研
把任务源头系统直连到你的工厂。GitHub Webhook 可以在 Issue 打上标签时触发任务；Linear、Jira 可通过工单状态变更触发；Slack 接收需求；CI 在构建失败时生成修复任务。这些事件送入 Temporal、Trigger.dev 或者自研队列 / 任务服务，在这里加上身份鉴权、优先级、权限控制、去重、就绪判断等逻辑，把原始事件转化为交给智能体执行的正式任务。 - 采购
接入能力大多内置。以 Warp 为例，它支持外部系统、自动化流程推送任务。不需要为每一类任务源单独开发接入层，工厂平台统一承接输入、启动任务流程。 - Fork 改造
开源项目自带一套初始接入架构。例如 Open SWE 原生支持 GitHub、Slack、Linear 和定时触发器。你依然要对接、适配这些入口到内部环境，但不用从零设计整套任务接收体系。 - 全权委托
常驻智能体依靠工具能力直接跨系统感知任务。它读取需求、查看工单、收集上下文、判断任务是否可执行，信息不足时主动找人澄清。任务只需要从 Slack 这类入口流入，就可以启动整条链路。
任务协同调度层
任务进入工厂后，系统需要决定后续流程：任务拆解、分派给指定工作节点、选用特定大模型、并行分片执行、失败重试、升级人工介入。
- 自研
执行层由可替换组件拼装而成。Temporal AI 提供持久化工作流与重试能力；Modal、E2B、Daytona、K8s 提供隔离计算环境；Claude Code、Codex、OpenCode 作为工作智能体运行在沙箱内；GitHub 分支 / 工作树隔离代码变更。你自己编写路由与监控逻辑，管控执行节点、模型、上下文与凭证、并行策略、失败兜底。 - 采购
例如 Warp 可以用工厂智能体，调度多套拥有独立提示词、工具、模型、测试环境的专用子智能体；Runner 定义任务运行环境。不用手写编排和执行底层，通过配置驱动系统。 - Fork 改造
核心调度逻辑已经写在你可掌控的代码里。Open SWE 采用统一智能体架构，划分规划、执行、CI 监控等软件生命周期模块。你可以修改架构、替换组件、新增能力，而不是从头设计调度体系。 - 全权委托
很多调度规则不需要提前硬编码。常驻智能体观察当前状态、自主决策下一步，调用编码智能体或者沙箱环境，观察结果之后继续判断。底层算力依然存在，但专门用来做调度的基础设施可以大幅简化。
自研、采购、Fork，是把智能体放进工厂里；全权委托，更像是把工厂装进一个智能体里面。
结果校验层
工厂必须校验产出是否合格。测试、静态分析是基础；自主化流程还会叠加智能体评审、安全扫描、浏览器 / 真机验证、部署验收、人工审批。
- 自研
GitHub Actions / Buildkite 跑测试与静态扫描，Snyk / Semgrep 做安全门禁，Playwright 验证业务功能。智能体评审负责处理需要主观判断的检查。你自行组装判定逻辑：验收通过、退回重改、呼叫专项智能体、切换模型、升级人工。 - 采购
Warp 提供 Benchmark 能力，用来评估单次任务输出，也可以跨不同配置批量跑标准任务。评测能力和生产链路打通，评测不再是独立后置环节。 - Fork 改造
校验流程随开源基线自带，支持扩展或替换。Open SWE 内置 CI 监控、代码评审流程，可以识别失败、响应反馈、继续迭代。你拿到一套可运行的校验闭环，同时可以自由修改规则。 - 全权委托
智能体同样可以通过工具串起校验流程：跑测试、排查报错、呼叫其他智能体评审、退回修改、卡住时上报。不需要预先穷举 “校验失败→重试” 的所有分支路径。
工厂自迭代优化层
工厂还需要一套优化自身的机制。这种持续迭代、改良工厂本身的能力，才是软件工厂模式真正的威力。 通用范式：采集真实任务数据，把代表性样例做成评测集；修改工厂配置；重跑任务对比效果。 一部分结果可以用测试做确定性判定；越来越多场景使用 “大模型裁判（LLM-as-a-judge）”，由另一个模型按标准打分。以此对比不同模型、沙箱、提示词、技能、路由策略、工具组合，在质量、成本、时延、故障率、人工介入率几个维度横向评估。
- 自研
迭代闭环全部自己搭建。采集线上智能体轨迹和结果，抽取典型案例构建评测集，在工厂变更后重放对比。测试负责正确性打分，LLM-as-a-judge 评估代码质量、任务合规性、执行效率；再把分数反向关联到对应的模型、沙箱、提示词、路由、工具配置。 - 采购
优化闭环属于平台能力。Warp 的 Benchmark 可以回放历史任务、或者跑自定义任务集，测试不同模型、沙箱、工厂配置。打分器依托大模型裁判，评估正确性、质量、效率以及自定义指标，评估结果反哺模型路由与工厂配置。 - Fork 改造
Open SWE 默认对接 LangSmith 做链路追踪。可以拿到智能体运行轨迹，把真实任务转为数据集、做多版本对照实验，用代码、人工反馈或者大模型裁判完成评测。 - 全权委托
这条路径目前短板明显。你可以让常驻智能体切换模型、新增技能，但很难量化对比改动带来的差异。
委托方案的短板
四种路径里，全权委托是最存疑的软件工厂形态。自研、采购、Fork 都构建了一套显式、结构化的工厂系统；全权委托更不透明，由模型动态调度大部分流程。
它的吸引力在于足够简单易用。但同时，它丢掉了一部分让工厂可工程化改进的结构。
传统工厂会产出完整流转日志：工程师清楚工厂预期行为、实际发生了什么，修改系统之后还能量化指标变化。 全权委托模式让这三件事都变难：任务链路没有统一承载系统，证据分散在常驻智能体、编码工作节点、GitHub、CI、工单系统和各类工具中；整套 “工厂” 本身很难被清晰定义，大部分编排逻辑在智能体循环里动态生成。
换句话说，常驻 Bot 本身就是系统。但它缺少一套埋点观测层，用来观测、管控任务，同时保留智能体自主决策的自由度。
检查点（Checkpoint）有望补上这个缺口：检查点定义任务必须满足的条件、以及用来证明达标所需证据。它提供明确、可采集、可修改、可度量的标准，至于用什么路径完成任务，交给智能体自主决定。Thruwire.ai 就在探索：用检查点构建稳定可衡量的任务表达，而不是强制规定执行路径。
小结：这场争论的答案
把自研、采购、Fork、全权委托当成互斥选项，更多是一种思想实验。现实里的软件工厂几乎都是混合模式：Fork 一份开源底座、采购沙箱基础设施、自研专属校验规则，同时用常驻智能体协调那些不需要显式编排的工作。
风险在于：如果每家公司都从零搭建一套完全不一样的软件工厂，新入职工程师就要额外学习一套内部私有系统。未来很可能会出现底层原语的标准化。
标准化也会带来商品化。长期来看，不太可能一直维持这么多迥异的搭建范式，一部分模式会胜出，成为行业主流标准。
术语对照表
-
Software factory：软件工厂（AI 编码智能体流水线） -
Always-on agent：常驻智能体 / 在线值守智能体 -
Fork：基于开源仓库分叉改造 -
LLM-as-a-judge：大模型裁判 -
Checkpoint：检查点 -
Trace：运行轨迹 / 链路追踪 -
Orchestration：编排调度 -
Pull Request：PR，代码合并请求