企业官网建设流程全解析

• 后端
• API网关
• MCP 服务
• dsh-plugin

本文以 treg.to（OpenRouter for agent tools）仓库中 marketing/rebuild/06-grok-bot-use-cases.md 的规划文档为骨架，完整讲解 Grok Bot 接入 treg.to 后的所有真实用例如何被映射为「单次调用的 job」与「多步串联的 workflow」两种形态：从已上线并附真实账单（receipt）的线索挖掘流水线，到因数据源可信度问题被暂时搁置的「X 平台投诉线索配方」，再到面向新兴搜索词的 SEO 落地策略。读完你将掌握：如何用一句话把 Grok Bot 从「能浏览」升级为「能拿数据」，如何按类别为它点单式指派 job，以及一条 workflow 从草稿、实验验证到正式上线的完整判定标准。

核心前提：站点已经为每种用例准备好了容器

规划文档开宗明义地指出：网站已经存在正确的容器，用例地图本身不需要新建任何东西。在 treg.to 的页面结构中，每一种 Grok Bot 用例都恰好落入两种形态之一：

• job（作业）：一次调用解决一个问题，落在/use-cases/<job>页面，并在/agents/grok-bot的「The menu（菜单）」中按类别分组列出，每组带一个类别提示词（category prompt）；
• workflow（工作流）：把多个 job 串成一条流水线，用户只写一个提示词，系统按步骤依次执行并产出一张真实运行的账单（receipt），落在/workflows/<slug>页面，并且现在每一个 agent 页面的「Workflows」区段都会列出它。

也就是说，真正的工作不是搭结构，而是判定哪些用例值得被真正跑一遍并写成 workflow——因为仓库中对 workflow 页面的硬性要求是「没有真实 run 就不写页面，数字就是页面本身」（见 src/treg/agent_pages.py 中 WORKFLOWS 字典的注释：A workflow page is never written without a real run behind it; the numbers are the page）。

用例地图：九个场景与两种形态的映射

文档给出了完整映射表，这里逐行保留并展开：

表格中的「jobs 已上线」意味着这些能力已经存在于 src/treg/agent_pages.py 的USE_CASES目录里，并且 agent 页面按类别渲染出菜单与提示词。例如：

• 「Market research」类别提示词为"Using treg, who is hiring salespeople this month, and what do their employees say about working there?"；
• 「Social listening」为"Using treg, find 20 TikTok creators posting about home espresso with 50k to 500k followers."；
• 「Search & rankings」为"Using treg, which queries is treg.to ranking 8 to 15 for in Search Console, and who outranks us?"。

这些提示词定义在CATEGORY_PROMPTS（agent_pages.py），而类别的一句话描述在CATEGORY_BLURBS（agent_pages.py）。Grok Bot 与 ChatGPT、Claude、Cursor 等 agent 共用同一份菜单：同一套 job、同一份价格、同一张 receipt。

线索挖掘 workflow：第一个真正跑通的多步流水线

映射表中唯一标注「已上线」的 workflow 是find-and-verify-a-lead-list。它在源码中的完整定义位于 src/treg/agent_pages.py，其页面文案的核心承诺是：

Give your agent one prompt and get back a lead list with a named person, a verified work email and a scored reason to write, for every company that fits.

即：一个提示词，换回一张「每家目标公司都带具名联系人、已验证工作邮箱和可打分开场理由」的线索表。

七个步骤与它们背后的真实账单

workflow 由 7 个步骤串成，每一步都标注了实际 run 使用的端点、计价方式与「为什么这么设计」：

1. 构建公司列表：apollo.companies.search——50 家美国软件公司，51–200 人规模，最近一轮为 Series A。Apollo 按页计价而非按公司计价，所以一页 50 家只收一次钱（workflow 中专门用"once": ("apollo.companies.search",)标注了这类「整单只调一次」的步骤）；
2. 用 jev 判定匹配度（decision）：typesafe.jev——在花任何付费步骤的钱之前，让 jev 只基于列表字段判断该公司是否符合 ICP（B2B 软件、面向销售/市场团队），低于 50% 直接丢弃。Apollo 列表页免费携带 domain、NAICS/SIC 代码、营收与人数增长，jev 读这些字段返回概率；
3. 找人：findymail.search.employees——找每家公司的 VP/Head of Marketing。Findymail 按返回的联系人计费；LeadMagic 的角色查找器作为兜底；
4. 找工作邮箱：tomba.people.email.find——指定「只按命中计费的最便宜提供商」。Tomba 是 catalog 里最便宜的 per-success 查找器，但在这次 run 中 treg.to 自己的 key 上容量不足，于是由 Hunter 顶上、Kitt 补 Hunter 的 miss；三家 miss 都免费；
5. 验证邮箱：leadmagic.people.email.verify——丢掉不可投递的，unknown 单独保留。LeadMagic 每个确定性判定收四分之一 credit，unknown 不收费；
6. 找开场素材：predictleads.companies.news_events——每家公司的最近三条新闻。PredictLeads 按调用计费；Akta 单次更便宜但首跑时额度不足；
7. 用 jev 给开场打分（decision）：typesafe.jev——从新闻事件里选出最该用来写第一句话的那条，并按四级量表打分，CSV 按开场强度排序。

jev 是决策步骤，不属于 catalog capability（调用走团队自己的 TypeSafe key），它的费率单独登记在DECISION_STEPS表中：$0.00002 / verdict，理由是单条公司行约 500 input tokens、按$0.042 / 百万 tokens的清单价折算（agent_pages.py）。

两次 run 的账单演化：$3.62 → $2.33

规划文档（2026-08-28 写作）记录的首次 receipt 是2026-08-26 的 $3.62 / 50 家公司。而当前仓库中run字段已经更新为2026-09-23 的第二次 run，总费用 $2.33，关键变化是加入了 jev 门槛（gate）：

次跑完整 receipt（见 agent_pages.py）：

• Apollo 匹配到 958 家，取第一页 50 家，一次收费 $0.026；
• 48/50 家带可用域名（2 家无主域名，后续步骤全部停在第 1 步）；
• jev 门槛：48 家中 27 家 ≥50% 通过，21 家在付费前被丢；若把阈值提到 60% 只剩 14 家；
• 27/27 找到具名市场负责人（20 家 Findymail、7 家 LeadMagic 角色查找）；
• 21/27 找到工作邮箱（18 家 Hunter、3 家 Kitt；Tomba 容量错误免费返回）；
• 验证：20/21 可投递、1 个 unknown、0 个 invalid；
• 19/21 拿到近一年新闻事件（PredictLeads）；
• jev 开场打分：19/19，四级量表（0–3）中 4 条达到 decent 以上，均值 1.79；
• jev 两段合计：67 次判定、55,009 input tokens、清单价 $0.0023，走团队自有 key 不计入计量；
• 墙钟时间（四路并行）：约 5 分钟，其中门槛判定 48 家耗时 90 秒；
• 总计量 $2.33，即每条可投递线索 $0.12；被拦的 21 家若按本次费率跑完，大约还要再加 $1.79。

workflow 页面还保留了完整的failure_modes（agent_pages.py），这些是真实 run 暴露出的坑：门槛读到的字段太薄（Apollo 列表字段不含「卖什么给谁」，概率最高只有 67%）、不同提供商对同一筛选条件计数差一个数量级（Icypeas 计 12 家 vs Apollo 计 958 家）、最便宜的提供商随时可能容量不足（Tomba → Hunter 单命中价格翻了近三倍）、Findymail 免费 miss 却不在响应里上报计价导致按清单价结算、catch-all 域名约占 B2B 列表的五分之一等。

尚未运行的候选：目录商家 workflow

映射表里唯一标注「Not run」的 workflow 候选是「目录商家」用例：按关键词+地理位置找本地商家 → 拉取评论 → 富化。规划文档没有给它强行编造一条流水线，而是如实标记为待验证状态。这与仓库「workflow 页面必须有真实 run 背书」的纪律一致——它已经在 src/treg/routers/web.py 的 Workflows 渲染逻辑里，但只要没有 run，就不会出现在WORKFLOWS字典中，也就不会生成页面。与之对应的 job 能力（按关键词+位置搜本地商家、商家评论、Google Business Profile 回复）已经在USE_CASES的「Local businesses & reviews」类别里上线（agent_pages.py），随时可以组装成下一条流水线。

Discovery PR 实际落地了什么：源码视角

规划文档「What shipped today」一节描述的内容，可以在当前仓库源码中逐一找到实现：

1. 所有 agent 页面新增「Workflows」区段。在 src/treg/routers/web.py，每个/agents/<slug>页面都会渲染<section id="workflows">，标题为"Sequences {agent} can run from one prompt"，遍历agent_pages.WORKFLOWS列出每条 workflow 的标题、步骤数（len(wspec.get("steps", ()))）与「每一步都是计量调用、花费前先展示价格」的说明。这意味着 Grok Bot 页面会直接挂出find-and-verify-a-lead-list的入口；
2. .md孪生。同一函数在as_md分支下生成 Markdown 版 agent 页（web.py），包含## Sequences {name} can run from one prompt一节，逐条列出 workflow 的句子、步骤数与 receipt 说明；每个 agent 页的 HTML<head>中通过<link rel="alternate" type="text/markdown" href="...">暴露 Markdown 版本，方便 Agent/LLM 直接抓取；
3. Grok Bot 专属 FAQ 扩为七条。AGENTS["grok-bot"]（agent_pages.py）的faq数组新增三条与本次扩展直接相关的内容：
   • 能做线索挖掘吗：可以，且这是被问得最多的序列——浏览（browse）不是数据（browsing is not data），但接上 treg.to 后 Grok Bot 能按行业/规模/融资构建公司列表、逐家找到决策人、找到并验证工作邮箱、拉最近新闻作为开场，且每一步在 bot 花钱前先报价；
   • 能做什么研究：公司研究（融资轮、人数、职位发布、技术栈、按域名的新闻）、人脉研究（LinkedIn 档案、近期帖子、工作邮箱）、市场研究（谁在招人、员工评价、竞品广告、关键词量与排名），菜单里每个 job 都是一次调用、按次计价；
   • 还不能做什么：不发送任何内容（邮件走你自己的发信序列、LinkedIn 走你自己的账号和 key）；LinkedIn 帖子搜索覆盖的是 Google 索引中的公开帖子而非 LinkedIn 自有信息流；帖子的 reactions 一次只回一页；没有「网页原文 → markdown」抓取器，网站读取是按域名做命名字段提取。
4. Grok Bot 路由与落地页。在 web.py 中，/agents/grok-bot会 301 重定向到/grokbot落地页（该 URL 才是主目的地）；agents 总览页中 grok-bot 卡片同样链接到/grokbot（web.py）。落地页src/treg/web/grokbot.html展示六个 treg 专属 bot（ICP Map Coach、Lookalike Scout、Rival Watch Desk、SERP Watch Team、Creator Shortlist Crew、GTM Expert），并有三个 CTA 指向 Grok 插件安装链接——这些约束由 tests/test_grokbot_gallery.py 用断言锁定（六位 bot 按 workflow 顺序各出现一次、CTA 链接计数等）。
5. 反向索引：job 页与 workflow 互链。web.py 实现了两个进程级缓存的索引：_jobs_by_provider()与_workflows_by_capability()，再经_workflows_for_caps()让每个 job 页面列出「链到它的 workflow」。代码注释记录了动机：此前 38 个 job 页和 2 个 workflow 页在 Google 零展示、报"URL is unknown to Google"，而由 /catalog 链接的 /tools/ 已被收录；索引上线后，任何新 job 或 workflow 一挂路由即被互链。

Provider note：为什么「X 投诉线索配方」仍是草稿

这是规划文档中最诚实也最有方法论价值的一节。这条被 @luismbat 等大 V 带火的配方（x.search.posts → x.user.profile → people.email.find → people.email.verify）卡在第 1 步的实验验证上，文档记录了一次真实的 step-1 run：

调用tikhub.x.twitter-web-fetch-search-timeline，查询"looking for an alternative to" hubspot，search_type=Latest，花费 $0.001。返回 5 条帖子，日期却是 2016–2024 年（并非最新），其中 4 条是推广 HubSpot 替代品的厂商自荐。如果基于这次结果写 receipt，它会显示「5 条帖子，0 个买家」。

文档给出了两个互斥的解释与一条行动路线：

• 要么该 provider 的Latest模式实际并不返回最新内容；
• 要么「抱怨式」措辞需要换成 X API 官方 recent search 端点——即x.x.search-posts-recent，该端点在当前仓库的 src/treg/catalog/x.extended.yaml 中有完整定义：GET /2/tweets/search/recent，按返回结果计费 $0.005 / 条帖子，必填参数query，可选max_results、start_time（须在最近 7 天内）、since_id/until_id、sort_order等；文档同时给出该路径的观测成功率约 44%（需用自己的 key）。

判定标准很清楚：在写页面之前，用更窄的查询加上 X-API 兄弟端点重跑一次；如果仍然返回厂商自荐，这条 workflow 的诚实版本就要换起点——从 LinkedIn 上竞品帖子的**评论区互动者（commenters）**开始，而不是从 X 的搜索开始。这是「先验证、后成文」的典型示范：宁可让一个高流量配方停留在草稿，也不在没有真实 run 的情况下编造数字。

面向新兴搜索词的页面策略

规划文档最后处理了 SEO 落地问题。「grok bot lead generation」这个术语当时（文档写作时）仅 17 天龄，尚无测量到的搜索量，SERP 也很软（x.ai 公告、一天龄的 YouTube 视频、一个 r/AI_Agents 帖子、两篇 setup 指南）。文档的决策是不新建页面去抢这个词：

• 承担该术语的页面就是已上线的线索列表 workflow本身（/workflows/find-and-verify-a-lead-list），当 workflow 页面具备 agent 专属渲染能力时再为它重拟标题；
• 或者用 X Article（marketing/_grok-bot-treg-2026-08-28.md）链接到该 workflow；
• 监测节奏：第 7 天 / 第 21 天检查精确头部（exact-head）排名位置，自动补全（autocomplete）每周复查。

这套做法与仓库整体的内容策略一致：workflow 页面的数字来自真实 run（"run"字段手录并标注日期），receipt就是页面本身；针对尚无法测量、但通过全部七项「新兴术语门槛」的词，用现有页面改标题承接，而不是为词造页。

结语：从这张地图能看到什么

把规划文档、源码定义和两次真实账单放在一起，能提炼出 treg.to 编排 Grok Bot 用例的完整方法论：

1. 一切用例先落为「菜单里的 job」——一次调用、一个价格、一个 /use-cases 页面，绝大多数研究类场景到此为止已经可用；
2. 只有被反复要求的、跨多个 job 的序列才升级为 workflow——升级的硬门槛是一次带 receipt 的真实 run（WORKFLOWS的注释与run字段都是证据），账单既用于定价展示，也用于失败模式分析；
3. 数据源可信度问题会显式阻塞路线——X 投诉配方被「5 条帖子、4 条厂商自荐」的实验结果拦住，替代路径（X 官方 recent search、LinkedIn 评论者）都写在了文档里，等下一次验证；
4. 结构服务于检索——Workflows 区段挂在每个 agent 页、.md孪生暴露给 Agent/LLM、反向索引打通 job/workflow/provider 三层互链，新兴搜索词用现有页面承接而非新建空页。

想继续深入，可以从这几处源码读起：WORKFLOWS 字典与 find-and-verify-a-lead-list 全定义、AGENTS["grok-bot"] 的 FAQ、agent 页面 Workflows 区段与 .md 孪生的渲染、x.x.search-posts-recent 端点定义，以及 join-problem 规划文档——后者是潜客研究类用例的下一张候选 workflow 蓝图。

• 后端
• API网关
• MCP 服务
• dsh-plugin