DeepSeek 智能体跑通实录：四个坑，最狠那个报错不在日志里

排障 · 约 3.7 万行 TypeScript（MIT）/ 单工单 50 秒未标注整理于 2026-11-13 有效期 180d

从零把 DeepSeek dsh-superagent（MIT，约 3.7 万行 TypeScript）跑到能自己提 PR，花了约 5 小时，最久的一段卡了 2 小时。四个坑里前三个都有明确报错、照着搜就能解决：面板不能绑 0.0.0.0 也不能绑网卡 IP（必须 loopback + SSH 隧道）、pnpm build 缺 unrun 这个 peerDependency、GitHub 必须两个账号且智能体账号要 watch 仓库。第四个坑报错根本不在日志里——它藏在 zstd 压缩的 Session 事件流中，内容是「No API key for provider」，而前面所有 timeout 记录都是假象。所有健康检查全绿，唯一异常是工单表空的。

本地部署智能体DeepSeekGitHubPR排错日志API keySGLangpeerDependency部署部署前置

这条适用于

一台 Linux 主机（4C8G 起，本例 80 线程 / 125GiB）
一个废弃的测试仓库 + 一个专用 GitHub 小号（不可省，省了会卡在坑三）
一个 OpenAI 兼容的模型服务（本例本地 SGLang 起 deepseek-v4.1-flash）

版本指纹

dsh-superagent-prototype（2026-10-31 开源 / MIT）/ pnpm / Node ESM / Ubuntu 26.04

具体做法

【效果实录（2026-11-12 21:21）】
21:21:48 决策 accept、创建工单 → 21:21:49 Worker 开始 → 21:22:39 报告 ready、PR 已推送 → 21:22:48 idle。
50 秒完成一个 1 字符改动的工单，全链路走完：拉代码、建 worktree、建分支、改文件、验证 diff、commit、push、开 PR、写描述、回 Issue 评论。
PR 描述自动带一行：This is by an automated agent, not a human.
它还拒绝了多余操作：指令只让改一处，bug.md 里其实有两个错字，它明确写了第二处故意没动并 flag 给你；另外两个内容重复的 Issue 被判 duplicate work 而 ignore。

【四个坑的卡时与报错位置】
坑1 面板不能绑 0.0.0.0 / 也不能绑网卡 IP —— 20 分钟 —— 启动日志，有明确报错
坑2 pnpm build 缺 unrun —— 15 分钟 —— 构建输出，有明确报错
坑3 GitHub 必须两个账号 —— 40 分钟 —— 没有任何报错，只是不触发
坑4 模型 provider 缺 apiKey —— 120 分钟 —— 不在日志里，藏在 Session 事件流
合计 195 分钟，其中坑四一项占 61.5%。

【坑四的排查路径（这才是重点）】
误判一：以为是模型太慢。库里一堆 {"kind":"unavailable","reason":[{"code":"timeout"}]}，把 eval.timeoutSeconds 从 120 调到 600，无效。实测模型单次请求 1.1 秒、并发 3 个各 1.4 秒——模型没问题。
误判二：以为进程卡死。`ss -tnp | grep 8888` 是空的，一条到模型服务的 TCP 连接都没有；进程 STAT=Ss、%CPU=0.0，日志只有一行 listening，零错误输出。请求压根没发出去。
真相：session.v4.jsonl.zstd 解压后找 turn/end，拿到 {"kind":"error","error":{"message":"No API key for provider: local-sglang","code":"PI_AI_ERROR"}}。
前面所有 timeout 记录都是假象——评估压根没开始，请求在发出前就被拒了。

【修复后的配置要点】
webserver: host 127.0.0.1 / port 3082（必须 loopback）
llm-pi-ai.providers.local-sglang: api openai-completions、apiKeyEnv SGLANG_API_KEY、defaultContextWindow 131072、defaultMaxTokens 32768、compat.thinkingFormat deepseek
agent-default-model: provider local-sglang / model deepseek-v4.1-flash
Executor prepare：每个工单独立 worktree + 独立分支（git worktree add --detach + checkout -b agent/<name>）

【架构为什么这么设计】
双层：Router（常驻主 Session）收消息、判权限、派活、统一对外说话，刻意不执行具体任务；Worker（每工单一个）写代码、跑测试、提 PR，上下文隔离且不直接对外说话。
官方图文里有个数字说明为什么不用提示词分工：中性提示下「主 Agent + subagent」5 次运行 0 次委派。想靠提示词劝模型自己分工劝不动，于是用架构强制分开。

【这笔账的真实结构】
模型 API 成本 0（本地）。成本换成了形态：一台常驻机器（已有）+ 电费（按 300-600W 估）+ 你的时间。
第一次跑通约 5 小时，其中 2 小时在坑四上；第二次部署 30 分钟到 2 小时能交付——这个差值就是经验的价格。
省的是 API 账单，付的是那一晚的四个报错；而报错只收一次费。

失效边界
本文是单机单次跑通记录（L0），报错原文、时间戳与 token 计数来自当晚会话实录，未做跨机器复现。「50 秒完成工单」是 1 字符改动的极简任务，复杂工单要跑十几分钟，不能当平均性能。dsh-superagent 是 DeepSeek Harness 团队放出的 research prototype，README 第一行写明「非官方产品、非生产级」，用前请自行 review 代码，别拿核心仓库试。2,323 万 token 与「完成时间压短 10-30%」引自官方公开实验结果，不是本机实测。电费按 300-600W 估算，未实测功耗。文中的部署机规格与机型表比对后归到「Xeon E5-2673 v4 / 80 线程 / 125GiB」这一档，若实际部署机不同，相关跑分应重新归属。

← 返回全部排错方案