71 个 Agent 真会一起干活？ECC 给 Codex 加了什么

页面已经能打开，按钮也能点，交给同事一试，却发现空列表导出报错，文件名不对，需求里写的权限检查根本没做。用AI做项目，最烦的常常不是“它不会写”，而是它写完以后，你还得把遗漏的工程环节一件件补回来。

10月23日，ECC因为“71个Agent、311个Skills”的介绍引起讨论。它提供的是一组角色定义、技能、规则和自动化机制，试图把规划、实现、审查、验证与经验保存连起来。它不是新模型，也不等于安装完成就有71名成员同时替你干活。原帖、ECC官方仓库

数量是真的，开发团队却不会自动出现

截至10月26日，本次核对的ECC提交为25278e7，版本文件和Codex插件清单均写2.2.3。直接按仓库路径统计，agents/根目录有71份Markdown定义，skills/一级子目录有311份SKILL.md。这能验证目录规模，不能验证某个任务会调用多少角色、结果提高多少。固定提交目录

*据固定提交的目录与插件清单整理。311是技能文件数量，281仍出现在Codex介绍文字中；它们都不是同时运行数量。*

一个值得注意的小差异：主README写311个技能，Codex专用README和插件短介绍仍写281；但该插件的skills字段实际指向根目录./skills/。按这个提交，可以确认引用的是整个目录，介绍文字尚未同步，不能据此另造“Codex只支持281个”的结论。Codex插件清单

Agent定义也要和运行机制分开看。角色文件描述职责和做法，真正是否启动、如何委派，要看客户端支持、配置与任务。仓库另有3份Codex示例角色配置，这也不等于所有角色已自动注册成Codex子代理。给项目加了更多工具，不等于马上拥有一支能自行协调的团队。

把“导出CSV”交给一套能检查的流程

用一个功能需求来看ECC的价值：给后台列表加CSV导出。下面是说明用的任务，不是已完成的项目实测。

如果只要求“帮我加导出”，模型可能做出一个能下载的按钮，却漏掉当前筛选、空数据、中文文件名或权限。先做规划，应该留下可检查的约定：导出全部还是当前筛选；字段顺序是什么；无数据怎样处理；谁可以导出。实现者拿到这些，才知道什么叫做完。

接着把验收要求变成检查动作，再编写或修改代码。审查时交给另一个上下文的，也应是需求、差异和检查结果，而不只是“我已经完成”的一句话。发现遗漏，再让实现环节接回修改。ECC的技能与角色定义可以为这些环节提供工作方法。官方组件说明

*以CSV导出为例的流程示意。交接对象是验收条件、代码差异和检查记录，图中不表示已执行或通过。*

这种流程对做原型的产品经理也有用：它把“看起来能用”拆成能检查的交付范围。对维护网站的人，价值则在于少漏一次权限或边界情况。收益要落到真实差异与结果上，不能靠多报几个角色名称证明。

验收条件还可以再具体一点。导出当前筛选，意味着不能偷偷带上筛选之外的数据；字段顺序，要能和业务表格对得上；空列表可以提示无数据，也可以导出只有表头的文件，但应先选定一种行为。中文文件名和包含逗号的单元格，则需要对应的检查样例。这些都是任务约定，不需要先召集一大群Agent才能写清。

审查者拿到的材料也不宜无限膨胀。把本次需求、有关差异、已做和未做的检查交接过去，通常比复制整段长对话更容易发现问题。“独立上下文”提供的是重新判断的机会；缺少验收要求，换一个角色也可能继续漏掉同样的事。

Skills、规则、Hooks和记忆，各做一件事

Skills提供某类任务的方法，比如测试驱动、代码审查、安全检查；规则是你选择让项目遵循的约定。Hooks则是在客户端支持的事件发生时执行已配置动作，比如会话启动。这几层不能混为“模型装上后自动变聪明”。官方目录与工作机制

记忆与持续学习保存的是经验、摘要或可复用做法，不是给底层模型重新训练。记录也会过期：上个月的部署路径、旧版接口、一次没有复现的修复，都可能把后面的任务带偏。留下来源和适用范围，让重要结论回到代码与文档核对，比存得多更重要。

ECC也包含AgentShield安全扫描，覆盖提示、Hooks、MCP配置、权限和密钥等检查对象。它是一层检查工具，不能代替对命令、权限和实际代码的判断。

Codex能安装插件，Hooks还需要单独信任

当前ECC文档提供Codex原生插件路径。按其说明，Codex 0.146.0及以后使用下面的命令；这是文档步骤，本篇没有执行安装。Codex专用说明

codex plugin marketplace add affaan-m/ECC
codex plugin add ecc@ecc
codex plugin list --json

安装后重启、查看插件，是第一层检查；还要确认它引用的技能、MCP配置和资源在缓存中完整。原生插件的启用状态保存在当前CODEX_HOME下，不照搬Claude Code的user、project、local三种安装范围。

*官方文档说明插件根目录和缓存资源的关系，以及Codex自身的启用范围。实际命令仍应阅读对应版本的原文。*

Hooks是另一回事。官方要求在新的Codex会话中打开/hooks，审阅并信任相应定义；插件已注册，不代表这些命令已被授权。Codex使用经过适配的Hooks子集，也不能照搬Claude的Hooks配置档位。

旧的sync-ecc-to-codex.sh属于复制、合并配置的兼容路径，和原生插件是两条安装方式。已有旧同步层的人，先查清现状，再决定迁移；不要为了“装得更完整”把两条路径叠起来。

先补一个缺口，别急着把所有能力用上

ECC当前以Claude Code为主要支持环境，Codex有原生插件路径，各平台的能力并不完全一致。官方矩阵还列出Windows原生环境中部分持续学习和记忆写入的已知问题；涉及这些功能，先看问题状态，不能把“支持Windows”理解为每个组件都无条件可用。平台支持矩阵

比较稳妥的起点，是选一个熟悉的小功能，只用规划、实现和审查所需的能力，要求交付验收条件、差异与检查记录。需要接入时，可以把下面这段交给自己的Agent：

阅读ECC当前官方Codex插件说明，先检查Codex版本、已有插件、
旧同步配置、项目规则和Hooks，报告冲突与必要改动。
优先采用官方原生路径，不同时叠加旧同步安装，不覆盖现有规则。
先列出适合当前任务的少量技能；Hooks由我审阅后决定是否信任。
验证插件注册与资源完整性，区分“已安装”和“任务效果已验证”。

ECC代码采用MIT许可，开源部分可免费取得；模型订阅、API调用以及可选托管服务仍是另一笔费用。多开一个上下文，就多一份读取和协调的消耗。若任务本来很简单，加上长规划和多轮审查，反而可能更慢。

因此第一次尝试不要用陌生的大项目判断成败。拿一个你清楚边界的小功能，记录原本容易遗漏什么，接入后是否补上；再看额外用了多少会话和时间。工具的作用应当能在交付物上指出来，而不是只在对话里多出现几种角色名称。

判断它是否值得留下，可以看下一次交付：原来漏掉的边界是否进入验收，审查发现的问题是否修掉，下一次会话能否接着已有记录继续。ECC值得关注的，是把这些工程环节做扎实的机会。71个Agent的名单，只是起点。