AI Agent 不只是模型——从 ECC 看 Agent 操作系统的五层架构

一、一个让我重新思考的问题

几个月前，我发现了一个 GitHub 仓库，当时它的 star 数还在十几万，现在已经飙到了 22.6 万——affaan-m/ECC。

ECC 的定位很特别。它不是一个新的 AI 模型，不是一个新的框架，而是定位为 "Agent Harness Operating System"——Agent 的"马笼头"操作系统。

当时我正在用自己的一套 Agent 系统做日常开发。Skills 系统有了，记忆能力有了，定时任务也有了。看起来该有的都有了。但当我深入阅读 ECC 的架构文档时，我发现自己缺了一个东西——系统思维。

我一直在"加功能"：加一个 skill、加一条记忆、加一个工具。而 ECC 在做的，是把 Agent 当成一个操作系统来设计。它有明确的分层、标准化的接口、完整的生命周期管理。

这个视角转换，比任何单个功能都更重要。

二、Agent 操作系统的五层架构

ECC 2.0 的参考架构文档定义了一个清晰的分层模型。下面是我从中提炼的五层结构，每一层解决一个核心问题。

每一层都有明确的职责边界，下层为上层提供能力，上层不越界干涉下层实现。这个设计让我意识到，我之前的"All-in-One"思路——把所有功能塞进一个系统——是没有可扩展性的。

第二层才是核心创新：Harness Adapter

ECC 让我印象最深的设计，不是功能多丰富，而是它对移植性的执念。

这句话的意思是：一个 Skill（工作流定义）应该能在任何平台上跑——Claude Code 能跑、Codex 能跑、OpenCode 能跑、Cursor 也能跑。而适配层只做三件事：

1. 加载共享资产——怎么读 SKILL.md
2. 适配事件形状——PreToolUse 在 Codex 里可能是别的事件名
3. 处理平台限制——这个平台不支持什么功能

这意味着什么？你写一次工作流，就能在所有 Agent 工具上复用。

对比我们的现状：Hermes 的 skills 只能用在 Hermes，Claude Code 的 skills 只能用在 Claude Code。每个工具都在造自己的轮子。ECC 给我们展示了一个更好的方式：把可复用的逻辑放在中间层，把适配的工作交给边缘层。

第三层的 Session 标准化是一个被低估的细节

ECC 定义了一个 ecc.session.v1 的 JSON schema，用来统一所有会话的状态：

{
  "schemaVersion": "ecc.session.v1",
  "session": { "id": "session-123", "kind": "history", "state": "recorded" },
  "workers": [{ "id": "worker-1", "state": "running", "health": "healthy" }]
}

为什么要费这个劲？因为会话数据太重要了。调试要查、分析要查、自动化要查、改进要查。但如果每个工具的会话格式都不一样，这些事就没法系统化地做。

我强烈建议每个做 Agent 系统的团队，都在早期就定义自己的会话标准格式。别等到几千条会话数据堆在那里才想起来要统一。

第五层应该是第三层：为什么安全这么靠下

ECC 把安全放在了第五层（最底层）。这不是说安全不重要，而是说安全应该是基础设施，不是功能。

ECC 的 AgentShield 有 1282 个测试、102 条规则。它覆盖：

• 提示注入检测（Prompt Injection）
• 供应链漏洞（第三方 MCP 包的安全扫描）
• 策略管控（什么工具在什么场景下可用）
• SARIF 格式输出（与 GitHub 代码扫描集成）

对比很多系统的现状：安全是靠"用户手工确认"来保证的——执行危险命令要确认，敏感操作要确认。这不是安全架构，这是人工审批流程。

一个成熟的 Agent 系统，安全不应该依赖人的警惕性，而应该依赖系统层面的策略引擎。

三、当前主流 Agent 系统的层次对比

这是我对几个主流系统的粗略定位（基于公开资料和个人使用经验）：

注意：这不是"谁好谁差"的对比，而是设计重点不同。Claude Code 专注于模型交互体验，Hermes 专注于多平台接入，ECC 专注于系统架构。但 ECC 的架构设计确实提供了一个很好的参考框架——尤其是它的分层思维。

四、这个架构图给我们的三个启发

启发一：分层不是文档里的装饰，是代码里的实体

不要在架构图里画了分层，代码里还是一团。每一层都应该有对应的：

• 目录——代码仓库里独立目录
• 契约——层间通信的接口定义
• 测试——层的独立测试套件

如果在代码里找不到"适配器层"、"运行时层"的实体，那架构图就只是装饰。

启发二：移植性应该从第一天开始设计

ECC 的 SKILL.md 能在 10 种工具上运行，不是靠后期适配，而是靠从一开始就克制地写在 SKILL.md 里——不写平台独有命令、不嵌凭据、不依赖特定 hook。

对我们来说，这意味着：写一个 skill 时，不要假设它在哪个平台运行。用通用的 Markdown 描述工作流，把平台相关的部分隔离到配置中。

启发三：安全不是"加个确认框"

真正成熟的安全应该是：

• 策略引擎——什么可以做什么不能做
• 扫描自动化——每次 tool call 前自动检查
• 供应链管控——第三方工具的安全评级
• 审计日志——所有操作的追踪记录

如果你还在靠"弹窗确认"来做安全，你的系统还处在早期阶段。

五、从今天可以做的三件事

1. 审查你的技能库的平台依赖。 打开你的所有 skill 文件，看看有没有硬编码了特定平台的写法。如果有，开始做隔离：工作流逻辑放一个文件，平台适配放另一个文件。

2. 定义一个最简单的 Session 格式。 不一定要像 ecc.session.v1 那么完整。先从"会话 ID + 时间 + 关键操作摘要"开始，把格式固定下来。你会在做跨会话分析时感谢自己。

3. 建一个安全检查清单。 列出你的 Agent 系统能执行的所有危险操作——文件删除、数据库写入、远程连接。不要只靠人工确认，看哪些可以用规则自动拦截。

参考资源

• ECC GitHub 仓库
• Cross-Harness Architecture
• ECC 2.0 Reference Architecture
• Session Adapter Contract