1. 从「Prompt 又改坏了」到「这次运行到底发了什么」只要写过一阵子 Agent大概率都经历过这种局面程序能跑结果不对但你没法指出到底是哪一步偏了。改了一版 system prompt工具调用开始飘把温度从 0.2 调到 0.7知识库该被查的时候没查同一个输入重跑三次两次正常一次开始编。终端里只剩零散输出prompt 散在文件里工具描述散在代码里模型参数散在环境变量里最后只能靠加 print、翻日志、反复重跑来找原因。LLM Space 想解决的就是这件事它把 Agent 运行拆成可追踪、可重放、可评估的步骤。而模型入口这一层可以统一收口到 TaoToken 官网在 LLM Space 模型设置里把 Base URL 填为https://taotoken.net/apiKey 用YOUR_API_KEY占位再去官网控制台创建真实 Key。这样 prompt 版本、模型配置、Token 调用记录才能放在同一条线上对比。LLM Space 是面向 Agent 构建者的桌面应用定位不是“帮你写一个 Agent”而是让你看清 Agent 已经做了什么。它把一次运行拆成模型调用、工具调用、上下文拼装、最终输出等环节并允许你从历史线程里重放某一次失败运行逐步检查每一步的输入和输出。对于单人开发它减少“猜”的时间对于企业 AI 团队它让 Agent 从 demo 走向生产时多了一层可审计、可排查、可优化的工程能力。本文不再泛泛讨论 Agent 可观测性而是给出一套可跟做的收口方案第一LLM Space 模型设置怎么填第二Claude Code、Codex、CC Switch 的配置怎么分开写第三一次失败运行怎么重放第四Token 调用记录怎么留成可评估的数据。所有命令和配置都由读者在本地执行生产库、敏感数据不要直接接进调试链路。2. 先把模型入口收口LLM Space 模型设置对照Agent 调试最怕变量太多。你以为是 prompt 写坏了实际是模型供应商换了你以为是工具返回格式不对实际是 Base URL 指向了另一个环境。把模型入口统一到 TaoToken至少能让“模型调用”这一层保持稳定重放时才有可比性。在 LLM Space 里模型设置通常需要填供应商类型、Base URL、API Key、模型名和推理参数。下面是一份建议对照表设置项建议值说明ProviderOpenAI Compatible 或 Anthropic Compatible按 LLM Space 当前版本支持的协议选择Base URLhttps://taotoken.net/api注意这里不加 UTM 参数作为工具配置保持干净API KeyYOUR_API_KEY到 TaoToken 控制台创建后替换Model你的目标模型名重放时不要频繁换模型Temperature0.1 到 0.3调试阶段先降低随机性Max Tokens按任务设置记录输出长度便于对比Timeout60s 到 120sAgent 链路可能较长操作路径可以按这个顺序走打开 LLM Space进入模型设置或 Provider 设置。新建一个配置名称建议写taotoken-debug不要写“测试1”“临时”这种无法追溯的名字。Base URL 填https://taotoken.net/api。API Key 先填YOUR_API_KEY真正运行时替换为控制台创建的 Key。创建入口在 TaoToken 官网。选择模型名保存配置。在 Agent 线程里固定使用这个配置重放时不要切换。如果你习惯用配置文件管理可以把等价设置写成 JSON方便纳入版本管理{ provider: openai-compatible, name: taotoken-debug, base_url: https://taotoken.net/api, api_key: YOUR_API_KEY, model: gpt-4.1-mini, temperature: 0.2, max_tokens: 2048, timeout_seconds: 90 }这份配置的重点不是某个具体模型名而是三个稳定项Base URL 固定、Key 来源固定、配置名称可追溯。调试 Agent 时最怕“这次跑不对”之后发现模型设置被手动改过。把模型入口收口到 TaoToken 后每次重放至少能确认请求发到了同一个 API 入口Key 属于同一个项目Token 记录也能在控制台侧对照。还有一个小细节Base URL 不要带 UTM 参数。UTM 是给官网页面统计用的不是给 API 请求用的。工具配置只填https://taotoken.net/api否则某些 SDK 可能把查询参数拼进请求路径导致 404 或签名异常。3. Claude Code、Codex、CC Switch三套配置不要混很多团队在调试 Agent 时会同时用 Claude Code、Codex 和 CC Switch。三者配置入口不同最容易犯的错误是把 Claude Code 的ANTHROPIC_*环境变量复制到 Codex或者把 Codex 的config.toml当成 Claude Code 的配置。下面分开写便于直接复制。3.1 Claude Code用 settings.json 和 ANTHROPIC_*Claude Code 走 Anthropic 协议时常见配置是settings.json里的env段或者系统环境变量。Base URL 指向 TaoTokenKey 用YOUR_API_KEY占位。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514, ANTHROPIC_SMALL_FAST_MODEL: claude-3-5-haiku-20241022 } }如果你不在settings.json里写也可以在本地 shell 中临时导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-20250514注意ANTHROPIC_*是 Claude Code / Anthropic SDK 这一侧的变量命名。不要把它写进 Codex 配置也不要用ANTHROPIC_AUTH_TOKEN去驱动 Codex。两套工具读取的配置键不同混用只会让你在重放时得到不可解释的报错。3.2 Codex用 config.toml 和独立环境变量Codex 常见配置在~/.codex/config.toml或项目级配置中。它使用model_providers定义供应商Base URL 同样填https://taotoken.net/api但环境变量建议用独立命名例如TAOTOKEN_API_KEY。model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses本地运行时导出 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你在 CI 或容器里运行不要把 Key 写进镜像层也不要在config.toml里硬编码。让env_key指向环境变量Key 由运行环境注入。这样 Token 调用记录和 Key 轮换都更好管理。3.3 CC Switch三件套填法CC Switch 这类切换工具核心是三件套配置名称、Base URL、API Key。可以新建一个供应商配置{ name: TaoToken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY }保存后CC Switch 里应该能看到一个名为TaoToken的配置项。切换时确认当前激活的是它而不是旧的默认供应商。调试 Agent 前先检查三处LLM Space 的模型设置、Claude Code 的settings.json、Codex 的config.toml。如果三处都指向同一个 Base URL但 Key 不同也会导致 Token 记录分散在多个项目下评估时无法对齐。这里再强调一次边界ANTHROPIC_*只用于 Claude Code / Anthropic 协议侧Codex 用config.toml和TAOTOKEN_API_KEYCC Switch 只负责三件套切换。不要让三套配置互相污染。把配置分开是让重放可信的第一步。4. 重放一次失败运行六个检查点LLM Space 的价值在于它不让你单步“代码”而是让你单步“Agent 的思考和动作”。传统程序是确定性的断点进去能看变量Agent 背后是概率推理同一个输入每次输出都可能不同。问题往往不在某一行代码而在某一次模型调用收到的上下文、某个工具返回的格式、某段 prompt 的措辞。下面用“客户咨询自动回复”这个场景做例子。Agent 应该先查知识库再回答。但某次失败运行里它没查知识库直接编了一个答案。以前你只能翻日志、猜是检索问题还是 prompt 问题。用 LLM Space可以重放这次运行按六个检查点逐步看。第一步打开历史线程找到失败的那次 run。记录它的线程名、运行时间、使用的模型配置。建议命名方式包含日期和 prompt 版本例如customer-reply-20260908-sys-v7。第二步点击重放。重放时尽量冻结变量同一个模型配置、同一个 Base URL、同一个 Key、同一个 prompt 版本。如果重放时换了模型结果不可比。第三步按六个检查点逐步检查输入与系统消息。看用户原话是什么system prompt 是哪个版本有没有拼进额外的角色设定。很多“答偏”其实是 system prompt 被另一个配置覆盖了。模型参数。看 temperature、max tokens、stop 条件。调试阶段温度过高会让工具调用选择变得不稳定。模型请求。看实际发给模型的消息数组尤其是工具描述和上下文摘要。这里能发现“知识库工具描述被截断”之类的问题。工具调用参数。看模型决定调用哪个工具、传了什么参数。该查知识库却没查可能是工具命名、描述或参数 schema 让模型理解偏了。工具返回。看知识库返回了什么。如果返回为空、格式异常或命中错误分片模型只能编。最终输出与评估。看模型如何基于工具返回生成答案以及这次运行在评估里被标记为成功还是失败。重放时建议在旁边开一个记录文件把每个检查点的关键信息写下来。比如{step:input,thread:customer-reply-20260908-sys-v7,user_query:退货政策是什么,system_prompt_hash:sys-v7} {step:model_request,model:gpt-4.1-mini,temperature:0.2,tool_choice:auto,context_tokens:1482} {step:tool_call,tool:kb_search,args:{query:退货政策,top_k:3},called:false} {step:model_output,answer:根据我们的政策7天内可以退货...,confidence:null} {step:eval,result:failed,reason:未调用知识库直接生成}这份记录不用很复杂关键是可追溯。下一次重放时你能对比哪些字段变了。LLM Space 的追踪、重放、评估三个动作正好对应“发现问题、复现问题、衡量问题”。当你能稳定复现一次失败运行调试就从玄学变成了工程。5. Token 调用记录把每次重放变成可对比的数据只重放不记录评估仍然靠感觉。Agent 开发需要数据每次运行用了哪个模型、输入多少 Token、输出多少 Token、耗时多少、调了哪些工具、最终结果如何。Token 调用记录不是为了算账而是为了对比。你可以用本地脚本调用 TaoToken API把响应里的 usage 落成 JSONL。下面是一个最小示例命令由读者在本地执行export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYYOUR_API_KEY curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4.1-mini, messages: [ {role: system, content: 你是一个客服 Agent必须先查知识库。}, {role: user, content: 退货政策是什么} ], temperature: 0.2, stream: false } | tee -a token_calls.jsonl实际使用时你可以在脚本里再追加线程名、prompt 版本、工具调用结果。建议至少记录这些字段字段含义ts运行时间threadLLM Space 线程名prompt_versionprompt 版本号model模型名base_url固定为https://taotoken.net/apiinput_tokens输入 Tokenoutput_tokens输出 Tokenlatency_ms耗时tool_calls工具调用列表result成功、失败或待评估一条记录可以长这样{ts:2026-09-08T10:12:33Z,thread:customer-reply-20260908-sys-v7,prompt_version:sys-v7,model:gpt-4.1-mini,base_url:https://taotoken.net/api,input_tokens:1482,output_tokens:276,latency_ms:2310,tool_calls:[kb_search],result:passed} {ts:2026-09-08T10:15:02Z,thread:customer-reply-20260908-sys-v7,prompt_version:sys-v7,model:gpt-4.1-mini,base_url:https://taotoken.net/api,input_tokens:1510,output_tokens:198,latency_ms:1980,tool_calls:[],result:failed_kb_skip}把这份 JSONL 和 LLM Space 里的重放结果放在一起你就能回答几个关键问题换 prompt 版本后工具调用率是升了还是降了换模型后Token 消耗和延迟怎么变同一类问题失败时是模型没调工具还是工具返回为空。企业团队做 Agent 评估时最怕没有基线。Token 调用记录就是最基础的基线数据。需要提醒的是本地调试记录不要写入生产数据库也不要把真实用户隐私、密钥、完整 prompt 明文提交到公共仓库。Key 用YOUR_API_KEY占位真实 Key 放在本地环境变量或密钥管理服务里。SQL 和命令都由读者在本地执行不要从 Agent 直连生产库。6. 企业团队落地私有化、可审计与边界LLM Space 的 local-first 特性对企业 AI 团队很有吸引力。线程作为本地文件存在prompt、工具配置、运行记录都留在开发机上。对于做私有化部署、处理敏感数据的团队这一点是刚需。调试 Agent 时prompt 里可能包含业务规则工具返回里可能包含客户信息Key 更是不能外泄。把这些留在本地比上传到某个不可控的云端调试平台更稳妥。把模型入口收口到 TaoToken还能带来一层管理便利Base URL 统一为https://taotoken.net/apiKey 在控制台创建和轮换Token 调用记录可对照。团队里不同成员可以各自持有 Key但使用同一套 API 入口和模型命名规范。重放失败运行时配置漂移更少。它适合谁正在构建和调试 Agent 的开发者尤其是被“跑不对但不知道哪错了”折磨的人。需要让 Agent 从 demo 走向生产要求可追踪、可重放、可评估的团队。重视数据主权希望 prompt、线程文件和 Key 尽量留在本地的私有化场景。它不适合谁只想使用现成 Agent、不参与构建的非技术用户。它是开发者工具不是终端产品。追求零配置开箱即用的人。追踪、重放、评估这套工作流需要花时间理解。希望把所有调试数据自动上传云端做协同的人。它的优势恰恰在本地优先。还要诚实提醒LLM Space 是桌面应用偏开发者工具仍在快速迭代。别指望它像成熟 IDE 那样面面俱到。它不会让你的 Agent 更聪明但会让你更能看清 Agent 到底做了什么。对于要上生产的 Agent 来说这种可观测性和可复现性比“偶尔聪明一次”更稀缺。7. 文末 CTA从模型对话到 Claude Code 文档如果你准备把 LLM Space、Claude Code、Codex 的模型入口统一收口可以按这个顺序走先到 模型对话 验证模型和 Key 是否能正常调用。如果调试频率高看 Coding Plan 是否适合你的日常开发用量。到 API Keys 创建真实 Key替换本文配置里的YOUR_API_KEY。需要把 Claude Code 接到同一套 Base URL参考 Claude Code 文档 完成settings.json和ANTHROPIC_*配置。最后回到 TaoToken 官网 管理项目和控制台配置。把 Base URL 固定为https://taotoken.net/api把 Key 占位符换成YOUR_API_KEY对应的真实值再把 LLM Space 的模型设置、Claude Code 的settings.json、Codex 的config.toml、CC Switch 的三件套分别配好。下一次 Agent 跑偏时你至少不用从“它到底调了哪个模型”开始猜而是直接打开线程重放看每一步。