🤖 AI

Specifying AI-SDLC Processes: A Protocol Language for Human-Agent Boundaries

本文提出了一种用于规范人工智能软件开发生命周期（AI-SDLC）流程的形式化领域特定语言，该语言通过结构化强制执行原语来定义人机边界，通过区分策略与机制来限制系统故障率，并实现多智能体软件开发中职责分离的形式化。

原作者： Ylli Prifti

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Ylli Prifti

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你正在建造一座摩天大楼。在过去，你雇佣了一支由人类建筑师、工程师和建筑工人组成的团队。每个人都各司其职，并且有着严格的规则：浇筑混凝土的人不能同时也是签署安全检查报告的人。

现在，想象一下你用一半极其聪明、快速但有时难以预测的 AI 机器人取代了你的团队。它们可以编写代码、设计蓝图并在几秒钟内修复漏洞。但问题在于：你如何确保这些机器人不会意外地让大楼爆炸、跳过安全检查，或者对自己的错误视而不见？

目前，团队只是通过聊天信息（提示词/prompts）来“告诉”机器人该做什么。但机器人就像是学生，如果你不把指令写得完美无缺，它们就会忘记指令，或者可能会感到困惑而偏离任务。如果机器人犯了错，它甚至可能意识不到，整个项目可能会因此崩塌。

这篇论文提出了一种新的规则手册（一种“协议语言”）来管理人机协作团队。与其仅仅与机器人聊天，不如编写一份严格的、机器可读的合同，使其充当大楼的结构钢材。

以下是该论文如何使用简单的类比来拆解其内容的：

1. 问题所在：“漂移”的指令

目前，如果你想让机器人检查自己的工作后再继续下一步，你必须在提示词中告诉它。但机器人是“非确定性”的——它们今天可能会遵守规则，明天却可能忽略规则，或者对“检查一下”的理解与你的本意不符。

论文的观点： 依赖机器人去“表现良好”，就像是在没有洗手池的情况下要求一个孩子记得洗手一样。这是有风险的。
解决方案： 与其要求机器人去“记住”，不如在门上安装一把锁。除非插入“钥匙”（验证令牌），否则机器人物理上无法进入下一步。如果机器人试图跳过检查，门就会保持锁定状态。

2. 新语言：“策略 vs. 机制”

作者区分了两个概念：

策略（意图）： “我们希望代码是安全的。”（这仅仅是一个愿望）。
机制（执行）： “系统将物理性地阻止代码被保存，除非有三个不同的验证者签字确认。”（这是一个硬性规则）。

这就像一家银行。

策略： “我们希望防止欺诈。”
机制： “未经经理指纹验证，你无法提取超过 500 美元的现金。”
论文认为，对于 AI，我们需要的是机制（指纹扫描仪），而不仅仅是策略（墙上的告示牌）。

3. “2+N” 团队模式

论文建议了一种效果最好的特定团队结构，称为 2+N 模式。

“2”个核心人类： 你需要两名负责人，但他们的职责不同。
- 人类 A（生产者）： 监督负责编写代码的机器人。
- 人类 B（审查者）： 监督负责检查代码的机器人。
- 为什么要两个人？ 一个人不应该被允许既编写检查项又签署检查项。他们必须分离，以防止错误或作弊。
“N”个机器人： 这些是专门的工人（编码员、安全检查员、测试员）。它们承担繁重的工作，但受到人类和规则的严格控制。

4. “自我检查”循环（克莱尼闭包/Kleene Closure）

想象一条工厂装配线。通常，如果零件损坏，生产线会停止。但在这种 AI 系统中，如果机器人发现了一个问题，它不仅会停止，还会自动生成一个新的、规模更小的机器人团队来专门解决该问题，并遵循完全相同的规则。

论文的观点： 这是自动发生的。系统设计为使“修复问题”本身就是另一个遵循相同严格检查规则的“任务”。这就像一个俄罗斯套娃，每一层都遵循同样的安全性规则。

5. “自我监管”的守护者

该设计最聪明的部分是，系统可以包含一个专门负责监视其他机器人的机器人。

这个“守护者机器人”并不编写代码；它只观察其他机器人是否遵守规则手册。
它会检查：“编码员在编辑前请求许可了吗？”“审查者签字了吗？”
如果守护者看到规则被违反，它会停止整个流程。这就像一名裁判，盯着球员以确保他们没有作弊。

6. 为什么这很重要（“商品化”论点）

论文指出，AI 模型（即“大脑”）正变得非常相似且廉价。很快，使用模型 A 还是模型 B 并不重要；它们都会擅长基础工作。

真正的价值： 价值不在于你使用哪个机器人，而在于你如何组织它们。
一个拥有优秀“规则手册”（协议）的团队将会生存并壮大，无论他们雇佣哪种机器人。规则手册将成为他们最宝贵的资产，就像一份秘密配方，而机器人仅仅是原材料。

总结

论文的核心观点是：不要信任 AI 去“记住”规则。 相反，要构建一个让规则被硬编码进机械构造中的系统。如果机器人试图违反规则，机器会物理性地阻止它。通过将“编写者”与“检查者”分离，并使用严格、不可破坏的过程，我们可以安全地利用 AI 来构建复杂的软件，而不至于让其崩溃。

该论文并未声称：

它并未声称这能让 AI 变得完美或毫无差错。机器人仍然可能犯错，但“跳过步骤”的行为被消除了。
它并未声称这适用于所有类型的职业；这目前是对软件开发领域的提议。
它并未声称已在数千家公司进行了测试；他们仅在自己的系统上进行了测试以证明其有效性。

技术摘要：规范 AI-SDLC 流程

1. 问题陈述

AI-SDLC（AI 集成软件开发生命周期）的出现，已将 AI Agent（智能体）确立为规划、编码、评审和部署阶段的一等公民团队成员。然而，目前存在一个关键的规范缺口：尽管行业报告和从业者文献都指出需要明确的人机责任映射、审批门禁和治理约束，但尚不存在能够将这些需求编码为可执行协议的形式化规范语言。

现有方法存在三个主要局限性：

行为漂移（Behavioral Drift）： 流程逻辑通常编码在 Agent 的提示词（Prompt）中，这容易受到解释漂移的影响，且缺乏结构化强制手段。
领域失配（Domain Mismatch）： 现有的工作流语言（如 BPMN 扩展）针对的是相邻领域或人机交互，未能原生建模自主 Agent 参与者、分歧解决机制或 Agent 特有的失效模式。
临时性实现（Ad-Hoc Implementation）： 团队目前依赖碎片化的工具和隐性规范，导致了运营风险、审计缺失和技术债。

核心挑战在于定义一种语言，用以规定谁（人类或 Agent）在何时做什么，何时需要审批，如何解决分歧，以及哪些约束是不可逾越的，且不依赖于对 Agent 合规性的假设。

2. 方法论

作者提出了一种用于将 AI-SDLC 流程规范化为形式化协议的领域特定语言（DSL）。该方法区分了策略（声明意图）与机制（结构化强制）。

2.1 形式化语言规范

该语言将一个协议 $P$ 定义为一个元组 $\langle M^*, V^*, D, C^* \rangle$ ：

模式（Modes, $M$ ）： 操作阶段（如 producer、reviewer），具有定义的权限。模式在基础设施层面进行强制执行。
角色（Roles, $R$ ）： 模式内的参与者，由身份和可访问工具定义。
验证器（Validators, $V$ ）： 独立的评估者，根据标准评估任务并发出严重程度等级。
分歧策略（Disagreement Policy, $D$ ）： 用于解决验证器结果的规则（例如：unanimous_pass、split $\to$ require_human、any_block_er $\to$ hard_stop）。
约束（Constraints, $C$ ）： 结构性禁止项和要求（例如：negative(producer_mode calls merge)）。

2.2 结构化强制 vs. 行为合规

论文认为仅靠策略是不够的。该 DSL 引入了强制不变性（INV1–INV4）来限制过程的非确定性：

令牌完整性（Token Integrity）： 验证令牌是由验证器发出的不可伪造的凭证；Agent 无法自行铸造。
能力边界（Capability Boundaries）： 工具仅在基础设施层面暴露给特定的模式（例如：producer 模式无法访问 merge 工具）。
不可覆盖的阻断（Non-Overridable Blockers）： 如果验证器发出了 blocker 严重程度，系统将结构化地停止执行；任何 Agent 都无法覆盖此操作。
审计完整性（Audit Completeness）： 所有状态转换和调度都会被不可篡改地记录。

2.3 2+N 团队模式

论文形式化了一个被称为 2+N 模式 的参考配置：

2 个人类控制（HI-CTRL）角色： 一个处于 producer 模式（拥有执行权），一个处于 reviewer 模式（拥有合并权）。这强制执行了职责分离，防止自我审批。
N 个专业化 Agent： 包括编排器、编码器和具有正交标准的验证器集群。
基础设施边界： 这两种模式通过不相交的工具集和独立的 MCP（模型上下文协议）服务器进行隔离。

2.4 涌现属性

Kleene 闭包（Kleene Closure）： 编排循环不是固定的序列，而是一个 Kleene 闭包（ $L^*$ ）。任务可以递归地生成子任务，每个子任务都需要遵循自身的治理和验证周期，且全部处于相同的协议约束之下。
自我强化遵循（Self-Reinforcing Adherence）： 该语言允许使用协议遵循验证器——即评估系统本身是否遵循协议规则的 Agent。这创造了一个自引用结构，使协议能够进行自我审计，而无需额外的元语言。

3. 核心贡献

形式化规范语言： 一种具有抽象语法、良构性条件（WF1–WF5）、操作语义和 AI-SDLC 强制不变性的 DSL。
策略-机制区分： 一个框架，其中协议声明意图，而实现通过结构化原语（令牌、能力边界）来限制非确定性。
2+N 团队模式： 一个形式化的 AI-SDLC 参考配置，将人机协作中的职责分离进行了编码。
失效率分析： 通过数学推导证明，结构化强制将系统失效率限制在 Agent 和验证器失效率的加权乘积内，而行为合规则会导致累积或接近饱和的失效增长。
拟确定性（Quasi-Determinism）： 提出虽然 Agent 的输出仍具有非确定性，但过程变得拟确定，因为 Agent 无法跳过或偏离协议步骤。
实现： 一个展示了该语言的可执行性和强制不变性可维护性的工作系统，包括系统自身代码库的自我开发。

4. 结果与分析

4.1 失效率界限

论文展示了失效率的对比分析：

行为合规： 失效会在工作流中复合。如果 Agent 在损坏的中间状态上运行，其失效率会增加。在级联失效的最坏情况下，系统失效率趋于饱和（接近 100%）。
结构化强制： 失效是受限的。系统失效率是单个 Agent 失效率（ $p_i$ $p_{i}$ ）和验证器漏检率（ $p_{quorum}$ $p_{q u or u m}$ ）的加权乘积，并受恢复成本调节。
- 分析表明，对于现实参数（例如 $N=5$ ，验证器法定人数 $K=3$ ），结构化强制可以将失效率比行为基准降低一个数量级。
- 至关重要的是，这种降低依赖于“过程步骤不可跳过”（INV3）且存在“恢复循环”的假设。

4.2 实现可行性

作者使用以下组件实现了该规范：

一个用于解析和良构性检查的协议引擎。
两个用于强制模式隔离的 MCP 服务器。
一个用于验证的令牌子系统。
一个事件溯源审计日志。
该系统成功地在 2+N 协议下扩展了其自身的代码库，为可行性提供了初步证据。

5. 重要性与定位

论文认为其贡献不在于发明了新的原语（DSL、能力令牌和基于角色的工作流已经存在），而在于将它们具体集成到一个连贯的 AI-SDLC 规范语言中。

与前人研究的区别：
- 不同于 MetaGPT（将 SOP 编码在提示词中，易受漂移影响），该语言提供了一种独立于 Agent 实现的机器可执行规范。
- 不同于 BPMN 扩展（虽然模拟了人机工作流，但缺乏基础设施层面的强制），该 DSL 将模式边界视为一等公民概念。
- 不同于 SAGA（侧重于 Agent 间的授权），该语言侧重于“验证到执行”的授权。
商品化论点：
作者认为，随着基础模型的性能趋同，组织的差异化资产将从“模型选择”转向“流程设计”。一个设计良好的协议充当了“制度记忆”，能够随模型更迭而生存，而模型则被视为商品化的基础设施。

6. 局限性与未来工作

论文对自身的研究范围保持了克制，承认了以下局限性：

单一实现证据： 可行性论证基于单一实现（ $N=1$ ）。与基准测试的对比性评估是未来的工作。
数学假设： 失效率界限假设失效率是恒定的且相关结构是稳定的，这在实践中可能并不成立。
实现依赖： 令牌完整性（INV1）是实现层面的责任；规范本身并未规定具体的加密原语。
验证器质量： 结构化强制无法超越验证器本身的质量。
缺乏形式化验证： 论文定义了良构性条件，但并未正式验证协议是否达到了其预设的时间目标。

作者总结道，在模型趋于商品化的时代，该规范语言为“流程设计”这一持久的工程资产提供了其所需的“形式”。