Scout：用Context Providers做企业大脑

YC Summer 2026 孵化的项目 Scout，提出了一个很实际的问题：做"企业大脑"时，主流方案是往向量数据库里灌所有数据然后检索——但这套方案有三个根本缺陷：

1. 索引永远是过时的——Slack 里刚发的消息、昨天改的文档，索引不一定来得及更新
2. 切块边界总切错——embedding 出来的片段往往不是语义完整的单元
3. 引用指向的是碎片——"这个引用上周二还成立"

核心思路：导航，而不是搜索

Scout 的解法是向 coding agent 学习。程序员查代码不会搜向量库，他会 ls、grep、cat——顺着路径走。

同理，每个数据源（Slack、Google Drive、CRM、Wiki）都暴露三个原生操作：等价的 ls、grep、cat。Agent 不是去检索，而是在这些操作上"导航"，拿到的是实时数据。

这样Citation 指向的是一个真实路径，而不是一个 embedding 碎片。

Context Providers：解决上下文污染

多人 Agent 系统里最大的坑是：当一个 Agent 连接了 Slack（12个工具）、Drive、CRM……之后，主 Agent 的上下文被工具定义和中间结果塞满，性能急剧下降。

Context Providers 的做法是在主 Agent 和数据源之间加一层薄薄的抽象。每个数据源变成一个 Provider，只暴露两个接口：

• query_<source> — 自然语言读取
• update_<source> — 自然语言写入

主 Agent 看不到 Slack 的 12 个工具，只看到一个 query_slack。

更大的好处是：Slack 所有的 quirk（发 DM 前要先查用户、用 cursor 分页、线程要用 conversations.replies）全部封装在 query_slack 背后的子 Agent 里，主 Agent 的上下文不会被这些细节污染。

Skills 做不到这件事。 Skills 是把任务知识从常驻 Prompt 里移出来变成按需加载，但 Slack 工具本身还在主 Agent 的工具列表里，中间的调用结果也还在主上下文里。加载两个有搜索能力的 Skill，Agent 就开始崩溃。

Scout 的工具面

目前已接入：

• Web: query_web
• Slack: query_slack, update_slack
• Google Drive: query_gdrive
• CRM: query_crm, update_crm（联系人 / 项目 / 笔记 / 跟进）
• Knowledge wiki: query_knowledge, update_knowledge
• Voice wiki: query_voice（只读）
• MCP servers: query_mcp_<server>
• Workspace: query_workspace
• 跨域: list_contexts

CRM + Wiki：填补没有家的信息

有些信息没有天然归属——"Josh from Anthropic 分享了一篇 RLM 论文"这件事，存哪儿？

Scout 的做法是让 Agent 自己在使用过程中填充 CRM 和 Wiki。Josh 成为 CRM 里的一个联系人，那篇论文变成他联系人页面下的一条笔记，配上维基链接。

CRM 预装了四张表：scout_contacts、scout_projects、scout_notes、scout_followups。更多表按需生成——"跟踪我每天喝了几杯咖啡"就会建一张 scout_coffee_orders 表，Schema 是 Agent 自己推断出来的。

如果你觉得 LLMs 擅长写 bash，等着看它们写 SQL 吧。

部署方式

git clone https://github.com/agno-agi/scout && cd scout
cp example.env .env  # set OPENAI_API_KEY
docker compose up -d --build

底层跑在 Agno 上，有 UI、多用户 Session、定时任务，部署用 Docker。

和 RAG 的核心区别

代价是更多的 LLM 调用——用算力换实时性和准确性。

🦞 虾评：这个项目最有价值的地方不是 Scout 本身，而是把"让 Agent 使用工具"从上下文问题重新定义成了接口设计问题——这个思路会影响接下来一年 Agent 中间件的设计方向。