1. 项目概述为什么我要重写 Hermes Agent如果你最近在折腾大语言模型LLM的应用开发特别是想让模型能稳定、可靠地调用工具Tools或函数Function Calling那么你大概率听说过或者用过 Hermes Agent。它作为一个轻量级的代理框架设计初衷是好的旨在简化 Agent 的开发流程。然而在实际的生产环境测试和几个中型项目的深度集成中我发现了它存在的几个“硬伤”。这些硬伤不是小打小闹的 Bug而是会直接影响系统稳定性、开发效率和最终用户体验的核心问题。比如工具调用的结果解析时常“抽风”上下文管理在长对话中容易“失忆”错误处理机制简陋到几乎等于没有以及配置的繁琐程度让人望而却步。这些问题让我在 deadline 的压力下不得不频繁地深入源码进行 Hack写各种补丁。最终我决定不再修修补补而是基于 Hermes Agent 的核心思想结合我在实际业务中积累的经验从头重写一个更健壮、更易用的版本。这不是一个简单的 Fork 或升级而是一次针对其架构和实现逻辑的深度重构。今天我就来详细拆解我遇到的这四个硬伤并分享在重写过程中我是如何设计解决方案的。无论你是正在评估 Agent 框架还是已经深受其扰相信这些实战经验都能给你带来直接的帮助。2. 硬伤一脆弱的工具调用与结果解析工具调用是 Agent 的灵魂但原版 Hermes Agent 在这方面的表现却像是一个不稳定的“实习生”。2.1 问题深挖JSON 解析的“玄学”行为最让人头疼的是工具调用结果的解析。框架期望 LLM 返回一个格式严格的 JSON 来指定调用的工具名和参数。理论上现代 LLM如 GPT-4, Claude-3的 JSON 模式已经相当可靠。但原版实现中对模型返回内容的处理过于简单粗暴。它通常只是做一个简单的json.loads()一旦模型返回的文本在 JSON 之外包含了任何解释性文字例如“好的我将调用天气查询工具参数是{“city”: “北京”}”解析就会立即崩溃整个 Agent 流程也就中断了。更糟糕的是其错误处理仅仅是抛出一个异常没有任何 fallback 机制或重试逻辑。在实际场景中LLM 的输出具有不可预测性网络波动、提示词Prompt的微小变化都可能导致输出格式的轻微偏离。这种“非黑即白”的解析策略使得系统在生产环境中极其脆弱。我的解决方案实现一个“宽容且智能”的解析层我重写的核心之一就是构建了一个健壮的解析器。它的工作流程如下正则提取优先首先使用精心设计的正则表达式尝试从模型返回的整个文本块中提取出类似 JSON 结构的字符串。正则表达式会匹配{...}模式并具备一定的容错能力允许参数值内存在未转义的双引号这是一个常见问题。安全解析与验证提取到候选字符串后使用json.loads()在try...except块中进行解析。如果失败解析器会尝试一些自动修复策略例如补全缺失的引号、处理常见的转义错误。LLM 辅助修复终极后备如果上述自动化方法都失败解析器会启动一个轻量级的“修复流程”。它将有问题的文本和期望的 JSON Schema 再次发送给 LLM可以是一个更小、更快的模型专门请求其进行格式修正。这一步虽然增加了一点延迟但相比整个 Agent 流程失败代价小得多。结构化日志无论成功与否解析的每一步都会产生详细的、结构化的日志。这让我们能清晰地追踪是哪个工具的调用、因为什么原因出了问题为后续的提示词优化提供了数据依据。# 简化的容错解析函数示例 import json import re import logging def robust_json_parse(llm_output: str, tool_schema: dict) - dict: 尝试从 LLM 输出中稳健地解析出工具调用 JSON。 # 步骤1正则提取 json_pattern r\{[^{}]*\} matches re.finditer(json_pattern, llm_output, re.DOTALL) best_match None for match in matches: candidate match.group() # 步骤2尝试直接解析 try: parsed json.loads(candidate) # 简单验证结构 if “tool_name” in parsed and “parameters” in parsed: best_match parsed break except json.JSONDecodeError: # 记录但不立即失败 logging.debug(f“初步解析失败候选内容: {candidate}”) continue if best_match: return best_match # 步骤3尝试自动修复例如处理单引号或缺失引号 # 这里省略具体的修复代码可能涉及字符串替换和二次解析尝试 # 步骤4如果自动修复失败记录错误并准备进入LLM修复流程或抛出更友好的错误 logging.error(f“无法从输出中解析工具调用: {llm_output}”) # 可以在这里触发一个 fallback 或重试机制 raise RobustParseError(“工具调用解析失败已记录详细日志。”)注意正则表达式不是万能的复杂的嵌套 JSON 或格式极其混乱的文本可能无法处理。因此清晰的工具调用提示词仍然是第一道防线。我的经验是在系统提示词中明确要求“请只返回一个纯净的 JSON 对象不要包含任何其他解释文本”能预防 90% 的解析问题。2.2 工具注册与发现的笨重之处原版框架中工具的注册和管理往往分散在代码各处或者需要一个集中的大型配置文件。当工具数量增多时维护和查找变得困难。此外动态工具根据运行时状态生成或失效的工具支持很弱。重写设计基于装饰器的声明式工具注册我借鉴了现代 Web 框架如 FastAPI的思想采用装饰器来声明工具。这使得工具的定义与其实现紧密相连代码可读性极高也便于利用 IDE 的跳转和查找功能。from my_rewritten_agent import tool_registry tool_registry.register( name“get_weather”, description“根据城市名称查询实时天气”, parameters_schema{ “type”: “object”, “properties”: { “city”: {“type”: “string”, “description”: “城市名称如‘北京’、‘上海’”} }, “required”: [“city”] } ) async def get_weather(city: str) - str: 实际的工具实现函数 # 调用天气 API # ... return f“{city}的天气是晴25摄氏度。”工具注册中心 (tool_registry) 会自动收集所有被装饰的函数并为其生成符合 OpenAI Function Calling 标准的 Schema。Agent 在初始化时只需加载这个注册中心就能获取所有可用工具的描述。这种方式天然支持模块化你可以将不同领域的工具放在不同的 Python 模块中通过导入来“注册”。3. 硬伤二上下文管理的混乱与“失忆”Agent 经常需要处理多轮对话Multi-turn Conversation。原版 Hermes Agent 的上下文管理更像是一个“简易记事本”存在两个主要问题令牌Token计数不准确和关键信息丢失。3.1 Token 计数不准与成本失控LLM 的 API 调用成本与输入的 Token 数量直接相关。原版框架通常使用简单的字符串长度估算或简单的分词器这在混合了中英文、代码和特殊符号的对话历史中误差可能高达 20%-30%。这意味着你可能为实际 8000 Token 的内容支付 10000 Token 的费用或者更糟因为低估了 Token 数而导致请求被 API 拒绝超过上下文长度限制。解决方案集成精准的 Token 计数在重写版中我强制集成了与目标 LLM 匹配的精准分词器。例如如果主要对接 OpenAI GPT就使用tiktoken如果支持开源模型就集成transformers库的相应分词器。上下文管理器在每次添加或删除消息时都会实时、精确地计算 Token 消耗。import tiktoken class PreciseContextManager: def __init__(self, model: str “gpt-4”): self.encoding tiktoken.encoding_for_model(model) self.messages [] self._token_count 0 def add_message(self, role: str, content: str): message_token_count len(self.encoding.encode(content)) if self._token_count message_token_count MAX_TOKENS[model]: # 触发智能裁剪策略而非简单丢弃最旧消息 self._smart_trim(message_token_count) self.messages.append({“role”: role, “content”: content}) self._token_count message_token_count def _smart_trim(self, incoming_tokens: int): 智能裁剪策略优先压缩或删除非关键交互如冗长的工具输出保留最新的用户指令和系统提示。 # 实现细节可以给消息赋予权重或识别工具输出进行摘要 # ...此外上下文管理器会提供一个实时的 Token 使用量仪表盘通过日志或监控接口让开发者对成本有清晰的感知并能设置预警阈值。3.2 长对话中的关键信息丢失当对话历史超过模型上下文窗口时需要裁剪Trim旧消息。原版通常采用简单的“先进先出”FIFO策略即丢弃最老的几条消息。这极易导致灾难性遗忘Agent 可能忘记了对话早期设定的关键目标或约束条件。重写策略基于重要性的智能裁剪我实现了一个优先级裁剪系统。系统提示词System Prompt和最近几轮的用户指令User Message具有最高优先级永远不会被主动丢弃。对于较旧的消息尤其是冗长的工具执行结果Tool Call Result系统会尝试进行“摘要”自动摘要对于文本类型的工具输出使用一个轻量级的文本摘要模型或再次调用 LLM 的摘要功能将其压缩用摘要替换原始长文本节省大量 Token。重要性标记允许开发者在定义工具时标记其输出是否为“关键上下文”。例如一个“查询数据库架构”的工具输出可能是关键的而一个“计算器”工具的结果可能用完即弃。向量记忆库集成对于超长对话或需要持久记忆的场景我设计了插件式的记忆后端。可以将重要的对话片段或事实存储到向量数据库如 Chroma, Weaviate中。当后续对话需要相关背景时Agent 可以先从向量库中检索Recall相关信息再注入到当前上下文。这实现了“记忆的外挂”突破了模型原生上下文长度的限制。4. 硬伤三简陋的错误处理与重试机制在原版框架中错误处理基本靠开发者自己用try...except包裹整个 Agent 运行流程。网络超时、API 限流、工具执行异常、模型返回格式错误……所有这些都混在一起排查起来如同大海捞针。4.1 构建分层的错误处理体系我重写后的 Agent 将错误分为几个清晰的层级并针对每一层提供处理策略基础设施层错误如网络连接失败、API 密钥无效。这类错误应立即失败并给出明确的、可操作的建议如“请检查网络”或“API 密钥已过期”。模型层错误如 API 返回速率限制429错误、服务器内部错误5xx。对于速率限制框架应自动实现指数退避重试对于服务器错误可以进行有限次数的重试。工具执行层错误这是重写的重点。工具执行失败如调用的外部 API 无响应不应导致整个 Agent 崩溃。框架应捕获异常并将格式良好的错误信息如“天气服务暂时不可用”作为工具执行结果返回给 LLM。LLM 可以根据这个错误结果决定下一步行动例如尝试另一个工具或向用户解释情况。这赋予了 Agent 从错误中恢复的能力。逻辑层错误如解析失败、状态矛盾。这类错误需要记录最详细的上下文包括当时的对话历史、工具调用记录并触发告警方便开发者进行深度调试。class ResilientAgent: async def run_tool(self, tool_name: str, params: dict): try: result await self._execute_tool(tool_name, params) return {“status”: “success”, “data”: result} except ExternalServiceError as e: # 外部服务错误返回友好信息供LLM决策 logging.warning(f“工具{tool_name}调用外部服务失败: {e}”) return {“status”: “error”, “message”: f“{tool_name}服务暂时不可用原因: {str(e)}”} except Exception as e: # 未预期的内部错误记录并返回通用错误 logging.error(f“工具{tool_name}执行内部错误: {e}”, exc_infoTrue) return {“status”: “error”, “message”: “工具执行过程中发生意外错误”} async def _execute_tool(self, tool_name: str, params: dict): # 实际的工具分发和执行逻辑 tool_func self.tool_registry.get(tool_name) if not tool_func: raise ToolNotFoundError(f“工具 {tool_name} 未注册”) # 这里可能涉及异步调用、超时控制等 return await tool_func(**params)4.2 可配置的重试与熔断机制对于模型调用和外部工具调用我引入了可配置的重试策略。开发者可以针对不同的错误类型设置不同的重试次数、重试间隔如指数退避。同时借鉴微服务中的熔断器Circuit Breaker模式如果一个外部工具连续失败多次可以暂时将其“熔断”在一段时间内不再尝试调用直接返回降级结果避免雪崩效应。5. 硬伤四不友好的配置与集成体验原版框架的配置往往散落在环境变量、代码常量和配置文件里缺乏统一管理。想要切换 LLM 提供商比如从 OpenAI 切换到 Anthropic或者调整底层通信协议比如使用不同的 HTTP 客户端可能需要修改多处代码。5.1 基于 Pydantic 的集中化配置管理我使用 Pydantic 的BaseSettings来管理所有配置。这带来了类型安全、环境变量自动加载、配置验证等好处。所有 Agent 运行所需的参数——LLM 的 API 密钥、基础 URL、模型名称、超时设置、重试策略——都集中在一个配置对象中。from pydantic import BaseSettings, Field class AgentSettings(BaseSettings): llm_provider: str Field(“openai”, description“LLM 提供商: openai, anthropic, azure 等”) openai_api_key: str | None None anthropic_api_key: str | None None model_name: str Field(“gpt-4-turbo-preview”, description“使用的模型名称”) request_timeout: int Field(30, description“API请求超时时间秒”) max_retries: int Field(3, description“失败重试次数”) class Config: env_file “.env” env_prefix “AGENT_” # 环境变量如 AGENT_LLM_PROVIDER # 使用配置 settings AgentSettings() agent MyRewrittenAgent(configsettings)通过环境变量AGENT_LLM_PROVIDERanthropic就可以无缝切换底层 LLM而无需改动业务逻辑代码。5.2 模块化与清晰的扩展点重写版框架被明确划分为几个松耦合的模块LLM 客户端模块负责与不同的大模型 API 通信。定义统一的接口方便接入新的提供商。工具管理模块负责工具的注册、发现和调用。上下文管理模块负责对话历史的存储、Token 计数和智能裁剪。执行引擎模块负责驱动“思考-行动-观察”的循环逻辑。每个模块都通过清晰的抽象类或协议定义接口。如果你想替换默认的 HTTP 客户端比如使用httpx替代aiohttp或者想增加一个自定义的记忆存储只需要实现对应的接口并在配置中指定即可。这种设计让框架的定制和扩展变得非常直观。6. 重写后的核心架构与工作流经过上述改造新的 Agent 框架内部工作流变得更加清晰和健壮。一个典型的执行循环如下接收用户输入将用户问题放入上下文管理器。准备系统提示与上下文结合系统指令、裁剪后的历史对话并可能从向量记忆库中检索相关记忆组装成最终的 Prompt。调用 LLM通过可配置、带重试和熔断的客户端调用 LLM请求下一步动作可能是直接回答也可能是工具调用。容错解析使用“宽容且智能”的解析器处理 LLM 返回内容提取工具调用指令或最终回答。执行工具如果解析出工具调用则通过工具管理模块分发给对应的函数执行。执行过程被完整的错误处理包裹任何异常都会被转化为结构化的错误结果。处理工具结果将工具执行的成功结果或错误信息格式化为一条新的“工具返回”消息添加到上下文中。循环或返回如果上一步添加了工具返回则回到步骤 3让 LLM 根据工具结果进行下一步思考这就是 ReAct 模式中的“观察”。如果 LLM 返回的是最终答案则将其返回给用户并选择性地将本轮关键信息存入长期记忆。这个流程的每一个环节都包含了之前提到的改进精准的 Token 管理、智能的上下文裁剪、分层的错误处理和可替换的模块。7. 实战对比新旧版本处理复杂任务的差异让我们通过一个具体场景来感受差异“帮我分析过去三个月公司官网的访问数据总结趋势并写一份简短的报告。”这个任务可能涉及多个工具调用查询数据库获取原始数据、调用数据分析库生成图表、最后调用 LLM 撰写报告。原版 Hermes Agent 可能的表现在第一步查询数据库时如果 SQL 查询因网络波动超时工具调用抛出未捕获的异常Agent 直接崩溃用户收到一个 Python 栈追踪错误。或者LLM 在返回调用“生成图表”工具的指令时多了一句“我觉得用折线图比较好”导致 JSON 解析失败流程中断。即使前几步成功在生成报告时因为长达数十轮的对话历史超过了上下文限制且被简单裁剪Agent 可能已经忘记了“三个月”和“官网”这两个关键约束生成的报告文不对题。重写版 Agent 的表现数据库查询超时错误被捕获LLM 收到的结果是“数据库查询服务超时请稍后重试或检查网络。” LLM 可以理解这个错误并回复用户“数据服务暂时不可用请您稍等片刻再试或者我先为您撰写报告的大纲”LLM 返回内容附带了额外文本智能解析器成功提取出了正确的 JSON流程继续。长对话中系统提示词“你是数据分析助手…”和用户最初的问题“分析过去三个月官网数据…”被标记为高优先级始终保留。中间庞大的数据结果被自动摘要为“过去三个月访问量分别为 10万、12万、15万呈上升趋势。” 从而节省了大量 Token确保了最终报告不偏离核心目标。8. 迁移与适配建议如果你正在使用原版 Hermes Agent并考虑迁移或借鉴思路以下是我的建议评估痛点首先确认你遇到的是否是上述四个硬伤。如果只是简单使用且运行良好未必需要立即重写。渐进式重构不要试图一次性替换整个系统。可以从最痛的点开始例如先实现一个独立的、健壮的工具调用解析器替换掉原来的脆弱解析逻辑。然后再逐步重构上下文管理、错误处理等模块。关注接口兼容性如果你希望平滑迁移在设计新框架时可以暂时保留原版的主要对外接口如agent.run(query)内部实现则用新的健壮模块。这样业务代码改动最小。强化测试新的 Agent 框架必须配备完善的测试套件包括单元测试测试工具解析、上下文裁剪逻辑、集成测试模拟完整的多轮对话和混沌测试模拟网络延迟、API 失败等异常情况。这是保证其稳定性的基石。重写 Hermes Agent 的过程本质上是对生产级 AI 应用稳定性和可维护性的一次深度思考。它不再是一个简单的“模型调用包装器”而是一个具备韧性Resilience、可观测性Observability和可扩展性Extensibility的智能体运行时环境。这次经历让我深刻体会到在 AI 应用工程化的道路上对细节的打磨和对故障的预设与算法模型的选择同样重要。 从零重构AI Agent：解决工具调用、上下文管理与错误处理三大核心难题
1. 项目概述为什么我要重写 Hermes Agent如果你最近在折腾大语言模型LLM的应用开发特别是想让模型能稳定、可靠地调用工具Tools或函数Function Calling那么你大概率听说过或者用过 Hermes Agent。它作为一个轻量级的代理框架设计初衷是好的旨在简化 Agent 的开发流程。然而在实际的生产环境测试和几个中型项目的深度集成中我发现了它存在的几个“硬伤”。这些硬伤不是小打小闹的 Bug而是会直接影响系统稳定性、开发效率和最终用户体验的核心问题。比如工具调用的结果解析时常“抽风”上下文管理在长对话中容易“失忆”错误处理机制简陋到几乎等于没有以及配置的繁琐程度让人望而却步。这些问题让我在 deadline 的压力下不得不频繁地深入源码进行 Hack写各种补丁。最终我决定不再修修补补而是基于 Hermes Agent 的核心思想结合我在实际业务中积累的经验从头重写一个更健壮、更易用的版本。这不是一个简单的 Fork 或升级而是一次针对其架构和实现逻辑的深度重构。今天我就来详细拆解我遇到的这四个硬伤并分享在重写过程中我是如何设计解决方案的。无论你是正在评估 Agent 框架还是已经深受其扰相信这些实战经验都能给你带来直接的帮助。2. 硬伤一脆弱的工具调用与结果解析工具调用是 Agent 的灵魂但原版 Hermes Agent 在这方面的表现却像是一个不稳定的“实习生”。2.1 问题深挖JSON 解析的“玄学”行为最让人头疼的是工具调用结果的解析。框架期望 LLM 返回一个格式严格的 JSON 来指定调用的工具名和参数。理论上现代 LLM如 GPT-4, Claude-3的 JSON 模式已经相当可靠。但原版实现中对模型返回内容的处理过于简单粗暴。它通常只是做一个简单的json.loads()一旦模型返回的文本在 JSON 之外包含了任何解释性文字例如“好的我将调用天气查询工具参数是{“city”: “北京”}”解析就会立即崩溃整个 Agent 流程也就中断了。更糟糕的是其错误处理仅仅是抛出一个异常没有任何 fallback 机制或重试逻辑。在实际场景中LLM 的输出具有不可预测性网络波动、提示词Prompt的微小变化都可能导致输出格式的轻微偏离。这种“非黑即白”的解析策略使得系统在生产环境中极其脆弱。我的解决方案实现一个“宽容且智能”的解析层我重写的核心之一就是构建了一个健壮的解析器。它的工作流程如下正则提取优先首先使用精心设计的正则表达式尝试从模型返回的整个文本块中提取出类似 JSON 结构的字符串。正则表达式会匹配{...}模式并具备一定的容错能力允许参数值内存在未转义的双引号这是一个常见问题。安全解析与验证提取到候选字符串后使用json.loads()在try...except块中进行解析。如果失败解析器会尝试一些自动修复策略例如补全缺失的引号、处理常见的转义错误。LLM 辅助修复终极后备如果上述自动化方法都失败解析器会启动一个轻量级的“修复流程”。它将有问题的文本和期望的 JSON Schema 再次发送给 LLM可以是一个更小、更快的模型专门请求其进行格式修正。这一步虽然增加了一点延迟但相比整个 Agent 流程失败代价小得多。结构化日志无论成功与否解析的每一步都会产生详细的、结构化的日志。这让我们能清晰地追踪是哪个工具的调用、因为什么原因出了问题为后续的提示词优化提供了数据依据。# 简化的容错解析函数示例 import json import re import logging def robust_json_parse(llm_output: str, tool_schema: dict) - dict: 尝试从 LLM 输出中稳健地解析出工具调用 JSON。 # 步骤1正则提取 json_pattern r\{[^{}]*\} matches re.finditer(json_pattern, llm_output, re.DOTALL) best_match None for match in matches: candidate match.group() # 步骤2尝试直接解析 try: parsed json.loads(candidate) # 简单验证结构 if “tool_name” in parsed and “parameters” in parsed: best_match parsed break except json.JSONDecodeError: # 记录但不立即失败 logging.debug(f“初步解析失败候选内容: {candidate}”) continue if best_match: return best_match # 步骤3尝试自动修复例如处理单引号或缺失引号 # 这里省略具体的修复代码可能涉及字符串替换和二次解析尝试 # 步骤4如果自动修复失败记录错误并准备进入LLM修复流程或抛出更友好的错误 logging.error(f“无法从输出中解析工具调用: {llm_output}”) # 可以在这里触发一个 fallback 或重试机制 raise RobustParseError(“工具调用解析失败已记录详细日志。”)注意正则表达式不是万能的复杂的嵌套 JSON 或格式极其混乱的文本可能无法处理。因此清晰的工具调用提示词仍然是第一道防线。我的经验是在系统提示词中明确要求“请只返回一个纯净的 JSON 对象不要包含任何其他解释文本”能预防 90% 的解析问题。2.2 工具注册与发现的笨重之处原版框架中工具的注册和管理往往分散在代码各处或者需要一个集中的大型配置文件。当工具数量增多时维护和查找变得困难。此外动态工具根据运行时状态生成或失效的工具支持很弱。重写设计基于装饰器的声明式工具注册我借鉴了现代 Web 框架如 FastAPI的思想采用装饰器来声明工具。这使得工具的定义与其实现紧密相连代码可读性极高也便于利用 IDE 的跳转和查找功能。from my_rewritten_agent import tool_registry tool_registry.register( name“get_weather”, description“根据城市名称查询实时天气”, parameters_schema{ “type”: “object”, “properties”: { “city”: {“type”: “string”, “description”: “城市名称如‘北京’、‘上海’”} }, “required”: [“city”] } ) async def get_weather(city: str) - str: 实际的工具实现函数 # 调用天气 API # ... return f“{city}的天气是晴25摄氏度。”工具注册中心 (tool_registry) 会自动收集所有被装饰的函数并为其生成符合 OpenAI Function Calling 标准的 Schema。Agent 在初始化时只需加载这个注册中心就能获取所有可用工具的描述。这种方式天然支持模块化你可以将不同领域的工具放在不同的 Python 模块中通过导入来“注册”。3. 硬伤二上下文管理的混乱与“失忆”Agent 经常需要处理多轮对话Multi-turn Conversation。原版 Hermes Agent 的上下文管理更像是一个“简易记事本”存在两个主要问题令牌Token计数不准确和关键信息丢失。3.1 Token 计数不准与成本失控LLM 的 API 调用成本与输入的 Token 数量直接相关。原版框架通常使用简单的字符串长度估算或简单的分词器这在混合了中英文、代码和特殊符号的对话历史中误差可能高达 20%-30%。这意味着你可能为实际 8000 Token 的内容支付 10000 Token 的费用或者更糟因为低估了 Token 数而导致请求被 API 拒绝超过上下文长度限制。解决方案集成精准的 Token 计数在重写版中我强制集成了与目标 LLM 匹配的精准分词器。例如如果主要对接 OpenAI GPT就使用tiktoken如果支持开源模型就集成transformers库的相应分词器。上下文管理器在每次添加或删除消息时都会实时、精确地计算 Token 消耗。import tiktoken class PreciseContextManager: def __init__(self, model: str “gpt-4”): self.encoding tiktoken.encoding_for_model(model) self.messages [] self._token_count 0 def add_message(self, role: str, content: str): message_token_count len(self.encoding.encode(content)) if self._token_count message_token_count MAX_TOKENS[model]: # 触发智能裁剪策略而非简单丢弃最旧消息 self._smart_trim(message_token_count) self.messages.append({“role”: role, “content”: content}) self._token_count message_token_count def _smart_trim(self, incoming_tokens: int): 智能裁剪策略优先压缩或删除非关键交互如冗长的工具输出保留最新的用户指令和系统提示。 # 实现细节可以给消息赋予权重或识别工具输出进行摘要 # ...此外上下文管理器会提供一个实时的 Token 使用量仪表盘通过日志或监控接口让开发者对成本有清晰的感知并能设置预警阈值。3.2 长对话中的关键信息丢失当对话历史超过模型上下文窗口时需要裁剪Trim旧消息。原版通常采用简单的“先进先出”FIFO策略即丢弃最老的几条消息。这极易导致灾难性遗忘Agent 可能忘记了对话早期设定的关键目标或约束条件。重写策略基于重要性的智能裁剪我实现了一个优先级裁剪系统。系统提示词System Prompt和最近几轮的用户指令User Message具有最高优先级永远不会被主动丢弃。对于较旧的消息尤其是冗长的工具执行结果Tool Call Result系统会尝试进行“摘要”自动摘要对于文本类型的工具输出使用一个轻量级的文本摘要模型或再次调用 LLM 的摘要功能将其压缩用摘要替换原始长文本节省大量 Token。重要性标记允许开发者在定义工具时标记其输出是否为“关键上下文”。例如一个“查询数据库架构”的工具输出可能是关键的而一个“计算器”工具的结果可能用完即弃。向量记忆库集成对于超长对话或需要持久记忆的场景我设计了插件式的记忆后端。可以将重要的对话片段或事实存储到向量数据库如 Chroma, Weaviate中。当后续对话需要相关背景时Agent 可以先从向量库中检索Recall相关信息再注入到当前上下文。这实现了“记忆的外挂”突破了模型原生上下文长度的限制。4. 硬伤三简陋的错误处理与重试机制在原版框架中错误处理基本靠开发者自己用try...except包裹整个 Agent 运行流程。网络超时、API 限流、工具执行异常、模型返回格式错误……所有这些都混在一起排查起来如同大海捞针。4.1 构建分层的错误处理体系我重写后的 Agent 将错误分为几个清晰的层级并针对每一层提供处理策略基础设施层错误如网络连接失败、API 密钥无效。这类错误应立即失败并给出明确的、可操作的建议如“请检查网络”或“API 密钥已过期”。模型层错误如 API 返回速率限制429错误、服务器内部错误5xx。对于速率限制框架应自动实现指数退避重试对于服务器错误可以进行有限次数的重试。工具执行层错误这是重写的重点。工具执行失败如调用的外部 API 无响应不应导致整个 Agent 崩溃。框架应捕获异常并将格式良好的错误信息如“天气服务暂时不可用”作为工具执行结果返回给 LLM。LLM 可以根据这个错误结果决定下一步行动例如尝试另一个工具或向用户解释情况。这赋予了 Agent 从错误中恢复的能力。逻辑层错误如解析失败、状态矛盾。这类错误需要记录最详细的上下文包括当时的对话历史、工具调用记录并触发告警方便开发者进行深度调试。class ResilientAgent: async def run_tool(self, tool_name: str, params: dict): try: result await self._execute_tool(tool_name, params) return {“status”: “success”, “data”: result} except ExternalServiceError as e: # 外部服务错误返回友好信息供LLM决策 logging.warning(f“工具{tool_name}调用外部服务失败: {e}”) return {“status”: “error”, “message”: f“{tool_name}服务暂时不可用原因: {str(e)}”} except Exception as e: # 未预期的内部错误记录并返回通用错误 logging.error(f“工具{tool_name}执行内部错误: {e}”, exc_infoTrue) return {“status”: “error”, “message”: “工具执行过程中发生意外错误”} async def _execute_tool(self, tool_name: str, params: dict): # 实际的工具分发和执行逻辑 tool_func self.tool_registry.get(tool_name) if not tool_func: raise ToolNotFoundError(f“工具 {tool_name} 未注册”) # 这里可能涉及异步调用、超时控制等 return await tool_func(**params)4.2 可配置的重试与熔断机制对于模型调用和外部工具调用我引入了可配置的重试策略。开发者可以针对不同的错误类型设置不同的重试次数、重试间隔如指数退避。同时借鉴微服务中的熔断器Circuit Breaker模式如果一个外部工具连续失败多次可以暂时将其“熔断”在一段时间内不再尝试调用直接返回降级结果避免雪崩效应。5. 硬伤四不友好的配置与集成体验原版框架的配置往往散落在环境变量、代码常量和配置文件里缺乏统一管理。想要切换 LLM 提供商比如从 OpenAI 切换到 Anthropic或者调整底层通信协议比如使用不同的 HTTP 客户端可能需要修改多处代码。5.1 基于 Pydantic 的集中化配置管理我使用 Pydantic 的BaseSettings来管理所有配置。这带来了类型安全、环境变量自动加载、配置验证等好处。所有 Agent 运行所需的参数——LLM 的 API 密钥、基础 URL、模型名称、超时设置、重试策略——都集中在一个配置对象中。from pydantic import BaseSettings, Field class AgentSettings(BaseSettings): llm_provider: str Field(“openai”, description“LLM 提供商: openai, anthropic, azure 等”) openai_api_key: str | None None anthropic_api_key: str | None None model_name: str Field(“gpt-4-turbo-preview”, description“使用的模型名称”) request_timeout: int Field(30, description“API请求超时时间秒”) max_retries: int Field(3, description“失败重试次数”) class Config: env_file “.env” env_prefix “AGENT_” # 环境变量如 AGENT_LLM_PROVIDER # 使用配置 settings AgentSettings() agent MyRewrittenAgent(configsettings)通过环境变量AGENT_LLM_PROVIDERanthropic就可以无缝切换底层 LLM而无需改动业务逻辑代码。5.2 模块化与清晰的扩展点重写版框架被明确划分为几个松耦合的模块LLM 客户端模块负责与不同的大模型 API 通信。定义统一的接口方便接入新的提供商。工具管理模块负责工具的注册、发现和调用。上下文管理模块负责对话历史的存储、Token 计数和智能裁剪。执行引擎模块负责驱动“思考-行动-观察”的循环逻辑。每个模块都通过清晰的抽象类或协议定义接口。如果你想替换默认的 HTTP 客户端比如使用httpx替代aiohttp或者想增加一个自定义的记忆存储只需要实现对应的接口并在配置中指定即可。这种设计让框架的定制和扩展变得非常直观。6. 重写后的核心架构与工作流经过上述改造新的 Agent 框架内部工作流变得更加清晰和健壮。一个典型的执行循环如下接收用户输入将用户问题放入上下文管理器。准备系统提示与上下文结合系统指令、裁剪后的历史对话并可能从向量记忆库中检索相关记忆组装成最终的 Prompt。调用 LLM通过可配置、带重试和熔断的客户端调用 LLM请求下一步动作可能是直接回答也可能是工具调用。容错解析使用“宽容且智能”的解析器处理 LLM 返回内容提取工具调用指令或最终回答。执行工具如果解析出工具调用则通过工具管理模块分发给对应的函数执行。执行过程被完整的错误处理包裹任何异常都会被转化为结构化的错误结果。处理工具结果将工具执行的成功结果或错误信息格式化为一条新的“工具返回”消息添加到上下文中。循环或返回如果上一步添加了工具返回则回到步骤 3让 LLM 根据工具结果进行下一步思考这就是 ReAct 模式中的“观察”。如果 LLM 返回的是最终答案则将其返回给用户并选择性地将本轮关键信息存入长期记忆。这个流程的每一个环节都包含了之前提到的改进精准的 Token 管理、智能的上下文裁剪、分层的错误处理和可替换的模块。7. 实战对比新旧版本处理复杂任务的差异让我们通过一个具体场景来感受差异“帮我分析过去三个月公司官网的访问数据总结趋势并写一份简短的报告。”这个任务可能涉及多个工具调用查询数据库获取原始数据、调用数据分析库生成图表、最后调用 LLM 撰写报告。原版 Hermes Agent 可能的表现在第一步查询数据库时如果 SQL 查询因网络波动超时工具调用抛出未捕获的异常Agent 直接崩溃用户收到一个 Python 栈追踪错误。或者LLM 在返回调用“生成图表”工具的指令时多了一句“我觉得用折线图比较好”导致 JSON 解析失败流程中断。即使前几步成功在生成报告时因为长达数十轮的对话历史超过了上下文限制且被简单裁剪Agent 可能已经忘记了“三个月”和“官网”这两个关键约束生成的报告文不对题。重写版 Agent 的表现数据库查询超时错误被捕获LLM 收到的结果是“数据库查询服务超时请稍后重试或检查网络。” LLM 可以理解这个错误并回复用户“数据服务暂时不可用请您稍等片刻再试或者我先为您撰写报告的大纲”LLM 返回内容附带了额外文本智能解析器成功提取出了正确的 JSON流程继续。长对话中系统提示词“你是数据分析助手…”和用户最初的问题“分析过去三个月官网数据…”被标记为高优先级始终保留。中间庞大的数据结果被自动摘要为“过去三个月访问量分别为 10万、12万、15万呈上升趋势。” 从而节省了大量 Token确保了最终报告不偏离核心目标。8. 迁移与适配建议如果你正在使用原版 Hermes Agent并考虑迁移或借鉴思路以下是我的建议评估痛点首先确认你遇到的是否是上述四个硬伤。如果只是简单使用且运行良好未必需要立即重写。渐进式重构不要试图一次性替换整个系统。可以从最痛的点开始例如先实现一个独立的、健壮的工具调用解析器替换掉原来的脆弱解析逻辑。然后再逐步重构上下文管理、错误处理等模块。关注接口兼容性如果你希望平滑迁移在设计新框架时可以暂时保留原版的主要对外接口如agent.run(query)内部实现则用新的健壮模块。这样业务代码改动最小。强化测试新的 Agent 框架必须配备完善的测试套件包括单元测试测试工具解析、上下文裁剪逻辑、集成测试模拟完整的多轮对话和混沌测试模拟网络延迟、API 失败等异常情况。这是保证其稳定性的基石。重写 Hermes Agent 的过程本质上是对生产级 AI 应用稳定性和可维护性的一次深度思考。它不再是一个简单的“模型调用包装器”而是一个具备韧性Resilience、可观测性Observability和可扩展性Extensibility的智能体运行时环境。这次经历让我深刻体会到在 AI 应用工程化的道路上对细节的打磨和对故障的预设与算法模型的选择同样重要。