用 Claude Code、Codex、Cursor 的人大多撞过同一组问题：换一个会话，Agent 就忘了上一轮的约定；每开一个新项目，CLAUDE.md 或 .cursorrules 要重写一遍；团队里几个人的 Agent 行为各走各的；放手让它自己跑命令，心里发毛。
affaan-m/everything-claude-code 就是冲这组问题来的。README 自述原文是 "The agent harness performance optimization system"，点名五个词：skills（技能）、instincts（直觉）、memory（记忆）、security（安全）、research-first development（研究优先的开发流程），目标宿主是 Claude Code、Codex、Opencode、Cursor。官网 ecc.tools，MIT 许可，仓库元数据语言标为 JavaScript。
它押的方向值得单独说一句：不训模型、不改模型，把推理外壳（harness）本身当成可调优、可跨宿主迁移的工程对象。它卖的不是模型能力，是一层让既有 Agent 更可控的配置层。
先说清可信度：以上全部来自仓库自述与元数据，属于单一来源，未经独立核实。下面这些也是素材到哪就说到哪。
核心概念
只有五个关键词加 "agent harness" 这一层称呼。README 可见部分止于徽章区，正文被截断，这些名词的语义、边界、实现形式没有依据，不做展开推测。
架构
没有可靠来源。本轮采集里 DeepWiki 返回 Vercel Security Checkpoint 验证页，CodeWiki 对应页面返回 404，两个第三方文档索引都取不到内容。模块划分、数据流一概不写。
怎么装
只确认了分发面：npm 上存在 ecc-universal 与 ecc-agentshield 两个包（README 徽章是 weekly downloads 口径，可见素材未给出具体数值）；GitHub Marketplace 上有应用 ecc-tools，徽章标注 150 installs。合理推断路径是「npm 安装/初始化 + GitHub App 授权」，但具体命令、支持的宿主、配置落盘位置都没有素材，请以仓库最新 README 为准。
怎么用
没有 CLI 示例，也没有 API 说明。唯一能确定的是它的形态------配置型工具，装好后改变宿主 Agent 的行为，不是被业务代码 import 的库。
生态与依赖
上游绑定四类宿主；topics 里含 mcp，可能接入 Model Context Protocol 工具链，但不足以确认它本身是不是 MCP server 形态。整体看，它是寄生在别人 harness 上的配置层，与各家规则文件格式、插件机制强耦合------宿主一次改版，就可能大面积失效。
成熟度与风险
事实：仓库创建于 2026-01-18，最近一次推送是 2026-10-15，存续不到一年；Stars 281,051，Forks 41,796，Watchers 281,051（与 Stars 数值完全相同），Open issues 229，Contributors 412，MIT 许可。
这个量级和不到一年的库龄严重不匹配，通常只见于十年老项目。所以「被大量 star」和「被大量真实采用」在这里必须分开看------榜单效应、命名即卖点、收藏成本极低，都会放大这个数字。
风险还有一层更实的：ecc-agentshield 按名字看是给 Agent 加权限护栏的安全组件，但它的权限模型、审计记录、CVE 情况在素材里完全缺失。把 Agent 的信任边界外包给一个不足一岁的项目，这件事本身值得犹豫。
竞争压力也很直接：Anthropic、OpenAI、Cursor 和各家 IDE 自带的 rules 目录、插件、slash command，大多免费且由平台方维护。这层中间件是被收编还是被吞掉，取决于平台方的动作。
接下来盯四个数
npm 上两个包的周下载量撑不撑得起 28 万 star 的量级；ecc-tools 的安装数会不会从 150 往上走；Anthropic/OpenAI/Cursor 是否推出原生的 skills / memory / 权限护栏等价能力；以及 star 与库龄的异常有没有被公开解释。
在一个 star 越来越像传播指标、而不是采用指标的环境里，判断一个 Agent 工具值不值得信，先去翻它的 npm 下载量和应用市场安装数。
