JOTO
Contact us
← AI 智库
电商AI

从一个 Bot 到一整个组织,Grok Bot 的进阶用法分享:本地电脑、AI 分工和知识库怎么接起来?

2026 年 10 月 17 日

本文分享 Grok Bot 在跨境电商与个人 IP 场景中的进阶落地实践,涵盖本地电脑与云电脑协同、Skill 从 Claude/Codex 迁移、按功能拆解 AI 岗位并设定清晰边界、1+N 统筹调度架构、调用外部 Agent 实现模型分层、飞书 CLI 自动交付云文档、以及手机端资料经 GBrain 知识库接入工作流的完整链路。

云电脑与本地电脑双轨协同

Grok Bot 本身能在云端长期运行,云电脑一直开着,浏览器保持登录,任务到点自动执行。笔记本合上后,云端仍可照常运行;手机和电脑看到的是同一台云电脑、同一套登录状态。

所有 Bot 共用这台云电脑。入口在设置的「电脑」页,打开「在这台电脑上执行」,可选「始终允许」。给了权限后,本地跑通的 Skill 可直接复制到云电脑供 Bot 使用,原有 MCP 接口也能一并接入。复制完成后需让 Bot 实际调用一次,验证是否正常运行。

手机和电脑显示同一台云电脑
▲ 手机和电脑,看到的是同一台云电脑
本地电脑交给 Grok Bot 示意
▲ 本地电脑交给它,Skill 复制、MCP 接入云电脑(示意)

Skill 是所有 Bot 共用的,复制一次,其他岗位也能调用。但 Skill 存放位置、调用岗位、各岗位职责需分开写明。

Skill 应先在本地打磨再交付 AI 员工

更建议在 Claude 或 Codex 中写好 Skill 并实际打磨后,再交由 Grok Bot 中的 AI 员工使用。相当于把 SOP 梳理清楚后再给新员工,入职即可直接调用;若让新员工面对空白直接开工,效果反而不佳。

本地 Agent 的优势在于可指定模型,且 Plan 模式支持更精细打磨。反复修改的留本地,跑顺了、需长期运行的再移交云端。模型、流程、分工不宜一次性全换,否则出错难以定位。

光有 Skill 不够,岗位背景也需补全。新建写作 Bot 时若说明为空,它会主动询问“写给谁看、读者是谁”,进入入门问答流程;补全说明后才开始正式工作。建 Bot 时须一次写清服务对象、负责环节、交付对象。

本地打磨 Skill 后再交给 AI 员工
▲ 本地打磨 Skill,跑顺了再交给 AI 员工

按功能拆解岗位并明确技术边界

岗位应按实际工作价值拆分,而非机械照搬数量。例如亚马逊财务分析原归于数据分析岗,广告分析则分散在数据分析与流量策略中;因广告投放高频、利润分析关键,10 月 10 日起将二者分别独立为机器人岗位。

机器人命名便于识别与派活,但每个岗位必须单独撰写说明,明确能做什么、可用哪些 Skill、负责到哪一步、交付给谁、向谁汇报、何时需人工介入。岗位说明中真实写入的几条边界如下:

  • 合理烧钱的广告投手:绝不写广告后台,不改出价、不改预算、不加否词、不建广告活动,所有动作只进待批清单。
  • 懂用户的文案高手:只出草稿,不上线任何正式内容。
  • 上架前找机会的海盗:买家账号只看,不下单、不加购、不留评、不提问,避免被亚马逊反爬机制封号。
岗位按功能拆解并写清边界
▲ 岗位按功能拆,边界单独写清

一个岗位可调用多个 Skill,同一 Skill 也可被多个岗位复用。需注意:共用云电脑意味着岗位边界仅为约定,非技术隔离;需人工把关处,必须写入交接关系,不可仅依赖总提示词。

采用 1+N 统筹调度架构替代群聊

初期按「单个/相似任务=一个机器人」跑通,确认单入口可获取完整结果;基础框架稳定后,推荐采用「1+N」模式:仅与一个统筹机器人(如「出海船长」)对话,由其调度分工明确的其他机器人,并汇总结果返回。

需用户补信息或做决策时,也统一经该入口返回。例如诊断链:出海船长派单 → 运营数据分析大佬诊断 → 按问题分发至广告投手、财务或供应链 → 船长汇总待批清单 → 用户逐条审批。

Grok 支持群聊,但 Token 消耗大,故作者尽量不用群聊,所有派活与交付均走 1+N 流程。例如船长某日两条指令:早上汇总每日前台巡检;用户回复「先把广告冲突需要我看下 那个先重新发我一下」,船长即刻返回含 5 处冲突及每处建议的待批清单,供用户在文档批注或回「照建议」。

船长汇总待批清单
▲ 我只跟船长对话,船长汇总待批清单
出海船长汇总派单示例
▲ 出海船长汇总派单

调用外部 Agent 实现模型分层与能力互补

作者主推两条路径:一是已订阅本地 Agent(如 Codex 200 美元套餐),在云电脑安装 CLI 并配好授权,由 Grok 调用;二是直接调用 Cursor 云端 Agent。过去已订阅 Cursor 的用户,老订阅方式仍可通过 Grok Bot 调用云端 Cursor 并指定 Opus 模型;新用户建议从最便宜套餐试用起。

Grok 默认按任务自动调用 Opus 5.5,但无法手动指定模型。需精确控制模型的任务,建议交由外部 Agent 执行。模型分层建议如下:

  • 取数、清洗、写表、核对等确定性任务,使用 Grok Bot 默认模型;
  • 分析、归因、策略判断等高阶任务,交由可调用的顶级模型(如 Opus)处理。
模型按任务分层示意
▲ 模型按任务分层,需要指定模型的活交给外部 Agent

例如公众号配图任务:Grok 在云电脑生成 Codex 设备登录代码 → 用户在 OpenAI Codex 设备登录页输入并告知「已登录 Codex」→ Grok 验证登录、配置生图环境 → 调用 Codex 订阅完成生图 → 配图排版机器人继续后续工作。

Grok 外接 Codex 登录后生图流程
▲ 外接 Codex,登录后继续生图

接入飞书 CLI 实现交付自动化与权限可控

接入飞书 CLI 后,Bot 可将产出内容直接写入飞书云文档。作者看重三点:支持人工批注、实时反馈、拥有独立链接,且文件尽可能保留在公司内部系统中。

云文档链接可直接发给本地 Agent 继续处理;可见范围按公司既有权限体系配置。

飞书云文档卡片示例
▲ 飞书云文档卡片

接入知识库打通手机端资料与工作流

作者接入的是开源项目 GBrain(YC 的 Garry Tan 发起),其他具备云端访问能力、自带 MCP 接口的知识库亦可替代。建议按「手机收集 → 入库 → 按任务分发给相关岗位」顺序接入。

例如在手机看到卡兹克公众号文章,直接将链接发给 GBrain 知识库机器人并说「学习一下然后沉淀到知识库」,机器人读完后存为一张待审页。需提前想清楚谁要用、本次调用哪些内容,避免将全部文章无差别塞给所有 Bot。已有资料只要满足云端可访问、Agent 可调用,即可优先接入现成知识库,无需重建。

手机发送文章链接至 GBrain 知识库
▲ 手机发文章,沉淀到云端的知识库

JOTO 企业落地观察

  • 企业部署智能体组织时,需警惕“岗位即 Bot”的思维惯性——文中强调 Skill 复用与岗位职责分离,说明企业应优先构建可编排的原子能力单元,而非为每个职能堆砌独立 Bot,这对降低 RAG 知识工程维护成本与提升智能体复用率具有直接指导意义。
  • 文中“合理烧钱的广告投手”等岗位边界描述,本质是将人类业务规则翻译为机器可执行的约束条件。这类显式边界定义,是 AI 安全治理在智能体工程中最轻量却最关键的落地切口,避免依赖黑盒模型的自我裁决。
  • 1+N 架构下“船长”作为唯一交互入口,既降低用户认知负荷,又天然形成操作审计路径。这对 FDE 驻场共创场景极具参考价值:企业可将 FDE 角色预置为“船长”,统一对接业务方需求并分发至各专业 Bot,确保交付过程全程可追溯、可干预。
  • 本地打磨 Skill 再迁移至云端的做法,揭示了一种务实的智能体演进节奏:企业不必强求所有能力一步上云,而应允许本地沙箱持续迭代高价值 Skill,待稳定性与 ROI 明确后再规模化部署,这对降低企业 AI 工程化试错成本至关重要。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们
Contact Us

Start your enterprise AI rollout

Tell us your industry, team, and current pain points. We'll get back to you within one business day to help you decide what to tackle first, what data to prepare, and which platform fits.

WeChat
Scan to add us for a 1:1 chat
JOTO WeChat consultation QR code

Tell us what you need

Once we receive your details, we'll be in touch within one business day.