Agentic SDLC 还不等于软件工厂，工程团队须自建并拥有有边界的 L4 系统 来自 @QodoAI 创始人 @itamar_mar 的分享，他认为：… · @shao__meng · TwKit

@shao__meng

Agentic SDLC 还不等于软件工厂，工程团队须自建并拥有有边界的 L4 系统 来自 @QodoAI 创始人 @itamar_mar 的分享，他认为：各阶段都有 Agent ≠ 已有软件工厂；工厂的目标是有边界的 L4：在界定工作类上能自主走完授权生命周期、产出可检验证据，并在失败时安全兜底；而不依赖工程师每次救场。团队优势在于 自建并拥有 这套系统（边界、证据、权限、反馈），而非堆模型或买黑盒。 核心区分 Agentic SDLC vs. Software Factory Agent 参与规划/实现/评审/测试等阶段 vs. 围绕交付的生产系统：输入、上下文、执行环境、验证、权限、发布、反馈 代码几乎全由 Agent 写，但仍靠人串阶段、补判断 vs. 问：系统能否在授权范围内把一类变更走完，而不反复要人补「缺的判断」 优先级口号：System > Agents > LLMs。更强模型能改善系统，但不能替组织决定可接受风险。 为何「工厂」才是改进单元 实现变便宜后，瓶颈常在：该不该改、架构约束、下游影响、对用户是否成立。工厂把「从想法到可发布、可观测、高质量软件」整条链工程化，改进一次可惠及成千上万次变更。OpenAI 的 harness engineering 等报告，也显示投入正转向环境、仓库知识、约束与反馈环。 借鉴自动驾驶：L3 vs L4（作者自拟框架） L0–L1：人执行 / AI 辅助单点活动 L2：Agent 干大块活，人主动监督、串联 L3（agentic-SDLC）：在限定条件下可跑交付流，但人仍是必需的批准或救援依赖 L4（lights-on factory）：对有界变更类，可完成授权生命周期（验证、允许的发布动作、安全回退），不依赖及时人工介入来遏制失败；工程师仍拥有边界与演进（「lights on」） L5（dark factory）：覆盖几乎全部软件工程，仍需目标、授权与问责 关键：L4 ≠ 无所不能；运行边界本身就是能力的一部分。可对「成熟内部服务的例行变更」冲 L4，对支付授权等仍紧控，不要把整家公司统称「L4」。 从 Agentic SDLC 迈向 L4：多做的那一步是「工程化边界」 1. 工作本身：仓库、变更类型、依赖、环境、权限与花费上限；何为不合格。例行依赖升级 ≠ 核心授权模型变更。 2. 可评估的成功：工单不是完整规格；架构决策、事故史、客户承诺、工程师记忆须可被工厂取用，并在实现前暴露歧义。 3. 经得起生成激励的验证：StrongDM 等案例强调场景/harness/外部依赖行为副本；验收标准要有独立权威，防 Agent「改考试通过条件」。第二个 Agent 叫「reviewer」≠ 独立。Anthropic generator/evaluator、Dex「Harness Engineering is not Enough」：绿测≠长期可维护。 4. 证据 > 自信：可检查的放行理由（需求、检查、约束、部署结果、未决不确定）。用合格工作完成率、剩余人工、逃逸、失败成本记账；而非 Agent 数量、生成行数、无人值守小时。 5. 安全回退：拒发、停 rollout、关特性、回滚；破坏性迁移可能无法回滚，边界须事先计入。可在安全态后再找人；L4 的硬标准是遏制失败不依赖人立刻接管。 Ownership > Implementation 拥有 = 控制工厂产出什么、何时可接受：组织上下文、架构、验收、权限、证据、运行边界；能诊断失败并改「产生失败的系统」。买平台/专用 Agent 可以，但像买云一样：架构、串联、应用逻辑与运营仍归工程组织。呼应 Kief Morris「on the loop」：重复人工判断应收成规则、测试或持久上下文；否则工厂还没吸收团队知识。 落地建议 先选一类需求与风险够清楚的工作 → 定资格规则、验证、权限、回退 → 人监督运行并度量干预点 → 有的进工具/上下文，有的永远不进自治。用有边界的 L4作务实目标，而非空想 L5。

曝光 507 · 评论 2 · 点赞 2 · 书签 5