npm - @chongyan/autospec - Versions diffs - 1.0.2 → 1.0.4 - Mend

@chongyan/autospec 1.0.2 → 1.0.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (688) hide show

package/knowledge/08-organization/00-vision-mission.md DELETED Viewed

@@ -1,113 +0,0 @@
-# AutoSpec 愿景与使命
-> **定位**: 组织层的纲领性文件，定义 AutoSpec 项目的愿景、使命和核心价值观
->
-> **进化分区**: 🟡 受控区（自动提议 + 人工批准）
----
-## 愿景 (Vision)
-**让 AI 成为可靠的研发伙伴，释放人类创造力**
-我们相信 AI 不应该替代人类，而是成为人类最可靠的协作伙伴。通过承担重复性、确定性的研发工作，AI 让人类从繁琐的编码任务中解放出来，专注于真正需要创造力和战略思维的高价值工作。
----
-## 使命 (Mission)
-**构建无人值守的自动化产品研发框架，通过 AI 驱动完整 SDLC，人类专注于高价值决策**
-AutoSpec 的使命是实现"Human On the Loop"（人类在环上）而非"Human In the Loop"（人类在环内）的协作模式：
-- **AI 负责**: 需求分析、方案设计、编码实现、代码审查、测试验证、交付部署
-- **人类负责**: 方向决策、安全确认、价值判断、异常处理
----
-## 核心价值观 (Core Values)
-### 1. 验证为王 (Verification First)
-**确定性验证 > AI 审查 > AI 自审**
-- 所有 AI 产出必须经过确定性验证（编译、测试、lint）
-- Layer 1 验证不通过，不进入 Layer 2 审查
-- 验证是质量的唯一标准，不是可选项
-### 2. 极简实用 (Minimal Viable Process)
-**能一个文件说清的不拆两个**
-- 5 分钟上手，按复杂度动态调整
-- 拒绝过度设计，追求刚好够用
-- 维护成本远低于收益时，才引入新机制
-### 3. 渐进自主 (Progressive Autonomy)
-**从"人审每步"到"人只管 harness"**
-- AI 先在受约束领域证明可靠
-- 通过双层验证建立信任
-- 逐步扩大 AI 自主决策边界
-### 4. 安全优先 (Safety First)
-**15 条宪法红线，不可逆操作人工确认**
-- 安全漏洞/数据丢失/3 次修不好 → 立即停线
-- DB 迁移、部署、外部 API → 必须人工确认
-- 进化系统不可修改自己的评判标准
-### 5. 持续进化 (Continuous Evolution)
-**三层自进化体系，实战经验自动回流**
-- L1 Self-Evolve: 框架自身的迭代升级
-- L2 Field-Evolve: 从实战项目中学习和提炼
-- L3 Project-Evolve: 实战项目自身的优化
----
-## 原则应用
-### 按场景应用
-| 场景 | 适用价值观 | 应用方式 |
-|------|-----------|---------|
-| **需求分析** | 极简实用 | 不多问，用 CEO 探索机制自动澄清 |
-| **方案设计** | 验证为王 | 设计方案必须可验证 |
-| **编码实现** | 渐进自主 | AI 自主实现，人类抽检 |
-| **代码审查** | 安全优先 | 做审分离，独立 Agent 审查 |
-| **错误修复** | 持续进化 | 记录 practice-log，触发进化 |
-| **框架改进** | 持续进化 | 三层自进化体系 |
-### 决策检查清单
-**重大决策前**:
-- [ ] 这个决策符合我们的愿景吗？
-- [ ] 这个决策服务于我们的使命吗？
-- [ ] 这个决策与核心价值观一致吗？
-**重大决策后**:
-- [ ] 决策结果可以追溯吗？
-- [ ] 有验证机制确保执行质量吗？
-- [ ] 有安全护栏防止意外吗？
----
-## 关联文档
-| 文档 | 说明 |
-|------|------|
-| [principles/01-first-principles.md](../principles/01-first-principles.md) | L1 第一性原则 |
-| [principles/09-constitution.md](../principles/09-constitution.md) | 项目宪法（15 条红线） |
-| [principles/10-evolution-mechanism.md](../principles/10-evolution-mechanism.md) | 自进化机制 |
-| [01-ai-native-culture.md](01-ai-native-culture.md) | AI Native 团队文化 |
-| [03-committee-structure.md](03-committee-structure.md) | 治理委员会架构 |
----
-**维护者**: AutoSpec 团队
-**进化分区**: 🟡 受控区
-**版本**: v1.0
-**最后更新**: 2026-03-27

package/knowledge/08-organization/01-ai-native-culture.md DELETED Viewed

@@ -1,318 +0,0 @@
-# AI Native 团队文化手册
-> 本手册定义 AI Native 团队的文化原则、工作方式和协作规范。
-> 与 `principles/03-constitution.md` 互补，宪法红线在此同样生效。
-## 核心理念
-AI Native 团队不是"使用 AI 的团队"，而是"以 AI 为核心设计工作流的团队"。
-### AI Native 四原则
-| 原则 | 描述 | 实践 |
-|------|------|------|
-| **AI 思维贯穿** | 每个角色都具备 AI 思维特质，不只是 AI 工程师 | 产品经理懂 AI 能力边界，工程师会用 AI 辅助编程 |
-| **数据驱动** | 决策有数据支撑，效果有评测验证 | 需求有用户数据，AI 功能有效果评测 |
-| **快速验证** | AI 功能先验证可行性再大规模开发 | MVP → 验证 → 迭代，不盲目铺量 |
-| **人机协作** | 明确 AI 与人各自擅长的领域 | AI 负责实现，人负责验收和决策 |
----
-## 工作模式
-### 1. Vibe Coding（ vibe 编程）
-> 核心理念：自然语言描述需求，AI 生成代码，人类验收。
-**传统模式 vs Vibe Coding**：
-| 维度 | 传统模式 | Vibe Coding |
-|------|---------|-------------|
-| 需求表达 | 写 PRD、User Story | 自然语言描述 + 示例 |
-| 代码实现 | 人类工程师编写 | AI 生成 |
-| 人类角色 | 实现者 + 审查者 | 验收者 + 架构师 |
-| 关注点 | 怎么实现 | 要什么效果 |
-**Vibe Coding 流程**：
-```
-1. 需求澄清
-   ↓
-2. 自然语言描述 + 示例
-   ↓
-3. AI 生成代码（可多轮迭代）
-   ↓
-4. 人类验收（功能 + 性能 + 安全）
-   ↓
-5. 通过 → 提交 | 不通过 → 反馈给 AI 修复
-```
-**适用场景**：
-- 功能明确、边界清晰的需求
-- 重复性 CRUD 页面
-- 测试用例生成
-- 文档生成
-**不适用场景**：
-- 架构决策
-- 安全敏感逻辑
-- 性能关键路径
-- 全新技术领域
-### 2. AI 结对编程
-> 核心理念：AI Agent 作为"第二开发者"，与人类工程师协同工作。
-**角色分工**：
-| 角色 | 职责 |
-|------|------|
-| **人类工程师** | 架构决策、Code Review、复杂问题解决 |
-| **AI 开发者** | 代码实现、测试生成、文档编写、Bug 修复 |
-**协作模式**：
-```
-人类工程师
-    │
-    ├──→ 需求描述
-    │         ↓
-    ←── AI 产出 ←── AI 开发者实现
-    │
-    ├──→ 反馈/修正
-    │         ↓
-    ←── 修订版 ←── AI 开发者修复
-    │
-    └──→ 最终验收
-```
-**关键原则**：
-- AI 产出必须经过人类审查
-- 复杂逻辑人类先行设计，AI 填充实现
-- 安全相关代码人类重点审查
-### 3. 多代理审查系统
-> 核心理念：并行启动多个专业审查 Agent，从不同角度审查代码。
-借鉴 Anthropic Claude Code 的实践：
-```
-┌─────────────────────────────────────┐
-│         Code Review Pipeline        │
-├─────────────────────────────────────┤
-│  并行启动多个审查 Agent：            │
-│  ├── 架构审查 Agent                 │
-│  ├── 安全审查 Agent                 │
-│  ├── 性能审查 Agent                 │
-│  ├── 可维护性审查 Agent              │
-│  └── 逻辑审查 Agent                 │
-├─────────────────────────────────────┤
-│  汇总审查结果                       │
-│  ├── 一致通过项                     │
-│  ├── 分歧项                         │
-│  └── 必须修复项                     │
-├─────────────────────────────────────┤
-│  人类最终确认                       │
-└─────────────────────────────────────┘
-```
-**审查维度**：
-| 维度 | 检查内容 |
-|------|---------|
-| 架构 | 模块划分、依赖关系、扩展性 |
-| 安全 | 注入漏洞、越权、敏感数据 |
-| 性能 | 复杂度、N+1、缓存策略 |
-| 可维护性 | 代码重复、命名、注释 |
-| 逻辑 | 业务逻辑正确性、边界条件 |
----
-## 角色转变
-### 从"实现者"到"验收者"
-| 传统角色 | AI Native 角色 |
-|---------|--------------|
-| 写代码 | 描述需求 + 验收代码 |
-| 解决 bug | 指导 AI 定位 + 验证修复 |
-| 写测试 | 审查 AI 生成的测试 |
-| 写文档 | 审核 AI 生成的文档 |
-### 各角色 AI Native 视角
-#### CEO / 创始人
-- 战略决策考虑 AI 能力边界
-- 识别 AI 带来的新机会
-- 评估 AI 投资回报率
-#### 产品经理
-- 理解 AI 能力边界，不过度承诺
-- 用自然语言表达需求
-- 设计 AI 可理解的验收标准
-#### 技术负责人
-- AI 架构思维，评估 AI 方案可行性
-- 设计人机协作流程
-- 建立 AI 效果评测体系
-#### 工程师
-- AI 集成思维，API 设计考虑 AI 调用
-- 掌握 AI 辅助编程工具
-- 审查 AI 生成的代码
-#### AI 工程师
-- 模型选型与 Prompt 工程
-- AI 效果优化
-- AI 与业务系统的集成
----
-## 决策流程
-### AI 参与决策的边界
-| 决策类型 | AI 角色 | 人类角色 |
-|---------|--------|---------|
-| 需求澄清 | 主导（11维扫描） | 确认 |
-| 技术方案 | 建议（多方案生成） | 选择 |
-| 代码实现 | 主导 | 验收 |
-| 安全决策 | 辅助（扫描） | 主导 |
-| 架构决策 | 建议 | 主导 |
-| 部署决策 | 风险评估 | 确认 |
-### 人机协作决策树
-```
-决策点
-  │
-  ├── 安全敏感？
-  │    ├── 是 → 人类主导，AI 辅助
-  │    └── 否 → 继续
-  │
-  ├── 可逆决策？
-  │    ├── 是 → AI 主导，人类抽检
-  │    └── 否 → 继续
-  │
-  └── 影响范围大？
-       ├── 是 → 人类确认
-       └── 否 → AI 自主
-```
----
-## 团队能力要求
-### 技能矩阵
-| 角色 | AI 基础技能 | AI 进阶技能 |
-|------|------------|------------|
-| 产品 | AI 需求表达、AI 效果评估 | AI 方案评估 |
-| 工程师 | AI 辅助编程、AI 代码审查 | AI 架构设计 |
-| AI 工程师 | Prompt 工程、模型调优 | AI 系统设计 |
-| 管理者 | AI 团队管理、AI 投资评估 | AI 战略规划 |
-### 培训体系
-1. **入门**：AI 辅助编程工具使用
-2. **进阶**：AI 代码审查与质量控制
-3. **专家**：AI 架构设计与团队赋能
----
-## 实践指南
-### 1. AI 需求表达
-好的需求描述：
-```
-"用户登录后展示订单列表，每个订单显示：
-- 订单号（订单号格式：ORD-YYYYMMDD-XXXX）
-- 下单时间（格式：YYYY-MM-DD HH:mm）
-- 订单金额
-- 订单状态（待支付/已支付/已完成/已取消）
-点击订单跳转到订单详情页。"
-→ AI 可直接生成完整功能
-```
-差的需求描述：
-```
-"做一个订单功能"
-→ AI 需要多次澄清，效率低
-```
-### 2. AI 代码验收清单
-- [ ] 功能完整性：需求中的每个点都有实现
-- [ ] 边界条件：空值、异常、超长都有处理
-- [ ] 性能合理：没有明显的性能问题
-- [ ] 安全合规：没有注入、越权等漏洞
-- [ ] 代码质量：命名清晰，逻辑可读
-### 3. AI 反馈技巧
-| 场景 | 反馈方式 |
-|------|---------|
-| 功能不对 | "期望行为是 X，实际是 Y" |
-| 风格不对 | "参考现有代码风格：..." |
-| 效率低 | "需要优化性能，参考：..." |
-| 边界漏了 | "还需要处理 X 情况" |
----
-## 与现有流程集成
-### 与 6 阶段流程的对应
-| 阶段 | AI 增强点 |
-|------|----------|
-| 需求分析 | AI 辅助需求澄清、竞品分析 |
-| 方案设计 | AI 辅助架构设计、API 推导 |
-| 编码实现 | Vibe Coding、AI 结对编程 |
-| 测试验证 | AI 测试生成、AI 异常检测 |
-| 部署交付 | AI 部署风险评估 |
-| 归档复盘 | AI 辅助 practice-log 分析 |
-### 与双层验证的集成
-- **Layer 1**：AI 辅助的自动化验证
-- **Layer 2**：多代理 AI 审查 + 人类确认
----
-## 反模式
-### 1. 盲目信任 AI
-- 表现：不审查 AI 产出，直接提交
-- 后果：安全漏洞、质量问题
-- 纠正：所有 AI 产出必须经过验收
-### 2. 过度依赖 AI
-- 表现：所有问题都交给 AI，不自己思考
-- 后果：失去技术判断力
-- 纠正：复杂问题人类先思考，AI 填充实现
-### 3. AI 能力过高估计
-- 表现：给 AI 无法完成的任务
-- 后果：产出质量差，返工多
-- 纠正：明确 AI 能力边界，选择合适场景
-### 4. AI 能力过低估计
-- 表现：能 AI 做的还人工做
-- 后果：效率低，浪费资源
-- 纠正：持续学习 AI 新能力，迭代工作流

package/knowledge/08-organization/02-team-metrics.md DELETED Viewed

@@ -1,228 +0,0 @@
-# 团队度量体系
-> 本文档定义 AI Native 团队的度量指标体系。
-> 与 [01-ai-native-culture.md](01-ai-native-culture.md) 互补。
-## 概述
-AI Native 团队的度量体系需要同时衡量：
-1. **AI 能力**：AI 在团队中的参与度和效果
-2. **流程效率**：研发流程的效率和质量
-3. **产出质量**：最终交付物的质量
----
-## 一、AI 能力指标
-### 1.1 AI 参与度指标
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 代码占比** | AI 参与生成的代码占总代码量比例 | AI 生成行数 / 总代码行数 | > 40% |
-| **AI 审查覆盖率** | AI 审查覆盖的变更比例 | AI 审查次数 / 总变更次数 | 100% |
-| **AI 测试覆盖率** | AI 生成的测试占总测试比例 | AI 生成测试数 / 总测试数 | > 60% |
-### 1.2 AI 质量指标
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 首次通过率** | AI 生成的代码一次通过审查的比例 | 一次通过次数 / AI 生成提交次数 | > 70% |
-| **AI 修复效率** | AI 修复问题的平均次数 | 修复总次数 / 问题数 | < 2 次 |
-| **AI 误报率** | AI 审查中误报的比例 | 误报数 / 总报告数 | < 15% |
-### 1.3 AI 效率指标
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 响应时间** | AI 从请求到响应的时间 | 平均响应时间 | < 30s |
-| **AI 并行度** | 同时运行的 AI 任务数 | 峰值并发数 | > 5 |
-| **AI 成本效率** | 每单位成本的 AI 产出 | 代码行数 / AI 成本 | 持续优化 |
----
-## 二、流程效率指标
-### 2.1 阶段效率指标
-| 阶段 | 指标 | 定义 | 目标 |
-|------|------|------|------|
-| 需求分析 | 需求澄清效率 | 需求到澄清完成的时间 | < 4h |
-| 方案设计 | 设计完成率 | 按计划完成设计的比例 | > 90% |
-| 编码实现 | 代码交付速度 | 每日提交行数 | 符合估算 |
-| 代码审查 | 审查响应时间 | 发起审查到首次响应 | < 4h |
-| 测试验证 | 测试通过率 | 首次提交测试通过率 | > 80% |
-| 交付部署 | 部署成功率 | 首次部署成功比例 | > 95% |
-### 2.2 迭代效率指标
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **周期时间** | 从需求到交付的总时间 | 交付时间 - 需求确认时间 | 持续缩短 |
-| **前置时间** | 需求确认到开始开发 | 开始时间 - 确认时间 | < 1 工作日 |
-| **批量大小** | 平均每次交付的需求数 | 交付需求数 / 交付次数 | 1-3 个 |
-| **在制品数量** | 同时进行的需求数 | 平均并行需求数 | < 5 个 |
-### 2.3 阻塞指标
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **阻塞率** | 被阻塞的阶段比例 | 阻塞次数 / 阶段总数 | < 10% |
-| **阻塞时长** | 平均阻塞时间 | 阻塞总时长 / 阻塞次数 | < 4h |
-| **升级率** | 需要人工介入的比例 | 升级次数 / 总任务数 | < 5% |
----
-## 三、质量指标
-### 3.1 代码质量指标
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **缺陷密度** | 每千行代码的缺陷数 | < 1 个/千行 |
-| **代码覆盖率** | 被测试覆盖的代码比例 | > 80% |
-| **技术债务比** | 技术债务与代码总量比 | < 5% |
-| **代码重复率** | 重复代码的比例 | < 3% |
-### 3.2 审查质量指标
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **审查通过率** | 首次提交通过审查的比例 | > 70% |
-| **审查意见数** | 平均每次审查的意见数 | 5-15 条 |
-| **审查时间** | 从提交到通过的平均时间 | < 1 工作日 |
-### 3.3 交付质量指标
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **线上缺陷率** | 线上发现的缺陷数 | < 2 个/版本 |
-| **回滚率** | 需要回滚的部署比例 | < 2% |
-| **P0 故障数** | 严重故障数量 | 0 |
----
-## 四、团队健康指标
-### 4.1 协作健康
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **任务完成率** | 按计划完成的任务比例 | > 90% |
-| **返工率** | 需要返工的任务比例 | < 10% |
-| **沟通成本** | 会议时间占比 | < 15% |
-### 4.2 成长健康
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **技能增长率** | 新技能掌握速度 | 持续提升 |
-| **知识分享数** | 团队分享次数 | 每周 > 2 次 |
-| **自动化程度** | 自动化任务占比 | 持续提升 |
----
-## 五、度量采集
-### 5.1 自动采集
-| 数据源 | 采集内容 | 频率 |
-|--------|---------|------|
-| Git | 提交、审查、合并数据 | 实时 |
-| CI/CD | 构建、测试、部署数据 | 实时 |
-| 项目管理 | 任务流转、阻塞数据 | 实时 |
-| 监控 | 线上质量数据 | 实时 |
-### 5.2 手动采集
-| 数据源 | 采集内容 | 频率 |
-|--------|---------|------|
-| 回顾会 | 团队反馈、改进建议 | 每周 |
-| 调查问卷 | 团队满意度 | 每月 |
-| 一对一 | 个人成长、挑战 | 每月 |
----
-## 六、度量看板
-### 6.1 核心看板
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    AI Native 团队度量看板                    │
-├─────────────────────────────────────────────────────────────┤
-│                                                             │
-│  AI 能力                    流程效率              质量       │
-│  ┌──────────┐            ┌──────────┐        ┌────────┐ │
-│  │AI代码占比 │            │周期时间   │        │缺陷密度│ │
-│  │   45%    │            │   5天    │        │ 0.8    │ │
-│  │   ↑5%    │            │   ↓1天   │        │  ↓0.2  │ │
-│  └──────────┘            └──────────┘        └────────┘ │
-│                                                             │
-│  ┌──────────┐            ┌──────────┐        ┌────────┐ │
-│  │AI首次通过 │            │审查响应   │        │覆盖率  │ │
-│  │   75%    │            │   3h     │        │  85%   │ │
-│  │   ↑10%   │            │   ↓1h    │        │  ↑5%   │ │
-│  └──────────┘            └──────────┘        └────────┘ │
-│                                                             │
-└─────────────────────────────────────────────────────────────┘
-```
-### 6.2 趋势分析
-| 指标 | 周环比 | 月环比 | 季度趋势 |
-|------|-------|-------|---------|
-| AI 代码占比 | +3% | +8% | ↑ |
-| 周期时间 | -0.5天 | -1天 | ↓ |
-| 缺陷密度 | -0.1 | -0.3 | ↓ |
----
-## 七、目标设定
-### 7.1 短期目标（1-3个月）
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 30% | 40% |
-| AI 首次通过率 | 60% | 70% |
-| 审查响应时间 | 6h | 4h |
-### 7.2 中期目标（3-6个月）
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 40% | 50% |
-| 周期时间 | 5天 | 3天 |
-| 缺陷密度 | 0.8 | 0.5 |
-### 7.3 长期目标（6-12个月）
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 50% | 60% |
-| 自动化程度 | 70% | 90% |
-| 线上缺陷率 | 1.5 | < 1 |
----
-## 八、持续优化
-### 8.1 度量评审
-- **周度**：查看核心指标趋势
-- **月度**：分析目标达成情况
-- **季度**：调整目标和策略
-### 8.2 改进闭环
-```
-发现 → 分析 → 制定 → 执行 → 验证
-  ↑______________________________↓
-```
-### 8.3 注意事项
-1. **不追求完美指标**：指标是工具，不是目的
-2. **关注趋势**：比关注绝对值更重要的是趋势
-3. **避免过度度量**：度量有成本，聚焦关键指标
-4. **结合定性分析**：定量 + 定性 = 完整画像

package/knowledge/08-organization/03-committee-structure.md DELETED Viewed

@@ -1,54 +0,0 @@
-# 治理委员会架构
-> 公司治理团队架构定义
-## 委员会组成
-### 技术委员会（Tech Committee）
-| 成员 | 角色 | 职责 |
-|------|------|------|
-| 技术负责人 | 召集人 | 技术决策、架构评审 |
-| 安全工程师 | 成员 | 安全评审 |
-| 运维工程师 | 成员 | 运维质量 |
-### 质量委员会（Quality Committee）
-| 成员 | 角色 | 职责 |
-|------|------|------|
-| 质量工程师 | 召集人 | 质量标准、流程优化 |
-| 技术负责人 | 成员 | 技术质量 |
-| 运维工程师 | 成员 | 部署质量 |
-### 战略委员会（Strategy Committee）
-| 成员 | 角色 | 职责 |
-|------|------|------|
-| CEO | 召集人 | 战略方向 |
-| 产品负责人 | 成员 | 产品战略 |
-| 技术负责人 | 成员 | 技术战略 |
-## 决策权限
-| 决策类型 | 负责委员会 | 决策方式 |
-|----------|-----------|----------|
-| 技术架构 | 技术委员会 | 多数投票 |
-| 质量标准 | 质量委员会 | 多数投票 |
-| 战略方向 | 战略委员会 | CEO最终决策 |
-| 紧急问题 | 召集人 | 快速决策 |
-## 会议频率
-| 委员会 | 频率 | 时长 |
-|--------|------|------|
-| 技术委员会 | 每周 | 30分钟 |
-| 质量委员会 | 每周 | 30分钟 |
-| 战略委员会 | 每月 | 60分钟 |
-## 治理Agent
-| Agent | 职责 |
-|-------|------|
-| 治理监测Agent | 每日扫描指标，识别异常 |
-| 治理分析Agent | 分析根因，生成提案 |
-| 治理协调Agent | 协调评审，跟踪执行 |