文章大纲 - ECC v2.0.0-rc.1¶

工作标题¶

将 ECC 打造为跨执行框架操作系统

核心论点¶

大多数智能体工作之所以失败，是因为工具彼此孤立。

杠杆来自于将执行框架、可复用工作流层和操作员 shell 视为一个系统：

• 用于可重复工作的技能
• 用于强制执行的钩子和测试
• 用于工具访问的 MCPs
• 用于连续性的记忆和交接
• 一个可以路由日常执行的操作员 shell

结构¶

1. 问题¶

• 太多聊天窗口
• 太多工具专属工作流
• 太多上下文存在于个人习惯中，而不是可复用的系统形态中

2. ECC 已经解决的问题¶

• 可复用技能格式
• 跨执行框架安装界面
• 钩子和验证纪律
• 安全与审查模式
• 围绕内容、研究和业务运营的操作员工作流技能
• 队列、讨论、Linear、遗留和发布证据检查，使运行状态可检查
• Mini Shai-Hulud/TanStack 行动后的供应链 IOC 扫描和无生命周期安装加固

3. 为什么 Hermes 是操作员层¶

• chat、CLI、TUI、cron 和交接可以位于可复用 ECC 层之上
• 业务和内容工作可以与工程工作并行运行
• 日常循环更容易检查和改进

4. rc.1 中发布的内容¶

• 已清理的 Hermes 设置指南
• 发布和分发材料
• 跨执行框架架构文档
• Hermes 导入指南
• 仓库中更清晰的 2.0 定位
• preview-pack 冒烟门禁
• GitHub 发布文案、X、LinkedIn、文章、Telegram/Hermes 交接和演示提示的发布草稿

5. 自 v1.10.0 以来的变化¶

• Claude Code 仍然是核心目标，但 ECC 现在将 Codex、OpenCode、Cursor、Gemini、Zed 和仅终端工作流视为共享执行界面。
• 发布流程现在具有可重复的平台、讨论、可观测性、供应链、Linear 进度和 preview-pack 检查。
• AgentShield 和 ECC Tools 工作已镜像到路线图，因此企业安全、托管审查、策略推广和计费就绪等方向不会偏离主发布。

6. 保留在本地¶

• 密钥和认证
• 原始工作区导出
• 个人数据集
• 尚未清理的特定操作员自动化
• 更深入的 CRM、财务和 Google Workspace 手册

7. 结尾要点¶

目标不是复制某一个完全相同的技术栈。

目标是在智能体周围构建一个操作系统，将重复工作转化为可复用、可衡量的界面。