Valhalla静态工程审阅｜ECC 源码静态评测：896 个 Agent Skill 背后的工程能力与安全边界【Agent Skill 特辑 #011】

TunerT_TQ

340人浏览 · 2026-08-16 13:59:09

TunerT_TQ · 2026-08-16 13:59:09 发布

Valhalla静态工程审阅｜ECC 源码静态评测：896 个 Agent Skill 背后的工程能力与安全边界【Agent Skill 特辑 #011】

评测对象：ECC（Agent harness 性能优化系统）
仓库：https://github.com/affaan-m/ECC
固定提交：f1923017275a69516822ad551a8dfed34a772723
评测类型：证据驱动的只读静态工程审阅
采集路线：SafeNet ALLOWED / GitHub Origin
适合读者：CEO、CTO、技术负责人、AI 平台工程师、安全审阅人员
重要边界：本文未执行项目代码、测试、依赖扫描或运行时安全验证

摘要

随着大模型 Agent 从对话系统进入代码编写、命令执行、工具调用和持续记忆阶段，单纯依赖模型提示词已经不足以支撑稳定的工程协作。Agent 需要具备可复用的技能、记忆管理、研究流程、安全策略、插件机制和多平台适配能力。

ECC 项目正是围绕这一方向构建的 Agent harness 系统。本次评测基于固定提交 f1923017275a69516822ad551a8dfed34a772723，对其源码结构、技能资产、构建配置、测试线索、CI 工作流和静态风险命中进行只读分析。

扫描结果显示：

识别出 651 个受支持源文件；
主要实现语言包括 JavaScript、Python、Shell、TypeScript、Rust 和 Swift；
识别出 896 个 SKILL.md 或技能条目；
识别出 20 个一级目录或顶层入口；
识别出 9 个构建与依赖配置文件；
识别出 100 个测试文件线索；
识别出 11 个 CI 工作流线索；
识别出 200 条静态风险命中，其中 Shell 调用和路径处理相关命中较多。

这些结果表明，ECC 的核心价值不只是一个脚本集合，而是一个包含技能编排、插件扩展、状态管理、跨 Agent 适配和安全检查的多语言工程系统。

但静态风险命中不能直接等同于漏洞，技能文件数量也不能直接等同于有效能力。对于 Agent 系统，真正需要验证的是：

技能是否可控？
权限是否最小？
命令是否可审计？
状态是否可恢复？
插件是否可信？
输出是否经过验证？

本文将从架构、工程证据、安全边界和落地验证四个方面进行分析。

一、结论先行

基于固定提交的源码静态证据，ECC 可以作出以下判断：

可以确认的事项

ECC 是一个多语言 Agent 工程系统；
JavaScript 是主要实现语言；
项目拥有较大的 Agent Skill 资产集合；
仓库存在多个 Agent 平台和插件适配入口；
项目包含 Node.js、Python、Rust 等不同技术栈；
仓库存在测试源码和 CI 工作流；
项目包含命令执行、文件访问、路径处理和动态执行等高敏感能力线索；
固定提交可作为后续构建、测试和安全复核的基线。

当前不能确认的事项

项目能否在目标环境成功安装和运行；
896 个技能是否均可用、有效或经过维护；
测试是否全部通过；
CI 工作流当前是否处于绿色状态；
静态风险命中是否能够被外部输入触发；
Shell 调用是否经过参数约束和权限隔离；
Agent 是否会访问敏感文件、凭证或生产环境；
项目是否适合直接用于企业生产环境。

因此，最准确的管理结论是：

ECC 已具备继续进行 PoC、测试和安全尽调的工程基础，但当前静态证据不足以支持生产放行或安全承诺。

二、ECC 是什么类型的系统？

从仓库结构和技能资产看，ECC 更接近一种：

面向 AI Agent 执行体的能力编排与工程约束系统。

它可能同时承担以下职责：

技能注册与发现；
Agent 行为规范；
记忆和状态管理；
研究流程封装；
安全规则注入；
插件适配；
命令或工具调用；
任务执行生命周期管理；
多种 Agent 平台集成。

与普通业务应用相比，这类系统有一个显著特点：

系统不只是处理数据，还会影响另一个具有决策和执行能力的自动化主体。

因此，ECC 的工程风险不能只按照“代码有没有报错”来判断，还需要关注：

Agent 可以调用哪些技能；
技能能访问哪些资源；
技能是否能够组合出高风险动作；
记忆内容是否可能污染后续任务；
插件是否能够绕过统一策略；
任务失败后是否会重复执行；
外部命令的输入和输出是否可控。

三、整体架构：从技能资产到执行体

根据当前静态证据，可以将 ECC 抽象为以下架构：

这张图表达的是静态源码结构推导出的能力关系，不代表完整运行时调用图，也不代表所有模块在每次任务中都会被执行。

四、源码规模与技术构成

4.1 多语言结构

本次扫描识别出 651 个受支持源文件：

语言	文件数量	主要可能承担的职责
JavaScript	514	插件、脚本、工具和运行时集成
Python	63	测试、辅助工具、模型或任务相关逻辑
Shell	34	安装、构建、环境配置和自动化操作
TypeScript	22	类型化插件或平台接口
Rust	17	`ecc2` 相关实现或底层组件
Swift	1	特定平台适配或辅助逻辑
合计	651

JavaScript 占据主导地位，说明项目的主要集成和自动化逻辑可能围绕 Node.js 生态展开。

同时，Python、Shell 和 Rust 的存在意味着部署和维护时需要同时管理：

Node.js 包管理器；
Python 环境；
Shell 工具链；
Rust 工具链；
可能存在的平台特定依赖。

这会增加安装、升级、供应链扫描和跨平台验证的复杂度。

4.2 技能资产规模

本次扫描识别出：

SKILL.md / 技能条目：896

这是 ECC 最具辨识度的资产之一。

技能文件数量较多，说明项目试图将 Agent 能力拆分为大量可复用单元。这样的组织方式有明显价值：

能力可以按领域独立维护；
Agent 可以按任务选择技能；
技能说明能够沉淀操作流程；
可以为不同 Agent 平台提供统一能力描述；
便于对技能进行版本控制和复用。

但数量不能直接等同于质量。

896 个技能条目可能同时带来以下问题：

技能命名和职责重叠；
技能之间缺乏统一输入输出契约；
技能权限声明不完整；
技能文档与实现不一致；
技能之间出现隐式依赖；
旧技能未及时维护；
同一任务存在多个行为相近但结果不同的技能；
Agent 选择技能时出现不稳定或不可解释行为。

因此，评估技能资产时，数量只是第一层指标，更重要的是技能治理。

五、技能系统的四层治理模型

建议将 ECC 的 SKILL.md 资产按照以下四层进行审阅：

5.1 身份层

每个技能至少需要有：

唯一名称；
明确用途；
适用 Agent；
维护状态；
版本或变更记录；
所属领域。

如果技能只包含宽泛描述，例如“处理项目问题”“执行研究任务”，Agent 可能难以稳定选择，也不利于审计。

5.2 契约层

技能不应只有自然语言说明，还应明确：

输入格式；
输出格式；
允许的缺省值；
失败条件；
是否可重试；
是否幂等；
是否产生外部副作用；
是否允许中途取消。

例如，一个文件修改技能应该明确：

name: update-config
input:
  - path
  - patch
output:
  - changed_files
  - diff
side_effects:
  filesystem: write
  network: none
idempotent: true
requires_approval: true

这比仅凭 Prompt 描述行为更适合工程治理。

5.3 权限层

对于 Agent Skill，最关键的安全问题通常不是“代码能否执行”，而是：

技能执行时可以执行什么？

至少应标注：

文件系统读权限；
文件系统写权限；
是否可执行 Shell；
是否可访问网络；
是否可读取环境变量；
是否可读取 Token、SSH Key 或云凭证；
是否可调用 Docker；
是否可操作 Git；
是否可修改系统配置。

技能应采用最小权限，而不是默认继承宿主 Agent 的全部权限。

5.4 证据层

一个技能被定义出来，并不意味着它已经可靠。应为关键技能补充：

单元测试；
集成测试；
输入边界测试；
错误路径测试；
幂等性测试；
权限拒绝测试；
外部副作用测试；
日志和审计测试。

对于高风险技能，最好形成：

技能定义
+ 权限声明
+ 测试用例
+ 变更记录
+ 安全审查
+ 运行时审计

六、主要模块与阅读入口

本次静态分析识别出 20 个一级目录或顶层入口，包括：

.claude
.codebuddy
.cursor
.kiro
.opencode
.pi
.trae
docker
docs
ecc2
ecc_dashboard.py
eslint.config.js
install.sh
integrations
scripts
skills
src
tests
workflows

需要注意：其中既包含目录，也包含顶层文件，例如：

commitlint.config.js
ecc_dashboard.py
eslint.config.js
install.sh

因此，20 项应理解为“一级模块和顶层入口表面”，不能全部视为独立业务模块。

6.1 Agent 平台适配层

以下目录是理解跨平台集成的重点：

.claude
.codebuddy
.cursor
.kiro
.opencode
.pi
.trae

它们可能承担不同 Agent 平台、编辑器或运行时的插件适配职责。

这类多平台适配的优势是：

降低技能复用成本；
便于同一套 Agent 方法迁移；
可以按平台实现不同事件和工具接口；
有利于形成统一的 Agent 工程规范。

但风险也很明显：

不同平台的权限模型可能不一致；
同一技能在不同平台上的行为可能不同；
某个平台可能绕过统一安全检查；
插件生命周期和异常处理可能不一致；
测试矩阵会快速膨胀。

因此，不能只测试核心运行时，还要验证：

同一技能
→ 不同平台入口
→ 是否具有一致权限
→ 是否具有一致输出
→ 是否具有一致审计行为

6.2 `scripts`

scripts 目录是工程自动化和状态管理的重要阅读入口。报告列出的相关文件包括：

scripts/lib/agent-proximity/index.js
scripts/lib/state-store/index.js
scripts/lib/skill-evolution/index.js

从命名看，可能涉及：

Agent 关系或邻近度管理；
状态存储；
技能演化或更新；
自动化任务编排。

这些区域需要重点确认：

状态写入位置；
是否使用用户输入构造路径；
是否存在并发写入；
是否有版本迁移；
是否支持回滚；
是否记录数据来源；
是否允许 Agent 自主修改技能。

尤其是“技能演化”类能力，如果允许系统自动修改技能内容，就需要额外关注：

修改审批；
版本控制；
差异审查；
回滚机制；
污染检测；
技能签名；
训练数据或反馈数据的来源。

6.3 `ecc2`

本次评测中，ecc2 包含 Rust 相关配置：

ecc2/Cargo.toml
ecc2/rust-toolchain.toml
ecc2/src/comms/mod.rs
ecc2/src/tui/dashboard.rs
ecc2/src/session/manager.rs

这说明项目除了脚本和插件层之外，还包含 Rust 组件。

Rust 可能适合承担：

高性能通信；
会话管理；
本地终端界面；
状态协调；
长驻运行时；
更严格的类型和内存安全边界。

但引入 Rust 也会带来新的工程验证要求：

Rust 工具链版本；
Cargo 依赖锁定；
跨平台编译；
二进制发布；
Node/Python 与 Rust 的接口；
构建缓存和制品可追溯；
安全更新和漏洞扫描。

不能因为 Rust 具备内存安全优势，就默认整个 ECC 系统安全。系统风险仍然可能来自 Shell、插件、文件路径、权限和外部命令调用。

6.4 `src`

报告列出了：

src/llm/__main__.py

这说明项目包含 Python 侧的 LLM 相关入口或辅助逻辑。

对这一部分的重点审阅方向包括：

模型或 Provider 配置来源；
API Key 的读取方式；
请求日志是否脱敏；
Prompt 和响应是否持久化；
超时与重试；
网络出口；
Provider 切换；
错误信息是否包含敏感上下文。

6.5 `tests`

测试目录中识别出多个 JavaScript 和 Python 测试入口，例如：

tests/plugin-manifest.test.js
tests/test_selector.py
tests/conftest.py
tests/run-all.js
tests/codex-native-hooks.test.js
tests/opencode-tools.test.js
tests/test_invariant_runner.py

这表明 ECC 至少在以下方向存在测试线索：

插件清单；
测试选择；
Codex 原生 Hook；
OpenCode 工具；
不变量检查；
多种模型或 Agent Provider。

但仍需通过实际执行确认：

测试套件是否完整；
测试是否依赖本地工具；
测试是否会调用外部网络；
测试是否会执行真实 Shell；
测试是否存在固定凭证或测试密钥；
测试夹具是否能接触真实文件系统。

七、静态风险命中：200 条意味着什么？

本次扫描识别出 200 条静态风险命中：

风险标签	命中数
`RISK-SHELL-INVOCATION`	120
`RISK-PATH-TRAVERSAL`	68
`RISK-SECRET-LITERAL`	7
`RISK-DYNAMIC-EXECUTION`	5
合计	200

这是一个需要人工复核的信号集合，不是漏洞数量。

7.1 Shell 调用：Agent 系统的核心风险面

Shell 调用命中数最多，达到 120 条。对于 ECC 这类 Agent harness，Shell 调用本身可能是合理设计，因为 Agent 需要：

执行测试；
运行构建；
查询 Git 状态；
调用本地工具；
管理插件；
运行环境检查；
启动辅助服务。

真正需要判断的是：

Shell 命令是否由外部输入影响？
参数是否经过安全构造？
是否使用固定命令白名单？
执行用户是否最小权限？
工作目录是否受控？
环境变量是否经过清理？
输出是否被审计？

例如以下两类代码的风险完全不同：

execFile("git", ["status", "--short"], options);

与：

exec(`git ${userInput}`, options);

静态规则可能同时命中 Shell 调用，但只有结合数据流和调用链后，才能判断是否存在命令注入或越权执行风险。

7.2 路径处理：Agent 读写能力的关键边界

路径相关命中为 68 条，样例包括：

.cursor/hooks/before-shell-execution-block-no-verify.js
.cursor/hooks/before-shell-execution.js
.trae/uninstall.sh
.opencode/tools/changed-files.ts
.opencode/plugins/ecc-hooks.ts
ecc2/src/tui/dashboard.rs
ecc2/src/session/manager.rs

路径处理需要重点检查：

是否接收用户或 Agent 生成的路径；
是否使用 .. 穿越；
是否解析符号链接；
是否限制在工作区根目录；
是否验证真实路径；
是否允许写入配置、Hook 或插件目录；
是否可能覆盖系统文件；
Windows 和 Unix 路径语义是否一致。

理想的文件访问策略应是：

输入路径
  → 规范化
  → 解析真实路径
  → 检查工作区边界
  → 检查文件类型
  → 检查操作权限
  → 执行读写
  → 记录审计事件

不能仅依赖字符串前缀判断路径安全，例如：

target.startsWith(workspace)

因为符号链接、路径规范化和同名前缀都可能导致边界判断错误。

7.3 动态执行：需要审阅上下文和数据流

动态执行命中包括：

.opencode/tools/security-audit.ts
tests/codex-config.test.js

动态执行可能用于：

加载插件；
解释配置；
执行测试；
运行脚本；
适配不同平台。

但必须确认：

执行内容来自静态代码还是外部输入；
是否存在 eval、动态导入或运行时编译；
模块路径是否可控；
运行环境是否隔离；
是否允许加载工作区中的不可信插件；
是否验证插件签名或哈希。

对于 Agent 插件系统，动态加载是常见能力，但应明确区分：

可信内置插件

与：

用户工作区插件

二者不能默认拥有相同权限。

7.4 Secret literal：测试字符串不等于真实凭证

扫描识别出 7 条 RISK-SECRET-LITERAL 命中，其中样例包括：

tests/test_claude_provider.py
tests/ci/ito-baskets-skill.test.js

这类命中可能是：

测试用 API Key；
占位字符串；
模拟 Token；
测试密码；
文档示例；
已失效的历史凭证。

但即使出现在测试文件中，也应该逐条确认：

是否具有真实格式；
是否曾经具备真实权限；
是否进入 Git 历史；
是否进入构建产物；
是否需要立即轮换；
是否应改用环境变量或测试注入；
是否已接入 Secret Scanning。

正确的结论只能是：

发现疑似敏感字面量，需要人工确认，不等于已确认存在真实泄露。

八、Agent 系统特有的安全威胁

ECC 的风险不能只按照普通 Node.js 或 Python 项目审查，因为 Agent 系统具有“自然语言输入驱动工具调用”的特征。

8.1 Prompt 注入与工具越权

攻击者可能通过：

仓库 README；
Issue；
代码注释；
外部网页；
文档；
测试数据；
工具返回值；

向 Agent 注入指令，诱导其：

读取敏感文件；
执行危险命令；
修改技能；
上传环境信息；
绕过审批；
修改 Hook 或插件；
伪造测试结果。

因此，技能系统应将“自然语言指令”和“安全策略”分离，不能把从外部数据中读取到的文本视为可信系统指令。

8.2 记忆污染

如果 ECC 会持久化 Agent 状态、经验或技能演化结果，需要关注：

谁可以写入记忆；
记忆是否区分租户；
记忆是否带来源和可信等级；
是否允许自动覆盖系统规则；
记忆是否支持版本回滚；
是否清理过期或污染内容；
后续任务是否会无条件读取历史记忆。

建议对记忆条目增加元数据：

memory:
  id: memory-123
  source: task-output
  tenant: tenant-a
  confidence: low
  created_at: 2026-08-16T05:00:00Z
  expires_at: 2026-09-16T05:00:00Z
  requires_review: true

8.3 技能组合导致权限放大

单个技能可能看起来风险较低，但多个技能组合后可能产生高危路径：

读取文件
  + 处理文本
  + 写入配置
  + 执行 Shell
  + 访问网络

这会形成从数据读取到外传或系统修改的完整链路。

因此，权限审计不能只检查单个 Skill，还应检查：

Skill 组合；
工具调用序列；
跨技能数据传递；
任务级权限预算；
高风险动作是否需要人工审批。

九、工程证据与治理能力

9.1 测试证据

测试文件线索为 100，说明项目具备一定测试资产。

不过，Agent 系统的测试不能只验证函数返回值，还应覆盖：

工具调用是否符合权限策略；
危险命令是否被阻止；
路径越界是否被拒绝；
插件加载失败是否安全；
外部服务超时是否正确重试；
任务取消后是否清理进程；
状态损坏后是否可恢复；
技能更新失败是否自动回滚；
Prompt 注入场景是否触发防护。

建议将测试分为四类：

测试类型	目标
单元测试	验证局部函数和模块逻辑
集成测试	验证插件、工具和状态之间的协作
对抗性测试	验证 Prompt 注入、路径穿越和命令注入防护
生命周期测试	验证安装、运行、升级、失败和卸载

9.2 CI 工作流证据

本次扫描识别出 11 个 CI 工作流线索，包括：

.github/workflows/release.yml
.github/workflows/supply-chain-watch.yml
.github/workflows/reusable-release.yml
.github/workflows/generator-generic-ossf-slsa3-publish.yml
.github/workflows/reusable-validate.yml
.github/workflows/reusable-test.yml
.github/workflows/monthly-metrics.yml
.github/workflows/maintenance.yml
.github/workflows/ci.yml
.github/workflows/release-announce.yml
.github/workflows/discussion-announce.yml

这说明项目存在：

持续集成；
可复用测试或发布流程；
供应链监测线索；
发布制品流程；
SLSA 相关发布线索；
维护和指标任务。

但“存在工作流”不能等价于：

当前工作流通过；
发布制品可信；
所有分支都执行安全检查；
供应链风险已经消除；
构建过程完全可复现。

需要进一步核对：

工作流当前运行状态；
使用的第三方 Action；
Action 是否固定到不可变提交；
构建依赖是否锁定；
发布制品是否签名；
是否生成 SBOM；
是否启用 provenance；
密钥权限是否最小；
Pull Request 是否执行同样的安全检查。

9.3 依赖和构建证据

本次识别出 9 个构建或依赖配置文件：

pyproject.toml
yarn.lock
package.json
docker/plugin-setup/Dockerfile
.opencode/package.json
ecc2/Cargo.toml
ecc2/rust-toolchain.toml
tests/fixtures/docker-plugin-project/package.json
skills/skill-comply/pyproject.toml

从工程角度看，这意味着 ECC 至少存在三条需要分别验证的依赖链：

建议为每条链分别生成：

依赖树；
锁文件检查；
SBOM；
漏洞扫描；
许可证报告；
构建产物哈希；
来源和版本记录。

十、面向管理层的工程判断

10.1 CEO：ECC 值不值得继续投入？

从静态证据看，ECC 具备较明显的产品化潜力：

技能资产规模较大；
支持多个 Agent 平台；
具有插件和工具集成；
存在测试和 CI 线索；
具备一定供应链工程意识；
包含状态、会话和技能演化等长期运行能力。

但它也明显不是一个“安装即可无风险使用”的工具。

继续投入前，管理层应重点确认：

目标用户是个人开发者、团队还是企业平台；
是否允许 Agent 执行真实 Shell；
是否会接触生产代码和凭证；
是否需要多租户隔离；
是否需要审计和合规；
是否需要稳定的版本兼容承诺；
是否有专人维护技能资产。

10.2 CTO：最先验证哪些问题？

优先级建议如下：

P0：安装与运行边界

最小安装命令；
Node、Python、Rust 版本要求；
是否需要 Docker；
是否需要联网；
是否修改用户目录；
是否安装全局 Hook；
卸载是否完整。

P0：命令和文件权限

Shell 调用清单；
命令参数来源；
工作目录边界；
环境变量读取；
凭证读取；
子进程权限；
网络出口。

P1：技能治理

896 个技能的索引；
技能重复和过期情况；
权限声明覆盖率；
高风险技能清单；
技能版本和更新机制；
技能组合风险。

P1：插件供应链

插件来源；
插件签名；
插件安装权限；
插件更新策略；
第三方 Action 固定方式；
发布制品校验。

P2：性能与稳定性

Agent 任务耗时；
并发任务数；
状态库读写性能；
长任务恢复；
插件故障隔离；
记忆规模增长；
多平台行为一致性。

十一、建议的验证架构

下一步建议建立四层验证体系：

十二、推荐的最小 PoC

为了避免只停留在源码统计，建议在隔离环境中完成一个最小验证闭环：

固定提交
  ↓
安装依赖
  ↓
加载一个低权限 Skill
  ↓
执行一个只读工具调用
  ↓
记录输入、权限和输出摘要
  ↓
触发一次拒绝场景
  ↓
确认日志和错误处理
  ↓
清理状态与临时文件

建议选择以下低风险验证任务：

读取当前工作区的固定文件；
输出 Git 状态；
运行只读测试；
尝试访问工作区外路径并确认被拒绝；
尝试执行不在白名单中的命令并确认被拒绝；
模拟插件加载失败；
检查任务结束后子进程和临时文件是否清理。

不要在首次验证时直接使用：

真实云凭证；
生产代码库；
SSH 私钥；
生产网络；
具备写权限的数据库；
未审计的第三方插件。

十三、静态风险命中的正确解读

需要特别强调以下三组区别：

不能混淆的概念	正确理解
静态命中 vs 漏洞	命中只是需要复核的代码模式
技能数量 vs 能力质量	条目数量不代表技能有效性
CI 文件存在 vs CI 可信	工作流文件不代表运行成功和制品安全
锁文件存在 vs 依赖安全	仍需漏洞、许可证和来源验证
Rust 代码存在 vs 系统安全	Shell、插件和权限边界仍可能成为风险源
测试文件存在 vs 测试通过	必须实际执行并记录结果

对于 ECC，最重要的不是盲目减少静态命中，而是建立风险分类：

命中位置
→ 数据来源
→ 调用方
→ 权限上下文
→ 生产可达性
→ 失败行为
→ 审计能力
→ 修复优先级

十四、最终评价

基于提交：

f1923017275a69516822ad551a8dfed34a772723

本次静态评测确认 ECC 具有以下工程特征：

651 个受支持源文件；
JavaScript 主导的多语言技术栈；
896 个 Agent Skill 或 SKILL.md 条目；
20 个一级目录或顶层入口；
9 个构建和依赖配置文件；
100 个测试文件线索；
11 个 CI 工作流线索；
200 条需要人工复核的静态风险命中。

ECC 的主要优势在于：

技能资产规模
+ 多 Agent 平台适配
+ 插件化结构
+ 测试与 CI 线索
+ 状态和会话能力

它的主要工程挑战在于：

技能治理
+ 权限最小化
+ Shell 调用边界
+ 文件路径安全
+ 插件供应链
+ 记忆污染
+ 多语言依赖管理
+ 多平台行为一致性

最终判断是：

ECC 已具备构建 Agent 工程基础设施的明显代码资产和组织结构，适合继续进行隔离环境 PoC、技能治理和安全验证；但当前静态证据不足以证明其适合直接接入生产代码库、真实凭证或高权限执行环境。

对于 Agent harness，最重要的评估路径不是：

技能数量越多越好

而是：

技能可发现
→ 权限可声明
→ 行为可测试
→ 副作用可审计
→ 失败可恢复
→ 版本可回滚
→ 组合风险可控制

当这条链条完成后，ECC 才能从一个“技能和插件集合”进一步成为可治理、可审计、可持续运行的 Agent 工程平台。

参考信息

项目仓库：https://github.com/affaan-m/ECC
固定提交：f1923017275a69516822ad551a8dfed34a772723
评测类型：证据驱动的只读静态工程审阅
主要证据：源码文件、技能条目、构建配置、测试线索、CI 工作流和静态风险标签
未覆盖范围：实际运行、测试通过率、性能、依赖漏洞、运行时安全和生产环境验证

更新日志

版本号	发布日期	修订内容
v2.0	2026-08-16	发布，完成项目核心架构评测、安全风险审计与场景落地建议

大厂官方AI工程硬核审计不易，点赞+收藏+关注，持续更新Vercel/Google/字节官方Agent基建尽职调查特辑！

所有评论(0)

查看更多评论

TunerT_TQ

@TunerT_TQ

已为社区贡献31条内容

Valhalla静态工程审阅｜ECC 源码静态评测：896 个 Agent Skill 背后的工程能力与安全边界【Agent Skill 特辑 #011】

TunerT_TQ

Valhalla静态工程审阅｜ECC 源码静态评测：896 个 Agent Skill 背后的工程能力与安全边界【Agent Skill 特辑 #011】

摘要

一、结论先行

可以确认的事项

当前不能确认的事项

二、ECC 是什么类型的系统？

三、整体架构：从技能资产到执行体

四、源码规模与技术构成

4.1 多语言结构

4.2 技能资产规模

五、技能系统的四层治理模型

5.1 身份层

5.2 契约层

5.3 权限层

5.4 证据层

六、主要模块与阅读入口

6.1 Agent 平台适配层

6.2 scripts

6.3 ecc2

6.4 src

6.5 tests

七、静态风险命中：200 条意味着什么？

7.1 Shell 调用：Agent 系统的核心风险面

7.2 路径处理：Agent 读写能力的关键边界

7.3 动态执行：需要审阅上下文和数据流

7.4 Secret literal：测试字符串不等于真实凭证

八、Agent 系统特有的安全威胁

8.1 Prompt 注入与工具越权

8.2 记忆污染

8.3 技能组合导致权限放大

九、工程证据与治理能力

9.1 测试证据

9.2 CI 工作流证据

9.3 依赖和构建证据

十、面向管理层的工程判断

10.1 CEO：ECC 值不值得继续投入？

10.2 CTO：最先验证哪些问题？

P0：安装与运行边界

P0：命令和文件权限

P1：技能治理

P1：插件供应链

P2：性能与稳定性

十一、建议的验证架构

十二、推荐的最小 PoC

十三、静态风险命中的正确解读

十四、最终评价

参考信息

更新日志

推荐标签

所有评论(0)

温馨提示：您尚未绑定手机号

TunerT_TQ

6.2 `scripts`

6.3 `ecc2`

6.4 `src`

6.5 `tests`