MAESTRO-SSOT：通过单一事实来源实现多智能体软件工程中的受控自主性
研究提案 (v1.0)研究方向：AI智能体 / 多智能体系统（应用层） 目标会议：ICSE、FSE、ESEC/FSE、AAMAS、ASE 或其他顶级软件工程/AI会议 预计时间表：首次提交前 6-9 个月
1. 项目概述
1.1 标题
MAESTRO-SSOT：通过单一事实来源和受控执行实现多智能体软件工程中的受控自主性
1.2 一句话总结
我们提出一个多智能体软件工程系统，其中专门的基于LLM的智能体围绕一个共享的、结构化的状态（单一事实来源）进行协作，并在受限的执行框架内运行，从而在无需人工干预的情况下实现持续自主开发循环，同时保持严格的安全性和可观测性保证。
1.3 核心假设
显式的共享状态中介（SSOT）结合运行时防护措施（智能体框架）能够使多智能体软件工程系统比消息传递或基于管道的替代方案获得更高的集成成功率和更低的通信开销，同时足够安全以实现无人监督的自主执行。
2. 背景与动机
2.1 智能体软件工程的兴起
近年来，基于LLM的编码智能体在个别软件工程任务上展示了令人印象深刻的能力。诸如 SWE-agent、Devin 和 OpenHands 等系统在 SWE-bench Verified 上通过将问题解决分解为迭代规划、工具使用和执行循环，实现了超过 70% 的准确率。
然而，这些系统主要保留了单智能体或松散委托的执行模型。即使是最近的多智能体提案（例如 Agyn、基于 AutoGen 的代码团队）也将协作视为孤立智能体之间的消息传递：任务被分派、独立执行，然后事后合并结果。
2.2 "分而治之"的隐藏成本
现实世界的软件开发不仅仅是任务分解——它是一个持续协商共享理解的过程：
- 后端开发者更改API模式；前端开发者必须适应
- 需求工程师澄清约束；架构师和实现者必须协调他们的心智模型
- 测试失败揭示跨越多个模块的集成不匹配
当前的多智能体系统缺乏维持对不断演变的共享工件的共识的显式机制。智能体在私有上下文上操作，导致：
- 集成失败：智能体 A 生成的代码假设接口 X；智能体 B 生成的代码假设接口 Y
- 冗余通信：智能体必须反复查询彼此以同步状态
- 不透明性：人类无法轻松观察每个智能体认为当前规范是什么
- 不安全的自主性：没有防护措施，自主智能体循环可能浪费令牌、损坏文件或执行危险操作
2.3 机会：从消息传递到共享状态
我们观察到，人类软件团队通过共享工件解决这些问题：Git仓库、API规范、项目管理板和设计文档。这些充当了单一事实来源（SSOT），所有参与者从中读取并写入其中。
我们假设赋予多智能体系统类似的显式SSOT层——结合受限的执行框架——将在集成可靠性、通信效率和自主执行安全方面产生实质性改进。
3. 问题定义
3.1 形式化问题陈述
给定一个自然语言软件需求 (R)、一组专门的智能体 (\mathcal{A} = {A_1, A_2, \ldots, A_n}) 和一个代码库 (C)，构造一个系统，使其：
- 维护一个共享的结构化状态 (S)（即SSOT），表示需求、设计契约、执行计划和当前进度
- 允许智能体在并发控制下原子地读取和写入 (S)
- 在受限框架 (H) 内执行智能体操作，该框架强制执行安全策略
- 运行一个自主控制循环，分派智能体、验证结果，并仅在 (R) 被满足或发生不可恢复的失败时终止
3.2 关键研究问题
RQ1（状态中介）：与消息传递多智能体架构相比，显式的SSOT是否能减少集成失败和通信开销？
RQ2（安全性）：智能体框架是否能提供足够的隔离和防护措施，以实现安全的无人监督自主执行，同时不牺牲任务完成率？
RQ3（自主性谱系）：智能体自主性（无需人工批准的连续执行）与安全性（限制性防护措施）之间的最佳权衡是什么？
RQ4（可扩展性）：SSOT架构如何随智能体数量和共享状态复杂性的增加而扩展？
4. 提议的系统：MAESTRO-SSOT
4.1 设计原则
- SSOT作为一等公民：共享状态不是日志或消息总线——它是一个结构化的、可查询的、版本化的工件，智能体主动操作它
- 智能体框架作为策略执行：安全不是事后诸葛亮；它通过显式的允许列表、预算和回滚触发器在操作层强制执行
- 设置即忘的自主性：一旦人类提供需求，系统就会运行直到完成、失败或遇到明确的升级条件
- 设计内置的可观测性：SSOT充当中人类监督者的实时仪表板
4.2 系统架构
┌─────────────────────────────────────────────────────────────────────┐
│ 人类监督者 │
│ (注入需求、监控) │
└──────────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ SSOT 中心（共享状态） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
│ │ 需求树 │ │ 契约注册表 │ │ 执行日志 │ │ 智能体 │ │
│ │ │ │ │ │ │ │ 记忆 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └───────────┘ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ SSOT 访问控制 │ │
│ │ (读/写锁、版本控制、冲突检测) │ │
│ └──────────────────────────────────────────────────────────────┘ │
└──────────────────────────────┬──────────────────────────────────────┘
│ 发布 / 订阅 / 查询
┌──────────────────────┼──────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 规划智能体 │ │ 执行智能体 │ │ 审查智能体 │
│ │◄────►│ │◄────►│ │
│ │ │ (后端、前端、│ │ │
│ 分解需求 │ │ 测试等) │ │ 验证契约 │
└──────────────┘ └──────┬───────┘ └──────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ 智能体框架（防护层） │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 沙箱 │ │ 权限控制 │ │ 预算管理 │ │ 回滚机制 │ │
│ │ (隔离执行) │ │ (文件/API │ │ (令牌和 │ │ (失败时 │ │
│ │ │ │ 的 ACL) │ │ 步骤上限) │ │ 撤销) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 操作验证器（执行前） │ │
│ └──────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ 自动循环控制器 │
│ while not done: │
│ 1. PLAN ──► 通过规划智能体分解需求 │
│ 2. ASSIGN ──► 将子任务分派给执行智能体 │
│ 3. EXEC ──► 通过框架运行操作 │
│ 4. VALID ──► 审查智能体检查契约和测试 │
│ 5. COMMIT ──► 更新SSOT；失败时回滚并重试 │
│ 6. CHECK ──► 验证需求满足；循环或退出 │
└─────────────────────────────────────────────────────────────────────┘4.3 SSOT中心：详细设计
SSOT不是键值存储。它是一个语义结构化的工作空间，具有四个主要域：
4.3.1 需求树
- 顶层需求 (R) 的层次分解
- 每个节点：
(id, description, status, assignee, acceptance_criteria, dependencies) - 状态枚举：
PENDING | IN_PROGRESS | BLOCKED | REVIEW | DONE | FAILED - 智能体认领节点、更新状态并报告完成情况
4.3.2 契约注册表
- 智能体/模块之间的显式接口契约
- 每个契约：
(contract_id, owner_module, consumer_modules, schema, version, status) - 状态枚举：
DRAFT | STABLE | DEPRECATED | BROKEN - 关键不变性：智能体修改导出接口之前，必须更新契约。消费者自动检测版本变更。
4.3.3 执行日志
- 所有智能体操作及其结果的仅追加记录
- 条目：
(timestamp, agent_id, action_type, target, input_hash, output_hash, status, error_if_any) - 实现完全的可重现性和取证分析
4.3.4 智能体工作记忆
- 智能体在步骤之间持续的短期上下文（例如，研究笔记、部分解决方案）
- 与执行日志不同：这是智能体的"草稿本"，而不是系统的审计跟踪
4.3.5 SSOT访问控制和并发
- 读取：任何智能体都可以查询任何域（鼓励透明度）
- 写入：智能体获取它们打算修改的特定子树或契约的锁
- 冲突检测：如果两个智能体在同一规划时期内写入重叠的契约，第二次写入将被拒绝，并通知智能体进行协调
- 版本控制：所有域支持原子快照，能够回滚到任何先前的状态
4.4 智能体框架：详细设计
框架包装每个智能体操作。它不仅仅是Docker沙箱——它是策略感知的操作拦截器。
4.4.1 沙箱层
- 智能体代码执行在隔离容器中运行（Docker或e2b.dev云沙箱）
- 网络出口限制为允许列表中的域（例如，PyPI、npm注册表）
- 文件系统访问限制为项目工作区+临时目录
4.4.2 权限层（ACL）
- 每智能体文件访问规则：
backend_agent可以写入src/api/和tests/api/，但不能写入src/ui/ - 每智能体工具允许列表：
frontend_agent可以调用npm、vite、jest，但不能调用docker或rm -rf - 每智能体API规则：外部服务调用的限制（例如，不允许生产数据库连接）
4.4.3 预算层
- 令牌预算：每个智能体每个任务的最大累计令牌数（防止无限LLM循环）
- 步骤预算：每个智能体每个时期的最大工具调用数（防止失控执行）
- 时间预算：每个子任务的最大墙钟时间（防止挂起进程）
- 当预算耗尽时，智能体被暂停，自动循环要么使用不同策略重试，要么升级给人类
4.4.4 回滚层
- 在任何智能体写入代码库之前，框架创建快照（Git提交或overlayfs检查点）
- 如果后续验证（测试、契约检查）失败，系统自动恢复快照
- 失败的尝试记录在执行日志中以供学习/避免
4.4.5 操作验证器（执行前）
在操作到达沙箱之前，它通过一个快速的基于规则的验证器：
- 此操作是否违反任何ACL规则？
- 此操作是否修改智能体分配范围之外的文件？
- 此操作是否在没有显式确认的情况下删除超过N行？
- 此操作是否匹配已知的危险模式（例如，
eval()、带有用户输入的os.system()）？
如果验证失败，操作将被立即拒绝，并向智能体返回解释性错误。
4.5 自动循环控制器：详细设计
自动循环是编排大脑。它不是LLM本身；它是一个具有LLM驱动决策点的确定性状态机。
python
class AutoLoop:
STATE: Enum = PLAN | ASSIGN | EXEC | VALID | COMMIT | CHECK | DONE | FAIL
def run(self, requirement: str):
ssot.initialize(requirement)
while self.state not in (DONE, FAIL):
match self.state:
case PLAN:
plan = planning_agent.decompose(ssot.requirements)
ssot.requirements_tree.commit(plan)
self.state = ASSIGN
case ASSIGN:
for task in ssot.requirements_tree.pending():
agent = scheduler.select_best_agent(task)
agent.claim(task)
self.state = EXEC
case EXEC:
for agent in ssot.active_agents():
result = harness.run(agent, agent.next_action())
ssot.execution_log.append(result)
self.state = VALID
case VALID:
review_results = [review_agent.check() for review_agent in reviewers]
contracts_valid = contract_validator.check_all()
tests_pass = test_runner.run_all()
if all(review_results) and contracts_valid and tests_pass:
self.state = COMMIT
else:
harness.rollback_all()
self.state = PLAN # 带反馈重试
case COMMIT:
ssot.snapshot() # 标记干净状态
self.state = CHECK
case CHECK:
if requirement_satisfier.verify(ssot, requirement):
self.state = DONE
elif ssot.retry_budget_exhausted():
self.state = FAIL
else:
self.state = PLAN # 完善剩余工作关键设计决策：
- 循环是确定性的，除了智能体内的LLM调用；这使得调试和可重现性变得易于处理
- 回滚是时期级别的，而不是单一操作的：如果任何验证失败，整个时期将被恢复，确保SSOT和代码库保持一致
- 重试预算：系统被允许N次完整循环重试，然后才宣布失败并通知人类
4.6 智能体角色
我们提出一个最小但足够的智能体角色集：
| 角色 | 职责 | SSOT读取访问 | SSOT写入访问 |
|---|---|---|---|
| 规划智能体 | 分解需求、解决歧义、检测矛盾 | 全部 | 需求树 |
| 后端智能体 | 实现服务器端逻辑、API、数据库模式 | 全部 | 契约注册表（API契约）、代码库（src/api/） |
| 前端智能体 | 实现UI组件、客户端逻辑 | 全部 | 代码库（src/ui/）、契约注册表（消费API契约） |
| 测试智能体 | 编写和运行单元/集成测试、报告覆盖率 | 全部 | 代码库（tests/）、执行日志 |
| 审查智能体 | 检查契约合规性、代码质量、安全问题 | 全部 | 执行日志（注释） |
| 契约验证器 | （非LLM规则引擎）验证所有消费者与其声明的契约版本匹配 | 契约注册表 | 契约注册表（状态更新） |
5. 技术实施策略
5.1 构建与复用
我们采用**"薄骨架+核心创新"**策略。我们不重建通用智能体基础设施；我们在经过验证的基础上构建SSOT、框架和自动循环层。
| 组件 | 复用决策 | 理由 |
|---|---|---|
| LLM API抽象 | litellm | OpenAI、Anthropic、本地模型的统一接口；1行提供商切换 |
| 智能体基础抽象 | PydanticAI（或AutoGen v0.4 Core） | 轻量级结构化智能体框架；支持类型化工具调用和结构化输出 |
| 代码沙箱 | e2b.dev（或Docker SDK） | 生产级隔离执行，无需维护我们自己的容器基础设施 |
| Git操作 | GitPython | 用于程序化仓库操作的经过实战检验的库 |
| AST解析/代码分析 | tree-sitter + Jedi | 为契约注册表提取API签名，而无需编写自定义解析器 |
| 测试执行 | pytest / jest CLI包装器 | 无需重新发明轮子 |
5.2 自构建组件（创新层）
这些是我们从头开始实现的组件，构成本论文的核心贡献：
ssot/— 共享状态层（约800–1200行代码）- 域模型：RequirementsTree、ContractRegistry、ExecutionLog、AgentMemory
- 访问控制：LockManager、VersionManager、ConflictDetector
- 持久性：基于Git版本控制的JSON/YAML快照
harness/— 防护层（约600–1000行代码）- 具有ACL执行的沙箱包装器
- 预算跟踪器（令牌、步骤、时间）
- 回滚协调器（Git快照或overlayfs）
- 操作验证器（基于规则的预过滤器）
loop/— 自主控制器（约400–600行代码）- 确定性状态机
- 智能体-任务分配的调度器
- 重试预算管理器
- 人类升级网关
agents/— 角色特定智能体（约600–1000行代码）- 每个角色的提示模板和工具绑定
- SSOT读/写集成
论文的预计总代码库：2500–4000行Python代码。
6. 实验设计
6.1 数据集与基准测试
我们围绕两个互补的评估集设计实验：
6.1.1 Contract-Bench（自构建，约80个任务）
一个专门设计用于测试多模块协作的新基准测试。每个任务至少需要两个智能体来生成能够正确集成的代码。
示例任务：
- "实现一个带有JWT身份验证的REST API和使用它的React前端。包括登录/注销流程和受保护路由处理。"
- "构建一个从SQLite数据库读取并导出CSV的Python CLI工具。数据库模式必须由单独的模块创建，并通过类型化接口共享。"
- "实现一个实时聊天WebSocket服务器和一个简单的HTML客户端。消息必须持久化到Redis并广播给所有连接的客户端。"
每个任务的评估标准：
- 编译/依赖解析成功
- 所有集成测试通过
- 契约一致性验证（没有调用者调用不存在的端点）
- 代码质量（linting、类型检查）
6.1.2 SWE-bench Multi（过滤子集，约50个任务）
我们过滤SWE-bench Pro / SWE-EVO，仅保留以下问题：
- 触及≥3个源文件
- 涉及跨模块变更（例如，API更改+消费者更新）
- 具有明确的测试标准
此子集专门奖励能够跨模块协调变更的系统。
6.2 基线
| 基线 | 描述 | 比较原因 |
|---|---|---|
| 单智能体 | SWE-agent风格：一个智能体处理整个任务 | 确立多智能体是否有益 |
| Agyn | 最先进的多智能体SE（基于角色的流水线、消息传递） | 直接竞争对手；显示SSOT与消息传递的价值 |
| AutoGen GroupChat | 默认多智能体对话 | 显示显式框架和循环设计的价值 |
| MAESTRO-SSOT（完整） | 我们的完整系统 | 主要贡献 |
| 消融实验 | 完整系统减去框架/减去SSOT/减去自动循环 | 隔离每个组件的贡献 |
6.3 评估指标
6.3.1 功能正确性
- Pass@1：任务在首次完成时通过所有测试
- 集成成功率：所有模块编译并且接口对齐的多模块任务百分比
- 契约违规率：智能体A的代码调用与智能体B的实现不匹配的接口的实例数
6.3.2 效率
- 消耗的总令牌：所有智能体的累计LLM令牌
- 通信轮次：智能体间消息交换次数（对于消息传递基线）与SSOT读/写操作
- 墙钟时间：端到端执行时间
- 完成步骤：工具调用/规划迭代次数
6.3.3 安全性与自主性
- 无人监督完成率：无需人工干预完成的任务百分比
- 回滚频率：框架触发自动恢复的频率
- 预算超支率：智能体达到令牌/步骤/时间限制的频率
- 危险操作阻止率：框架验证器拒绝率
6.3.4 可观测性（用户研究，可选）
- 人类使用SSOT与消息日志诊断失败所需的时间
- 对系统状态的主观信心
6.4 预期结果
| 指标 | 单智能体 | Agyn | MAESTRO-SSOT |
|---|---|---|---|
| Pass@1 (Contract-Bench) | 30–40% | 50–60% | 65–75% |
| 集成成功率 | 40–50% | 60–70% | 80–90% |
| 契约违规率 | N/A（单模块） | 15–25% | <5% |
| 总令牌（每任务） | 基线 | 1.5–2×基线 | 1.0–1.2×基线 |
| 无人监督完成 | 80%* | 60%（脆弱） | 85% |
* 单智能体无人监督完成率高是因为任务范围更窄；它经常在集成时静默失败而不是明确请求帮助。
7. 创新与贡献
7.1 主要贡献
多智能体SE的单一事实来源
- 我们是首个提出和评估显式的、结构化的、并发可访问的共享状态作为基于LLM的软件工程智能体的主要协调机制的研究者。这将超越消息传递，转向受人类团队实践启发的"共享工作空间"范式。
智能体框架：基于策略的受控执行
- 我们引入了一个统一的防护层，将沙箱、ACL、预算和自动回滚结合到一个连贯的策略执行框架中。与现有的代码沙箱（仅隔离执行）不同，我们的框架中介智能体被允许对彼此和共享状态做什么。
具有受控失败的自主控制循环
- 我们设计了一个确定性循环，能够实现持续自主执行，同时为系统何时应重试、回滚或升级定义清晰的边界。这为"多少自主性是安全的？"提供了原则性的答案。
7.2 次要贡献
Contract-Bench：多模块智能体协作的基准测试
- 我们发布一个明确需要跨模块协调的软件工程任务数据集，填补了专注于孤立错误修复的现有基准测试的空白。
开源参考实现
- 我们将系统作为现有框架的模块化扩展发布（最初独立，具有清晰的适配器接口），使社区能够在自己的智能体系统中采用SSOT和框架原则。
8. 相关工作与定位
8.1 单智能体编码系统
SWE-agent、Devin、OpenHands 和 CodeAct 代表了单智能体软件工程的最先进技术。它们在顺序推理和工具使用方面表现出色，但不是为并行、多模块开发而设计的。我们的工作是补充性的：这些智能体中的任何一个都可以作为我们框架中的执行智能体。
8.2 多智能体SE系统
Agyn（2026）是最接近的竞争对手。它证明基于角色的多智能体团队在SWE-bench上优于单独智能体。然而，Agyn使用异步消息传递，并且没有显式建模共享接口或提供运行时防护措施。我们的SSOT和框架层正好解决了这些遗漏。
FlowGen（2025）使用多智能体工作流模拟经典的软件工程方法（Scrum、瀑布）。虽然具有流程感知性，但FlowGen使用固定的、预定义的工作流。我们的自动循环是自适应的：它根据验证失败和契约变更重新规划。
AutoGen 和 CrewAI 提供通用的多智能体编排，但不是为软件工程优化的。它们的群聊模型缺乏我们提出的结构化状态和安全保证。
8.3 多智能体系统中的共享状态
在经典的多智能体系统中（LLM之前），共享黑板和元组空间已被广泛研究。然而，这些系统使用符号推理，而不是LLM，并且没有面临基于LLM的代码生成的独特挑战（幻觉接口、不安全的工具使用、令牌预算）。我们的SSOT专为LLM智能体的生成性、概率性和工具使用性质而设计。
8.4 智能体的安全性和防护措施
最近关于智能体安全性的工作主要集中在提示注入检测和输出过滤上。我们的框架通过在操作层强制执行约束来补充这一点：可以接触哪些文件、可以运行哪些命令以及可以花费多少预算。这更接近操作系统安全而不是输入清理。
9. 时间表与里程碑
阶段1：基础（第1-4周）
- [ ] 确定系统架构和SSOT模式
- [ ] 设置开发环境（litellm、e2b、PydanticAI）
- [ ] 实现SSOT中心核心（需求树+契约注册表）
- [ ] 构建最小智能体框架（沙箱+基本ACL）
- 交付物：两个智能体可以读/写SSOT并在沙箱中执行代码
阶段2：核心系统（第5-10周）
- [ ] 实现具有所有六个状态的自动循环控制器
- [ ] 构建所有智能体角色（规划、后端、前端、测试、审查）
- [ ] 集成契约验证器（基于规则的一致性检查器）
- [ ] 实现回滚机制和重试预算逻辑
- [ ] 构建Contract-Bench v1（20个任务）
- 交付物：在简单任务上的端到端自主执行
阶段3：评估与加固（第11-18周）
- [ ] 将Contract-Bench扩展到80个任务
- [ ] 实现所有基线（单智能体、Agyn如果代码可用、AutoGen）
- [ ] 运行完整的基准测试套件并收集指标
- [ ] 实现消融研究（无SSOT、无框架、无自动循环）
- [ ] 调试稳定性问题；加固错误恢复
- 交付物：具有统计显着性的完整实验结果
阶段4：撰写与提交（第19-26周）
- [ ] 撰写论文草稿（引言、相关工作、方法、实验）
- [ ] 准备工件包（代码+基准测试+文档）
- [ ] 内部审查和修订
- [ ] 提交到目标会议（ICSE/FSE/ASE周期）
- 交付物：已提交的论文+开源仓库
阶段5：缓冲与修订（第27-36周）
- [ ] 解决审稿人反馈（如适用）
- [ ] 根据实验见解扩展系统
- [ ] 准备最终版本和工件评估
- 交付物：已发表的论文
10. 风险分析与缓解
| 风险 | 可能性 | 影响 | 缓解措施 |
|---|---|---|---|
| Agyn代码不开源 | 中 | 中 | 转向使用AutoGen v0.4作为基础；Agyn比较变为概念性而非实证性 |
| SSOT并发导致死锁 | 中 | 高 | 从粗粒度锁（每域）开始；稍后优化；带超时的死锁检测 |
| LLM不一致性使契约不可靠 | 高 | 中 | 混合提取：AST解析签名+LLM语义摘要；报告提取准确性 |
| Contract-Bench任务太简单/太难 | 中 | 中 | 通过试点运行迭代任务设计；包括难度分级；报告每个难度的结果 |
| 实验显示比Agyn没有改进 | 低 | 高 | 确保基准测试强调多模块集成；如果结果为空，将论文转向关于SSOT没有帮助原因的诊断分析 |
| e2b/litellm API更改 | 低 | 中 | 固定依赖版本；保留基于Docker的沙箱备用 |
11. 预期成果
11.1 学术方面
- 一篇提交给顶级软件工程或AI会议的完整研究论文
- 一个向社区发布的基准测试数据集（Contract-Bench）
- 关于在基于LLM的SE中共享状态与消息传递协调的有效性的可引用证据
11.2 工程方面
- 具有清晰文档的开源参考实现（约3000–4000行代码）
- 可重现的实验管道（一键基准测试执行）
- 能够在其他智能体框架中采用的模块化设计
11.3 更广泛的影响
- 安全自主软件开发的原则性框架
- 可应用于代码生成之外的设计模式（SSOT、框架、自动循环）（例如，数据工程、科学计算、硬件设计）
12. 附录：初步SSOT模式
yaml
# requirements_tree.yaml
requirements:
- id: R0
description: "实现用户身份验证系统"
status: IN_PROGRESS
children:
- id: R0.1
description: "后端：JWT令牌生成和验证"
status: DONE
assignee: backend_agent
acceptance_criteria:
- "POST /auth/login返回有效JWT"
- "JWT包含user_id和exp声明"
dependencies: []
- id: R0.2
description: "前端：登录表单和受保护路由"
status: IN_PROGRESS
assignee: frontend_agent
acceptance_criteria:
- "登录表单调用POST /auth/login"
- "401重定向到/login"
dependencies: [R0.1]
# contract_registry.yaml
contracts:
- id: C1
name: "AuthAPI"
owner: backend_agent
consumers: [frontend_agent]
version: 2
status: STABLE
schema:
endpoints:
- path: "/auth/login"
method: POST
request: { email: string, password: string }
response: { token: string, expires_in: int }
- path: "/auth/verify"
method: GET
headers: { Authorization: "Bearer <token>" }
response: { user_id: string, valid: bool }
changelog:
- version: 2
change: "添加了/auth/verify端点"
timestamp: "2025-04-23T10:00:00Z"
# execution_log.yaml
log:
- timestamp: "2025-04-23T10:05:00Z"
agent_id: backend_agent
action_type: CODE_WRITE
target: "src/api/auth.py"
status: SUCCESS
ssot_version: "abc123"
- timestamp: "2025-04-23T10:06:00Z"
agent_id: frontend_agent
action_type: CONTRACT_READ
target: "C1"
status: SUCCESS
note: "消费了AuthAPI版本2"13. 附录：智能体框架策略DSL
yaml
# harness_policy.yaml
agents:
backend_agent:
filesystem:
allow:
- "src/api/**"
- "tests/api/**"
- "migrations/**"
deny:
- "src/ui/**"
- "*.env"
commands:
allow: ["python", "pytest", "pip", "git"]
deny: ["rm -rf", "curl", "wget", "docker"]
budget:
max_tokens_per_task: 50000
max_steps_per_epoch: 30
max_wall_time_minutes: 10
rollback: true
human_gate:
- action_pattern: "DELETE > 50 lines"
requires_approval: true
- action_pattern: "MODIFY .env*"
requires_approval: true
frontend_agent:
filesystem:
allow:
- "src/ui/**"
- "tests/ui/**"
- "public/**"
deny:
- "src/api/**"
commands:
allow: ["npm", "npx", "vite", "jest", "git"]
deny: ["curl", "wget", "docker", "sudo"]
budget:
max_tokens_per_task: 40000
max_steps_per_epoch: 25
max_wall_time_minutes: 8
rollback: true文档为MAESTRO-SSOT项目准备。最后更新：2025-04-23。