企业官网建设流程全解析

本指南面向需要让 Company Brain 完成"研究型任务"的读者：不是一次快速查价，而是要把文档、tickets、会议记录、代码和过往 Slack 线程里的信息综合成一个有依据的答案。文章先讲清楚什么是长时研究问题、期望中的交互形态，再说明当前自托管构建的真实能力边界（尚未有专门的长时研究模式），最后给出当下可直接落地的拆解式用法，并附上源码层面的实现证据。

长时研究：什么样的提问算"研究项目"

有些问题不是一个快速查找就能回答的。它们需要从许多不同的地方拉取信息——产品文档、支持 tickets、会议记录、代码仓库、过往的 Slack 讨论——再把这些零散素材综合成一个连贯的答案。这更像是接了一个小型研究项目，而不是回答一句 "what's the pricing?"。

官方场景描述原文如下（docs/guide/use-cases/long-horizon-research.md）：

Some questions aren't a quick lookup. They need pulling information from a lot of distinct places (docs, tickets, meetings, code, past Slack threads) and synthesizing it into one coherent answer. Closer to a research project than "what's the pricing?"

典型的"长时研究"问题特征包括：

• 多来源：答案必须横跨多个独立系统（Notion 文档、Linear issue、Granola 会议纪要、#sales频道历史、GitHub 代码）；
• 需要综合（synthesis）：不是罗列各来源的原文，而是提炼出一个统一结论；
• 有明确交付物：往往以"简报（brief）"、"总结"、"调查报告"的形式产出，甚至希望直接转成一份文档。

与之形成对照的是单来源问答：比如"Q2 路线图里有什么？"（查 Notion 一页即可）、"Acme 会议决定了什么？"（查 Granola 笔记即可），这类问题在 知识召回 与 会议召回 两个场景中有专门说明。

期望中的交互形态：一份跨来源的企业简报

文档给出了一个完整的示例对话，展示托管产品正在构建的目标体验。在#product频道中，用户用一句自然语言请求一份跨两个季度的综合简报，而 Company Brain 返回一份带结构化小节、带结论、带来源的答案：

#product

You:@company-brain prepare a brief on how we've handled enterprise SSO requests over the last two quarters: who asked, what we promised, what's still open, and what engineering thinks the real effort is

Company Brain:Enterprise SSO: two-quarter brief

• Demand:6 serious asks (Acme, Globex, Initech, …). Three converted to paid pilots.
• Promises made:Okta + Azure AD for pilots; custom SAML called "roadmap" in two decks.
• Still open:Globex blocked on SCIM; Initech waiting on audit-log export.
• Eng view:~6 weeks for Okta/Azure path (from#engthread Mar 18 + Linear ENG-610); SCIM is the long pole.

Sources: Q1/Q2 enterprise notes, Linear ENG-610, Granola "SSO planning",#salesthreads. Want this as a Linear doc?

注意这个目标体验的几个关键设计：

1. 问题本身是多维的：谁提了需求（who asked）、我们承诺了什么（what we promised）、还悬而未决什么（what's still open）、工程侧真实工作量（what engineering thinks the real effort is）——一次提问拆出了四个子问题；
2. 答案是按维度组织的结构化简报，而不是一段流水账；
3. 每个结论都带出处：#eng线程日期、Linear issue 编号（ENG-610）、Granola 会议记录名、#sales频道线程——读者可以回溯验证；
4. 交付物可延伸：结尾反问 "Want this as a Linear doc?"，意味着研究结果可以直接落成一份正式文档。

这正是"长时研究"模式想达到的效果：更多时间、更多并行挖掘、在回复前先做一次结构化的综合（structured synthesis）步骤。

当前构建的真实边界：尚无专门的长时研究模式

文档对这一节标注了明确的说明（引用原文）：

Not yet.This page shows the experience the hosted product was building toward. There's no dedicated long-running research mode in this build; a single turn does its best with the sources it can reach.

也就是说：

• 本自托管构建（self-hosted build）没有专门的长时研究模式；
• 当前的实际行为是：单个 turn（一次交互回合）尽力用它能触及的来源作答；
• 页面内容描述的是托管产品正在构建的方向，而非已交付的能力。

这一点与仓库代码是一致的：从源码结构看，src/brain下并没有一个独立的 "long-horizon research" 执行引擎（不存在专门的 runloop、独立的队列或持久化的多轮研究状态机），文档在 docs/guide/use-cases/overview.md 中也把"长时研究"明确列在Not yet（尚未实现）分类下，与已可用的支持、事件、文档召回等场景区分开。

但"没有专门模式"不等于"什么都做不了"——下一节说明当前单回合已经具备的多来源综合能力。

单回合已具备的能力：多连接器 + 频道记忆

文档指出（引用原文）：

Today, a single turn can already hit multiple connectors and channel memory in one answer.

这意味着当前构建里，一次回答已经可以同时跨多个实时工具和一个组织的记忆来取材，只是缺少"长时间、多轮、结构化综合"那一层。

工具连接器：实时读取与操作

根据 docs/guide/connectors.md，本构建提供的是工具连接器（tool connectors）——基于 MCP 的实时集成，不只是索引历史内容，而是当下就读、当下就操作：

连接入口是应用内的Configure → Integrations，或 bot 欢迎 DM 中的按钮。连接分两个作用域：Organization（组织共享）与Personal（个人）——读取优先走个人连接、回退到组织共享连接；写入永远只走个人连接，以便动作归属于真人（详见 权限图）。如果自己和组织都没连某个工具、但某个同事连了，Company Brain 可以请求该同事lease（租借）一次性临时访问。

记忆的三种作用域

依据 docs/guide/permissions.md，记忆不是"一个共享大脑 + 一个私人大脑"，而是一张图：

• 员工记忆（employee memory）：每人一份，来自与 bot 的 DM，仅自己可见；
• 私密频道记忆（private channel memory）：每个私密频道一份，仅该频道成员可见；
• 公共频道记忆（public channel memory）：全组织一份，来自公共频道的持久化内容，全组织可读。

一次回答能读到什么，取决于提问发生的房间：公共频道只能读公共频道记忆；私密频道还能叠加公共频道记忆；DM 是"最宽"的座位，能读员工记忆 + 公共频道记忆 + 自己所属的所有私密频道记忆。落到底层，这些分别是 supermemory 容器标签sm_org_shared、slack_channel_<channel id>、user_<user id>。

所以文档中"单个 turn 已经能命中多个连接器和频道记忆"这句话，对应的是"实时工具读取 × 权限图限定的记忆范围"两个维度的组合——这也是长时研究模式未来要在此基础上叠加"时间、并行、综合"三层能力的原因。

源码纵深：与"长时研究"相邻的现有实现

虽然专门的长时研究模式尚未实现，但仓库源码里已经存在多个与"多来源综合"思路同源的实现，可以作为理解演进方向的参照。

1. 渐进式调查（Progressive investigation）：系统提示词中的综合范式

src/brain/prompt/system.ts 中定义了一种"渐进式调查"的行为范式，其模式与长时研究文档中的示例高度同构——同样是跨来源调查、边发现边汇报、最终综合：

Progressive investigation. "why are enterprise trials stalling?" → short standalone messages as findings land: "Pulled the trial cohort — the drop-off clusters at SSO setup, not pricing." then "Support backs it up: three of the last five stalled trials hit the same SAML metadata error." → final message, high level: "Enterprise trials are stalling at SSO setup, not on price — the SAML metadata step is the shared failure and support has three recent cases. Want the specific orgs, the exact error, or what a fix takes?" Findings surface as they land; the final message synthesizes and points at where to dig instead of re-listing everything.

关键点：

• 发现边落地边浮现（findings surface as they land）：先抛短期结论（"流失集中在 SSO 设置"），再用支持数据佐证（"三个案例同一个 SAML 元数据错误"）；
• 最终消息负责综合（the final message synthesizes）：给出高层结论，并指出下一步该往哪里深挖，而不是把证据重新列一遍；
• 这与 src/brain/turn/state.ts 中"后续更新只携带净新增发现，最终回复负责综合"的状态设计相呼应。

2. 三档投入分级：xhigh 被明确定义为"长时调查"用途

src/brain/slack/triage.ts 中，路由/分诊逻辑为异常宽泛、模糊或后果重大的请求保留了最高投入档位xhigh，其适用场景描述中直接出现了 "long-horizon investigation"：

xhigh — reserve for exceptionally broad, ambiguous, or consequential work where high effort is plausibly insufficient: many interdependent checks, deep diagnosis across systems, complex strategy with major tradeoffs, or along-horizon investigation requiring repeated hypothesis testing. Do not use xhigh merely because a request is urgent, important, or asks for a polished answer.

可以推断：系统层面已经为"需要反复假设检验的长时调查"预留了资源分级的语义，只是它仍发生在单个回合内，而不是跨回合的独立研究任务。

3. 注册研究（onboarding research）：面向多来源的结构化研究骨架

src/brain/turn/research.ts 展示了一个已经落地的"研究式工作流"——组织注册时对目标公司做深度研究。它按aspect（维度）拆解研究任务：

• RESEARCH_ASPECT_PLAN定义六个维度：公司概览、产品与业务、团队与关键人物、值得关注的项目与工作、竞争对手、近期里程碑（research.ts）；
• 每个 aspect 配有独立的搜索 query 与 LLM instruction，例如竞争对手维度的指令是"说出真实竞争的对手公司"（research.ts）；
• 研究过程先抓取公司官网主页（researchHomepage，截取前 6000 字符），再逐 aspect 走contextSearch搜索 +generateText生成摘要，并强制要求 "Use only the sources below and do not invent facts"（research.ts）；
• 每个 aspect 的产出连同sources（来源 URL 列表）一起写入记忆，附带稳定的 topic 标签（company/<aspect.key>）；
• 整个流程通过brain_research与brain_research_phase两张 D1 表追踪状态，并通过syncResearchCard在 home channel 里渲染一张实时进度卡（research.ts）。

这个实现印证了文档中"多来源、多步骤、最后综合成一份答案"的研究骨架在当前构建中是真实存在的——只是它目前服务于公司注册研究这一固定场景，尚未泛化为用户可随时触发的一般性长时研究。

配套的 src/brain/turn/research-brief.ts 展示了研究产出的消费方式：把已完成的 aspect 摘要（label: detail）拼装成一段 prompt 上下文供后续回合使用——这正是"研究结论喂给后续综合"的机制雏形。

4. 自动研究（auto-research）：plan → draft → store 的批量研究管线

src/brain/auto-research/run.ts 实现了另一条"研究"管线runAutoResearch，流程是plan（规划）→ draft（逐项起草）→ store（落库）：

• 先从组织上下文、脑档案、跟踪话题中derivePlan推导研究计划，未定向的轮次还会用 watchlist 上排名靠前的话题做 backfill；
• 起草阶段以DRAFT_CONCURRENCY = 6的批量并发执行，默认maxTargets = 3、maxPeople = 2，整轮在一个批次内跑完；
• 全程由 DO 本地租赁锁（lease）保护，TTL 15 分钟、心跳 5 分钟，防止两个触发并发跑同一组织；每个草稿等待真人确认后才会发送，且"组织从未要求的工作绝不产生账单"（skipBilling: true）。

从源码结构看，auto-research 已经具备"长时间、多目标、结构化综合"的大部分机械装置（规划、批量、并发、进度追踪、人工确认），但它目前的输出形态是供人审阅的草稿笔记，而不是文档所设想的"对一个用户提问的即时综合简报"——两者之间还差一个"接到任意长时研究请求 → 编排并行挖掘 → 结构化综合成文"的用户入口。

当下的实践路径：把大问题拆成小问题

在没有专门长时研究模式的前提下，文档给出的建议是直接可用的（引用原文）：

Until then, break big questions into smaller ones (docs, then tickets, then "summarize what we have"); Company Brain already handles each of those well.

即把大问题拆成小问题，按依赖顺序逐个问：

1. 先问文档（docs）：如"企业 SSO 相关的文档在哪？我们的承诺记录在哪？"——对应 知识召回，走 Notion 等连接器的实时搜索读取；
2. 再问 tickets："过去两个季度有哪些企业 SSO 请求？哪些还开着？"——对应 Linear、Plain 等连接器；
3. 最后让它综合（summarize what we have）："把上面查到的内容总结一下"——单回合内已有能力把多来源素材收拢成一段答案。

每一步 Company Brain 当前构建都能处理得很好（文档原文 "Company Brain already handles each of those well"），而综合的职责由用户自己以"总结一下"的指令显式触发，替代了设想中自动化的结构化综合步骤。实操上的建议包括：

• 先连上团队真正会反复查阅的那几个来源（产品规格、手册、最新路线图），而不是一次性把全部工具都接进来——工具连接器的价值取决于你指向什么（见 连接器指南 的 NOTE）；
• 提问时把"事实来源"和"综合指令"分开：先确认各来源的答案，再在最后一步要求汇总；
• 对时效性敏感的问题，直接在提问里指定范围（如"近两个季度"），当前回合会以权限图限定的范围尽力取材。

阅读延伸

• 知识召回（Answering from docs）：当前单回合知识召回的形态——"Q2 路线图里有什么？"这类问题如何实时读 Notion；
• 会议召回（Meeting recall）：从会议笔记中提取决策——"Acme 会议决定了什么？"，答案带来源可回溯验证；
• 连接器（Connectors）：长时研究所需的全部数据来源如何接入；
• 权限图（Permissions）：一次多来源回答实际能读到什么，取决于提问房间与提问者身份；
• 自动化与主动性（Automations）：定时摘要与主动发言同样遵守同一张权限图。