1. 先把模型出口固定LLM Space 重放 Agent 失败运行前的第一步用 LLM Space 重放 Agent 失败运行之前先把模型出口固定下来TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_agent_debug 拿 KeyBase URL 填 https://taotoken.net/api。很多人第一次用 LLM Space注意力全在「重放」和「评估」上结果卡在更靠前的环节模型设置里的接入地址填错、Key 从别的地方凑、模型 ID 和控制台对不上于是追踪面板里全是 401 和空响应根本谈不上定位故障。这篇把顺序倒过来先把出口配通再用 LLM Space 的追踪、重放、评估三件套去拆 Agent 的每一步。Agent 跑偏的时候终端里通常只剩最后一句输出。中间发生过什么——调了哪个模型、拼了什么上下文、工具返回了什么、第几步开始不查知识库直接编——全散在一堆 print 和滚动日志里。翻日志、加打印、反复重跑一轮下来半小时起步还不一定定位得到。这是构建 Agent 的人最熟悉的一种消耗问题不是「改不动」而是「不知道改哪儿」。LLM Space 要解决的就是这件事。它是一个面向 Agent 构建者的桌面应用Mac / Windows / Linux 都可以装开源、MIT 许可、TypeScript 实现来自 DeerFlow 团队。它把 Agent 开发拆成六个动作构建把 prompt、系统消息、工具定义、模型设置做成可版本化的配置不再散落成一堆脚本常量追踪实时查看 Agent 循环里的每一次模型调用、每一次工具执行调试从历史记录里重放某次运行逐步执行找出跑偏的那一步评估用数据衡量多次运行的表现而不是「感觉还行」管理线程以本地文件形式存在保持有序、可检索生成辅助写 prompt 和工具甚至把一条线程转成可运行的 LangGraph Agent。这六件事里前五件都依赖同一个前提每一次模型调用得被完整、准确地记录下来。如果出口是拼凑的记录里就会出现「模型字段一会儿是这个、一会儿是那个」的噪声重放对比就失去了意义。所以第一件事不是装工具而是让模型出口稳定、可复现、可对账。LLM Space 的定位偏开发者工具不是给非技术用户的开箱即用产品。它需要你花一点时间理解「追踪 / 重放 / 评估」这套工作流理解之后调试方式会发生一个明显变化从单步「代码」变成单步「Agent 的思考与动作」。2. LLM Space 模型设置对照Base URL、Key、模型 ID 一次填对LLM Space 是 local-first 的线程文件、配置、Key 都存在你自己的机器上。这一点对做企业 AI、做私有化部署的团队很关键——调试 Agent 的过程里prompt、业务数据、Key 都属于敏感信息留在本地比上传云端更让人放心。也正因为它是本地应用模型出口这件事必须由你自己指定。先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_model_settings 获取 Key。拿到之后别直接贴进聊天窗口或提交到仓库先放进本地密码管理器再填进 LLM Space。在 LLM Space 的模型设置里按下面这张表逐项对照填能避开绝大多数「连不上」和「记录对不上」的问题设置项填写内容容易踩的坑Provider / 接口类型OpenAI 兼容 / 自定义选错协议类型工具调用字段会解析失败Base URLhttps://taotoken.net/api末尾不要多加斜杠也不要自己拼错路径层级API KeyYOUR_API_KEY前后多余空格、误带引号是最常见的 401 来源模型 ID以控制台可用模型列表为准手写模型名容易错大小写建议直接复制流式输出开启关掉之后追踪面板的实时颗粒度会变粗工具调用开启关掉后重放里看不到工具节点等于自断线索Base URL 这一项特别说明一下统一填https://taotoken.net/api不要再往后追加别的前缀或后缀。很多人习惯把 OpenAI 风格的完整路径一次性粘进去结果请求打到了不存在的端点追踪里只留下一个 404还以为是 Key 的问题。为了便于团队留档和复现建议把同一份出口配置在本地记录一份不要提交到版本库# .env.local —— 仅本地留存务必加入 .gitignore TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_MODELyour-model-id# .gitignore .env.local .env.*.local这里有一个判断标准如果追踪面板里的每一次调用模型字段、供应商字段都是一致的那么后续做重放对比时你观察到的差异就大概率来自 prompt、上下文或工具返回而不是「这次换了另一个模型」。把变量控制住排查才有因果。3. 同一份出口配置在 Claude Code / Codex / CC Switch 里怎么写LLM Space 本身是 GUI 配置没有可直接复制的配置文件但如果你的日常链路里同时还跑着 Claude Code 或 Codex最好让它们指向同一个出口。这样跨工具的追踪、Token 用量、故障时间线才能对齐。下面三份配置只针对两个不同的客户端请注意它们的字段体系并不通用。Claude Code 走的是ANTHROPIC_*体系写在 settings.json 里{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: your-claude-model-id } }三个字段的含义分别是ANTHROPIC_BASE_URL指向接入地址ANTHROPIC_AUTH_TOKEN放你自己的 KeyANTHROPIC_MODEL填控制台里可用的 Claude 系列模型 ID。这个文件通常放在项目的.claude/settings.json或用户级配置目录下具体读取位置以你当前 Claude Code 版本的说明为准。改完先在终端跑一句最简单的对话验证再去跑长任务。Codex 走的是另一套model_provider体系写在 config.toml 里model your-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat注意这里有一个高频错误不要把ANTHROPIC_*环境变量搬到 Codex 上。Codex 不认识这套变量它的env_key指向的是一个环境变量名值需要你自己在 shell 里导出export TAOTOKEN_API_KEYYOUR_API_KEYwire_api这一项建议与你的客户端版本说明保持一致如果工具调用一直解析不出来优先检查这里和 Provider 类型。CC Switch 是用来在多个供应商配置之间切换的工具配置它只需要记「三件套」配置项值Base URLhttps://taotoken.net/apiAPI Key / TokenYOUR_API_KEY默认模型与 Claude Code 中使用的模型 ID 保持一致切换前先备份原配置切换后用一次最小对话验证连通性再回到长任务。这样做的价值在于出问题的时候你能快速判断故障发生在出口切换之后还是之前而不是把所有环节重新怀疑一遍。4. 重放一次失败运行可复现的八步排查流程拿一个具体场景来走你在做一个「客户咨询自动回复」的 Agent。上线前自测发现它对某一类问题总是答偏——本该先去知识库检索它却直接开始编答案。以前的排查路径是翻日志 → 找到那次调用 → 看 prompt → 看检索返回 → 猜是检索问题还是措辞问题 → 改一处 → 重跑 → 再观察。现在换成 LLM Space 的重放流程可以更收敛复现并锁定线程。用同一句输入再跑一次确认问题稳定出现记下这条线程和这次运行的标识。不稳定复现的问题先解决复现不要急着改 prompt。打开这次运行的追踪视图。按步骤展开 Agent 循环step序号应当连续如果出现跳号先怀疑编排层丢了节点而不是模型行为异常。定位分叉点。找第一次「本该调工具却没有调」的那一步这就是故障的分叉位置而不是最后输出错答案的那一步。重放该次运行。从历史记录里把它重新拉起来逐帧推进保持输入和工具环境不变。逐步比对三样东西模型实际收到的上下文系统消息 历史 检索片段、工具返回的原始内容格式和字段是否完整、模型给出的工具调用意图有没有生成、参数对不对。单独验证一次模型调用。把同样的上下文拿出来单独发一次请求看它是否依然选择不调工具。这一步用于区分「prompt 措辞让模型误解」和「检索内容质量太差模型判断不值得用」。只改一处再跑一次。新旧两次运行并排看确认差异确实由这一处改动引起。一次改多个地方等于把变量重新搅浑。把这条失败样本加入评估集。它不该被修完就丢掉而应该成为长期回归用例。这套流程真正的变化是排查从「猜」变成了「看」。传统调试器依赖确定性——同一输入必得同一路径断点和单步才有意义而 Agent 背后是概率推理同一输入两次运行的结果都可能不同。所以对 Agent 有效的调试方式不是单步代码行而是单步「它想了什么、调了什么、为什么这么选」。这也是 LLM Space 这类工具存在的理由。5. Token 调用记录怎么读一次运行里该盯哪几个字段追踪能给到的原始信息通常可以整理成一条条结构化记录。为便于对账和长期留档建议按下面的形态记录每次模型调用{run_id:run_20260908_01,step:3,model:your-model-id,prompt_tokens:1840,completion_tokens:126,tool_calls:[{name:kb_search,status:ok,latency_ms:742}],finish_reason:tool_calls} {run_id:run_20260908_01,step:4,model:your-model-id,prompt_tokens:2210,completion_tokens:88,tool_calls:[],finish_reason:stop}对应到排查动作几个字段值得重点看run_id/step用来确认追踪是否完整以及分叉发生在第几步model用来确认整条链路没有中途换模型这是重放对比成立的前提prompt_tokens突然暴涨通常意味着历史消息没有裁剪上下文被越滚越长completion_tokens输出异常短而问题没解决可能是被长度限制截断tool_calls[].name与status出现tool_calls却没有后续执行说明编排层丢节点工具返回错误但模型继续生成说明错误没有被回灌给模型latency_ms耗时高而 Token 不多多半是网络链路或上游排队而不是模型推理本身慢finish_reasontool_calls与stop的切换点往往就是行为分叉点。把这份记录和 TaoToken 控制台里的用量视图对照能进一步确认「本地追踪到的调用」和「出口侧统计到的消耗」是否一致。对账入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_token_log 。两边对得上说明追踪链路没有丢事件对不上问题通常出在并发上报、重试或超时重发上。6. 接入后高频故障对照表401、404、模型名、流式、工具调用刚接上的那半天遇到的问题大多集中在几个固定位置。按现象对照处理能省下大量试错时间现象常见原因处理方式401 / 403Key 填错、前后有空格、误带引号重新复制 Key 到YOUR_API_KEY位置检查是否有隐藏字符404Base URL 拼错或被追加了多余路径只填https://taotoken.net/api不要自己往后拼模型不存在模型 ID 与控制台列表不一致大小写不同直接从控制台复制模型 ID流式响应中断本地代理缓冲、超时设置过短检查本地网络代理与客户端超时配置工具调用解析失败Provider 类型选成了非 OpenAI 兼容协议回到模型设置改回兼容协议追踪里没有工具节点工具调用开关被关闭在模型设置中重新开启记录断号编排层在异常分支里直接结束了循环检查 Agent 循环的异常处理路径有一点需要反复强调排障时不要同时改多个变量。先确认出口连通能不能正常拿到一次响应再确认记录完整追踪里是否有完整的 step 序列最后再回到 Agent 逻辑本身。顺序错了你会发现每个环节看起来都有嫌疑。7. 从「能跑」到「可信」评估、回归与团队协作Agent 开发这两年正在经历一个转折不再满足于「能跑通」开始追问「为什么这么跑、跑得对不对、怎么让它更可靠」。任何技术从 demo 走向生产都要经过同一道门槛——可观测、可调试、可评估。软件有 debugger、有 APM、有测试覆盖率Agent 需要对应的一套东西LLM Space 的评估能力就是冲着这个来的。具体到团队协作可以用三个小指标把「感觉还行」变成可对话的数据任务成功率同一批输入跑 N 次多少次达成预期结果平均步数完成同一任务所需的 Agent 循环步数步数变多往往是 prompt 或工具描述退化的信号工具命中率该调工具时是否调了工具返回错误后是否正确降级单次平均 Token结合追踪记录统计用于判断上下文裁剪策略是否有效。把这四项做成一个固定的评估集每次改 prompt、换模型、调整工具描述之后跑一遍回归问题会明显更早暴露。评估集的输入建议直接来自真实失败样本——前面第八步留下的那批用例是性价比最高的素材。对做企业 AI 落地的团队来说这套能力的价值很直接客户最关心的往往不是「你的 Agent 有多聪明」而是「出了错能不能快速定位、能不能解释清楚、能不能持续优化」。没有可观测性这三个问题一个都答不上来有了它Agent 才具备进入生产环境讨论的资格。数据主权方面LLM Space 把线程和配置留在本地配合你自己持有的 Key敏感信息不必离开内网。更多接入与配置信息可以从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_team_ready 进入查看。最后补一句诚实的提醒LLM Space 还在快速迭代功能会持续演进不要指望它像成熟 IDE 那样面面俱到它适合正在构建、调试 Agent 的开发者以及需要把 Agent 从 demo 推向生产、要求可观测可评估的团队。如果你只是 Agent 的使用者这套工具帮不上忙。8. 下一步把出口和追踪链路一次性配通顺序建议按下面四步走每一步都能单独验证出问题也容易定位先用模型对话验证出口。打开 https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_chat 确认 Key 和接入地址能正常拿到响应这一步不涉及任何 Agent 逻辑。需要长期跑 Agent 循环和编码任务看 Coding Plan。https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_coding_plan 按实际调用量选择合适的方案避免调试期间频繁卡在额度上。创建并管理 Key。到 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_api_keys 生成 Key需要区分环境时建议一个环境一把便于按环境对账和回收。接 Claude Code 时对照官方文档。https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentllm_space_claude_code_doc 把 settings.json 里的字段逐项核对避免把 Codex 的配置体系混进来。回到最开始那个问题Agent 跑不对的时候你需要的是能看见它的每一步。LLM Space 提供了追踪、重放、评估这套观察手段TaoToken 提供的是稳定、可对账的模型出口——Base URL 填https://taotoken.net/apiKey 用YOUR_API_KEY占位替换成你自己的。两者接上之后你的 Agent 不会因此变得更聪明但它做的每一个决定都能被翻出来看清楚。对正在把 Agent 推向生产的团队来说这比「聪明」更稀缺。