实用提示：使用 Ollama 在本地（且安全地）运行 Hermes Agent
《实用笔记》操作指南：使用 Ollama 在本地（且安全地）运行 Hermes Agent，以及为采用该模式的团队提供的合同、检查项和即插即用代码模块。
可将此文档视为《在 Arch Linux 上使用 Ollama 和 Rootless Podman 本地（且安全地）运行 Hermes Agent》一文中内容的操作员版重构版本：清晰的阶段划分、有序的代码模块，以及便于交接时参考的恢复说明。 “概览”阶段若被视作可量化的基准，则效果最佳。在扩大范围之前，应先记录一份标准操作流程、一个故障案例以及回滚说明。 将此阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，绝不允许出现无声的半完成状态。
1. 安装 Rootless Podman
对于需要安装 rootless 版本 Podman 的阶段，在修改代码之前需先定义输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。应在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。应将客户端构建部分与消息处理循环分开，这样即便更换提供商，也无需重写对话状态机。
sudo pacman -Syu podman
1) crun
2) krun
3) runc
1
podman --version
podman info --format '{{.Host.OCIRuntime.Name}}'
crun
grep "^$USER:" /etc/subuid
grep "^$USER:" /etc/subgid
2. 如有必要，修复 rootless OverlayFS
对于需要两次修复的rootless OverlayFS阶段，在修改代码之前应先明确输入参数、该步骤的负责人以及结束标准。操作人员应当能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置应与应用程序代码分开。环境文件、密钥存储以及功能标志应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 将客户端构建与消息循环分开，这样一来即便更换提供方，也无需重写对话状态机。
kernel does not support overlay fs:
'overlay' is not supported over extfs
sudo pacman -S fuse-overlayfs
which fuse-overlayfs
/usr/bin/fuse-overlayfs
~/.config/containers/storage.conf
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
podman info --debug | grep -Ei 'graphDriverName|mount_program|overlay'
3. 可选：将Podman的存储移至容量更大的驱动器
对于那3个可选的Podman阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 需同时记录正常流程与故障恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 应将客户端构建逻辑与消息处理循环分开，这样即便更换服务提供商，也无需重写对话状态机。 对于那3个可选的Podman阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 应将这一阶段视为输入参数与经过验证的输出结果之间的契约。为相关输出文件命名，明确成功判定标准，并禁止出现无声的、不完整的处理结果。
write /var/tmp/container_images_storage...:
no space left on device
$HOME/.local/share/containers/storage
/var/tmp
/path/to/large-drive/podman/
├── storage/
└── tmp/
sudo mkdir -p /path/to/large-drive/podman/storage
sudo mkdir -p /path/to/large-drive/podman/tmp
sudo chown -R "$USER:$USER" /path/to/large-drive/podman
mkdir -p ~/.config/containers
nano ~/.config/containers/storage.conf
[storage]
driver = "overlay"
graphroot = "/path/to/large-drive/podman/storage"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
export TMPDIR=/path/to/large-drive/podman/tmp
echo 'export TMPDIR=/path/to/large-drive/podman/tmp' >> ~/.bashrc
source ~/.bashrc
podman info --format 'GraphRoot: {{.Store.GraphRoot}}'
podman info --debug | grep -Ei 'graphRoot|imageCopyTmpDir|mount_program'
~/.local/share/containers/storage
4. 创建Hermes唯一可访问的宿主文件夹
在执行“创建唯一阶段”这一步骤时，首先需明确相关要求：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改不会出错。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。 每次调用时都要记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务提供商错误就会被视为应用程序的故障。
export HERMES_WORKSPACE="$HOME/path/to/Hermes-Workspace"
mkdir -p "$HERMES_WORKSPACE"
Obsidian Vault/
├── Personal/
├── Work/
├── Research/
└── Agent Workspace/ ← only this folder is exposed
podman volume create hermes-data
podman volume create ollama-models
5. 配置AMD GPU访问权限
在完成“配置 AMD GPU”的5个阶段时，首先列出相关要求：所需输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会出错。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 每次调用时都要记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务错误就会被误认为是应用程序的故障。
/dev/kfd
/dev/dri
ls -l /dev/kfd
ls -l /dev/dri/render*
groups
sudo usermod -aG video,render "$USER"
groups
groups
video render
6. 检查 /dev/net/tun
在完成“6项检查开发网络”阶段时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误处理都属于产品功能的一部分，而非后续的优化工作。 每次调用时都要记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务错误就会被视为应用程序的缺陷。 在完成“6项检查开发网络”阶段时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将此阶段视为输入与验证后输出之间的契约。为相关成果命名，定义成功判定标准，并杜绝无声的半完成状态。
pasta failed with exit code 1:
Failed to open() /dev/net/tun: No such device
ls -l /dev/net/tun
sudo modprobe tun
uname -r
ls /usr/lib/modules/
7. 选择本地模型
在将“选择本地模型”这一阶段视为可度量的对象时，其效果最佳。在扩大范围之前，先记录一份理想的测试用例、一个故障案例以及回滚说明。在功能结果旁还需记录执行时间以及令牌或查询成本。提前了解这些成本信息，可避免在从演示环境过渡到共享环境时出现意外费用。在教授循环逻辑之前，需固定解释器及依赖项的锁定文件。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。
gemma4:12b
export HERMES_MODEL="gemma4:12b"
8. 拉取容器镜像
将“8 Pull容器阶段”视为可测量的界面来使用效果最佳。在扩大范围之前，先记录一份成功的示例、一个故障案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，这样操作人员无需查看整个架构即可进行审计。 在讲解循环逻辑之前，先锁定解释器和依赖项的版本。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。
podman pull docker.io/ollama/ollama:latest
podman pull docker.io/ollama/ollama:rocm
podman pull docker.io/nousresearch/hermes-agent:latest
9. 将模型下载到持久化卷中
将“9 下载模型”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，需记录一份理想运行案例、一个故障案例以及回滚说明。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 在编写循环逻辑之前，先锁定解释器及依赖项的版本。笔记本电脑与持续集成环境之间的差异是 API 演示中最常见的隐性故障原因。 将“9 下载模型”阶段视为输入与经过验证的输出之间的契约。为相关输出文件命名，明确成功标准，杜绝隐性部分完成的情况。
podman rm -f ollama-bootstrap 2>/dev/null
podman run -d \
--name ollama-bootstrap \
-v ollama-models:/root/.ollama \
docker.io/ollama/ollama:latest
podman rm -f ollama-bootstrap 2>/dev/null
podman run -d \
--network host \
--name ollama-bootstrap \
-v ollama-models:/root/.ollama \
docker.io/ollama/ollama:latest
podman exec -it ollama-bootstrap \
ollama pull "$HERMES_MODEL"
podman exec ollama-bootstrap ollama list
gemma4:12b
podman rm -f ollama-bootstrap
container name "ollama-bootstrap" is already in use
podman rm -f ollama-bootstrap
10. 创建仅限内部使用的网络
在“创建仅限内部使用”的阶段，需先定义输入参数、该步骤的负责人以及结束标准，然后再进行代码修改。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在系统从演示环境切换到共享环境时出现意外费用。此外，应将客户端构建与消息循环分开，这样即便更换服务提供商，也无需重写对话状态机。
--network none
podman network create \
--ignore \
--internal \
hermes-internal
podman pod create \
--name hermes-local \
--network hermes-internal \
--userns=keep-id:uid=10000,gid=10000
11. 使用 AMD ROCm 启动 Ollama
对于需要分阶段启动 Ollama 的场景，应在修改代码之前明确输入参数、各步骤的负责人以及终止条件。操作员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放，以便操作员无需查看整个系统结构即可进行审核。 将客户端构建逻辑与消息处理循环分开，这样在更换服务提供者时无需重写对话状态机。
podman run -d \
--name ollama \
--pod hermes-local \
--device /dev/kfd \
--device /dev/dri \
--group-add keep-groups \
-e HOME=/root \
-e OLLAMA_MODELS=/root/.ollama/models \
-e OLLAMA_CONTEXT_LENGTH=64000 \
-v ollama-models:/root/.ollama \
docker.io/ollama/ollama:rocm
--device /dev/kfd
--device /dev/dri
--group-add keep-groups
ollama/ollama:rocm
HOME=/root
OLLAMA_MODELS=/root/.ollama/models
podman exec ollama ollama list
podman logs ollama
HOME=/
OLLAMA_MODELS=/.ollama/models
/root/.ollama/models
HOME=/root
OLLAMA_MODELS=/root/.ollama/models
podman exec ollama ollama list
12. 验证 ROCm 是否确实使用了 GPU
在进入“12 Verify ROCm”阶段之前，需先明确输入参数、该步骤的负责人以及终止标准，然后再进行代码修改。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 需同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及错误处理方式都是产品本身的一部分，而非后续需要补充的功能。 应将客户端构建部分与消息循环分离，这样即便更换服务提供商，也无需重新编写对话状态机。 在进入“12 Verify ROCm”阶段之前，需先明确输入参数、该步骤的负责人以及终止标准，然后再进行代码修改。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 应将此阶段视为输入与验证后输出之间的契约。需为相关成果命名，明确成功判定标准，并禁止出现无声的、不完整的处理结果。
podman logs ollama 2>&1 | grep -Ei 'gpu|rocm|amd|gfx'
podman exec -it ollama \
ollama run gemma4:12b \
"Reply with exactly: AMD GPU test successful"
podman exec ollama ollama ps
PROCESSOR
CONTEXT
64000
13. 以仅一个主机文件夹挂载的方式启动Hermes
在按照“13. 通过分阶段方式启动Hermes”的步骤操作时，首先需列出相关要求：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会出错。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。 每次调用时都要记录请求ID、模型ID和延迟时间。如果没有这些记录，间歇性的服务提供商错误就会被视为应用程序故障。
podman run -d \
--name hermes \
--pod hermes-local \
--security-opt=no-new-privileges \
--pids-limit 512 \
-v hermes-data:/opt/data \
-v "$HERMES_WORKSPACE:/opt/data/workspace:rw,nodev,nosuid" \
-w /opt/data/workspace \
docker.io/nousresearch/hermes-agent:latest \
sleep infinity
/:/host
/home:/home
~/.ssh
~/.config
Docker socket
Podman socket
$HERMES_WORKSPACE
↓
/opt/data/workspace
hermes-data
↓
/opt/data
14. 验证挂载边界
在完成“14. 验证挂载阶段”时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离原定方向。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 每次调用时都要记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务端错误就会被误认为是应用程序的故障。
podman inspect hermes \
--format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'
Podman volume -> /opt/data
your allowed folder -> /opt/data/workspace
podman exec hermes sh -c \
'test ! -S /var/run/docker.sock && echo "No Docker socket exposed"'
podman exec hermes sh -lc \
'test -e "$HOME/.ssh" && echo "SSH directory visible" || echo "Host SSH directory not visible"'
15. 验证Hermes能否连接到Ollama
在完成“15个Verify Hermes可部署的测试用例”时，首先需明确合同条款：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 每次调用时都要记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务错误就会被视为应用程序的缺陷。 在完成“15个Verify Hermes可部署的测试用例”时，首先需明确合同条款：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 将此阶段视为输入与验证后输出之间的契约。为相关产物命名，定义成功检测标准，并拒绝默许的部分完成状态。
podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:11434/v1/models").read().decode())'
podman exec hermes python - <<'PY'
...
PY
podman exec -i hermes python - <<'PY'
import urllib.request
print(
urllib.request.urlopen(
"http://127.0.0.1:11434/v1/models"
).read().decode()
)
PY
16. 确认外部网络访问已被阻断
将“确认外部网络访问”这一环节视为可测量的指标来处理，效果最佳。在扩大测试范围之前，需记录一份成功的测试案例、一个失败案例以及回滚说明。在功能结果旁还需记录执行时间以及令牌或查询成本。提前了解这些成本信息，可避免在测试环境从演示模式切换到共享环境时出现意外费用。在讲解循环逻辑之前，需先固定解释器及依赖项的锁文件。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。
podman exec hermes python -c \
'import urllib.request; print(urllib.request.urlopen("https://example.com", timeout=5).read())'
podman ps
11434/tcp
0.0.0.0:11434->11434/tcp
17. 配置Hermes以使用本地Ollama
将“17. 配置Hermes以分阶段执行”这一方法视为可度量的操作面时效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 应将配置与应用程序代码分开。环境文件、密钥存储和功能开关应集中存放于一个位置，这样操作人员无需查看整个架构即可进行审计。 在讲解循环逻辑之前，先锁定解释器及依赖项的版本。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes model
Ollama Cloud
Custom endpoint (enter URL manually)
http://127.0.0.1:11434/v1
gemma4:12b
64000
18. 使用Hermes的本地终端后端——在容器内部
将“18 Use Hermes本地测试阶段”视为可度量的测试环境使用效果最佳。在扩大测试范围之前，需记录一份理想运行案例、一个故障案例以及回滚说明。同时文档化正常流程与恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的一部分，而非后续需要补充的内容。在讲解循环逻辑之前，先锁定解释器及依赖项的版本文件。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。“18 Use Hermes本地测试阶段”作为输入与经过验证的输出之间的契约来使用效果最佳。为相关输出文件命名，明确成功标准，杜绝隐性部分完成的情况。
terminal:
backend: local
Hermes "local"
↓
Hermes container
Hermes "local"
↓
your Arch workstation
podman exec --user 10000:10000 hermes \
hermes config set terminal.backend local
podman exec --user 10000:10000 hermes \
hermes config set terminal.cwd /opt/data/workspace
podman exec --user 10000:10000 hermes \
hermes config set terminal.home_mode profile
19. 启动 Hermes
在为第19次启动Hermes阶段编写代码之前，需先明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境切换到共享环境时出现意外费用。应将客户端构建与消息循环分开，这样即便更换提供方，也无需重写对话状态机。
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes
20. 在系统启动时自动启动环境
在“启动环境”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。 将客户端构建与消息处理循环分开，这样在更换提供方时无需重写对话状态机。
mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/hermes-local.service
[Unit]
Description=Hermes Local AI Pod
After=default.target
[Service]
Type=oneshot
RemainAfterExit=yesExecStart=/usr/bin/podman pod start hermes-local
ExecStop=/usr/bin/podman pod stop -t 30 hermes-localTimeoutStartSec=120
TimeoutStopSec=60[Install]
WantedBy=default.target
systemctl --user daemon-reload
systemctl --user enable hermes-local.service
systemctl --user start hermes-local.service
systemctl --user status hermes-local.service
Active: active (exited)
sudo loginctl enable-linger "$USER"
loginctl show-user "$USER" -p Linger
Linger=yes
podman ps
podman exec -it \
--user 10000:10000 \
-w /opt/data/workspace \
hermes \
hermes
排查实际出现的问题
在修改代码之前，为故障排查阶段明确输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新执行该步骤，而无需猜测隐藏状态。 需同时记录正常流程与恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 将客户端构建部分与消息循环分离，这样即便更换服务提供商，也无需重写对话状态机。 在修改代码之前，为故障排查阶段明确输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新执行该步骤，而无需猜测隐藏状态。 应将此阶段视为输入与已验证输出之间的契约。为相关产物命名，明确成功判定标准，并拒绝默许部分完成的情况。
Problem:
kernel does not support overlay fs
Fix:
Install fuse-overlayfs and configure it as the overlay mount program.
Problem:
no space left on device under /var/tmp
Fix:
Move Podman's graphroot if needed AND set TMPDIR.
Changing Podman's --tmpdir is not the same thing.
Problem:
ollama-bootstrap name already in use
Fix:
podman rm -f ollama-bootstrap
Problem:
pasta cannot open /dev/net/tun
Fix:
sudo modprobe tun
If the installed modules don't match the running kernel, reboot.
Problem:
Installed nvidia-container-toolkit on an AMD machine
Fix:
Don't.
Use ollama/ollama:rocm with /dev/kfd and /dev/dri.
Problem:
Added myself to video/render but `groups` still didn't show them
Fix:
Log out and back in.
The existing login session retains its original supplementary groups.
Problem:
Ollama model files and manifest exist, but `ollama list` is empty
Fix:
Check:
podman logs ollamaIf Ollama is using:
OLLAMA_MODELS=/.ollama/modelswhile the volume is mounted under:
/root/.ollamaset explicitly:
HOME=/root
OLLAMA_MODELS=/root/.ollama/models
Problem:
Hermes → Ollama Python test silently prints nothing
Fix:
If using `python -` with a heredoc, add `podman exec -i`.
Or simply use `python -c`.
Problem:
The Hermes provider menu doesn't contain "local Ollama"
Fix:
Choose:
Custom endpoint (enter URL manually)Then:
http://127.0.0.1:11434/v1
Problem:
Everything works, but Hermes reports an inadequate context window
Fix:
Set OLLAMA_CONTEXT_LENGTH=64000 server-side and configure Hermes for the same value.
Verify the real allocation with:
ollama ps
为何您更倾向于这种方式而非单纯信任代理
在分析“为何选择此阶段”时，首先写下相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。 每次调用都要记录请求ID、模型ID和延迟时间。如果没有这些记录，间歇性的服务提供商错误就会被视为应用程序故障。
Prompt restrictions
↓
Hermes file write protections
↓
Hermes container filesystem
↓
Rootless Podman user namespace
↓
Host filesystem permissions
关于发展迅速的本地AI工具的说明
在处理关于快速迭代阶段的A笔记时，首先写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在每次调用时记录请求ID、模型ID以及延迟时间。如果没有这些记录，间歇性的服务错误就会被视为应用程序的缺陷。
Does Podman see the GPU?
↓
Does Ollama see the model?
↓
Does Ollama actually use the GPU?
↓
Is the context really 64K?
↓
Can Hermes reach /v1/models?
↓
Can Hermes perform an actual file operation?
↓
Can Hermes reach anything it shouldn't?
最终结果
在处理最终结果阶段时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都属于产品功能的一部分，而非后续的优化工作。 每次调用时都要记录请求ID、模型ID以及响应延迟时间。如果没有这些记录，间歇性的服务错误就会被视为应用程序的缺陷。 在处理最终结果阶段时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 将这一阶段视为输入与验证后输出之间的契约。为相关产物命名，定义成功判定标准，杜绝无声的半完成状态。
Local inference YES
AMD GPU acceleration YES
Hermes persistent memory YES
One writable host workspace YES
Cloud LLM required NO
Host filesystem exposed NO
Podman/Docker socket exposed NO
Normal Internet egress NO
Entire Obsidian vault exposed NO
操作检查清单
在处理操作检查清单阶段时，首先写下合同细节：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。
优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。
每次调用时都要记录请求ID、模型ID以及延迟时间。没有这些记录，间歇性的服务端错误就会被视为应用程序的缺陷。
保持图结构的扁平化与类型化。嵌套的数据结构会掩盖哪个节点修改了哪个字段，还会导致中断后无法继续执行。
在预算允许的情况下，使用测试数据而非真实的付费API，在持续集成过程中添加用于检测关键路径的冒烟测试。
应将配置置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作人员无需查看全部内容即可进行审计。
在升级技术栈之前，需冻结版本、为关键流程保存标准记录，并明确回滚步骤。共享环境需要设置速率限制、进行租户验证，同时指定专人负责密钥轮换。与其追求花哨的一次性演示，不如注重扎实的可靠性。
针对 bab1ff410bd9 的批量说明：请将提供方密钥移出代码仓库，设定单会话令牌上限，并将记录与评估用文件一同存储，以便后续模型更换时保持可比性。