从零搭建 VPS 诊断 Agent：LangGraph + One API + Telegram 定时报告

2026年10月18日2026年10月18日 ai-agent 11 Views 0 Comments LangGraph

之前用 OpenClaw 跑多 Agent 实验，一直停在“玩具”阶段——Agent 只会说“1+1=2”。这次把它变成一个真正能用的东西：一个每小时自动检查 VPS 状态、跑真实诊断命令、把报告发到 Telegram 的 Agent。整个过程踩了不少坑，记录一下。

目标

用 LangGraph 搭一个 Agent，能调真实系统命令（free、ps、systemctl、journalctl）
用 One API 作为模型网关，不额外配 GPU
每小时自动跑一次，结果通过 Telegram 推送
加 tracing（记录每次工具调用耗时）和 token 预算（防止失控烧钱）

架构

cron (每小时)
  └─ cron-diagnose.sh
      └─ swarm_quick6.py (LangGraph Agent)
          ├─ check_memory        → free -h
          ├─ check_top_processes → ps aux --sort=-%mem
          ├─ check_service_status → systemctl status
          └─ check_recent_logs   → journalctl -u
      └─ openclaw message send → Telegram

第一个坑：模型名必须精确匹配

最初脚本里写 deepseek-v4.1-flash，One API 报：

当前分组 default 下对于模型 deepseek-v4.1-flash 无可用渠道

对比 OpenClaw 日志才发现，它用的是 deepseek-ai/deepseek-v4.1-flash（带前缀）。One API 按精确名字匹配渠道，少一个前缀就找不到。

第二个坑：慢模型不适合做“工具密集”的 Agent

deepseek-ai/deepseek-v4.1-flash 单次响应 75-150 秒。Agent 要连续做多次推理（决定调工具 → 解读结果 → 生成结论），5 分钟 timeout 不够。
试过换 gpt-oss:120b，结果 429（上游饱和）。试过 meta/llama-3.2-11b-vision-instruct，快，但只支持单次工具调用，Agent 并行调两个工具时报 400。
最终方案：单 Agent + 真实工具，不用多 Agent 嵌套。只有 3 次模型请求（决策调工具 → 解读结果 → 生成结论），5 分钟内能跑完。

第三个坑：@tool 和 @traced 装饰器冲突

想给工具加 tracing，写成：

@tool
@traced("check_memory")
def check_memory() -> str:
    """查看系统内存..."""

报错：

ValueError: Function must have a docstring if description not provided.

原因：@traced 返回的 wrapper 函数没有 docstring，@tool 拿到的不是原始函数。修法是加 @wraps(fn)，它会复制原函数的 __doc__ 和 __name__ 到 wrapper 上。

跑通后的输出

任务: 检查一下当前内存使用情况，以及占用最高的进程是什么，给出一句话结论。
=== 执行过程 ===
  🔧 agent: ['check_memory', 'check_top_processes']
  💬 tools: total 5.8Gi used 2.9Gi free 607Mi ...
  💬 tools: root 771456 25.5% ... openclaw ... gateway --port
  💬 agent: **结论：内存偏紧——5.8Gi 总量已用 2.9Gi、可用仅 2.6Gi，
  且 swap 2.0Gi 已被吃掉 1.6Gi（80%），说明存在明显内存压力；
  占用最高的是 openclaw gateway（RSS 约 1.3GB / 21.8%），
  是当前主要内存消耗方。**
  📊 Token 使用: 1825/50000
=== 完成 ===

Agent 真的调用了 free 和 ps，拿到了真实数据，并给出了准确结论。这不是编的，是基于真实输出推理的。

Tracing 记录

每个工具调用都记录耗时到 /var/log/langgraph-agent/trace.jsonl：

{"ts":"2026-10-18T02:22:03","tool":"check_memory","elapsed_ms":4,"status":"ok"}
{"ts":"2026-10-18T02:22:03","tool":"check_top_processes","elapsed_ms":17,"status":"ok"}

工具执行极快（4-17 毫秒），慢的完全是模型推理。这告诉我们：未来优化方向是换更快的模型，而不是优化工具代码。

Token 预算

每次模型响应累加 usage_metadata.total_tokens，超过 50000 就抛异常停止。单次诊断只花 1825 token，即使按 50000 预算，也能跑 27 次才超限。

定时任务

cron-diagnose.sh 每小时跑一次：

0 * * * * /bin/bash /opt/langgraph-agent/cron-diagnose.sh >> /var/log/langgraph-agent/cron.log 2>&1

跑完后通过 OpenClaw 的 message send 把报告发到 Telegram：

✅ Sent via telegram. Message ID: 1953

几个关键教训

模型名必须和 One API 渠道里注册的完全一致，包括前缀、大小写、连字符。
慢模型不适合做工具密集的 Agent。如果模型单次响应 75 秒，而 Agent 要连续推理 3 次，5 分钟 timeout 不够。
装饰器顺序很重要。@tool 在外层时，内层装饰器返回的 wrapper 必须有 docstring，用 @wraps(fn) 保留。
不要一次改太多。先跑通单 Agent + 真实工具，再加 tracing，再加预算，最后加 cron。每步独立验证，出问题好定位。
工具只读。ps、free、systemctl status、journalctl 安全，systemctl restart、kill 绝对不要给 Agent，否则它可能误操作。

目标

架构