MOSS:自源代码级重写实现自进化自主智能体系统
MOSS(Model-Oriented Self-Source)是一个新颖的框架,它赋予了自主智能体系统在生产级源码层面进行自重写的能力。MOSS 框架解决了一类关键局限性:现有智能体通常只能迭代文本可变的部分(如提示词、技能文件、内存等),但无法触及和修正驱动整个系统的核心逻辑层——即Agent Harness(代理骨架)。
原始内容来自 https://arxiv.org/html/2605.22794v1
📖 1. 核心问题与理论突破
1.1 现有智能体的局限性(The Text Barrier)
目前应用层自主智能体的核心风险点在于其架构(Harness)的稳定性。当故障源于以下底层逻辑时,仅通过文本修改(如优化 Prompt 或增加 Skills)无法解决:
- 消息路由异常。
- 钩子(Hooks)触发顺序错误。
- 会话状态(Session State)的原子性问题。
核心观点: 代码级别的逻辑错误无法通过简单的文本补丁来修复。
1.2 MOSS 的解决方案:源码级适应性 (Source-Level Adaptation)
MOSS 的优势在于其演化空间是编译型、确定性、且处于最通用的层面。
- 计算完备性 (Turing Completeness): 源代码设计空间构成了最普遍的搜索空间,使其严格包含于所有文本可变范围。
- 确定性 (Determinism): 行为运行在受控的代码逻辑(例如状态机不变式)之上,而不是依赖于大型语言模型是否能完美理解并遵守新的文本规则。
- 稳定性 (Stability): 演化补丁作为结构化代码,不会在长上下文漂移(Long-context Drift)中被消解,保证了系统的鲁棒性。
⚙️ 2. 系统架构与组件分离
MOSS 在一个复杂、多进程(Multi-Process)的宿主机(Host-Side)拓扑上运行,以确保在进行代码演化时,不会中断实时的用户体验。
| 组件 (Component) | 核心职能 (Function) | 技术要点 (Key Features) |
|---|---|---|
| Substrate (目标子系统) | 宿主用户交互层,提供用户感知的 Agent 界面和能力。 | 状态(会话、内存、凭证)通过挂载点(Mount)从宿主获取,确保状态持久性。 |
| Control Surface (控制界面) | 提供统一的演化管理入口,屏蔽复杂的内部流程。 | 通过一个 moss evo CLI 命令注入到 Substrate 的系统 Prompt 中。对外暴露演化生命周期(触发、状态查询、应用)。 |
| External Coding Agent (编辑器) | 负责执行具体的代码修改和重写任务。 | 作为宿主机进程调用,而非嵌入主容器内,可调用宿主机提供的完整 Shell 环境和网络出口。支持多方模型插件化。 |
| Host-Daemon Supervisor (中央守护) | 负责管理整个系统的生命周期和演化流程。 | 核心组件。管理 docker build、试用工作节点(Trial-Worker) 的生命周期,并运行自动扫描引擎来查找失败证据。 |
| Ephemeral Trial Workers (验证器) | 用于验证代码修改是否成功,并暴露潜在的“间歇性故障”。 | 每次构建后,守护进程都会在独立的、短暂的容器(Candidate Image)中执行任务批次,重复任务直到暴露最脆弱的缺陷。 |
🔄 3. 确定性演化流程 (The Evolution Workflow)
MOSS 遵循一个严格、确定且有界限的闭环迭代过程,核心驱动力是真实的生产环境失败证据。
3.1 步骤 一:输入证据的采集 (Evidence Ingestion)
演化的目标不是一个理论上的基准测试,而是修复一组具体的、出问题的生产批次证据。
- 周期性扫描 (
moss evo catch-up): 扫描历史会话 JSONL 文件,自动识别出对话流程中表现不佳或失败的对话片段。 - 用户触发 (
moss evo flag): 当用户在对话中明确表达了对当前系统的某些行为不满意时触发,将该时刻的上下文加入待修复批次。
批量管理: 无论是哪种来源,最终都汇入一个待处理批次 (Open Batch),当该批次积攒到默认阈值(例如 8 个缺陷块)时,即将其封闭(Sealed)。
3.2 步骤 二:迭代与验证循环 (The Iteration Loop)
- 代码生成/修改: External Coding Agent 基于当前批次证据,生成修改后的代码片段。
- 构建镜像: Host-Daemon Supervisor 使用新的代码片段对 Substrate 进行修改和
docker build,生成一个新的候选镜像(Candidate Image)。 - 任务激活: 守护进程启动独立的 Trial Worker 容器,使用该候选镜像运行原始失败任务批次。
- 收敛/回滚: Trial Worker 发现问题后,守护进程根据测试结果判断是否发生“收敛”(Converged)或“失败”(Failed)。如果失败,则进入下一轮迭代,直到达到预设的成功标准或无法再进行修复。
🛠️ 4. 实施资源与实践指导
🔗 关键依赖资源 (Resources)
- CLI 工具:
moss evo CLI(通过 System Prompt 或 Bind-mount 注入,是用户交互的唯一入口)。 - 模型/插件: 框架支持多种外部代码代理,包括 Claude Code (Anthropic)、OpenAI Codex、DeepSeek-TUI 和 OpenCode 等。这增强了系统的灵活性。
🚀 脚本与代码参考 (Scripts/Code Reference)
1. 自动扫描脚本 (Conceptual catchup.py):
# 流程: 扫描 session_history.jsonl
def scan_for_failure(jsonl_path: str):
"""Reads session logs and flags non-deterministic state transitions."""
# 实施: 调用底层 state-machine 状态验证器
candidates = load_and_filter_sessions(jsonl_path)
# 返回需要修复的失败证据批次
return process_and_aggregate_failures(candidates)
2. 构建与部署流程 (Conceptual Handshake):
# 步骤 1: 检出 (Checkout)
docker build -t candidate:sha-$(date +%s) .
# 步骤 2: 预热测试 (Health Probe)
docker run --rm candidate:$(sha-dummy) ./run_health_check.sh
# 步骤 3: 部署 (Swap & Commit)
if [ $? -eq 0 ]; then
echo "Health Check OK. Committing new state."
docker commit $(get_container_id) new-stable:commit
else
echo "Health Check failed. Rolling back attempt."
fi
(注意:此处的 ./run_health_check.sh 脚本依赖于宿主机环境的 Shell 和 Docker CLI)
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)