Agent

在 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 会先调用"架构分析技能"来识别潜在的副作用，而不是直接开始修改代码。 ...

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%。 ...

Arthas 最近放出了 MCP Server 能力。这个变化的意义，不只是“Arthas 多了一个新入口”，而是： Java 诊断能力，第一次可以被本地 Agent 以标准工具协议直接调用。 以前我们做性能测试，常见流程是这样的： 压测工具把流量打上去 我们盯着监控看 CPU、RT、GC 发现异常后，再 SSH 到机器里 attach Arthas 手工跑 thread、dashboard、trace、watch 最后把零散信息拼成结论 这个流程不是不能用，但它有两个问题： 慢：压测窗口很短，手工分析经常跟不上问题出现的节奏 碎：数据、判断和命令是割裂的，很难形成可复用流程 Arthas MCP 把这件事往前推进了一步：AI Agent 可以直接把 Arthas 当工具调用。 于是问题就变成了： 如果我的 Java 服务跑在远端 K8s 集群里，本地 Agent 怎么安全地连上远端 Arthas MCP，并在压测时参与分析？ 这篇文章我想把这件事讲透，重点回答四个问题： Arthas MCP 到底解决了什么问题 远端 K8s 场景下，链路应该怎么设计 最推荐的接入方式是什么 我如何把这件事做成一键脚本，并真正用于压测分析 一、Arthas MCP 到底是什么 根据 Arthas 官方文档，Arthas MCP Server 是 Arthas 的实验性模块，实现了基于 MCP（Model Context Protocol） 的服务端能力，通过 HTTP / Netty + JSON-RPC 2.0 对外暴露工具接口。 ...

最近看到一篇公众号文章在聊 OpenAI 刚开源的 Symphony。如果只看标题，很容易把它理解成“又一个 AI 编程神器”。但我把它的 GitHub 仓库、SPEC.md 和 Elixir 参考实现说明都过了一遍之后，感觉这项目真正值得看的地方，不是“AI 会不会写代码”，而是： OpenAI 正在尝试把 AI 编程从“对话式辅助”推进到“任务级执行”。 一句话总结： Symphony 不是 IDE 里的代码助手，而是一个围绕 issue、workspace、coding agent、PR、CI 和人工审批构建的任务编排器。 项目地址： GitHub：https://github.com/openai/symphony 先说结论：Symphony 解决的是“管理工作”，不是“补全代码” 今天大多数 AI 编程工具的典型使用方式还是这样： 你在 IDE 或终端里提问 AI 给你一段实现 你审查、纠偏、继续补上下文 AI 再继续写 这种模式当然有效，但本质上还是 人工实时驾驶。 你虽然在用 AI，但注意力并没有真正被解放。你只是把“自己敲代码”变成了“盯着 AI 敲代码”。 Symphony 想解决的正是这个问题。它的目标不是让 AI 把某个函数写得更快，而是把一项工程工作变成一个 可调度、可隔离、可观察、可审批 的自动化执行单元。 也就是说，工程师关注的对象从： “这几行代码怎么写” 转向： “这个任务有没有被正确完成” “交付结果是否可信” “现在是否应该批准合并” 这背后其实是一种非常明确的范式变化： 从管理代码生成过程，转向管理任务完成结果。 Symphony 是怎么工作的 根据 README.md、SPEC.md 和 elixir/README.md，Symphony 的大致工作流程是这样的： 持续轮询任务系统（当前规范版本主要是 Linear） 找出符合条件的 issue 为每个 issue 创建一个独立 workspace 在 workspace 里启动 coding agent 按仓库中的 WORKFLOW.md 指令推进实现 让 agent 生成 PR、CI 状态、review 反馈等结果 把任务交给人工审批或流转到下一状态 如果任务状态改变，比如变成： ...