Hermes推理解析与输出清理让AI的思考变成工程产物「Hermes Agent自进化智能体深度解析」系列 | 模块九 · 第3篇#22拆解了Tool Dispatch Runtime——工具分发的引擎。但引擎的燃料从哪来从LLM的原始输出中来。问题是LLM的输出是一团混合了推理、工具调用、注释和格式标记的浓汤。本篇深度拆解Hermes如何将这碗浓汤变成一杯精确的工程产物。一、天才的草图与工程的图纸LLM的输出就像一个天才随手画的草图——想法绝妙但格式混乱。如果你不能从中提取结构化信息天才的想法就变成了废纸。想一想你见过的每一次LLM调用推理链与工具调用混在一起中间状态散落各处格式时好时坏不可预测。你以为你拿到了答案实际上你拿到的是一堆需要二次加工的原始矿石化石。绝大多数Agent框架对此的应对方式是——祈祷。祈祷模型输出格式正确祈祷JSON能解析祈祷工具调用参数没写错。祈祷不是工程。Hermes Agent不祈祷。它有一套精密的翻译清洗管线将LLM的原始输出——无论多么混乱——逐层解析、清洗、校验最终变成结构化的工程产物。这条管线不是事后补救而是自进化的前端传感器每一次解析都在为下一次推理积累经验每一次错误修复都在让Agent更聪明。这就是Hermes与普通框架的根本差异——它把理解AI在想什么变成了一门可度量、可优化、可进化的工程学科。二、LLM输出的混乱现实在拆解解决方案之前先看看我们面对的是什么。下面是一段真实的LLM原始输出——混合了推理、工具调用、自我注释、格式标记和不确定的中间结果thinking 用户想查询北京今天的天气我需要调用天气API。 不过用户说的是今天我需要确认当前日期。 先调用 get_current_time 获取时间再调用 get_weather。 等等也许我应该先检查一下用户是否有位置偏好设置... /thinking 好的我来帮您查询北京的天气。 tool_call {name: get_weather, arguments: {city: 北京, date: 2026-06-01}} / 我还需要考虑空气质量指数... thinking 等等我刚才的tool_call格式可能不对让我重新格式化 /thinking json {name: get_weather, arguments: {city: 北京, date: 2026-06-01}}嗯根据我的知识北京6月1日通常是初夏天气气温在25-35度之间但具体数据还是以API返回为准。北京今天的天气晴转多云气温28°C湿度45%空气质量指数82良。我应该同时给出穿衣建议。 建议穿着轻薄透气的夏季服装外出可携带薄外套。 这段输出包含了至少七种不同类型的信息自由推理、格式化的工具调用两种格式、自我纠正、格式标记、自然语言回复、中间结果注释和建议。如果Agent直接拿到这段文字就开始执行它会尝试解析两个不同格式的工具调用——一个失败误把推理链中的也许我应该…当作指令丢失中间结果中的结构化数据把HTML注释当垃圾丢弃或当作工具参数这就是LLM输出的三大混乱——推理链与工具调用交织、中间状态散落各处、格式不可预测。而Hermes的解析管线正是为驯服这三种混乱而生。三、解析Pipeline五步流程┌─────────────────────────────────────────────────────────────────┐ │ Hermes LLM Output Parsing Pipeline │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Step 1 │──│ Step 2 │──│ Step 3 │──│ Step 4 │ │ │ │ Stream │ │ Reasoning│ │ Tool │ │ Intermed.│ │ │ │ Segment. │ │ Extract. │ │ Call │ │ State │ │ │ └──────────┘ └──────────┘ │ Parsing │ │ Assembly │ │ │ │ │ └──────────┘ └──────────┘ │ │ v v │ │ │ │ raw_segments reasoning_blocks tool_calls state_map │ │ │ │ │ │ v v │ │ ┌──────────────────────────┐ │ │ │ Step 5 │ │ │ │ Output Cleaning │ │ │ │ (sanitize validate) │ │ │ └──────────────────────────┘ │ │ │ │ │ v │ │ Structured Engine Output │ │ {reasoning, tools, state, response} │ └─────────────────────────────────────────────────────────────────┘Step 1: Stream Segmentation —— 切分洪流LLM的输出是一个字符流第一步是将其切分为有意义的片段。Hermes维护一个Token Pattern Registry用正则表达式匹配已知的输出模式# stream_segmenter.yamlpatterns:thinking_block:open:thinkingclose:/thinkingtype:reasoningtool_call_xml:open:tool_callclose:/type:tool_invocationtool_call_json:pattern:json\s*\{.*?name.*?\}.*?type:tool_invocationhtml_comment:pattern:!--.*?--type:intermediate_statenatural_text:fallback:truetype:response输入→ 一团原始字符流处理→ 按Pattern Registry逐段匹配每个片段打上类型标签输出→ 一个有序的raw_segments列表raw_segments [ {type: reasoning, content: 用户想查询北京今天的天气..., order: 0}, {type: response, content: 好的我来帮您查询..., order: 1}, {type: tool_invocation, content: {name:get_weather,...}, order: 2}, {type: reasoning, content: 等等我刚才的tool_call..., order: 3}, {type: tool_invocation, content: {name:get_weather,...}, order: 4}, ... ]关键洞察Hermes不只匹配成功模式还记录匹配失败的片段——这些孤儿片段是发现新输出格式的种子也是自进化学习的素材。Step 2: Reasoning Extraction —— 提取思考从raw_segments中分离出所有推理块构建推理树classReasoningExtractor:defextract(self,segments:List[RawSegment])-ReasoningTree:reasoning_blocks[sforsinsegmentsifs.typereasoning]treeReasoningTree()fori,blockinenumerate(reasoning_blocks):nodeReasoningNode(idfrn_{i},contentblock.content,orderblock.order,# 检测推理类型计划/自我纠正/评估/记忆检索node_typeself._classify_reasoning(block.content),confidenceself._estimate_confidence(block.content),position_contextself._get_position_context(block,segments))tree.add_node(node)# 构建推理链的时序关系tree.build_temporal_edges()returntree推理类型自动分类类型标记含义示例planning任务分解与步骤规划“我需要先调用A再调用B”self_correction自我纠错“等等刚才的格式不对”evaluation结果评估“API返回的数据看起来合理”memory_retrieval记忆检索“用户之前说过偏好公制单位”uncertainty不确定性表达“我不确定是否应该…”这个分类不是装饰——它直接影响推理链如何存储到记忆层、如何被未来的推理复用。自进化的关键每次推理分类的结果都回流到Pattern Registry让分类器越来越精准。Step 3: Tool Call Parsing —— 解析工具调用这是最关键也最容易出错的环节。工具调用可能出现在任何位置、任何格式中classToolCallParser:defparse(self,segments:List[RawSegment])-List[ToolCall]:tool_segments[sforsinsegmentsifs.typetool_invocation]parsed_calls[]forsegmentintool_segments:# 策略1尝试标准JSON解析callself._try_json_parse(segment.content)ifcall:parsed_calls.append(call)continue# 策略2尝试XML属性解析callself._try_xml_parse(segment.content)ifcall:parsed_calls.append(call)continue# 策略3模糊匹配 LLM辅助修复callself._fuzzy_parse_with_repair(segment.content)ifcall:parsed_calls.append(call)self._log_repair(segment.content,call)# 记录修复用于自进化else:# 策略4标记为不可解析进入错误处理流程parsed_calls.append(UnparseableToolCall(rawsegment.content))# 去重同一次推理中可能输出多次相同的工具调用returnself._deduplicate(parsed_calls)三级解析策略的设计哲学优先确定性解析JSON/XML退化到模糊匹配最终退化到错误标记。每一级退化都意味着更低的置信度而置信度直接影响后续执行策略。Step 4: Intermediate State Assembly —— 中间状态组装散落在输出中的中间数据——HTML注释、内联计算结果、引用的知识片段——需要被收集并组装成一个统一的状态映射# intermediate_state_map 示例state_map:weather_data:source:html_commentcontent:{temperature:28°C,humidity:45%,aqi:82}confidence:0.95extracted_at:segment_order_6domain_knowledge:source:natural_textcontent:北京6月1日通常是初夏天气气温在25-35度之间confidence:0.7extracted_at:segment_order_5这些中间状态不仅服务于当前任务的执行还会被写入短期工作记忆供同一会话中的后续推理步骤直接引用。这是Hermes自进化记忆系统的微循环。Step 5: Output Cleaning —— 输出清洗最后一步是清洗——去除冗余、脱敏敏感信息、统一格式classOutputCleaner:defclean(self,parsed:ParsedOutput)-CleanedOutput:# 1. 去除重复的推理内容自我纠正后旧版本应标记为supersededparsed.reasoning_tree.mark_superseded()# 2. 脱敏检测并替换PII个人身份信息parsedself._sanitize_pii(parsed)# 3. 统一工具调用格式为内部标准forcallinparsed.tool_calls:call.normalize_to_standard()# 4. 验证检查工具名是否在注册表中、参数是否合规validation_resultsself._validate_tool_calls(parsed.tool_calls)parsed.validationvalidation_results# 5. 生成最终的清洁输出returnCleanedOutput(reasoningparsed.reasoning_tree,tool_callsparsed.tool_calls,intermediate_stateparsed.state_map,responseself._extract_final_response(parsed),metadata{parse_confidence:parsed.overall_confidence,repairs_applied:parsed.repair_count,segments_processed:len(parsed.raw_segments)})┌───────────────────────────────────────────────┐ │ 解析前后对比从混乱到秩序 │ │ │ │ BEFORE (原始LLM输出) │ │ ┌─────────────────────────────────────┐ │ │ │ thinking用户想查询.../thinking │ │ │ │ 好的我来帮您查询。 │ │ │ │ tool_call {name:get_weather… │ │ │ │ 我还需要考虑空气质量... │ │ │ │ thinking等等格式不对.../thinking│ │ │ │ json{name:get_weather… │ │ │ │ !-- temperature28°C -- │ │ │ │ 北京今天天气晴转多云... │ │ │ └─────────────────────────────────────┘ │ │ │ │ │ v │ │ AFTER (结构化输出) │ │ ┌─────────────────────────────────────┐ │ │ │ reasoning: │ │ │ │ rn_0: [planning] 查询北京天气 │ │ │ │ rn_1: [self_correction] 格式修正 │ │ │ │ tool_calls: │ │ │ │ - get_weather(city北京, ...) │ │ │ │ intermediate_state: │ │ │ │ temperature: 28°C, humidity: 45% │ │ │ │ response: 北京今天天气晴转多云... │ │ │ │ metadata: {confidence: 0.92, ...} │ │ │ └─────────────────────────────────────┘ │ └───────────────────────────────────────────────┘四、错误输出的检测与自修复解析管线不是银弹。LLM的输出有时会超越所有已知模式甚至包含结构性错误。Hermes为此设计了五层错误检测与自修复机制。五种常见错误与修复策略错误1工具调用参数格式错误LLM输出了工具调用但参数格式有瑕疵——缺少引号、数据类型不对、嵌套JSON未闭合。# 原始输出错误tool_call:name:get_weatherarguments:{city:北京,date:2026-06-01}# 缺少引号date是字符串不是日期# 修复后tool_call:name:get_weatherarguments:{city:北京,date:2026-06-01}_repair_log:auto_quoted_keys, date_kept_as_string修复策略基于工具Schema的自动补全与修正。Hermes的工具注册表包含每个参数的JSON Schema解析器以此为蓝本进行结构化修正。错误2推理链断裂推理过程中出现逻辑跳跃——前一步在讨论天气下一步突然跳到订机票缺少过渡。# 推理链断裂检测classReasoningContinuityChecker:defcheck(self,tree:ReasoningTree)-List[Gap]:gaps[]foriinrange(1,len(tree.nodes)):prev,currtree.nodes[i-1],tree.nodes[i]similarityself._semantic_similarity(prev.content,curr.content)ifsimilarityself.gap_threshold:gaps.append(Gap(between(prev.id,curr.id),similaritysimilarity,suggestionmodel_supplement# 请求模型补充过渡推理))returngaps修复策略当检测到推理链断裂时Hermes会向LLM发送一个补充请求要求其解释两个步骤之间的逻辑过渡。补充内容被插入推理链并标记为auto_filled: true。错误3工具调用指向不存在的工具LLM调用了一个未注册的工具比如check_flight_status——而工具注册表中只有search_flights。# 降级策略error:type:unknown_tooltool_name:check_flight_statusresolution:strategy:fuzzy_matchcandidates:[search_flights,get_flight_info]selected:search_flightsconfidence:0.78action:execute_with_warning# 执行但降低置信度修复策略模糊匹配 降级执行。Hermes用编辑距离和语义相似度在工具注册表中寻找最接近的替代执行时降低该步骤的置信度分数。错误4输出包含敏感信息LLM的推理过程中泄露了用户的敏感数据——手机号、身份证、API密钥等。classPIISanitizer:patterns{phone:r1[3-9]\d{9},id_card:r\d{17}[\dXx],api_key:rsk-[a-zA-Z0-9]{32,},email:r[\w.-][\w.-]\.\w}defsanitize(self,parsed:ParsedOutput)-ParsedOutput:fornodeinparsed.reasoning_tree.nodes:forpii_type,patterninself.patterns.items():node.contentre.sub(pattern,f[{pii_type}_REDACTED],node.content)returnparsed修复策略自动脱敏。所有PII在进入结构化输出之前被替换为占位符原文仅保留在加密的审计日志中且仅在授权上下文中可还原。错误5格式完全不可解析LLM输出了某种从未见过的格式——没有已知的标记、没有可识别的结构就是一段自由文本。# 回退策略error:type:unparseable_formatraw_length:847resolution:strategy:full_fallbackactions:-treat_entire_output_as_response# 整段作为自然语言回复-log_to_pattern_discovery_queue# 加入新格式发现队列-trigger_human_alert:false# 仅在连续N次时告警-increment_unparseable_counter# 自进化指标修复策略全回退模式。整段输出作为自然语言回复处理同时将其加入Pattern Discovery Queue——这是Hermes自进化系统的好奇心引擎。队列中积累足够多的同类不可解析样本后系统会自动尝试发现新模式并更新Pattern Registry。震撼时刻0.3秒内的自动修正考虑这个真实场景用户要求帮我分析2026年Q1的销售数据并生成报告。LLM输出了工具调用但参数完全错误——它把Q1解释为第一天把年份写成了2025# LLM原始输出严重错误 thinking 用户要分析Q1销售数据Q1就是1月1日年份应该是2025... /thinking tool_call {name: query_sales_db, arguments: {date: 2025-01-01, metrics: revenue}} /Hermes的检测-分析-修正流程全部在0.3秒内完成┌─────────────────────────────────────────────────────────────┐ │ 0.3秒自修复流程 (total: 300ms) │ │ │ │ T0ms ┌──────────────┐ │ │ │ Schema校验 │ 检测到date参数类型正确但值可疑 │ │ └──────┬───────┘ (10ms) │ │ v │ │ T10ms ┌──────────────┐ │ │ │ 上下文推理 │ 用户说Q1→工具Schema期望date_ │ │ │ │ range→Q1全年前三个月→2026年Q1 │ │ └──────┬───────┘ (80ms) │ │ v │ │ T90ms ┌──────────────┐ │ │ │ 参数重构 │ date→date_range │ │ │ │ 2025-01-01 → [2026-01-01, │ │ │ │ 2026-03-31] │ │ └──────┬───────┘ (30ms) │ │ v │ │ T120ms ┌──────────────┐ │ │ │ 置信度评估 │ 修正置信度0.94高 │ │ └──────┬───────┘ (20ms) │ │ v │ │ T140ms ┌──────────────┐ │ │ │ 执行提交 │ 使用修正后的参数调用工具 │ │ └──────┬───────┘ (160ms含API调用) │ │ v │ │ T300ms ✓ 成功返回Q1销售数据 │ │ │ │ 自进化记录本次修正确认Q1→date_range映射规则 │ │ 置信度从0.82提升至0.94规则权重1 │ └─────────────────────────────────────────────────────────────┘但这不是最令人震撼的部分。真正让Agent越用越强的是这个这次修正确认了一条映射规则——“当用户说Q1时工具参数应该是date_range而非date”——这条规则被写入记忆层下次遇到类似的季度请求时解析器直接应用已学到的规则跳过修复步骤解析延迟从300ms降到10ms。Agent不只处理了错误还让错误成为学习机会。这就是自进化。五、推理链的结构化存储解析后的推理链不会随用随弃。它被结构化存储到Hermes的记忆层成为Agent经验库的一部分# reasoning_record Schemareasoning_record:record_id:rr_20260601_001goal_id:goal_analyze_sales_q1created_at:2026-06-01T10:30:00Zreasoning_tree:nodes:-id:rn_0type:planningcontent:用户要分析Q1销售数据需要查询数据库...confidence:0.91based_on:[goal_analyze_sales_q1]led_to:tool_call:query_sales_db-id:rn_1type:self_correctioncontent:Q1应映射为date_range非单个dateconfidence:0.94based_on:[rn_0,schema:query_sales_db]repair_applied:truerepair_rule:quarter_to_date_range-id:rn_2type:evaluationcontent:返回数据合理Q1收入1.2M符合趋势confidence:0.88based_on:[tool_result:query_sales_db,memory:historical_trend]metadata:total_nodes:3avg_confidence:0.91repairs:1new_rules_learned:[quarter_to_date_range]reusable:true# 标记为可复用——未来类似任务可检索此推理链关键字段解析based_on记录每一步推理的依据上游节点、Schema约束、记忆数据形成完整的推理溯源链confidence每步推理的置信度低置信度的节点是未来优化的首要目标repair_applied标记哪些节点经过自动修复这些是自进化系统的训练样本reusable当标记为true时此推理链可被未来相似任务直接检索和复用——这是Hermes推理能力自进化的核心机制推理记录被存入记忆层后Hermes的Context Engine在处理类似任务时会检索历史推理链将高置信度的推理模式作为参考注入到新的推理上下文中。Agent每解决一次问题就为下一次类似问题铺好了路。六、总结与预告本篇拆解了Hermes Agent的LLM输出解析管线——从原始的混乱字符流到结构化的工程产物Stream Segmentation将字符流切分为有序片段Reasoning Extraction构建推理树并自动分类Tool Call Parsing三级策略确保工具调用的高可靠解析Intermediate State Assembly收集散落的中间数据Output Cleaning脱敏、去重、验证、标准化五层错误检测与自修复机制确保即使在最恶劣的输出场景下Agent也能优雅降级并持续学习。推理链的结构化存储让每一次思考都成为可复用的工程资产。但这条管线产生的数据——推理记录、工具调用日志、执行轨迹、修复历史——它们去了哪里如何被存储、检索和利用下一篇#24将拆解Trajectory日志工程——Hermes自进化数据层的写入口看推理、工具调用和执行轨迹如何被完整记录成为Agent进化的化石层。延伸阅读与交流本文涉及的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/