介绍构建软件工厂所需的开放、可组合、以代码定义的基础设施栈，涵盖工厂即代码、数据与上下文及计算层。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @zachlloydtweets# 软件工厂技术栈 软件工厂应当构建在一个开放、可组合且以代码定义的基础设施栈之上。(https://docs.warp.dev/factories/factory-as-code/) 开放 == 兼容任意模型、智能体及托管配置 可组合 == 你可以采用该技术栈的部分或全部，并按需使用其中的组件 以代码定义 == 工厂状态可版本化、可测试、可回滚 在本文中，我将介绍我们为 Warp Factories 设计技术栈的方式。这些原则同样适用于任何希望转向工厂模型的人。(https://www.warp.dev/factories) 让我们逐层拆解，从底层基础开始，逐步向上： ## 工厂即代码 整个工厂技术栈的底层是工厂即代码（Factory-as-code）的定义，以 factory.yaml 为起点，包括：(https://docs.warp.dev/factories/factory-as-code/) - 智能体配置：其提示词、技能、MCP 以及模型路由配置 (https://docs.warp.dev/factories/factory-agents/) (https://docs.warp.dev/platform/harnesses/) - 运行器（Runners）：工厂运行环境的相关信息（例如如何启动工厂智能体）(https://docs.warp.dev/platform/runners/) - 代码仓库（Repos）：与工厂所操作产品对应的一组代码仓库 - 自动化（Automations）：驱动智能体行为的触发器与动作，例如定时 cron 任务、错误监控推送、任务看板状态变更、GitHub 拉取请求更新等 (https://docs.warp.dev/factories/automations/) - 集成（Integrations）：工厂所集成的工具（例如 Slack、Jira），以及用于从外部触发工厂动作的 Webhook 配置（例如 Grafana 或 Sentry 告警）(https://docs.warp.dev/factories/connect-your-factory/) - 评分器、评估与基准测试：用于衡量工厂质量的工具 (https://docs.warp.dev/factories/measure-and-improve/) 代码的具体格式不如采用基于代码的方式重要——后者允许对工厂定义进行版本化变更。版本化开启了基准测试、A/B 测试、回滚等可能性。这就是工厂领域的 Terraform。如果你的工厂以代码定义并进行版本管理，你（或你的智能体）将更容易对其进行测试和改进。 ## 数据与上下文 技术栈的上一层是工厂的上下文层（Context Layer），由以下部分组成： - 内部 MCP 与 CLI：供工厂智能体将组织信息拉取到智能体上下文中的工具，以及用于管理其使用的认证与 RBAC 系统 (https://docs.warp.dev/platform/mcp/) - 记忆（Memories）：智能体存储的学习内容（例如"以下是我们关于全局常量的编码规范"），可通过用户的显式指令或推断出的改进来生成。这些内容可存储于第三方服务、向量数据库或普通文件中 (https://docs.warp.dev/agents/agent-memory/) - 智能体追踪（Agent traces）：工厂智能体所有历史运行记录（完整对话日志），以及智能体运行的元数据，如成本、耗时等。这些构成了自我改进循环的原始输入。 - 智能体遥测与访问日志：所有智能体交互及工具调用的完整审计追踪，用于安全与调试 - 代码仓库（Repos）：工厂所操作的代码，以及存储于该代码中的版本化智能体技能（Skills） - 技能与插件市场：用于发现和使用内部技能（Skills）的可扩展方式 (https://docs.warp.dev/factories/factory-skills/) 上下文层应具备可插拔性与可扩展性。 如果你使用的是第三方上下文层，你应当能够将其中所有数据存储在自己的基础设施上。任何外部提供商都不应有权使用这些数据进行训练。零数据留存（ZDR）是必须的。(https://x.com/zachlloydtweets/status/2097701689340129781?s=20) ## 计算 再往上是计算层（Compute Layer）。这是你的智能体实际运行的地方。 在计算层，你需要： 远程开发环境：可通过 Docker、k8s 或任何其他云托管原语来定义。(https://docs.warp.dev/platform/environments/) - 需要具备快速启动、拉取代码仓库、安装工具链、构建并运行应用的能力 - 应支持暂停、恢复，并允许跨机器迁移状态 计算机与浏览器使用：应能够接入计算机使用模型，以测试代理在远程开发环境中构建的应用程序。这对于复现问题、验证结果和原型开发非常有用。(https://docs.warp.dev/agents/capabilities/computer-use/) 多平台支持：根据应用需求，可能需要跨 Linux、Mac 和 Windows 的运行能力。这对于构建原生应用和移动应用的开发者尤为重要，而不仅仅是浏览器应用。 如果你正在评估工厂基础设施提供商，应确保计算资源支持自托管。(https://docs.warp.dev/platform/self-hosting/) ## 推理 推理层应支持运行任意模型和任意代理，以便你能够持续演进和测试工厂配置，从质量、成本和速度三个维度进行优化。这也能防止供应商锁定，避免单一模型提供商对你的组织形成长期定价优势，同时规避仅依赖单一模型来源所带来的风险（例如监管风险等）。 应支持前沿模型和开放权重模型，以及多种代理框架，以便测试其质量。 例如，至少应有一个支持开放权重模型的框架，如 Warp Agent 或 OpenCode，同时还应能直接运行各模型实验室提供的主流模型框架，如 Claude Code 和 Codex。(https://docs.warp.dev/platform/harnesses/) 此外，还应支持多种推理来源，包括连接以下 API： - 来自模型实验室等外部提供商（如 OpenAI、Anthropic、xAI） - 来自提供开放权重模型服务的新兴云平台（如 Baseten、Fireworks） - 来自超大规模云服务商托管，如 AWS Bedrock 和 GCP Vertex - 来自自托管的微调模型 最后，应支持可调节的模型路由，以便在对工厂进行测量和基准评估时，能够调整模型与框架的组合，从而针对自身工作流优化性能。 ## 改进 任何软件工厂的重要组成部分，是改进基础设施：工厂提供哪些机制，以确保软件随时间推移以更高质量、更低成本持续构建。 改进的第一步是指标与可观测性。工厂应提供以下可见性：(https://docs.warp.dev/factories/factory-dashboard/) - 每个 PR 的成本 (https://docs.warp.dev/factories/measure-and-improve/) - 自动化衡量指标 - 周期时间 - 以及更多…… 所有原始内部指标数据应可通过 MCP 和 API 获取，以便你（以及你的代理）能够对数据进行多维度分析，了解工厂吞吐量。 一旦拥有可靠的指标，就需要建立改进基础设施： - 评分器：以 LLM 作为评判者，或通过人工反馈对历史运行记录的不同维度进行评估 (https://www.warp.dev/blog/engineering-self-improving-software-factories) - 回放：能够以完全相同的初始状态重放真实工厂任务，以测试不同配置之间的差异 - 基准测试：创建包含不同配置的测试任务套件，以实证方式测试不同工厂模型与框架配置在真实工作中的表现 (https://www.warp.dev/blog/warp-factory-benchmarks) - 自我改进：由代理自动发现工厂中潜在的改进领域，并建议对模型路由、技能等工厂配置进行变更 (https://www.warp.dev/blog/agent-self-improving-software-factories) 请注意，可量化的改进只有在以下条件满足时才成为可能： - 工厂存储并开放所有改进所需的数据。 - 工厂以代码形式定义，因此你可以可靠地测试和衡量改进效果。否则，你只是在凭感觉猜测。 ## 编排层 你的工厂需要一个运行时，它需要具备： - 启动执行工作的智能体的能力 - 对所有正在运行的智能体进行跟踪 - 在智能体发生故障时进行恢复 - 一个中央"控制室"仪表板，向管理工厂的人员展示当前状况（https://docs.warp.dev/factories/factory-dashboard/） 可以将其视为工厂的"控制平面"，它应当处理以下事项： - 从所有集成点启动智能体 - 管理自动化任务和定时任务 - 将工作拆分给子智能体，并监控其进度 - 支持在智能体运行时对其进行实时干预 - 支持将智能体工作从云端切换至本地执行（https://docs.warp.dev/factories/factory-mcp/） 如上所述，编排层应支持多种智能体框架，并为与所有框架协同工作及存储各自产生的数据提供统一接口。 ## 访问层 访问层位于工厂技术栈的顶端。 "访问"是指工作如何通过外部系统进出工厂。 这些系统包括： - 可使用 Factory MCP 与工厂通信、向工厂提交或提取工作的外部编码智能体（https://docs.warp.dev/factories/factory-mcp/） - Slack / Teams、Jira / Linear 等知识工作工具（https://docs.warp.dev/factories/connect-your-factory/） - 代码托管平台（Github / Gitlab / Azure Devops），你可以在其中审查 PR（https://docs.warp.dev/factories/connect-your-factory/） - 专用的 Web 和移动端 UI，用于与工厂交互 所有这些访问入口在底层都应使用一套统一的 API，支持启动工作、监控进度、更新工厂定义等操作。（https://docs.warp.dev/reference/api-and-sdk） API 优先至关重要，因为它允许智能体在人类监督下对工厂进行调试和控制。 ## 结语 总而言之，随着世界向自动化开发迈进，你应当将自己的软件工厂视为一套基础设施技术栈来规划。Warp Factories 提供了这一技术栈的开放、可组合实现。 Warp Factories 正在被财富 500 强企业部署，帮助它们扩大开发规模，同时可量化地提升编码智能体的投资回报率。 如果你正在探索采用软件工厂方法，我们诚挚邀请你与我们交流。（https://warp.dev/factories/request-access）
