Hermes 自进化Skill：让AI能力自己长出来

自进化Skill：让AI能力自己长出来

「Hermes Agent自进化智能体深度解析」系列 | 模块十 · 第2篇

你有没有想过，AI的能力能不能像生物一样自己进化？

不是你坐在那里一行行改配置、一个个调参数，而是它自己从失败中学习、从成功中提炼、从模式中觉醒------每一次执行都在让它变得更强。这不是科幻，这是Hermes Agent正在做的事情。

但现实是，今天绝大多数Agent的Skill都是静态的。你写好一个代码审查Skill，它审查了1000次代码，第1000次和第1次用的是完全相同的策略。遇到新的攻击手法？不知道。遇到新的框架规范？不知道。遇到团队成员已经变了代码风格？还是不知道。你只能人工发现这些盲区，手动去改Skill配置。改一个Skill尚且如此，当你有50个Skill在并行运行呢？哪个需要改？改成什么样？谁来改？改完会不会引入新问题？这就是静态Skill的死穴------它把人锁在了优化循环里，AI的能力天花板就是人的精力和认知带宽。

Hermes Agent给出的答案，是一个彻底打破这个死循环的机制：Self-Improving Skill------自进化Skill。它不是你写完就固定下来的死代码，而是一个活的、会呼吸的、持续从执行反馈中自我优化的能力单元。在上一篇#26中，我们拆解了七种Skill设计模式，其中最独特、最能代表Hermes"自进化"基因的，就是这种能够自主进化的Skill。今天，我们就来彻底拆解它的内部机制。

一、Self-Improving Skill的核心机制：一条永不闭合的进化链

自进化的本质是什么？是把"人观察→人分析→人修改"这个循环，变成"系统自动观察→系统自动分析→系统自动修改"。

在Hermes中，这条进化链的完整形态如下：

rust 复制代码

┌──────────────────────────────────────────────────────────────────┐
│                    Self-Improving Skill 闭环                      │
│                                                                    │
│   ┌──────────┐    ┌──────────┐    ┌──────────────┐               │
│   │  Skill   │───>│   执行    │───>│   结果验证    │               │
│   │  加载    │    │  Engine  │    │  Validation  │               │
│   └──────────┘    └──────────┘    └──────┬───────┘               │
│        ^                                  │                       │
│        │                                  v                       │
│   ┌──────────┐    ┌──────────┐    ┌──────────────┐               │
│   │  Skill   │<───│  策略优化  │<───│  模式识别    │               │
│   │  更新    │    │ Strategy │    │   Pattern    │               │
│   └──────────┘    └──────────┘    └──────┬───────┘               │
│        ^                                  │                       │
│        │                                  v                       │
│        │                           ┌──────────────┐              │
│        └───────────────────────────│  反馈采集    │              │
│                                    │  Feedback   │              │
│                                    └──────────────┘              │
│                                          ^                        │
│                                          │                        │
│                                    ┌─────────────┐               │
│                                    │  多源信号    │               │
│                                    │  (详见下文)  │               │
│                                    └─────────────┘               │
└──────────────────────────────────────────────────────────────────┘

注意，这不是一个一次性跑完就结束的流水线。它是一个持续运转的闭环------每一次Skill执行都在产生新的反馈信号，每一个信号都可能触发一次微小的策略调整，每一次调整都在让下一次执行更精准。

这条闭环的关键环节有四个：

反馈采集（Feedback Collection）：不是简单地记录"成功"或"失败"，而是从多个维度、多个来源采集结构化的反馈信号。

模式识别（Pattern Recognition）：不是看到一次失败就改，而是识别出"这确实是一个持续存在的模式"才触发进化。

策略优化（Strategy Optimization）：不是乱改一气，而是基于模式分析结果，有针对性地调整Skill的参数、步骤或组合方式。

验证更新（Validation & Update）：不是改完就上线，而是先在影子模式下验证改进效果，确认成功率提升后才正式更新。

二、进化引擎三层架构：从信号到进化的完整管道

Hermes的自进化能力不是一层黑魔法。它是一个设计精密的三层架构，每一层都有明确的职责和边界。

yaml 复制代码

┌─────────────────────────────────────────────────────────────┐
│                   Evolution Engine 三层架构                    │
│                                                               │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Layer 3: 策略优化层 Strategy Optimization              │  │
│  │  ┌───────────┐  ┌───────────┐  ┌──────────────────┐    │  │
│  │  │ 参数调优   │  │ 步骤增删   │  │ 组合重组          │    │  │
│  │  │ Threshold │  │ Steps +/-  │  │ Recombination    │    │  │
│  │  └───────────┘  └───────────┘  └──────────────────┘    │  │
│  └──────────────────────────┬──────────────────────────────┘  │
│                             │                                  │
│  ┌──────────────────────────┴──────────────────────────────┐  │
│  │  Layer 2: 模式识别层 Pattern Recognition                 │  │
│  │  ┌───────────┐  ┌───────────┐  ┌──────────────────┐    │  │
│  │  │ 失败模式   │  │ 成功模式   │  │ 跨Skill迁移      │    │  │
│  │  │ Failure   │  │ Success   │  │ Cross-Skill      │    │  │
│  │  └───────────┘  └───────────┘  └──────────────────┘    │  │
│  └──────────────────────────┬──────────────────────────────┘  │
│                             │                                  │
│  ┌──────────────────────────┴──────────────────────────────┐  │
│  │  Layer 1: 信号采集层 Signal Collection                   │  │
│  │  ┌───────────┐  ┌───────────┐  ┌──────────────────┐    │  │
│  │  │ 执行结果   │  │ Review    │  │ 用户反馈 / 性能   │    │  │
│  │  │ Results   │  │ Feedback  │  │ Signals          │    │  │
│  │  └───────────┘  └───────────┘  └──────────────────┘    │  │
│  └─────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Layer 1: 信号采集层（Signal Collection）

这是整个进化引擎的输入端。没有高质量的信号，就没有高质量的进化。

Hermes从以下五个核心渠道采集反馈信号：

信号来源	信号类型	示例
执行结果	客观结果数据	测试通过率、构建状态、部署成功率
Review反馈	主观评价数据	代码Review意见、设计Review打分
测试报告	结构化验证数据	单测覆盖率、安全扫描结果、性能基准
用户反馈	显式反馈信号	用户点赞/踩、修正操作、手动覆盖
性能数据	隐式反馈信号	执行耗时、资源消耗、重试次数

信号进来之后，不是一股脑全扔给进化引擎，而是先做分类和优先级排序：

yaml 复制代码

signal_classification:
  critical:
    description: "必须处理的信号，通常涉及安全性或核心功能"
    examples:
      - "安全扫描发现SQL注入漏洞被Skill遗漏"
      - "部署Skill导致生产环境故障"
    action: "立即触发进化流程，同步通知人工审核"
    
  important:
    description: "应该处理的信号，涉及效率或质量提升"
    examples:
      - "代码审查Skill连续3次给出相同的优化建议被忽略"
      - "测试Skill的重试率从5%上升到15%"
    action: "加入进化队列，在下一个进化周期处理"
    
  nice_to_have:
    description: "可以处理的信号，涉及体验优化"
    examples:
      - "Skill执行耗时比上周增加了10%"
      - "用户手动调整了Skill的输出格式"
    action: "记录但不主动触发进化，作为参考数据积累"

一个关键细节：Hermes会做信号的结构化。原始反馈往往是自然语言的，比如"这个代码审查漏了一个空指针异常"。信号采集层会将其结构化为：

yaml 复制代码

structured_signal:
  skill_id: "code_review_v3"
  signal_type: "missed_defect"
  severity: "critical"
  context:
    file_type: "java"
    pattern_category: "null_pointer"
    code_context: "optional chaining without null check"
  improvement_suggestion:
    action: "add_check_step"
    target_step: "security_scan"
    new_check: "null_reference_validation"
    priority: "high"

从模糊的人类反馈到精确的改进建议------这是信号采集层的核心价值。

Layer 2: 模式识别层（Pattern Recognition）

信号是零散的，模式是有意义的。这一层负责从海量的信号中发现真正值得进化的模式。

失败模式识别：

不是一次失败就触发进化------那样会导致系统频繁抖动。Hermes的规则是：连续3次在同类场景失败，触发进化流程。"同类场景"怎么定义？通过场景指纹（Scene Fingerprint）：

yaml 复制代码

pattern_detection:
  failure_rule:
    trigger: "same_scene_failures >= 3"
    scene_fingerprint:
      dimensions:
        - task_type        # 任务类型：code_review, deploy, test...
        - context_features # 上下文特征：语言、框架、文件类型...
        - error_category   # 错误类别：遗漏、误报、超时...
    example: |
      code_review Skill在 "java + database_operation" 场景下
      连续3次遗漏SQL注入检测 → 触发进化

成功模式提取：

同样，连续5次在同类场景成功，提炼为可复用策略。为什么要5次而不是3次？因为成功比失败更容易偶然发生，需要更多的样本才能确认这是稳定模式。

yaml 复制代码

pattern_detection:
  success_rule:
    trigger: "same_scene_successes >= 5"
    action: "extract_as_reusable_strategy"
    example: |
      code_review Skill在 "typescript + react_hooks" 场景下
      连续5次准确识别了useEffect内存泄漏 → 提炼为独立审查策略

跨Skill模式迁移：

这是Layer 2最强大的能力。当A Skill发现了某个成功模式，系统会自动评估这个模式能否迁移到B Skill：

yaml 复制代码

cross_skill_transfer:
  source: "code_review"
  pattern: "dependency_version_conflict_detection"
  transfer_candidates:
    - skill: "dependency_update"
      relevance: 0.92
      action: "apply_with_adaptation"
    - skill: "ci_pipeline"
      relevance: 0.78
      action: "suggest_for_review"
    - skill: "documentation"
      relevance: 0.31
      action: "skip"

注意relevance评分------不是所有模式都能迁移。只有相关性超过0.8的模式才会被自动应用，0.5-0.8的会建议人工审核，低于0.5的直接跳过。

Layer 3: 策略优化层（Strategy Optimization）

模式识别出来之后，怎么改Skill？这就是策略优化层要做的事情。它有三种优化手段：

参数自动调优：调整Skill内部的阈值、权重、排序策略。比如代码审查Skill中"建议优先级"的阈值从0.6调到0.75，或者安全检查的权重从0.3提升到0.5。

步骤自动增删：发现遗漏的步骤就添加，识别冗余的步骤就删除。这是最激进的优化------因为它改变了Skill的执行流程。

组合自动重组：发现更高效的Skill组合方式。比如原来"代码审查→测试→部署"的三步流程，可能进化为"代码审查+安全扫描并行→智能测试→条件部署"的更优流程。

yaml 复制代码

strategy_optimization_example:
  skill: "code_review"
  before:
    steps:
      - syntax_check
      - style_check
      - logic_review
    parameters:
      security_weight: 0.3
      performance_weight: 0.2
      
  optimization:
    type: "step_addition"
    trigger: "failure_pattern: SQL_injection_missed_3x"
    action:
      add_step:
        name: "database_security_check"
        position: "after_logic_review"
        content: |
          Check for SQL injection patterns:
          - String concatenation in SQL queries
          - Unparameterized query execution
          - Dynamic table/column names from user input
      adjust_parameter:
        security_weight: 0.3 → 0.5
        performance_weight: 0.2 → 0.15
        
  after:
    steps:
      - syntax_check
      - style_check
      - logic_review
      - database_security_check    # 新增步骤
    parameters:
      security_weight: 0.5          # 调整权重
      performance_weight: 0.15

三、从失败到进化：一个完整的链路演示

让我们用一个真实的场景，走完从失败到Skill改进的完整链路。

场景：代码审查Skill（code_review_v3）在第47次执行时，漏掉了一个SQL注入漏洞。

Step 1 --- 信号采集：

yaml 复制代码

[Signal Collector] New signals detected:
├── Source: Review Agent
│   └── "code_review_v3 missed SQL injection in UserService.java:142"
│       Severity: CRITICAL
│
├── Source: Security Scanner  
│   └── "SQL injection vulnerability detected: unparameterized query"
│       Severity: CRITICAL
│
└── Source: Execution Metrics
    └── "code_review_v3 success_rate in db_operations: 67% (below threshold 85%)"
        Severity: IMPORTANT

Step 2 --- 模式识别：

yaml 复制代码

[Pattern Recognition Engine] Analyzing signals...
├── Scene Fingerprint: java + database_operation + security_scan
├── Historical Pattern:
│   ├── Failure #1 (Exec #23): Missed ORM injection in OrderService
│   ├── Failure #2 (Exec #35): Missed dynamic query in PaymentService  
│   └── Failure #3 (Exec #47): Missed SQL injection in UserService ← 当前
├── Pattern: CONSECUTIVE_DB_SECURITY_FAILURES (3/3 confirmed)
├── Root Cause: No dedicated database security check step
└── Decision: TRIGGER_EVOLUTION

Step 3 --- 策略优化：

系统分析出根因是Skill缺少专门的数据库安全检查步骤，自动生成优化方案：

yaml 复制代码

evolution_plan:
  skill_id: "code_review_v3"
  evolution_type: "step_addition"
  
  analysis:
    root_cause: "No dedicated database operation security check"
    affected_scenes: ["java", "python", "go"]  # SQL注入不限于Java
    confidence: 0.94
    
  changes:
    - action: "add_step"
      step_name: "database_security_check"
      position: "after:logic_review"
      conditions:
        - trigger: "file_contains_database_operations"
          detection: "regex: (SELECT|INSERT|UPDATE|DELETE|executeQuery|raw SQL)"
      
    - action: "adjust_parameter"
      parameter: "security_check_depth"
      value: "standard → deep"
      scope: "database_related_files"
      
    - action: "update_prompt"
      target: "review_checklist"
      addition: |
        When reviewing code that interacts with databases:
        - Verify all queries use parameterized statements
        - Check for string concatenation in SQL construction
        - Validate dynamic table/column names are whitelisted
        - Ensure ORM raw query methods are properly sanitized

  validation_plan:
    method: "shadow_mode"
    test_cases: 12   # 包含3个历史失败案例
    success_threshold: 0.90
    rollback_on_failure: true

Step 4 --- 验证与上线：

ini 复制代码

[Evolution Validator] Running shadow mode validation...
├── Test Case 1 (Historical Failure #23): PASSED ✓ (was FAILED)
├── Test Case 2 (Historical Failure #35): PASSED ✓ (was FAILED)  
├── Test Case 3 (Historical Failure #47): PASSED ✓ (was FAILED)
├── Test Case 4-12 (Regression Tests):   ALL PASSED ✓
├── Overall Success Rate: 94% (threshold: 90%) ✓
├── No Regressions Detected ✓
└── Decision: APPROVE FOR DEPLOYMENT

[Skill Registry] code_review_v3 → code_review_v3.1 deployed successfully
[Evolution Log] Evolution #48 recorded. Success rate: 67% → 94%

优化前后的Skill定义对比：

yaml 复制代码

# ═══════════════════════════════════════════════════
#  BEFORE: code_review_v3 (success rate: 67% on DB ops)
# ═══════════════════════════════════════════════════
skill:
  id: code_review_v3
  steps:
    - syntax_check
    - style_check
    - logic_review
    - performance_check
  parameters:
    security_weight: 0.3
    
# ═══════════════════════════════════════════════════
#  AFTER: code_review_v3.1 (success rate: 94% on DB ops)
# ═══════════════════════════════════════════════════
skill:
  id: code_review_v3.1
  steps:
    - syntax_check
    - style_check
    - logic_review
    - database_security_check    # ← 进化新增
    - performance_check
  parameters:
    security_weight: 0.5         # ← 进化调整
  evolution_metadata:
    version: "v3.1"
    evolved_from: "v3"
    evolution_trigger: "failure_pattern: SQL_injection_missed_3x"
    evolved_at: "2026-05-28T14:32:00Z"
    validated: true

从遗漏漏洞到自动修复，全程无人工介入。Skill自己完成了"发现问题→定位根因→生成方案→验证上线"的完整闭环。

四、进化度量体系：如何量化"变强了"

进化不是玄学，必须可度量。Hermes为每个Self-Improving Skill维护了一份完整的进化档案。

erlang 复制代码

╔══════════════════════════════════════════════════════════════╗
║          Skill Evolution Dashboard: code_review              ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  版本: v3.7                进化次数: 47                      ║
║  初始成功率: 72%           当前成功率: 94%                    ║
║  累计提升: +22%            平均进化周期: 3.2天                ║
║                                                              ║
║  进化来源分布:                                               ║
║  ├── 失败模式分析  ████████████████████████░░  62%           ║
║  ├── 成功模式提取  ████████░░░░░░░░░░░░░░░░░░  21%           ║
║  └── 跨Skill迁移   █████░░░░░░░░░░░░░░░░░░░░░  17%           ║
║                                                              ║
║  优化类型分布:                                               ║
║  ├── 参数调优      ██████████████████░░░░░░░░  45%           ║
║  ├── 步骤增删      █████████████░░░░░░░░░░░░░░  34%           ║
║  └── 组合重组      ████████░░░░░░░░░░░░░░░░░░░  21%           ║
║                                                              ║
║  跨Skill贡献:                                                ║
║  ├── 向 security_scan 迁移了 2 个审查策略                    ║
║  ├── 向 ci_pipeline 迁移了 1 个检查模式                      ║
║  ├── 向 deploy_guard 迁移了 1 个安全规则                     ║
║  ├── 向 test_generator 迁移了 1 个场景识别方法               ║
║  └── 向 doc_review 迁移了 1 个一致性检查策略                 ║
║                                                              ║
║  进化健康度:                                                 ║
║  ├── 回滚次数: 2 (4.3%)    稳定性: 优秀                     ║
║  ├── 上周进化次数: 3       节奏: 正常                        ║
║  └── 待处理信号: 1         积压: 低                          ║
║                                                              ║
╚══════════════════════════════════════════════════════════════╝

几个关键指标的解读：

初始成功率72% → 当前94%：22个百分点的提升，全部由自动进化贡献，零人工调优。

失败模式分析贡献62%的改进：这说明"从错误中学习"是最有效的进化路径。一个系统如果不敢面对失败、不能从失败中提取信号，就永远无法自我超越。

被5个其他Skill复用了审查策略：这是进化的网络效应------一个Skill的进化成果，会通过跨Skill迁移机制扩散到整个系统。

回滚率4.3%：有2次进化尝试导致了成功率下降，系统自动回滚。进化不是只有成功，关键是失败的代价要可控。

五、进化的边界：什么时候不能让AI自己来

自进化很强，但不能没有边界。Hermes定义了四条进化红线，任何一条被触碰，进化流程都会被暂停：

红线一：安全相关变更必须人工审核

yaml 复制代码

evolution_guardrail:
  rule: "security_related_change"
  condition: |
    evolution adds/modifies any step related to:
    - Authentication or authorization checks
    - Data encryption/decryption
    - Access control policies
    - PII handling procedures
  action: "require_human_approval"
  rationale: "安全策略的误改可能导致系统性风险，必须经过安全专家审核"

红线二：核心业务逻辑变更需领域专家确认

yaml 复制代码

evolution_guardrail:
  rule: "core_business_logic"
  condition: |
    evolution modifies steps that directly affect:
    - Financial calculation accuracy
    - Legal compliance checks
    - Medical diagnosis workflows
  action: "require_domain_expert_review"
  rationale: "业务逻辑的正确性优先于优化效率，领域专家的判断不可替代"

红线三：成功率下降超过阈值时自动回滚

yaml 复制代码

evolution_guardrail:
  rule: "regression_threshold"
  condition: "post_evolution_success_rate < pre_evolution_success_rate - 5%"
  action: "automatic_rollback"
  notification: "alert_to_skill_owner"
  rationale: "进化不应该让事情变得更糟，5%是允许的最大回退幅度"

红线四：进化频率限制

yaml 复制代码

evolution_guardrail:
  rule: "evolution_frequency"
  condition: "same_skill_evolution_count_per_day >= 1"
  action: "queue_for_next_day"
  rationale: |
    过于频繁的进化意味着系统不稳定。
    同一个Skill一天最多自动进化1次，避免"进化振荡"------
    今天改过来，明天改回去，后天又改过来。

这四条红线，把自进化框定在一个"大胆尝试、谨慎落地"的区间内。进化可以大胆假设，但上线必须小心求证。

六、震撼时刻：进化雪崩------一个初始改进引发的链式反应

以下是一个真实记录的"进化雪崩"事件：

erlang 复制代码

╔══════════════════════════════════════════════════════════════╗
║              Evolution Avalanche Event Log                   ║
║              2026-05-12 → 2026-05-15 (72 hours)             ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  T+0h   code_review v3.7 → v3.8                             ║
║         │  触发: 失败模式 (SQL注入遗漏)                       ║
║         │  改进: 新增database_security_check步骤             ║
║         │  成功率: 94% → 96%                                 ║
║         v                                                    ║
║  T+8h   security_scan v2.1 → v2.2                           ║
║         │  触发: 跨Skill迁移 (来自code_review的DB安全策略)    ║
║         │  改进: 增强SQL注入检测模型                         ║
║         │  检出率: 89% → 93%                                 ║
║         v                                                    ║
║  T+20h  deploy_guard v1.4 → v1.5                            ║
║         │  触发: 跨Skill迁移 (来自security_scan的安全规则)    ║
║         │  改进: 部署前DB变更安全检查增强                     ║
║         │  拦截率: 91% → 95%                                 ║
║         v                                                    ║
║  T+36h  test_generator v2.3 → v2.4                          ║
║         │  触发: 成功模式 (deploy_guard的新检查需要新测试)     ║
║         │  改进: 自动生成DB安全测试用例                       ║
║         │  覆盖率: 78% → 86%                                 ║
║         v                                                    ║
║  T+52h  ci_pipeline v3.1 → v3.2                             ║
║           触发: 跨Skill迁移 (来自test_generator的测试模式)    ║
║           改进: CI流水线新增DB安全测试阶段                    ║
║           流水线拦截准确率: 85% → 93%                        ║
║                                                              ║
║  ══════════════════════════════════════════════════════════  ║
║  整体系统成功率: 78% → 93%  (72小时内 +15%)                  ║
║  涉及Skill数: 5   链式进化层数: 5                             ║
║  人工干预: 0次    回滚: 0次                                   ║
║  ══════════════════════════════════════════════════════════  ║
║                                                              ║
╚══════════════════════════════════════════════════════════════╝

一个代码审查Skill的微小改进------新增了一个数据库安全检查步骤------在72小时内引发了5个Skill的链式进化。整个过程零人工干预，系统整体成功率从78%飙升到93%。

这就是自进化的网络效应：当每个Skill的进化成果都能被其他Skill感知和利用时，改进就不再是线性的，而是指数级的。一个节点的觉醒，带动整个网络的进化。

传统Agent系统中，你要实现这种效果，需要5个团队分别优化各自的模块，协调会议开不完，集成测试跑不完。在Hermes中，系统自己完成了这一切。

七、总结：能力不是写出来的，是长出来的

Self-Improving Skill的本质，是把AI能力的增长从"人工编写→固定运行"的静态模式，转变为"持续执行→自动进化→越用越强"的动态模式。

回顾今天拆解的核心架构：

三层进化引擎：信号采集→模式识别→策略优化，从原始反馈到Skill改进的完整管道
进化闭环：执行→验证→反馈→识别→优化→更新，一个永不停歇的自我强化循环
进化边界：四条红线确保自进化在安全可控的范围内运行
网络效应：跨Skill迁移让一个改进可以引爆整个系统的进化雪崩

在#09中我们说过"Skill不是写完就固定了，它可以根据执行反馈持续优化"，在#11中我们探讨了自进化Skills与多智能体协作的化学反应。今天我们终于揭开了这个机制的全貌。

但一个关键问题浮出水面：Skill会进化了，但进化的Skill还是好的Skill吗？ 自动添加的步骤会不会引入新问题？从失败中学习的策略会不会过拟合？AI自己长出来的能力，经得起生产环境的考验吗？

下一篇#28，我们进入Skill测试与验证工程------确保每一次进化都是真正的进化，而不是退化。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

主题：AI原生Hermes自进化智能体系统
时间：2026年7月4-5日（周末）
形式：线上直播
内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。

技术交流

联系人：Sam
WeChat：NLP_ChatGPT_LLM
Hermes Agent技术文档：hermes-agent.nousresearch.com/docs/