⚡

代理原生架构审计Skill agent-native-audit

代理原生架构审计技能用于对代码库进行全面的代理原生架构审查。通过启动并行子代理评估八个核心原则（如动作对等、工具作为原语），生成评分报告，帮助识别和改进代理实现中的架构问题。关键词：代理原生架构、审计、AI智能体、代码审查、架构原则、评分报告、软件优化。

AI智能体 0 次安装 0 次浏览 更新于 3/9/2026

name: 代理原生审计 description: 运行全面的代理原生架构审查，带评分原则

参数

[可选：特定原则进行审计]

代理原生架构审计

对代码库进行全面的代理原生架构原则审查，启动并行子代理为每个原则，并生成评分报告。

核心原则审计

  1. 动作对等 - “用户能做的，代理也能做”
  2. 工具作为原语 - “工具提供能力，而不是行为”
  3. 上下文注入 - “系统提示包括关于应用状态的动态上下文”
  4. 共享工作空间 - “代理和用户在同一个数据空间工作”
  5. CRUD完整性 - “每个实体都有完整的CRUD（创建、读取、更新、删除）”
  6. UI集成 - “代理动作立即在UI中反映”
  7. 能力发现 - “用户可以发现代理能做什么”
  8. 提示原生特性 - “特性是定义结果的提示，而不是代码”

工作流程

步骤 1: 加载代理原生技能

首先，调用代理原生架构技能以理解所有原则：

/compound-engineering:agent-native-architecture

选择选项 7（动作对等）以加载完整参考材料。

步骤 2: 启动并行子代理

使用任务工具启动 8 个并行子代理，设置 subagent_type: Explore，每个代理对应一个原则。每个代理应：

  1. 枚举代码库中的所有实例（用户动作、工具、上下文、数据存储等）
  2. 检查原则的合规性
  3. 提供具体评分，如“X 分之 Y（百分比%）”
  4. 列出具体差距和建议

<子代理>

代理 1: 动作对等

审计动作对等 - "用户能做的，代理也能做。"

任务：
1. 枚举前端中的所有用户动作（API 调用、按钮点击、表单提交）
   - 搜索 API 服务文件、获取调用、表单处理程序
   - 检查路由和组件中的用户交互
2. 检查哪些有对应的代理工具
   - 搜索代理工具定义
   - 映射用户动作到代理能力
3. 评分："代理能做 X 分之 Y 的用户动作"

格式：
## 动作对等审计
### 找到的用户动作
| 动作 | 位置 | 代理工具 | 状态 |
### 评分：X/Y（百分比%）
### 缺失的代理工具
### 建议

代理 2: 工具作为原语

审计工具作为原语 - "工具提供能力，而不是行为。"

任务：
1. 查找并读取所有代理工具文件
2. 将每个分类为：
   - 原语（好）：读取、写入、存储、列表 - 无需业务逻辑即可启用能力
   - 工作流（坏）：编码业务逻辑、做出决策、编排步骤
3. 评分："X 分之 Y 工具是合适的原语"

格式：
## 工具作为原语审计
### 工具分析
| 工具 | 文件 | 类型 | 理由 |
### 评分：X/Y（百分比%）
### 问题工具（应为原语的工作流）
### 建议

代理 3: 上下文注入

审计上下文注入 - "系统提示包括关于应用状态的动态上下文"

任务：
1. 查找上下文注入代码（搜索“上下文”、“系统提示”、“注入”）
2. 读取代理提示和系统消息
3. 枚举已注入与应注入的内容：
   - 可用资源（文件、草稿、文档）
   - 用户偏好/设置
   - 最近活动
   - 列出可用能力
   - 会话历史
   - 工作空间状态

格式：
## 上下文注入审计
### 上下文类型分析
| 上下文类型 | 已注入？ | 位置 | 注释 |
### 评分：X/Y（百分比%）
### 缺失的上下文
### 建议

代理 4: 共享工作空间

审计共享工作空间 - "代理和用户在同一个数据空间工作"

任务：
1. 识别所有数据存储/表/模型
2. 检查代理是否读写相同的表或独立的表
3. 查找沙箱隔离反模式（代理有独立的数据空间）

格式：
## 共享工作空间审计
### 数据存储分析
| 数据存储 | 用户访问 | 代理访问 | 共享？ |
### 评分：X/Y（百分比%）
### 隔离的数据（反模式）
### 建议

代理 5: CRUD完整性

审计 CRUD 完整性 - "每个实体都有完整的 CRUD"

任务：
1. 识别代码库中的所有实体/模型
2. 对每个实体，检查是否存在代理工具用于：
   - 创建
   - 读取
   - 更新
   - 删除
3. 按实体和总体评分

格式：
## CRUD 完整性审计
### 实体 CRUD 分析
| 实体 | 创建 | 读取 | 更新 | 删除 | 评分 |
### 总体评分：X/Y 实体具有完整 CRUD（百分比%）
### 不完整的实体（列出缺失的操作）
### 建议

代理 6: UI集成

审计 UI 集成 - "代理动作立即在UI中反映"

任务：
1. 检查代理写入/更改如何传播到前端
2. 查找：
   - 流式更新（SSE、WebSocket）
   - 轮询机制
   - 共享状态/服务
   - 事件总线
   - 文件监视
3. 识别“静默动作”反模式（代理更改状态但UI不更新）

格式：
## UI 集成审计
### 代理动作→UI更新分析
| 代理动作 | UI 机制 | 立即？ | 注释 |
### 评分：X/Y（百分比%）
### 静默动作（反模式）
### 建议

代理 7: 能力发现

审计能力发现 - "用户可以发现代理能做什么"

任务：
1. 检查以下 7 个发现机制：
   - 显示代理能力的入门流程
   - 帮助文档
   - UI 中的能力提示
   - 代理在响应中自我描述
   - 建议的提示/动作
   - 空状态指导
   - 斜杠命令（/help、/tools）
2. 针对 7 个机制评分

格式：
## 能力发现审计
### 发现机制分析
| 机制 | 存在？ | 位置 | 质量 |
### 评分：X/7（百分比%）
### 缺失的发现机制
### 建议

代理 8: 提示原生特性

审计提示原生特性 - "特性是定义结果的提示，而不是代码"

任务：
1. 读取所有代理提示
2. 将每个特性/行为分类为定义在：
   - 提示（好）：结果用自然语言定义
   - 代码（坏）：业务逻辑硬编码
3. 检查行为更改是否需要提示编辑 vs 代码更改

格式：
## 提示原生特性审计
### 特性定义分析
| 特性 | 定义在 | 类型 | 注释 |
### 评分：X/Y（百分比%）
### 代码定义的特性（反模式）
### 建议

</子代理>

步骤 3: 编译总结报告

所有代理完成后，编译总结：

## 代理原生架构审查：[项目名称]

### 总体评分摘要

| 核心原则 | 评分 | 百分比 | 状态 |
|----------------|-------|------------|--------|
| 动作对等 | X/Y | Z% | ✅/⚠️/❌ |
| 工具作为原语 | X/Y | Z% | ✅/⚠️/❌ |
| 上下文注入 | X/Y | Z% | ✅/⚠️/❌ |
| 共享工作空间 | X/Y | Z% | ✅/⚠️/❌ |
| CRUD 完整性 | X/Y | Z% | ✅/⚠️/❌ |
| UI 集成 | X/Y | Z% | ✅/⚠️/❌ |
| 能力发现 | X/Y | Z% | ✅/⚠️/❌ |
| 提示原生特性 | X/Y | Z% | ✅/⚠️/❌ |

**总体代理原生评分：X%**

### 状态图例
- ✅ 优秀（80%+）
- ⚠️ 部分（50-79%）
- ❌ 需改进（<50%）

### 按影响排名前 10 的建议

| 优先级 | 行动 | 原则 | 努力程度 |
|----------|--------|-----------|--------|

### 优秀之处

[列出前 5 个优势]

成功标准

  • [ ] 所有 8 个子代理完成审计
  • [ ] 每个原则有具体数值评分（X/Y 格式）
  • [ ] 总结表显示所有评分和状态指示器
  • [ ] 前 10 个建议按影响优先级排序
  • [ ] 报告识别优势和差距

可选：单一原则审计

如果 $ARGUMENTS 指定单一原则（例如“动作对等”），则仅运行该子代理并提供该原则的详细发现。

有效参数：

  • 动作对等 或 1
  • 工具 或 原语 或 2
  • 上下文 或 注入 或 3
  • 共享 或 工作空间 或 4
  • crud 或 5
  • ui 或 集成 或 6
  • 发现 或 7
  • 提示 或 特性 或 8