AI Agent技能工程多Agent对抗设计系统安全审计

从三个顶级Agent项目中提取设计模式，强化Hermes技能体系

三个项目，三个可以偷的思路

2026年6月，Agent生态里有三个项目值得深挖：Google的DESIGN.md规范（设计系统标准化）、ai-berkshire（多大师Agent对抗投资分析）、gstack（Garry Tan的23角色虚拟工程团队）。

这三个项目的共同点：它们不是又一个框架或SDK，而是把人类团队的最佳实践编码成Agent可执行的结构化流程。

本文记录了如何从这三个项目中提取核心设计模式，集成到Hermes的三个技能中。

一、DESIGN.md：让Agent理解品牌设计系统

问题

claude-design技能在生成HTML时，工作流第二步说”读取项目文件、设计资产”。但这太泛了——实际执行时，Agent经常跳过已有设计系统，从头发明颜色和字体。

DESIGN.md做了什么

Google的DESIGN.md规范定义了一种文件格式：YAML frontmatter存精确token值 + Markdown正文存设计理由。

---
name: Heritage
colors:
  primary: "#1A1C1E"
  tertiary: "#B8422E"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
---

Agent读到这个文件后，生成的UI就会用Deep Ink色做标题、Boston Clay色做按钮——不再凭空发明。

集成方案

在claude-design的设计流程前，增加一个Step 0自动检测层：

Step 0: DESIGN.md Auto-Detection
├── 1. 检查项目根目录 DESIGN.md → 解析YAML tokens
├── 2. 检查 tokens.json (W3C DTCG)
├── 3. 检查 tailwind.config.js → 提取 theme
├── 4. 检查 variables.css → 提取 CSS自定义属性
└── 找到 → 用token值verbatim生成CSS，不发明新值
    未找到 → 进入正常设计流程

关键规则：如果DESIGN.md存在，所有生成的CSS必须使用其token值。 与DESIGN.md冲突时， surfaced conflict 并询问用户，而不是默默覆盖。

这个改动只有15行，但从根本上改变了Agent的行为——从”每次发明”变成”先读规范再动手”。

二、ai-berkshire：多Agent对抗 → 因子评审

问题

factor-cross-review技能原来用的是单Agent自我审视模式：同一个Agent先做判断，再回头找自己的漏洞。这就像让学生先答题再自己批改——天然倾向于给自己高分。

ai-berkshire做了什么

ai-berkshire的核心创新不是”用AI分析股票”，而是四个独立Agent各自扮演一位价值投资大师，产生真实的观点对抗。

以拼多多为例：

  • 段永平视角（商业模式）：好生意，C2M难复制 → 3.7分
  • 巴菲特视角（财务估值）：扣现金PE仅6.3x，印钞机 → 4.4分
  • 芒格视角（逆向思考）：护城河比想象浅 → 3.5分
  • 李录视角（长期确定性）：管理层有隐患 → 2.0分

巴菲特说”真便宜”，李录说”不确定就不买”——这种冲突才是避免盲点的关键。

此外，ai-berkshire还有一套8条快速否决清单：管理层诚信污点 → 直接否决，不管估值多便宜。这比任何深度分析都更有效地防止灾难性决策。

集成方案

将因子评审从”单Agent串行”改为Bull/Bear双Agent并行对抗。

Phase 1：8条快速否决清单（优先于一切）

在做任何Agent分析之前，先用Python脚本逐条检查：

检查项否决阈值理由
IC方向在牛熊期翻转翻转即否决因子在regimes间不稳定
样本量不足小于250个交易日统计显著性不够
单调性检验失败分5档不单调因子区分度不够
Turnover过高大于200%年化交易成本吃掉收益
IC波动率过大std/abs(mean) 大于2.0IC不稳定
前视偏差因子在回测起点前不可计算数据泄露
与已有因子高相关绝对值大于0.8信息冗余
Walk-forward衰减IC衰减大于50%因子样本外失效

任何一条命中 → 直接否决，不进入对抗流程。省算力，防灾难。

Phase 2：双Agent并行对抗

使用delegate_task同时派出两个子Agent：

**Bull Agent（因子确认方）**的任务：

  • 找出3个采用此因子的理由
  • 必须引用具体IC/IR数据，不接受”看起来不错”
  • 必须回答：这个因子捕捉了什么alpha来源？为什么市场还没套利掉？
  • 给出仓位建议和置信度评分

**Bear Agent（因子攻击方）**的任务：

  • 找出3个不采用此因子的理由
  • 必须检查：前视偏差、幸存者偏差、过拟合、数据挖掘
  • 必须检查：IC是否只在特定时间段集中贡献
  • 每个攻击点标注 Critical / Warning / Minor

两个Agent完全独立，互不知晓对方输出。

Phase 3：Judge合并裁决

裁决规则（严格优先级）：

  1. Bear Agent找到任何Critical级攻击 → 默认否决
  2. Bull置信度低于5 → 否决
  3. Bear所有攻击均为Minor + Bull置信度大于等于7 → 采用
  4. 其他 → 灰色地带，要求补充实验

Judge默认偏向保守——有疑虑时选择”放弃”而非”试试看”。

为什么这比单Agent评审更好

单Agent自我审视的结构性缺陷是确认偏差：一旦Agent做出”采用”的初步判断，后续的”自我评审”会不自觉地为自己的判断找理由。

双Agent对抗消除了这个问题：Bear Agent的唯一目标就是攻击，它没有”保护自己之前判断”的心理负担。这比让同一个Agent”既要又要”有效得多。

三、gstack：角色化工作流 → 开发生命周期

问题

development-lifecycle技能原来是6阶段流水线（Spec → Plan → Build → Test → Review → Ship）。Review阶段只有基础安全扫描（硬编码密钥、SQL注入），缺乏独立的深度安全审计和架构评审。

gstack做了什么

Garry Tan（YC CEO）的gstack把Claude Code变成23个专家角色，核心创新是每个角色有独立的检查视角和工具链。

两个最值得借鉴的角色：

  • /cso（Chief Security Officer）— OWASP Top 10 + STRIDE威胁建模，每个发现附带具体exploit场景
  • /plan-eng-review（Eng Manager）— ASCII数据流图、错误路径分析、测试矩阵、状态机

gstack的核心理念是：并行扇出评审。不是一个Reviewers看所有维度，而是不同专家各看各的领域。

集成方案

在6阶段基础上增加两个显式阶段，将流水线从6阶段扩展到8阶段：

阶段2b：Architecture Review（架构评审）

触发条件：改动超过3个文件 OR 新增外部依赖 OR 涉及数据库/API变更。

8项检查清单：

  1. 数据流图：输入到输出的完整路径
  2. 错误路径：每个外部调用有fallback/timeout/retry
  3. 状态机：并发/异步无死锁
  4. 向后兼容：API/DB schema变更不破坏现有调用
  5. 可观测性：日志覆盖关键路径
  6. 测试矩阵：正常/边界/异常/并发四种场景
  7. 性能基线：预期QPS/延迟/内存
  8. 依赖审查：新增依赖是否必要

阶段5b：Security Audit（深度安全审计）

触发条件：diff超过100行 OR 涉及认证/数据库/外部API/配置文件。

OWASP Top 10快速检查覆盖注入漏洞、认证管理、XSS、权限提升、敏感数据泄露等10个维度。

对于复杂功能（支付/认证/数据管道），追加STRIDE威胁建模：

威胁类型检查问题
Spoofing（身份伪造）JWT密钥是否泄露？API key是否硬编码？
Tampering（数据篡改）数据库写入有否权限校验？
Repudiation（抵赖）关键操作有否审计日志？
Information Disclosure错误信息是否暴露内部结构？
Denial of Service有否速率限制？大请求防御？
Elevation of Privilege角色检查是否在每个API端点？

审计结论三级：通过（0 Critical）、需修复后发布、阻止发布（2+ Critical）。

为什么不直接装gstack

gstack的23个角色对个人开发者来说太重了。它的设计假设是一个团队在用，需要CEO、设计师、QA等多角色的协作流程。

个人开发者的实际需求更精简：大部分代码不需要CEO级别的产品反思，但涉及安全和架构的改动必须有独立审查。所以只提取了两个最高价值的角色（安全审计 + 架构评审），嵌入既有流水线，而不是全盘照搬。

三项改动的共性

这三个集成看起来领域不同（设计/量化/工程），但遵循同一个方法论：

  1. 找到核心机制，不是照搬工具 — DESIGN.md的本质是”让Agent先读规范再动手”，不是YAML格式本身；ai-berkshire的本质是”对抗产生真相”，不是巴菲特的名言
  2. 结构化清单优于自由判断 — 8条快速否决清单比”请仔细分析风险”有效10倍；OWASP Top 10比”检查安全问题”更有执行力
  3. 独立视角优于自我审视 — 不管是Bull/Bear对抗还是Security Audit独立阶段，核心都是用不同的Agent/角色打破单一视角的盲点

这三个原则比任何具体实现都更重要。项目会过时，技能会迭代，但把人类团队的最佳实践编码成Agent可执行的结构化流程这个思路，是Agent工程的核心方法论。

完整变更清单

技能改动来源
factor-cross-review单Agent评审 → Bull/Bear双Agent并行对抗 + 8条快速否决清单ai-berkshire
development-lifecycle6阶段 → 8阶段（新增架构评审 + 安全审计）gstack
claude-design新增Step 0：DESIGN.md自动检测层Google DESIGN.md

💬 评论