Scouts by Yutori：任务列表抽取与仓库修复，发布层仍未接上

7 月 21 日，Scouts by Yutori 的代码层继续动，但这次新增的仍是维护信号：Python SDK 抽出共享的任务列表命令封装，并补齐异步客户端测试夹具；MCP 修掉一个会吞掉新脚本的 .gitignore 规则。三项改动都没有进入正式版本，也没有对应的官网产品公告。123

对竞品判断来说，今天的重点不是「有多少条 commit」，而是维护工作仍停留在开发者入口和仓库卫生，尚未转化为用户能安装、调用或比较的新能力。

7 月 21 日 20:18（北京时间）的提交，为 SDK 测试加入 async_client fixture，用来替代异步测试中反复手写的 AsyncYutoriClient 上下文；提交说明写明这是测试结构整理，没有行为变化。2

21:07 的另一条提交把 browse.list_tasks 与 research.list_tasks 的重复命令体抽成 list_and_render_tasks()，两个命令继续沿用原有参数和控制流。提交说明同样标注「No behavior change」，并称 CLI 测试通过；它降低了后续修改列表输出时的重复维护成本，但没有新增 API、CLI 参数或任务类型。1

这两条提交和前一天的 render_entity_table() 抽取属于同一条线索：Yutori 在整理 CLI 的列表获取、渲染和测试边界。这个方向可能是在为后续版本降低维护成本，但当前证据不足以把它升级为 Scouts 的产品功能更新。

MCP 在 21:06 提交修复了 .gitignore 中多余的 scripts/* 规则。此前，新建脚本可能不会出现在 git status 或 git add -A 的结果里；修复后，脚本目录中的新文件可以按正常流程被发现和提交。提交没有新增工具、输入字段或响应格式。3

这对维护者有用，对 MCP 使用者暂时没有直接变化。把它和 SDK 的任务列表抽取放在一起看，开发线在收口工程重复项，产品线却没有同步给出新的安装包或公开接口。

Python SDK 的 Latest 仍是 v0.8.1，页面标注发布日期为 6 月 25 日；MCP 的 Latest 仍是 v0.3.1，页面标注发布日期为 6 月 26 日。7 月 21 日的三条提交都没有对应的新 tag。45

官网 What's New 当前最新条目仍是 5 月 6 日的 Navigator n1.5。桌面端 Releases 的 Latest 仍是 v0.4.14，页面标注发布日期为 5 月 2 日。67

所以现在不能把 main 分支的连续维护写成「产品正在快速迭代」。对同类产品团队更有用的判断是：Yutori 仍在打磨 SDK/MCP 的开发者体验，但正式发布节奏尚未恢复，新的接口、权限、套餐或可靠性承诺仍没有公开证据。

本窗口没有检出可核验的融资、合作或媒体产品事件。Yutori 官方公司页当前展示的是使命、团队和投资方信息，没有带 7 月 21 日至 22 日事件日期的更新。8

官方 yutori_ai 时间线返回的最新可验证条目仍是 7 月 16 日 09:13（北京时间）的一条转发，内容为「new @yutori_ai lander: web agents @ web-scale」，不属于本窗口的新产品主贴。9

Product Hunt 当前仍列出 3 次历史 launch，Reviews 区显示「No reviews yet」。这能说明社区页面没有积累新的公开 review，但不能用来推断用户满意度，更不能替代带具体任务、结果和发布时间的独立使用反馈。10

Scouts by Yutori 的定位仍是让一组 AI agents 按计划持续监测网页，把发现交付成报告或可更新结果；公开产品页和历史更新也显示，Yutori 正在把网页监测与任务执行、MCP 和开发者平台放进同一套产品体系。68

但 7 月 21 日的增量只证明工程线仍有维护，不足以改变产品竞争力判断。当前最稳妥的结论仍是：运行和开发基础没有停摆，发布层和外部用户验证没有跟上。

未来 24 至 48 小时看两件事。第一，list_and_render_tasks() 和 MCP 仓库修复是否进入新版本，并在 release note 里写出使用者能感知的变化。第二，官网或官方账号是否重新发布 Scouts 的功能、权限或运行边界说明。若两项都没有发生，判断不变：Scouts by Yutori 的代码维护仍在继续，发布层还没有接上。