1. 从一次“找不到根因”的排查说起Agent 面对陌生信息空间时最怕的不是模型不够聪明而是它根本不知道该去哪里找。你给它一个模糊提问——“订单确认邮件偶尔混入其他客户的条目”它要么把整个代码库塞进上下文然后被 token 限制卡死要么用纯语义检索召回一堆“看起来相关但逻辑无关”的文档最后告诉你“没找到”。这个场景在 Agentic Search 里非常典型任务相关信息未知需要 Agent 自己探索。15000 文件的遗留代码库、一份没看过的合同、一段 500MB 的黑盒事故日志关键信息藏在哪没人知道。渐进发现Progressive Discovery要解决的就是这个问题——让 Agent 用“广扫→聚焦→深挖”的迭代循环在有限 token 内逼近“足够好”的答案而不是追求理论最优解。这套思路的原型是 Pirolli Card 1999 年提出的信息觅食理论以及 Herbert Simon 的 satisficing 思想在 LLM Agent 上的工程化复刻。觅食者不会翻遍整片森林也不会闭眼乱走先找可能有食物的斑块有价值就深挖边际收益下降就换地方。Agent 找路也是同样的逻辑。这篇会给出 TaoToken 统一 Key/API 通道的config.toml与settings.json骨架配置并演示一次从模糊提问到精准命中的渐进发现验证流程。目标很明确让你可复制地跑通 Agent 自主找路的最小闭环。适合正在做 RAG、Agentic Search、Coding Agent 的开发者也适合想把“会搜索的 Agent”落到生产环境的人。2. TaoToken 前置统一通道与 Key 准备在跑渐进发现闭环之前先把模型调用通道理顺。TaoToken 在这里的角色是统一 Key/API 通道——你不需要为每个模型单独维护一套鉴权和 endpoint用一个 Key 就能在多个模型之间切换这对 Agent 探索场景很关键广扫阶段可以用便宜快速的模型做关键词推导和候选筛选深挖阶段再切到推理更强的模型做根因判断。先拿到 API Key。打开控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完成后在 API Keys 页面复制 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keysAPI 基础地址统一用https://taotoken.net/api注意这个地址不加 UTM 参数直接作为base_url使用。模型对话调试入口在这里可以先用它验证 Key 是否可用https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat如果你打算长期跑编码类 AgentCoding Plan 页面有更细的额度说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan接入文档在这里配置字段对不上时优先查它https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocClaude Code 相关的 Anthropic 兼容配置参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentclaudecode-anthropic提示Key 只存在本地环境变量或配置文件里不要写进代码仓库。下面配置里用TAOTOKEN_API_KEY占位你替换成自己的即可。3. 可复制配置config.toml 与 settings.json 骨架渐进发现的最小闭环需要两个配置文件一个给 Agent 运行时用config.toml一个给编辑器/工具链用settings.json。先给骨架再解释每个字段为什么这么设。3.1 config.tomlAgent 运行时骨架# config.toml - 渐进发现 Agent 运行时配置 [llm] provider taotoken base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} # 广扫阶段用快速模型深挖阶段切强推理模型 model_forage gpt-4o-mini model_deepen claude-sonnet-4-20250514 timeout_seconds 60 max_retries 2 [discovery] # 三阶段循环上限防止无限探索 max_cycles 3 # 单轮 token 预算forage 候选太多立刻截断 budget_per_cycle 20000 # 广扫候选数量上限 forage_candidate_limit 50 # 聚焦阶段精读文件数 focus_file_limit 8 # 深挖最大依赖跳数超过就停下判断 deepen_max_hops 2 # 是否追第三方库源码 follow_third_party false [tools] # 原子工具拆开给 Agent 才能基于上轮发现重组下轮动作 enable_grep true enable_glob true enable_read true enable_follow_imports true # 不要只给一个 search_codebase()那样 Agent 无法组合 atomic_tools_only true [trace] # 记录探索证据链让过程可观测 enabled true trace_fields [ phase, query, result_count, selected_count, next_phase, token_cost, elapsed_ms, files_read, signal_score, decision_reason, cycle_index, budget_remaining ] output_path ./logs/discovery_trace.jsonl [scorer] # 业务权重生产 测试核心目录 边缘近期 久未触碰 production_weight 3.0 test_weight 0.5 core_dir_weight 2.0 recent_commit_weight 1.53.2 settings.json编辑器/工具链骨架{ taotoken: { baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, defaultModel: claude-sonnet-4-20250514, fastModel: gpt-4o-mini }, agenticSearch: { mode: progressive-discovery, maxCycles: 3, budgetPerCycle: 20000, atomicTools: [grep, glob, read, follow_imports], traceEnabled: true, tracePath: ./logs/discovery_trace.jsonl }, rag: { enabled: false, note: 中小型代码库优先 agentic search超大/跨 repo 再考虑持久化索引 }, scorer: { productionWeight: 3.0, testWeight: 0.5, coreDirWeight: 2.0, recentCommitWeight: 1.5 } }3.3 关键字段为什么这么设max_cycles 3对应 satisficing 的纪律探索不能无限循环找不到就交给人。budget_per_cycle 20000是单轮 token 上限广扫阶段候选太多立刻截断否则 token 迅速爆掉。atomic_tools_only true是渐进发现的核心工程纪律——给 Agent 原子工具它才能基于上轮发现重组下轮动作只给一个search_codebase()它就失去了“找路”的能力。follow_third_party false和deepen_max_hops 2是防止深挖追进死胡同。一路追进第三方库源码读几百行无信号是生产里最常见的坑之一。设边界不追第三方库除非点名、不追超过 2 跳依赖A→B→C 后停下判断。trace_fields里的 12 个字段是让探索变成可观测工程对象的关键。Agent 为何从 47 个结果只选 5 个为何从广扫切精读为何追pod-7c2而不是换方向这些决策必须落到 trace 里变成可调试的证据链而不是藏在模型输出里暗箱操作。4. 验证请求从模糊提问到精准命中的渐进发现流程配置就绪后跑一次完整的渐进发现验证。用一个模拟的电商订单邮件 bug 场景观察 Agent 如何从模糊提问逐步收敛到精准命中。4.1 广扫阶段低成本扫描拿候选Agent 收到模糊提问“订单确认邮件偶尔混入其他客户的订单条目”。第一步不是读文件而是用 grep/glob 做低成本广扫。# 广扫找邮件发送相关入口 grep -rn send.*confirm --include*.rb ./app | head -50 # 输出示例30 个候选文件名 # app/mailers/order_confirmed.rb # app/mailers/user_notification.rb # app/workers/mailer_worker.rb # app/services/order_mailer_service.rb # ...这一阶段只看文件名、路径、匹配行、周边上下文不读完整文件。token 消耗在几千级别。Agent 在 trace 里记录{ phase: FORAGE, query: send.*confirm, result_count: 30, selected_count: 5, next_phase: FOCUS, token_cost: 3200, elapsed_ms: 1800, decision_reason: 候选过多按路径权重和近期 commit 筛选 top5 }4.2 聚焦阶段精读候选建立局部理解从 30 个候选里挑 5 个最可能的完整读。Agent 用 scorer 加业务权重生产 测试、核心目录 边缘、近期 久未触碰。app/mailers/order_confirmed.rb在这一阶段跳出。# 聚焦精读最可能的文件 cat app/mailers/order_confirmed.rb cat app/workers/mailer_worker.rb cat app/services/order_mailer_service.rb读 5 个文件后Agent 看到调用链MailerWorker → Cache.get_user → render。trace 记录{ phase: FOCUS, query: read top5 candidates, result_count: 5, selected_count: 3, next_phase: DEEPEN, token_cost: 8500, elapsed_ms: 4200, files_read: [ app/mailers/order_confirmed.rb, app/workers/mailer_worker.rb, app/services/order_mailer_service.rb ], decision_reason: 调用链指向 Cache.get_user需深挖 cache key 构造 }4.3 深挖阶段沿可疑链追找到根因沿调用链继续追读Cache.get_user的实现# 深挖追 cache key 构造 grep -rn def get_user ./app ./lib cat app/cache/user_cache.rb发现 cache key 用了order_id缺customer_id# app/cache/user_cache.rb def self.get_user(order_id) key user:order:#{order_id} # 缺 customer_id导致跨客户命中 Rails.cache.fetch(key) { User.find_by_order(order_id) } endBug 找到。仅 4 轮探索、约 18K token、3 分钟。trace 记录{ phase: DEEPEN, query: Cache.get_user cache key, result_count: 2, selected_count: 1, next_phase: VERIFY, token_cost: 6300, elapsed_ms: 2100, files_read: [app/cache/user_cache.rb], signal_score: 0.92, decision_reason: cache key 缺 customer_id与 bug 现象一致 }4.4 验证阶段用反例和边界条件确认没找错补一个 Verify 阶段用反例验证如果 cache key 加上customer_idbug 是否消失Agent 可以生成一个最小复现测试# spec/cache/user_cache_spec.rb it does not leak user across customers do user_a create(:user, order_id: 1, customer_id: 100) user_b create(:user, order_id: 1, customer_id: 200) expect(UserCache.get_user(1, customer_id: 100)).to eq(user_a) expect(UserCache.get_user(1, customer_id: 200)).to eq(user_b) end验证通过闭环完成。整个流程从模糊提问到精准命中Agent 自主找路每一步都有 trace 可查。5. 本篇常见错排查渐进发现落地时下面几个坑出现频率最高。5.1 Forage 关键词太宽token 爆掉现象“登录变慢”直接 greplogin得到 5000 候选token 迅速爆掉。解法用更窄关键词LoginController/auth_timeout或者用轻量模型把用户描述翻成 5-8 个精确词。配置里forage_candidate_limit 50就是硬截断。5.2 Focus 挑错文件读到一堆测试现象scorer 把测试文件排前面Agent 读了一堆test/spec无信号。解法scorer 加业务权重生产 测试、核心目录 边缘、近期 久未触碰。配置里production_weight 3.0、test_weight 0.5就是干这个的。5.3 Deepen 追进死胡同读第三方库几百行现象一路追进第三方库源码读几百行无信号。解法设边界不追第三方库除非点名、不追超过 2 跳依赖。配置里follow_third_party false、deepen_max_hops 2。5.4 Discovery 和 RAG 撞车Agent 不知信谁现象两个系统结果不一致Agent 不知信谁。解法先定主路径而非简单混用。中小库/隐私敏感 → Discovery超大/跨 repo → 索引灰度地带明确定义冲突谁优先。配置里rag.enabled false是默认走 Discovery需要时再开。5.5 zero_signal_rate 突然升高现象三阶段跑完仍无有效信号的比例突然升高。这往往不是模型变笨而是工具层出问题——grep 没查到、read 权限错、scorer 排序坏、索引过时。先查工具层再查模型。5.6 trace 没开探索变成暗箱现象Agent 说“找到了”但你不知道它怎么找的、为什么选这个文件。解法trace.enabled true12 个字段全记。Discovery 的价值不只是答案也包括中间证据链。6. 让 Agent 学会找路从最小闭环到生产观测跑通上面的最小闭环后下一步是把它变成可观测、可调优的小系统。三个健康指标值得盯指标含义健康线cycles_to_success_p50找到答案需几轮接近 1forage_to_focus_ratio广扫 token / 聚焦 token0.3-0.5zero_signal_rate三阶段跑完仍无有效信号的比例 5%forage_to_focus_ratio太高说明关键词太宽太低说明关键词太窄。zero_signal_rate突然升高先查工具层。工业级 Discovery 不是一段“会搜索的代码”而是一套小系统前面 atomic tools 接触真实世界中间三阶段循环控制节奏旁边业务上下文把搜索变诊断后面 trace 指标让过程可观测可调优。渐进发现的灵魂是 satisficing——不是在有限时间/有限 token/有限上下文里追求理论最优解而是找一个足够好的解。想通这点工程决策全通了为什么有max_cycles探索不能无限循环。为什么有 token budgetDiscovery 的目标是有纪律地看不是越多越好。为什么 atomic tools 优于search_codebase()拆开工具才能基于上轮重组下轮动作。为什么 agentic search 优于 RAG它不假设索引覆盖一切而是带着当前线索逐步逼近。设计探索型 Agent 的关键给原子工具、给好的 keyword 推导、给 satisficing 的纪律。这比把整个代码库一股脑塞给它重要得多。记住Discovery 是侦探——广扫够广、聚焦能准、深挖够克制。如果你在接入或排障时遇到配置对不上的问题优先查接入文档和 API Keys 页面想先验证模型对话是否通用模型对话入口长期跑编码类 Agent看 Coding Plan 的额度说明。把上面的config.toml和settings.json复制下来替换 Key跑一遍那个订单邮件的模拟场景你会对“Agent 学会找路”这件事有完全不一样的理解。
渐进发现实战：用 TaoToken 统一通道让 Agent 学会“找路”
1. 从一次“找不到根因”的排查说起Agent 面对陌生信息空间时最怕的不是模型不够聪明而是它根本不知道该去哪里找。你给它一个模糊提问——“订单确认邮件偶尔混入其他客户的条目”它要么把整个代码库塞进上下文然后被 token 限制卡死要么用纯语义检索召回一堆“看起来相关但逻辑无关”的文档最后告诉你“没找到”。这个场景在 Agentic Search 里非常典型任务相关信息未知需要 Agent 自己探索。15000 文件的遗留代码库、一份没看过的合同、一段 500MB 的黑盒事故日志关键信息藏在哪没人知道。渐进发现Progressive Discovery要解决的就是这个问题——让 Agent 用“广扫→聚焦→深挖”的迭代循环在有限 token 内逼近“足够好”的答案而不是追求理论最优解。这套思路的原型是 Pirolli Card 1999 年提出的信息觅食理论以及 Herbert Simon 的 satisficing 思想在 LLM Agent 上的工程化复刻。觅食者不会翻遍整片森林也不会闭眼乱走先找可能有食物的斑块有价值就深挖边际收益下降就换地方。Agent 找路也是同样的逻辑。这篇会给出 TaoToken 统一 Key/API 通道的config.toml与settings.json骨架配置并演示一次从模糊提问到精准命中的渐进发现验证流程。目标很明确让你可复制地跑通 Agent 自主找路的最小闭环。适合正在做 RAG、Agentic Search、Coding Agent 的开发者也适合想把“会搜索的 Agent”落到生产环境的人。2. TaoToken 前置统一通道与 Key 准备在跑渐进发现闭环之前先把模型调用通道理顺。TaoToken 在这里的角色是统一 Key/API 通道——你不需要为每个模型单独维护一套鉴权和 endpoint用一个 Key 就能在多个模型之间切换这对 Agent 探索场景很关键广扫阶段可以用便宜快速的模型做关键词推导和候选筛选深挖阶段再切到推理更强的模型做根因判断。先拿到 API Key。打开控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完成后在 API Keys 页面复制 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keysAPI 基础地址统一用https://taotoken.net/api注意这个地址不加 UTM 参数直接作为base_url使用。模型对话调试入口在这里可以先用它验证 Key 是否可用https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat如果你打算长期跑编码类 AgentCoding Plan 页面有更细的额度说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan接入文档在这里配置字段对不上时优先查它https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocClaude Code 相关的 Anthropic 兼容配置参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentclaudecode-anthropic提示Key 只存在本地环境变量或配置文件里不要写进代码仓库。下面配置里用TAOTOKEN_API_KEY占位你替换成自己的即可。3. 可复制配置config.toml 与 settings.json 骨架渐进发现的最小闭环需要两个配置文件一个给 Agent 运行时用config.toml一个给编辑器/工具链用settings.json。先给骨架再解释每个字段为什么这么设。3.1 config.tomlAgent 运行时骨架# config.toml - 渐进发现 Agent 运行时配置 [llm] provider taotoken base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} # 广扫阶段用快速模型深挖阶段切强推理模型 model_forage gpt-4o-mini model_deepen claude-sonnet-4-20250514 timeout_seconds 60 max_retries 2 [discovery] # 三阶段循环上限防止无限探索 max_cycles 3 # 单轮 token 预算forage 候选太多立刻截断 budget_per_cycle 20000 # 广扫候选数量上限 forage_candidate_limit 50 # 聚焦阶段精读文件数 focus_file_limit 8 # 深挖最大依赖跳数超过就停下判断 deepen_max_hops 2 # 是否追第三方库源码 follow_third_party false [tools] # 原子工具拆开给 Agent 才能基于上轮发现重组下轮动作 enable_grep true enable_glob true enable_read true enable_follow_imports true # 不要只给一个 search_codebase()那样 Agent 无法组合 atomic_tools_only true [trace] # 记录探索证据链让过程可观测 enabled true trace_fields [ phase, query, result_count, selected_count, next_phase, token_cost, elapsed_ms, files_read, signal_score, decision_reason, cycle_index, budget_remaining ] output_path ./logs/discovery_trace.jsonl [scorer] # 业务权重生产 测试核心目录 边缘近期 久未触碰 production_weight 3.0 test_weight 0.5 core_dir_weight 2.0 recent_commit_weight 1.53.2 settings.json编辑器/工具链骨架{ taotoken: { baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, defaultModel: claude-sonnet-4-20250514, fastModel: gpt-4o-mini }, agenticSearch: { mode: progressive-discovery, maxCycles: 3, budgetPerCycle: 20000, atomicTools: [grep, glob, read, follow_imports], traceEnabled: true, tracePath: ./logs/discovery_trace.jsonl }, rag: { enabled: false, note: 中小型代码库优先 agentic search超大/跨 repo 再考虑持久化索引 }, scorer: { productionWeight: 3.0, testWeight: 0.5, coreDirWeight: 2.0, recentCommitWeight: 1.5 } }3.3 关键字段为什么这么设max_cycles 3对应 satisficing 的纪律探索不能无限循环找不到就交给人。budget_per_cycle 20000是单轮 token 上限广扫阶段候选太多立刻截断否则 token 迅速爆掉。atomic_tools_only true是渐进发现的核心工程纪律——给 Agent 原子工具它才能基于上轮发现重组下轮动作只给一个search_codebase()它就失去了“找路”的能力。follow_third_party false和deepen_max_hops 2是防止深挖追进死胡同。一路追进第三方库源码读几百行无信号是生产里最常见的坑之一。设边界不追第三方库除非点名、不追超过 2 跳依赖A→B→C 后停下判断。trace_fields里的 12 个字段是让探索变成可观测工程对象的关键。Agent 为何从 47 个结果只选 5 个为何从广扫切精读为何追pod-7c2而不是换方向这些决策必须落到 trace 里变成可调试的证据链而不是藏在模型输出里暗箱操作。4. 验证请求从模糊提问到精准命中的渐进发现流程配置就绪后跑一次完整的渐进发现验证。用一个模拟的电商订单邮件 bug 场景观察 Agent 如何从模糊提问逐步收敛到精准命中。4.1 广扫阶段低成本扫描拿候选Agent 收到模糊提问“订单确认邮件偶尔混入其他客户的订单条目”。第一步不是读文件而是用 grep/glob 做低成本广扫。# 广扫找邮件发送相关入口 grep -rn send.*confirm --include*.rb ./app | head -50 # 输出示例30 个候选文件名 # app/mailers/order_confirmed.rb # app/mailers/user_notification.rb # app/workers/mailer_worker.rb # app/services/order_mailer_service.rb # ...这一阶段只看文件名、路径、匹配行、周边上下文不读完整文件。token 消耗在几千级别。Agent 在 trace 里记录{ phase: FORAGE, query: send.*confirm, result_count: 30, selected_count: 5, next_phase: FOCUS, token_cost: 3200, elapsed_ms: 1800, decision_reason: 候选过多按路径权重和近期 commit 筛选 top5 }4.2 聚焦阶段精读候选建立局部理解从 30 个候选里挑 5 个最可能的完整读。Agent 用 scorer 加业务权重生产 测试、核心目录 边缘、近期 久未触碰。app/mailers/order_confirmed.rb在这一阶段跳出。# 聚焦精读最可能的文件 cat app/mailers/order_confirmed.rb cat app/workers/mailer_worker.rb cat app/services/order_mailer_service.rb读 5 个文件后Agent 看到调用链MailerWorker → Cache.get_user → render。trace 记录{ phase: FOCUS, query: read top5 candidates, result_count: 5, selected_count: 3, next_phase: DEEPEN, token_cost: 8500, elapsed_ms: 4200, files_read: [ app/mailers/order_confirmed.rb, app/workers/mailer_worker.rb, app/services/order_mailer_service.rb ], decision_reason: 调用链指向 Cache.get_user需深挖 cache key 构造 }4.3 深挖阶段沿可疑链追找到根因沿调用链继续追读Cache.get_user的实现# 深挖追 cache key 构造 grep -rn def get_user ./app ./lib cat app/cache/user_cache.rb发现 cache key 用了order_id缺customer_id# app/cache/user_cache.rb def self.get_user(order_id) key user:order:#{order_id} # 缺 customer_id导致跨客户命中 Rails.cache.fetch(key) { User.find_by_order(order_id) } endBug 找到。仅 4 轮探索、约 18K token、3 分钟。trace 记录{ phase: DEEPEN, query: Cache.get_user cache key, result_count: 2, selected_count: 1, next_phase: VERIFY, token_cost: 6300, elapsed_ms: 2100, files_read: [app/cache/user_cache.rb], signal_score: 0.92, decision_reason: cache key 缺 customer_id与 bug 现象一致 }4.4 验证阶段用反例和边界条件确认没找错补一个 Verify 阶段用反例验证如果 cache key 加上customer_idbug 是否消失Agent 可以生成一个最小复现测试# spec/cache/user_cache_spec.rb it does not leak user across customers do user_a create(:user, order_id: 1, customer_id: 100) user_b create(:user, order_id: 1, customer_id: 200) expect(UserCache.get_user(1, customer_id: 100)).to eq(user_a) expect(UserCache.get_user(1, customer_id: 200)).to eq(user_b) end验证通过闭环完成。整个流程从模糊提问到精准命中Agent 自主找路每一步都有 trace 可查。5. 本篇常见错排查渐进发现落地时下面几个坑出现频率最高。5.1 Forage 关键词太宽token 爆掉现象“登录变慢”直接 greplogin得到 5000 候选token 迅速爆掉。解法用更窄关键词LoginController/auth_timeout或者用轻量模型把用户描述翻成 5-8 个精确词。配置里forage_candidate_limit 50就是硬截断。5.2 Focus 挑错文件读到一堆测试现象scorer 把测试文件排前面Agent 读了一堆test/spec无信号。解法scorer 加业务权重生产 测试、核心目录 边缘、近期 久未触碰。配置里production_weight 3.0、test_weight 0.5就是干这个的。5.3 Deepen 追进死胡同读第三方库几百行现象一路追进第三方库源码读几百行无信号。解法设边界不追第三方库除非点名、不追超过 2 跳依赖。配置里follow_third_party false、deepen_max_hops 2。5.4 Discovery 和 RAG 撞车Agent 不知信谁现象两个系统结果不一致Agent 不知信谁。解法先定主路径而非简单混用。中小库/隐私敏感 → Discovery超大/跨 repo → 索引灰度地带明确定义冲突谁优先。配置里rag.enabled false是默认走 Discovery需要时再开。5.5 zero_signal_rate 突然升高现象三阶段跑完仍无有效信号的比例突然升高。这往往不是模型变笨而是工具层出问题——grep 没查到、read 权限错、scorer 排序坏、索引过时。先查工具层再查模型。5.6 trace 没开探索变成暗箱现象Agent 说“找到了”但你不知道它怎么找的、为什么选这个文件。解法trace.enabled true12 个字段全记。Discovery 的价值不只是答案也包括中间证据链。6. 让 Agent 学会找路从最小闭环到生产观测跑通上面的最小闭环后下一步是把它变成可观测、可调优的小系统。三个健康指标值得盯指标含义健康线cycles_to_success_p50找到答案需几轮接近 1forage_to_focus_ratio广扫 token / 聚焦 token0.3-0.5zero_signal_rate三阶段跑完仍无有效信号的比例 5%forage_to_focus_ratio太高说明关键词太宽太低说明关键词太窄。zero_signal_rate突然升高先查工具层。工业级 Discovery 不是一段“会搜索的代码”而是一套小系统前面 atomic tools 接触真实世界中间三阶段循环控制节奏旁边业务上下文把搜索变诊断后面 trace 指标让过程可观测可调优。渐进发现的灵魂是 satisficing——不是在有限时间/有限 token/有限上下文里追求理论最优解而是找一个足够好的解。想通这点工程决策全通了为什么有max_cycles探索不能无限循环。为什么有 token budgetDiscovery 的目标是有纪律地看不是越多越好。为什么 atomic tools 优于search_codebase()拆开工具才能基于上轮重组下轮动作。为什么 agentic search 优于 RAG它不假设索引覆盖一切而是带着当前线索逐步逼近。设计探索型 Agent 的关键给原子工具、给好的 keyword 推导、给 satisficing 的纪律。这比把整个代码库一股脑塞给它重要得多。记住Discovery 是侦探——广扫够广、聚焦能准、深挖够克制。如果你在接入或排障时遇到配置对不上的问题优先查接入文档和 API Keys 页面想先验证模型对话是否通用模型对话入口长期跑编码类 Agent看 Coding Plan 的额度说明。把上面的config.toml和settings.json复制下来替换 Key跑一遍那个订单邮件的模拟场景你会对“Agent 学会找路”这件事有完全不一样的理解。