【全栈开发 3】静态网页部署
完成 HTML、CSS 和 JavaScript 后，网页目前只存在于本地。要让其他用户通过公网访问，需要将代码同步到云服务器，再由 Nginx 对外提供静态文件。 部署链路整个部署过程涉及三个位置： 1234567本地开发环境 ↓ git pushGitHub 远程仓库 ↓ git pull云服务器 ↓ Nginx公网浏览器 各部分的职责如下： 本地环境用于编写、调试和提交代码。 GitHub 用于保存代码，并在本地与服务器之间同步版本。 云服务器运行在公网环境中，保存用于部署的网站代码。 Nginx 监听 HTTP 或 HTTPS 请求，并返回对应的静态文件。 GitHub 在这条链路中负责代码托管，不直接承担网站服务。真正响应用户访问请求的是云服务器上的 Nginx。 本地与服务器目录同一个项目在本地和服务器上各有一份副本。例如： 12本地： /Users/username/zero-to-tech服务器： /home/ubuntu/zero-to-tech 两边的绝对路径可以不同，但项目内部结构应保持一致： 1234zero-to-t...
【全栈开发 2】前端页面基础
前端页面主要由 HTML、CSS 和 JavaScript 构成。三者分别负责页面的结构、样式和交互，并由浏览器统一解析和执行。 HTML：页面结构HTML 负责描述页面中包含哪些内容，以及这些内容之间的结构关系。 123456789101112<!DOCTYPE html><html lang="zh-CN"><head> <meta charset="UTF-8"> <title>页面标题</title></head><body> <h1>前端页面</h1> <p id="message">这是页面正文。</p> <button id="change-button">修改内容</button></body></html> 其中： <!DOCTYPE html> 声明当前文档使用 H...
【全栈开发 1】Web 访问链路基础
访问一个网站，看起来只是输入网址并按下回车，背后却涉及浏览器、URL、域名、DNS、IP 地址、端口和服务器等多个部分。本文从一次完整的网页访问出发，梳理这些概念之间的关系。 浏览器、HTML 与服务器浏览器是 Web 的客户端。它负责向服务器请求资源，解析服务器返回的内容，并将其渲染成用户看到的网页。 HTML 是用于描述网页结构的文本格式。它定义页面中的标题、段落、链接和图片等内容。浏览器读取 HTML 后，会按照其中的结构生成网页。 服务器是一台运行服务程序的计算机。它持续监听网络请求，并根据请求返回 HTML、CSS、JavaScript、图片或接口数据等内容。 三者之间的基本关系是： 12345浏览器请求网页 ↓服务器返回 HTML 等资源 ↓浏览器解析并渲染网页 URLURL 是网络资源的完整地址。例如： 1https://example.com:443/articles/hello 这个 URL 可以拆分为： 1234https 协议example.com 域名443 ...
【云计算】AWS 核心概念与访问模型
AWS 的身份、权限和资源并不属于同一层。首次通过邮箱或 Google 账户登录，只完成了身份验证；真正访问云资源，还要经过账户、角色和临时会话等环节。 可以先用一条主线理解整个体系： 123456用户 → 外部登录身份 → AWS Organization 与 Account → Account 中的 IAM Role → STS 签发的临时 Session → 某个 Region 中的 Resource AWS CLI 和开发工具还会在本地使用 Profile，保存认证入口、默认区域和相关配置。 Organization、Account 与 ProjectAWS OrganizationsAWS Organizations 用于集中管理多个 AWS Account，本身不承载网站、服务器或数据库。它主要提供： 统一创建和管理成员账户。 集中结算费用。 按组织单元管理账户。 通过 Service Control Policy（SCP）限定成员账户的最大权限。 典型结构如下： 12345AWS Organization├── Management Account...
【AI 工具】Hermes Agent Plugin
Tool 让 Hermes 能执行动作，Skill 告诉 Hermes怎样正确完成任务，Plugin 则把代码接入 Hermes 的运行过程。本文先厘清三者的关系，再通过 Ponytail、Superpowers 和 Web Search Plus 三个案例说明 Plugin 的实际用途。 Plugin、Tool 和 Skill 的关系这三个概念并不处于同一层级。 Tool 是提供给模型调用的具体能力，例如读取文件、执行命令、搜索网页或发送消息。 Skill 是按需加载的知识和工作流程，告诉 Agent 何时做、按什么顺序做，以及如何验收结果。 Plugin 是可安装的运行时扩展，可以向 Hermes 注册 Tool、Skill、斜杠命令、生命周期 Hook、Provider 或平台适配器。 可以把它们理解成： 123Tool：手脚，决定“能做什么”Skill：经验，决定“应该怎么做”Plugin：扩展模块，决定“如何把新能力接入 Hermes” 例如，terminal 是 Tool，因为它真正执行命令；“发布 Hexo 博客”适合写成 Skill，因为它主要规定构建...
【Agent】把通用 Agent 装进生产环境：一套基于 Hermes Agent 的垂类架构
本文讨论如何把通用 Agent 收敛为面向单一业务场景的生产级智能体，并通过可信会话、Skill、Action Tool 和受控后端划清推理、权限与执行边界。 背景大语言模型已经能让通用 Agent 听懂需求、规划步骤、调用工具。做一个演示不难，难的是把它放进真实业务里，并且让人敢用。 到了生产环境，问题很快会从“模型够不够聪明”变成另一组更麻烦的事：用户身份从哪里来？模型可以执行哪些动作？谁来校验权限？流程中断后怎么接着跑？路径、凭据和基础设施信息又该如何藏在边界以内？ 下文把基于 Hermes Agent、面向单一业务场景收敛出来的生产级智能体称为 ScenarioAgent。这里不讨论某个具体功能，而是拆解它从通用 Agent 走向生产环境时需要的分层架构： 用户负责表达目标，ScenarioAgent 负责理解与编排，Skill 按需提供流程提示词，Action Tool 收窄动作，CLI/API 受控后端负责可信执行。 总体分层架构 flowchart TB User(["用户"]):::user Gate...
【Agent】浏览器自动化最佳实战
让 Agent 操作网页，第一反应通常是”让它像人一样点”。截图、识别按钮、移动鼠标、输入文字，看起来很自然，也很符合我们对”电脑自动化”的直觉。 但实际做过几次就会发现：能点，不等于好用。一次临时演示可能没问题，真正要把它变成稳定、可重复、以后一句话就能执行的能力，难点完全不同。 这篇文章记录我目前认为更适合个人 Agent 的浏览器自动化方案：复用用户已经登录的 Chrome，通过 Apple Events 向当前页面注入 JavaScript，直接读取和操作 DOM，并把最终流程沉淀成 Skill。 文中不会讨论某个网站的具体按钮、接口或业务细节，只讲通用方法。 候选方案选择浏览器自动化方案时，先看 Agent 要控制的是哪一层：浏览器页面、整个桌面、独立自动化浏览器、现有 Chrome、还是网站接口。下面六种方案各自控制不同的对象，不应混为一谈。 方案一：使用 Hermes Agent 内置的浏览器工具Hermes Agent 内置了 browser_navigate、browser_snapshot、browser_click、browser_type、brows...
【AI 工具】Hermes Agent 内置 Skills 概览
本文按类别整理 Hermes Agent 内置的全部 Skills，逐一介绍它们的用途、来源和常见使用场景。 本文内容根据 Hermes Agent 内置 Skills 目录整理。不同 Skill 可能对操作系统、外部命令、账号授权或 API 凭证有额外要求；Hermes 更新后，内置 Skills 的数量和内容也可能变化。 自治 Agent 与 Hermesclaude-code 将功能开发、Bug 修复和 PR 等任务委派给 Claude Code CLI，并负责传递上下文、跟踪进度和验收结果。 这是 Hermes 对 Anthropic Claude Code 的工作流封装，重点不是简单调用另一个模型，而是管理一个独立运行的 Coding Agent。 实战案例： 123请把这个功能交给 Claude Code 实现：新增用户登录接口，补齐测试，并在独立 Git Worktree 中工作。让 Claude Code 修复当前分支的 CI 失败；完成后返回修改文件、测试命令和真实结果。请让 Claude Code 审查这次跨前后端改动，只报告高风险问题，不要直接修改代...
【网络与代理】WSL 多网段服务访问超时：防火墙、Docker 路由与 SSH 代理排查
问题背景一台 Windows + WSL2 服务器同时运行了 Web 服务、SSH、Docker 和本地代理。服务器所在网段可以正常访问这些服务，但另一个内网网段的机器始终连接超时。 最初看起来像 Windows 防火墙没有放行端口。实际排查后发现，问题由两层配置叠加造成： Windows 防火墙需要允许可信内网访问 WSL 中的 TCP 服务。 WSL 里的 Docker 网桥与真实内网网段重叠，导致返回数据走错网卡。 第二点更隐蔽。即使端口已经监听、防火墙规则也正确，只要回程路由错误，客户端看到的仍然只是超时。 先确认服务真的在监听不要一开始就改防火墙。先在 WSL 中确认服务监听地址： 1ss -lntp 如果服务只监听 127.0.0.1，其他机器无法直接连接。需要对内网提供服务时，应让它监听 0.0.0.0:<PORT>，或者通过反向代理暴露。 然后分别从服务器本机和客户端测试： 12345# 在服务器本机测试curl -I http://127.0.0.1:<PORT># 在内网客户端测试curl -I --connect-timeou...
【AI 工具】Hermes 小众但强大的斜杠命令
Hermes 除了 /help、/new、/model 这些常用命令，还藏着不少能明显改善工作流的斜杠命令。本文只保留命令、作用和示例，方便随时查阅。 任务运行 /steer <指令>：在不中断当前任务的情况下，把补充要求注入下一次工具调用之后。 1/steer 不要修改数据库结构，只修应用层 /queue <指令>：把新要求排到当前任务结束后，作为下一轮消息执行。 1/queue 完成后再生成一份变更说明 /background <任务>：在独立后台会话中运行任务，当前会话可以继续使用，完成后结果会自动返回。 12/background 调研最近一周发布的开源医学多模态模型/background 检查完整测试套件并汇总失败项 /goal <目标>：让 Hermes 围绕一个明确目标自动持续执行，直到 Judge 判断完成或达到轮次上限。 12345678910# 设置一个持续执行的目标/goal 修复这个项目，直到全部测试通过# 查看当前 Goal 的状态/goal status# 暂停 Goal 的自动...
【AgentDaily】Codex exec 正常，交互式 TUI 却 TLS EOF：一次代理与流式传输排查记
同一套代理下，codex exec 连续成功，交互式 TUI 却稳定报 tls handshake eof。这次排查最有用的收获不是找到了某个“神奇节点”，而是把短连接、非交互调用和真实 TUI 传输路径拆开验证。 问题现象环境是 WSL，使用 Clash/Mihomo 类代理，Codex CLI 版本为 0.145.0，通过 ChatGPT OAuth 登录。 最初使用默认代理出口运行 Codex 时，下面两个接口都返回 HTTP 403： 12https://chatgpt.com/backend-api/codex/modelshttps://chatgpt.com/backend-api/codex/responses Cloudflare 返回页提示 VPN 可能受限。切换到一个标有 GPT 解锁能力的候选节点后，非交互命令马上恢复： 1codex exec --skip-git-repo-check "hi" 命令能够正常返回。到这里很容易以为问题已经解决，但交互式 codex 输入 hi 仍然失败，先出现： 12Falling...
【AgentDaily】如何在飞书群里做 A2A：Hermes Bot-to-Bot 最佳实践
两个 Hermes 机器人在同一个飞书群里协作，关键不是“看见对方的名字”，而是让发送方使用接收方自己确认过的 bot open_id 发出真正的 @，再由接收方按 mention 策略放行。 飞书里的四类身份飞书消息事件中常见的身份字段有 open_id、user_id 和 union_id，机器人还多了一层应用身份： 身份 作用域 典型形式 适合用途 app_id 应用 cli_xxx 标识应用和申请 tenant access token，不是群消息中的 @ 目标 open_id 应用 ou_xxx 同一主体在不同应用下可能不同，消息事件和 @ 提及中最常用 user_id 租户 u_xxx 企业租户内的用户身份，是否返回取决于权限和事件配置 union_id 开发者 on_xxx 同一开发者主体下跨应用关联用户，适合做跨应用身份归并 open_id 的“应用作用域”是 A2A 最容易踩坑的地方。同一个人经过两个飞书应用观察，得到的 open_id 可能不同；机器人同样不能把 app_id、群成员接口中的某个 ID 和 mention 事件...
【AgentDaily】Hermes terminal.cwd 与 AGENTS.md 加载机制
这篇文章记录一次关于 terminal.cwd、启动目录和 AGENTS.md 的小排查。结论很简单：terminal.cwd 是工具执行起点，不一定等于当前 CLI 会话的 Project Context 加载目录。 起因今天遇到一个很容易混淆的问题。 我在 /Users/tianlejin 启动 Hermes，但当前 profile 的配置里写了： 123terminal: backend: local cwd: /Users/tianlejin/workspace-hermes-teacher 于是自然会产生一个疑问：如果启动目录和 terminal.cwd 不一样，Hermes 到底会加载哪个目录下的 AGENTS.md？ 当时实测的终端输出是： 1pwd 返回： 1/Users/tianlejin Project Context 中注入的内容也来自： 1/Users/tianlejin/AGENTS.md 而不是： 1/Users/tianlejin/workspace-hermes-teacher/AGENTS.md 所以这次的关键点不在于 ter...
【AgentDaily】Hermes 新 Profile Gateway 飞书 WebSocket 超时排查记
systemd 显示 Gateway 正在运行，飞书却始终连不上。最后发现，问题不在凭据，而在新 Profile 的服务没有继承代理环境变量。 问题现象我为 Hermes 新建了 blog-writer Profile，并为它启动了独立的 systemd 用户服务： 1systemctl --user status hermes-gateway-blog-writer.service 服务状态显示为 active (running)，乍看没有异常。但 Gateway 日志中的飞书连接会等待 30 秒后超时： 12feishu connect timed out after 30sGateway started with no connected platforms — 1 platform(s) queued for retry 后续自动重连也没有成功： 1Reconnect feishu error: feishu connect timed out after 30s, next retry in 60s 这里最容易被 active 误导。它只能说明 Gatewa...
【AgentDaily】Hermes 升级后 reasoning_effort 导致 litellm 400 报错排查记
Hermes 升级后，调用本地 LiteLLM 代理时全部模型返回 400。后来接入 Azure GPT 时又遇到相似错误，但两者的正确解法并不相同。 问题现象Hermes 升级后，调用本地模型时所有请求都返回 HTTP 400： 12345HTTP 400: litellm.UnsupportedParamsError: openai does not support parameters: ['reasoning_effort'],for model=GLM-5.2. To drop these, set `litellm.drop_params=True` or for proxy:`litellm_settings: drop_params: true` 主模型和 fallback 模型全部报同样的错，会话完全无法使用。 背景自建的 litellm 代理转发到内部模型服务。升级前使用不同厂商的独立 endpoint（Kimi、Qwen、GLM 各自有独立地址），升级后切换到了统一的 litellm 代理 endpoint。 Hermes 使...
【AgentDaily】Hermes update 误判 Docker 容器排查记
明明在宿主机，却被 Hermes 误判为 Docker 容器？一个 stamp 文件引发的血案！ 🎯 问题现象今天在宿主机执行 hermes update --check，结果跳出了 Docker 相关的提示： 1234567✗ ``hermes update`` doesn't apply inside the Docker container.Hermes Agent runs as a published image (nousresearch/hermes-agent), not agit checkout — the container has no working tree to pull into. Update bypulling a fresh image and restarting your container instead: docker pull nousresearch/hermes-agent:latest 但我明明是在 macOS 宿主机上，根本没在 Docker 容器里。 🔍 背景我确实拉过 Hermes 的 Doc...
【AI 工具】Hermes Agent 上下文文件配置指南
本文介绍 Hermes Agent 的上下文与记忆文件系统，包括 SOUL.md、AGENTS.md、/personality、MEMORY.md、USER.md 的作用、加载机制与最佳实践。相关文件位置：~/.hermes/ 整体概览Hermes Agent 有一套完整的”认知文件”系统，分成三类： 类型 文件 作用 生命周期 身份 SOUL.md Agent 是谁、怎么说话 全局永久 项目上下文 AGENTS.md / .hermes.md 等 当前项目的规范与指令 跟随项目 跨会话记忆 MEMORY.md / USER.md Agent 主动积累的事实与用户画像 跨会话持久 三者各司其职，互不替代。理解清楚之后，配置起来会非常顺手。 SOUL.md ⭐️：Agent 的灵魂SOUL.md 是 Agent 的主要身份，占据系统提示词的第 #1 槽位，完整替换内置的默认身份。它定义的是 Hermes 这个 Agent “是谁”——语气、表达风格、面对分歧时的态度……这些性格层面的东西全在这里。 文件位置123~/.hermes...
【AI 工具】Hermes Agent 飞书配置指南
本文介绍 Hermes Agent 如何接入飞书，以及与飞书有关的的高级配置配置文件位置：~/.hermes/config.yaml 和 ~/.hermes/.env 创建飞书应用1hermes gateway setup 选择 Feishu / Lark，然后用飞书手机 App 扫码。Hermes 会自动帮你创建好机器人应用，配好权限，保存凭证。 基础配置确认 ~/.hermes/.env 文件中有以下必需配置： 12345# 必需FEISHU_APP_ID=cli_xxxFEISHU_APP_SECRET=secret...ishuFEISHU_DOMAIN=feishu # feishu（中国）或 lark（国际）FEISHU_CONNECTION_MODE=websocket 也可以用交互式配置：hermes gateway setup，选择 Feishu / Lark 按提示填写。 配置完成后，重启 Gateway： 1hermes gateway restart 然后在飞书里给机器人发条消...
【AI 工具】Hermes Agent 模型配置指南
核心概念Hermes 的模型配置分为三层： 主模型层：对话主力军，负责核心推理 辅助模型层：轻量级任务专用（图像识别、网页总结、上下文压缩） 回退链层：主模型挂了自动切换备胎 配置文件位置：~/.hermes/config.yaml 环境变量替换在 config.yaml 中可以使用 ${VAR_NAME} 语法引用环境变量，避免硬编码敏感信息： 1234567auxiliary: vision: api_key: ${GOOGLE_API_KEY} base_url: ${CUSTOM_VISION_URL}delegation: api_key: ${DELEGATION_KEY} 特性： 单个值中可以有多个引用：url: "${HOST}:${PORT}" 如果引用的变量未设置，占位符保持原样（${UNDEFINED_VAR} 不变） 仅支持 ${VAR} 语法 —— ...
【AI 工具】Hermes Agent 配置指南
本文主要介绍博主认为常用的 Hermes Agent 的核心配置项（重要的配置会标注 ⭐️）： 目录结构与配置优先级、上下文文件 显示与流式传输设置 群聊会话隔离 智能审批机制 终端后端（local / docker / ssh / modal 等） 上下文压缩 快速命令 检查点 本文未介绍但会在其他文章单独介绍的配置： 技能相关： skills 模型相关： model, providers, fallback_providers, custom_providers 本文未介绍的配置（博主认为不重要）： 管理配置、环境变量替换、内存配置、文件读取安全、工具输出截断限制、全局工具集禁用、Git Worktree 隔离、上下文引擎、迭代预算压力、上下文压力警告、凭据池策略、Prompt 缓存、辅助模型、推理努力程度、工具使用强制、TTS 配置、隐私、语音转文字（STT）、语音模式（CLI）、未授权 DM 行为、人类延迟、代码执行、Web 搜索后端、浏览器、时区、Discord、安全、网站黑名单、委托、澄清、工作目录 配置目录结构...