Hermes Agent Chat 方法分析

那小子、真烦2026-05-28 13:52

📍 核心入口方法

chat() 方法

  • 位置 ：run_agent.py:15573-15585
  • 判断依据：最外层问答接口，通过 API 签名（输入字符串、输出字符串）标识为"简洁接口"。

✅ 对应模块 QA

Q：chat() 方法的核心作用是什么？
A ：作为 Hermes 最外层的无状态问答入口，接收用户文本消息，内部委托 run_conversation() 执行完整对话、工具调用、上下文压缩及记忆更新全流程，最终仅返回纯字符串回答。支持流式回调（stream_callback），适配 TTS、实时输出等场景，极大降低外部集成成本。

🏗️ 七层架构详解

第一层：入口方法层 - chat()

职责 ：提供简洁的外部接口，隐藏内部复杂性。
特点：无状态设计、支持流式回调、返回纯字符串。

第二层：核心对话循环层 - run_conversation()

位置 ：run_agent.py:11675-15571

2.1 初始化阶段

关键初始化步骤：

  1. 安全标准流安装 ：run_agent.py:11708

    • 大白话：给输出加个"防弹衣"。
    • 为啥要做：有时候 Agent 跑在后台或者 Docker 里，如果输出管道突然断了（比如你关掉了终端），程序会直接报错崩溃。这一步就是告诉程序："就算没人看你的输出，你也别崩，继续干活。"

  2. 数据库会话确保 ：run_agent.py:11710

    • 大白话：先占个座，确认数据库能连上。
    • 为啥要做：就像去餐厅先拿号一样。先确定数据库链接是好的，保证待会儿聊天的内容能存进去。如果这步就挂了，后面聊再多也白搭；同时这也为后面"上下文压缩"时能找到历史记录打个基础。

  3. 运行时主模型设置 ：run_agent.py:11726-11731

    • 大白话：同步一下最新的"大脑"型号。
    • 为啥要做：防止工具"记错账"。有时候用户在命令行临时换了个模型，但配置文件还没改。这一步就是告诉所有工具："别翻旧配置文件了，现在用的是这个新模型"，避免工具因为型号对不上而出错。

  4. 会话上下文绑定 ：run_agent.py:11736-11737

    • 大白话：给日志贴个"专属标签"。
    • 为啥要做 ：Agent 运行时会打印很多日志。如果不贴标签，所有对话的日志都混在一起，根本分不清哪句是谁说的。贴上 session_id 后，你想查某次对话的毛病，一搜标签全出来了。

  5. 技能写入来源标记 ：run_agent.py:11744-11745

    • 大白话：盖个章，分清是谁干的活。
    • 为啥要做：Agent 有两种学习方式：一种是你教它的，一种是它自己偷偷复盘学到的。这一步就是为了区分：这条经验到底是用户教的，还是系统自己悟出来的，防止以后搞混了。

  6. 重试计数器重置 ：run_agent.py:11779-11798

    • 大白话：清空"错误小本本"，重新开始。
    • 为啥要做：上一轮对话如果出错太多，计数器可能已经爆表了。如果不重置，新一轮对话刚开始就会因为"历史遗留问题"被直接判死刑。重置后，每一轮对话都有公平的 3 次重试机会。

✅ 本阶段配套 QA

Q：会话数据库主要存储哪些字段？
A ：在初始化阶段完成数据库会话绑定，核心存储字段包含：session_id、model、provider、platform、token 及全量会话统计数据；同时关键存储 parent_session_id 字段，用于搭建会话谱系树，实现会话关联追溯。

2.2 内存管理机制
A. 内置内存（MemoryStore）
  • 位置 ：run_agent.py:5971-5980
  • 工作机制 ：
    • 存储格式：JSONL 文件（~/.hermes/memory/）。
    • 触发时机 ：每 N 回合自动触发审查（_memory_nudge_interval，默认 5 轮）。
    • 提取方式：后台线程异步执行。
    • 注入位置：系统提示词的"易变层"。
B. 外部内存提供商（MemoryManager）
  • 预取逻辑 ：run_agent.py:12128-12146 - 通知新回合开始并预取上下文。
  • 注入逻辑 ：run_agent.py:12296-12312 - 将临时上下文注入到当前回合的用户消息中。
  • 关键设计决策 ：
    • 注入位置：用户消息而非系统提示词。
    • 原因：保持系统提示词字节级稳定，最大化 prompt cache 命中率。
    • 缓存策略：每回合预取一次，所有工具调用共享。
C. 后台自我审查机制
  • 触发条件 ：run_agent.py:11910-11917 - 计数器累加达到阈值后触发。
  • 执行流程：计数器累加 → 达到阈值 → 后台线程异步执行 → 保存到 JSONL → 下次构建提示词时加载。

✅ 内存与自我审查模块 全套 QA（带案例）

Q13：后台记忆审查什么时候触发？（带案例）
A ：系统内置对话轮次计数器 _turns_since_memory，每完成一轮用户与助手完整交互，计数器自动+1。当数值 ≥5 轮时，标记 _should_review_memory = True，计数器归零，后台异步启动记忆与技能审查，全程不阻塞当前对话。
触发真实案例：用户在连续 5 轮对话中表达了"爱吃川菜"、"编写 Python 脚本"等信息，第 5 轮结束后触发后台审查并入库沉淀。

Q14：审查代理具体做什么？
A：后台异步审查启动后，读取当前累计的全部对话历史，从「用户画像」和「场景技能」两个维度筛选可长期复用的有效信息，分别更新 USER.md（用户画像） 和 MEMORY.md（场景记忆）。若无沉淀价值，则返回 Nothing to save。

Q15：三套审查提示词分别负责什么？
A：

  1. 记忆审查：专注抓取用户个人身份、长期偏好、生活习惯、使用期望等个人特质信息。
  2. 技能审查：专注沉淀任务执行流程、用户风格纠正、工具调试方法、固定工作模式。
  3. 组合审查：整合前两套规则，同时完成用户记忆更新和任务技能迭代，是日常对话主用模式。

Q16：USER.md 与 MEMORY.md 两个记忆文件分工区别？（实例对比）
A：两者存储边界完全隔离：

  • USER.md（用户是谁：事实、偏好、特质）：示例：用户喜欢吃川菜、偏爱辣味回复风格。
  • MEMORY.md（用户在做什么：场景、技术、经历）：示例：用户经常编写、优化 Python 脚本，日常从事代码开发相关工作。

Q17：记忆文件字符上限是多少？
A ：为防止记忆无限膨胀，系统设置固定字符上限：MEMORY.md 默认 2200 字符（≈800 tokens），USER.md 默认 1375 字符（≈500 tokens）。用户可通过修改本地 ~/.hermes/config.yaml 手动调大上限。

Q18：记忆写入的时机？
A：

  1. 阈值自动触发：每累计 5 轮对话，后台审查代理自动筛选、写入。
  2. 用户主动触发：用户明确指令「记住这个」时，LLM 主动调用 memory 工具即时写入。
  3. 插件异步同步：Honcho、Mem0 等外部记忆插件，每轮对话结束后异步同步更新。

Q19：哪些内容值得存记忆？
A：仅留存长期有效、可复用的核心信息：

  1. 用户自身固定信息：长期偏好、生活习惯、身份特质、固定诉求。
  2. 用户对 AI 的固定使用期望：回复风格、排版格式、固定工作方式、输出要求。
2.4 MCP 协议集成（连接外部世界的桥梁）

大白话：Hermes 是怎么连上数据库、GitHub 或者 Slack 的？

  • 位置 ：run_agent.py:12100-12140 & <tools/mcp_client.py>
  • 核心逻辑 ：
    1. 动态发现：在对话初始化时，Hermes 会扫描配置文件中的 MCP Servers。比如你配置了一个"飞书 MCP"，Hermes 就会自动把"发送消息"、"读取文档"这些能力加载进来。
    2. 标准化接入：不管后端是 Python 脚本还是 Node.js 服务，只要符合 MCP 协议，Hermes 就能把它们当成普通工具一样调用。
    3. 上下文注入：MCP 服务器不仅能提供工具，还能提供"资源"（Resources）。比如连上 GitHub MCP 后，它能把最近的 Issue 列表直接塞进你的系统提示词里，让模型"看"到最新的项目状态。

✅ MCP 集成 QA

Q：MCP 在 Hermes 中扮演什么角色？
A：它是 Agent 的"万能插头"。通过 MCP，Hermes 可以即插即用各种外部服务，无需为每个新工具重写代码。

Q：MCP 工具和内置工具有什么区别？
A ：内置工具（如 write_file）是 Hermes 自带的，跑在本地；MCP 工具通常由外部服务器提供，可能涉及网络请求或第三方 API 授权。

2.3 上下文压缩机制
A. 什么时候触发？（触发条件）

想象一下，你的模型窗口是 128K，但系统为了安全起见，只用到 85%（约 108K）就会开始准备压缩。

  1. 预检触发（进门前检查） ：run_agent.py:11996-12058
    • 场景：当你加载一个已经聊了 100 行的旧会话时，系统会先算一下总 Token 数。如果一进来就超标了，它会立刻在后台把历史消息"瘦身"，然后再让你开始说话。
  2. 运行中触发（边聊边看） ：
    • 场景：每轮对话结束后，如果发现加上工具返回的结果，Token 快要撑爆窗口了，系统会在下一轮调用 API 前自动触发压缩。
  3. 报错触发（救火队员） ：
    • 场景 ：如果 API 直接报了 400 Context Overflow 错误，说明刚才没算准，这时候系统会紧急启动压缩来"救场"。
B. 触发后的逻辑是怎么样的？（以 100 行记录为例）

假设你现在有 100 行对话，触发了压缩，系统会执行一套"去头、留尾、缩中间"的手术：

  • 第一步：保护"头"和"尾"
    • 头（前 3 行）：这是你们对话的起因（比如"帮我写个 Python 脚本"），必须留着，不然模型不知道你在干嘛。
    • 尾（最近 20K Token）：这是你们刚才聊的最新进展，必须留着，保证对话连贯。
  • 第二步：压缩"中间"
    • 中间的 90 多行会被交给一个专门的"摘要模型"。它会把这 90 行浓缩成一段话，比如："用户之前讨论了 API 设计，确定了使用 RESTful 风格，并修复了两个 Bug。"
  • 第三步：会话"换血"（关键步骤）
    • 压缩完成后，原来的 100 行记录会被替换成：3 行开头 + 1 段摘要 + 最近的对话。
    • 注意 ：这时候数据库里会产生一条新记录（子会话），它通过 parent_session_id 连着旧的那 100 行。这样你以后想看原始记录还能找回来。
C. 第一次压缩和后面一次有什么区别？
维度 第一次压缩 第二次及后续压缩
处理对象 真实的、完整的 100 行对话记录。 包含"上一次摘要"的记录。
摘要方式 全量生成：从头到尾总结一遍。 增量更新：在旧摘要的基础上，把新产生的对话补进去。
系统提示词 第一次构建，建立缓存。 重新构建，但因为稳定层没变，缓存依然有效。
会话谱系 产生第一个子会话（Parent -> Child 1）。 产生更深层的子会话（Child 1 -> Child 2）。

💡 为什么要有这种区别？

因为如果每次都把几百行的历史记录重新读一遍再总结，太慢也太贵了。增量更新就像写日记续集，只需要看昨天的总结和今天发生的事，效率极高。

✅ 上下文压缩 & 会话谱系 全套 QA（带案例）

Q1：parent_session_id 的核心作用是什么？
A：核心用于构建会话谱系树，是实现超长对话续接、会话分支创建、全量历史会话追溯的核心标识。让压缩生成的新会话、用户手动创建的分支会话，能够精准绑定旧会话上下文，彻底解决长对话断裂问题。

Q2：哪些场景会生成带 parent_session_id 的子会话？
A：

  1. 会话自动压缩场景：超长会话触发压缩后，新生成的精简会话会绑定旧会话 ID 作为父 ID。
  2. 用户手动分支场景：用户在任意历史会话基础上新建对话分支，分支会话自动关联原会话父 ID。

Q3：会话压缩时系统具体做了哪些操作？（附完整谱系案例）
A：

  1. 旧会话标记终止 ：写入 end_reason = "compression"。
  2. 通知外部插件 ：执行 on_pre_compress。
  3. 生成全新子会话：重置消息列表。
  4. 建立父子关联 ：新会话 parent_session_id 指向旧会话。
  5. 自动传播会话标题 。
    谱系案例：会话 A (root) → 压缩 → 会话 B (parent=A) → 压缩 → 会话 C (parent=B)。

Q4：Hermes 如何处理会话标题冲突？
A：系统内置标题自动规避机制，在自动生成压缩会话或用户手动创建分支时，会自动检测存量会话标题，重复标题自动编号微调（如「项目分析」→「项目分析 #2」）。

Q6：什么时候会触发上下文自动压缩？
A：

  1. 加载历史会话时，整体 token 总量超标。
  2. 对话运行中主动抛出 Context Overflow Error。
  3. 新一轮用户消息/工具调用，剩余上下文窗口容量不足以承载。
  4. 每轮对话结束后自动预检，token 超标立即触发。

Q7：压缩阈值如何计算？（带数值案例）
A ：系统固定采用 85% 阈值比例。公式：threshold_tokens = 模型最大上下文长度 × 0.85。例如 128K 模型阈值为 108.8K tokens。

Q8：压缩时哪些消息保留、哪些被压缩？（区段策略）
A：

  • ✅ 头部强制保护：默认前 3 条初始消息永久保留。
  • ✅ 尾部优先保留：留存最近 20K tokens 最新对话。
  • ❌ 中间区段压缩：历史老旧对话、冗余工具返回结果统一结构化压缩。

Q9：压缩具体做了哪些瘦身优化？效果如何？
A：清理重复工具执行结果、用结构化摘要替换超长工具返回内容、截断冗余参数。整套流程可稳定减少 20%--30% token 占用。

Q10：结构化摘要压缩的完整流程？
A：前置冷却校验 → 智能区分模式（增量/全新） → 固定结构化输出（任务-目标-决策-文件-进度） → 自动脱敏 → 模型降级容错 → 频次限制（最多 3 次）。

Q11：压缩过程被用户新消息打断怎么办？
A：系统配备实时中断检测机制，一旦捕捉到用户新消息，立即终止当前所有压缩流程，优先响应用户操作。

Q12：压缩会通知外部记忆插件吗？
A ：会。压缩清理上下文之前，系统会主动执行 _memory_manager.on_pre_compress()，通知插件提前保存核心关键信息。

第三层：系统提示词三层结构

位置 ：run_agent.py:5799-6006

3.1 Stable Tier（稳定层）
  • 内容：SOUL.md 身份定义、工具指导、Kanban 指导、计算机使用指导、Nous 订阅提示、Google/OpenAI 模型操作指导、技能系统提示、环境提示、平台特定提示。
  • 特点：字节级稳定，整个会话生命周期不变；Anthropic cache_control 标记在此层。
3.2 Context Tier（上下文层）
  • 内容 ：自定义系统消息（system_message）、项目上下文文件（AGENTS.md, .cursorrules 等）。
  • 特点：cwd 依赖，可能在不同会话间变化。
3.3 Volatile Tier（易变层）
  • 内容：内置内存快照（MemoryStore）、用户画像（USER.md）、外部内存提供商块（MemoryManager）、时间戳行。
  • 特点：每会话/每回合可能变化，不缓存。

💡 真实案例：系统提示词是如何组装的？

假设你正在一个 Python 项目中与 Hermes 对话，你的系统提示词将由以下三部分拼接而成：

层级 包含内容示例 缓存状态
Stable Tier "你是 Hermes Agent，一个强大的 AI 助手... 你必须使用工具..." 🔒 全局缓存
Context Tier "当前项目 AGENTS.md 规定：请使用 pytest 进行测试..." 🔄 会话缓存
Volatile Tier "当前时间：2024-05-27... 用户画像：你喜欢简洁的代码... 记忆：上次讨论了 API 设计..." ❌ 无缓存

✅ 提示词缓存机制 QA

Q26：系统提示词组装顺序？（缓存分层）
A：严格按照「稳定→次稳定→动态」三层顺序拼接：

  1. 永久稳定层（全局缓存）：SOUL.md 固定身份、核心运行规则。
  2. 会话稳定层（会话缓存）：AGENTS.md 全局配置、项目专属规则。
  3. 动态可变层（无缓存）：实时时间戳、会话元数据、USER/MEMORY 记忆。

Q27：缓存带来的性能优势？
A：首次调用需全量加载；后续复用调用时，稳定层、会话层直接缓存命中，仅重新组装动态可变层内容，大幅减少 token 消耗和计算开销。

Q28：外部内存插件如何接入系统提示？
A ：所有外部记忆服务商统一通过 self._memory_manager.build_system_prompt() 专属方法，将外部存储的记忆数据整合组装，最终全局注入系统提示词。

第四层：主对话循环

位置 ：run_agent.py:12148-15200

4.1 循环控制
  • 位置 ：run_agent.py:12148
  • 退出条件：达到最大迭代次数（默认 90）、迭代预算耗尽、用户中断、工具护栏阻止、非重试客户端错误。
4.2 API 调用准备
4.3 API 调用执行
  • 位置 ：run_agent.py:12362
  • 重试逻辑：最多重试 3 次，指数退避 + 随机抖动。特殊处理：413（触发压缩）、429（等待 Retry-After）、400（触发压缩或降级）、UnicodeEncodeError（清理代理字符）、图像拒绝（剥离图像）。
4.4 意图拆解与任务规划（大脑的决策时刻）

大白话：模型是怎么把一句模糊的指令变成具体行动的？

  • 位置 ：run_agent.py:12370-12410 & run_agent.py:14582-14893
  • 拆解逻辑 ：
    1. 思维链（Think Tag） ：模型在输出工具前，会先在 <think> 标签里"碎碎念"。比如："用户想看代码结构，我得先列出目录，再看几个关键文件。"这就是意图拆解的过程。
    2. 多步拆解 ：如果任务复杂，模型会一口气给出好几个工具调用。系统在 run_agent.py:14582 会把这些拆解后的动作全部抓出来排队。
    3. 看板管理（Kanban）：对于超长任务，Hermes 要求模型维护一个"任务清单"，每拆解出一个新意图，就更新一下状态。

✅ 意图拆解 QA

Q：Hermes 是如何拆解复杂指令的？
A ：依靠 LLM 的原生推理能力 + 结构化提示词。模型会在 <think> 标签中进行自我对话，将模糊指令（如"优化这个项目"）拆解为具体的原子操作（如"运行测试"、"修改 A 文件"）。

Q：意图拆解出错怎么办？
A：如果模型拆解错了，它在下一轮看到工具返回的结果后，会通过"自我修正"机制重新调整计划。这就是为什么主循环要不断迭代的原因。

4.5 响应处理与循环收尾
  • Token 统计 ：run_agent.py:12370-12410 - 更新压缩器、累加会话统计、持久化到数据库。
  • 助手消息构建 ：run_agent.py:12412 - 标准化助手消息。
  • 工具调用检测与循环收尾 ：run_agent.py:14582-14893 - 捕获内容和工具调用组合、追加消息、执行工具、处理护栏停止信号。

✅ 主对话循环模块全套QA

Q29：主对话循环的核心运行逻辑是什么？
A：采用「迭代循环+工具驱动」模式：每轮迭代完成消息清洗、API 组装、模型推理、响应解析、工具执行；检测到工具调用则持续循环，无工具调用则终止输出最终回答。

Q30：主循环设置多重退出条件的意义？
A：保障系统稳定性：最大迭代次数防死循环、预算限制资源消耗、用户中断保实时性、工具护栏拦截违规、客户端错误终止异常。

Q31：API消息组装阶段的核心优化手段有哪些？
A：

  1. 清洗损坏参数、修复角色交替。
  2. 注入外部内存预取、插件临时上下文。
  3. 剥离内部私有字段，适配各类模型 API。
  4. 启用 Anthropic 分层缓存。
  5. 规范化 JSON 格式、清理非法代理字符。

Q32：模型API调用的重试机制如何工作？
A：默认 3 次重试，指数退避 + 随机抖动。针对超大负载、限流、溢出、编码错误、图像兼容等报错做定制化预处理后重试。

Q33：Token统计模块的核心作用？
A：实时全维度统计会话 Token 消耗（输入、输出、缓存读写、推理），同步更新压缩器阈值，持久化至数据库实现成本核算与资源监控。

第五层：工具调用执行层

核心方法：_execute_tool_calls()

5.1 工具调用前置校验
  • 逻辑说明 ：在主循环中已完成合法性校验（run_agent.py:14590-14640），包括工具白名单校验和参数 JSON 合法性校验。
5.2 工具并发执行机制
  • 位置 ：run_agent.py:10602-10850
  • 执行策略：无依赖工具并行执行（最大 5 线程），存在上下文依赖的工具串行执行。
5.3 工具结果封装与返回
  • 逻辑说明：统一标准化工具返回格式，携带工具 ID、名称、执行结果、异常信息，供主循环解析处理。

✅ 工具调用模块全套QA

Q34：工具调用的前置校验包含哪些维度？
A：

  1. 工具白名单校验：拦截未授权工具。
  2. 参数合法性校验：校验入参 JSON 格式，超限直接终止任务。

Q35：工具为什么采用有限并发执行策略？
A：默认最大 5 线程并发。既提升多工具场景效率，又防止过多线程抢占资源引发限流或卡顿，平衡效率与稳定性。

Q36：工具执行失败后系统如何处理？
A：自动分类容错：参数错误触发 JSON 重试、工具非法触发无效工具重试；单次失败不影响其他工具；重试超限直接终止并返回报错。

第六层：后置记忆沉淀层

执行时机：单轮对话、工具调用全部结束后，主循环退出后置执行。

6.1 自动记忆沉淀流程
  • 位置 ：run_agent.py:15300-15350
  • 逻辑说明：若满足审查条件，后台异步启动记忆审查；同步提交会话记忆。
6.2 异步审查核心逻辑
  • 逻辑说明：后台独立线程运行记忆、技能双维度审查，自动过滤无效信息，增量更新 USER.md 和 MEMORY.md。

✅ 后置记忆沉淀QA

Q37：记忆沉淀为什么采用异步线程执行？
A：优化用户交互体验。记忆审查、解析、写入属于耗时操作，异步执行不阻塞主对话响应，保障长期记忆沉淀不丢失。

Q38：单轮对话结束后一定会触发记忆更新吗？
A：不会。仅满足条件触发：开启记忆功能、存在合法记忆工具、达到 5 轮对话阈值。

第七层：结果封装与返回层

核心职责：汇总全流程会话数据、统计信息、历史记录，标准化封装返回结果。

7.1 最终结果封装逻辑
  • 位置 ：run_agent.py:15400-15571
  • 返回结构 ：包含 final_response、messages、session_id、exit_reason、token_usage、api_call_count、compressed。
7.2 核心返回字段说明
  • final_response：纯文本最终回答。
  • messages：完整对话历史、工具交互记录。
  • session_id：当前会话唯一标识。
  • exit_reason：对话终止原因（normal, interrupted_by_user, budget_exhausted, tool_terminated, compression, guardrail_halt, error）。
  • token_usage：全量 Token 消耗统计。

✅ 结果封装层QA

Q39：chat()和run_conversation()返回值区别是什么？
A：

  • chat()：轻量化对外接口，仅返回纯文本最终回答。
  • run_conversation()：底层核心方法，返回完整结构化字典，包含会话 ID、Token 统计、对话历史、终止原因等全量数据。

Q40：exit_reason字段的业务价值？
A：精准标记对话终止根因，支持问题定位与流程优化。可快速区分正常流程与异常中断场景，便于日志排查、运维监控。

📌 全文核心总结（七层架构闭环）

Hermes Agent 完整对话流程依托七层分层架构实现全链路可控、可扩展、高性能运行：

  1. 第一层 入口方法层：轻量化对外统一接口，屏蔽底层复杂逻辑。
  2. 第二层 核心循环初始化层：完成会话绑定、状态重置、内存预加载、运行环境初始化。
  3. 第三层 提示词分层构建层：稳定层、上下文层、易变层分层组装，适配缓存机制。
  4. 第四层 主对话循环层：核心调度中枢，完成模型推理、消息迭代、异常重试、资源管控。
  5. 第五层 工具调用执行层：合法校验、并发执行、容错处理，支撑 Agent 工具化能力。
  6. 第六层 后置记忆沉淀层：异步无感完成用户画像、场景记忆迭代，实现模型持续学习。
  7. 第七层 结果封装返回层：标准化输出结果，适配各类业务场景，完成对话闭环。

整套架构核心优势 ：分层解耦、缓存优化、异步记忆、会话谱系、容错稳健、资源可控，完美支撑超长对话、工具复用、持续学习、稳定交互四大核心能力。

相关推荐
爱喝水的鱼丶1 小时前
SAP-ABAP：变量、常量、结构与内表声明（10篇博客合集） 第六篇：ABAP 7.40+新特性：声明语法的简化写法与兼容注意事项
运维·服务器·开发语言·学习·算法·sap·abap
上海合宙LuatOS1 小时前
Air8000低功耗指南
开发语言·物联网·php·lua
happymaker06261 小时前
SpringBoot使用Thymeleaf模板引擎，前端的基本语法
开发语言·python
01_ice1 小时前
Java抽象类和接口
java·开发语言
小马爱打代码1 小时前
Spring源码 第七篇：Spring Boot 自动配置原理深度拆解
java·spring boot·spring
日取其半万世不竭2 小时前
给 Docker 容器设置 CPU 和内存限制，避免单个服务拖垮整机
java·docker·容器
铁皮哥2 小时前
【agent 开发】Claude Code 的 Skill 是怎么被加载的？从 name/description 到 SKILL.md 再到资源文件
java·服务器·数据库·python·gitee·github·软件工程
小糯米6012 小时前
C语言 自定义类型：结构体 与 联合体
c语言·开发语言·数据结构
jieyucx2 小时前
Go 语言 JSON 序列化与反序列化
开发语言·golang·json·序列化
热门推荐
01GitHub 镜像站点02【AI】2026 年具身智能模型和世界模型总结03Codex 接入 DeepSeek API 完整配置文档04【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法05裂开！ChatGPT 居然开始要手机号验证，附详细解决方法06CC-Switch & Claude 基于 Linux 服务器安装使用指南07DeepSeek V4 + Claude Code thinking mode 400 错误修复方案082026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot09CC-Switch 全平台下载、安装与使用全指南（Windows/macOS/Linux）10Windows端Codex接入第三方模型（DeekSeek，BaiLian)