[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-1813":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":14,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":14,"starSnapshotCount":14,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},1813,"moss-harness","cybernetix-lab\u002Fmoss-harness","cybernetix-lab","A production-grade AI Agent Harness engineering template providing a reliable, observable, and recoverable Agent runtime environment.",null,"Shell",164,4,1,0,3,2.1,"MIT License",false,"main",true,[],"2026-06-12 02:00:33","# 🚀 Moss Harness\n\n[![License: MIT](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT-yellow.svg)](https:\u002F\u002Fopensource.org\u002Flicenses\u002FMIT)\n\n> A self-evolving superintelligence harness substrate, providing a reliable, observable, and recoverable execution environment for agent systems.\n\n**A next-generation agent collaboration framework designed on the principles of System, Control, and Information (SCI) theory.**\n\n[English](.\u002FREADME.md) | [中文](.\u002FREADME.zh-CN.md)\n\n---\n\n## ✨ Core Features\n\n### Scientific Design Philosophy\n\nUnlike platforms driven by mere prompt stacking, this project is built on the rigorous foundation of SCI theory (Systematics, Cybernetics, and Informatics) to establish underlying system order:\n\n- **Systematics** — Seeing the whole: A six-role lane separation architecture that enables higher-order coordination and emergence (1+1>2).\n- **Informatics** — Understanding communication: Transactional fact chains, structured protocol communication, and memory curation.\n- **Cybernetics** — Achieving goals: A Workflow Orchestrator driving two-stage routing and cybernetic feedback loops.\n\n```text\n┌─────────────────────────────────────────────────────────────────────────┐\n│                    Moss Harness Architecture                            │\n├─────────────────────────────────────────────────────────────────────────┤\n│ Systematics │ Coordinator → Planner → Reviewer → Executor → Evaluator   │\n│             │ (with Memory Curator for cross-run curation)              │\n├─────────────────────────────────────────────────────────────────────────┤\n│ Informatics │ Structured Protocols │ Transactional Fact Chain │ Memory  │\n├─────────────────────────────────────────────────────────────────────────┤\n│ Cybernetics │ Workflow Orchestrator │ Two-Stage Routing │ Feedback Loop │\n├─────────────────────────────────────────────────────────────────────────┤\n│ Observability │ Execution Tracing │ Evaluation │ Analytics              │\n└─────────────────────────────────────────────────────────────────────────┘\n```\n\n### Key Capabilities\n\n- 🏛️ **Four-Layer Architecture** - Strict separation of Strategy (Governance), Harness (Orchestration\u002FSubstrate), App (Case Studies), and Observability.\n- 🤖 **Multi-Agent Lanes** - 6 dedicated role lanes for specialized collaboration, eliminating single-agent hallucinations.\n- 🔀 **Two-Stage Routing** - Coarse Intent classification + precise Policy Evaluation.\n- 🔄 **Feedback-Driven Loop** - Review and evaluation results act as control logic to dynamically alter execution paths.\n- 📋 **Transactional Claiming** - \"Facts before broadcast.\" Agents autonomously scan and claim work from the Task Board atomically.\n- 🧠 **Memory & Emergence System** - Cross-session learning that automatically extracts reusable patterns and candidate expert agents.\n- 📊 **Read-Only Observability** - State changes are persisted as a fact chain, providing timeline-based Execution Tracing, Quality Evaluation, and Analytics.\n- 🔌 **MCP Integration** - Standardized interfaces for external tools and systems.\n- 🔒 **Constraint Guardrails** - 4-level constraint system (Hard\u002FSoft\u002FGuidelines\u002FPreferences).\n- 🛠️ **Skill System** - Reusable agent capability modules and code rule checks.\n\n---\n\n## 🎯 Why Choose Moss Harness?\n\n### 1. Scientific Foundation\n\nUnlike traditional agent frameworks that rely on \"experience-driven\" design or flat capability lists, Moss Harness builds underlying order based on mature system theories:\n\n| Dimension | Traditional Frameworks | Moss Harness |\n|------|---------|---------------|\n| **Architecture** | Experience-driven, API wrappers | Architecture-first, SCI theory driven |\n| **Routing** | Static single-path or LLM free-roam | **Two-Stage Routing** (Intent + Policy) |\n| **Quality Control** | Simple pass\u002Ffail, or post-logs | **Cybernetic Feedback**, directly altering workflow |\n| **Task Claiming** | Centralized Dispatch | **Transactional Autonomous Claiming** |\n\n### 2. Preventing Optimism Bias\n\nThe six-role separation architecture ensures execution quality through strict permission and objective isolation:\n\n```text\nCoordinator → Planner → Reviewer → Executor → Evaluator\n                 ↑                         │\n                 └────────── Feedback ─────┘\n      Memory Curator operates across runs to curate knowledge\n```\n\n- **Planner\u002FReviewer\u002FEvaluator**: Read-only permissions, focusing on requirements analysis, plan review, and objective assessment.\n- **Executor**: Read\u002Fwrite and execution permissions, focusing on code implementation and testing.\n- A Planner never evaluates its own plan; an Executor never reviews its own code.\n\n### 3. A Truly Closed-Loop Orchestrator\n\nMoss Harness is not a linear workflow; it is a cybernetic closed-loop system powered by the Workflow Orchestrator:\n\n```text\nRole Lane → Orchestrator → Fact (persist) → Audit → Broadcast\n            ↓ execution   ↓ Execution Tracing \u002F Evaluation \u002F Analytics\n            Feedback ← quality \u002F confidence ← Reviewer \u002F Evaluator\n            Memory & Governance → inform the next run\n```\n\nCorrection must change the path, not just add a log entry. This is the core purpose of the Orchestrator residing in the Harness layer.\n\n---\n\n## 🚀 Quick Start\n\n### Installation\n\n```bash\n# Clone the repository\ngit clone https:\u002F\u002Fgithub.com\u002Fcybernetix-lab\u002Fmoss-harness.git\ncd moss-harness\n\n# Install dependencies and build\nnpm install\nnpm --prefix apps\u002Fmosscli run build\n```\n\n### Basic Usage (App Layer: mosscli)\n\n`mosscli` is the first terminal application case built on top of `moss-harness`:\n\n```bash\n# View help\nnode apps\u002Fmosscli\u002Fdist\u002Fcli\u002Findex.js --help\n\n# Run a harness case application\nnode apps\u002Fmosscli\u002Fdist\u002Fcli\u002Findex.js run --goal \"Implement user authentication\"\n```\n\n### Running Observability\n\n```bash\n# Check task status\nnode apps\u002Fmosscli\u002Fdist\u002Fcli\u002Findex.js status\n\n# Run execution tracing and evaluation analytics\nnode apps\u002Fmosscli\u002Fdist\u002Fcli\u002Findex.js trace\nnode apps\u002Fmosscli\u002Fdist\u002Fcli\u002Findex.js evaluate\n```\n\n---\n\n## 📁 Project Structure\n\nThe project is strictly organized following the four-layer architecture (Strategy -> Harness -> App -> Observability):\n\n```text\nmoss-harness\u002F\n├── apps\u002F                      # [App Layer] Case applications\n│   ├── agent-cli\u002F             # Legacy bash CLI application\n│   └── mosscli\u002F               # TypeScript CLI-first validation app\n├── configs\u002F                   # [Strategy Layer] Configuration center\n│   ├── agents\u002F                # Agent template configurations\n│   ├── constraints\u002F           # System constraints and tool policies\n│   ├── orchestration\u002F         # Orchestration and lane configs\n│   ├── protocols\u002F             # Structured communication protocols\n│   ├── rules\u002F                 # Rules and tool constraints\n│   ├── skills\u002F                # Skill registry\n│   └── telemetry\u002F             # Telemetry configurations\n├── deployments\u002F               # Infrastructure orchestration\n│   ├── docker\u002F                # Docker Compose configurations\n│   ├── helm\u002F                  # Helm Charts configurations\n│   └── k8s-operator\u002F          # Kubernetes Operator and CRDs\n├── docs\u002F                      # Documentation and architecture specs\n├── evals\u002F                     # [Observability Layer] Evaluation framework and metrics\n├── integrations\u002F              # [Harness Layer] MCP and external Skill extensions\n│   ├── extensions\u002F            # Core extensions (e.g., Mailbox system)\n│   ├── mcp\u002F                   # MCP server definitions\n│   └── skills\u002F                # Skill definitions (React, Security, etc.)\n├── observability\u002F             # [Observability Layer] Prometheus and Grafana configs\n├── runtime\u002F                   # [Harness Layer] TypeScript core implementation\n│   ├── agents\u002F                # Role Agent implementations\n│   ├── context\u002F               # Policies and context compaction\n│   ├── memory\u002F                # Memory and curation system\n│   ├── orchestration\u002F         # Workflow Orchestrator and routing\n│   ├── sandbox\u002F               # Execution sandbox management\n│   ├── storage\u002F               # Storage implementations (SQLite, Base)\n│   ├── subagent\u002F              # Sub-agent registry and scheduler\n│   └── telemetry\u002F             # Telemetry collectors and metrics\n├── scripts\u002F                   # [Harness Layer] DevOps and management scripts\n├── src\u002F                       # [Harness Layer] Shell core source code (Legacy)\n│   ├── core\u002F                  # Legacy bash Workflow Orchestrator\n│   ├── agents\u002F                # Legacy bash Role Agent implementations\n│   └── memory\u002F                # Legacy bash Memory system\n└── tests\u002F                     # Test cases (Bats\u002FJest)\n```\n\n---\n\n## 🛠️ Skill System\n\nSkills are reusable capability modules provided at the App and Harness layers, either directly mounted or via MCP:\n\n```bash\n# Activate a skill (Example)\n.\u002Fscripts\u002Fskill-activate.sh code-review\n```\n\n### Built-in Capability Directions\n\n| Skill Category | Associated Role | Description |\n|------|------|------|\n| `architecture-design` | Planner | Architecture patterns and technical solution output |\n| `security-review` | Reviewer | Security checks for code and plans |\n| `test-driven-dev` | Executor | TDD red-green cycle implementation |\n| `knowledge-extraction` | Memory Curator | Extracting candidate expert traits from context |\n\n---\n\n## 🤖 Agent Role Model\n\nThis project adopts a **six-role multi-agent architecture** and curates Experts within each Lane.\n\n| Role Category | Responsibility | Permissions | Expert Agent Example |\n|-------|------|----------|----------------|\n| **Coordinator** | Intent recognition, requirement clarification | Read-only | `api_coordinator` |\n| **Planner** | Requirement analysis, task breakdown, design | Read-only | `db_planner` |\n| **Reviewer** | Risk identification, plan evaluation, suggestions | Read-only | `sec_reviewer` |\n| **Executor** | Code implementation, test writing, self-testing | Read\u002FWrite\u002FExec | `frontend_executor` |\n| **Evaluator** | Quality assessment, requirement validation | Read\u002FTest | `perf_evaluator` |\n| **Memory Curator**| Context compression, knowledge archiving | Read\u002FExec | `doc_curator` |\n\n### Workflow\n\n```text\nUser submits intent\n    ↓\nCoordinator clarifies requirements and outputs Requirement Task\n    ↓\nPlanner claims requirement, outputs Execution Plan\n    ↓\nReviewer performs structured review (APPROVED \u002F NEEDS_REVISION)\n    ↓\nExecutor claims and executes code implementation\n    ↓\nEvaluator assesses implementation quality (PASS \u002F NEEDS_IMPROVEMENT)\n    ↓\n┌──────────┴──────────┐\n│                     │\nPASS\u002FEXCELLENT    NEEDS_IMPROVEMENT\n│                     │\nMemory Curator    (Orchestrator Routing)\ncurates knowledge   Returns to Executor\u002FPlanner to fix\n```\n\n---\n\n## 📊 Evaluation & Emergence\n\n### Agent Evaluation\n\nBased on the objective fact chain produced by the Evaluator, the system supports metrics for agents in each lane:\n\n```bash\n# Evaluate a single agent\n.\u002Fscripts\u002Fagent-eval.sh run planner\n\n# View evaluation report\n.\u002Fscripts\u002Fagent-eval.sh report planner\n```\n\n### Pattern Extraction & Evolution\n\nWhen a pattern successfully recurs multiple times within the same lane, the Memory Curator records it as a **Candidate Expert**. After review, it is automatically promoted to a formal Expert Agent.\n\n```bash\n# Analyze agent performance and curated patterns\n.\u002Fscripts\u002Fagent-evolve.sh analyze planner\n```\n\n---\n\n## 🔬 Feedback-Driven Loop\n\nA cybernetics-based feedback loop that directly intervenes in the Workflow Orchestrator routing:\n\n### Core Mechanisms\n\n- **Task Governance**: Based on risk feedback from the Reviewer\u002FEvaluator, dynamically decides whether to \"proceed\", \"rework\", or \"circuit break\".\n- **Learning Progression**: Automatically breaks down collection, extraction, synthesis, and validation subtasks based on knowledge gaps.\n\n### Two-Stage Routing\n\n1. **Coarse Intent Classification**: `intent-classifier` decides which Policy family to use (Governance vs Learning).\n2. **Precise Policy Evaluation**: `task-governance` or `learning-progression` calculates the exact next stage (e.g., `NEEDS_REVISION` → route back to Planner).\n\n---\n\n## ⚙️ Configuration\n\n### Environment Variables\n\n```bash\nexport MOSS_AGENT=planner            # Activate a specific role agent\nexport MOSS_PERMISSION_LEVEL=strict  # Constraint level\nexport MOSS_TELEMETRY_ENABLED=true       # Enable telemetry and observability\n```\n\n### Model Configuration\n\nModel configurations are located in `configs\u002Fagents\u002F` or `config\u002Fmodels.yaml`:\n\n```yaml\nmodel:\n  provider: anthropic\n  model: claude-3-5-sonnet\n  temperature: 0.2\n  max_tokens: 4096\n```\n\n### Local Models (Ollama, vLLM, LM Studio)\n\nYou can easily route tasks to local, privacy-preserving models using the built-in `local` profile (which uses the OpenAI-compatible API format):\n\n```yaml\n# In configs\u002Fagents\u002Fmodels.yaml\nagent_models:\n  executor:\n    profile: local\n\nprofiles:\n  local:\n    provider: openai-compatible\n    base_url: http:\u002F\u002Flocalhost:11434\u002Fv1  # Example for Ollama\n    model: qwen2.5-coder:7b\n```\n\n### Governance Constraints\n\nSystem rules are not just prompts; they are hard-coded governance strategies:\n- **Level 4 (Hard)**: Unauthorized sandbox execution isolation.\n- **Level 3 (Soft)**: Fact chain protocols that must be structurally persisted.\n\n---\n\n## 📝 Docs Map\n\n- [ARCHITECTURE.md](ARCHITECTURE.md) - Deeper system shape, runtime logic, and four-layer boundaries.\n- [docs\u002Fdesign-philosophy.md](docs\u002Fdesign-philosophy.md) - Why SCI theory matters to the architecture.\n- [docs\u002Fagent-collaboration.md](docs\u002Fagent-collaboration.md) - Agent collaboration workflow instructions.\n- [apps\u002Fmosscli\u002FREADME.md](apps\u002Fmosscli\u002FREADME.md) - `mosscli` as an app-layer case application.\n- [CONTRIBUTING.md](CONTRIBUTING.md) - Engineering conventions for contributing to the substrate.\n\n---\n\n## 🤝 Contributing\n\nWe welcome all forms of contribution! Please follow the Architecture-First principle and check [CONTRIBUTING.md](.\u002FCONTRIBUTING.md) to learn how to participate in building the substrate.\n\n---\n\n## 📄 License\n\nThis project is licensed under the [MIT License](.\u002FLICENSE).\n\n---\n\n## 🙏 Acknowledgments\n\n- Design philosophy inspired by Systematics, Cybernetics, and Informatics (SCI theory).\n- Architecture design inspired by executive control and learning memory mechanisms in neuroscience.\n\n---\n\n## ⭐ Star History\n\n[![Star History Chart](https:\u002F\u002Fapi.star-history.com\u002Fsvg?repos=cybernetix-lab\u002Fmoss-harness&type=Date)](https:\u002F\u002Fstar-history.com\u002F#cybernetix-lab\u002Fmoss-harness&Date)\n","Moss Harness 是一个生产级的AI代理运行环境模板，旨在为代理系统提供可靠、可观察和可恢复的执行环境。项目基于系统、控制与信息（SCI）理论设计，采用了六角色车道分离架构来实现高层次协调，通过事务性事实链、结构化协议通信以及记忆整理确保有效沟通，并利用工作流编排器驱动两阶段路由和控制反馈循环。它适用于需要复杂多代理协作且对系统稳定性、可追踪性和自我进化能力有高要求的应用场景，如智能决策支持系统、自动化流程管理等。",2,"2026-06-11 02:46:12","CREATED_QUERY"]