1. 从零搭建 AI-Research 深度探索智能体为什么总卡在工具链上想徒手打造一个类 Manus 的深度探索智能体核心思路其实不复杂让 DeepSeek-R1 负责推理和规划让 websearch 负责把外部信息捞回来中间用一套循环把「检索—反思—总结」串起来最后吐出一份 Markdown 研究报告。听起来很顺但真正动手的人大多会卡在同一个地方——工具链的 Key 太散了。我试过最原始的搭法DeepSeek-R1 的推理 Key 一个、websearch 的检索 Key 一个、后面接 coding 工具或 Agent 框架时又是另一套凭证。每换一个环节就要改一次环境变量每换一台机器就要重新配一遍。更麻烦的是当你想把 DeepSeek-R1 换成别的模型、或者给 websearch 加一个备用检索源时代码里散落各处的base_url和api_key会让你改到怀疑人生。这篇要解决的就是这个问题。目标很明确用 TaoToken 的统一 Key 把 DeepSeek-R1 推理和 websearch 检索这两条链路收敛到一套配置里交付一份可以直接复制的settings.json/config.toml骨架再配合 CC Switch / Cline 侧的验证动作把「检索—推理—汇总」这个闭环真正跑通。适合谁适合已经会写一点 Python、想自己搭 Agent 但不想被 Key 管理拖住的人也适合已经在用 Cline 这类工具、想把深度研究能力接进现有工作流的人。整个 AI-Research 的运行逻辑可以拆成四步。第一步是研究计划让 DeepSeek-R1 根据用户 query 生成报告大纲拆成若干段落。第二步是逐段研究每个段落先由模型规划出搜索查询交给 websearch 执行拿回结果。第三步是反思迭代模型看着已有总结判断还缺什么再补一轮搜索。第四步是汇总成稿把所有段落的最新状态拼成 Markdown。这四步里第一步和第三步强依赖推理模型第二步强依赖检索工具而它们之间的凭证如果各管各的调试成本会成倍上升。2. TaoToken 前置把 DeepSeek-R1 和 websearch 收敛到一套 Key在动手写 Agent 之前先把凭证这层理顺。TaoToken 在这里扮演的角色是统一入口你不需要为每个模型或每个工具单独维护一套 Key而是通过一个 API 地址和一份 Key 来访问背后的模型能力。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时直接用这个干净地址。具体要准备的东西有三样。第一是 TaoToken 的 API Key在控制台的 API Keys 页面生成地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。第二是确认你要用的模型名DeepSeek-R1 系列在模型对话页可以看到可用列表地址是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。第三是 websearch 的检索凭证如果你用的是 Tavily 这类检索服务它自己的 Key 仍然需要单独申请但调用方式可以统一收进同一份配置文件里管理。这里要区分清楚TaoToken 统一的是模型推理侧的 Keywebsearch 作为外部检索工具它的 Key 是独立的一环。所谓「统一 Key 打通工具链」指的是把推理和检索的配置都收进同一份settings.json或config.toml让 Agent 启动时只读一个配置源而不是在代码里到处os.getenv。这样你换模型、换检索源、换机器都只改一个文件。如果你后面打算长期跑编码类或 Agent 类任务可以顺带看一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合需要持续调用模型的场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置参数有疑问时对着文档核对。3. 可复制配置settings.json 与 config.toml 骨架先给一份settings.json骨架适合 Cline、CC Switch 这类工具直接读取。核心是把模型推理的base_url指向 TaoToken 的 API 入口api_key用你的 TaoToken Key模型名填 DeepSeek-R1 对应的标识。websearch 部分单独放一个块保留它自己的 Key 字段。{ llm: { provider: taotoken, base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key, model: DeepSeek-R1, temperature: 1, max_tokens: 8192 }, websearch: { provider: tavily, api_key: tvly-your-tavily-key, max_results: 5, include_raw_content: true }, agent: { reflection_iterations: 2, max_paragraphs: 5, output_format: markdown } }如果你更习惯 TOML下面这份config.toml是等价的字段名保持一致方便你在 Python 里用tomllib或toml库读取。[llm] provider taotoken base_url https://taotoken.net/api api_key sk-your-taotoken-key model DeepSeek-R1 temperature 1 max_tokens 8192 [websearch] provider tavily api_key tvly-your-tavily-key max_results 5 include_raw_content true [agent] reflection_iterations 2 max_paragraphs 5 output_format markdown配置里几个参数值得说明。temperature设成 1 是因为 DeepSeek-R1 这类推理模型在规划阶段需要一定的发散性设太低会让大纲过于保守。reflection_iterations控制每个段落反思几轮设 2 是成本和质量的平衡点设太高会明显拉长单次研究时间。max_results控制每次 websearch 返回几条结果5 条是实测下来信息量和 token 消耗比较均衡的值。include_raw_content打开后能拿到网页正文对后续总结质量帮助很大但会显著增加 token 消耗如果预算紧可以关掉只留摘要。在 Python 侧读取这份配置的代码大概长这样注意base_url直接用 TaoToken 的 API 地址不要带任何多余路径。import json import os from openai import OpenAI with open(settings.json, r, encodingutf-8) as f: cfg json.load(f) client OpenAI( api_keycfg[llm][api_key], base_urlcfg[llm][base_url], ) def call_model(system_prompt, user_content): response client.chat.completions.create( modelcfg[llm][model], messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperaturecfg[llm][temperature], ) return response.choices[0].message.content这里有个细节DeepSeek-R1 的输出里会带thinking标签里面是推理过程。Agent 真正需要的是标签之后的内容所以得写一个清理函数。def remove_reasoning_from_output(output: str) - str: return output.split()[-1].strip()这个函数看着简单但少了它后面解析 JSON 大纲时会频繁报错因为推理过程里可能混着花括号和引号。4. 验证请求从单次调用到检索—推理—汇总闭环配置写好后先别急着搭完整 Agent用一次最小请求验证 TaoToken 这条链路是通的。跑下面这段代码如果能看到模型正常返回内容说明 Key 和base_url没问题。resp call_model( system_promptYou are a helpful assistant., user_content用一句话说明深度研究智能体的核心循环。, ) print(remove_reasoning_from_output(resp))预期结果是模型输出一句关于「检索—反思—总结」循环的描述。如果这里报 401说明 Key 不对报 404说明base_url或模型名写错了。确认单次调用通过后再往下接 websearch。websearch 这一环用 Tavily 举例调用逻辑很直接。from tavily import TavilyClient def tavily_search(query, cfg): client TavilyClient(api_keycfg[websearch][api_key]) return client.search( query, include_raw_contentcfg[websearch][include_raw_content], max_resultscfg[websearch][max_results], )现在把两步串起来验证「检索—推理—汇总」的最小闭环。先让模型根据主题生成搜索查询再执行检索最后让模型基于检索结果写一段总结。topic 人类物种的认知特征 # 第一步让模型规划搜索查询 plan_prompt 你是一个研究助手。根据用户主题输出一个最优的搜索查询只返回查询本身。 search_query remove_reasoning_from_output( call_model(plan_prompt, topic) ).strip() print(搜索查询:, search_query) # 第二步执行 websearch results tavily_search(search_query, cfg) raw_contents [ r[raw_content][:20000] for r in results[results] if r.get(raw_content) ] print(检索到结果数:, len(raw_contents)) # 第三步让模型基于检索结果总结 summary_prompt 你是一个研究助手。根据给定的搜索结果写一段结构清晰的总结。 summary_input f主题{topic}\n\n搜索结果\n \n---\n.join(raw_contents) summary remove_reasoning_from_output( call_model(summary_prompt, summary_input) ) print(总结:, summary[:300])跑通这段你会看到三个阶段的输出一个搜索查询、一个检索结果数量、一段总结文本。这就是 AI-Research 的最小闭环。把它套进循环对大纲里的每个段落重复执行再在每轮之后加一次反思搜索就得到了完整的深度探索流程。反思步骤的提示词可以这样写让模型看着已有总结判断还缺什么。reflection_prompt ( 你是一个研究助手。给定段落标题、计划内容和当前总结 判断是否遗漏了关键方面并输出一个新的搜索查询。只返回查询本身。 ) reflection_input f标题{title}\n计划{content}\n当前总结{latest_summary} next_query remove_reasoning_from_output( call_model(reflection_prompt, reflection_input) ).strip()拿到next_query后再跑一次tavily_search把新结果并进search_history再让模型更新latest_summary。这个循环跑reflection_iterations次就停。5. 本篇常见错排查配置、解析与调用三类问题第一类问题出在配置读取上。最常见的现象是api_key读成了空字符串原因是settings.json里的 Key 字段名和代码里取的不一致。建议在读取后加一行断言assert cfg[llm][api_key].startswith(sk-)早点暴露比后面报 401 强。另一个坑是base_url末尾多写了/v1或/chat/completionsTaoToken 的 API 入口就是https://taotoken.net/api路径由 SDK 自己拼你多写反而会 404。第二类问题出在 JSON 解析上。DeepSeek-R1 在生成大纲时输出里可能带 json代码块标记也可能在 JSON 前后混入解释文字。直接json.loads会抛异常。处理办法是先remove_reasoning_from_output去掉思考过程再用clean_json_tags 去掉代码块标记。def clean_json_tags(text: str) - str: return text.replace(json\n, ).replace(\n, ).strip()如果清理后还是解析失败大概率是模型输出了不完整的 JSON比如数组没闭合。这时候可以在提示词里强调「只返回 JSON不要附加任何解释」并且把temperature稍微调低一点牺牲一点发散性换稳定性。第三类问题出在 websearch 调用上。raw_content字段不是每条结果都有有些网页抓不到正文就只返回摘要。代码里必须用if r.get(raw_content)过滤否则会拿到None然后在拼接字符串时报TypeError。另外max_results设太大时单次请求的响应时间会明显变长建议从 5 开始试稳定后再往上加。还有一类容易被忽略的问题反思循环没有终止条件。如果模型每次反思都输出一个新查询循环会一直跑下去。所以reflection_iterations这个计数器必须在每轮结束后自增达到上限就强制跳出。这个字段在状态结构里要单独维护别指望模型自己停。6. 把闭环接进 Cline / CC Switch 与后续扩展配置和闭环都验证通过后下一步是把它接进你日常用的工具。如果你用 Cline可以在它的模型设置里把 provider 选成自定义 OpenAI 兼容接口base_url填https://taotoken.net/apiapi_key填 TaoToken 的 Key模型名填 DeepSeek-R1。这样 Cline 里的对话和代码任务就走同一条链路不用再单独配一套。CC Switch 侧同理把配置文件指向同一份settings.json即可。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的参数说明和示例。如果你更想先在网页上直接试模型效果模型对话页在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 可以拿它来快速验证提示词。长期跑编码和 Agent 任务的话Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 按需选用。后续可以扩展的方向有几个。一是把 websearch 换成多源检索比如同时接两个检索服务在配置里加一个fallback字段主源失败时自动切备用。二是把反思次数改成动态的让模型自己判断「信息是否足够」足够就提前结束不够就继续搜。三是在最终报告里附上每个段落的参考链接把search_history里的 URL 一起输出这样报告的可信度会高很多。这几个改动都不需要动核心循环只改配置和提示词就能实现。