先看证据
生产搜索先要定义什么算完成
TinyFish 的两篇工程文章讨论的是面向生产级 AI Agent 的 agentic search：系统要搜索网页、浏览网站、收集多来源证据，并据此生成带引文的报告。它们分别提出一套搜索控制架构，并复盘 deep research 系统在规划、上下文和子任务编排上的设计调整，目标不是让模型多搜几轮，而是让搜索结果能被核验、失败能被识别。
这组材料值得技术负责人读，不是因为它给出了一个新的 Agent 名词，而是因为它把问题从“模型能不能找到答案”挪到了“系统凭什么认为答案已经足够”。当研究过程会迭代、用户会追问、网页又可能不可访问时，搜索质量不能只看最终文本是否流畅，还得看证据覆盖、来源质量以及系统何时决定停下。需要说明的是，所给原始页面摘录主要是 cookie 文本，具体架构内容来自随附研究材料对 TinyFish 两篇文章的整理，无法据此独立核验文章全文或其线上表现。
证据契约把搜索变成可验收任务
生产架构文章用“证据契约”描述任务级要求。它要先说清楚需要哪些事实或字段、什么来源和时效可以接受、是否必须给出出处、输出应是什么格式，以及哪些结果算完成、部分完成、失败或需要人工处理。TinyFish 特别说明，这是文章采用的工作术语，并非宣称已经成为行业标准。它的价值在于把“找相关网页”改写成可以验收的交付要求。
这份要求贯穿一个七阶段流程，文章还把它展开为十一项动作：定义任务与证据要求，拆解信息需求并安排依赖，生成查询和选择起始工具，发现、筛选并获取来源，评估证据是否充分，按失败类型重试或升级访问方式，最后停止并验证结果。阶段数本身不是质量保证，但它迫使设计者把规划、取证、判断和终止放进同一个控制流程，而不是只在末尾加一道“请附引用”的提示词。
工具选择应由证据缺口决定
架构的关键不是把搜索、抓取、浏览器和 Web Agent 全部接上，而是根据当前缺什么来路由。来源未知时先搜索；已有 URL 时直接抓取；需要操作页面或保留会话状态时用浏览器；需要跨多个网页自主决策时才交给 Web Agent。这样的区分把工具调用变成一种有理由的访问策略，也避免把每个网页任务都升级成最重的 Agent 流程。
取回内容后，评估器检查证据覆盖、来源、时效和冲突。材料列出五种评估状态：充分、不完整、冲突、无法访问、预算耗尽。状态划分的意义在于，不完整的证据不应被包装成确定答案，来源冲突也不该被简单平均掉；系统应据此判断是换查询、换来源、改变访问方式，还是明确报告目前无法解决。
移除独立规划器，不等于取消规划
TinyFish 的 deep research 复盘解释了为何调整组件边界。早期版本由独立 planner 生成子问题、查询和研究策略，再交给 orchestrator 执行。研究进入迭代阶段、用户提出追问后，orchestrator 已拥有对话历史、先前报告和中间发现；重新调用的 planner 却只收到结构化状态，可能因此失去重要上下文。问题不一定是规划能力不足，而可能是规划与执行分处两个状态空间。
TinyFish 后来把规划并入 orchestrator 的同一推理循环，并取消了逐查询启动 subagent，改用工具做确定性的排序、分类和证据提取，再把整理后的结果交回 orchestrator。因此，“生产架构有 planner 职责”和“复盘说移除了 planner”并不矛盾：前者谈工作流需要规划，后者谈不再把规划封装成独立组件。团队可以把这看作上下文连续性的设计取舍，而不是“Agent 越少越先进”的普遍结论。
有上限的重试，也要允许系统停下
证据不足时，系统可以改写查询、更换来源或升级访问方式，但重试要针对具体失败并设上限。材料没有披露上限具体是多少，也没有给出 planner 合并或取消 subagent 前后的延迟、成本对照。TinyFish 称这些改动减少了上下文、延迟和成本，但现有材料只能支持这是作者的定性经验，不能推导改善幅度，更不能说明所有研究任务都适合相同做法。
对已有研究 Agent 的团队，更可执行的判断不是照抄组件图，而是先检查任务是否有明确的证据契约、路由规则、失败状态和停止条件，再观察系统是否会重复取证或在证据不足时过度自信。可以针对自己的工作负载比较独立规划与主循环规划，也可以比较 subagent 与确定性工具整理，但要记录证据覆盖、延迟、成本和未解决率。访问边界、预算或来源冲突仍可能让任务只能部分完成；生产化不是保证每次回答完整，而是让系统知道何时不能声称已经完成。