【搜索能力反馈】云文档搜索无法发现多维表格记录与个人版(my.feishu.cn) Base

[hoangngochuong24947-gif]

背景

使用官方 CLI（lark-cli v1.0.96，npm @larksuite/cli）驱动 AI Agent 日常操作飞书。遇到「搜索与资源发现」的三个盲区：Agent 明明有权限读写某个 Bitable，却无法通过任何搜索/枚举接口发现它，只能靠人工粘贴链接。

环境

• macOS，lark-cli v1.0.96，user_access_token 授权
• 租户：qcn1egiawdhn.feishu.cn；问题资源位于个人版域名 my.feishu.cn 下

盲区一：云文档搜索不覆盖多维表格记录内容

复现：以某条 Bitable 记录的字段值（如任务名称「整理读代码相关文档」）为关键词，调用 Search v2（doc_wiki/search，对应 CLI drive +search / docs +search），返回 0 结果——该记录真实存在且有权限。

期望：搜索索引覆盖 Bitable 记录级内容，或提供按关键词跨表搜记录的接口。

盲区二：个人版（my.feishu.cn）Base「能读不能搜」

复现：对 my.feishu.cn 域下一个 Base：

• 给定 URL 后 base +url-resolve、+field-list、+record-search、+record-update 全部成功（user token 有读写权限）；
• 但 drive files list（根目录及目录树递归）与 +search 返回中完全不存在该 Base。

影响：同一份 token「读得到但搜不到」，发现能力与权限不一致。

盲区三：缺少「列出我有权限的所有 Bitable」入口

drive files list 只能沿 folder-token 目录树遍历；文件若由应用/妙记等创建于特殊空间，无法被发现。

实际影响

Agent 自动化场景（任务调度、妙记纪要转任务）中，表定位完全依赖人工提供链接；同模板多表并存时极易写错目标表。

建议

1. 搜索索引覆盖 Bitable 记录；
2. search / files 接口结果覆盖用户可访问的个人版域资源；
3. 或新增 list-accessible-bases 类发现接口。

---

同一反馈已通过邮件提交至 contact@feishu.cn。

[hoangngochuong24947-gif]

补充：问题不止官方 CLI，是所有外部 AI Agent 访问飞书内容的通病

收到用户视角的重要补充，请把本 issue 的定位从「CLI 搜索盲区」升级为「飞书内容对 AI Agent 的可编程访问是一等公民问题」：

实际场景（用户主力工作流在本地，非云端）：

1. 云端 Agent（如豆包）：读取飞书文档已经很困难，要看多维表格里的具体内容，Agent 只能自己去打开浏览器操作网页——自动化链路里混入浏览器会话，脆弱且不可靠。
2. 本地 Agent（更常见的形态）：没有云端浏览器会话、没有现成授权体系，连「打开浏览器」这条路都没有，访问飞书文档/多维表格比云端更难受。
3. 结果：用户被迫在浏览器里人工复制粘贴内容喂给 Agent，飞书成了自动化工作流中最难打通的一环。

对飞书的建议（在原三点搜索建议之上，追加）：

• 把「AI Agent 可编程读取飞书内容」作为明确的建设方向：文档与多维表格的记录级结构化读取 API 应做到不需要浏览器就能完整获取；
• 提供面向本地 Agent 的标准接入方案（本地 CLI / MCP + user 授权流程），让任何外部 Agent 不依赖浏览器会话即可读写；
• 官方 CLI 已是很好的起点，建议把它背后的能力（授权、搜索、读取）打磨成「任何 Agent 开箱即用」的基础设施，而非仅覆盖官方 CLI 自己。

原 issue 的三个搜索盲区（记录内容不进索引 / 个人版 Base 能读不能搜 / 缺 list-all-bases 接口）在上述场景下影响被进一步放大：本地 Agent 连「给个链接再解析」的机会都常常没有。