开源项目

在 GitHub 上拥有超过 50,000 颗星的 everything-claude-code（以下简称 ECC），其 README 的第一句话就明确写着：“Not just configs”（不仅是配置）。对于大多数初次接触它的开发者来说，这可能是一个令人费解的定义。 通常，开发者使用 Claude Code 或 Codex 的方式非常直观：安装、提问、观察 AI 生成代码、手动修复错误。在这种模式下，AI 只是一个高级的自动补全或交互式脚本工具。ECC 的出现改变了这个逻辑——它不是在 Claude Code 之上堆叠更多的 Prompt 模板，而是试图解决一个更底层的问题：如何让 AI agent 像一个成熟的软件工程师一样，具备可预测、可复用且能持续进化的工程交付能力。 ECC 的本质是一套为 AI agent 量身定制的 harness 操作系统。它将"AI 如何可靠完成工程任务"这一复杂课题，拆解为技能、本能、记忆、验证四个维度，并提供了一套系统化的技术实现框架。 它不是配置包 当你打开 ECC 的代码库，你会发现它并没有提供成千上万行的配置文件。相反，它提供了一套完整的逻辑层，介入了 AI agent 与文件系统、终端命令以及开发者意图之间的每一次交互。 大多数开发者在使用 AI coding 工具时，面临的最大痛点是"随机性"。同一个任务，在不同的 session 中可能会得到完全不同的实现路径。ECC 认为，这种随机性源于 agent 缺乏统一的工程规范和执行框架。ECC 提供的不是"更好的答案"，而是"更好的工作流"——它将 AI 从一个随机应变的聊天机器人，转变为一个遵循特定协议的工程执行单元。这种从"对话驱动"到"协议驱动"的转变，是 ECC 区别于普通配置包的根本原因。 四层体系 ECC 当前包含 28 个专用子代理、116 个技能和 59 个命令，背后是四个相互支撑的层级设计。每一层都解决了 AI agent 在工程化落地中的特定缺陷。 技能（Skills）：这是 ECC 的执行库，116 个标准化工作流定义，覆盖从 TDD、架构分析、自动化安全扫描到内容写作的各个领域。这些技能是原子化的——当 agent 需要执行特定的工程操作时，按需调用相应的技能模块。例如，在进行代码重构前，agent 会先调用"架构分析技能"来识别潜在的副作用，而不是直接开始修改代码。 ...

在使用 Claude Code 进行超过 3 天的持续开发后，你可能会发现它的表现开始下滑：原本能完美遵循的架构规范被无视，它开始频繁回复"I’ll be more concise now"，甚至遗忘半小时前刚刚达成的技术决策。这不是 Claude 的逻辑能力下降了，而是 context window 中充斥了大量过往推理、错误尝试和冗长的文件读写记录，导致注意力的精确度发生了系统性偏移。 这种现象被称为 Context Rot（上下文腐烂）。对于任何试图用 AI 助手构建真实产品而非简单 Demo 的开发者来说，Context Rot 是限制生产力的核心瓶颈。 get-shit-done（以下简称 GSD） 的出现并非为了让 AI 写出更精妙的代码片段，而是为 Claude Code 引入了一个专门的项目管理层。它的核心逻辑只有一句话：通过外部化的状态文件和受限的编排架构，从底层消灭 context 积累，从而彻底解决 Context Rot 问题。 Context Rot 是什么，为什么它是真正的问题 当你在一个 Session 中连续输入超过 50 轮对话，Claude 的 context usage 往往会跳升至 100k token 以上。此时最直观的证据是响应变慢，以及它开始丢失对全局约束的感知。Transformer 架构的注意力机制在处理超长序列时存在权重弥散——模型会更倾向于关注最近几轮对话的细节，忽略初始阶段定义的架构原则。 根本原因是信息密度超载。在原始的 Claude Code Session 中，搜索结果、代码修改记录、测试报错和无关闲聊被线性地堆叠在一起。这些"噪音"占据了宝贵的注意力空间。即使 Claude 有 200k 的窗口，真正有效的注意力和被噪音稀释后的执行质量之间存在着巨大的鸿沟。 GSD 的判断：不要试图管理长 context，而要从架构上消灭它的积累。 它强制要求通过文件来同步状态，而不是通过对话历史。 状态文件体系：将记忆外挂 GSD 要求项目根目录下存在一套标准的机器可读文件，包括 PROJECT.md、STATE.md、REQUIREMENTS.md、ROADMAP.md 和 PLAN.md。这些文件不是写给人类看的文档，而是 Claude 的"外挂硬盘"。 ...

Andrej Karpathy 最近发布的 autoresearch 仓库在机器学习社区引发了关注。表面上看，这是一个自动搜索 Transformer 最优超参和架构的工具，但从系统设计视角来看，它更像是一个关于"如何设计真正自主的 Agent 系统"的完整示范。 大多数 AI Agent 开发者仍受困于"如何让 LLM 稳定执行复杂任务"的泥潭，而 autoresearch 通过极其克制的代码结构，回答了 Agent 自主性的三个核心问题：目标如何定义、边界如何划定、反馈如何保证客观。 这个系统仅由三个核心文件支撑：prepare.py、train.py 和 program.md。这种三层分离的架构，而非复杂的框架嵌套，才是其设计哲学的精髓。 三文件架构：冻结层、可变层与元层 在 autoresearch 中，Agent 的操作空间被严格限定。 prepare.py（冻结层）：定义评估标准、数据集和强制性的时间预算，Agent 无权修改。这确保了实验的基座稳固，Agent 无法通过修改数据或放宽测试标准来"作弊"。 train.py（可变层）：这是 Agent 唯一的操作对象。Agent 通过读取、修改并运行这个文件来验证自己的猜想。 program.md（元层）：人类写给 Agent 的"系统宪法"。它不包含具体的编程步骤，而是规定了运行逻辑、错误处理策略、结果记录格式以及"永不停止"的指令。 这种三层设计让 Agent 拥有了在受控环境下的完全自主权。它不需要询问用户"下一步做什么"，因为它在宪法约束下，在冻结层基准上，不断迭代可变层。 固定预算：从限制到设计 autoresearch 强制要求每个实验只能运行 5 分钟。在追求极致性能的 ML 领域，这看起来像是妥协，实则是高明的设计。 固定时间预算提供了绝对公平的比较前提。无论 Agent 把模型改得更深还是更宽，引入了怎样的优化算法，性能提升必须在 5 分钟内体现。这迫使 Agent 寻找的是"计算效率最优解"，而非堆砌算力的暴力解。 系统采用 val_bpb（验证集每字节位数）作为评价指标，与词表大小和分词方式无关。这保证了评估函数不可被 Agent 通过架构选择来"游戏化"。有了客观且难以作弊的反馈，Agent 的 keep/discard 决策才具备可信赖的意义。 Agent 发现了什么：时间约束下的帕累托最优 MLX 社区（Apple Silicon 移植版）的公开实验结果很能说明问题。Agent 将默认的 8 层深度砍到 4 层，val_bpb 从 2.667 降到了 1.808，单次实验降幅接近 28%。 ...