Hermes Skill设计模式：把AI能力变成可复用的工程资产

#26 Skill设计模式把AI能力变成可复用的工程资产「Hermes Agent自进化智能体深度解析」系列 | 模块十 · 第1篇你会写代码但你能让AI也学会写代码吗Prompt教AI做事是手工作坊Skill让AI自己做事才是工业革命。你花了两小时精心构造了一个代码审查的Prompt效果惊艳。但这个能力锁在你的聊天记录里——换了项目、换了同事、换了一个对话窗口一切归零。你的AI能力从来没有真正属于你的团队。它散落在无数聊天记录的角落像手写配方一样随人走随人亡。这不是个别现象而是整个行业的痛点。大多数团队的AI能力本质上就是几个资深工程师脑子里的Prompt集合。团队扩张时新人从零摸索项目交接时经验随风消散季度复盘时没人说得清团队到底积累了多少可复用的AI能力。每一次有价值的AI协作经验都在对话窗口关闭的那一刻蒸发。Hermes的答案是Skill设计模式——七种将AI能力从手工作坊提升为工业资产的结构化模式。在#09模块四第1篇中我们介绍了Skills系统的七个必定义要素和基础用法。今天我们从会用Skill升级到设计Skill——就像从会写代码升级到会用设计模式写代码一样这是一次认知层级的跨越。当你的团队掌握了七种Skill设计模式每一个AI能力都不再是消耗品而是可以复用、组合、进化的工程资产。Skill完整生命周期从诞生到进化一个Skill不是写完就结束了。它有自己的生命周期——从定义、到触发、到执行、到验证、到沉淀、最终到进化。理解这个生命周期是掌握Skill设计模式的前提。┌─────────────────────────────────────────────────────────────────────┐ │ Skill Lifecycle: 从诞生到进化 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Define │───→│ Trigger │───→│ Execute │───→│ Verify │ │ │ │ 结构定义 │ │ 条件匹配 │ │ 工具调度 │ │ 证据校验 │ │ │ └─────────┘ └─────────┘ └─────────┘ └────┬────┘ │ │ │ │ │ ┌─────────┐ ┌─────────┐│ │ │ │ Evolve │←───│ Store │← │ │ │ 自进化 │ │ 经验沉淀 │ │ │ └────┬────┘ └─────────┘ │ │ │ │ │ ▼ │ │ ┌───────────┐ │ │ │ 下一轮执行 │ │ │ │ 更强的Skill│ │ │ └───────────┘ │ └─────────────────────────────────────────────────────────────────────┘Define结构定义— 按照七种设计模式之一将AI能力结构化定义。模板模式最简单组合模式最强大。定义的质量直接决定Skill的可复用性和可进化性。Trigger条件匹配— Context Engine分析当前Goal的语义和上下文判断是否匹配某个Skill的触发条件。精准的Trigger定义是避免该用没用和不该用乱用的关键。Execute工具调度— Skill的Steps被翻译为具体的Tool Dispatch调用。Execution Layer#21中拆解的Layer 3负责调度Worker、分配工具、管理执行顺序。Verify证据校验— 每一步执行的结果都经过Verification Protocol#25中深度拆解的校验。不是看起来完成了而是有证据地完成。Store经验沉淀— 执行轨迹、成功模式、失败教训全部写入Memory SystemLTM和EP。这不是日志归档而是为自进化准备燃料。Evolve自进化— 这是生命周期的终点也是下一轮的起点。Trajectory Log中的模式被Skill Registry识别提炼为Skill的改进版本。一个定义时只有3个Step的Skill经过100次执行后可能进化为5个Step——因为系统学到了两个新的边界条件需要处理。Skill不是静态代码而是活的工程资产。七大Skill设计模式从简单到强大的阶梯软件工程有23种经典设计模式。Hermes的Skill系统提炼出七种高频模式覆盖从最简单的单步操作到最复杂的多Skill编排。掌握这七种模式就像掌握了搭建能力建筑的七种标准结构——任何AI能力都可以用它们的组合来表达。模式一模板模式Template Pattern最简单也最常用的模式。固定执行步骤参数化输入。就像一个模板函数——逻辑不变数据可替换。┌──────────────────────────────────────┐ │ Template Pattern │ │ │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │ │Step 1 │──→│Step 2 │──→│Step 3 │ │ │ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ │ │ │ │ ┌───▼───────────▼───────────▼───┐ │ │ │ 参数化输入 (inputs) │ │ │ │ files, context, standards │ │ │ └───────────────────────────────┘ │ └──────────────────────────────────────┘适用场景流程固定、输入可变的任务。代码审查、文档生成、测试编写。skill:code_review_v2pattern:templatetrigger:当需要审查代码变更时inputs:-files:{type:listpath,required:true}-strictness:{type:enum[standard,strict],default:standard}-focus_areas:{type:liststring,default:[security,performance,style]}steps:-action:读取变更文件的git difftool:git_diff-action:运行静态分析工具tool:linter_runner-action:按维度逐一审查tool:llm_reasoningcontext:{focus_areas} 维度清单-action:生成结构化审查报告tool:report_generator模式二策略模式Strategy Pattern同一目标多种策略可选。运行时根据上下文选择最优策略。┌──────────────────────────────────────┐ │ Strategy Pattern │ │ │ │ ┌──────────┐ │ │ │ 目标 Goal │ │ │ └─────┬────┘ │ │ │ │ │ ┌──────────┼──────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐┌─────────┐┌─────────┐ │ │ │策略 A ││策略 B ││策略 C │ │ │ │金丝雀 ││蓝绿部署 ││滚动更新 │ │ │ └─────────┘└─────────┘└─────────┘ │ │ │ │ │ │ │ └──────────┴──────────┘ │ │ │ │ │ ┌─────▼─────┐ │ │ │ 策略选择器 │ │ │ │(基于上下文)│ │ │ └───────────┘ │ └──────────────────────────────────────┘适用场景同一任务有多种实现路径需要根据环境、风险级别、资源约束动态选择。skill:deploymentpattern:strategytrigger:当需要部署服务到目标环境时strategy_selector:rules:-condition:environment production AND risk_level highstrategy:canary-condition:environment production AND rollback_window immediatestrategy:blue_green-condition:environment staging OR change_scope smallstrategy:rollingfallback:rollingstrategies:canary:steps:[部署到5%流量,监控15min,扩大到25%,监控15min,全量]blue_green:steps:[部署蓝环境,健康检查,切换流量,保留绿环境30min]rolling:steps:[批次1(25%),批次2(50%),批次3(75%),批次4(100%)]模式三管道模式Pipeline Pattern串行处理每步输出是下步输入。经典的数据处理流水线。┌────────────────────────────────────────────────────────┐ │ Pipeline Pattern │ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌─────┐ │ │ │Extract│──→│Clean │──→│Trans-│──→│Enrich│──→│Load │ │ │ │ │ │ │ │form │ │ │ │ │ │ │ └──────┘ └──────┘ └──────┘ └──────┘ └─────┘ │ │ ↓output ↓output ↓output ↓output ↓ │ │ 成为下步input 成为下步input ... ... 完成 │ └────────────────────────────────────────────────────────┘适用场景数据处理、ETL、多阶段代码生成分析→设计→编码→测试。skill:data_pipelinepattern:pipelinetrigger:当需要处理和转化数据时inputs:-source:{type:data_source,required:true}-target:{type:data_sink,required:true}pipeline:-stage:extracttool:data_connectoroutput:raw_data-stage:cleantool:data_cleanerrules:[remove_nulls,deduplicate,normalize_encoding]input_from:raw_dataoutput:clean_data-stage:transformtool:llm_reasoningprompt:按目标Schema转换数据格式input_from:clean_dataoutput:transformed_data-stage:enrichtool:external_apiinput_from:transformed_dataoutput:enriched_data-stage:loadtool:data_writerinput_from:enriched_dataoutput:completion_report模式四分支模式Branching Pattern条件判断后走不同路径。不是所有任务都是直线——有些需要根据中间结果做决策。┌──────────────────────────────────────────────────┐ │ Branching Pattern │ │ │ │ ┌──────────┐ │ │ │ 输入判断 │ │ │ └─────┬────┘ │ │ │ │ │ ┌──────────┼──────────┐ │ │ ▼ ▼ ▼ │ │ ┌────────┐┌────────┐┌────────┐ │ │ │路径 A ││路径 B ││路径 C │ │ │ │error_type│error_type│error_type │ │ │timeout │auth │data │ │ │ └───┬────┘└───┬────┘└───┬────┘ │ │ └──────────┴──────────┘ │ │ ▼ │ │ ┌──────────┐ │ │ │ 结果合并 │ │ │ └──────────┘ │ └──────────────────────────────────────────────────┘适用场景错误处理根据错误类型选择修复策略、用户请求路由根据意图分发、条件发布根据检查结果决定下一步。skill:error_handlerpattern:branchingtrigger:当执行过程中出现错误时branches:-condition:error.type TIMEOUTpath:retry_with_backoffsteps:[等待1s,重试,失败则等待2s再试,3次后升级]-condition:error.type AUTH_FAILUREpath:refresh_credentialssteps:[刷新Token,重试原操作,仍失败则升级人工]-condition:error.type DATA_VALIDATIONpath:auto_fix_datasteps:[分析校验失败原因,生成修复方案,自动应用,重新验证]-condition:error.type UNKNOWNpath:escalatesteps:[记录完整错误上下文,生成诊断报告,升级到人工审批]模式五并行模式Parallel Pattern多个子任务同时执行结果汇聚。大幅缩短执行时间。┌──────────────────────────────────────────────┐ │ Parallel Pattern │ │ │ │ ┌──────────┐ │ │ │ 任务分发 │ │ │ └─────┬────┘ │ │ ┌──────────┼──────────┐ │ │ ▼ ▼ ▼ │ │ ┌────────┐┌────────┐┌────────┐ │ │ │子任务A ││子任务B ││子任务C │ ← 同时执行 │ │ │file_1 ││file_2 ││file_3 │ │ │ └───┬────┘└───┬────┘└───┬────┘ │ │ └──────────┼──────────┘ │ │ ▼ │ │ ┌──────────┐ │ │ │ 结果汇聚 │ │ │ └──────────┘ │ └──────────────────────────────────────────────┘适用场景多文件审查、批量数据处理、多环境测试、多源信息聚合。skill:multi_file_reviewpattern:paralleltrigger:当需要同时审查多个文件时parallel_tasks:-task:review_fileinputs:{file:${files[0]},focus:security}-task:review_fileinputs:{file:${files[1]},focus:security}-task:review_fileinputs:{file:${files[2]},focus:security}# ... 动态扩展每个文件一个并行子任务aggregation:strategy:merge_reportssteps:[收集所有审查结果,去重重复问题,按严重性排序,生成汇总报告]模式六递归模式Recursive Pattern自我调用处理层级结构。文件系统遍历、嵌套数据解析、分治问题求解。┌───────────────────────────────────────────────────┐ │ Recursive Pattern │ │ │ │ ┌───────────┐ │ │ │ 处理节点N │ │ │ └─────┬─────┘ │ │ │ │ │ ┌────▼────┐ │ │ │有子节点│ │ │ └──┬───┬──┘ │ │ YES│ │NO │ │ │ └──→ 返回处理结果 │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ 对每个子节点递归调用 │──→ 处理节点N/child_1 │ │ │ ├──→ 处理节点N/child_2 │ │ │ └──→ ... │ │ └──────────┬──────────┘ │ │ ▼ │ │ 合并所有子结果 │ └───────────────────────────────────────────────────┘适用场景目录结构遍历、嵌套JSON/XML解析、分治算法、多层依赖分析。skill:directory_analyzepattern:recursivetrigger:当需要分析目录结构和代码组织时recursive_logic:base_case:当前节点是文件 → 分析单个文件recursive_step:当前节点是目录 → 对每个子节点递归调用自身aggregation:合并所有子节点的分析结果max_depth:10termination:-condition:depth max_depthaction:停止递归返回当前层级摘要-condition:node_count 500action:切换为采样模式每层最多分析50个节点模式七组合模式Composition Pattern多个Skill组合成新Skill——这是最强大的模式。当原子Skill足够丰富时组合模式让你像搭积木一样构建复杂的AI能力。┌─────────────────────────────────────────────────────────┐ │ Composition Pattern │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ Composite Skill: 发布流水线 │ │ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────────────┐ │ │ │ │ │Skill A │ │Skill B │ │ Skill C │ │ │ │ │ │代码审查 │→│安全扫描 │→│ 部署 │ │ │ │ │ └─────────┘ └─────────┘ │ ┌──────┐ │ │ │ │ │ │ │策略A │ │ │ │ │ │ │ │金丝雀│ │ │ │ │ │ │ └──────┘ │ │ │ │ │ └─────────────────┘ │ │ │ └──────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘适用场景完整CI/CD流水线、端到端开发流程、复杂工作流编排。skill:release_pipelinepattern:compositiontrigger:当需要执行完整的发布流程时composed_skills:-skill_ref:code_review_v2# 模板模式inputs_mapping:files:${goal.changed_files}strictness:strict-skill_ref:security_scan# 模板模式inputs_mapping:target:${goal.project_root}-skill_ref:multi_file_review# 并行模式inputs_mapping:files:${goal.changed_files}condition:code_review_v2.passed true-skill_ref:deployment# 策略模式inputs_mapping:environment:${goal.target_env}condition:all_previous.passed true七种模式全景对比模式复杂度适用场景自进化潜力关键价值模板模式低流程固定、输入可变中 — 步骤可扩展最快上手团队入门首选策略模式中同一目标、多种路径高 — 策略库可增长运行时动态选择最优解管道模式中串行多阶段处理高 — 管道节点可插拔数据流转清晰可控分支模式中条件判断、路径选择高 — 分支条件可学习应对不确定性并行模式中高多任务并发执行中 — 并行策略可优化执行效率倍增递归模式高层级/嵌套结构处理中 — 终止条件可进化处理任意深度结构组合模式最高多Skill编排成流水线极高 — 组合方式指数级增长能力的复利效应七个必定义要素的工程深化设计模式视角在#09中我们介绍了Skill的七个必定义要素——Trigger、Inputs、Tools、Steps、Failure Handling、Logs、Verification。现在我们从设计模式的视角重新审视它们。不同的设计模式会从根本上改变每个要素的定义方式。Trigger从关键词匹配到语义理解模板模式的Trigger通常是简单的关键词或条件判断。但策略模式需要更智能的Trigger——它不仅要判断该不该触发还要判断该用哪个策略。组合模式的Trigger最复杂它需要理解Goal的完整语义才能决定是否需要触发一整条流水线。# 模板模式Trigger — 简单条件trigger:当需要审查代码变更时# 策略模式Trigger — 条件 策略选择trigger:condition:当需要部署服务时strategy_resolver:根据environment risk_level动态选择策略# 组合模式Trigger — 语义匹配trigger:condition:当Goal语义匹配发布流程或上线部署时composition_resolver:根据Goal上下文选择Skill组合方案Inputs从静态参数到动态流管道模式中Inputs是动态流动的——每一步的输出自动成为下一步的输入。并行模式需要将Inputs拆分到多个子任务。递归模式的Inputs在每次自我调用时都在变化当前处理的节点不同。# 管道模式Inputs — 流式传递pipeline:-stage:extractoutput:raw_data# 自动注入下一阶段-stage:cleaninput_from:raw_data# 引用上一阶段输出output:clean_data# 并行模式Inputs — 动态分片parallel_inputs:source:${goal.changed_files}partition_strategy:one_file_per_taskSteps从线性列表到动态DAG模板模式的Steps是固定的线性列表。分支模式的Steps是条件树。组合模式的Steps是多个Skill的编排图。Steps的定义方式直接决定Skill的表达能力上限。# 模板模式Steps — 线性steps:[步骤1,步骤2,步骤3]# 分支模式Steps — 条件树steps:-action:判断错误类型branches:-condition:timeout →[重试逻辑]-condition:auth →[刷新Token]# 组合模式Steps — DAG编排steps:-skill:code_review → 输出到 gate_1-skill:security_scan → 输出到 gate_1-gate_1:全部通过? → 输入到 deployment-skill:deployment → 输入来自 gate_1Failure Handling从单点重试到模式化容灾管道模式中某一步失败可能需要从失败点重新开始而非从头重跑。并行模式中一个子任务失败不应阻塞其他子任务。递归模式需要防止无限递归。每种模式有其独特的失败模式容灾设计必须与之匹配。Logs和Verification从记录到进化燃料无论哪种模式Logs和Verification都是自进化的关键输入。管道模式记录每阶段的延迟用于优化瓶颈。策略模式记录每次策略选择的结果用于优化选择器。组合模式记录每条流水线的端到端指标用于优化编排策略。Logs不只是审计日志它是Skill自我进化的训练数据。从Prompt到Skill的转化方法论理论说完了。现在看一个完整的转化案例——从每次花20分钟写代码审查prompt到一行指令调用Skill的全过程。第一步识别高频操作回溯过去一个月的AI交互记录找出你反复在做的操作。代码审查、Bug分析、API设计、测试编写——这些高频操作就是Skill的候选。判断标准同一个操作你做了3次以上它就应该被封装为Skill。第二步提取模式分析这些高频操作的共性。以代码审查为例原始Prompt片段每次都要重写 请审查以下代码变更注意 1. SQL注入等安全漏洞 2. N1查询等性能问题 3. 是否符合团队编码规范 4. 边界条件处理 5. 异常处理完整性 6. 与现有架构的兼容性 请按严重程度标注每个问题...提取模式这是一个模板模式Skill——步骤固定6个审查维度输入可变不同的代码文件。第三步结构化定义将提取的模式按照七个必定义要素结构化# 转化前每次花20分钟手写Prompt# 转化后一行调用/skill code_review_v2--files src/api/auth.py,src/services/user.py# 背后的完整定义skill:code_review_v2version:2.4# 经过24次迭代进化pattern:templateevolution_log:-v1.0:初始6维度审查-v1.3:增加依赖兼容性维度从第8次执行中学到-v2.0:重构为模板模式从第15次执行中发现模式-v2.4:增加LLM幻觉检测维度从第22次的误报中学到trigger:当需要审查代码变更时inputs:-files:{type:listpath,required:true}-strictness:{type:enum[standard,strict],default:standard}-focus_areas:{type:liststring,default:[security,performance,style,edge_cases,error_handling,architecture_compatibility]}tools:[git_diff,linter_runner,test_runner,llm_reasoning,report_generator]steps:-读取git diff提取变更范围-运行静态分析和测试套件-逐维度深度审查61个维度-标注严重级别生成修复建议-输出结构化审查报告failure_handling:-linter失败:跳过自动检查切换为纯LLM审查-文件过大:自动分片审查每片不超过500行-超时:返回已完成部分的审查结果标记未完成区域logs:-审查文件数、发现的问题数及级别分布、审查耗时verification:-所有变更文件均已审查-每个问题包含位置、严重级别、修复建议-报告格式符合团队标准stats:# 自进化统计数据total_invocations:247success_rate:96.3%avg_issues_per_review:3.7false_positive_rate:4.1%# 持续下降中last_evolved:2026-05-28看到evolution_log了吗这个Skill不是一次写完就固定的——它经历了24次迭代每次迭代都来自真实执行中发现的新模式。v1.3的依赖兼容性维度是从第8次执行中发现的盲区代码本身没问题但新引入的依赖版本与现有系统冲突。v2.4的LLM幻觉检测维度是从第22次执行中学到的审查报告引用了一个不存在的函数名后来发现是LLM的幻觉。这些都是人类不可能在第一次定义时就预见到的——只有通过持续执行和自进化才能学到。震撼时刻Skill的网络效应以下是一个真实团队在6个月内的Skill积累数据。看这张表的时候请注意最后一列。┌────────────────────────────────────────────────────────────────────┐ │ 团队Skill积累曲线从0到47的6个月旅程 │ │ │ │ 月份 Skill数 本月新增 总调用次数 平均成功率 组合复用次数 │ │ ───── ──────── ──────── ──────────── ──────────── ──────────── │ │ M1 3 3 47 78.2% 0 │ │ M2 8 5 186 84.1% 7 │ │ M3 16 8 523 89.7% 34 │ │ M4 27 11 1247 92.3% 128 │ │ M5 38 11 2891 94.8% 437 │ │ M6 47 9 5634 96.1% 1203 │ │ │ │ ═════════════════════════════════════════════════════════════════ │ │ 核心洞察组合复用次数的增长不是线性的而是指数级的 │ │ │ │ M1→M3: 16个Skill, 34次组合 → 每个Skill平均参与 2.1次组合 │ │ M4→M6: 47个Skill, 1203次组合 → 每个Skill平均参与 12.8次组合 │ │ │ │ 第47个Skill的价值 ≈ 前46个Skill创造的所有组合机会 │ │ 公式新增组合潜力 C(46,1) C(46,2) ... ≈ 2^46 │ └────────────────────────────────────────────────────────────────────┘Skill的价值不是线性的而是网络效应式的——第47个Skill的价值远大于第1个因为它可以与前46个Skill任意组合。这就像城市的交通网络。第1条路的价值很低——它只连接两个点。但当路网扩展到47条路时每新增一条路不仅连接两个新点还让所有已有的点之间多了一种新的可达路径。47个Skill的团队本质上已经拥有了一个覆盖C(47,2)1081种双Skill组合、C(47,3)16215种三Skill组合的能力网络。更关键的是最后一列的数据——成功率从78.2%上升到96.1%。这不是因为团队在手动优化每个Skill而是因为自进化机制在每次执行后自动提炼经验。每个Skill的成功率提升会通过网络效应传导到所有包含它的组合Skill中——一个基础Skill的1%提升可能让10条流水线的端到端成功率各提升0.5%。Skill vs Plugin vs Macro本质区别这三个概念经常被混淆。但它们之间的差异不是程度上的而是本质上的。维度Macro宏Plugin插件Skill技能抽象层级操作序列的录制回放功能接口的标准化封装能力的结构化表达可组合性低 — 顺序拼接中 — 通过接口调用高 — 七种设计模式自由组合自进化能力无 — 录完即固化无 — 版本需手动升级核心特征 — 每次执行都在积累进化数据上下文感知无 — 不看环境弱 — 固定参数强 — Context Engine动态注入失败处理无 — 出错即停弱 — try-catch多层级 — 重试/降级/分支/升级人工治理复杂度低 — 几乎不需要中 — 版本和依赖管理高 — 但设计模式提供标准化治理框架价值增长曲线线性 — 加一个多一个线性 — 装一个多一个指数级 — 网络效应驱动复利增长核心区别用一句话概括Macro是你做了什么的回放Plugin是系统能做什么的扩展Skill是Agent学会了什么的能力资产。只有Skill具备自进化能力——它越用越强越组合越强大越分享越有价值。模块十启程从底层到能力的跨越模块九的五篇文章#21-#25拆解了Hermes的五层架构全景——从Interface到Foundation从Tool Dispatch到Trajectory Log从Reasoning Parsing到Verification Protocol。那些是Hermes的骨架和肌肉。模块十我们进入一个全新的维度——能力层。七个Skill设计模式是能力层的设计语言。模板模式让简单的事标准化策略模式让复杂的事可控化管道模式让数据流转工程化分支模式让不确定性可管理并行模式让效率最大化递归模式让层级结构可处理组合模式让能力实现指数级增长。这七种模式不是选一个用——它们是组合使用的。一个成熟团队的Skill库中七种模式都会出现而且越高级的模式越依赖低级模式作为积木。但设计模式说完了Skill最可怕的特性还没有展开——它会自己进化。本文的evolution_log字段只是冰山一角。下一篇我们将拆解自进化Skill的完整机制Skill如何从执行轨迹中自动学习新步骤如何从失败中自动提炼新的分支条件如何从用户反馈中自动调整策略权重#27自进化Skill让AI能力自己长出来。延伸阅读与交流本文涉及的Hermes Agent自进化智能体技术体系目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。专题信息主题AI原生Hermes自进化智能体系统时间2026年7月4-5日周末形式线上直播内容方向AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层分享嘉宾王老师GavinAgentic AI企业联合创始人兼CTO十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构提出语言即控制Language as Control原创范式在RLHF、PPO、DPO、GRPO等方向有系统化工程实践推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。技术交流联系人SamWeChatNLP_ChatGPT_LLMHermes Agent技术文档https://hermes-agent.nousresearch.com/docs/