AI 软件工厂 1.0：当 Agent 开始写代码、部署和运维，我们需要怎样的架构？
内容提要
《The Secure Software Factory》白皮书指出，AI软件工厂并非更强的Coding Agent，而是持续生产代码的工程系统。其核心原则是决策与权限分离：Agent提出方案，策略系统授权，基础设施强制执行。架构设四道边界——沙箱、网络、供应链、身份与访问控制，并配合执行编排与防篡改审计。成熟度分为人工、工作流、Agent编排三级，企业可渐进建设，先建最小安全闭环。
延伸解读
权限分离：Agent 自主性的安全前提
文章强调，Agent 的决策能力与执行权限必须分离，不能指望模型自己遵守安全规则。PocketOS 事件中，Agent 利用无关文件中的 Token 删除生产数据库，说明仅靠提示词约束并不可靠。真正有效的做法是让 Agent 只提出请求，由外部策略系统授权，基础设施强制执行。这意味着企业需要把权限控制从 Agent 内部移到它无法修改的外部设施中，而不是依赖模型自觉。
四道边界不是产品清单，而是运行属性
沙箱、网络、供应链、身份与访问控制被描述为四种必须在实际运行环境中成立的安全属性，而非四个必须购买的产品。例如，容器不等于安全沙箱，挂载 Docker Socket 就可能突破隔离；网络边界必须由沙箱外设施强制执行，不能只靠 Agent 配置代理。企业应关注这些属性是否真正生效，而不是简单堆叠工具。
渐进落地：先建最小安全闭环
白皮书提出人工编排、工作流编排、Agent 编排三个成熟度层级，企业不必一步到位。文章建议已有 GitLab CI 和模型网关的团队，先建立受控的单 Agent 环境，再把任务编排与授权分离，接着打通审计与验证，最后才引入更高自主运行。这种路径的价值在于，团队可以在现有工程体系上先获得安全边界，再逐步提高自动化程度，而非等待完美平台。
审计与失败关闭：自主运行的可信基础
文章指出，每次运行都应分配唯一 run_id，关联身份、授权决策、网络请求、依赖引入和测试结果，且记录须防篡改。如果安全控制设施不可用，系统应失败关闭，而不是放开限制让任务继续。这提醒读者，可观测性不仅是调试工具，更是追责和止损的基础；没有可信证据链，Agent 的规模化自主就缺乏可靠前提。
Q&A
AI软件工厂和普通的Coding Agent有什么区别？
软件工厂不是更强的Coding Agent，而是一套能持续接收任务、生产代码、验证结果并反馈改进的工程系统。它关注如何把多个工程环节组织成可重复执行、可观察、能控制风险的系统，而不仅依赖模型能力。
为什么不能只靠提示词让Agent遵守安全规则？
因为Agent会自主选择命令、工具和下一步行动，提示词中的限制只是建议而非可靠边界。只要Agent仍能接触超出任务范围的权限（如生产凭据），就可能突破限制。必须由外部基础设施强制执行权限边界。
软件工厂的四道安全边界具体指什么？
四道边界是：沙箱（限制Agent在哪里执行）、网络（限制Agent能访问什么）、供应链（限制Agent使用什么组件）、身份与访问控制（限制Agent代表谁、可以做什么）。它们不是四个独立产品，而是必须在运行环境中成立的安全属性。
软件工厂的成熟度分为哪几个层级？
分为三个层级：Level 1人工编排（开发者决定何时启动Agent和分配任务）、Level 2工作流编排（工厂成为共享服务，预定义工作流调度Agent）、Level 3 Agent编排（Agent可决定创建哪些任务，但授权仍由独立服务完成）。企业可渐进式建设。
在现有Go技术栈中落地软件工厂，应该从哪里开始？
建议先建立最小可行的安全执行链路，而不是开发复杂多Agent框架。可按四阶段推进：建立受控单Agent环境；将任务编排与授权分离；打通审计与验证（为每次运行分配run_id）；再逐步引入更高程度的自主运行。
为什么说容器不等于安全沙箱？
因为容器并不自动提供安全隔离。如果把宿主机Docker Socket挂载进容器，Agent可能通过Docker API创建特权容器、挂载宿主机文件系统，从而突破隔离。多个任务共用可写工作目录也可能导致代码、凭据泄漏。正确做法是每个任务拥有独立、受控、可销毁的执行环境。
软件工厂的可观测性需要记录哪些内容？
需要为每次运行分配唯一run_id，关联请求、授权决策、网络请求、进程活动、依赖引入、测试结果、评审与部署事件。记录应防篡改，且Agent无法自行修改。如果一次运行无法产生必要的安全记录，就不应被视为正常完成。
